GNOME Bugzilla – Bug 721621
Unable to play animal_planet.mpg video stream
Last modified: 2018-11-03 13:19:43 UTC
This stream can't be played with gstreamer: http://work.salstar.sk/public/gstreamer/animal_planet.mpg Response from Tim@IRC: <__tim:#gstreamer> the primary bug is that it doesn't play at all, the secondary issue is the detection of that lpcm or whatever stream Steps to reproduce: gst-launch-1.0 playbin uri=http://work.salstar.sk/public/gstreamer/animal_planet.mpg
And if played with a manual pipeline, the MPEG video stream is completely corrupted. avplay can play this movie correctly.
The video stream plays fine here with a manual pipeline: gst-launch-1.0 filesrc location=~/Samples/animal_planet.mpg ! tsdemux name=d d. ! queue ! mpegvideoparse ! mpeg2dec ! videoconvert ! autovideosink d. ! queue ! mpegaudioparse ! avdec_mp2float ! pulsesink So that bit was fixed at some point. gst-discover-1.0 and gst-play-1.0 still timeout/hang though.
The streams are detected as LPCM because that's what the "type" identifier says in MPEG-TS. I guess whatever muxed those streams in got it wrong. Bodging the code to assume the actual MP2 format does not fix the hang though, so that's apparently unrelated.
One of the streams is a private stream with a 0x80 type, which is recognized as "DCII" video. This is handled like MPEG video (and a mpegvideoparse element gets plugged in response). However, what goes though doesn't seem to be MPEG video, and mpegvideoparse doesn't push anything out, which causes the pipeline to not preroll because the sink doesn't get a buffer. The IDs seem correct, and DCII was added in https://bugzilla.gnome.org/show_bug.cgi?id=697892. Searching the net shows that DCII is a "proprietary standard" (sic) for encrypted video, though it's not clear if it's actually encrypted here. VLC shows two video tracks, and I can switch between both. The two seem to be the same (unless VLC still displays the first one, the switch is without apparent effect on the output). One possible fix would be to error out in mpegvideoparse if nothing can be parsed within a certain amount of input data. This would cause the pipeline to error out though, which isn't ideal since there's another video stream in there. Another would be to send GAP events, assuming we can determine timing from the buffers without being able to parse them.
I noticed there is a DCII sample linked from https://bugzilla.gnome.org/show_bug.cgi?id=697892, and it plays fine, so it looks like the bug with video in the file above may be another case of bad identifiers by whatever muxed this.
-- 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-bad/issues/124.