If xoverlay is available, v4l2sink should create a window for the overlay to
display in.
The window automatically tries to make itself as large as possible.
This works well on a small screen, but perhaps should first attempt to use
the size of the video that is played (no scaling).
Special case check for sub-buffers: In certain cases, places like
GstBaseTransform, which might check that the buffer is writable before copying
metadata, timestamp, and such, will find that the buffer has more than one
reference to it. In these cases, they will create a sub-buffer with an offset=0
and length equal to the original buffer size.
This could happen in two scenarios: (1) a tee in the pipeline, and (2) because
the refcnt is incremented in gst_mini_object_free() before the finalize function
is called, and decremented after it returns.. but returning this buffer to the
buffer pool in the finalize function, could wake up a thread blocked in
_buffer_alloc() which could run and get a buffer w/ refcnt==2 before the thread
originally unref'ing the buffer returns from finalize function and decrements
the refcnt back to 1!
This is related to issue #545501
When v4l2sink goes to PAUSED->READY it only stops streaming, so the state
should be set to STATE_PENDING_STREAMON in case the element transitions
back to PLAYING.
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.
Most v4l2 drivers will get upset when you queue the same buffer twice in a
row without first dequeueing it.
Rendering of pre-roll buffers can be re-introduced later, but will require
tracking the state of the buffer, and avoiding to re-QBUF if the buffer has
already been passed to the driver.
When the decoder is using pad_alloc(), v4l2sink would behave badly if
the number of buffers ('queue-size' property) was not high enough to
account for all the buffers needed by the decoder, and other elements
(such as queues) between the decoder and v4l2sink. This patch
slightly increases the default number of buffers, and changes v4l2sink
to drop frames rather than return an error in case the number of
buffers is not high enough.
it's perfectly ok for a video output device to not have overlay capabilities.
this patch removes the need to get/set the overlay parameters if the user
does not explicitely request one of the overlay properties
In the case we change the State from READY_TO_NULL the buffers in the pool
still hold an open dup file descriptor to the device, therefore the device
release function will not be called and the device will probably answer with
-EBUSY when we reopen it in the next NULL_TO_READY transition.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
See bug #622500 and #612244.
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.
