GNOME Bugzilla – Bug 733031
regression in position queries when seeking in READY
Last modified: 2018-11-03 12:21:10 UTC
Something changed in gstreamer to break seek in READY again. The pipeline plays from the right pos, but reports position starting from 0 instead of seek-pos. Seeking in ready is important for me, when the user want to play from somewhere in the middle and/or wants to play in a loop. If I send the flushing seek in PAUSED it works, but then I preroll twice - once where gstreamer assumes playback will start at 0 (is open ended and not using the segment flag) and once for the actual segment. I was iterating the pipeline in ready and sending the seek to each source-element (as e.g. bins were dropping the seek as the flags where flushing). Now this is not good anymore. Most likely something change with regard to segment initialization in bins. Now of course seek-in-ready is not officially supported (maybe). So what can we do instead to actually make that use-case work? a) I don't tink we can just add a new seek-flag b) new seek-like event to init the segment? c) ?
For details, see GST_BUG_733031 in https://github.com/Buzztrax/buzztrax/commit/a392519d580cf80fbb91505456c324f2832ed750
Perhaps you could make a check unit test that demonstrates the issue and makes sure it's not broken again once fixed?
Good point, the patch in comment#1 has one, I'll adapt it to gst.
Also note that PiTiVi folks have started working on officially seek-on-read, they might be aware (Thibault and Mathieu). Though they target 1.6.
Note that seeking in READY is used successfully by the adaptive streaming demuxers in combination with souphttpsrc. And there is even a unit test that is testing if basesrc handles it correctly.
Here is a standalone repro: https://github.com/Buzztrax/buzztrax/blob/master/design/gst/seekinready.c gcc -Wall -g seekinready.c -o seekinready `pkg-config gstreamer-1.0 gstreamer-controller-1.0 --cflags --libs` # without adder - it works GST_DEBUG="seekinready:4" ./seekinready 0 0:00:00.033200236 28861 0x26a9f80 INFO seekinready seekinready.c:86:state_changed: state change on the bin: NULL -> READY 0:00:00.033568743 28861 0x26a9f80 INFO seekinready seekinready.c:100:state_changed: ->PLAYING needs async wait 0:00:00.053815663 28861 0x26a9f80 INFO seekinready seekinready.c:86:state_changed: state change on the bin: READY -> PAUSED 0:00:00.053950452 28861 0x26a9f80 INFO seekinready seekinready.c:110:state_changed: playback pos: 0:00:01.000000000 0:00:00.056317329 28861 0x26a9f80 INFO seekinready seekinready.c:86:state_changed: state change on the bin: PAUSED -> PLAYING 0:00:00.056375694 28861 0x26a9f80 INFO seekinready seekinready.c:110:state_changed: playback pos: 0:00:01.000000000 # with adder/audiomixer - it does not GST_DEBUG="seekinready:4" ./seekinready 1 0:00:00.039097527 28879 0xd0bb50 INFO seekinready seekinready.c:86:state_changed: state change on the bin: NULL -> READY 0:00:00.039361277 28879 0xd0bb50 INFO seekinready seekinready.c:100:state_changed: ->PLAYING needs async wait 0:00:00.050805048 28879 0xd0bb50 INFO seekinready seekinready.c:86:state_changed: state change on the bin: READY -> PAUSED 0:00:00.050896443 28879 0xd0bb50 INFO seekinready seekinready.c:110:state_changed: playback pos: 0:00:00.000000000 0:00:00.051113134 28879 0xd0bb50 INFO seekinready seekinready.c:86:state_changed: state change on the bin: PAUSED -> PLAYING 0:00:00.051219153 28879 0xd0bb50 INFO seekinready seekinready.c:110:state_changed: playback pos: 0:00:00.000000000
(In reply to comment #5) > Note that seeking in READY is used successfully by the adaptive streaming > demuxers in combination with souphttpsrc. And there is even a unit test that is > testing if basesrc handles it correctly. right, on a per element basis. This simply look like a bug in adder and audiomixer. Please poke Thibault, he might already have fixed this.
-- 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/62.