Re: [RFC] V4L2 codecs in user space

[Damian Hobson-Garcia <dhobsong@igel.co.jp>]

Hello again,

On 2015-06-02 10:40 AM, Damian Hobson-Garcia wrote:
> Hello All,
> 
> I would like to ask for some comments about a plan to use user space
> video codecs through the V4L interface.  I am thinking of a situation
> similar to the one described on the linuxtv.org wiki at
> http://www.linuxtv.org/wiki/index.php/V4L2_Userspace_Library
> 
> The basic premise is to use a FUSE-like driver to connect the standard
> V4L2 api to a user space daemon that will work as an mem-to-mem driver
> for decoding/encoding, compression/decompression and the like.  This
> allows for codecs that are either partially or wholly implemented in
> user space to be exposed through the standard kernel interface.
> 
> Before I dive in to implementing this I was hoping to get some comments
> regarding the following:
> 
> 1. I haven't been able to find any implementation of the design
> described in the wiki page.  Would anyone know if I have missed it? 
> Does this exist somewhere, even in part? It seems like that might be a
> good place to start if possible.
> 
> 2. I think that this could be implemented as either an extension to FUSE
> (like CUSE) or as a V4L2 device driver (that forwards requests through
> the FUSE API).  I think that the V4L2  device driver would be
> sufficient, but would the fact that there is no specific hardware tied
> to it be an issue?  Should it instead be presented as a more generic
> device?
> 
> 3. And of course anything else that comes to mind.

I've been advised that implementing kernel APIs is userspace is probably
not the most linux-friendly way to go about things and would most likely
not be accepted into the kernel.  I can see the logic of
that statement, but I was wondering if I could confirm that here. Is
this type of design a bad idea?

Also, if this method is not recommended, should there be a 1-2 line
disclaimer on the "V4L2_Userspace_Library" wiki page that mentions this?

Thank you,
Damian