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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/