GNOME Bugzilla – Bug 706307
segment: frame stepping returns video to the start + gst_segment_do_seek: assertion 'start <= stop' failed
Last modified: 2018-11-03 12:18:46 UTC
Using totem-3.8.2-1.fc19.x86_64 and gstreamer1-1.0.9-1.fc19.x86_64 on fedora 19. To reproduce: 1) Open the a theora video file, http://v2v.cc/~j/theora_testsuite/320x240.ogg 2) It will start playing, pause it about 1 second in by pressing space 3) press ',' (comma) to step back 1 frame 4) press '.' (full stop) to step forwards one frame Expected result: Steps forward 1 frame Actual result: Video return to start In terminal I see the message (totem:3794): GStreamer-CRITICAL **: gst_segment_do_seek: assertion `start <= stop' failed
Reproduced, but not root caused.
I added some more debug to Totem, and couldn't get it to show any GStreamer warnings, leading me to believe that the problem is with GStreamer. Reassigning.
Confirmed here too with latest git master, it steps sometimes in undeterministic ways and then goes back to the beginning with the gst_segment_do_seek() assertion.
Created attachment 252776 [details] 320x240.ogg Adding test file so it doesn't get lost.
Can one step back with tests/examples/playback/playback-test ? The step number can't be set to negative (well, it can, but pressing step moves it back to 1).
You set rate to -1.0 and then do a step :)
Hmm, I'd tried that and saw: (lt-playback-test:18314): GStreamer-CRITICAL **: gst_event_new_step: assertion `rate > 0.0' failed So I assumed that was "I'm afraid I can't let you do that, Dave". If it's meant to work, then I guess I have something to debug right there :)
k, I found you have to seek with negative rate in the seek section, then come back and step in the step section. That steps back. Using the rate in the step section breaks. I'm going to ignore that for now.
The rate can only be adjusted into the same direction with step events. Reversing the playback direction requires a seek.
(In reply to comment #9) > The rate can only be adjusted into the same direction with step events. > Reversing the playback direction requires a seek. That's already what totem does, fwiw.
Yes, otherwise it would've never worked :) Just mentioned that because it wasn't clear if Vincent knew that. I think it would be a good idea to try if this problem still persists with the latest 1.2 branch or git master. There were a few changes related to reverse playback that might help here.
Just trying now with latest core and -base and it seems to work.
It still throws errors here after you press "." after step 4 as mentioned in comment 0 (in short, pause, period, comma, period): (totem:25371): GStreamer-CRITICAL **: gst_segment_do_seek: assertion 'start <= stop' failed gstreamer1-1.4.2-1.fc21.x86_64 gstreamer1-plugins-base-1.4.2-1.fc21.x86_64 gstreamer1-plugins-good-1.4.2-1.fc21.x86_64
I can see reproduce it. I have to select the seek bar handle for it to blow up. And it looks like the last seek before the assert has both start and stop set to 0. Is that legal ? playsink gstplaysink.c:4707:gst_play_sink_send_event_to_sink:ESC[00m sending event: seek event: 0x56526efbe730, time 99:99:99.999999999, seq-num 369, GstEventSeek, rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, flags=(GstSeekFlags)GST_SEEK_FLAG_FLUSH+GST_SEEK_FLAG_ACCURATE, cur-type=(GstSeekType)GST_SEEK_TYPE_SET, cur=(gint64)0, stop-type=(GstSeekType)GST_SEEK_TYPE_SET, stop=(gint64)0;
Created attachment 332738 [details] [review] reset -1 stop time if seeking without a stop set This fixes it, and seeking after that works fine. However, I can't help but feel it's a bit iffy.
It's very possible that the bug is in the bacon-video-widget. I'd welcome any fixes there, especially as I'm at a bit of a loss why it would occur.
bacon-video-widget looks ok, it's sending seeks with unset stops.
Happens with MP4 and MKVs as well, so let's start with gst_segment_do_seek().
-- 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/gstreamer/issues/42.