The library has started preventing a lot of interesting use cases,
like CREATE_BUFS, DMABuf, usage of TRY_FMT. As the libv4l2 is totally
inactive and not maintained, we decided to disable it. As a convenience
we added a run-time environment that let you enable it for testing.
GST_V4L2_USE_LIBV4L2=1
This of course only works if you have enabled libv4l2 at build time.
Add a couple of useful debug traces , they happened to be useful to
debug/investigate a 4K video playback issue with v4l2, so let's make these
changes more permanent.
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
https://bugzilla.gnome.org/show_bug.cgi?id=785109
First step of a larger cleanup, all function from v4l2_calls are in fact
methods on GstV4l2Object. This split makes the code really confusing.
This also remove no longer unused macros.
Before that, each m2m node would be wrapped as a single, multi-format
decoder element. As a unique name was needed, we where using the device
name, which changes between re-boots. This led to unpredictable element
names. In this patch, we generate an element per codec, using
v4l2<codec>dec name. If there is multiple decoder for the same format,
the following elements will be named v4l2<node><codec>dec.
https://bugzilla.gnome.org/show_bug.cgi?id=784908
Running `gst-validate-launcher -t validate.file.playback.change_state_intensive.vorbis_vp8_1_webm`
on odroid XU4 (s5p-mfc v4l2 driver) often leads to:
ERROR:../subprojects/gst-plugins-good/sys/v4l2/gstv4l2videodec.c:215:gst_v4l2_video_dec_stop: assertion failed: (g_atomic_int_get (&self->processing) == FALSE)
This happens when the following race happens:
- T0: Main thread
- T1: Upstream streaming thread
- T2. v4l2dec processing thread)
[The decoder is in PAUSED state]
T0. The validate scenario runs `Executing (36/40) set-state: state=null repeat=40`
T1- The decoder handles a frame
T2- A decoded frame is push downstream
T2- Downstream returns FLUSHING as it is already flushing changing state
T2- The decoder stops its processing thread and sets `->processing = FALSE`
T1- The decoder handles another frame
T1- `->process` is FALSE so the decoder restarts its streaming thread
T0- In v4l2dec-> stop the processing thread is stopped
NOTE: At this point the processing thread loop never started.
T0- assertion failed: (g_atomic_int_get (&self->processing) == FALSE)
Here I am removing the whole ->processing logic to base it all on the
GstTask state to avoid duplicating the knowledge.
https://bugzilla.gnome.org/show_bug.cgi?id=778830
If the duration of the v4l2object is GST_CLOCK_TIME_NONE, because the
sink did not specify a framerate in the caps and the driver accepts the
framerate, the decoder element uses GST_CLOCK_TIME_NONE to calculate and
set the element latency.
While this is a bug of the capture driver, the decoder element should
not use the invalid duration to calculate a latency, but print a warning
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=779466
Instead of completely getting rid of the input buffer, copy
the metadata, the flags and the timestamp into an empty buffer.
This way the decoder base class can copy that information again
to the output buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=758424
gst_v4l2_probe_caps() returns the coded size, not the visible size. Subtract
the known padding from probed caps with the coded size before using them as
filter for caps negotiation with downstream elements.
https://bugzilla.gnome.org/show_bug.cgi?id=766382
There was some miss-match in the implementation. This makes it
concistent, though functionally it worked, except the video decoder
output-io-mode getter.
Replace the sink_query with new getcaps() virtual and use the proxy
helper with the probed caps. This allow upstream element taking decision
base on what is supported downstream.
This allow skipping buffer flagged with ERROR that has no payload.
This is typical behaviour when a recovererable error occured during
capture in the driver, but that no valid data was ever written into that
buffer. This patch also translate V4L2_BUF_FLAG_ERROR into
GST_BUFFER_FLAG_CORRUPTED. Hence decoding error produce
by decoder due to missing frames will now be correctly marked. Finally,
this fixes a buffer leak when EOS is reached.
https://bugzilla.gnome.org/show_bug.cgi?id=740040
The decodeing thread returning flushing isn't an error, we should simply
try starting the task again. If it's actually flushing, it will stop again by itself.
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
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
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.
Now that we might be copying out buffer (e.g. downstream don't support video
meta bug we need it) we need to move the EOS handling inside the process
method.
Upon error, the pools might not have been allocated yet, hence we should not
try and flush them (even though we still want to make sure the processing thread
is fully stopped).
