GNOME Bugzilla – Bug 796620
playbin2 flush doesn't travel upstream
Last modified: 2018-11-03 12:08:07 UTC
Created attachment 372712 [details] test app to show problem. Can be built to send flush to appsrc or playbin. I have an application that constructs a playbin2 based pipeline. It uses an appsrc element to write TS muxed data in push mode. The application has a need to flush the pipeline when starting playback of a new stream and it does this by sending a flush-start, flush-stop pair of events to the playbin. We've recently updated from GStreamer 1.4.x to 1.8.3 and found that the appsrc elements aren't receiving the flush events when the playbin is flushed (they did when using 1.4). The particular change that caused this behaviour was introduced in 1.6.1 by https://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/gst/playback/gstplaybin2.c?h=1.6&id=cfb6d6e7b44fedddeb6aa6f0fdb1189541d3d035. The GStreamer examples and documentation that I've seen state that flush events should be sent to the pipeline and my application has followed this advice. Since this change has been in place for so long I find it hard to believe that this is a bug so I'm looking for advice on whether the application behaviour is correct. I've attempted to reproduce the logic in a test application (see attached) and can confirm it's broken on 1.8.3 and git master. The test app builds a pipeline, pushes a large amount of data, then after 1 second issues a flush. If the flush is sent to the appsrc then all is well, however if it's sent to the playbin then it doesn't travel to the appsrc. Should playbin/pipeline send the events upstream to the appsrc in push-mode? or should my app always have been sending the flush events to the appsrc? Thanks
Flush events (flush-start and flush-stop) are downstream event (end at sink). Did you confuse upstream and downstream, or is this bug report invalid ?
TBH I'm not sure. The app currently sends the flush-start, flush-stop events to the pipeline and with gstreamer 1.4 this sent the flush events to all elements in the pipeline (including the appsrc). As of 1.6.1 this doesn't happen. So I'm confused as to whether this is a bug in my app code that worked on 1.4 but shouldn't have, or is this a bug in the playbin2 code?
Flush events can go in both directions. A demuxer's seek handler will (when operating in pull mode) typically send flush upstream and downstream, for example, to unblock the streaming thread (which might be stuck in a pull/read in the source or in a push downstream).
I'm now also seeing similar behaviour with SEEK events. Issuing a seek event to the pipeline (or indeed to a sink element) seems to skip the decoder and go straight to the upstream demux. I'm very confused as to what the correct behaviour should be so any clarification would be helpful. Or, is there test code that validates the event traversal of the pipeline? I'd like to compare known working code with our application. Thanks!
-- 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/gst-plugins-base/issues/463.