Add different transport methods to the bufferpool (MMAP and READ/WRITE)
Do more parsing of the bufferpool config.
Start and stop streaming based on the bufferpool state.
Make separate methods for getting a buffer from the pool and filling it with
data. This allows us to fill buffers from other pools too. Either use copy or
read to fill up the target buffers.
Add property to force a transfer mode in v4l2src.
Increase default number of buffers to 4.
Negotiate bufferpool and its properties in v4l2src.
When we have all buffers queued for playback and we need a new empty buffer,
dequeue one and return it.
Set the right size for sink buffers.
Improve counting of queued buffers.
Extend from GstBufferPool.
Handle the lifetime of the pool buffers correctly with the start/stop vmethods.
Map acquire and release directly to QBUF and DQBUF. We still expose an explicit
qbuf for the v4l2sink for now.
We want to keep the default strides in the videoinfo. Keep the stride of the
video frames separate so that we can use both to copy a video frame and do
correct stride conversion.
Keep track of the currently configured format and setting in the
v4l2object.
Pass the v4l2object to the bufferpool constructor so that the bufferpool can
know everything about the currently configured settings. This also allows us
to remove some awkward code.
Various cleanups, avoids useless casts, move error handling outside of the main
code flow.
Negotiate to a resonable resolution instead of the max resolution.
Older kernels don't have these, and there's no easy way to check for the
existance of enums that doesn't involve a configure check, so just define
these if the V4L2_CAP_VIDEO_OUTPUT_OVERLAY define is not there, which was
added in the same commit as the TB/BT enum. Fixes compilation on CentOS 5.
https://bugzilla.gnome.org/show_bug.cgi?id=639339
The size of the buffer would be zero'd out in gst_v4l2_buffer_finalize()
after the buffer is qbuf'd or pushed onto the queue of available buffers..
leaving a race condition where the thread waiting for the buffer could awake
and set back a valid size before the finalizing thread zeros out the length.
This would result that the newly allocated buffer has length of zero.
We'd prefer to throttle the decoder if we run out of buffers, to keep a bound
on memory usage. Also, for OMAP4 it is a requirement of the decoder to not
alternate between memory alloced by the display driver and malloc'd userspace
memory.
note: this really only affects v4l2sink since gst_v4l2_buffer_pool_get() is
only called once per buffer in the v4l2src case (in
gst_v4l2src_buffer_pool_activate())
It seems to cause strange occasional high latencies (almost 200ms) when dequeuing buffers from _buffer_alloc(). It is simpler and seems to work much better to dqbuf from the same thread that is queuing the next buffer.
This also does the following changes:
(1) pull the bufferpool code out into gstv4l2bufferpool.c, and make a
bit more generic so it can be used both for v4l2src and v4l2sink
(2) move some of the device probing/configuration/caps stuff into
gstv4l2object.c so it does not have to be duplicated between
v4l2src and v4l2sink
Fixes bug #590280.
