[FFmpeg-devel] FFV1.3

[Dave Rice]

On Aug 8, 2012, at 2:29 PM, Michael Niedermayer wrote:

> On Tue, Aug 07, 2012 at 09:24:55PM -0400, David Rice wrote:
>> 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?
> 
> rgb should be lossless, how can i reproduce this issue ?

Ack, my bad. I missed the fact that ffv1 encodes rgb24 data as bgr0. The framemd5's of the rgb24 and bgr0 data naturally mismatched and my test flagged this as lossy. When I converted the ffv1 encoded bgr0 back to rgb24, the output was identical to the source. Sorry about that.
Dave