Similar to NV12_10LE40, this is a 422 variant. This format is also named
NV20 (20bit per pixels) in other stack and is produced by rkvdec
decoder.
Co-authored-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5612>
The only thing that can be used in the chain function is the input segment. The
output segment might not be available at all yet or out of sync with the current
input segment.
Also because of that, the unadjusted timestamp has to be used for the
calculations as the adjustment is only part of the output segment.
This fixes the deadline calculation and the handling of force-keyunit events for
encoders using frame reordering (i.e. setting a minimum PTS).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8842>
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>
