[FFmpeg-devel] evaluating the experimental status of ffv1 version 3

[Dave Rice]

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).

> and slice count on the
> compression rate (especially with 2pass mode)

I have not testing 2 pass mode. Can you provide a working command?

Dave Rice