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 [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
