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

Thu Nov 30 13:14:24 CST 2006

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 :(.

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

Xavier

> 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
>
> _______________________________________________
> pvrusb2 mailing list
> pvrusb2 at isely.net
> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
>