<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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 class="moz-cite-prefix">On 07-02-2023 21:45, Kyle Flores wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFzL5Sg+1doEGEUnYpcF48TF6q5QZEa7W5d48J+6Nh-+hZrbbw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">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>
</body>
</html>