gst_v4l2_object_set_format_full() was returning FALSE without setting
an error. Caller code (gst_v4l2src_fixate()) was then derefing a
NULL pointer when trying to handle the error.
libv4l2 reset the colorpace to 0 and does not do any request to the
driver. This yields an invalid colorspace which currently cause a
negotiation failure. This workaround by ignoring bad values during the
TRY_FMT step.
We were already supporting horizontal padding by setting bytesperline to
the buffer stride but not vertical one.
We are now updating the format height with the padded height and crop to
the actual video resolution if needed.
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.
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
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 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
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
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.
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
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
BT2020_12 is not represented in V4L2, so drivers providing full colority
for BT2020 will set V4L2_XFER_FUNC_709 transfer function. To fix the
issue, we bump this to BT2020_12 if the resoltion is 4K, but we should
only do that if the colorspace is BT2020 to start with, otherwise it's
not possible to use normal BT709 for 4K 8bit formats.
So far we were only setting colorimetry for OUTPUT devices (v4l2sink or
m2m sink pad). This prevented selecting through caps negotiation the
colorimetry for CAPTURE devices (v4l2src or m2m src pad). This is rarely
selectable, but trying is harmless.
This implements a "big hammer" reallocation method. We effectively
drain and stop both side of the decoder and restart. This though is
the most generic method. This change should enable on most drivers
adaptive streaming.
https://bugzilla.gnome.org/show_bug.cgi?id=752962
The difference between mmap and mmap64 is the type of 'offset' argument.
mmap64 always uses a 64-bit interger as offset, while mmap uses off_t,
whose size can vary on different operating systems or architectures.
However, not all operating systems support mmap64. Fortunately, although
FreeBSD only has mmap, its off_t is always 64-bit regardless of
architectures, so we can simply use mmap when sizeof(off_t) == 8.
https://bugzilla.gnome.org/show_bug.cgi?id=791779
This way we can pass the pad name instead of the element for tracing
which helps identifying which v4l2object is used withing M2M element
like decoder, encoder and transform. For the reference, pads are name
<parent-name>:<pad-name>.
