Cropping parameters were being miscalculated - getting
the output width/height wrong when an x/y crop offset
was given.
Cropping was also incorrectly being applied twice (because at
some point after the convertframe code was written,
`videocrop` also started paying attention to the
GstVideoCropMeta, but not in useful ways for this purpose). Add
a buffer probe to strip the crop meta from the input buffer
so videocrop can do its job correctly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8526>
transform_caps() from the upload methods can return NULL in some cases, so fall
back to empty caps in that case.
This can happen if "Raw Data" is the currently selected method and new caps with
memory:DMABuf caps feature are negotiated.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8514>
This leads to spurious negotiation failures because the configured method can
change over time and caps queries (and thus transform_caps) are happening
independently from configuring caps. Instead prefer the transformed caps of the
current method, but always also return the transformed caps for all other
methods. Previously all other methods would've only been used if the current
method returned empty caps. If a different method is needed later when
configuring the caps, it will be and was selected regardless.
Later during caps fixation, prefer the caps of the current method too for the
fixated caps if possible in any way.
This should preserve the desired behaviour of preferring the current method if
possible but to change to a different method if nothing else is possible, while
also returning consistent (and not too narrow) caps every time.
The way how the current method was checked was also racy as the current method
might change at any moment during caps query handling, and apart from
inconsistent results also a NULL pointer dereference was possible here. Use the
GST_OBJECT_LOCK to protect access to the current method like in other places.
This part of the code was introduced in f349cdccf5
and tried to be fixed multiple times over the years without addressing the root
cause of caps queries and caps configuration happening independently from each
other, e.g. in !2687 and !2699.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8431>
Previously there was no validation at all and the defaults were set if the
colorimetry was not set or invalid, but there's not really any connection
between colorimetry and chroma-site.
More validation could make sense in the future.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8258>
With this patch, configure time is identical no matter whether doc is
enabled or not.
The configuration files also now contain explicitly-listed sources with
no wildcards.
For the four libraries where hotdoc needs to use clang to generate the
documentation (as opposed to the rest of the libraries where hotdoc uses
the gir), the script will call pkg-config to determine the appropriate
C flags.
This means a side effect of this patch is that pkg-config files are now
generated for the gstadaptivedemux and gstopencv libraries.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8312>
appsink was queuing the caps event both in its GstBaseSinkClass.set_caps()
and its GstBaseSinkClass.sink_event() implementation, but only signaling
new_event from `sink_event`.
This caused `new_event` callbacks to start lagging by one.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7749>
The goal is equivalent to adding DMA_DRM caps to the existing raw
uploader, but creating a new dedicated uploader allows separating the
logic more easily.
Test:
- use an AMD system
- modprobe visl
- gst-launch-1.0 filesrc location=some-1080p-content.mkv ! parsebin ! v4l2slh265dec ! glimagesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8126>
Leaky appsrc feature was implemented similar to queue. Dropping item
is a normal case because it is configured so. Warning messages
is too severe for this event.
Level changed to DEBUG just like in queue.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8147>
This is used for optimize frame drop issue. Some video streams such as av1
contains decode-only frames. These frames are handled by decoder but not show
by display, which will cause input frame count unmatch the output frame count.
After collecting more decoder only frame, it will cause error report "so many
frame droped". So attach the flag GST_BUFFER_FLAG_DECODE_ONLY with the input
buffer, the v4l2videodecoder can further handle the decode-only buffer in
output list.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8142>
We get loads of warnings when parsing videos from users:
gsth264parser.c:1115:gst_h264_parser_parse_user_data_unregistered: No more remaining payload data to store
gsth264parse.c:646:gst_h264_parse_process_sei:<h264parse0> failed to parse one or more SEI message
Those are raised because of unregistered SEI without user data.
The spec does not explicitly state that unregistered SEI needs to have
data and I suppose the UUID by itself can carry valuable information.
FFmpeg also parses and exposes such SEI so there is no reason for us no
too as well.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7931>
At least some Mesa drivers (see llvmpipe_query_dmabuf_modifiers()) don't
initialize the provided external_only array, so some format/modifier
combinations could get incorrectly marked as only external.
Make sure we zerofill the array before passing it to
eglQueryDmaBufModifiersEXT().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6792>
