There was a race condition where the demuxer would seek back to beginning after
determining the duration and while that seek was in progress one pad would
attempt to push a new buffer downstream, leading to a critical warning in
gst_pad_push().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8785>
driftsamples currently uses the requested skew directly, even if it
exceeds cexternal.
Use the approach that skew_slaving uses to fix this. As a side benefit,
this makes the custom_slaving and skew_slaving code easier to compare.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8605>
The 'new-pref' property sets the preference to use the new (next)
instead of the old (previous) buffer. The default is set to 0.5 to get
a similar behaviour as before the change.
Value 0.0 makes sure that only frames are shown where it's known that
the frame content is visible at that time, always show the old frame
until the new frame timestamp is reached.
Then, if the next buffer replaces the previous buffer the new buffer
is pushed as often as possible until PTS is reached. Before the new
buffer was only pushed once the new next buffer arrived.
Use GstClockTimeDiff because it's known that the current buffer time
is inside the time interval of previous buffer and next buffer the
calculation can be done with building absolute values. Special macros
are not needed here.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8579>
gst_video_time_code_to_date_time() simply calculated the date time based on
adding the hours/minutes/seconds to the daily jam. This causes a gap every full
minute (except for every 10th minute) with drop-frame timecodes as the first 2
(29.97fps) or 4 (59.94fps) timecodes are skipped (not frames!), e.g. with
29.97fps:
timecode: 12:00:59;28 12:00:59;29 12:01:00;02 12:01:00;03
time : 12:00:59.950 12:00:59.983 12:01:00.017 12:01:00.050
and not
time : 12:00:59.934 12:00:59.968 12:01:00.067 12:01:00.100
|-- gap of 2 frames --|
The correct calculation would be to use gst_video_time_code_nsec_since_daily_jam()
and add that to the daily jam.
Also add a test for this.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8649>
`parsebin` is potentially added by a `typefind` callback.
That `typefind` was activated by a `READY_TO_PAUSED` state change on `urisourcebin`
We want to ensure that it is the "setup_parsebin_for_slot" method that activates
the underlying `parsebin`, and not the external state-change.
Otherwise we would risk a potential deadlock where elements activating in
`parsebin`, and which would cause the upstream `typefind` to switch scheduling
mode, would not be able to acquire the STREAM_LOCK of the `typefind` task.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/4225
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8511>
Scenario is using wayland with this pipeline: videotestsrc ! glupload ! qml6glsink.
First pipeline and qml construction works just fine. However if all GStreamer
and QML scenegraph resources are removed, GStreamer will call eglTerminate() and
sever the connection to the display server for Qt. When Qt attempts to do any
further GL operations like construct a new QML scene, it can crash in any number
of places as libEGL will start returning NULL or other unexpected values.
What we really need is to ensure that if an external API (e.g. Qt) will
eventually call eglTerminate(), there is no need for GStreamer to call
eglTerminate(). This is what the foreign display flags allows setting.
There is also another possible scenario where one may like to make GStreamer
assume ownership of an EGLDisplay and thus eventually call `eglTerminate()`. As
such, it is now also possible to mark an GstGLDisplayEGL as non-foreign.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8504>
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>
The property is defined as:
> The difference between incoming timestamp and next timestamp must exceed
> the given value for audiorate to add or drop samples.
so if the gap duration < tolerance, we should not act.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8498>
AV1 specification [1] define 2 AV1 raw bitstreams storage
formats without containers:
- OBU in chapiter 5.2
- Annexb in chapiter 11.
Implement a detection function for the both cases mostly
by testing OBU forbidden, type, has_size_field and reserved bits.
For annexb case testing if temporal unit size, frame unit size and
obu length are valid. If they are check that the first OBU is
a temporal delimiter.
[1] https://aomediacodec.github.io/av1-spec/av1-spec.pdf
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8502>
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 f349cdccf5e1538f3eb9caa31458b53fdd81671b
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>
