[MPlayer-dev-eng] [PATCH] SwScaler YV12 to BGR32 having zeroed alpha

[Jason Tackaberry]

On Sun, 2005-05-29 at 23:02 +0200, Michael Niedermayer wrote:
> if it would be clean, wont cause any slowdown and is preferably optional then 
> yes,

Well there are a couple extra additions and shifts in C case, and a
pcmpeqb instead of pxor in the MMX case, so it will naturally be slower,
but I'd be shocked if it was measurable. :)

I can't imagine a case where alpha being initialized to 0xFF would break
anything.  Is there any existing code anywhere that relies on it being
0x00?  If there is, then I suppose it would have to be optional, and
disabled by default.  But it would complicate the code quite a bit over
what I'm attaching to this email.  Well, if that's the only way it would
get merged, then I'll implement it that way.  But I think setting alpha
the alpha to fully opaque is a more sane default.

At any rate, the attached patch makes the alpha bytes 0xFF in SwScaler
for unscaled and scaled conversions to BGR32 or RGB32 in both C and MMX
cases.  All cases have been tested and work.  The only thing I'm not
sure about in terms of cleanliness is the unscaled C case (yuv2rgb.c).
The same macros are used for both 32bpp and 16bpp cases (DST1(i) and
DST2(i)).  I'm adding (255 << 24) to the values.  This isn't really any
problem since for the 16bpp case it will just overflow and not affect
the value.  But perhaps a better solution would be to add another
argument to the macro that's used for the 32bpp case.  I think it's a
matter of taste, but let me know.

>  btw just curious, what are you doing that needs the alpha values?

Ok, since you asked ... :)

You may or may not have heard of MeBox (http://sault.org/mebox) which is
a HTPC project I'm working on that uses mplayer.  (It's mentioned on
mplayer's site under the related projects page.)  MeBox is, at the
moment, a collection of random code that doesn't do anything much.  Some
of this code is for mplayer.  I'm also in regular contact with Freevo
developers and am making sure that they can benefit from my work as much
as possible.

I've written a filter that outputs the video to a BGRA shared memory
buffer, optionally scaling it.  With Evas, the canvas library written
for the Enlightenment project, I can create a canvas, create an image
object, and map the shared BGRA buffer to that image object.  When
mplayer puts a new frame into the buffer, the canvas gets updated.  When
using evas's opengl canvas, it's quite feasible to run many videos on
one canvas, all alpha blended and scaled variously.  Here is a
screenshot:

   http://sault.org/~tack/vf_outbuf.jpg

Evas image objects use per-pixel alpha that can be multiplied with the
object's "global" alpha.  So when mplayer writes to that buffer (using
SwScaler) and currently has all alpha values 0, the canvas image is
naturally fully transparent (i.e. invisible).  I need to manually set
all those bytes to 0xff.  I have been doing this in the filter's code,
but I really think it belongs in SwScaler.

This accomplishes similar goals to Emotion, which provides a video
canvas object, except that instead of using Xine, I can use MPlayer
controlled in slave mode.  You're probably thinking that outbuf should
be a video-out rather than a filter, but for MeBox I require the ability
to render to the buffer and Xv at once, or toggle between them.  (This
is a pretty obscure requirement, but it's the reason I wrote this as a
filter instead of vo.)

I have been working on another filter in parallel, called vf_osd, which
stems from my bmovl2 filter (that never did make it into mplayer).
vf_osd provides a BGRA buffer that can be drawn to (again via shmem) and
it works much like the OSD in the Hauppauge PVR-350 in terms of
functionality and features.  I plan to submit vf_osd very soon as it's
almost done and cleaned up.

Using one mplayer instance to draw the video to a buffer using
vf_outbuf, and another process that uses Evas to create an in-memory
canvas (which is BGRA), and another mplayer process that uses vf_osd and
maps the OSD buffer to the canvas's memory, I can play a movie over
another movie.  This screenshot demonstrates:

   http://sault.org/~tack/vf_osd.jpg

Monsters, Inc. is being played by one MPlayer using -vo xv.  (Actually
-vo x11 in this case, so I could take the screenshot.)  It uses vf_osd,
which another process using evas uses as the memory for a buffer canvas.
Another MPlayer is spawned running X-Men 2 and uses vf_outbuf to draw
each frame to the memory of a canvas image object, which gets rendered
to the canvas's buffer, which ultimately gets updated to the other
mplayer processes's OSD.  Clear as mud?

Now, there are better ways to get the same visual effect (like use two
mplayers both using vf_outbuf which draw to a canvas that does the
actual display), but this was a nice stress-test for vf_osd.

Maybe that explains it.  Or maybe it just raises more questions.  I'll
be submitting more code this week for vf_osd (and probably vf_outbuf,
though that might be a tougher sell).  It would be nice to see vf_osd
merged because Freevo will undoubtedly use it as well.

> me looks ... doesnt see gdb output ... "bugreport" closed

Yes yes, fair enough.  I'll see if I can get a stack trace.  (The x86_64
system isn't mine so I only have access to it occasionally.)

Anyway, please review the patch and let me know of any necessary
changes.

Cheers,
Jason.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postproc-2005-05-29.patch
Type: text/x-patch
Size: 2524 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20050529/2027cbbf/attachment.bin>