On Sat, May 23, 2009 at 4:07 PM, Markus Rechberger <mrechberger@xxxxxxxxx> wrote: > On Sat, May 23, 2009 at 4:00 PM, BOUWSMA Barry > <freebeer.bouwsma@xxxxxxxxx> wrote: >> Moin Devin, thanks for the reply. >> >> On Fri, 22 May 2009, Devin Heitmueller wrote: >> >> [cut my drivel] >>> The dvb core does have infrastructure to support hardware pid >>> filtering. >> >> If you don't mind, and this is a serious question, could you >> give me some keywords to look for? I've come up with some >> obvious winners in dvb-usb with uppercase FILTER, but lowercase >> filter didn't give me any serious Aha! moments for other >> devices, in an attempt to determine device capabilities by >> simple code reading. Thanks! (And I'll gladly eat my shoes >> when it turns out to be something stupendously simple, as I'm >> no code-reader) >> >> >>> I don't know too much about the DVB standards, but I know >>> that ATSC is 19.39MB/s and QAM as deployed in US cable systems is >>> about twice that. Neither would fit in a 12Mbps stream. >> >> Bleedin' 'ell, I knew things were bigger in Texas, but I >> didn't know they wuz that big! ;-) Just kidding, I know >> what you meant... >> >> Just for background, the overall bandwidth of DVB-T will be >> determined by choice of frequency at one transmitter site or >> whether shared by several and how far apart, as well as other >> factors that are basically able to be simplified as a tradeoff >> of reliability over distance against bandwidth. There's a wide >> variance here, but in even the most widely-reaching Single- >> Frequency-Networks that are meant to be received at large >> distances under difficult conditions, where available overall >> bandwidth is less than that of a single transmitter serving >> a local area, said overall bandwidth is generally going to >> exceed that which I've achieved from USB1.1. A certain DVB-H >> network with 1/2 FEC and 1/4 guard interval drops below >> 10 000kbit/sec but isn't likely to represent common usage >> for broadcast TV services. >> >> On the other hand, the individual services within each >> multiplex will generally be well within the USB1.1 available >> bandwidth, provided hardware PID filtering can be applied. >> Bitrates for television services can be from some 2Mbit/sec >> up to over 5Mbit/sec at times, depending on whether that >> service has been configured to get the lion's share of the >> bandwidth at the expense of the other services with rates >> dynamically varying based on picture content thanks to >> statistical multiplexing. >> >> In any case, while I've been able to watch average-per-second >> bitrates of different PIDs on different multiplexes, I've >> just realized that I haven't actually used any DVB-T >> receivers for any length of time on a USB1.1 port to see >> if instantaneous bursts will exceed that bandwidth, as is >> the case for quality services delivered via DVB-S and USB1.1. >> >> But I've read that it's the exception rather than the rule >> that a particular service will be privileged to get more >> than its proportional share of overall bandwidth, to be free >> of most artifacts and be watchable, so I'd be willing to posit >> that a full service (video, multiple audio, PMT, teletext, and >> the like) will fit onto USB1.1. >> >> So much for background. Anyone still bothering to read? >> >> >>> If I knew of a em2874/em2884 device that also didn't use the drx, I >>> would consider it worthwhile to spend the time to do the work for the >>> hardware filtering. Until that happens though, I've got better things >>> to spend my time on. >> >> No argument there. I had a look through Herr Rechberger's >> code (simply because it's had a wider variety of included >> hardware, not to say anything about the linuxtv code) to get >> a feel for how many devices were exclusively DVB-T, or at >> least didn't include some baseband video. >> >> It appears that a group of EM2870 devices (may well be the >> 2874 in reality, I just numbly scan the code) are limited >> to DVB-T, including Terratec Cinergy T XS, Pinnacle PCTV DVB-T, >> a couple KWorld 35xU DVB-T devices, and a Compro VideoMate. >> Apart from that, all remaining devices (apart from DMB and >> the like) appear to have the ability to handle analogue >> signals, and need USB2.0 to reach full potential. >> >> >> >>> filtering in conjunction with USB 2.0. The fix is really in response >>> to users with older PCs trying to capture a full ATSC stream (or >>> analog capture), and being *very* confused. If there is really a >>> concern that we should be supporting USB 1.1 ports, even though USB >>> 2.0 has been around for almost ten years, I guess I can add a modprobe >>> option to allow the user to override the check. >> >> I actually have dredged from the dank dingy decaying dumpster >> depths or doom a machine fast enough to decode and display SD >> images, even without XVMC MPEG-2 acceleration, after replacing >> most of the electrolytic condensers/capacitors on the board, yet >> the internal USB ports are again 1.1. Given all the Blinkenlights >> it's probably an ex-gamer machine, but compared with my machine >> at some 1/7 the CPU clock, it's not as obsolete as it could be, >> though that still doesn't stop me from periodically wanting to >> hurl it across the room every so often. >> >> So there are probably still a fair number of boxen out there >> with internal USB1.1 ports, that would be my guess. And while >> I've added USB2.0 cards to my machines with as many ports as >> possible, I still find I can take advantage of the original >> USB1.1 ports, and often I need to, given how external devices >> appear to breed, and external hubs are not always reliable. >> >> >> If I were to have some supported em28xx device where I only >> wanted part of a transport stream, I'd probably try to come >> up with hacks to make it work on selected inputs when attached >> to a USB1.1 port. Rather, I have the opposite problem, that a >> specific device will connect via USB1.1 yet does not perform >> the hardware filtering, and as such is useless apart from a >> handful of SCPC feeds, and gives no warning. Probably I >> should polish and submit the patch I made for that, although >> it was merely a code comment to say this doesn't work as >> advertised, rather than loudly warning the victim. >> >> Hmmm. I See A Great Need. Of course, I don't mean to be >> volunteering you, and for now, a give-user-loaded-pistol- >> with-instructions-concerning-feed* type of module parameter >> is probably adequate -- as you note, it may well suffice to >> get some uncorrupted scan results amidst a heap of garbage, >> but without hardware PID filtering, save for extreme cases, >> probably is a knob to twist with a view to the future. >> > > this patch is not good, the em28xx TS input does not necessarily need > to carry DVB-T or ATSC it can carry any mpeg-ts input. At a lower > speed (eg. from mpeg encoderchips) it _can_ work. For example ISDB-T 1 Seg. ISDB-T uses QPSK for modulation, with 2/3 forward error correction and 1/4 guard ratio. The total datarate is 416 kbit/s. > > Markus > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
