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

[Francois Cartegnie]

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.

> 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.

> 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.

I'll add my lines in top of a cloned input negociation code then. Maybe
it will make things more clear.

Francois