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

[Peter B.]

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:

== Steps to reproduce it:
1) Download the input video "bridge_close_cif.y4m" [1]
2) Encode to FFv1.3 using the following parameters:
   *) level=3 context=0 coder=0 g=1 threads=1
   *) slices=24,30 slicecrc=0,1

3) Here is a short BASH script used to reproduce the problem case:
//------------
#!/bin/bash

FFMPEG="/path/to/ffmpeg"
VIDEO_IN="bridge_close_cif.y4m"

FFV1_SLICES="24 30"
FFV1_SLICECRCS="0 1"

for FFV1_SLICE in $FFV1_SLICES; do
     for FFV1_SLICECRC in $FFV1_SLICECRCS; do
         VIDEO_OUT=$(printf "%s-%ds_%dcrc.avi" "$VIDEO_IN" $FFV1_SLICE  
$FFV1_SLICECRC)
         $FFMPEG -i "$VIDEO_IN" -an -vcodec ffv1 -level 3 -context 0  
-coder 0 -g 1 -threads 1 -strict experimental -slices $FFV1_SLICE  
-slicecrc $FFV1_SLICECRC "$VIDEO_OUT"

         $FFMPEG -i "$VIDEO_OUT" -an -f framemd5 "$VIDEO_OUT.framemd5"
     done
done
//------------

4) The results of this script are 4 videos a framemd5 file for each  
one of them.
5) Run "vimdiff *.framemd5":
It's interesting to see that not sometimes there's even a difference  
if CRC is enabled or disabled. btw: CRC does not report errors.

Also compare these 4 framemd5 results to the original video's framemd5 file.

The SD-tests are almost done, but I'll wait with further test-runs  
until it is known what causes this issue here.

Regards,
Pb

== References:
[1] http://media.xiph.org/video/derf/y4m/bridge_close_cif.y4m