Usage of tee with queue

[David Ing]

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?

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le lun. 4 mars 2019 19 h 26, David Ing <[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[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 <[hidden email]> wrote:

Le lun. 4 mars 2019 19 h 26, David Ing <[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel