[FFmpeg-devel] [RFC] Rework swscale-test.

[Michael Niedermayer]

On Fri, Sep 10, 2010 at 10:25:07PM -0300, Ramiro Polla wrote:
> Hi,
> 
> Currently swscale-test runs tests in the following way:
> 
> for each possible input format
>  convert reference from yuva420p to input format
>  for each possible output format
>   for a bunch of up/down/un-scaled horizontal and vertical conversions
>    for each algorithm
>     convert from input format to output format
>     run crc on output
>     convert from output format back to yuva420p
>     run ssd against reference
> 
> This spends most of the time to/from yuva420p. It also repeats many
> conversions to/from yuva420p, so that when one conversion is wrong,
> you get a bunch of lines differing in the output.
> 
> I want to know what you guys think of changing it to run something like:
> 
> for each possible input format
>  convert reference from yuva420p to input format
>  for each possible output format !!! starting from current input format
>   for a bunch of up/down/un-scaled horizontal and vertical conversions
>    for each algorithm
>     convert from input format to output format
>     run crc on output
>     convert from output format back to input format !!!
>     run crc again !!!
>     run ssd against input !!!
> 
> I marked the changes with "!!!". This should still cover all
> conversions but dramatically reduce the time spent on swscale-test
> (from 2m to about 40s). One thing that changes a lot is how SSD should
> be performed. It will no longer be a simple 4 plane yuv SSD, but
> rather compare the data in the input pixel format. This is fairly easy
> to do in 8bpp and 16bpp formats, but somewhat trickier on formats like
> monow, rgb4, rgb555. monow could use a simple xor and count number of
> ones (hey, that's still a sum of squared differences =). For the rest
> (similar to rgb4 and rgb555) av_read_image_line() could be used, but
> then I thought I'd ask here first if this is not a fundamentally
> flawed approach. Do the ssd values still have meaning if they're
> calculated differently for some types of pixel format? Are they for
> some reason less accurate than in yuva420p?
> 
> Comments, suggestions for better ways to test swscale, etc...?

flaws aside i dont think this is a good idea in terms of speed optim
vs complexity

instead of

>     convert from input format to output format
>     run crc on output
>     convert from output format back to yuva420p
>     run ssd against reference

we should do

convert from input format to output format
run crc on output
if(crc differs from expected value) // rare, only if in->out changed
    convert from output format back to yuva420p
    run ssd against reference
else
    print expected ssd value so output is consistent

also if its too slow, w/h can just be cut in half

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB


I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100911/eb49ecba/attachment.pgp>