GNOME Bugzilla – Bug 679378
[basesink] Changing playback rate via step events does not work
Last modified: 2012-10-06 11:36:29 UTC
Created attachment 217986 [details] Basic tutorial 13 from the GStreamer SDK The attached code exercises multiple trick modes. For convenience, step events are used to change the playback rate. The first rate change works fine, however, further changes seem to be ignored. E.g., moving from 1x to 2x works, but then you are stuck at 2x. Reverse playback does not work either, but that's filed as a separate bug https://bugzilla.gnome.org/show_bug.cgi?id=679250
There seems to be a bug with the flushing of the current video frame when a flushing step with amount = 0 is done, looking into it now.
commit 48dbfd530a06c7c77af3ae4a67e6e5b1d7b35fb8 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Wed Jul 11 12:37:05 2012 +0200 basesink: handle step end correctly when we have a new step event with a -1 amount, make sure that we follow the regular code path so that the stop_end handler is called as usual. This takes care of flushing the buffer in case of a flushing step and also posts a step end message. See https://bugzilla.gnome.org/show_bug.cgi?id=679378
The problem now is that changing the playback speed with a -1 step doesn't work. The -1 step is to stop the currently active step operation and resume normal playback.
So, either change the playback speed with a seek event or do stepping with small increments. Also flushing steps are most likely not what you want.
Created attachment 219011 [details] Debug log Obtained with GST_DEBUG=2,basesink:5 (a single non-flushing step with amount 0, around second 4)
With these changes the Step Events seem to be completely ignored. They do not change the playback rate not even once, no matter if the amount is set to 0 or -1, or if the Step is flushing or not. Debug log attached.
(In reply to comment #6) > With these changes the Step Events seem to be completely ignored. They do not > change the playback rate not even once, no matter if the amount is set to 0 or > -1, or if the Step is flushing or not. It does change the playback rate but since the duration of the step is 0 (the same as -1) the step completes immediately and then it continues normal playback. > Debug log attached.
So, the real bug here is fixed and everything else is just misunderstanding of how the step events work. Nonetheless it makes sense to change the meaning of -1 as amount in 0.11 to mean "step forever". Currently 0 and -1 have the same meaning.
Untested: commit 5360ba56f7fa552865a42ed12845e748663ae6db Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Wed Jul 18 11:17:23 2012 +0200 basesink: handle -1 step amounts Define a 0 and -1 step amount. They used to almost do the same thing but now, 0 cancels/stops the current step and -1 keeps on stepping until the end of the segment. See https://bugzilla.gnome.org/show_bug.cgi?id=679378