GNOME Bugzilla – Bug 454228
[mpegdemux] problem with mark shuttleworth clip
Last modified: 2009-03-13 10:18:47 UTC
The bug has been opened on https://bugs.launchpad.net/ubuntu/+source/totem/+bug/124288 "Binary package hint: totem-gstreamer totem-gstreamer can't handle mpeg muxed videos properly. It can play it but can't realy seeck true it. For example you press forvard it should go 1 minut up but will only 1 second up or 3 minuts back. It is 100% reproduceble. You can get mpeg muxed video with: mencoder -ovc lavc -oac lavc -of mpeg -o brocken.mpg ubuntu.ogg ... http://launchpadlibrarian.net/8318196/test.mpg mpeg muxed video (14.6 MiB, video/mpeg)"
Both mplayer and xine seem to have (different) problems with this file, only VLC seems to play it okay-ish.
still not fixed on ubuntu intrepid Totem Video-Player 2.24.2 GStreamer 0.10.21
*** This bug has been marked as a duplicate of 574009 ***
It's not quite the same issue as the duplicate.
The problem on that clip is that first PES packet have a SCR value that looks like if it where the one that should go following the last one in the clip. That causes wong base_time and wrong src_adjustment that is derived in a wrong first timestamp and wrong newsegment. The following patch privdes a workarround for this kind of issue detecting it and skipping the offending PES packet which can be a wrong decision too. https://core.fluendo.com/gstreamer/trac/changeset/1600/trunk/gst-fluendo-mpegdemux It needs to be formally reviewed as I'm not sure if this is the best strategy. With independence of the issue of this ticket, the following pair of lines should be added in any case. demux->scr_rate_n = demux->last_scr_offset - demux->first_scr_offset; demux->scr_rate_d = demux->last_scr - demux->first_scr; The following line cause the packet skipping, this is the most questionable change. demux->sink_segment.last_stop = offset;
Definitely a blocker. Josep, could you commit that patch please ?