GNOME Bugzilla – Bug 753869
avviddec: Resolution changes result in outdated buffer pool configuration
Last modified: 2015-09-08 14:58:22 UTC
Using the following pipeline: gst-launch-1.0 uridecodebin name="uribin" uri="http://rdmedia.bbc.co.uk/dash/ondemand/bbb/2/client_manifest-avc1.mpd " \ caps="video/x-h264, alignment={ au }; audio/mpeg, mpegversion=4" ! \ video/x-h264 ! h264parse ! \ queue ! \ avdec_h264 ! \ autovideoconvert ! \ ximagesink sync=true max-lateness=1000000000 \ uribin. ! audio/mpeg ! queue ! \ aacparse ! avdec_aac ! audioconvert ! \ alsasink max-lateness=1000000000 When the bitrate switch occurs, the display window goes black and the following errors appear on the console: ** (gst-launch-1.0:7341): CRITICAL **: gst_video_frame_map_id: assertion 'info->width <= meta->width' failed ** (gst-launch-1.0:7341): CRITICAL **: gst_video_frame_map_id: assertion 'info->width <= meta->width' failed ** (gst-launch-1.0:7341): CRITICAL **: gst_video_frame_map_id: assertion 'info->width <= meta->width' failed ** (gst-launch-1.0:7341): CRITICAL **: gst_video_frame_map_id: assertion 'info->width <= meta->width' failed WARNING: from element /GstPipeline:pipeline0/GstAutoVideoConvert:autovideoconvert0/GstAutoConvert:autoconvertchild/GstVideoConvert:videoconvert0: Internal GStreamer error: code not implemented. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer. Additional debug info: gstvideofilter.c(292): gst_video_filter_transform (): /GstPipeline:pipeline0/GstAutoVideoConvert:autovideoconvert0/GstAutoConvert:autoconvertchild/GstVideoConvert:videoconvert0: invalid video buffer received ERROR: from element /GstPipeline:pipeline0/GstXImageSink:ximagesink0: Output window was closed Additional debug info: ximagesink.c(700): gst_x_image_sink_handle_xevents (): /GstPipeline:pipeline0/GstXImageSink:ximagesink0 Execution ended after 0:00:06.059768280 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... Trying the same pipeline with an AVC3 stream works correctly: gst-launch-1.0 uridecodebin name="uribin" uri="http://rdmedia.bbc.co.uk/dash/ondemand/bbb/2/client_manifest-common_init.mpd" caps="video/x-h264, alignment={ au }; audio/mpeg, mpegversion=4" ! video/x-h264 ! h264parse ! queue ! avdec_h264 ! autovideoconvert ! ximagesink sync=true max-lateness=1000000000 uribin. ! audio/mpeg ! queue ! aacparse ! avdec_aac ! audioconvert ! alsasink max-lateness=1000000000
Most likely a bug in gst-libav, that it configures buffer pools incorrectly for the caps.
77 g_return_val_if_fail (info->width <= meta->width, FALSE); (gdb) print info->width $1 = 896 (gdb) print meta->width $2 = 512 And the resolution changed from 512 to 896. direct-rendering=false on avdec_h264 makes it work. I suspect something wrong with the buffer pool code in this commit: commit e3bdfb560858da160edb486c960bfaf4e744fb22 Author: Nicolas Dufresne <nicolas.dufresne@collabora.com> Date: Sun Aug 16 19:08:16 2015 +0200 aviddec: Re-enable direct rendering This is achieved by using a tempory internal pool. We can then switch to a downstream pool if the downstream pool buffer have matching strides. https://bugzilla.gnome.org/show_bug.cgi?id=752802
Also this stream causes a segfault with this stream, or the same assertions: http://dash.edgesuite.net/dash264/TestCasesHEVC/2b/2/BBB_Live_HEVC_MultiRes.mpd (see bug #750865).
The first link give me no-linked on git master, that should probably never happen in playbin. I can reproduce the crash with the second.
Created attachment 309730 [details] [review] avviddec: Fix pool reallocation logic The check was not correct, which would lead to the buffer pool not being re-created when it should.
This should fixe the problem initially (even though the link is broken for me, I tested with a resize media of mine). Though it does not fix the second issue reported here.
Comment on attachment 309730 [details] [review] avviddec: Fix pool reallocation logic the HEVC stream still crashes with ERROR:gstavviddec.c:802:gst_ffmpegviddec_get_buffer2: assertion failed: (picture->linesize[c] == ffmpegdec->stride[c])
Created attachment 309773 [details] [review] avviddec: Fix pool reallocation logic Some check where incorect and also unsafe. The only reliable information in get_buffer2 is the picture width/height really. The side effect is that the width/height of the internal pool endup padded, so when we switch we also need to switch to the a new width/height, hence we save the pool info.
So, this is a more complete fix, but I have a leak which I need to chase now. I've published it so one can review.
Created attachment 309774 [details] [review] avviddec: Fix pool reallocation logic Some check where incorect and also unsafe. The only reliable information in get_buffer2 is the picture width/height really. The side effect is that the width/height of the internal pool endup padded, so when we switch we also need to switch to the a new width/height, hence we save the pool info.
Attachment 309774 [details] pushed as 6e590fe - avviddec: Fix pool reallocation logic
It does not appear fully fixed. While I do not get any errors, I end up with only part of the video displays on a sink that does not change size (and no scaling happens to match). Looks like some renegotiation does not happen, or something (playbin or the sink) does not do enough to display the full video.
Actually, nevermind. Adding a manual videoscale makes this work, and playbin works too (via gst-play-1.0).
(phew)