Usage of tee with queue

[David Ing]

Ahh ... I do see the comment on the documentation page now:

One needs to use separate queue elements (or a multiqueue) in each branch
to provide separate threads for each branch. Otherwise a blocked dataflow
in one branch would stall the other branches.


I guess this is not a bug, but it is a part of the documentation that I
overlooked.

Thanks!

On Mon, Mar 4, 2019 at 4:41 PM Nicolas Dufresne <nicolas at ndufresne.ca>
wrote:

>
>
> 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
>
> _______________________________________________
> 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/e8a87935/attachment.html>