Re: [Cellar] I-D Action: draft-ietf-cellar-ffv1-15.txt

[Dave Rice <[e-mail]>]

> On Jun 25, 2020, at 1:31 PM, Murray S. Kucherawy <[e-mail]> wrote:
> 
> On Thu, Jun 25, 2020 at 10:19 AM Jerome Martinez <[e-mail]> wrote:
> On 25/06/2020 18:24, Murray S. Kucherawy wrote:
>> Hooray, most of those "type" columns are gone!  But, alas, not all of them.  They're still present in Sections 4.1 and below.  I counted at least seven of them just in the diff I'm reviewing.  As before, they should also be removed, or at least explained.
>> 
>> A minor point: Prior to Section 3.8.2.3, it looks like all of the examples are in C.  After that, they switch to pseudo code.  Any reason we can't be consistent?
> The figures before section 4 are autonomous functions, used for describing a part of the algorithm and not used for directly reading out any symbol from the bitstream, so it was making sense to remove the "type" column at these places (this column was not used there). They could be more pseudocode nonetheless, as the C types ("int" etc) are not really relevant (they depends on the programming language).
> 
> The figures in section 4 are for explaining the bitstream parsing order, and the "type" column is used for indicating the kind of value it is (types are described in https://tools..ietf.org/id/draft-ietf-cellar-ffv1-15.html#table-4 , I see that it is called "Symbol" here, we'll change "Symbol" to "Type" in this table).
> This kind of method for describing a video bitstream is very classic, for example in:
> - H.264, see the full spec (PDF to download) https://www.itu.int/rec/T-REC-H.264-201906-I/en
> - AV1, see an online direct example at https://aomediacodec.github.io/av1-spec/#frame-obu-syntax
> 
> As in theses specs, we have some figures without usage of the "type" column because they are intermediate figures (the "type" column is used in the figures using this figure and the figures called by this figure), split from another figure, in order to have the spec more readable (focusing on a specific topic). AV1 uses it for example at https://aomediacodec.github.io/av1-spec/#decode-tile-syntax
> 
> 
> Your previous AD and I were both confused by the format and what it's trying to convey.  I appreciate that it might be classic in some realms, but as neither of us had seen it, I imagine others on the IESG who don't work in our layers (i.e., most of them) will also ask about it.  If you want to leave them in, I suggest including either some text about how to interpret them, or a reference to such guidance elsewhere.

As a draft to try to address this, I added this paragraph and figure to Section 2.2.1 which describes the use of pseudo-code within the document:

>    In some instances, pseudo-code is presented in a two-column format
>    such as shown in Figure 1.  In this form the "type" column provides a
>    symbol as defined in Table 4 that defines the storage of the data
>    referenced in that same line of pseudo-code.
> 
>    pseudo-code                                                   | type
>    --------------------------------------------------------------|-----
>    ExamplePseudoCode( ) {                                        |
>        value                                                     | ur
>    }                                                             |
> 
>        Figure 1: A depiction of type-labelled pseduo-code used within
>                                this document.

This proposed change is at https://github.com/FFmpeg/FFV1/pull/217/files, comments/suggestions welcome.

Note that Section 4.8 of https://aomediacodec.github.io/av1-spec/#method-of-describing-bitstream-syntax uses a similar description for its own pseudo-code.

Dave