[MPlayer-dev-eng] [PATCH] VF Overlay

[Jason Tackaberry]

On Sun, 2010-02-28 at 16:36 +0100, Reimar Döffinger wrote:
> Uh, why don't you do IPC_RMID right after shmat?
> Then the shared memory will be deleted as soon as both MPlayer and application
> detach...

Because then the application won't be able to connect to the shm buffer
after MPlayer starts.

The process works like this:
     1. Controlling app spawns mplayer
     2. Controlling app checks MPlayer's stdout for shm buffer creation
        info.
     3. Controlling app attaches to shm buffer.

If we do IPC_RMID right after shmat(), step 3 will fail.


> Also, the way it is done currently, won't the attach count increase each time
> config() is called? We attach each time config is called but never detach...

We don't call shmat() every config().  We only call shmat() when the shm
segment is created for the first time.

If config() is called again with the same dsize, the shm buffer is
reused.  If it's called with a different dsize, the old shm buffer is
destroyed and a new one is created.  The docs say:

        If the application requires a fixed or predictable overlay image
        size, it can use the scale, expand, and/or dsize filters before
        specifying overlay in the filter chain. Otherwise, the
        application should parse MPlayer's output to determine the
        overlay size. In this case, if the filter is reinitialized (due
        to a loadfile command) and the display size is different than the
        previous file, the previous shared memory segment will be
        destroyed and a new one created.  The shared memory segment will
        also be destroyed when MPlayer exits.