[linux-dvb] Re: Adding V4L interface to budget cards

[Holger Waechtler <holger@convergence.de>]

Ralph Metzler wrote:
> Rene Bartsch writes:
>  > after reading documentation of new FFMPEG 0.4.6 I got the idea to add a
>  > libavfomat-based V4L-device to the DVB-driver, which decodes TS to standard
>  > YUV (or whatever is used on the V4L-interface).
>  > 
>  > This would allow programs like XawTV to watch TV without having a own
>  > MPEG-TS decoder. Standard TV-software could handle the DVBs like a analogue
>  > TV-card (except tuning-parameters, of course).
>  > 
>  > Comments?
> 
> Software decoding should not be put into the kernel.
> Other drivers (USB webcam) had simple color conversions thrown out
> when they were integrated into the kernel. They also had the
> conversion in the driver to make it easier for applications which
> could only handle certain color formats. I think the outcome of the
> discussion on the V4L list was that a standard user library should
> handle this. 
> 
> You could also use vloopback to do the decoding in userspace but still
> have a V4L device with the decoded result.

The problem is not the v4l interface, this can get faked easily by a 
userspace library API.

Kernel space codec libraries get interesting when you start to replace 
the so called firmware libraries or 'BIOS'es by an own implementation. 
Those are basically a 'ffmpeg with some hardware acceleration hooks' 
running in kernel space.

When your implementation is getting distributed on several parts of the 
processor and it's coprocessor(s), maybe one or two onchip DSPs and/or a 
DCT acceleration units you will get happy when you have a unified codec 
infrastructure in the kernel. Take a quick look on the Texas Instruments 
OMAP datasheet to get an impression how todays media processors work. 
The datasheet is available on http://dspvillage.ti.com/.

Another advantage is DivX support, most today's MPEG processors only do 
DCT/iDCT, coefficient quantisation and pixel interpolation in hardware, 
this would be sufficient for many other video codecs beside MPEG too.

so after all: There are some pretty strong reasons for a kernel space 
codec infrastructure and ffmpeg is a pretty good starting point but it 
will get pretty hard to get it accepted by the kernel gods.

Maybe at the end we will stay stuck with the proprietary firmware 
libraries which do essentially the same, but they are 'politically more 
accepted', just because there is much more black voodoo around them and 
you can't get rid of them so fast...

Holger



-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.