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>.
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 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.
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
Since 1.6, the transfer function for BT2020 has been changed from BT709
to BT2020_12. It's the same function, but with more precision. As a side
effect, the V4L2 colorpsace didn't match GStreamer colorspace. When
GStreamer ended up making a guess, it would not match anything supported
by V4L2 anymore. This this by using BT2020_12 for BT2020 colorspace and
BT2020 transfer function in replacement of BT709 whenever a 4K
resolution is detected.
The pixel aspect ratio is documented to not change unless the TV
Standard is changed. So this mean that this will be uniform across all
possible format and resolutions.
https://bugzilla.gnome.org/show_bug.cgi?id=784674
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.
Increasing this number fix a buffer starvation problem I'm hitting
with a "v4l2src ! kmssink" pipeline.
kmssink requests 2 buffer as it keeps a reference on the last rendered
one. So we were allocating 3 buffers for the pipeline.
Once the first 2 buffers have been pushed we ended up with:
- one buffer queued in v4l2
- one being pushed
- one kept as last rendered
If this 3rd buffer is released after that v4l2 used the first one to
capture we end up with a buffer starvation problem as no buffer is currently
queued in v4l2 for capture.
Fixing this by adding one extra buffer to the pipeline so when one
buffer is being pushed downstream the other can already be queued to
capture the next frame.
We were already adding 3 buffers if downstream didn't reply to the
allocation query. I reduced this number to 2 to compensate the extra
buffer which is now always added.
https://bugzilla.gnome.org/show_bug.cgi?id=783049
Without a specified framerate from the sink, the decoder frame interval
should be set using the framerate of the encoded video stream.
Therefore, the v4l2object should be able to change the framerate on the
output if the V4L2 device accepts it.
This is also necessary for mem2mem encoders so that their bitrate
calculation code may work correctly and they may report the correct
frame duration on the capture queue.
https://bugzilla.gnome.org/show_bug.cgi?id=779466
