GNOME Bugzilla – Bug 594812
[mpegpsdemux] Seeking broken for MPEG PS cut from VOB file
Last modified: 2011-09-30 16:49:14 UTC
I'm sorry to report this again, but I have many MPEG PS files for which seeking is broken. They were apparently all cut directly (without remuxing) from a VOB file and have some weird time codes. It's now broken like this: Open the video in totem and it starts to play. Then seek to the middle of the file. That makes the CPU and the disk activity go to the top for about 10 seconds. Then the time indication in totem is something like "1:19:14 / 4:11" and it plays for a few seconds and then it freezes. MPlayer and VLC both handle them fine. It was reported before in bug #557161 and bug #574009, and it worked for a time, but now it doesn't any more. I will provide the link to a sample file by e-mail.
Can you git bisect to find the commit that breaks this? Or give the last commit you know where it worked and the first where it broke?
It worked before commit c8eb591688cc64c3da68ef34729b2720fd94a99b "Add pull mode to mpegpsdemux". I think it remained broken since then.
Ok, thanks. Josep, any idea why exactly this is broken now? :)
I sent both of you a link to a sample file which is broken. Hope that helps.
I've just tried with the seek example + git gstreamer and the issue is not reproducible here. GST_DEBUG=flu*:5 seek 15 "filesrc location=seeking-broken.vob ! mpegpsdemux ! flumpeg2vdec ! queue ! xvimagesink" 2>l.txt Here is a relevant part of log in the video decoder to show the time required to do seek. 0:00:07.262195906 7688 0x23924d0 DEBUG flumpeg2vdec flumpeg2vdec.c:1272:gst_flumpeg2vdec_src_event:<flumpeg2vdec0> seek - trying directly upstream first 0:00:07.262224499 7688 0x23924d0 DEBUG flumpeg2vdec flumpeg2vdec.c:940:gst_flumpeg2vdec_sink_event:<flumpeg2vdec0> handling event type flush-start 0:00:07.798722424 7688 0x23924d0 DEBUG flumpeg2vdec flumpeg2vdec.c:940:gst_flumpeg2vdec_sink_event:<flumpeg2vdec0> handling event type flush-stop 0:00:07.798892867 7688 0x2982f50 DEBUG flumpeg2vdec flumpeg2vdec.c:940:gst_flumpeg2vdec_sink_event:<flumpeg2vdec0> handling event type newsegment 0:00:07.798930948 7688 0x2982f50 DEBUG flumpeg2vdec flumpeg2vdec.c:969:gst_flumpeg2vdec_sink_event:<flumpeg2vdec0> new segment, format=3, base=94840102773, start = 4778519102773, end=-1 0:00:07.798942617 7688 0x2982f50 DEBUG flumpeg2vdec flumpeg2vdec.c:1003:gst_flumpeg2vdec_sink_event:<flumpeg2vdec0> received new segment time segment start=1:19:38.519102773, stop=99:99:99.999999999, last_stop=1:19:38.519 0:00:07.798981709 7688 0x2982f50 LOG flumpeg2vdec flumpeg2vdec.c:846:gst_flumpeg2vdec_sink_chain:<flumpeg2vdec0> incoming buffer timestamp 99:99:99.999999999 duration 99:99:99.999999999 offset 18446744073709551615 keyfr 0:00:07.798993772 7688 0x2982f50 DEBUG flumpeg2vdec flumpeg2vdec.c:849:gst_flumpeg2vdec_sink_chain:<flumpeg2vdec0> this buffer has a DISCONT flag, flushing 0:00:07.799113457 7688 0x2982f50 LOG flumpeg2vdec flumpeg2vdec.c:846:gst_flumpeg2vdec_sink_chain:<flumpeg2vdec0> incoming buffer timestamp 1:19:39.121366666 duration 99:99:99.999999999 offset 18446744073709551615 keyfra I've commited several fixes related to performance some long ago, maybe those fixed the issue. Are you using those changes?
I used a relatively recent gst* from git. But I have now distcleaned and updated everything and will try it again in the evening. Have you also tried seeking in totem?
Ok, seeking is still broken with gst* from git master of today. Can you tell me with which command you got the above? I don't have "seek" here. Neither do I have the flumpeg2vdec element. When I do the following: gst-launch filesrc location=seeking-broken.vob ! mpegpsdemux ! navseek ! mpeg2dec ! queue ! xvimagesink and seek once by pressing the right arrow, it takes about 1 second to seek a little bit.
The seek example is at gst-plugins-base/test/examples/seek [1]. Certainly there's something broken somewhere, I suspect mpeg2dec because in demuxer side seeking looks correct. The following case doesn't work seek 15 "filesrc location=seeking-broken.vob ! flupsdemux ! mpeg2dec ! queue ! xvimagesink" The following case seems to work better seek 15 "filesrc location=seeking-broken.vob ! flupsdemux ! mpegvideoparser ! mpeg2dec ! queue ! xvimagesink" Sebastian, do you have any idea on why it could fail ? [1] http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/tests/examples/seek
I think this commit should fix it, please reopen if not: commit 50d08ce73286348e33fbd8cf0a5cd054848be56c Author: Jan Schmidt <thaytan@noraisin.net> Date: Tue Sep 15 23:32:06 2009 +0100 mpegdemux: Handle base_time when sending segment updates. Don't send bogus new segment update events when the stream doesn't start at 0. Fixes broken seeking in some files. Fixes: #594812
It's much better with this commit. But it still takes longer than other files and for example pulling the seek knob with the mouse in totem (direct seeking) is unusable because it's still too slow. Jan, I also sent you the link now.
There's still a difference between Ogg seeking and mpeg-ts seeking. This is the first new_segment, and a new_segment after a seek in totem, for an Ogg and TS. Note that accum is different. 0:00:01.438677550 4008 0x90c78f0 ERROR basevideo gstbasevideodecoder.c:227:gst_base_video_decoder_sink_event: new segment time segment start=1:00:00.000000000, stop=1:00:59.933333333, last_stop=1:00:00.000000000, duration=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000, accum=0:00:00.000000000 0:00:04.172007896 4008 0x90c78f0 ERROR basevideo gstbasevideodecoder.c:227:gst_base_video_decoder_sink_event: new segment time segment start=1:00:15.670000000, stop=1:00:59.933333333, last_stop=1:00:15.670000000, duration=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:15.670000000, accum=0:00:59.933333333 0:00:01.361036266 4027 0x99a3d40 ERROR basevideo gstbasevideodecoder.c:227:gst_base_video_decoder_sink_event: new segment time segment start=17:10:35.286066666, stop=99:99:99.999999999, last_stop=17:10:35.286066666, duration=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000, accum=0:00:00.000000000 0:00:05.202696720 4027 0x99a3d40 ERROR basevideo gstbasevideodecoder.c:227:gst_base_video_decoder_sink_event: new segment time segment start=17:12:29.786066666, stop=17:15:48.606167531, last_stop=17:12:29.786066666, duration=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:01:54.500000000, accum=0:00:00.000000000
Actually, this looks more like the problem. The segment start is 17:12:37, yet the first timestamp is 17:14:27. I'm seeking to about 2 minutes into the file, which starts at 17:10:35. 0:00:03.662600996 5197 0xb3d00af8 ERROR basevideo gstbasevideodecoder.c:227:gst_base_video_decoder_sink_event: new segment time segment start=17:12:37.452066200, stop=17:15:48.606167531, last_stop=17:12:37.452066200, duration=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:02:02.165999534, accum=0:00:00.000000000 0:00:03.662675727 5197 0xb3d00af8 ERROR basevideo gstbasevideodecoder.c:615:gst_base_video_decoder_chain: timestamp 99:99:99.999999999 0:00:03.662948737 5197 0xb3d00af8 ERROR basevideo gstbasevideodecoder.c:615:gst_base_video_decoder_chain: timestamp 99:99:99.999999999 0:00:03.662968991 5197 0xb3d00af8 ERROR basevideo gstbasevideodecoder.c:615:gst_base_video_decoder_chain: timestamp 17:14:27.227188888 0:00:03.664916375 5197 0xb3d00af8 ERROR basevideo gstbasevideodecoder.c:615:gst_base_video_decoder_chain: timestamp 99:99:99.999999999 0:00:03.664973016 5197 0xb3d00af8 ERROR basevideo gstbasevideodecoder.c:615:gst_base_video_decoder_chain: timestamp 17:14:27.268855555 0:00:03.664989638 5197 0xb3d00af8 ERROR basevideo gstbasevideodecoder.c:615:gst_base_video_decoder_chain: timestamp 99:99:99.999999999 0:00:03.665013105 5197 0xb3d00af8 ERROR basevideo gstbasevideodecoder.c:615:gst_base_video_decoder_chain: timestamp 17:14:27.435522222
Um, never mind me. I'm commenting on the wrong bug.
Jan told me that the remaining sluggishness is an artefact of attempting to accurately seek in MPEG files. Unfortunately, we still do much worse than VLC and MPlayer in this respect, but I'll close this bug anyway.
May be fixed for good now with the resolution of bug 659485.