[MPlayer-dev-eng] Re: [MPlayer-users] ssa reader for mplayer using vf_overlay

[Jason Tackaberry]

On Thu, 2005-09-29 at 00:21 -0400, Robert Henney wrote:
> I've run into two possible bugs so far, although it may be more likely
> I'm just doing something wrong.  one is the locking.  after first
> attaching to the shared memory and issuing a "visible=1", the lock byte
> is 0x10.  I set it to 0x20 and make my writes and then issue an
> "invalidate=...", but the lock byte never changes back from 0x20.  I've
> ended up just ignoring the lock byte in my code because otherwise my
> code doesn't seem to ever get access back to the shared memory. 

Yes, I see the problem here.  The overlay state is defined as "dirty"
when any overlay slave command has been issued, this includes toggling
visibility.  vf_overlay won't reset the lock byte (to BUFFER_UNLOCKED)
unless the overlay is dirty AND the the buffer is locked.

What's happening is that by issuing visible=1 up front, you're making
the overlay dirty. But this dirty flag doesn't get reset because the
lock byte is still unlocked.  By setting the lock byte to BUFFER_LOCKED
(0x20) before writing to it, by the time you're finished writing and
issue another slave command, vf_overlay has gone and unlocked the buffer
on you.

One consequence of the above logic is that even if you want to change
the global alpha level of the overlay, you need to set the lockbyte to
BUFFER_LOCKED (0x20) before before the OSD gets updated.  Behaviour like
this is only a bug if I define it to be, but I don't like it, so I think
I'll change it in my next patch.  The lock byte really only makes sense
when the actual bytes of the buffer are being changed.

The solution to your problem should be pretty simple: don't set the lock
byte to BUFFER_LOCKED until after you're done writing to it.  This might
seem counter-intuitive until you realize that the lock/unlock status is
actually from the perspective of your application, not vf_overlay.  So
when the buffer is unlocked, you're allowed to write to it.  When it's
locked, you're not.  So make your changes to the buffer, issue the
invalidate slave command, and then set the buffer to BUFFER_LOCKED
(0x20).  vf_overlay won't read it until it's set to this state.

> The other is that invalidate ranges don't seem to be working perfectly
> right for me.  Currently to get around the problem I'm issuing an
> "invalidate=.." with dimentions that cover the entire overlay memory.

I haven't noticed any problems myself with this.  I've never been
concerned about calculating the invalidate rectangles since I've been
using Evas, and it does that for me.  If there's a bug in this area, I'm
guessing that it has to do with the coordinate translation code.  Is
there any hardware scaling of your video happening?  If so, vf_overlay
will scale the OSD from display size to frame size, and it will
translate all coordinates from one to the other.  You can try using
software scaling in the filter chain to prevent any resizing and see if
it fixes your problem.

Are you specifying a slice?  You probably should be, since it will
improve performance a fair bit when you just want to overlay a line or
two of text.  If so, what you're describing could be a bug there as
well.

Or maybe the bug is in your application, I don't know. :)  If you can
tell me how to reproduce it, I can certainly fix it.

> Oh, also.. not necessarily a problem or a bug, but I have noticed that
> what I write to the overlay appears to get 'softened' with the colors
> looking less than vibrant.

This might happen if the overlay is getting scaled as I described above.
See if this goes away also when you use software scaling before
vf_overlay in the filter chain.  If at the point in the filter chain
vf_overlay appears the frame size and display size are equal, no OSD
scaling will occur and we can rule this out.  If you find that this
helps what you're describing, try editing the vf_overlay.c and change
all occurrences of SWS_FAST_BILINEAR to SWS_BICUBIC and see if that
helps.

Thanks for your feedback.  This is good stuff, and it exposes some areas
that need to be cleaned up in the code, and areas of the documentation
that need to be clarified.

Cheers,
Jason.

P.S.  If you're subscribed to mplayer-dev-eng, you should probably
remove mplayer-users in your reply, since this is arguably off-topic
there.  (Well, at least Attila agrees. :))
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20050929/18c16b89/attachment.pgp>