<div dir="ltr"><div>Michiel, thanks for your reply.</div><div><br></div><div>That's a good suggestion, and I gave it a try this morning. Surprisingly the behavior is about the same, with the whole camera pipeline appearing to stop when the pipeline with the appsink goes to null. I checked by placing an "identity" with dump=true after the "videotestsrc", and it stops dumping buffers at the same time.</div><div><br></div><div>With regard to shmsink and multiple clients, I didn't find a doc that mentioned it either. However, aspects of its source code like storing "clients" in a GList and looping over it made me think that it would support more than one client.</div><div><br></div><div>-Kyle<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 6, 2023 at 12:22 AM Michiel Konstapel <<a href="mailto:michiel@aanmelder.nl">michiel@aanmelder.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 02-02-2023 23:36, Kyle Flores via gstreamer-devel wrote:<br>
> Hi gst-devel,<br>
><br>
> I'm working on an application where a single camera produces a stream <br>
> that I'd like multiple clients (such as a display, or network stream) <br>
> to use. One such client is an appsink that does some custom work, and <br>
> then stops after it has processed a fixed number of buffers. My goal <br>
> is to capture a "snapshot" of the camera stream with this, and am <br>
> trying to have an appsink pipeline run temporarily and then go back to <br>
> null, but I'm open to other ways to accomplish the same thing, as <br>
> something's incorrect about mine.<br>
><br>
> Here are pipelines descriptions that simulate my configuration, but in <br>
> practice run inside an application rather than by gst-launch-1.0.<br>
> - "camera" source: videotestsrc is-live=true pattern=ball ! <br>
> video/x-raw,format=I420,width=640,height=480,framerate=60/1 ! shmsink <br>
> name=source_shmsink socket-path=/tmp/shmdemo sync=false <br>
> wait-for-connection=false<br>
> - display client: shmsrc name=watch_shmsrc socket-path=/tmp/shmdemo <br>
> is-live=true ! <br>
> video/x-raw,format=I420,width=640,height=480,framerate=60/1 ! <br>
> videoconvert ! autovideosink sync=false<br>
> - appsink client: shmsrc name=app_shmsrc socket-path=/tmp/shmdemo <br>
> is-live=true ! <br>
> video/x-raw,format=I420,width=640,height=480,framerate=60/1 ! appsink <br>
> sink=false<br>
><br>
> All three pipelines are set to playing, I see the display pop up, and <br>
> then another thread begins calling pull_sample on the appsink, <br>
> reporting each sample that arrives. The thread stops calling <br>
> pull_sample after handling a fixed number of samples, then tries to <br>
> set the state of the appsink client pipeline to NULL. In the logs I <br>
> see the appsink go to NULL, but a short time after this, the display <br>
> client also appears to stop. Additionally, I don't see that message <br>
> from shmsink that a client disconnected that appears when other shmsrc <br>
> clients go to NULL. I tried various combinations of properties on <br>
> shmsrc/sink and appsink but haven't seen anything change yet. Ideally, <br>
> I'd like the camera source and the display client to continue even <br>
> after the appsink client stops, and I don't understand how stopping <br>
> the appsink client affects the display client.<br>
><br>
> I'd be curious to know if/how I'm misusing appsink or the shmsrc/sink <br>
> pair. Specifically for the shm plugins I haven't found much precise <br>
> info so my usage has just been based on observing their behavior.  <br>
> I've seen my app do the same thing on different gst versions so I <br>
> don't think this is a bug with the plugins themselves.<br>
><br>
> Thanks for any suggestions or pointers.<br>
<br>
I have never used shmsink but I wonder if it is intended to support <br>
multiple sources "connecting" to it. The documentation says "Send data <br>
over shared memory to *the* matching source", emphasis mine. Can you <br>
have a tee in your camera pipeline and separate shmsinks for each <br>
intended consumer? Something like this:<br>
<br>
videotestsrc is-live=true pattern=ball ! <br>
video/x-raw,format=I420,width=640,height=480,framerate=60/1 ! tee name=t \<br>
t. ! queue ! shmsink name=display_shmsink <br>
socket-path=/tmp/shmdemo_display sync=false wait-for-connection=false \<br>
t. ! queue ! shmsink name=appsink_shmsink <br>
socket-path=/tmp/shmdemo_appsink sync=false wait-for-connection=false<br>
<br>
And then have each consumer read from its designated socket path.<br>
<br>
Cheers,<br>
Michiel<br>
<br>
</blockquote></div>