[pvrusb2] PVR-USB2 and DVB-T

[Mike Isely]

On Tue, 8 Aug 2006, Michael Krufky wrote:

> leonardo wrote:
>>
>> thanks a lot for your answer, but if there is no DVB
>> support, what exactly are the DVB references in the
>> driver webpage referring to?
>>
>> from main page:
>> "No DVB support. Your author here needs to learn about
>> Linux DVB architecture first, but my gut feeling is
>> that this should be doable."

Yes, that was in the list of missing features.

>>
>> and:
>> http://www.isely.net/pvrusb2/usage.html#DVB

Yup.


>
> Mike Isely is the author in question, here.  The most meaningful piece
> of information in the DVB section of the pvrusb2 web page is the part
> that reads, "Your author here needs to learn about Linux DVB
> architecture first"  (no offense, Mike) :-P

What offense?  I'd be offending myself here :-)



>
> Anyhow, some clarification...
>
> What Mike meant by, "I have several interesting thoughts towards also
> making a DVB interface concurrently available"  , what he had in mind
> was to make the mpeg2 stream accessible via the DVB kernel API -- he did
> NOT intend on implementing DVB support for a piece of hardware that
> lacks DVB tuner capability.

My intent - and realize that this was thinking that started back around 
April 2005 - was to master the DVB API and then to see how well it might 
be possible to make this driver implement that API.

I _still_ haven't studied the DVB architecture well enough to make such a 
judgement.  In that regard, Mike Krufky here is the expert not me.  My 
only thought (back then and still now) is that the biggest thing that 
jumped out at me about DVB vs V4L is this: V4L really has its roots in 
dealing with uncompressed video frame buffers and making possible methods 
to move such data as rapidly and efficiently as possible - the reason why 
V4L has these complex hairy methods for doing I/O.  DVB really has its 
roots in dealing with simpler digital streaming video, not frame buffers. 
There are certainly many other differences (especially in how DVB 
separates out functional parts of a device and exports separate device 
abstractions for each, apparently), but in light of that primary 
difference it had occurred to me that the PVR USB2 device is closer to DVB 
than it is to V4L.  I could be wrong there (probably am wrong), but I was 
also thinking about this in the context of the pcHDTV HD-3000 tuner, which 
is an ATSC receiver.  That device's driver started life in V4L-land, but 
apparently now everyone uses a DVB based driver for it.  Certainly the 
HD-3000 is not a true DVB device, so it seemed to me that a similar stunt 
might be possible with the PVR USB2 device that we all know about here. 
Anyway, that's the thought process that led to my comments on the web 
page.  I'm not saying those conclusions are right; certainly Mike (Krufky) 
will show me the error(s) of my ways once I finally take the time to learn 
about DVB internals :-)


>
> I agree that the paragraph on the web site is misleading.  It might be a
> good idea to restructure the mpeg encoding API such that it would be
> able to use the DVB interface, but this also has many implications that
> we are not yet ready to deal with.  The largest implication is the fact
> that the analog API, (including analog MPEG encoding) is completely
> separate from the DVB API.   The truth of the matter is, this is a folly
> that happened long ago when these kernel subsystems were originally
> created.  To go back and change things now is a big task, and it will be
> quite difficult to get the other developers to agree with it.  That
> doesnt stop us from doing it, however... We just cannot expect to see
> such changes like that merged into the mainline kernel -- at least not
> quickly.
>
> Mike says on his web site that, "The internal architecture of the driver
> should make this sort of stunt possible,"  but if something like that
> should happen, IMHO, it should be done somewhere in a central core part
> of v4l, so that the other mpeg encoders could do the same.  However, I
> fear that Mike may disagree with me about this, largely because the
> pvrusb2 driver is already structured in such a way that adding
> interfaces like this would be quite easy to do, without having to mess
> in core v4l stuff.  I'm sure that Mike will have a lot to say on this
> topic when he gets back.

Yup.  Well here goes...

