shmsink changes from 1.0.10 to 1.1.4

[Peter Maersk-Moller]

Hi Josh

Nothing wrong in the receiving end not keeping up with the sending end. In
that case the sender should eventually stop handing out shmbuf upstream,
which I believe it does. Adding a leaky queue upstream will then lead to
dropping buffers, which is predictable. However, what seems to happen is
that shmsink stops sending shmbuf into shm area or stop signal them as sent
over its control pipe, if shm-size is below some currently not understood
threshold, even though the receiving end acknowledge the buffers sent and
the buffers becomes available again.

(To the Gst developers)
BTW, are shmsrc/sink now available for the OS X platform? If not, do you
have any plans for it?

BTW2. A neat feature of shmsink, especially when used by external programs,
would be if it had 2 extra commands added. These should be:

  1) Stop handing out more buffers upstream.
  2) Start handing out more buffers upstream.
  3) Drop all buffers handed out upstream until now, but not yet sent.

A video mixer application like Snowmix could then much better do resource
control. Imagine you have a video mixer with 10-20 gstreamer pipeline
inputs, it can really save a lot of CPU and memmove bandwidth, if the mixer
can temporarily halt pipeline not currently being mixed. Now that is
already possible, but not  before the shmsink has used up all available shm
area. Just a thought. Limiting the amount of unnecessary memmove becomes
important when doing many pipelines of 1920x1080 @60fps.

best regards
Peter MM



Best regards

On Thu, Sep 19, 2013 at 3:05 PM, Josh Doe <josh at joshdoe.com> wrote:

> On Wed, Sep 18, 2013 at 7:26 PM, Peter Maersk-Moller <pmaersk at gmail.com>
> wrote:
> > Hi Olivier
> >
> > Tried your pipelines and it works (ie. not locking). However
> experimented a
> > bit further and ended up with these two pipelines
> >
> > gst-launch-1.0 -v videotestsrc ! $RAWVIDEO ! queue ! identity ! shmsink
> > wait-for-connection=1 socket-path=/tmp/tmpsock shm-size=15000000
> sync=true
> >
> > gst-launch-1.0 shmsrc socket-path=/tmp/tmpsock ! $RAWVIDEO ! queue !
> > fakesink
> >
> > Now if I first define RAWVIDEO as shown below:
> >
> > RAWVIDEO='video/x-raw, format=(string)I420, width=(int)1280,
> > height=(int)720, framerate=(fraction)30/1'
> >
> > Then around 9-10 frames give or take are acknowledged in shmpipe.c before
> > freezing. 15000000 is 10.8 frames in that size in I420.
> >
> > If i increase shm-size to shm-size=20000000, then it will run without
> > freezing. And I can't see why.
>
> I've experienced this as well, having to bump the shm-size up
> significantly to avoid any blocking. I'd think a warning would be
> better than blocking if the receiving end can't keep up with the
> sending side, but I'd have to look at the implementation to see if/how
> this could be done.
>
> -Josh
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130919/e75941e4/attachment-0001.html>