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