[FFmpeg-cvslog] r15305 - in trunk: Makefile tests/ffmpeg.regression.ref tests/libav.regression.ref tests/regression.sh tests/rotozoom.regression.ref tests/seek.regression.ref

[Michael Niedermayer]

On Sat, Sep 13, 2008 at 11:59:30AM -0700, Mike Melanson wrote:
> Michael Niedermayer wrote:
> > On Sat, Sep 13, 2008 at 10:35:22AM -0700, Mike Melanson wrote:
> >> Michael Niedermayer wrote:
> >>> On Fri, Sep 12, 2008 at 09:18:15PM -0700, Mike Melanson wrote:
> >>>> Mike Melanson wrote:
> >>>>> michael wrote:
> >>>>>> Author: michael
> >>>>>> Date: Sat Sep 13 05:49:54 2008
> >>>>>> New Revision: 15305
> >>>>>>
> >>>>>> Log:
> >>>>>> Switch regression tests to swscale.
> >>>>>> Plain C, x86-32 and -64 have been tested and should work, other
> >>>>>> archs that had asm optmizations in swscale likely will need some fixes
> >>>>>> to either fallback to C if SWS_BITEXACT is set or make the asm match C.
> >>>>>> This also disables the PAL8 test as neither swscale or the old scaler
> >>>>>> really support PAL8 output, imgconvert supported a fixed 666 palette
> >>>>>> as output and swscale supports fixed 884 and 422.
> >>>>> Do I need to change anything in FATE?
> >>>> Judging by the build results so far, I guess I need to update all of the 
> >>>> build configurations to build with swscale.
> >>> You also have to update all tests that involve scaling or colorspace
> >>> convertion.
> >>> Also you must pass at least -sws_flags +bitexact to the tests that do.
> >> Are you sure about this? Because
> >>
> >> ffmpeg -i full9iron-partial.mov -pix_fmt rgb24 -f framecrc -
> >>
> >> and
> >>
> >> ffmpeg -i full9iron-partial.mov -sws_flags +bitexact -pix_fmt rgb24 -f 
> >> framecrc -
> >>
> >> and
> >>
> >> ffmpeg -sws_flags +bitexact -i full9iron-partial.mov -pix_fmt rgb24 -f 
> >> framecrc -
> >>
> >> produce identical output. Output that varies from x86_32 to PPC.
> >>
> >> Am I missing something?
> > 
> > sws on ppc does not support bitexact because the flag did not exist when
> > the ppc code was written and i dont have a ppc so could not test which
> > parts of the ppc code where bit identical to C.
> > Its the same reason why the regression tests fail on ppc ATM.
> > 
> > It should pass on ppc when altivec is disabled, if not then the problem
> > may be elsewhere.
> 
> Then the problem must be elsewhere. --disable-altivec doesn't do change 
> the output.

does the output look ok or are there any red<->blue issues?
also, even though i do not think it is the issue, you did try make distclean?


> 
> Also, would you expect -sws_flags +bitexact to alter the output? Because 
> it doesn't, at least not with that 8BPS samples on x86_32.

i would after RTFS

does the altivec vs x86 difference also persist with yuv420p
and yuv444p output?

also when all else fails do any of the other scaler algos
(-sws_flags area, -sws_flags neigbor, ...) make the difference disapear?


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20080914/ff755cf3/attachment.pgp>