GNOME Bugzilla – Bug 759730
basesink: seeking issue when async is set to false
Last modified: 2018-11-03 12:31:28 UTC
If I set the async property to false of sink element, seeking does not works well. Forward seeking seems like okey but backward seeking does not work. You can check the issue with gst-play-1.0. # gst-play-1.0 /home/eunhye/content/mp3/piano.mp3 --audiosink="pulsesink async=false" Thank you.
async=false is not a good idea on sinks and all the sinks are async=true by default for a good reason :) That said, there might still be a bug here. But there should be no reason to have async=false in this situation in the first place (what is your reason?).
The issue is that a flushing seek will restart timestamps from 0 but as the sink is async=false it won't lose its state on a flush and, as it doesn't change state to paused and back to playing, the base-time is still the same. This makes all the data up to the last position before the flush be dropped as late.
When we control the pipeline during playing, (like disable audio path / enable audio path / seeking during disable audio path / etc. ) async is set to false not to do async state change and ignore the preroll things. I think we can find a way to control the pipeline with async=true, but I think we need to know and check this issue.
You should consider making it work with async=true as that will prevent lots of other problems too for real sinks. Independent of that, this is a bug that should be solved but not sure how.
-- 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/146.