shmsink changes from 1.0.10 to 1.1.4

[Olivier Crête]

See below

On Thu, 2013-09-19 at 22:23 +0200, Peter Maersk-Moller wrote:

> On Thu, Sep 19, 2013 at 8:05 PM, Olivier Crête
> <olivier.crete at collabora.com> wrote:
>         > 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.
>         
>         
>         Can't your just halt it directly ? Why do you wait for all of
>         the buffer
>         space to be used up ?
> 
> 
> No I can not halt it directly.
> 
> One of the standard use scenario for shmsink is when you have a
> GStreamer pipeline in one process (process 1) sending buffers to
> another process (process 2) running whatever that process runs. There
> is no easy way for process 2 to tell process 1 to halt unless it keeps
> all the buffers sent by process 1. Please note that halt is bit
> unclear. In my scenario halt means stop sending buffers (and hopefully
> stop using so many ressources, CPU, disk, memmove bandwidth, network
> etc.). It does NOT mean terminate.
> 
> 
> Now if process 2 keeps all the buffers it receive, process 1 will
> eventually reach a state, where it temporarily halts or alternatively
> leaks buffers in a queue. However there is a lag and as we have seen,
> the lag has to  be of a certain size due to the freeze thing we
> discussed in another thread.
> 
> Hmmmmmm that give rise to a problem. Assume you have the following:
> 
> 
>   somesrc ! queue leaky=2 ! shsmsink  ----------- process 2
> 
> 
> Then how can the queue leak if process 2 keeps all the buffers ? In
> that case, somsrc will freeze too. How can that be fixed?

One thing we could do is add properties to limit the size of "queue"
that's inside shmsink by time or bytes or buffers (like the queue
element). I'd certainly be open to something like that.

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