[pvrusb2] Does it make sense to try to port pvrusb2 to dvb?

[Mike Isely]

On Thu, 30 Nov 2006, xavier.gnata at free.fr 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
                        |                             |