Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver

[Thierry Merle <thierry.merle@free.fr>]

Mauro Carvalho Chehab a écrit :
>   
>   
>>> Hi Mauro and Markus,
>>> Just to summ up what I understood we need:
>>>
>>> What do we need in userspace, only for v4l (dvb is not concerned):
>>> - colorspace translations
>>> - filters that be done in hardware if the selected hardware can, 
>>> otherwise software plugin
>>> - decompression algorithm like stk11xx or usbvision (the decompression 
>>> algorithm is in kernelspace since it is of linear complexity but shall 
>>> be moved to userspace)
>>>       
>
> Yes. The first focus, IMO, should be the last one.
>
>   

OK, so we must open the V4L2 API to add a custom pixel format.
While brainstorming, I thought it would be funny to create userspace 
drivers like FUSE based projects do.
Applications would see nothing but a new device driver to access, all 
decompression algorithm would be in userspace.
The path from the application to the v4l2 kernel driver:
[Application]<->[/mnt/video0 (created by FUSE-like userspace 
lib)]<->[/dev/video0 (created by kernel v4l2 driver)]
There are limitations that I don't know, but this would be transparent 
for the applications.

>>> Using pwlib will not mean that application developers will use pwlib 
>>> to decode v4l driver outputs.
>>> C bindings are much more popular than C++ bindings and do not prevent 
>>> object oriented design.
>>>       
>
> IMO, we should implement very simple and efficient C subroutines.
>
>   
>>> Application developers implement their own codecs.
>>>       
>
> They can do it if they want. However, if we have a very consistent and
> easy to use subroutines for those weird decompress stuff, it is likely
> that they will use it.
>
>   
>>> As an example, every application do deinterlacing internally or not...
>>> Application developers will probably not use pwlib v4l extensions 
>>> because they will prefer to write adapted codecs for their framework.
>>>       
>
> I think we shouldn't deal with deinterlacing. the API should be as
> simple as possible, focusing on implementing some stuff highly linked
> with the hardware (like specific decompression stuff, proprietary
> colospace conversions, etc).
>   
>>> Much more important for me is to see the actual specification of the 
>>> needed v4l extensions points, with advice/participation of 
>>> application/codec developers.
>>>       
>> As an example, we could empacket frames with a header containing 
>> audio/video format as it is done for MPEG streams.
>> Is it possible without breaking the current ABI?
>>     
>
> Yes, it is possible. In fact, some devices currently work by generating
> a common audio and video stream. The driver may just send the packet
> as-is, leaving to the userspace API the function to de-merge and
> synchronize audio and video.
>   
So we have a userspace lib that will demux/uncompress device driver output.
This lib will know each device driver particularities to know how to 
demux/uncompress in a a/v format that will be understood by the application.
>   
>> Do application developers would cope with that?
>>     
>
> Maybe.
>  
> Cheers,
> Mauro
>
>   
Thanks
Thierry