Instead of passing along the system frame number, we pass along a reference to
the GstVideoCodecFrame.
In order for all internal cleanup to happen properly, this also requires
switching to the proper AVPacket creation/destruction methods (av_packet_alloc()
and av_packet_unref())
Fixes#2568
Co-authored-by: Edward Hervey <edward@centricular.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5186>
This is already done for every other calls to send_packet. The deadlock occures
since FFMPeg 6.0. The decoder tries to get a buffer from a thread during
the draining process, and blocks trying to get the video decoder stream lock
already heald by the drain function.
Fixes#2383
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4171>
This fixes a compile error with recent upstream FFmpeg.
The AV_CODEC_CAP_AUTO_THREADS was deprecated and renamed to
AV_CODEC_CAP_OTHER_THREADS in FFmpeg upstream commit
7d09579190de (lavc 58.132.100).
The AV_CODEC_CAP_AUTO_THREADS was finally removed in FFmpeg upstream
commit 10c9a0874cb3 (lavc 59.63.100).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3951>
In cases where an invalid input packet is submitted to the decoder we emit a
warning but reporting the flow error upstream would also be useful. This came up
with a case were the application interacts directly with the decoder, using a
mechanism similar to GstHarness.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3463>
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>
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>
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>
