GNOME Bugzilla – Bug 740368
mpeg2dec: Failed "uncleanly" upon resolution change (e.g. video track change)
Last modified: 2018-11-03 15:34:46 UTC
If a media has different video tracks, set the playbin "current-video" property allow to select the current track displayed g_object_set (playbin, "current-video", index, NULL); This is working perfectly fine if the different tracks have the same width/height. However, if the width/height change, gstreamer will fail with the following error setting current video stream to 1 ERROR default video-frame.c:152:gst_video_frame_map_id: invalid buffer size 540000 < 556800 ERROR mpeg2dec gstmpeg2dec.c:563:gst_mpeg2dec_alloc_buffer:<mpeg2dec0> Failed to map frame WARN multiqueue gstmultiqueue.c:1571:gst_multi_queue_loop:<multiqueue0> error: Internal data stream error. WARN multiqueue gstmultiqueue.c:1571:gst_multi_queue_loop:<multiqueue0> error: streaming stopped, reason error Error received from element multiqueue0: Internal data stream error. ( as reported using GST_DEBUG=*:3) Please find attached a test application that can be used to reproduce the bug, based on http://docs.gstreamer.com/plugins/viewsource/viewpagesrc.action?pageId=327794 I've made the following changes: 1) update to be compatible with gst 1.0 (playbin2 -> playbin) 2) uri of media comes from command line 3) console prompt is used to select video (instead of text) Hopefully the attached code can be compiled directly using cmake (cmake file includes). Steps to reproduce the issue: 1) test with a video containing 2 video tracks (same width / height): ./multitrack http://trac.webkit.org/export/176315/trunk/LayoutTests/media/content/two-audio-and-video-tracks.mkv --> press 0 or 1 in console allow to select the video track, it works perfectly fine. 2) test with a video containing 3 video tracks with different w/h: GST_DEBUG=*:3 ./multitrack file://$PWD/multivideo.mp4 gstreamer will fail when changing the video track. multivideo.mp4 is included in attached code and has been generated using ffmpeg: ffmpeg -loop 1 -i image000.png -c:v libx264 -t 30 -pix_fmt yuv420p blue.mp4 ffmpeg -loop 1 -i image002.png -c:v libx264 -t 30 -pix_fmt yuv420p purple.mp4 ffmpeg -loop 1 -i image001.png -c:v libx264 -t 30 -pix_fmt yuv420p green.mp4 ffmpeg -i green.mp4 -i blue.mp4 -i purple.mp4 -map 0:0 -map 1:0 -map 2:0 -metadata:s:v:0 language=eng -metadata:s:v:1 language=fre -metadata:s:v:1 language=deu -c copy -c:v mpeg2video multivideo.mp4 (mplayer and SMPlayer are able to select multivideo.mp4 video tracks).
Created attachment 291002 [details] source code + cmake + video
I've been able to workaround the "gst_video_frame_map_id: invalid buffer size 540000 < 556800" issue, using GST_PAD_SET_FLUSHING(pad) on the previously activated track before g_object_set(m_playbin.get(), "current-video" Change the "current-video" works fine in that case, however we cannot switch back to a previously activated track, i.e. 1) track 0 is selected 2) GST_PAD_SET_FLUSHING(pad) on track 0 pad. 3) g_object_set(m_playbin.get(), "current-video", 1); 4) track 1 is selected, everything fine so far 5) GST_PAD_SET_FLUSHING(pad) on track 1 pad. 6) g_object_set(m_playbin.get(), "current-video", 0); 7) track 0 won't playback (because of flushing) FYI, In step 6), gst_pad_check_reconfigure (m_pad) returns true. Is there any way to "restart" a pad that has been set to FLUSHING ? (GST_PAD_UNSET_FLUSHING is not working). Or is there any other workaround that could allow to bypass the " invalid buffer size" issue ? Updating the GStCaps somehow ? Any input / comment is welcome. Thanks a lot.
Does mpeg2dec support renegotiation at all ? Might be a missing feature here. Have you tried the same with H264/avdec_h264 ?
I've re-encoded my media using libx264 and it works fine, I can change the video track. This workaround is good enough for me, thanks a lot ! We can close this bug, except if anyone is willing to work on renegotiation support in mpeg2dec ^^ (I can help to test if needed, but I fear I cannot help further). Thanks again.
I'll have to check if there isn't already a bug for renegotiation in mpeg2dec, though imho it should fail in a cleaner way if we don't implement the feature. We'll keep it around until we have sorted it out. Thanks a lot for the report, glad you aren't blocked on this.
I thought this worked at some point.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/issues/9.