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

Michael Niedermayer michaelni at gmx.at
Mon Nov 11 19:46:03 CET 2013


On Mon, Nov 11, 2013 at 04:38:45PM +0100, Peter B. wrote:
> 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?

have you looked at tools/trasher ?

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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131111/ab89c0bd/attachment.asc>


More information about the ffmpeg-devel mailing list