GNOME Bugzilla – Bug 702806
mpegvideoparse/mpeg2dec: No valid frames found before end of stream
Last modified: 2013-07-30 04:56:42 UTC
gst-launch-1.0.exe filesrc location=720x576_p25_video_mpg2_audio_mp2_xion-sd-cam.avi ! avidemux ! mpegvideoparse ! mpeg2dec ! autovideosink -v Setting pipeline to PAUSED ... Pipeline is PREROLLING ... /GstPipeline:pipeline0/GstMpegvParse:mpegvparse0.GstPad:sink: caps = video/mpeg, systemstream=(boolean)false, mpegversion=(int)2, framerate=(fraction)25/1, width=(int)720, height=(int)576, codec_data=(buffer)000001b32d024023138823821020202620262c2c2c2c2c2c343034363636343434343636363a3a3a4444443a3a3a36363a3a404044444a4c4a464644464c4c50505060605c5c7070748a8aa7101010101010101010101111111111121212121212131313131313131414141414141414151515151515151616161616161717171717181818181a1a1a1c1c1e000001b5148200010000, pixel-aspect-ratio=(fraction)16/15 ERROR: from element /GstPipeline:pipeline0/GstMpegvParse:mpegvparse0: No valid frames found before end of stream Additional debug info: gstbaseparse.c(1066): gst_base_parse_sink_default (): /GstPipeline:pipeline0/GstMpegvParse:mpegvparse0 ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ...
Link to video file: https://www.dropbox.com/s/bvykzv7vck7kg88/720x576_p25_video_mpg2_audio_mp2_xion-sd-cam.avi
I can confirm that. Just using mpeg2dec and no video parser does not work either. Using no mpegvideoparse but avdec_mpeg2video works just fine. Seems to be a special kind of MPEG stream that for some reason is not detected as MPEG video by mpegvideoparse and libmpeg2.
Maybe it just needs to dump the codec_data with the stream headers inline before any other data?
I think (from memory) that gst-launch-1.0 filesrc location=foo.avi ! mpegvideoparse ! dec ! .. worked :)
Created attachment 249863 [details] [review] mpegvideoparse: Fix codec_data handling Set to sequence_offset so that _process_config accepts it. (btw: seq_offset usage throughout this plugin is really dodgy)
The bug was even more pathetic. We never parsed the codec_data. so if the sequence_header was only in the caps (and not in the stream) ... it would always fail.
Review of attachment 249863 [details] [review]: Indeed, since the codec data contains a start code .... It's actually confusing, since this is not always true in other formats
commit 06717150bfc39d89f7b298fcb0596fc5427a753f Author: Edward Hervey <edward@collabora.com> Date: Tue Jul 23 10:10:13 2013 +0200 mpegvideoparse: Fix codec_data handling Set to sequence_offset so that _process_config accepts it. (btw: seq_offset usage throughout this plugin is really dodgy) https://bugzilla.gnome.org/show_bug.cgi?id=702806
I don't think this is a proper fix. I have file where codec data doesn't contain the startcode. https://s3.amazonaws.com/MatejK/Samples/x.mp4 Perhaps we should check if startcode is present first?
Or perhaps demuxer should be responsible for this?
That codec_data doesn't look right indeed, something to fix/detect in the demuxer. Can you open a new bug regarding that ?