Usage of tee with queue

[Nicolas Dufresne]

Le lun. 4 mars 2019 19 h 26, David Ing <ding at panopto.com> a écrit :

> For about a year I've been having a problem where my gstreamer pipeline
> would sometimes hang while changing from READY to PAUSED.  Specifically, my
> call to `gst_element_get_state` would return ASYNC (it would time out).  I
> eventually determined that this happens when I have a tee (GstTee) having
> multiple source pads.  There was no problem when the tee had only a single
> source pad.
>
> This felt like a thread deadlock issue related to the tee.  I fixed the
> problem by putting a queue after each of the tee's source pads.  I am not
> sure why this fixes in the problem, but I know that adding queues to a
> pipeline also adds threads behind the scenes.
>
> Is this a known problem with the tee?
>

No and this is well documented.

https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-plugins/html/gstreamer-plugins-tee.html

As tee (just like any demuxer) push from a single thread, you can easily
endup in a situation where a sink waits for another sink before returning
from the chain function. That's because of the preroll, we need all sinks
to have data before we can start playback. This is the only way in a push
back model to avoid skipping data while making sure streams are on sync
from the start.

If queue/thread is a problem for your use case, you may want to try using
async property of sync element. Though, some streams may endup skipping to
catch up with the first sync that reached ready state. Remember though the
GStreamer is a push back model, so each push to each pad of the tee may
block for an arbitrary amount of time, e.g on the clock to do pacing.


_______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190304/65296f59/attachment-0001.html>