From time to time, when the image_pool list has more then 1 element
and I suppose at start, all but 1 pooled ximage are leaked. This is
due to broken algorithm in gst_ximagesink_src_ximage_get(). There was
also a risk of use after free for the case where the ximage size has
changed.
https://bugzilla.gnome.org/show_bug.cgi?id=728502
gstv4l2bufferpool.c:608:18: error: implicit conversion from enumeration type
'enum _GstV4l2BufferPoolAcquireFlags' to different enumeration type
'GstBufferPoolAcquireFlags' [-Werror,-Wenum-conversion]
params.flags = GST_V4L2_POOL_ACQUIRE_FLAG_RESURECT;
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We need to handle the case where a flush occure while the streaming
thread is being brought up. In this case, the flushing state of the poll
object is cleared. To solve this, we simply set the capture poll to flushing
again, this way we know the thread will exit. The decoder streamlock
is used to synchronize with handle frame.
M2M devices were sharing the same properties as src and sink. Most of
these made no sense. This patch reduces the number of propeties and
makes io-mode clearer by having capture-io-mode and output-io-mode. This
also accidently fixed a bug in gstv4l2transform io-mode code, where the
capture io-mode could not be set.
https://bugzilla.gnome.org/show_bug.cgi?id=729591
If the driver need more buffers than requested by the config,
update the pool min/max values. The minimum value for the pool
could be provided either by the driver or by the pool. This is
best effort for drivers that don't support
CID V4L2_CID_MIN_BUFFERS_FOR_CAPTURE.
https://bugzilla.gnome.org/show_bug.cgi?id=730200
This allow calling start streaming later for capture device. Currently it breaks
in dmabuf-import because downstream is holding a buffer that will only be
released after stream-start.
https://bugzilla.gnome.org/show_bug.cgi?id=730207
When extrapolating the offset, we need to use the extrapolate
stride rather then the base stride. This should fix support for format
with more then two planes (I420, Y42B, etc).
When doing frame operation, we need to use the default VideoInfo
and let the frame API read the video meta in order to get the stride
and offset right. Currently we where using the specialized VideoInfo
which reflects what the HW is setup to.
Simplify framerate field if possible, so we don't end up with
e.g. framerate = (fraction) { 30/1 }. Maybe the helper function
should be moved to core, but we can do this later.
This moves away from copying information and store everything inside
the GstVideoInfo structure. The alignement exposed by v4l2 api
is now handled using proper offset.
Return a buffer from an otherpool has unwanted side effects that lead to leaks and
prevents deactivating the pool. Instead, we change the _process() API so it can
replace the internal buffer with the buffer from the downstream pool. This implied
moving from _fill() to _create() method in the src.
Buffer refcounting is a bit hard, because of the duality between CAPTURE and
OUTPUT mode. In the long term, we should consider having two seperate pool
instead of this mess. At least state should be better kept this way.
All enum that has REQBUFS and CREATE_BUFS where missing S, which was
confusing since they are supposed to match with associcated ioctl name. This
also fixes the yet unused CAN_REQUEST flag check.
