47ca2ce499
Increasing this number fix a buffer starvation problem I'm hitting with a "v4l2src ! kmssink" pipeline. kmssink requests 2 buffer as it keeps a reference on the last rendered one. So we were allocating 3 buffers for the pipeline. Once the first 2 buffers have been pushed we ended up with: - one buffer queued in v4l2 - one being pushed - one kept as last rendered If this 3rd buffer is released after that v4l2 used the first one to capture we end up with a buffer starvation problem as no buffer is currently queued in v4l2 for capture. Fixing this by adding one extra buffer to the pipeline so when one buffer is being pushed downstream the other can already be queued to capture the next frame. We were already adding 3 buffers if downstream didn't reply to the allocation query. I reduced this number to 2 to compensate the extra buffer which is now always added. https://bugzilla.gnome.org/show_bug.cgi?id=783049
v4l2 plugins
============
The idea is a bit the same as the idea for the v4l1 plugins. We want
one generic v4l2element, and a few child objects (probably only two:
v4l2src and v4l2sink):
/-------- v4l2src
v4l2element ---=
\-------- v4l2sink
Both v4l2src and v4l2sink have a uncompressed and a compressed
recording-/playback-mode. Since this is all part of v4l2, the 'client'
of these elements, i.e. an application using v4l2src/v4l2sink, will
hardly notice this. All capsnego stuff is done inside, and the plugin
knows which formats are compressed and which are not.
Please note that the v4l1 and the v4l2 plugins are *not* compatible
concerning properties. Naming has been kept the same where possible,
but in some cases, properties had to be removed or added to make
full use of v4l2.
V4L2 API: http://linux.bytesex.org/v4l2/.
http://v4l2spec.bytesex.org/
/usr/include/linux/videodev2.h or
Kernel patches available from
http://dl.bytesex.org/patches/.
Articles:
http://lwn.net/Articles/203924/