[FFmpeg-devel] evaluating the experimental status of ffv1 version 3
michaelni at gmx.at
Mon Sep 24 05:37:38 CEST 2012
On Sun, Sep 23, 2012 at 08:16:39PM +0200, Peter B. wrote:
> On 09/20/2012 01:20 PM, Peter B. wrote:
> > Even though the testscript is still running on <= SD material from
> > Delf's collection, I've already ran the framemd5 evaluation and I've
> > found errors!
> > For the slice numbers 24 and 30, some files have broken slices.
> > The error appears with different input videos and sometimes it only
> > appears with GOP>1, but I've found a case where it happens with GOP=1,
> > too:
> I've now reproduced this error with the current git-head
> (N-44711-gf25d53d) on 2 different computers and different Distros
> (Debian 6.0.3/Ubuntu 11.10). Behavior is consistent, so I assume my test
> is correct.
> Can anyone else confirm this?
> Additionally, I've now ran the tests with slice-count iterating from
> 2-70 (Yes, I know that only some of these values are valid, but that was
> the fastest way to check if other slice-count numbers are affected, too)
> The slice-count numbers producing broken slices for
> "bride_close_cif.y4m" are:
> 24, 30 and 56.
should be fixed with the patchset i just posted
please run the full tests with that patchset applied to confirm they
work. Also id like to include this fix in the release so its
important this is done now and not in 2 days or like all the
other tests 6 month after when they where
needed. In the meantime i dont even remember what i needed them for
speaking of this, the latency of the testing done is far FAR very FAR
To be of _any_ use in developing ffv1 tests have to be finished in
less than 24h after i ask for them to be done.
When i developed the ffv1.0 algorithm i tested maybe 100
variants per day not 1 variant in a year like your testing is aiming
seriously, your tests are very usefull (just here you found a quite
serious bug that luckily we can now fix before 1.3 is released)
but at this rate i think this is actually slowing ffv1.3
work down as i could have done the whole test that i need in a
few hours and i still wait for the results from you
also you test much more than i asked for i hope you will sort these
results in a way that is more than a table with 300 columns because
I wouldnt know what to do with that
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel