Re: [Cellar] FFV1 Version 4

[Michael Niedermayer <[e-mail]>]

On Tue, Jan 05, 2016 at 05:09:40PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Tue, Jan 05, 2016 at 02:22:46PM +0000, Kieran O Leary wrote:
> > Hello,
> > 
> > I saw on your charter that a milestone for September 2016 is "Submit
> > specification for FFV1 video codec version 4 to IESG (Standards Track)".
> > https://datatracker.ietf.org/wg/cellar/charter/
> > 
> > Is there any information or roadmap available about proposed changes from
> > version 3 to version 4? I'm asking as the added features of Version 3 were
> > significant for moving image archives, and I'm curious to know what version
> > 4 may look like.
> 
> i dont know about roundmaps but what might be in the next version
> i guess depends largly on what volunteers do (spec, implementation
> and testing wise)
> support for bayer "pixel" formats and maybe paletted formats could
> be in it. Some compression improvments by using inter frame prediction
> would be an idea too. But i think 2016-sep is too soon for complex
> additions like inter frames. All these things require trying multiple
> solutions and testing/evaluating how they perform comression, speed
> and complexity wise to see what makes sense to add to the spec

also theres a raw slice coding mode and a more flexible RCT in the
implementation and partly in the draft spec, these likely will be in
version 4 (depening on peoples oppinions i assume)

the "raw" coding mode for slices is needed so a tight upper bound
can be put on the compressed size of slices, otherwise its possible
to construct a sequence of frames where one slice has a compressed
size that is very much larger than its raw size, this would likely
never occur with any real video but contructed videos that push
the range coder statistics one direction and then sharply switch
everything to have completely opposite statistics would result in
a locally bloated up bitstream.
Such bloated up slices would annoyingly require larger buffers to be
allocated to allow encoding them, the raw coding mode puts a
constraint on this so that a buffer that is about as large as the raw
pixels is gurateed to be large enough for coding a slice in some mode.
Reducing the needed memory and complexity of an encoder implementation
and also reducing the worst case local bitrate requirement for
anything else in the chain



[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire