[vlc-devel] [PATCH] add V4L2 video_output module

[Rémi Denis-Courmont]

   Hello,

On Friday 20 January 2012, Francois Cartegnie wrote:
> Le 18/01/2012 10:09, Rémi Denis-Courmont a écrit :
> > So what? Not crashing does not imply not having bugs. I could see why
> > cheap hardware with a simplistic MMU would not support writev(). I cannot
> > see why an in-memory device driver would not.
> 
> According to the fact the OS can emulate writev() with write() and v4l2
> assumes 1 Write = 1 frame, it's not surprising it is not supported by
> the V4l2 driver interface if it isn't mandatory for devices.

Meh? The point is, there are no excuses for a loopback driver not to support 
writev(). If it indeed does not support writev(), I would argue it is crap. If 
it is crap, it is no wonder that it was not merged upstream in 5 years of 
existence!

> > A kernel driver to transmit video frames between applications is a very
> > inefficient design. If you need to copy memory once more in user space,
> > it gets worse.
> > Normally, you do that with shared memory and IPC, not with kernel
> > drivers.
> 
> Although the RW method being the only mandatory one, it's only a
> fallback method. While I hardly see how we could merge scattered memory
> areas for a single write without copying, maybe we can skip that copy
> operation in the case the picture is not cropped if all lines/planes are
> contiguous. Is there any luck this would work with all formats ?
> 
> > - nobody cares because nobody uses the driver.
> 
> Chicken and egg problem. On windows, people use dedicated applications
> to do this, usually for Ustream/stickam like websites. There's many
> forks for linux and it's not easy to have it working.

Unless I missed the discussion, you did not try to push the driver upstream. 
There are two inherent problems with non-upstream drivers:
- they are not reviewed properly so often have bugs,
- the interface often gets changed before the driver is merged,
- almost nobody uses them (with the exception of NVidia GPU).

I am fine with adding code for non-standard drivers (we have some of that 
already) in general. But I do have a problem with redefining an official driver 
interface based on an unofficial driver. This is extremely likely to cause 
problems down the line.

In my opinion, a v4l2 video output has to be... a V4L2 video output, not a 
vloopback video output. If you want to make a vloopback interface, then fix the 
name and put appropriate sanity checks, I don't know what.

> > And I am opposed to deviating from the official V4L2 API in the official
> > VLC for obvious reasons. If you want to fork and redefine the semantics
> > of the V4L2 API for use with an out-of-tree driver, then you should make
> > an
> 
> V4L2 does not provide guidance for output negociation outside of "Well
> written V4L2 applications ensure they really get what they want".
> 
> Input negociation provides option for trying to negociate a user defined
> chroma. A profile just adds an optional user size. I'm not deviating or
> redefining in any way.

Maybe the loopback driver is doing this. That's the same. It might be one of 
the reason why it was not upstreamed. There may also be political and high-
level technical problems.

In fact, based on recent discussions on the DVB loopback, I believe a libv4l2 
plugin would be the most commendable manner to loop video back with the V4L2 
API. It would require libv4l2 0.9 and a lot more code though.

> I'll add my lines in top of a cloned input negociation code then. Maybe
> it will make things more clear.
> 
> Francois
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel
-- 
Rémi Denis-Courmont
http://www.remlab.info