GNOME Bugzilla – Bug 759125
GstBin: async-handling latency handling is decoupled from parent pipeline
Last modified: 2015-12-09 09:15:08 UTC
Since async-handling attempts to emulate a top-level pipeline object, latencies are configured within a GstBin with async-handling=TRUE independently of (a) fixed latencies set by gst_pipeline_set_latency and (b) other negotiated latencies in the pipeline. (a) will make it impossible to use bins with async-handling in a live pipeline where the overall latency has to be controlled by a fixed value (since the bin will ignore it and configure whatever it sees fit) (b) if a bin with async-handling=TRUE has one sink, and the hosting pipeline of such a bin has other sinks (or other bins with sinks), then those sinks won't be in-sync with the one of the bin with async-handling, because potentially each bin might configure a different latency.
Created attachment 316882 [details] [review] bin: Don't do latency handling if async-handling=true Otherwise each bin might have a different latency in the end, causing synchronization problems.
This has the problem that latency configuration would *never* happen unless explicitly triggered for such bins. Maybe for async-handling=true we should post a LATENCY message instead in this place?
Created attachment 316884 [details] [review] bin: Don't do latency handling if async-handling=true Otherwise each bin might have a different latency in the end, causing synchronization problems.
Changing the behaviour to not do the latency calculation here is an API break. I think the best we can do is to post a message if it's not truly the top level bin. Doing the latency queries in the bin and then re-doing later from the main loop should be fine. Ie, s/else if/if/ and leave the toplevel check as-is.
Created attachment 316955 [details] [review] bin: Post a LATENCY message with async-handling=TRUE if the PLAYING state is reached Otherwise each bin might have a different latency in the end, causing synchronization problems. The bin will still first handle latency internally as before, but gives the overall pipeline the opportunity to update the latency of the whole pipeline afterwards.
Good point, what about this one? It's not great but otherwise applications that e.g. don't handle LATENCY messages at all would just stop working properly now.
Review of attachment 316955 [details] [review]: ::: gst/gstbin.c @@ +2673,2 @@ GST_OBJECT_LOCK (bin); + toplevel = GST_OBJECT_PARENT (bin) == NULL; Why change the definition of toplevel?
Unintentional. Will fix that in a bit :)
Created attachment 317009 [details] [review] bin: Post a LATENCY message with async-handling=TRUE if the PLAYING state is reached Otherwise each bin might have a different latency in the end, causing synchronization problems. The bin will still first handle latency internally as before, but gives the overall pipeline the opportunity to update the latency of the whole pipeline afterwards.
Attachment 317009 [details] pushed as 2d427c7 - bin: Post a LATENCY message with async-handling=TRUE if the PLAYING state is reached