GNOME Bugzilla – Bug 789193
Switch to new send/receive API
Last modified: 2018-05-04 13:00:12 UTC
A try to decode h.264 stream, generates multiple warnings "Got unexpected packet size after a partial decode" and no frame has been decoded.
I can confirm this here.
AVCodec internals changed in https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/061a0c14bb5767bca72e3a7227ca400de439ba09 . Seems the compat wrappers aren't fully compatible. Porting doesn't look trivial.
Thanks for checking this Jan, can you submit a bug to the ffmpeg people for that? The compatibility layer should probably be fixed.
https://trac.ffmpeg.org/ticket/6446 mentions that the wrappers don't like getting fed empty frames if you don't actually need to drain them, but GStreamer attempts to drain the decoder right after opening it.
More info about the new API: https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html As an aside, the codecs apparently now always allocate their own output memory and do not allow providing allocated frames from our own pool, so the compat wrappers copy the output to the GStreamer-provided AVFrame. --- The compat wrappers seem to get stuck in an EOF mode whenever they get an empty packet (GStreamer drains before any DISCONT buffer) until the codec is flushed. Reverting 67e55e47e2aaa07ef179b72637d8a1a3e13064f7 (so that avcodec_flush_buffers is called after draining) makes decoding video work again. However, as mentioned in that commit, decoding of streams with missing frames is now broken: gst-launch-1.0 videotestsrc ! x264enc ! rtph264pay ! identity drop-probability=0.1 ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! autovideosink I've tried avoiding a drain when the decoder hasn't handled any frames yet, but that's not enough as it still gets stuck on the next DISCONT.
Upstream bug: https://trac.ffmpeg.org/ticket/6775
Ok, there is an upstream bug, but we should work out in the base class a way to avoid all these useless drain. There is not enough context in the subclass do to so, and it would need to happen everywhere. That behaviour is currently blocking me from implementing drain vmethod in v4l2src.
Created attachment 363014 [details] [review] quick & dirty hack to use new decoding API for viddec Not meant as "fix" but as temporary workaround for people bothered by this issue: This quick & dirty hack replaces the deprecated call to avcodec_decode_video2 by calls to avcodec_send_packet and avcodec_receive_frame. Note that this is hack is really ugly, because the API really isn't meant to be used this way (the assumption is that each call to avcodec_send_packet will produce at most one new frame) and also the error handling and probably other cases are not handled correctly. However, MP4 videos seem to play fine for me.
3.4.1 has fixed the compatibility issue. After testing everything looks fine. That being said we do need to switch to the new API eventually. I do find it weird that one cannot provide your own (downstream) buffers with the new system. Demoting from blocker and updating title accordingly. commit 829b269e1ef30c8f588ec0a8bddeff117c29c43a Author: Edward Hervey <bilboed@bilboed.com> Date: Sat Feb 10 14:56:50 2018 +0100 gst-libs: Switch to ffmpeg n3.4.1
That broke the build on various platform. Android: missing <linux/perf_event.h> Windows: Failed to find tom config.mak IOS: Same as windows
*** Bug 768280 has been marked as a duplicate of this bug. ***
*** Bug 779479 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 792900 ***