VA encoders, at reconfiguration, have to check if the rate-control was changed
by the user, but since user parameters setting are in another thread, the
comparison was racy.
This patch locks the object to compare the current rate-control with the one set
by the user.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9480>
Make it work a little more like RTP. Have the source interact with the
clock and set the capture time on each packet. Then the other elements
can use that to do adjustments. Since AVTP is always very low latency,
it can be assumed that the gPTP clock at the packet reception is very
close to the sending time, never more than 2 seconds off, so the
timestamps can be compared directly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9412>
Caps may change the framerate used and the frame counting approach for
timestamps, needs to account for this by taking a snapshot of the current frames
and running time to add to all subsequent produced frames. Code is mostly taken
from videotestsrc.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9455>
When the base videodecoder class re-attempts a negotiation after flush, the
vabasedec `need_negotiation` flag isn't necessarily set to TRUE, because in that
situation the input state hasn't changed.
By always chaining up we are sure that buffer pool negotiation will always be
attempted.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9457>
When the base videodecoder class re-attempts a negotiation after flush, the
vabasedec `need_negotiation` flag isn't necessarily set to TRUE, because in that
situation the input state hasn't changed.
By always chaining up we are sure that buffer pool negotiation will always be
attempted.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9457>
When the base videodecoder class re-attempts a negotiation after flush, the
vabasedec `need_negotiation` flag isn't necessarily set to TRUE, because in that
situation the input state hasn't changed.
By always chaining up we are sure that buffer pool negotiation will always be
attempted.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9457>
When the base videodecoder class re-attempts a negotiation after flush, the
vabasedec `need_negotiation` flag isn't necessarily set to TRUE, because in that
situation the input state hasn't changed.
By always chaining up we are sure that buffer pool negotiation will always be
attempted.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9457>
This is needed if the LCEVC enhancement data is part of the video stream as SEI
and the demuxer outputs 'lcevc=false' src caps because LCEVC enhancement data is
not stored as a separate stream in the container.
To clarify, 'lcevc=true' just means that the video buffers have LCEVC metadata
attached. Therefore, it is valid to have a stream with LCEVC enhancement data as
SEI with 'lcevc=false' as long as it is not attached as metadata.
This will be needed once we add support for the demuxer to attach LCEVC metadata
to video buffers if it is stored in a separate track.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9427>
This broke in 81bdef0150df3306136137a5187dc25a7c5f4aee. Simplify
removal of the plugin from the plugin list if features are listed, and
fix invocation of the script -- it was adding an extra space before
the first plugin filename.
Also ensure that gst-full CI is run when the script changes.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9452>
Just because a plugin name is a substring of another plugin, doesn't
mean it is the same plugin. If the list of plugins can contain
a filename, that will be a static lib of the form libgstfoo.a
For example, if you had `-p applemedia -e app:appsrc,appsink` then
`applemedia` would be removed from the plugins list.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9442>
