Commit 1f31715c98 ("v4l2videodec: use visible size, not coded size,
for downstream negotiation filter") added support for removing the
padding obtained as the difference between width/height from G_FMT and
visible width/height from G_SELECTION from the probed caps obtained
via TRY_FMT.
This patch fixes the padding removal for drivers that only round up
height, but not width, to the padded frame size. This might happen
because horizontal padding can be handled by line stride (bytesperline),
but there is no such thing as plane stride in the V4L2 API for
single-buffer planar formats.
https://bugzilla.gnome.org/show_bug.cgi?id=791271
In MPLANE mode, the driver may set data_offset, which represent some
padding at the start of the buffer used internally. This portion of the
data need to be skipped, though it is included in bytesused.
This patch removes frame size sanity check as the method used will no
longer work. This check was simply there to help detect broken kernel
drivers. It would be re-implement by estimating the plane size, which is
not totally trivial and may be too much work for a simple debug check.
https://bugzilla.gnome.org/show_bug.cgi?id=733501
Issue an invalid VIDIOC_EXPBUF ioctl to the driver to check if the
driver supports dmabuf export. If the driver does not implement the
IOCTL, the error is ENOTTY. Any other error codes mean that the driver
implements VIDIOC_EXPBUF.
https://bugzilla.gnome.org/show_bug.cgi?id=779466
The purpose of being able to flush the buffer pool is only to
unlock any blocked operation. Doing streamoff/streamon had the
side effect of turning off and on the camera. As we do a flush_start
/ flush_stop sequence when shutting down, that would cause a really
quick sequence of streamoff/streamon/streamoff/close which was
causing some cameras to stop working.
https://bugzilla.gnome.org/show_bug.cgi?id=783945
The code relied on the list compare function to fixate the caps
but if the caps only has one structure, the compare function will
never get called. Capture device for which there is only one
structure in the caps would then get some assertion and later
fail badly.
Instead, fixate before inserting into the list and split the reading
and the fixation of the structures.
try_fmt will update the caps colorimetry and interlace-mode. Before this
call, those field are missing. The caps equality check was always
failing when a spurious reconfigure event was received.
These have been copy pasted all over the place and are not used anymore.
All object have it's own category now. This fixes build warning since
the VP9 decoder had vp8 category declared.
Whenever we import from downstream pool (userptr or dmabuf-import), we
should copy over the flags and timestamp, otherwise downstream will not
get proper synchronization or will not be able to notice frames that has
corruption in it.
https://bugzilla.gnome.org/show_bug.cgi?id=785680
Removes the FIXME/Question in the buffer pool and add a ref to the
element in the GstAllocator too. This ref is strictly required to keep
the GstV4l2Object structure around.
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.
While not documented, gst_video_colorimetry_matches() only accepts well
known names. Looking at the code and unit test, this seems to be on
purpose, so fixing by parsing the string and compating the colorimetry
structures.
The subclass negotiated function will call set_format, if that fails the
pool will not be created. We ended up with an assertion.
GStreamer-CRITICAL **: gst_buffer_pool_set_active: assertion 'GST_IS_BUFFER_POOL (pool)' failed
In this commit, we enabled skip_try_fmt_probes quirk in order to speed
up the start which is known to be disastrously slow with certain USB
cameras.
This has the side effect that we needed to rewrite the entire
negotiation process in a way that we iterate over the possible caps
until we find one that works.
The new negotiation method consist of extracting a preferred structure
from the peer caps and using this to fixate and sort the caps. To
reflect the old behaviour, we sort all resolution strictly bigger
to the preferred one with the closes one first. The rest is appended,
keeping the same order. We then normalize the caps in case there was
some list of interlace-mode or colorimetry left. We finally iterate
over all fixed caps and try it. 99% of the time, the first or the
second one should work, whit the result of a single S_FMT being issues.
From there, it will be relatively easy to introduce new negotiation
algorithm. The current algorithm is made for optimal image quality
with a scaling sink that sets it's window resolution as preference.
This the case if for:
v4l2src ! videoconvert ! videoscale ! ximagesink
Other strategy would be needed to optimize for non-scaling sink like
ximagesink or kmssink when the driver does not scale.
https://bugzilla.gnome.org/show_bug.cgi?id=785156
skip_try_fmt_probes quirk is set, V4L2 object will not probe for
interlace-mode and colorimetry to avoid relying on try_fmt. This quirk
will be used by v4l2src to avoid desastrous startup time with slow
USB webcams.
When this quirk is enabled, caller will have to iterate over the
negotiated caps as it may contains unsupported formats. If the peer
didn't choose a specific interlace-mode, or colorimetry, the value
chosen by the driver is set into the caps. For this reason, when this
mode is enabled, gst_v4l2_object_set_format() will require writable
caps.
https://bugzilla.gnome.org/show_bug.cgi?id=785156
According to the spec,TRY_FMT cannot return EBUSY, though it can
return EINVAL if it was not possible to update the format to
something supported.
https://bugzilla.gnome.org/show_bug.cgi?id=785156
This is in preparation for removing slow TRY_FMT probes for
colorimetry. As we won't have tried that colorimetry we cannot
assume the driver will accept it.
https://bugzilla.gnome.org/show_bug.cgi?id=785156
This is in preparation from removing the slow TRY_FMT probes for
interlacing. As we won't have tried that interlace-mode already
we need to validate that the driver isn't refusing it.
https://bugzilla.gnome.org/show_bug.cgi?id=785156
