On Thu, 30 Nov 2006, [EMAIL PROTECTED] wrote: > Woh! I have written a 3 lines question and I get pages of answers. > Thanks! > "The real solution would be to kick some sense into the applications, and > teach > them how to handle v4l2 mpeg stuff" > Well xawtv in almost dead. > Let us consider tvtime. It is just great but tvtime time do not want to > include > mpeg2 capabilities in it. Why? They said they do not want to convert a tv app > into an mpeg file player. The main problem are the asm-well-optimized filter > in > many tv apps : They will not work on mpeg pixel format. > So, IMHO, they is a real gap between v4l people and "mpeg" ones. > Maybe mpeg has nothing to do in v4l :(.
You've hit upon a key problem. Decoding mpeg data is fundementally different than dealing with V4L video frames. mpeg is a lot harder. There are a number of reasons for this: 1. The data has to be decoded. That is a tough problem, but the ffmpeg library has this covered pretty well so it's not really a showstopper (any more). 2. mpeg data is self-timed. V4L frame timing is an artifact of the V4L API. What this means is that "knowing when" to put up the next frame can be inferred by when the next frame is available from V4L. But mpeg data is just a stream of bytes whose rate of transfer varies and has nothing to do with the display rate. Thus any app displaying mpeg data has to "know" that the frame rate is "xyz" and then implement the needed high resolution timing and synchronization to display it. So there's an entire timing subsystem needed now that wasn't there for V4L. 3. mpeg data includes audio. V4L frame style video "outsources" the audio side to Alsa. Any app which plays mpeg must therefore decode the audio and marshall it back into the system's audio driver. Apps which just deal with V4L frames can ignore all that and simply assume that either the user has a loop-around cable plugged into his sound card or something else is dealing with the audio. 4. mpeg data requires audio / video synchronization. With V4L it's just "there" as an effect of the API. That is a potentially nasty problem. If the audio and video start to drift apart (which is almost certainly going to happen over time), then the app has to figure this out and stretch / expand one of the two sides to bring it all back into sync. "Kicking some sense" into V4L apps means they must all deal with the above. I think that's a pretty high barrier to overcome, especially if the app was never designed with this sort of thing in mind. TvTime is optimized for V4L; I seriously doubt it's ever going to be able to do this. (I invite TvTime developers to prove me wrong. Please!) Now with that said, this is still no excuse for any V4L-aware apps which already happen to be able to decode mpeg data. It should not be difficult for mplayer or Kaffeine or xine to do all of the above - they already do. They need to recognize that a V4L device may spit out mpeg and then just handle it like any other mpeg source. But I think tvtime is a lost cause and so will be any other currently existing V4L app that was never written with mpeg in mind. Mike Krufky's comments not withstanding, if there *is* a Linux API that works with mpeg and that a bunch of apps happen to use, then I think it stands to reason that a driver for a piece of mpeg-aware hardware should at least try to implement that API. Yes, the results may be ugly in the driver if the API isn't otherwise a clean fit, and I suppose it might even be so bad as to preclude inclusion into the kernel. I don't really know. But I think saying that "A" will never work with "B" because "B"'s needed implementation of the shearing layer "C" will be too ugly is something that shouldn't be discounted so quickly. Mike Krufky is a DVB expert. I am not. I am still learning DVB. It's entirely likely that what he is telling me about it means that the pvrusb2 driver may never have a practical DVB implementation. However that probably isn't going to be reason enough to stop me from trying. Sometimes I like tilting at windmills. Every once in a while I manage to knock one over :-) What's really stopped me from trying to-date is just a lack of time. > > But way, can you tell me the main difference between pvrusb2 device and for > instance this device : http://www.expansys.fr/p.aspx?i=127821 (DVB-T). > (France is switching to DVB-T quite quickly) > http://www.linuxtv.org/wiki/index.php/PCI_devices_DVB-T > So, there are tv card supported as dvb and not v4l2 devices. > I must been missing something. Please tell me :) I'm out of time right now to answer (need to go look at what you are referencing). Probably because I've spent too much time running on about this above :-) I'll try to follow up with a comment later. -Mike -- | Mike Isely | PGP fingerprint Spammers Die!! | | 03 54 43 4D 75 E5 CC 92 | isely @ pobox (dot) com | 71 16 01 E2 B5 F5 C1 E8 | | _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
