Recent kernels allow REQBUFS(0) on a queue that still has buffers in
use (mmapped or exported via dmabuf), orphaning all buffers on the queue.
If this is supported, the v4l2videodec element does not have to send a
drain request downstream.
Now that the v4l2allocator allows orphaning the V4L2 buffer queue, add
support for orphaning in the v4l2bufferpool. gst_v4l2_buffer_pool_orphan
can be used as a replacement for gst_v4l2_buffer_pool_stop, without
having to wait for buffers to be returned to the pool.
Recent kernels allow REQBUFS(0) on a queue that still has buffers in
use (mmapped or exported via dmabuf), orphaning all buffers on the queue.
Orphaning the allocator causes it to release all buffers with
REQBUFS(0), even if they are still in use. An orphaned allocator can
only be stopped. It can not be restarted or create new buffers.
Update to the latest installed headers (output of make headers_install)
from the media tree, keeping the slight modifications to the includes.
This includes new HEVC controls, the AdobeRGB -> opRGB rename, a new
capabilities field for v4l2_requestbuffers and v4l2_create_buffers, new
32-bit YUV formats, and request_fd changes.
The caps features were lost when sorting caps structures in
gst_v4l2src_fixate(). This was breaking alternate as
GST_CAPS_FEATURE_FORMAT_INTERLACED was removed from the caps.
The V4L2 elements already set the delta unit buffer flag when dequeueing
the buffer, but gst_video_encoder_finish_frame overwrites it from the
passed codec frame's sync point flag. Set the flag correctly.
This fixes a critical warning if the last-sample property is enabled:
(gst-launch-1.0:391): GStreamer-CRITICAL **: 01:12:57.428: gst_object_unref: assertion 'object != NULL' failed
If the allocation query does not contain any allocation pools,
gst_query_parse_nth_allocation_pool will leave the local pool,
min, and max variables undefined, so check the array length first.
If pool is NULL, do not call gst_object_unref.
The function gst_v4l2_object_add_interlace_mode() has repeating code so
it's best use a loop instead. That will make it easy and simple to add
additional interlace modes in a following patch.
The previous patch did not even compile on any possible platform or C
standard. That commit also didn't have a proper commit message.
Android ships Linux with a different signature for ioctl. They first
released an ioctl with int as request type, and later "fixed" it by
adding an override with unsign, which is still not matching Linux and
BSD implementation which uses unsigned long int.
If there was no interlace-mode field in the caps. Read back the value
selected by the driver. This way, if the driver does not support
progressive, then it will automatically negotiate the returned mode
unless this mode is not supported by GStreamer.
This method was already used for colorimetry. Just like colorimetry, the
interlace mode is not longer probed by v4l2src dues to performance
issues.
Fixes#511
There is no specific needs to duplicate the FD. Unlike the exportation,
we don't depend on code that will call close. This will make debugging
easyer since the traced FD will match the exporter.
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
