Using appsink in an shmsrc pipeline

[Kyle Flores]

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()".


On Wed, Feb 8, 2023 at 12:09 AM Michiel Konstapel <michiel at aanmelder.nl>
wrote:

> Too bad! I guess that even with wait-for-connection=false, shmsink blocks
> if it HAD a client that then disconnects.
>
> 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.
> On 07-02-2023 21:45, Kyle Flores wrote:
>
> Michiel, thanks for your reply.
>
> 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.
>
> 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.
>
> -Kyle
>
> On Mon, Feb 6, 2023 at 12:22 AM Michiel Konstapel <michiel at aanmelder.nl>
> wrote:
>
>> On 02-02-2023 23:36, Kyle Flores via gstreamer-devel wrote:
>> > Hi gst-devel,
>> >
>> > I'm working on an application where a single camera produces a stream
>> > that I'd like multiple clients (such as a display, or network stream)
>> > to use. One such client is an appsink that does some custom work, and
>> > then stops after it has processed a fixed number of buffers. My goal
>> > is to capture a "snapshot" of the camera stream with this, and am
>> > trying to have an appsink pipeline run temporarily and then go back to
>> > null, but I'm open to other ways to accomplish the same thing, as
>> > something's incorrect about mine.
>> >
>> > Here are pipelines descriptions that simulate my configuration, but in
>> > practice run inside an application rather than by gst-launch-1.0.
>> > - "camera" source: videotestsrc is-live=true pattern=ball !
>> > video/x-raw,format=I420,width=640,height=480,framerate=60/1 ! shmsink
>> > name=source_shmsink socket-path=/tmp/shmdemo sync=false
>> > wait-for-connection=false
>> > - display client: shmsrc name=watch_shmsrc socket-path=/tmp/shmdemo
>> > is-live=true !
>> > video/x-raw,format=I420,width=640,height=480,framerate=60/1 !
>> > videoconvert ! autovideosink sync=false
>> > - appsink client: shmsrc name=app_shmsrc socket-path=/tmp/shmdemo
>> > is-live=true !
>> > video/x-raw,format=I420,width=640,height=480,framerate=60/1 ! appsink
>> > sink=false
>> >
>> > All three pipelines are set to playing, I see the display pop up, and
>> > then another thread begins calling pull_sample on the appsink,
>> > reporting each sample that arrives. The thread stops calling
>> > pull_sample after handling a fixed number of samples, then tries to
>> > set the state of the appsink client pipeline to NULL. In the logs I
>> > see the appsink go to NULL, but a short time after this, the display
>> > client also appears to stop. Additionally, I don't see that message
>> > from shmsink that a client disconnected that appears when other shmsrc
>> > clients go to NULL. I tried various combinations of properties on
>> > shmsrc/sink and appsink but haven't seen anything change yet. Ideally,
>> > I'd like the camera source and the display client to continue even
>> > after the appsink client stops, and I don't understand how stopping
>> > the appsink client affects the display client.
>> >
>> > I'd be curious to know if/how I'm misusing appsink or the shmsrc/sink
>> > pair. Specifically for the shm plugins I haven't found much precise
>> > info so my usage has just been based on observing their behavior.
>> > I've seen my app do the same thing on different gst versions so I
>> > don't think this is a bug with the plugins themselves.
>> >
>> > Thanks for any suggestions or pointers.
>>
>> I have never used shmsink but I wonder if it is intended to support
>> multiple sources "connecting" to it. The documentation says "Send data
>> over shared memory to *the* matching source", emphasis mine. Can you
>> have a tee in your camera pipeline and separate shmsinks for each
>> intended consumer? Something like this:
>>
>> videotestsrc is-live=true pattern=ball !
>> video/x-raw,format=I420,width=640,height=480,framerate=60/1 ! tee name=t \
>> t. ! queue ! shmsink name=display_shmsink
>> socket-path=/tmp/shmdemo_display sync=false wait-for-connection=false \
>> t. ! queue ! shmsink name=appsink_shmsink
>> socket-path=/tmp/shmdemo_appsink sync=false wait-for-connection=false
>>
>> And then have each consumer read from its designated socket path.
>>
>> Cheers,
>> Michiel
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20230221/b1696574/attachment-0001.htm>