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

[Mike Isely]

On Wed, 29 Nov 2006, Michael Krufky wrote:

> xavier.gnata at free.fr wrote:
> > 
> > Hi,
> > 
> > Has there is no good *small* TV application able to read mpeg2 V4L2 I would like
> > to know if it would make sense to try to port the driver to dvb.
> > Kaffeine looks so nice as a dvb end application....
> > Any comments?
> 
> That would be like programming an apple-picking robot to harvest oranges 
> from an apple tree.
> 
> DVB is a lot more than just an mpeg stream -- it is multiple mpeg streams 
> muxed into a single transport stream.

Yes, DVB handles multiple mpeg streams.  But an mpeg stream that is just "one" 
stream is by definition just a subset of the multiple case.  So I don't see 
that as being a showstopper.  Read on...


> 
> Kaffeine could work with the v4l2 mpeg encoding API, so there is no reason 
> why you can't still use it.

It could, but does it?  The last time I tried Kaffeine (admittedly many months 
ago), it was useless for V4L devices, at least those that didn't happen to 
work as dumb frame buffer devices.

There is a general perception that V4L == "dumb framebuffer device" and so any 
such app written this way becomes useless when the V4L device in question 
really spits out mpeg2.  In several cases this is really a crying shame too, 
because the app happens to already have mpeg2 decoding capability but fails to 
bring that to bear on any V4L device.  It just "goes dumb" and then fails when 
it unexpectedly can't stream uncompressed frames from the device.  This is 
definitely true of mplayer (which is why you can't run mplayer in "v4l mode" 
on a pvrusb2 device), it's true of Kaffeine and also xine.  The only V4L apps 
I have come across that _natively_ works with ivtv-style V4L devices (such as 
the pvrusb2) appear to be xawtv and mythtv.  For everything else that I've 
tried, you're limited to running the app as if it were playing a mpeg2 regular 
file.  And now xawtv is dying of neglect.  Granted, mythtv is the 6000 pound 
gorilla of the V4L world, but still this is not a bright future for V4L 
devices which spit out mpeg2 data.

Solving this requires one of two things.  Either more V4L apps should start 
grok'ing mpeg2 data natively as part of the V4L transport, or such devices 
need to move towards DVB.  Of those two possibilities I can only control the 
second one.  I am not about to go rewriting 5 different V4L apps.  Maybe there 
needs to be change in attitude here.  Maybe there already is and I haven't 
heard about it.  But from where I'm sitting things are much more promising if 
the pvrusb2 driver had a DVB interface.

I am still not nearly enough of an expert on DVB yet to know for sure, but I 
have been steadily (though slowly) coming up to speed on the DVB architecture.  
For the pvrusb2 driver to operate there, it would not be a perfect fit, but I 
*do* think it is doable.  Handling the mpeg2 stream I think would not be a 
problem.

The issue involves controlling aspects of the driver which (AFAIK) have no 
meaning in DVB - however until recently those aspects had no real meaning in 
V4L either.  I'm talking about all the knobs and switches one can twiddle that 
influence the mpeg encoding process.  We've gotten away with this in V4L over 
time because V4L has a nice mechanism for self-identifying "private" controls 
(which the V4L maintainer seems to actively discourage people from using).  
Recently V4L has added an mpeg encoding API that covers pretty much everything 
that was a private control previously.  The pvrusb2 driver implements that 
API, and of course the whole thing is visible through sysfs as well.  So this 
really hasn't been a problem on the V4L side, but for DVB it could be.

The way I see it, any DVB interface for the pvrusb2 driver simply would not 
have those encoding controls visible through DVB.  However they could still be 
visible in sysfs, and I also don't see (yet) why the V4L side could not also 
still work.  So the lack of those controls in DVB I don't consider to be a 
showstopper (but still certainly a pain).  On the other hand, having the 
driver work as a DVB device does suddenly open the doors to a lot of other 
video apps out there, so I think this is important enough to try to do.

Another thing which continues to make me think seriously about this has to do 
with hybrid devices.  There is at least one TV device out there that is both 
ATSC and NTSC, where the NTSC side has a hardware mpeg2 encoder.  With the 
current driver landscape, the ATSC side is a DVB device while the NTSC side 
ends up being a V4L device.  That's just plain silly.  It's also difficult to 
get right because the two sides share the same RF section and so you're stuck 
either running only one driver at a time or the two drivers somehow have to 
coordinate their use of the shared tuner.  This sort of idiotic thing is a big 
burden on any app (because now it _must_ use two completely different APIs AND 
know that it must treat them mutually exclusively) - and we have no business 
putting that sort of burden on any app.  It's just plain stupid.  I think the 
"right" answer has to be that the device must "look" like a single device with 
only a single driver API needed for operation (sure it can implement multiple 
APIs but the app only needs to ever choose one), and that the driver takes 
care of the details of which side to operate based on the tuning requests from 
the app.  If the app tunes an analog station, then the NTSC (or PAL or 
whatever) side is used and the app gets an mpeg2 stream.  If the app tunes a 
digital station, then the ATSC side is used and the app gets, well, an mpeg2 
stream.  Oh look - it's mpeg2 both times.  Isn't that nice?

Yes, I know I've left out a lot of detail here.  For example for digital we're 
really dealing with mpeg-ts while for analog it's probably mpeg-ps.  And of 
course this ideal only makes sense if the analog side has a hardware encoder 
(or we invent a way to loop software encoding from user space back through a 
kernel driver).  But I think the overall concept is still valid.

Unfortunately I've had zero time to pursue that grand vision :-(

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