[Bug 606382] decodebin: Upstream events (seek,qos) get lost when switching groups/chains

[GStreamer (GNOME Bugzilla)]

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

--- Comment #53 from Duncan Palmer <dpalmer at digisoft.tv> ---
Bummer... I've put in a bit of a hack to try and avoid the issue. Seems to be
working so far. What I try and do is avoid sending a seek in whilst decodebin
is creating a new group as a result of a bitrate switch.

The way I've done this is to add a new signal to decodebin, which I've called
pad-activated. It fires after gst_decode_pad_activate() is called. I can know
how many pads I expect to be 'activated' (it's the same as the number of src
pads created by the tsdemux), so I can know when the new group has been built
by counting the number of times pad-activated has fired.

hlsdemux emits a message to indicate when it's switching to a new playlist.

So, between these two things, I almost have a slightly fragile mechanism of
detecting when the decodebin is busy creating a new decode group. There is a
still a race with hlsdemux - the streaming thread needs to be paused before
sending the seek event so we're not racing with the beginning of a bitrate
switch.

This is a bit horrible, but is the best I can think of, seeing as not allowing
seek isn't an option for me.

Another avenue I haven't investigated it to determine why a seek request can
hang at the moment. If it instead failed cleanly, that's something I could deal
with.

If anyone has any suggestions for a nicer workaround, I'd be grateful ;)

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