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. 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
