How to truly decouple pipelines using gst-interpipe ?

[pawan9]

I wanted to create decoupled dynamic pipelines and gst-interpipe has helped me achieve this. My application has 2 pipelines, one video pipeline connects to the video source and decodes the stream and distributes decode data using interpipesink, other video analysis pipeline receives that decoded data using interpipesrc and does some video analysis on that.

In the video pipeline there is reconnection logic for which there is a probe on the rtspsrc element's src pad to observer if data is being received, if data is not received for more than certain threshold(in seconds) then it reconnects. The video pipeline also has a videosink (for debugging purposes).

Q.1 Now when the two pipelines are connected and if i pause the analysis pipeline (need to that for some reason), the video freezes in the videosink and the reconnection logic runs and goes into loop of connecting and reconnecting. If i see the state of video pipeline and its elements they are in playing state. How do i decouple the pipelines such that the state of one doesn't affect another ?

Q.2 If there is some error in the analysis pipeline, the same thing of the video freezing in the videosink and the reconnection logic running in loop mentioned in Q.1 happens but this time there is a upstream reconfigure event on interpipesink of video sink - which i drop by adding a probe, but the situation still happens. How do stop this event ?

Here are the graphs of the pipelines. Video Pipeline

Analysis Pipeline

[fischer]

Please add the pipelines in text format to this issue so we can more easily comment and make suggestions.

[pawan9]

@fischer you can use the below given pipelines for checking. The pipelines are are not exactly the ones given in the graph above but the same issue occurs in these, i have tested it using gstd.

Represents Video pipeline uridecodebin uri="rtsp://127.0.0.1:8555/1" ! tee name=td ! queue ! interpipesink name=src_1 forward-events=false forward-eos=false wait-on-eos=false td. ! queue ! nveglglessink

Represents Analysis Pipeline interpipesrc name=interpipesrc1 listen-to=src_1 is-live=true ! queue ! fakesink

flow

pipeline_create  video  pipeline_string
pipeline_create  analysis  pipeline_string
pipeline_play video
pipeline_play analysis
pipeline_pause analysis

[jcaballeros]

Hi,

Which gst-interpipe and gstd versions, and platform are you using?

I tried to reproduce this issue with the following commands, but I don't see it yet:

pipeline_create src videotestsrc is-live=true ! tee name=t ! queue leaky=downstream max-size-buffers=3 ! interpipesink  name=src_1 sync=false async=false t. ! queue leaky=downstream max-size-buffers=3 ! autovideosink

pipeline_create sink interpipesrc listen-to=src_1 stream-sync=restart-ts ! autovideosink

pipeline_play src
pipeline_play sink

pipeline_pause sink

Can you confirm if you see the issue with these pipes?

Thanks

[pawan9]

@jcaballeros the issue is not produced with the test pipes that you suggested. But is persists with my pipelines.

[jcaballeros]

Hi @pawan9,

I tried to reproduce the issue also with the following pipes on a Jetson TX2, but didn't see it yet:

pipeline_create video videotestsrc is-live=true ! tee name=td ! queue ! interpipesink name=src_1 forward-events=false forward-eos=false wait-on-eos=false td. ! queue ! nveglglessink

pipeline_create analysis interpipesrc name=interpipesrc1 listen-to=src_1 is-live=true ! queue ! fakesink

pipeline_play video
pipeline_play analysis
pipeline_pause analysis

Can you please enable gstd debug and share the logs to see if there is any useful message there? Check the gstd wiki

Thanks

[pawan9]

Hi @jcaballeros

The pipeline that you have mentioned works fine on my system too, but the issue occurs when i use the pipeline that i mentioned earlier (containing uridecodebin pointing to a rtsp video source)

logs for the pipeline in which issue occurs - containing uridecodebin

logs for the pipeline that you mentioned

[lazylazypig]

@pawan9 hi, could you share your rtsp reconnection logic implementation? when the stream stop (maybe caused by the bad network)， an "eos" message is sent to the source pipeline's bus, I choose to ignore the message and do my reconnection logic; but the source pipeline seems not to work anymore, reconnection was not affected.