[FFmpeg-devel] evaluating the experimental status of ffv1 version 3
michaelni at gmx.at
Thu Sep 6 20:49:02 CEST 2012
On Thu, Sep 06, 2012 at 01:44:31PM -0400, Dave Rice wrote:
> Hi Michael,
> On Sep 6, 2012, at 12:01 PM, Michael Niedermayer wrote:
> > On Thu, Sep 06, 2012 at 09:35:44AM +0200, Peter B. wrote:
> >> Quoting David Rice <daverice at mac.com>:
> >>> How close are we to an official ffv1 version 3?
> >> I'm sorry for the massive delay from my side for such an incredible
> >> long time. The test results are excellent so far, and I couldn't
> >> spot any errors, but I did all the tests in my free time, due to
> >> lots of other deadlined-TODOs at work :(
> >> From my point of view, FFv1.3 worked flawless in all my tests. The
> >> only open issues so far on my side are:
> >> 1) Run the whole test-suite under clean conditions with different
> >> input material (VHS, DigiBeta, ...). All tests done so far were
> >> fine, but I've done them with 1 single source video, and while
> >> developing my testscript. So I wouldn't guarantee for what I saw.
> > also see http://media.xiph.org/video/derf/ for more test material
> This is the resource I used for some earlier testing (reported here: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-August/129145.html). For this test I downloaded bridge_far_cif.y4m bridge_close_cif.y4m foreman_cif.y4m bowing_cif.y4m akiyo_cif.y4m stefan_sif.y4m stefan_sif_mono.y4m foreman_qcif.y4m and foreman_qcif_mono.y4m. I then used this shell script to process them all with various versions of ffv1. For each resulting ffv1 encoding it produced the same framemd5 report as the original.
> >> 2) The strange fact that newer versions of ffmpeg produce larger
> >> FFv1 AVIs - even with FFv1.1
> > did you report this previously? did we come up with some conclusion?
> > if not which revission is small and which large ?
> > [...]
> >> @Michael:
> >> What's your opinion? Are there any parts in the code/bitstream which
> >> you think should be examined more closely by testing?
> > the effects of gop size (especially gop=1)
> I would advocate for the use of gop=1 as a default in this case. The effect on total data rate is minimal and adds a high degree of error resilience. If a user was looking to optimize for size rather than resilience they could still increase the gop size (though to slight effect).
I think if i didnt miss any tests then theres still a significnat lack
of tests that where run to have sufficient information on what the
default should be
I think that at a minimum 10 samples that cover every combination of
8bit, >8bit and RGB,4:2:0,4:4:4 should be tested
all tests should be done in 1pass, 2pass, and 2pass with a 1pass from
another file of same type.
all compressed file sizes should be posted here nicely formated in a
table, with average, best and worst differences highlighted
What it is to test, is gop=1 vs gop=300 for FFV1.3
then the whole thing again for slices like 1 vs 4 vs 16 slices
here the material has to span a wide range of resolutions as well
Then we can discuss what defaults should be and what range of
values should be allowed and what recommanditions to write in the
docs for the users.
Or we might try to change ffv1.3 to improve its performance and then
all tests have to be run again.
> > and slice count on the
> > compression rate (especially with 2pass mode)
> I have not testing 2 pass mode. Can you provide a working command?
ffmpeg -i matrixbench_mpeg2.mpg -an -vcodec ffv1 -strict -2 -slices 4 -level 3 -coder 1 -context 1 -pass 1 ffv1.3-p1.avi
ffmpeg -i matrixbench_mpeg2.mpg -an -vcodec ffv1 -strict -2 -slices 4 -level 3 -coder 1 -context 1 -pass 2 ffv1.3-p2.avi
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel