Duplicate seek events to appsrc #1404
Closed
Comments
http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/design/part-seeking.txt hints at the solution. I've just tested changing our code to send the seek event to the queue we have in front of the output bin. Sending it to the playbin, audio-sink bin or the outputs bin won't work as the default seek handling of a bin is to forward to all sinks. So using the queue as the spot to inject the event is the way to go. |
Though this idea might not work as it only seems to play a few seconds of the next song and then goes quiet for and extend time before coming back again. :/ |
Correct fix might be an event probe on the src pad of the appsrc and rejecting all but the first or last seek event. We'll see tomorrow. |
jodal
added a commit
that referenced
this issue
Feb 3, 2016
audio: Prevent double seeks in appsrc (fixes: #1404)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently we get one seek data event per output in the tee. This can be easily verified by commenting out the dummy fakesink in the tee, or adding extra ones. The end result of this is that mopidy-spotify seeking isn't smooth, as we start playing from the seeked position and then do it again shortly afterwards.
Proper fix for this, assuming multiple outputs is still a goal is to have mopidy de-dupe this, or to do it ourselves via the new segment events getting to the tee.
The text was updated successfully, but these errors were encountered: