[FFmpeg-devel] [PATCH] swscale alpha channel support (was: [RFC] Alpha support)
Cédric Schieli
cschieli
Sun Feb 8 22:21:59 CET 2009
2009/2/8 Michael Niedermayer <michaelni at gmx.at>
> On Sun, Feb 08, 2009 at 06:15:36PM +0100, C?dric Schieli wrote:
>
[...]
> > Yes, it's clearer that way. I can also enclose most of the new code in
> > CONFIG_ALPHA ifs/ifdefs
>
> i prefer the least amount of #if* thus please only do that where it is
> really
> helping speed or object size
> if(CONFIG_ALPHA && ...) is also much prettier than
> #if CONFIG_ALPHA
> if(...)
>
Sadly, adding a --enable-alpha option badly defines ARCH_ALPHA besides
defining CONFIG_ALPHA.
Is CONFIG_ALPHA_CHANNEL ok ? or maybe CONFIG_SWSCALE_ALPHA ?
> > [...]
> > > > @@ -1165,6 +1231,36 @@
> > > > {
> > > > //Note 8280 == DSTW_OFFSET but the preprocessor can't
> handle
> > > that there :(
> > > > case PIX_FMT_RGB32:
> > > > + if(c->alpPixBuf)
> > > > + {
> > > > + __asm__ volatile(
> > > > + "mov %%"REG_b", "ESP_OFFSET"(%5) \n\t"
> > > > + "mov %6, %%"REG_b" \n\t"
> > >
> > > you write into ebx here
> > >
> > > > + "mov %%"REG_b", "U_TEMP"(%5) \n\t"
> > > > + "mov %7, %%"REG_b" \n\t"
> > >
> > > %7 is "m" and could use ebx to address
> > > you can prevent this by putting REG_b on the clobber list though this
> > > will likely not compile with -fPIC
> > >
> > > basically once you changed a register that is not on the output and not
> > > clobber list you no longer can access any "m" nor "r"
> > >
> >
> > Ok. That's my first experiment with inline assembly (and x86 assembly),
> so I
> > have a lot to learn. I thought only "pointer" registers (esp, ebp) could
> be
> > used for "m" referencing.
>
> gcc does use pretty much the full set of valid addressing modes
> that incudes base register + index register * scale constant + offset
> constant
>
>
> >
> > also keep in mind push/pop change esp, and esp can be used in "m" as well
> > > so again no more "m" after push
> > >
> >
> > I've already figured it out myself, painfully...
> >
> > What about the following ?
> >
> > __asm__ volatile(
> > "mov %%"REG_b", "ESP_OFFSET"(%5) \n\t"
> > "mov %6, %%"REG_b" \n\t"
> > "mov %%"REG_b", "U_TEMP"(%5) \n\t"
> > "mov "ESP_OFFSET"(%5), %%"REG_b" \n\t"
> > "mov %7, %%"REG_b" \n\t"
> > "mov %%"REG_b", "V_TEMP"(%5) \n\t"
> > "mov "ESP_OFFSET"(%5), %%"REG_b" \n\t"
> > "mov %4, %%"REG_b" \n\t"
> > "push %%"REG_BP" \n\t"
> > [...]
> > :: "c" (buf0), "d" (buf1), "S" (uvbuf0), "D"
> (uvbuf1),
> > "m" (dest),
> > "a" (&c->redDither), "m" (abuf0), "m" (abuf1)
> > );
>
> i think this is valid but bloated
>
>
> >
> > Or this one ?
> >
> > __asm__ volatile(
> > "mov %%"REG_c", "ESP_OFFSET"(%5) \n\t"
> > "mov %6, %%"REG_c" \n\t"
> > "mov %%"REG_c", "U_TEMP"(%5) \n\t"
> > "mov %7, %%"REG_c" \n\t"
> > "mov %%"REG_a", "V_TEMP"(%5) \n\t"
> > "mov "ESP_OFFSET"(%5), %%"REG_c" \n\t"
> > "mov %%"REG_b", "ESP_OFFSET"(%5) \n\t"
> > "mov %4, %%"REG_b" \n\t"
> > "push %%"REG_BP" \n\t"
> > [...]
> > :: "c" (buf0), "d" (buf1), "S" (uvbuf0), "D"
> (uvbuf1),
> > "m" (dest),
> > "a" (&c->redDither), "m" (abuf0), "m" (abuf1)
> > );
>
> this is a little more risky
s/REG_a/REG_c/
>
>
> is there some special reason why you dont just do
> context->u_temp= (whatever cast it needs) abuf0;
> context->v_temp= (whatever cast it needs) abuf1;
>
> ?
>
No special reason, just a lack of thinking...
I was looking for a solution for %6 and %7 while I should have focused on
abuf0 and abuf1
Regards,
C?dric Schieli
> _______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel at mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sws_use_alpha.patch
Type: text/x-patch
Size: 51125 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090208/ec198a5d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sws_use_alpha_reindent.patch
Type: text/x-patch
Size: 6926 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090208/ec198a5d/attachment-0001.bin>
More information about the ffmpeg-devel
mailing list