[FFmpeg-devel] FFV1.3

David Rice daverice at mac.com
Wed Aug 8 03:24:55 CEST 2012


On Aug 7, 2012, at 8:08 PM, Peter B. wrote:

> On 04/20/2012 03:50 PM, Michael Niedermayer wrote:
>> Ive just commited some changes to the ffv1 codec v1.3
> Sorry it took so incredibly long.
> Funny video-archivist's "everyday adventures" to master and
> video-mysteries to solve! - that's what stole my time! :)
> 
> 
> ----------------------------------------------------------
> Here's a quick summary of my FFv1.3 tests:
> ----------------------------------------------------------

I've run some tests as well and am including results and process inline where it aligns with yours.

> 1) YUV Colorspaces:
> Script tries to create files in any colorspace supported by ffmpeg. The
> logs then show which pix_fmts actually got encoded.
> 
> 2) Losslessness:
> A set of reference framemd5 files for each colorspace is generated once.
> Afterwards, all video files created with different options for
> ffv1-encoding are then framemd5-compared to those references: So far,
> all match as they should!

For your steps 1 and 2 I created a shell script to use ffmpeg to pull from /dev/random to produce 1 second rawvideo files at different combinations of frame size and pixel format. Each random source file is then decoded to produce an md5. Then the random source is encoded with ffv1 version 1 and 3 which are then each used to produce a framemd5 output.
My shell script is here: https://gist.github.com/3291078.

When I run this test the 9 bit and 10 bit yuv pixel formats come up lossy. From this I filed this ticket: http://ffmpeg.org/trac/ffmpeg/ticket/1569. But in reviewing this again I think there may be a flaw in my test process.

Also the rgb24 encodings are lossy, but this is intentional, right? Is ffv1 only lossless with YUV pixel formats?

Michael suggested I do some testing with standard test files. From http://media.xiph.org/video/derf/y4m/ I downloaded these files: 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 foreman_qcif_mono.y4m. Then I wrote a shell script to loop through the test files, encode to lossless ffv1 version 1 and 3, then use framemd5 to assess the results (shell script is here: https://gist.github.com/3291131). The result of this was that all tests (version 1 and version 3 on all test files listed) were lossless without error.

> 3) Performance:
> I haven't summarized the transcoding performance in numbers yet, because
> I did my tests on an external USB drive, so the numbers aren't
> representative, as I expect disk I/O to be a factor for the fps count.
> The test-setup was to have different options for threads, slices and
> colorspaces.
> 
> Here are some rough results from my machine:
> (NOTE: All values apply to a VHS PAL yuv422p source and transcoding
> running on an Intel Quadcore i7-2600K @ 3.40 GHz)
> 
> == yuv420p
> ffv1.1 -> ffv1.1 : 21 fps
> ffv1.1 -> ffv1.3 : 28 fps
> ffv1.3 -> ffv1.3 : 50 fps
> 
> == yuv422p
> ffv1.1 -> ffv1.1 : 20 fps
> ffv1.1 -> ffv1.3 : 28 fps
> ffv1.3 -> ffv1.3 : 45 fps
> 
> == yuv444p
> ffv1.1 -> ffv1.1 : 17 fps
> ffv1.1 -> ffv1.3 : 20 fps
> ffv1.3 -> ffv1.3 : 20 fps
> 
> 
> 4) Bit error resilience:
> I'm using the tool "zzuf" to fuzz the differently encoded files.
> Several levels of damage are simulated, then the impact is checked:
> effect on playability, stability, artefacts, a/v sync.
> This part of the test-suite is still work in progress, as I'd like to
> have some meaningful fuzzing-parameters for zzuf.
> 
> So far I can say that using slices makes the image contentually more
> robust, as only the slice is broken.
> With a FFv1.1 encoded video, the whole frame falls apart into
> LSD-rainbows ;)

Using -g 1 will also minimize the effects of fuzzing.
You have an older version of the ffv1 decoder. Error concealment was added to git on July 16th which will conceal the LSD rainbow effect.

> 5) Aspect ratio:
> I was surprised to see that the aspect ratio is already stored somehow
> in a FFv1.1 stream:
> I've produced AVIs which played back anamorphic videos correctly using
> ffplay.
> ffmpeg/ffprobe also read the DAR correctly from the file, although AVIs
> can't store the aspect ratio (right?).
> Any other player tried so far did not handle ffv1's aspect ratio, but
> that was to be expected, as this feature is now new in ffv1.
> 
> Does anyone of you know how the support for ffv1.3 within VLC will
> assumably proceed, after Michael marks it as non-experimental?

Beyond testing, another issue in the experimental status may be that the updates to ffv1 need to be reviewed by someone that isn't Michael.

> I've heard that VideoLAN is using their own library fork, but based on
> libav instead of ffmpeg. Is that true?

Have you filed a ticket at VLC's trac?

> 6) Filesize:
> The filesizes are the size of the transcoded "per-Minute-AVI".
> 
> Original (yuv422p, ffv1.1): 431.5 MB
> 
> == yuv420p
> ffv1.1 -> ffv1.1 : 339.7 MB
> ffv1.1 -> ffv1.3 : 352.6 MB
> ffv1.3 -> ffv1.3 : 352.6 MB
> 
> == yuv422p
> ffv1.1 -> ffv1.1 : 429.0 MB
> ffv1.1 -> ffv1.3 : 444.4 MB
> ffv1.3 -> ffv1.3 : 444.4 MB
> 
> == yuv444p
> ffv1.1 -> ffv1.1 : 461.3 MB
> ffv1.1 -> ffv1.3 : 475.3 MB
> ffv1.3 -> ffv1.3 : 475.3 MB

It may be worth testing size and speed when using '-g 1' or not. If the effects of -g 1 are not substantial on these numbers it would be more worth making -g 1 the default.
Also ffv1.3 includes the ability to do a two-pass encoder which could improve the filesize.

> I will try to get my hands on real xxx444p16 material in order to get
> more realistic filesizes for a >422p8 source.
> Then I'll get all those numbers together and in a proper shape for a
> proper ffv1 reference paper.

I'd be happy to contribute.
Dave Rice



More information about the ffmpeg-devel mailing list