Nested pipelines with different running time

[Nicolas Dufresne]

Le lundi 24 octobre 2016 à 11:26 +0200, Andrzej Bartoszek a écrit :
> Let's suppose that we work with such pipeline:
> 
> +-pipeline-------------------------------------+
> |               +-pipeline A-----------------+ |
> |             --| timeshift buffer ---> sink | |
> |            /  +----------------------------+ |
> | live src --                                  |
> |            \ +-pipeline B-----------------+ |
> |             --| timeshift buffer ---> sink | |
> |               +----------------------------+ |
> +----------------------------------------------+
> 
> Currently, both inner pipelines can be in different states (let's 
> consider only PAUSED and PLAYING). Which is good.

This is not expected to be reliable. State should be handled by the
pipeline globally unless you are doing dynamic linking or course.

> 
> However, when one pipeline is paused (after being in PLAYING) and
> then 

There is only 1 pipeline, hence only 1 base_time/start_time here.

> it goes back to PLAYING, it does not change base_time. In this way,
> when 
> inner pipeline is calculating its running time (clock_time -
> base_time), 
> it is equal to running time of outer pipeline. Despite being in
> PAUSED 
> state for some time. Is that a valid behavior?

Yes.

> 
> This is caused by patch to bug #665390 - after this change, only 
> toplevel pipelines perform clock/time management. If described
> behavior 
> is not valid, maybe there is need for some better fix (flag in 
> GstElement, similar to locked state?) allowing for nesting pipelines 
> with different running time?

I don't think we want to support that. Maybe you should describe what
you are trying to do. I'm sure there is a better way to do that.

Nicolas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20161027/e9390a76/attachment.sig>