[FFmpeg-devel] FFV1 Specification

[Michael Niedermayer]

On Sun, Apr 08, 2012 at 05:33:44PM +0200, Michael Niedermayer wrote:
> On Sun, Apr 08, 2012 at 04:42:00PM +0200, Reimar Döffinger wrote:
> > On Sun, Apr 08, 2012 at 04:29:18PM +0200, Michael Niedermayer wrote:
> > > On Sun, Apr 08, 2012 at 04:04:03PM +0200, Reimar Döffinger wrote:
> > > > > Also in relation to this (10 seconds from the matrix lobby scene)
> > > > > using rangecoding and the larger context model:
> > > > > ffv1    GOP=300     23736978
> > > > > ffv1    GOP=1       25056734
> > > > > 
> > > > > ffv1.2  GOP=300     23648224
> > > > > ffv1.2  GOP=1       23645074
> > > > > 
> > > > > and ffv1.2 does low latency multithreaded encoding & decoding for all
> > > > > who dont know that yet ...
> > > > 
> > > > Larger GOP values giving larger file size is not really the expected
> > > > behaviour though I have to say...
> > > 
> > > I dunno, its not so unexpected
> > > for gop 1 each slice starts with a good average optimized state
> > > for gop 300 most slices use the previous slices state, this as such
> > > would likely be better but its not exactly what happens rather the
> > > left top starts using the coder state of the previous slices bottom
> > > right and with the matrix lobby scene with 4 rectangular slices the
> > > tops and bottoms allways are in a different area (black border vs
> > > picture) this likely gives a penalty relative to starting with
> > > a middle average state
> > 
> > Well, it certainly isn't from a user standpoint.
> > Maybe with slices the context should be moved around, i.e. top slice
> > always gets default state, second slice uses state from first slice
> > of previous frame etc.
> > That would also make frame-parallel decoding of dependent frames
> > more efficient...
> > It's not that important, but if larger GOP size most of the time
> > gives worse compression, we probably should refuse to allow setting
> > GOP size except with a special -strict -2 or such...
> > (note I haven't actually check what the current state of all this
> > is, and whether v1.2 is even "official" yet)
> 
> pushed some code to allow easy testing of 1.2, before you had to edit
> the source to enable it.
> 
> also to get good compression with gop=1 you need to use some statistics
> generated by -pass 1 though these dont need to be from teh same file
> as the actual encoding uses.
> 
> if someone wants to test ffv1.2, especially with diverse raw material,
> this would be quite interresting. Especially knowing where it performs
> poorly ...

btw, ive updated the spec (lyx only ATM) to describe ffv1.2 too

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- 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/20120408/be6b5965/attachment.asc>