GNOME Bugzilla – Bug 727255
playbin: filter out buffering messages when switching URI and the previous URI is still playing
Last modified: 2014-09-11 14:10:31 UTC
Created attachment 273180 [details] [review] playbin: filter out buffering messages when switching uri and playsink still has buffers to play When switching URI from about-to-finish, playbin starts decoding the new URI and the queue2 inside uridecodebin starts emitting buffering messages immediately. However, the queue(s) inside playsink still have buffers to play and the pipeline doesn't need to pause for buffering, so we should not send those buffering messages up to the application, otherwise there is an audible glitch caused by pausing the pipeline for a very short time. The attached patch attempts to find how much time there is left before the queues inside playsink drain and filters out any buffering messages for all this time. After the end of that time, however, it stops filtering, because if the source is too slow the sink is going to drain and we do want the application to pause the pipeline. Related to https://bugzilla.gnome.org/show_bug.cgi?id=726423
Do you have a sample application that can reproduce the issue? I can see that it can happen but would like to try.
Comment on attachment 273180 [details] [review] playbin: filter out buffering messages when switching uri and playsink still has buffers to play This seems overly complicated. You should be able to detect the group switch from the stream-start message of playsink.
Review of attachment 273180 [details] [review]: As I said, I can see there is an issue here but I don't think using the clock or running time is the best approach to solve it. I'd be more inclined to have a solution that would consider looking if there is a 'stream_changed_pending' on the current group. Pretty much like it is done for the duration query.
Yes, exactly :)
Ping?
Sorry, I missed your comments. I will try to re-work this. The application that I had a problem with was webkitgtk, patched to loop html5 audio by re-setting the same uri in about-to-finish in order to do a gapless loop. I could write a more simple example, though.
(In reply to comment #6) > Sorry, I missed your comments. I will try to re-work this. The application that > I had a problem with was webkitgtk, patched to loop html5 audio by re-setting > the same uri in about-to-finish in order to do a gapless loop. I could write a > more simple example, though. Great, thanks. If you have time to write an example it would be great, it is also possible to try to reproduce it with the recent gst-play application in -base/tools. Also if you could simplify your patch and confirm that it still works would be great! And then we can merge this fix and from the related bug.
Created attachment 285228 [details] [review] playbin: filter out buffering messages when switching uri Updated patch according to comments
Review of attachment 285228 [details] [review]: ::: gst/playback/gstplaybin2.c @@ +2814,3 @@ + GST_DEBUG_OBJECT (playbin, "Storing buffering message from pending group " + "%p %" GST_PTR_FORMAT, group, msg); + group->pending_buffering_msg = msg; gst_message_replace() would make these 3 lines one :)
Created attachment 285264 [details] [review] playbin: filter out buffering messages when switching uri Updated for using gst_message_replace and also made the stream_pending_change variable only be set to true if this is not the first URI to be played. This avoids dropping buffering messages from the first URI and will only drop if it is a chained playback of media. It doesn't seem to have any side effect on the duration query that also uses the stream_pending_change
Review of attachment 285264 [details] [review]: Looks good
commit a2122f04ec6305a1393e73eb8e7fccb291f36ccb Author: George Kiagiadakis <george.kiagiadakis@collabora.com> Date: Fri Mar 28 13:02:54 2014 +0100 playbin: filter out buffering messages when switching uri When switching URI from about-to-finish, playbin starts decoding the new URI and the queue2 inside uridecodebin starts emitting buffering messages immediately. However, the queue(s) inside playsink still have buffers to play and the pipeline doesn't need to pause for buffering, so we should not send those buffering messages up to the application, otherwise there is an audible glitch caused by pausing the pipeline for a very short time. https://bugzilla.gnome.org/show_bug.cgi?id=727255