[Bug 761815] playbin: changing playbin flags stalls playback

[GStreamer (GNOME Bugzilla)]

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

Edward Hervey <bilboed at bilboed.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bilboed at bilboed.com

--- Comment #15 from Edward Hervey <bilboed at bilboed.com> ---
(sorry for the delay, was re-re-re-reading the playsink code...)

The provided patch is wrong. It goes under the assumption that playsink->flags
is what's actually configured.

playsink->flags actually corresponds to "I would like you to configure yourself
to this combination of flags if possible". Knowing whether a certain "flag" is
active or not depends on a (way too big) list of things:
* Whether a pad was requested for that input
* Whether a chain was created already for a flag
* Whether the input caps for a given pad changed or not
* ...

The design/code hasn't fundamentally changed since 0.10 ... which is the core
issue. But we don't have time to rewrite/refactor/redesign this in the current
timeframe.

What I'm currently looking at is the following:
* set_flags only stores the flags (i.e. don't apply the proposed patch)
* Only make decisions of what to block/activate/unlink in
gst_play_sink_reconfigure().
** The rationale is that by then the various pads should have been requested,
i.e. we have all the information needed to figure out the next steps
** This also means figuring out the various
need_{audio|video|vis|deinterlace|text} variables there (which is currently
done in _do_reconfigure() which is *after* pads are blocked).
** Use the presence (or not) of a chain to determine whether a "flag" is
already active or not (ex: textchain != NULL => text flag was active
previously)
** If a flag is to be removed (ex: audiochain != NULL but need_audio is FALSE)
then just set an idle probe which will unlink/destroy the associated chain
** Only add a blocking probe if really need (i.e. a chain was added)

I'll update once I have more results

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