[FFmpeg-devel] [PATCH]Support 64bit RGB input
michaelni at gmx.at
Sun Mar 4 05:37:07 CET 2012
On Sat, Mar 03, 2012 at 11:55:44PM +0000, Carl Eugen Hoyos wrote:
> Michael Niedermayer <michaelni <at> gmx.at> writes:
> > On Sat, Mar 03, 2012 at 11:22:13PM +0000, Carl Eugen Hoyos wrote:
> > > Michael Niedermayer <michaelni <at> gmx.at> writes:
> > >
> > > > > > > Attached patch allows to convert 64bit RGB input.
> > > > > >
> > > > > > LGTM
> Applied since I assume the remaining problems are not directly
> 64bit related and conversion to yuva420 works fine.
> > > > > Conversion to RGBA produces (nearly) transparent files
> > > > > because A1 and A2 overflow in yuv2rgb_1_c_template if
> > > > > input is 0xFF, patch follows inlined:
> > > >
> > > > why do they overflow ? is there some incorrect scaling applied
> > > > somewhere ?
> > >
> > > rgba64ToA_c() in input.c reads 65535 (=completely opaque), not
> > > 0xFF as written above, as alpha value for (the lower part of)
> > > the sample from ticket #503, hyscale() in swscale.c calls
> > > c->hyScale() which changes the value to 32767,
> > > yuv2rgb_1_c_template() in output.c calculates A1 and A2
> > > as 0x100 ((32767+64)/2^7) which is then written as "0"
> > > (=completely transparent) if the output is RGBA.
> > something like
> > *255 + 16384 >> 15
> > should work better
> I can confirm that the following inlined patch fixes the problem
> with RGBA64 -> RGBA conversion:
patch ok though i suspect theres alot more to get all the scaling
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
What does censorship reveal? It reveals fear. -- Julian Assange
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel