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

[Rémi Denis-Courmont]

On Tue, 17 Jan 2012 21:20:12 +0100, Francois Cartegnie <fcvlcdev at free.fr>
wrote:
> Le 17/01/2012 21:06, Rémi Denis-Courmont a écrit :
>> That driver is non-standard, and it seems buggy. As far as I know the
>> linux-media guys, it is probably never going to get merged. V4L2 video
>> output is meant to drive, well... video outputs. The analog TV out on
>> some OMAP board is an example.
> 
> The old v4l loopback was buggy. The v4l2 looks really stable for me.

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

In any case, there is something inherently fishy if this driver could not
be merged in the kernel as yet. Possibly some of:
- the driver is not in good shape,
- a libv4l plugin should be used rather than an in-kernel driver,
- nobody cares because nobody uses the driver.

> We just have few lines to deal with it, and that will easily bring
> features to users.

It is much more than a few lines if it requires custom profile code
instead of the correct driver-driven feature negotiation.

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
out-of-tree plugin. The official VLC plugin for V4L2 video output ought to
target the official V4L2 semantics and supported kernel drivers.

What would you think if you bought a new "car" from a car dealer, and then
you found out that the "car" can only be used on racing tracks, but not
normal roads?

-- 
Rémi Denis-Courmont
http://www.remlab.net/