[FFmpeg-devel] FFV1.3

[Michael Niedermayer]

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 ?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120808/e02b900f/attachment.asc>