This pool isn't reusing its buffers, which makes it pointless to enable
the cache
Holding an extra buffer in free queue can also lead to a deadlock when
the pool's max buffer count is configured low (commonly 2).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8939>
By design, unixfd is meant to be used for zero-copy and failing when the data is
not FD based memory is wanted to help debug pipelines. Though, there exists
cases, notably with RTP payloader and demuxers, where its not possible
to get all the data into FD memory through allocation queries.
To allow using unixfd for these cases, introduce a property on the unixfdsink
that enable copying the non FD data into freshly allocated memfd.
Co-authored-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8861>
Wrap dependencies add a ton of warnings with the latest GCC in Fedora
42. Squelch them by specifying that these dependencies are not
a part of the gstreamer project, and should be treated as system deps.
libsoup needs some porting work for the bump, and vorbis/lame are
already at their latest releases.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8753>
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>
