GNOME Bugzilla – Bug 557161
Wrong time displayed and no seeking with MPEG PS cut from VOB file
Last modified: 2008-12-29 18:34:41 UTC
There are MPEG PS files which were directly cut from the middle of a VOB file without remuxing (e.g. a video clip from a DVD). Because of this, the timestamps in the file don't start at 0 but at the time they originally started on the DVD. When such a file is viewed in Totem, it displays a full progress slider and the time is displayed like this: 1:35:08 / 5:00. Because the progress slider is already at the end, seeking is not possible, not even with the keyboard shortcuts.
Created attachment 120966 [details] [review] remove base_time, start all timestamps at 0 I don't know if this could/should be fixed in Totem, but the attached patch "fixes" mpegdemux in that it removes base_time so that all videos start with timestamp 0. With that patch applied, Totem behaves as it should (and as other players behave) in that it displays the correct time and seeking is possible. I hope changing this behaviour doesn't break other use cases. Does it?
The part where the elapsed time is converted to bytes and where the position is reported are definitely correct and now commited: Patch by: Robin Stocker <robin at nibor dot org> * gst/mpegdemux/gstmpegdemux.c: (gst_flups_demux_src_query): Converting from time to bytes operates on the stream_time, not the SCR timeline. The position reporting should happen in stream_time, not the segment timestamp range. See #557161.
I just updated my checkout and am happy to report that (with revision 1.9 of gstmpegdemux.c) the file now plays fine in Totem, position is correct and seeking works :).
some more patches to make it even better: * gst/mpegdemux/gstmpegdemux.c: (gst_flups_demux_send_data): * gst/mpegdemux/gstmpegdemux.h: The position member in the newsegment event corresponds to the stream_time of the segment start position. * gst/mpegdemux/gstmpegdemux.c: (gst_flups_demux_src_query), (gst_flups_demux_parse_pack_start): Use the adjusted SCR for calculating the mux rate. Don't update the rate estimation after a discont.