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. barry bouwsma * Original typo. I corrected it to the intended `feet', had a bit of a think, and decided my subconscious deserves some praise, while I'm trying to give priority to my unconscious. -- 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
