shmsink changes from 1.0.10 to 1.1.4

[Olivier Crête]

On Thu, 2013-09-19 at 09:05 -0400, Josh Doe 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.

The explanation is that I re-enabled zero-copy in shmsink, so that means
that now the buffers are being allocated and sent up the pipeline, so
they end up being used longer so you need more. 

-- 
Olivier Crête
olivier.crete at collabora.com