<div dir="ltr"><div>Just to follow up on this issue, I did eventually achieve what I wanted, for the appsink client pipeline to stop without jamming the shmsink, by setting the appsink callbacks to an empty object before setting the appsink pipeline to null. My app is written w/ the rust bindings, so that empty callback object was "gst_app::AppSinkCallbacks::builder().build()".</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 8, 2023 at 12:09 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">
<div>
<p><font face="DejaVu Sans">Too bad! I guess that even with
wait-for-connection=false, shmsink blocks if it HAD a client
that then disconnects.</font></p>
<p><font face="DejaVu Sans">Maybe you can set the shmsink to state
NULL and back to PLAYING on the "client-disconnected" signal? So
it goes back into "waiting for a connection, but not blocking
the pipeline". If you have a separate shmsink per client, that
might be viable.</font><br>
</p>
<div>On 07-02-2023 21:45, Kyle Flores wrote:<br>
</div>
<blockquote type="cite">
<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" target="_blank">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>
</blockquote>
</div>
</blockquote></div>