[Bug 758928] play https mp4 gst blocking

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=758928

--- Comment #23 from Thiago Sousa Santos <thiagossantos at gmail.com> ---
Some notes on what is happening:

1) playsink blocks all pads until all of them have data
2) dvbmediasink elements accept non-raw data so decodebin never needs decoders
or parsers in this scenario
3) flush-stop triggers resending of sticky events (stream-start is resent)
4) This sample file has mdat|moov (in this order) so qtdemux does seeks to read
the moov before getting to the mdat
5) flush-stop handling in queues is synchronous (happens on upstream thread)

When you use sinks that accept raw data it will have decoders and parsers that
need some data before they push caps and buffers. So decodebin won't expose
pads until some data actually flows. In this case, qtdemux can do its seeks
"safely" as all the events are confined to decodebin's internals.

When using dvbmediasink elements as sinks they take non-raw data and qtdemux's
pads are exposed directly from decodebin and it is linked to downstream. This
makes the flush-stop from qtdemux's seek travel until playsink where the
handling makes a stream-start reach the playsink pad block and stalls as
everything is happening from a single thread.

Still thinking on how to fix this, other than having qtdemux not allow its
seek's flush travel downstream.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.