The internal architecture of the pvrusb2 driver was something I put 
together before I got my fingers into the V4L community directly. 
Probably if I had gotten more directly involved in V4L development 
earlier, things might be different.  However at the time (again we're 
talking about April 2005), I was looking at a way to put this driver 
together such that it could be easily made to work in DVB in addition to 
V4L.  That meant that all responsibility for isolation and layering had to 
happen in the driver itself, not in the V4L core - since at the time I was 
not involved in the V4L core at all.

The situation today is different of course.  And there is this interesting 
situation right now where we have two considerably different architectures 
- V4L and DVB which in an ideal world should probably be one architecture. 
And I don't mean that in a way to slight either DVB or V4L.  The simple 
fact is that each architecture started with a different set of goals 
(digital video streaming versus a common API for 'dumb' video capture 
boards) and over time I think both are inevitably expanding to include 
functions that are covered by the other.  Witness V4L slowly bringing in 
functionality to handle mpeg2 streaming - and unfortunately in a manner 
independant of DVB.

The current situation also leads to crazy setups with "hybrid" devices, 
i.e. tuners that have both analog and digital video sides like this Sasem 
device Mike is talking about.  Right now we can make the digital side of 
the device (mostly) work with DVB and the analog side (mostly) work with 
V4L.  But that's nuts.  An application should not have to deal with 2 
mutually incompatible drivers to fully use a device.  I mean heck, with 
the Sasem device it's all mpeg2 coming out the end anyway so why should an 
app have to do something different to get that stream depending on the 
video source?


>
> Of course, Mike and I have been throwing some ideas around, such that
> pvrusb2 itself may end up being the core of a larger driver, in which
> case this idea will gradually become more feasable.

Anyway, I'm rambling here.  The ideas we've been throwing around revolve 
around the sorts of things I'm talking about above.  As to whether the 
result is one driver that implements both DVB and V4L seamlessly or a DVB 
driver that shoehorns the analog side or a V4L driver that hacks on the 
digital side, I don't think anyone knows.  Clearly the best outcome in the 
long run is a single driver that doesn't have to hack or shoehorn anything 
- but that may cause more upset in the cores of the two architectures...

Probably one thing Mike (Krufky) and I have disagreed on has not been the 
outcome but perhaps how to get there.  There's a number of "interesting" 
things going on in the pvrusb2 driver that Mike (and others) would like to 
see in the V4L core.  (Well at least that's my impression.)  Some of the 
feedback I've gotten has been to the effect of why did I implement it 
inside of pvrusb2 when it should be in V4L.  My response is basically that 
I can hack on the pvrusb2 driver and iterate experiments there a lot 
faster.  The alternative, working directly in V4L, seems to be one of a 
lot of e-mail debate back and forth before even the first experiment is 
tried.  I don't think like that.  I much prefer to push stuff into code 
and see what happens.  If the result sucks then it dies.  If the result 
looks good, then we can talk about putting it in a more generic place. 
The counter argument to this sort of strategy is probably one of a lot of 
extra work moving code around and angst among V4L people about there being 
too much complexity in the pvrusb2 driver because of it.


>
> On the bright side, I mentioned to you earlier a company called, "Sasem"
> ..  They have given Mike and I some samples of their hybrid analog mpeg
> encoder / ATSC receiver device.  This particular device ALREADY works in
> analog mpeg encoder mode with the pvrusb2 driver (except the pvrusb2
> driver needs some massaging in order to get it to play nice with the
> Cirrus Logic CS53L32A audio ADC) , and I also do have a (50% working)
> driver written to handle the ATSC (HDTV in USA) side.  The biggest
> problem right now is that we have two separate drivers to handle the
> separate functionality. Mike and I have plans to work this out
> (hopefully) within the next few months.  Unfortunately, we are both very
> busy with our full-time jobs.....  but we will get there sooner or later.
>
> This email turned into a long ramble... I hope that I answered your
> question sufficiently, along with providing a lot more info that you may
> (or may not) actually be interested in.
>
> If you have any more questions, I'd be happy to try to answer them.
>
> Cheers,
>
> Michael Krufky

Mike:

I'm back from vacation.  You should see me lurking around IRC once 
again...

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