[FFmpeg-devel] [PATCH] Add additional FFV1 fate tests

Peter B. pb at das-werkstatt.com
Mon Nov 11 16:38:45 CET 2013


Quoting Michael Niedermayer <michaelni at gmx.at>:
>
> running make -j12 `make fate-list | grep ffv1`
> i get
>
> TEST    ffv1-dec-v3-yuv422p_pass1
> TEST    ffv1-enc-v3-yuv422p_pass2
> TEST    ffv1-dec-v3-yuv444p
> TEST    ffv1-dec-v3-yuv444p10
> TEST    ffv1-dec-v3-yuv444p16
> TEST    ffv1-dec-v3-yuv444p9
> TEST    ffv1-dec-v3-yuva420p10
> TEST    ffv1-dec-v3-yuva420p16
> TEST    ffv1-dec-v3-yuva420p9
> TEST    ffv1-dec-v3-yuva422p10
> make: `fate-ffv1-enc-v3-yuv422p_pass1' is up to date.
> make: `fate-ffv1-enc-v3-yuv444p16' is up to date.
> make: `fate-ffv1-enc-v3-yuv444p9' is up to date.
> make: `fate-ffv1-enc-v3-yuva420p10' is up to date.
> make: `fate-ffv1-enc-v3-yuva420p16' is up to date.
> make: `fate-ffv1-enc-v3-yuva420p9' is up to date.
> make: `fate-ffv1-enc-v3-yuva422p10' is up to date.
> make: `fate-ffv1-enc-v3-yuva422p9' is up to date.
> TEST    ffv1-dec-v3-yuva422p9
> make: `fate-ffv1-enc-v3-yuva422p16' is up to date.
> TEST    ffv1-dec-v3-yuva422p16
> make: `fate-ffv1-enc-v3-yuva444p10' is up to date.
> TEST    ffv1-dec-v3-yuva444p10
> make: `fate-ffv1-enc-v3-yuv422p_pass2' is up to date.
> TEST    ffv1-dec-v3-yuv422p_pass2
> make: `fate-ffv1-enc-v3-yuva444p9' is up to date.
> TEST    ffv1-dec-v3-yuva444p9
> make: `fate-ffv1-enc-v3-yuva444p16' is up to date.
> TEST    ffv1-dec-v3-yuva444p16
> make: `fate-vsynth2-ffv1' is up to date.
> TEST    seek-vsynth2-ffv1
>
> a simpler testcase is
> make fate-ffv1-dec-v1-bff fate-ffv1-enc-v1-bff -j12
> TEST    ffv1-enc-v1-bff
> make: `fate-ffv1-enc-v1-bff' is up to date.
> TEST    ffv1-dec-v1-bff

Hm.
If I interpret this correctly, this is caused by the dependency that a  
decoding-test (fate-ffv1-dec-%) must have its encoding-test  
(fate-ffv1-enc-%) run as prerequisite.
So, the output is - although it looks "unpretty" - correct.
Isn't it?


> about the fuzzed samples, cant tools/trasher be used to generate
> them from some source ffv1 ?
> or is there something special about them that makes this
> disadvantaneous ?


I've used "zzuf" [1] for fuzzing the files, so that the damage *is*  
reproducable and scriptable ;)
The fuzz-ratio used for zzuf in this case is not completely arbitrary  
though, because too much or too little triggered different errors.

I'd love to generate the files, but how to deal with the dependency to  
a fuzzer-tool?


Regards,
Pb


== References:
[1] http://caca.zoy.org/wiki/zzuf



More information about the ffmpeg-devel mailing list