This is to support Amlogic CODEC driver which does not provide a full
list of formats when the driver is initially opened. GStreamer does
not strictly need this full list initially, but only later, in order
to negotiate with downstream if multiple format can be selected.
With this change, we will no longer probe twice the device, since the
probed list can be directly used for negotation.
Add a debug message right before waiting for the driver.
This is useful in order to debug drivers without a properly
implemented decoder or encoder stop command.
This allow forcing going through the transform driver even if there
isn't an conversion happening. This is usedful when the m2m driver can
be used to adapt the type of memory between two drivers.
This method will check if a buffer, base on it's video meta,
can be imported. It will also try and adapt the request stride
in case this is the only that miss-match.
https://bugzilla.gnome.org/show_bug.cgi?id=583890
The preparation code imports the buffer, doing bunch of
validation. Only queue the buffer in the driver if the
importation worked. This way we don't rely on the driver
to validate.
https://bugzilla.gnome.org/show_bug.cgi?id=583890
This change has no effect. We will need to acquire a buffer from the
pool later in order to validate / adapt with the video alignment for
the downstream buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=583890
Always initially use try_format(), delaying set_format() to when the
allocation is being negotiated. This avoid having two code paths, and
will be help adding support for properly importing buffers of specific
strides and offsets.
https://bugzilla.gnome.org/show_bug.cgi?id=583890
The desired colorimetry is logged with all parameters (colorpsace,
range, matrix, and transfer function), but of the values actually
set by the driver, only colorspace is logged. Complete the debug
log message to display all colorimetry parameters:
Desired colorspace is 8:1:1:1
Got format of 640x480, format YU12, nb planes 1, colorspace 8
->
Desired colorspace is 8:1:1:1
Got format of 640x480, format YU12, nb planes 1, colorspace 8:0:0:0
https://bugzilla.gnome.org/show_bug.cgi?id=796940
gstjpegdec sets 1:4:0:0 colorimetry (full range BT.601 YCbCr encoding
with unknown primaries and unknown transfer function). This currently
gets translated to bt601 or bt709 depending on resolution.
Both cases result in a negotiation failure:
ERROR: from element /GstPipeline:pipeline0/v4l2video0convert:v4l2video0convert0: Device '/dev/video0' does not support 1:4:0:0 colorimetry
Improve the guessing game by selecting JPEG colorimetry (JPEG colorspace
with sRGB transfer function) under these specific conditions, and loosen
the matching so that 1:4:0:0 input gets accepted if the device is
actually configured to 1:4:7:1 (V4L2_PIX_FMT_JPEG default).
https://bugzilla.gnome.org/show_bug.cgi?id=796940
Setting the priv field to a magic value stops V4L2 core from zeroing
the extended colorimetry fields quantization, ycbcr_enc, and xfer_func
for non-mplane queues.
https://bugzilla.gnome.org/show_bug.cgi?id=796940
The input from an v4l2 device that was used the first time was
remembered for next times, and set again always the pipeline is
set to READY state. This was making that users wasn't able to
select a different input without having to create a new pipeline.
This patch makes that v4l2src element forget previous used input
when going to NULL state, so it will check again for the current
selected input when going again to READY state. Users can change
to NULL state, select a new input with a VIDIOC_S_INPUT ioctl
and change to PLAYING again.
https://bugzilla.gnome.org/show_bug.cgi?id=796908
When the pool is started, we allocate and release buffer, expecting
the pool release-buffer handler to queue them. Though, as we rely
on release function, there is no direct way to detect that this
process didn't work.
To check this, validate that the number of queued buffer is the same
as the number of allocated buffers. This allow returning an error
when buffer importation was refused by the driver.
https://bugzilla.gnome.org/show_bug.cgi?id=583890
This will avoid sending EOS on v4l2src when a driver sends an empty
buffers. This case would be a bug in the driver, but yet the camera
should keep running.
This also removes the check for corrupted buffers, as this check is
already done later.
https://bugzilla.gnome.org/show_bug.cgi?id=794842
We were calling gst_v4l2_is_buffer_valid() before and inside
gst_v4l2_buffer_pool_qbuf() as we needed to access the group. The second
check failed since the writability of the buffer get inherited from the
GstMemory, which lead to pipeline failure. As we cannot avoid the extra
ref, it would be racy otherwise, just pass the group to _dbuf() so it
does not have to call gst_v4l2_is_buffer_valid() again.
https://bugzilla.gnome.org/show_bug.cgi?id=796692
Some camera firmware crash is TRY_FMT is called during streaming. As a
side effect. This try and detect that the same format as currently
running is about to be tried, and skip renegotiation.
https://bugzilla.gnome.org/show_bug.cgi?id=796789
In some cases, set_format() may get called twice before the output
format is set. Running an allocation query in this case is both not
needed and will cause assertion due tot he NULL caps.
The first converter to be found will now gain the name v4l2convert.
Other converters will be named after the m2m dev node end point they are
attached to.
https://bugzilla.gnome.org/show_bug.cgi?id=784958
When the decoder get linked further, it will receive a renegotiation
event from downstream. This case is not supported and should be ignored.
This fixes issues when this encoder is used inside an GstRtspServer
pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=796525
This fixes patch dd1c5aed65 which
pretended to always set colorimetry but the patch was incomplete.
This is again best effort considering the spec says that for CAPTURE
you may only read this value.
gst_v4l2_buffer_pool_flush() executes streamoff for the output, but
streamoff->streamon for the capture of the decoder.
gst_v4l2_buffer_pool_streamon() on capture assumes that is able to
resurrect the buffers from the pool, but acquiring buffers fails if the
buffer pool is still flushing.
The decoder needs to stop flushing the pools before calling
gst_v4l2_buffer_pool_flush() to restart the v4l2 device. Otherwise
starting the decoding thread might fail, because there are no buffers in
the capture pool.
This fixes a regression that was introduced in 97985a335c
("v4l2videodec: Add dynamic resolution change support").
https://bugzilla.gnome.org/show_bug.cgi?id=796681
The S_CROP call doesn't work on mem2mem output queues. Use the
S_SELECTION call to set the crop rectangle and only fall back to
S_CROP for ancient kernels.
This will allow v4l2videoenc to set the coded size on the output
queue via S_FMT and then set the visible size via the crop rectangle,
as required by the V4L2 codec API.
https://bugzilla.gnome.org/show_bug.cgi?id=796672
Some drivers need output buffers set before capture buffers.
CODA cannot set output format if capture is streaming.
Exynos MFC fails on output STREAMON if capture is already streaming.
This patch delays capture activation until output is configured and
streaming
https://bugzilla.gnome.org/show_bug.cgi?id=796693
Drop truncated frames regardless if they have the ERROR flag or not.
Truncated frame causes video frame map failure in many elements
including cluttersink, glupload etc.
In this patch we use a non-blocking poll in order to return all input
buffers (buffers from v4l2-output queue). This prevent holding too long
on upstreaming buffer in importing.
https://bugzilla.gnome.org/show_bug.cgi?id=794904
gst_v4l2_dup() will now take care of setting
v4l2capture->no_initial_format and keep_aspect instead of doing it
manually.
Fix a typo as keep_aspect was set twice on v4l2output but never on
v4l2capture.
https://bugzilla.gnome.org/show_bug.cgi?id=795028
libv4l2 does not prevent exporting DMABuf even when emulated formats are
in use. As a side effect, userspace ends up with buffers of the original
formats which will cause issues.
https://bugzilla.gnome.org/show_bug.cgi?id=795097
