[MPlayer-dev-eng] [PATCH] vf_osd take two

[Jason Tackaberry]

On Wed, 2005-09-07 at 00:22 +0200, Michael Niedermayer wrote:
> if i understand that correctly the app sends BGRA to vf_osd which converts it
> to YV12A, isnt it (optionally) possible to send YV12A directly?

My vf_bmovl2 patch (which vf_osd deprecates) supported this, but I
removed it since I didn't think there would be a very big need for it,
particularly because YV12A isn't really a recognized format (and in my
implementation there are 5 planes: luma, 2 chroma, luma alpha and chroma
alpha).  Theoretically it's rather straightforward to add.  If you think
that's a feature people would care about, I can add that.

> i dont want to be picky but which version? :) ==v2 or >=v2?

I don't think that's being picky.  It's an oversight on my part.
Although I'm inclined to stipulate >=v2, is there a preference among
mplayer developers?

> hmm, does doxygen support such comments for several variables at once?

Now that you mention it, I don't think it does.

> i really think this should be split in a few comments+variables, even if
> doxygen supports this which iam not sure if it does

Agreed.  I will make that change.

> i still dislike these globals somehow but iam not objecting against applying
> it if the other devels think its ok

The problem I face is that the OSD buffers must persist between
loadfiles and loops.  As a result, the buffer can't be blindly allocated
on every call to vf_config.  It needs some way to determine if this is
the same filter being reinitialized on a new file.  The only way that
was evident to me was to keep some global state.

> [...]
> > +            : "=r" (dst),
> > +              "=r" (src),
> > +              "=r" (osd),
> > +              "=r" (alpha)
> > +            : "m" (c) 
> > +            : "%ecx", "memory");
> 
> %1 is a output operand so you can read & write to it but its initial value
> doesnt have to be src
> "+r" (src) would be input+output
> "=r"(src) : "1"(src) should work too

I have to plead ignorance here.  Why are these alternatives better than
what I have above?  I don't doubt that they are, just that I don't know
why. :)

Thanks,
Jason.
-------------- 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/20050906/1a5ff3d4/attachment.pgp>