Tee request pads unexpectedly go missing

[GStreamer-devel mailing list]

Hi guys, I am trying to setup a dynamic pipeline and it seems my Tee request
pads unexpectedly go missing sporadically.
Not quite sure how to give the best info as the code base has grown quite
large.

I have a pipeline that works around 80% of the time but every now and then
the pipeline fails with:

"Error received from element Source_file1: Internal data stream error.
Debugging information: gstbasesrc.c(3072): gst_base_src_loop ():
/GstPipeline:gst_pipeline/GstFileSrc:Source_file1:
streaming stopped, reason not-linked (-1)"

I created a dot file when the error callback is called and could see that
some of the tees were not linked and didn't have
src request pads. BUT I also created a dot file where I link the the tees to
the queue and there they are linked.

In the time between where they are linked and become unlinked I do no more
mapping. All I do is write data to the filesrc (fifo) and read the filesink
(also fifo). So there may be delays where there is no data but as far as I
understand this should not effect the tee request pads?

I do have a deinterleave element with sometimes pads but that seems to work
and I have a "pad-added" callback for that and link with gst_pad_link() as
most online posts have suggested. Not sure if deinterleave with sometimes
pads can cause issues?

Any help would be greatly appreciated!

The first image is the pipeline directly after I link the Tees to queues and
what it should look like when streaming:
The second image is the generated when the error-callback is called:

<http://gstreamer-devel.966125.n4.nabble.com/file/t379842/not.png>


<http://gstreamer-devel.966125.n4.nabble.com/file/t379842/error.png>




--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[GStreamer-devel mailing list]

Sorry it seems the images are quite small and I can't edit.

<http://gstreamer-devel.966125.n4.nabble.com/file/t379842/not.png>

<http://gstreamer-devel.966125.n4.nabble.com/file/t379842/error.png>



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[GStreamer-devel mailing list]

Le mardi 04 mai 2021 à 02:44 -0500, Nick_law via gstreamer-devel a écrit :

> Hi guys, I am trying to setup a dynamic pipeline and it seems my Tee request
> pads unexpectedly go missing sporadically.
> Not quite sure how to give the best info as the code base has grown quite
> large.
>
> I have a pipeline that works around 80% of the time but every now and then
> the pipeline fails with:
>
> "Error received from element Source_file1: Internal data stream error.
> Debugging information: gstbasesrc.c(3072): gst_base_src_loop ():
> /GstPipeline:gst_pipeline/GstFileSrc:Source_file1:
> streaming stopped, reason not-linked (-1)"

I'm not sure what is your use case, but perhaps having unlinked tee pad is valid
for you application. If this is the case, consider setting the property "allow-
not-linked" to TRUE.

>
> I created a dot file when the error callback is called and could see that
> some of the tees were not linked and didn't have
> src request pads. BUT I also created a dot file where I link the the tees to
> the queue and there they are linked.
>
> In the time between where they are linked and become unlinked I do no more
> mapping. All I do is write data to the filesrc (fifo) and read the filesink
> (also fifo). So there may be delays where there is no data but as far as I
> understand this should not effect the tee request pads?
>
> I do have a deinterleave element with sometimes pads but that seems to work
> and I have a "pad-added" callback for that and link with gst_pad_link() as
> most online posts have suggested. Not sure if deinterleave with sometimes
> pads can cause issues?
>
> Any help would be greatly appreciated!
>
> The first image is the pipeline directly after I link the Tees to queues and
> what it should look like when streaming:
> The second image is the generated when the error-callback is called:
>
> <http://gstreamer-devel.966125.n4.nabble.com/file/t379842/not.png>
>
>
> <http://gstreamer-devel.966125.n4.nabble.com/file/t379842/error.png>
>
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> 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]

Morning, Yes my use-case requires the tees to be temporarily unlinked while
the de-interleave gets setup and a user selects what channels they would
like to see on the sink end. So I am already doing "allow-
not-linked" for the tees.

But in this case the tees are unexpectedly unlinked (actually 3 of the 4) so
the sink branch still receives data from one tee but not the others which is
why I think gstreamer complains.

Interestingly though I only see this issue on my local PC and not on the
embedded device I work on.

My guess is that on my local PC interrupts are causing issues with gstreamer
while on the embedded device the same is not the case. I do use sleeps now
and then to wait for gstreamer to create pads etc, and my feeling is that
sleeps along with interrupts are breaking things on my local PC.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[GStreamer-devel mailing list]

Le mer. 5 mai 2021 03 h 15, Nick_law via gstreamer-devel <[hidden email]> a écrit :

Morning, Yes my use-case requires the tees to be temporarily unlinked while
the de-interleave gets setup and a user selects what channels they would
like to see on the sink end. So I am already doing "allow-
not-linked" for the tees.

But in this case the tees are unexpectedly unlinked (actually 3 of the 4) so
the sink branch still receives data from one tee but not the others which is
why I think gstreamer complains.

Interestingly though I only see this issue on my local PC and not on the
embedded device I work on.

My guess is that on my local PC interrupts are causing issues with gstreamer
while on the embedded device the same is not the case. I do use sleeps now
and then to wait for gstreamer to create pads etc, and my feeling is that
sleeps along with interrupts are breaking things on my local PC.

Sleeps can only result in a racy outcome. You may test some hypothesis of missing delay with sleeps, but I discourage using that in a product.

--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
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]

Confirmed, removing sleeps from code fixed all my issues.

I now only use sleeps after the pipeline has been completely setup and to
simulate audio rate.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel