[Cellar] Robert Wilton's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-cellar-ffv1-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thank you for taking the time to document FFV1 version 0, 1 and 3.

I support Barry's discuss in that I found this document hard to read and
interpret.  I think that I would struggle to implement a FFV1 encoder/decoded
from scratch based on this document.  However, this is a long way outside my
area of expertise and there is perhaps a corpus of basic video codec knowledge
that is assumed in this specification.

Is the intention of this document that it gets obsoleted when FFV1 version 4 is
documented?

I haven't reviewed the entirety of this document, but I do have some comments
of particular areas of the document that I found hard to follow that additional
text or explanation may be helpful.

Overall, having some more introduction text explaining the overall structure of
the encoding , i.e. how the different parts fit together would likely help
readability.

3.1.  Border

      Figure 2: A depiction of FFV1's assumed border for a set example
                                  Samples.

I wasn't sure whether an extra row at the bottom of this table would have been
helpful, but perhaps it is not required because it is not referenced.

3.2.  Samples

   The labels for these relative "Samples" are made of the first letters
   of the words Top, Left and Right.

Don't feel obliged to change this, but I wonder whether keep lowercase for all
of the relative positions might have been clearer.  E.g., perhaps using "tt"
instead of "T" and "ll" instead of "L".

3.3.  Median Predictor

   Exception for the median predictor ...

Possibly putting the exception text into a 3.3.1 sub-section would aid
readability.

3.4.  Quantization Table Sets

It wasn't clear to me what a "Quantized Sample Differences" is.

3.7.2.  RGB

   Cb = b - g
   Cr = r - g
   Y = g + (Cb + Cr) >> 2
   g = Y - (Cb + Cr) >> 2
   r = Cr + g
   b = Cb + g

Perhaps split into two sets of 3 equations to define the relationship in either
direction.

   Exception for the JPEG2000-RCT conversion ...

Again, putting this into a sub-section (3.7.2.1) might aid readability, i.e.
the split between what is desired vs what is being described due to bugs in
real implementations.

3.8.  Coding of the Sample Difference

   coder_input = [(sample_difference + 2 ^ (bits - 1)) &
                 (2 ^ bits - 1)] - 2 ^ (bits - 1)

It wasn't clear to me what [] brackets meant here.

3.8.1.1.  Range Binary Values

I found this hard to follow, as in I couldn't figure out what it means.

3.8.1.4.  State Transition Table

It wasn't really clear to me what these were used for.

3.8.2.1.  Signed Golomb Rice Codes

Unclear what is meant by "ESC case"

Regards,
Rob