GNOME Bugzilla – Bug 668684
mpegtsdemux: Certain samples do not show start of video
Last modified: 2013-09-25 22:19:22 UTC
The sample at http://samples.mplayerhq.hu/V-codecs/h264/HD-h264.ts does not show the beginning on the 0.10 branch anymore. It works with latest stable releases. Tested with the following pipeline: gst-launch-0.10 playbin2 uri=file:///tmp/HD-h264.ts video-sink="navseek ! timeoverlay ! autovideosink" On 0.10 branch this is stuck at displaying the frame at timestamp 12:44:55.363 for about 18 seconds before proceeding with video, whereas that frame is not the beginning of it all. With latest stable releases (core/base 0.10.35, good .30, bad .22, ffmpeg 0.10.12) it starts at timestamp 12:44:37.112 instead, is only still for about a second and shows all the ~18 seconds of video that the 0.10 branch completely skips (showing the later frame instead for 18 seconds until timestamps catch up). Made sure this isn't a h264parse related regression (with parsers being plugged now by playbin2), with the following pipeline: gst-launch-0.10 filesrc location=/tmp/HD-h264.ts ! mpegtsdemux name=d ! queue max-size-buffers=0 max-size-time=0 ! ac3parse ! a52dec ! audioconvert ! audioresample ! pulsesink d. ! queue max-size-buffers=0 max-size-time=0 ! ffdec_h264 ! ffmpegcolorspace ! timeoverlay ! ffmpegcolorspace ! xvimagesink Works with last stable releases, but doesn't with 0.10 branch. Adding h264parse before ffdec_h264 makes no difference. Note that in 0.10 branch replacing mpegtsdemux with tsdemux in the long pipeline doesn't work at all (internal data stream error while prerolling), while it does with latest release. master will be tested a bit later, after I'm done pinning down H.264 regressions on the 0.10 branch.
I have the feeling that the stream contains error. With current master or the latest stable release, I get missing frames and errors from ffdec_h264 plus I get the exact same behaviour of missing frames with VLC or ffplay. So are you totally sure that the stream is good? Do you have other streams with the same problem ? Concerning tsdemux, indeed there is another bug that I am now investigating.
Created attachment 207535 [details] GST_DEBUG=2 log showing reported errors from ffdec_h264
Many streams on samples.mplayerhq.hu are problematic or not quite up to ideal spec indeed. It's just something I found while trying to find a public sample for a different problem, which showed problems with git 0.10, while it does show the beginning half video of the sample with latest release versions. So if this isn't a regression in H.264 or MPEG-TS playback, it is at least a regression in being able to make the best possible out of problematic media
Marking as NEW, as it's clearly a bug.
The stream plays with tsdemux after: commit 1182dd0c1ba3e97d197d145dcdb0feeb76f6cd1e Author: Thibault Saunier <thibault.saunier@collabora.com> Date: Wed Feb 15 10:32:17 2012 -0300 tsdemux: Avoid throwing FLOW_ERROR on last PCR processing error In the case of scanning last pcr, errors are not critical, so we keep the stream flowing. Now, the result with tsdemux is exactly the same as with either vlc or mplayer.
The issue is with multiple programs it seems.
Works fine (i.e. the same way as mplayer/vlc) with current master. Closing.