GNOME Bugzilla – Bug 758651
Fail to play MPEG2 video clip in file container format MPEG-PS in manual gst command pipeline
Last modified: 2017-03-07 17:40:00 UTC
Fail to play same MPEG2 Video clip with file container format MPEG-PS thru manual gst pipeline command. command: gst-launch-1.0 -v filesrc location=/root/MPEG_PS.mpg ! mpegpsdemux ! mpegvideoparse ! vaapidecode ! vaapisink But able to play it thru auto plug in gst pipeline thru playbin. command: gst-launch-1.0 playbin uri=file:///root/MPEG_PS.mpg Tested in gstreamer framework 1.6.1 and also 1.4.5 version with same libva, intel va and gstreamer-vaapi version.
Please attach the sample file...
(In reply to sreerenj from comment #1) > Please attach the sample file... And the error.
Just had a quick test, and reproducible. Thanks for the bug report. My educated guess is that, it could be related with the fact mpegpsdemux reporting the version as MPEG1 . We only support MPEG2 in vaapidecode. But it theory it should work since mpegvideoparse is reporting version as 2. I haven't debugged since busy with blocker bugs for 0.7 release in one week :)... I will look into into this, but unfortunately no promise to do it before the release :(.
Created attachment 316322 [details] sample mpeg-ps stream
It is interesting that fixed pipeline stalls on the demuxer, the prerolling does not finish. I'll set this as an enhancement, though I doubt if this is a gstreamer-vaapi issue.
Any update on this issue?
Works with avdec_mpeg2video and mpeg2dec, with or without playbin (git master). Maybe I'm testing it wrong ? Might not be strictly related, but there is something around VAAPI, or more generically a "zero-copy" path ?
It looks like the problem here is that this clip is mpeg video version 1. The mpegpsdemux eventually adds a video pad with mpegversion=1. mpegvideoparse's sink pad has already fixated at mpegversion=2 from vaapidecode so the pads can't link. I'm not familiar enough with gst-launch-1.0 to understand why it then just sits waiting, but you can see the same behavior without vaapi in this pipeline: gst-launch-1.0 filesrc location=sample_mpeg_ps_stream ! mpegpsdemux ! mpegvideoparse ! video/mpeg,mpegversion=2 ! avdec_mpegvideo ! fakesink
With a typefind, bellow command line work (playbin also use typefind to link the elements). It might not be a real bug, it might be just that clip is special and mpegpsdemux recognizes it as mpeg1 ps (need to check ISO 11172-1/mpeg1ps and ISO 13818-1/mpeg2ps to confirm it) gst-launch-1.0 filesrc location=./MPEG-PS/Gonegirl_640x320_6mbps_30fps_Main@High.mpg ! mpegpsdemux ! typefind ! mpegvideoparse ! vaapidecode ! vaapisink
Bellow is MPEG2PS spec and MPEG1PS spec for the pack_header syntax: ISO13818-1: pack_header() { pack_start_code 32 bslbf '01' 2 bslbf system_clock_reference_base [32..30] 3 bslbf marker_bit 1 bslbf ........ } ISO11172-1 pack() { pack_start_code 32 bslbf '0010' 4 bslbf system_clock_reference [32..30] 3 bslbf marker_bit 1 bslbf ........... } mpegdemux gstmpegdemux.c:gst_ps_demux_parse_pack_start follows above spec: static GstFlowReturn gst_ps_demux_parse_pack_start (GstPsDemux * demux) { ........... /* skip start code */ data += 4; ........... /* start parsing the stream */ if ((*data & 0xc0) == 0x40) { guint32 scr_ext; guint32 next32; guint8 stuffing_bytes; GST_LOG ("Found MPEG2 stream"); demux->is_mpeg2_pack = TRUE; ........... } else { GST_DEBUG ("Found MPEG1 stream"); demux->is_mpeg2_pack = FALSE; /* check markers */ if (G_UNLIKELY ((scr1 & 0xf1000100) != 0x21000100)) goto lost_sync; ........... } ........... } Check the clip, it will fall into gstmpegdemux.c:gst_ps_demux_parse_pack_start MPEG1 code path according to ISO13818-1/ISO11172-1: hexdump -C Gonegirl_640x320_6mbps_30fps_Main@High.mpg 00000000 00 00 01 ba 21 00 01 00 01 80 7b 3f 00 00 01 bb |....!.....{?....| 00000010 00 09 80 7b 3f 00 21 ff e0 e0 e6 00 00 01 e0 07 |...{?.!.........| 00000020 df 31 00 03 77 01 11 00 03 5f 91 00 00 01 b3 28 |.1..w...._.....(| 00000030 01 40 15 0e a6 23 80 00 00 01 b5 14 4a 00 01 00 |.@...#......J...| 00000040 00 00 00 01 b8 00 08 00 40 00 00 01 00 00 0a 84 |........@.......|
As @Austin analysis concludes, the file is not well crafted, since the demuxer announce a MPEG1, thus the pipeline cannot be linked with vaapimpeg2dec because it only supports mpeg2 (avdec_mpeg2video supports both, 1&2). It works with decodebin because the decoder is chosen after the parse detects MPEG2. Since the media file is ill-crafted, I will close this as notabug. If somebody else thinks that this is real bug that need to be solved, please reopen it.