There are cases where upstream will not provide a framerate, or it won't be
fixed. But if there is latency introduced by the decoder we do want to report
it.
Therefore use the framerate stored in the actual decoder, which will have a
default.
Fixes hangs when playing back such streams with decodebin3 (where the multiqueue
will not have been informed of that downstream latency and not grow accordingly)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3391>
Subtracting a gint from another (or a guint from another) has no guarantees that
it will result in a gint.
Therefore do the actual comparision instead.
Also use the *actual* type for comparing flags (the field value types are different)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3319>
The picture parameter picture->top_field_first is reused in this mode
to signal the TOP fields. As a side effect, it will change every frame
and current code assumed that if this changes then a renegotiation is
needed. Fixed this by ignoring that change whenever we are decoding one field
only.
Fixes#1523
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3276>
segment events by demuxer.
In order to play nicely with `ffmpeg`, demuxers in `gst-libav` have to make
buffers available to `ffmpeg` while taking the blocking I/O model in `ffmpeg`
into account, which results in buffers not being sent downstream until `ffmpeg`
has processed them in its separate thread.
In constrast, many `gstreamer` events are simply forwarded downstream.
Currently `GST_EVENT_SEGMENT` events are forwarded downstream without any
processing, which can potentially result in:
* `GST_EVENT_SEGMENT` events being out of sync with buffers
* `GST_EVENT_SEGMENT` events going out that are incorrect because they apply
to data seen by the demuxer, but not necessarily seen by downstream elements
I came across this bug when I was attempting to enable G723.1 demuxing/decoding
using the G723.1 demuxer and decoder provided by `ffmpeg`. I wrote tests to
verify support for the functionality, and found that, in push mode,
`GST_EVENT_SEGMENT` events pushed to the demuxer by the upstream `filesrc`
element would be forwarded to the decoder without modification, resulting in
an internal data streaming error. With this patch, tests work in both push and
pull mode.
This patch solves the problem by disabling the forwarding of
`GST_EVENT_SEGMENT` events downstream (an initial `GST_EVENT_SEGMENT` event is
still pushed downstream by the demuxer). It's possible there's a better way to
do this, but, having looked at how a few different `gstreamer` demuxers deal
with `GST_EVENT_SEGMENT` events, it seems like the processing is somewhat
specific to the demuxer implementation, whereas `gst-libav` has one general way
of handling the situation for any `ffmpeg` demuxer. Perhaps there's a better
way to solve this using the `ffmpeg` API to take advantage of specific demuxer
details. IDK.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3218>
It would constantly want to renegotiate (and spam the debug log) even
though the channel layout hasn't actually changed. We use the same
fallback in gst_ffmpegauddec_negotiate() already.
This happens with WMA files for example.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3103>
The AVClass name of Animated PNG in FFmpeg 5.x is "(A)PNG"
and it will be converted to "-a-png" through
g_ascii_strdown() and g_strcanon(). But GLib disallow leading '-'
character for a GType name. Strip leading '-' to workaround it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2724>
Some encoders (e.g. Makito) have H265 field-based interlacing, but then
also specify an 1:2 pixel aspect ratio. That makes it kind-of work with
decoders that don't properly support field-based decoding, but makes us
end up with the wrong aspect ratio if we implement everything properly.
As a workaround, detect 1:2 pixel aspect ratio for field-based
interlacing, and check if making that 1:1 would make the new display
aspect ratio common. In that case, we override it with 1:1.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2577>
FFMPEG 5+ doesn't allow overriding the codec anymore (causes a segfault if you
attempt to do that). But the best part is ... that with the current caps
implementation in pad template and gst_ffmpeg_caps_to_codecid() we would never
replace it by anything different than the existing codec id.
Fixes#1054
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2052>
Latest ffmpeg has removed avcodec_get_context_defaults(), and its
documentation says a new AVCodecContext should be allocated for this
purpose. The pointer returned by avcodec_find_decoder() is now
const-qualified so we also need to adjust for it. And, AVCOL_RANGE_MPEG
is now rejected with strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1531>
