[FFmpeg-devel] FFV1 Specification

[Michael Niedermayer]

On Sat, Apr 07, 2012 at 08:36:27PM +0200, Peter B. wrote:
> On 04/06/2012 11:56 PM, Michael Niedermayer wrote:
> > latest draft at github and at:
> > http://ffmpeg.org/~michael/ffv1-draft/ffv1.html If someone could read
> > through it and point out where its unclear or incomplete, that would
> > be very helpfull! I imagine i can easyly miss incompletenesses given
> > that i know the codec pretty well ... Also
> > spellcheck/grammer/formating tips are welcome too! [...]
> I've cloned the github repo and made a few minor style changes to the text.
> I'm a complete git-newbie (only SVN experience so far), but from what
> I've read, I could commit my changes locally and send a "pull request"?

yes, well, you will need to push them to some public repo before they
can be pulled


> 
> 
> Here are some comments/questions:
> 
> 1) Which colorspaces can be handled?
> The paragraph "3.5 Colorspace" merely contains a formula, which looks
> like RGB-YCbCr conversion to me. Important would be to know which
> colorspaces can natively be supported without any conversion.
> The "high level description" mentions splitting a frame in Y/Cr/Cb/Alpha

> - what if the source was RGB?

its losslessly converted to YCbCr


> 
> 2) There's no text for "Run length coding". Is that on purpose?

it appears ive forgotten this


> 
> 3) Is "high level description" supposed to give an overview of how FFv1
> works?

yes


> Since the current text only mostly describes the colorspace and plane
> handling.
> 
> 4) Median predictor:
> What does "diag" mean? (diagonal?)

yes


> 5) Do you have any estimations about bit-error resilience of FFv1's stream?

ive not tested it but i suspect bit errors are quite bad. ffv1 is not
designed to handle that. It could be changed to handle bit errors
much better but this would cause overhead both speed and compression
wise. Is this something important for the likely users of ffv1?
I would expect that bit errors are not a big issue on modern storeage
media, which corrects bit errors internally and the end user gets a
error free sector or no sector (or a heavily damaged sector)


> 
> There's probably more feedback/questions to come from me ;)


[...]

-- 
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/20120407/cf0cea87/attachment.asc>