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

[Michael Krufky]

Mike Isely wrote:
> 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.

I cant address every point, due to time constraints, however:

DVB is a television broadcast standard.

A pvr device is using analog television broadcasts and encoding an mpeg stream
from it.

A DVB device is nothing but a network connection.

---

About whether DVB can handle the mpeg stream of a pvr device -- that's the easy part.

A DVB device will never be able to provide any type of interface to handle
what we know as "v4l controls" ... simply because there is nothing to be
controlled in a dvb device, except for the frequency and mux.

You will still need the v4l subsystem in order to handle the broadcast decoder.

---

If somebody were to create a "dvb" interface for a pvr-style device, it would
entail looping back the encoder output to the dvr device, while fooling the
software demuxer to leave the stream alone.  There would have to be a "dummy"
frontend present, in order to satisfy the DVB kernel subsystem...

It will require a LOT of explanation to get my point across.... but what I am
trying to say is that in order to make a pvr device use the DVB api, it would
require a ton of dummy code, responding to the subsystem API to effectively
provide zero functionality.

Your main point I see is here:

> Oh look - it's mpeg2 both times.  Isn't that nice?

Yes, mpeg2 is the end result in both cases, but how do we arrive at mpeg2?  That
is the functional difference.  For an analog encoder, it is 100% through the use
of handling analog video in one way or another.  For DVB it is just a matter of
receiving the stream over a network connection.

---

You presented the problem about hybrid devices ... again, its too much to explain
here, but the tuner handling itself is not the problem -- that's the easy part.

This isnt necessary, but I wrote a tuner-wrapper module.  It is a proper DVB tuner
module that forwards v4l api commands to tuner.ko through the use of
_i2c_call_clients.  I repeat -- this is absolutely not necessary in the least,
but it does help to illustrate to how how little of a problem the tuner itself would be.

http://linuxtv.org/~mkrufky/pending/tuner-wrapper/tuner-wrapper.patch

 linux/drivers/media/dvb/frontends/Kconfig         |    9 +
 linux/drivers/media/dvb/frontends/Makefile        |    1 
 linux/drivers/media/dvb/frontends/tuner-wrapper.c |  118 ++++++++++++++++++++++
 linux/drivers/media/dvb/frontends/tuner-wrapper.h |   39 +++++++
 4 files changed, 167 insertions(+)

---

The problem with hybrid devices, is the input switching on the bus of that device.
In the case that you are thinking of, the pvrusb2-style device with the ATSC demod,
the handling of this is extremely easy, provided that a single driver handles
both interfaces.  However, in our case, you have a mature driver that handles
the analog mpeg encoding, and I have a mature driver (except for that power-cycle bug)
that handles the ATSC demuxing.

In our case, one of us will have to concede and merge functionality into the other
driver.  Until then, we can run our separate drivers only one at a time. (yuck)

Considering the changes that we know are coming to the world of analog mpeg
encoders with a usb2 interface, it makes the most sense for ME to concede my 
driver, and merge the functionality into yours... (yes, i've flip-flopped on this
issue many times already, but given the circumstances.........)

---

bottom line:  I think the real reason why you like the idea of converting the pvrusb2
driver to use the DVB api would be the fact that it would allow you to ditch the
problems relating the the poor design of the v4l api itself.

The real solution would be to kick some sense into the applications, and teach them
how to handle v4l2 mpeg stuff.

A temporary solution:  write a dvb-dummy driver, tell it to use the dummy frontend,
do not attempt any ts demuxing, and loopback the ps to the dvr device.  convert all
frontend dvb api commands to relate the command to the tuner.ko module through the use
of a wrapper.

heck - i might even attempt the above for the fun of it, since I've already written the
tuner-wrapper.

Gee, look at the time!  I might have addressed all points, after all 8-)

ttyl,

Michael Krufky