After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 796620 - playbin2 flush doesn't travel upstream
playbin2 flush doesn't travel upstream
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-06-18 13:26 UTC by James
Modified: 2018-11-03 12:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test app to show problem. Can be built to send flush to appsrc or playbin. (3.77 KB, text/x-csrc)
2018-06-18 13:26 UTC, James
Details

Description James 2018-06-18 13:26:10 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
Comment 1 Nicolas Dufresne (ndufresne) 2018-06-18 13:54:32 UTC
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 ?
Comment 2 James 2018-06-18 14:03:57 UTC
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?
Comment 3 Tim-Philipp Müller 2018-06-18 14:04:37 UTC
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).
Comment 4 James 2018-06-26 16:08:51 UTC
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!
Comment 5 GStreamer system administrator 2018-11-03 12:08:07 UTC
-- 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.