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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Mon, 05 Oct 2020 07:54:36 -0700

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

---

From: Jerome Martinez <[email-masked]>
Date: Wed, 7 Oct 2020 17:16:04 +0200

Hi Robert,
Thank you for your comments. Answers inline:

There is no definitive answer but I think that at long term FFV1 version 
4 specification is intended to be on IETF standard track, with the 
decoder based on the specification, and that we will remove all the 
parts specific to FFV1 version 0, 1 and 3 e.g. all the exceptions 
documented due to the spec written after the decoder and all the "if 
version is" related to previous versions, so this document would not be 
obsoleted when FFV1 version 4 is accepted as an IETF standard.

> the encoding , i.e. how the different parts fit together would likely help

Since the last IETF version we added a couple of  introduction texts, 
with links to other parts, hoping that it helps to clarify the 
specification.

> helpful, but perhaps it is not required because it is not referenced.

I don't get this sentence. In my opinion the figure has an arbitrary 
choice of a slice of 3x3 samples showing the dependencies between 
samples, showing the exception for the 1st and last lines and columns, 
and the references are all at the top, left or right. No bottom line 
here because the compute of the samples doesn't include any sample below 
the 3x3 samples.

> instead of "T" and "ll" instead of "L".

I am personally not in favor of that, the 2-letter lowercase strings 
being also used for the samples near the reference one, so in my opinion 
it makes sense to have another method for the sampls far from the 
reference one. I let another specification writer send a patch if there 
is a disagreement.

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

I added this suggestion in https://github.com/FFmpeg/FFV1/pull/247

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

I added an introduction in https://github.com/FFmpeg/FFV1/pull/247

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

I have split the formulae in https://github.com/FFmpeg/FFV1/pull/247

> the split between what is desired vs what is being described due to bugs in

I added this suggestion in https://github.com/FFmpeg/FFV1/pull/247

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

It was for doing the difference between "near" parenthesis and "far" 
parenthesis, but maybe not a good idea.
I added this suggestion to use only parenthesis in 
https://github.com/FFmpeg/FFV1/pull/247

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

This is the mathematical explanation behind the algorithm of Range 
Coder, without reproducing literature like in
http://www.compressconsult.com/rangecoder/#literature

I would not change that part because it would be hard in any case, due 
to the need of specific math skills.

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

I added an introduction in https://github.com/FFmpeg/FFV1/pull/247

> Unclear what is meant by "ESC case"

I added an explanation in https://github.com/FFmpeg/FFV1/pull/247

Jérôme

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 7 Oct 2020 10:59:58 -0500

Hi, Robert,

> obsoleted when FFV1 version 4 is accepted as an IETF standard.

Just to follow up on Jerome's more experienced answer,
https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1-v4/ is listed as
Standards Track, so yes, that's the goal.

Questions of what's obsoleted, or declared Historic, or otherwise done
to FFV1 version 0, 1 and 3, would be decided by the working group, AD, and
IESG when FFV1 version 4 is in IESG Evaluation, I think?

If that's not the case, I'll let someone correct me.

Best,

Spencer

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Oct 2020 14:39:44 -0400

Spencer Dawkins at IETF <[email-masked]> wrote:
    > to FFV1 version 0, 1 and 3, would be decided by the working group, AD,
    > and IESG when FFV1 version 4 is in IESG Evaluation, I think?

I understood that FFV1 version 0/1/3 was Informational.
I guess it could be marked Historic by the IESG at some point.
I didn't think that time would be when FFV1 v4 was published, but sure.

I thought that this was even in our charter somewhere, so I'm confused by
this thread.

This follows the pattern of publishing an RFC that is not within IETF
revision control that documents "current practice", and then publishing an
RFC on standards track, that is within IETF revision control.

Here "revision control" means we can change the bits-in-the-wire
(or in the file) in incompatible ways.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 7 Oct 2020 13:53:41 -0500

Hi, Michael,

> I didn't think that time would be when FFV1 v4 was published, but sure.

Yeah, I should have said "at the earliest, when FFV1 version 4 was
approved", but my intention was to say "not yet".

I could have also reasonably said "or takes no action to twiddle the status
of FFV1 version 0/1/3" - that's also a path that would be open.

And I wasn't trying to guess what would happen. Different IESGs have
handled these situations on a case by case basis.

> I thought that this was even in our charter somewhere, so I'm confused by

Yup. I'm looking at this, from the charter.

 - Informational specification for FFV1 video codec versions 0, 1 and 3 to
IESG for publication

Best,

Spencer

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 8 Oct 2020 10:40:09 +0000

Hi Michael, Spencer,

So, the reason that I asked the question as to whether this document would end up historical was to try and gauge how important it is for this specification to be generally implementable.

Personally, I would find this specification very hard to implement correctly in an interoperable way.  However, I don't have any expertise in video codecs, and if I did then perhaps this specification would be sufficient, it is hard to judge.  However, if this document is primarily intended to act as a historical record for existing FFV1 implementations, with the main focus being on a standards track FFV1 version 4, then the fact that parts of this document are a bit opaque may not really be important in the longer term, particularly if the FFV1 v4 specification is more accessible.

Hopefully that clarifies the purpose of my question.

Regards,
Rob

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Michael Richardson
> Sent: 07 October 2020 19:40
> To: Rob Wilton (rwilton) <[email-masked]>; The IESG <[email-masked]>;
> [email-masked]; [email-masked]; Codec Encoding
> for LossLess Archiving and Realtime transmission <[email-masked]>; Peter
> B. <[email-masked]>
> Subject: Re: Robert Wilton's No Objection on draft-ietf-cellar-ffv1-17:
> (with COMMENT)
> 
>

---

From: Jerome Martinez <[email-masked]>
Date: Thu, 8 Oct 2020 12:51:37 +0200

On 08/10/2020 12:40, Rob Wilton (rwilton) wrote:
> Personally, I would find this specification very hard to implement correctly in an interoperable way.  However, I don't have any expertise in video codecs, and if I did then perhaps this specification would be sufficient, it is hard to judge.

There was a write from scratch of a decoder, based on this document.
Presentation video: https://www.youtube.com/watch?v=4HB7v7dItWE
Slides: 
https://mediaarea.net/Events/2019-12-05_NoTimeToWait4/13.%20Derek%20Buitenhuis%20-%20I%20Wrote%20an%20FFV1%20decoder%20in%20Go%20for%20Fun,%20What%20I%20learned%20going%20from%20Spec%20to%20Implementation/derek_nttw4_ffv1.pdf
And this led to some issues publicly raised:
https://github.com/FFmpeg/FFV1/issues?q=is%3Aissue+author%3Adwbuiten+created%3A2019
(and fixed)

Jérôme

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Oct 2020 13:49:22 -0400

Rob Wilton (rwilton) <[email-masked]> wrote:
    > Personally, I would find this specification very hard to implement
    > correctly in an interoperable way.  However, I don't have any expertise
    > in video codecs, and if I did then perhaps this specification would be
    > sufficient, it is hard to judge.  However, if this document is
    > primarily intended to act as a historical record for existing FFV1
    > implementations, with the main focus being on a standards track FFV1
    > version 4, then the fact that parts of this document are a bit opaque
    > may not really be important in the longer term, particularly if the
    > FFV1 v4 specification is more accessible.

Ah, I understand you concern much better now.

Given that there is significant content in this format which is being
archived, one should assume that someone might want to write a new decoder in
some new language in 50 years.

I think that FFV1 v4 builds upon the notation and concepts in v013,
so I think that any clarifications or style changes that we can make on this
pass will help when v4 comes forward.