Subject: [Cellar] generate a version (0, 1, 3) and version 4 FFV1 document from single source

From: Dave Rice <[email-masked]>
Date: Sat, 3 Feb 2018 13:24:15 -0500

Hi cellar,

I’ve drafted a pull request at https://github.com/FFmpeg/FFV1/pull/102 based on Michael Niedermayer’s suggestion https://github.com/FFmpeg/FFV1/pull/93#issuecomment-356348383 <https://github.com/FFmpeg/FFV1/pull/93#issuecomment-356348383>. This attempts to create a method where the FFV1 specification may be worked upon within a single document while the parts that only relevant to the version 0,1,3 document are suppressed from the version 4 document and vice versa. To do this I’d created a method of ending lines with with "{V3}” (for version 3 and prior) or “{V4}” for version 4 or greater. I think this will help enable work to progress on the version 4 document as defined in our charter even while the version 0,1,3 hasn’t been reviewed by the IESG yet.

However some IETF questions:

In the PR the new outputs of the Makefile are:
draft-ietf-cellar-ffv1-01 (defines version 0, 1 and 3 of FFV1)
draft-ietf-cellar-ffv1-v4-00 (defines version 4 of FFV1)

This keeps the same id for version 0, 1, and 3 but would something else be more clear? Any examples of naming when IETF defines multiple versions of the same thing in separate documents?

I’ve separated the document version numbers for each, so draft-ietf-cellar-ffv1 stays at 01 and draft-ietf-cellar-ffv1-v4 starts at 00. Work?

In the version 4 output there are references to exceptions defined in our work on version 0,1,3. These include all lines starting with “Background”. I suggest resolving these in a subsequent commit, but perhaps the version 4 document need not include these but could only reference exceptions existed in prior version.

Best Regards,
Dave Rice

---

From: Reto Kromer <[email-masked]>
Date: Sat, 3 Feb 2018 19:54:05 +0100

Hello Dave,

thank you very much indeed for this!

>perhaps the version 4 document need not
>include these but could only reference exceptions existed in
>prior version.

In my personal opinion, this is exactly the way to go.

Best regards, Reto

---

From: Jerome Martinez <[email-masked]>
Date: Sat, 3 Feb 2018 20:08:32 +0100

On 03/02/2018 19:24, Dave Rice wrote:
>
> In the version 4 output there are references to exceptions defined in 
> our work on version 0,1,3. These include all lines starting with 
> “Background”. I suggest resolving these in a subsequent commit, but 
> perhaps the version 4 document need not include these but could only 
> reference exceptions existed in prior version.

IMO we should remove exceptions in v4, in order to have a easy and 
coherent bitstream specifications (and I expect that the compression is 
slightly better without the exceptions, I'll run some tests) so 
“Background” would be marked v3 doc only, without any reference in v4.
I'll open a separate thread about that when I do the tests.

---

From: Dave Rice <[email-masked]>
Date: Mon, 5 Feb 2018 15:43:57 -0500

> On Feb 3, 2018, at 2:08 PM, Jerome Martinez <[email-masked]> wrote:
> 
> IMO we should remove exceptions in v4, in order to have a easy and coherent bitstream specifications (and I expect that the compression is slightly better without the exceptions, I'll run some tests) so “Background” would be marked v3 doc only, without any reference in v4.

FYI, on this issue there was more discussion at https://github.com/FFmpeg/FFV1/pull/102 <https://github.com/FFmpeg/FFV1/pull/102>. The results are now merged in, so the Makefile process for the FFV1 repository will create two documents:

draft-ietf-cellar-ffv1-01: FFV1 Video Coding Format Version 0, 1, and 3
and
draft-ietf-cellar-ffv1-v4-00: FFV1 Video Coding Format Version 4

At this point, all issues in Github related to “FFV1 Version 0, 1, and 3” are resolved, but there are two open pull requests:

https://github.com/FFmpeg/FFV1/pull/87 <https://github.com/FFmpeg/FFV1/pull/87> - minor change in terminology about bitstream components
https://github.com/FFmpeg/FFV1/pull/71 <https://github.com/FFmpeg/FFV1/pull/71> - IANA Considerations

I suggest that once these are pull requests are resolved to increment the version numbering and post draft-ietf-cellar-ffv1-02 for a last call and to post an initial post of draft-ietf-cellar-ffv1-v4-00.

Best Regards,
Dave Rice

---

From: Jerome Martinez <[email-masked]>
Date: Mon, 5 Feb 2018 21:49:53 +0100

On 05/02/2018 21:43, Dave Rice wrote:
>
>
> At this point, all issues in Github related to “FFV1 Version 0, 1, and 
> 3” are resolved,

A bit late on it, but a question: how will be handled FFV1 v3.5, if we 
decide to have such version? FFV1 v4 is for incompatible changes, but 
micro_version seems planned for compatible changes (e.g. adding metadata 
like matrix coefficients for YUV in the configuration record part)

---

From: Dave Rice <[email-masked]>
Date: Wed, 7 Feb 2018 10:54:50 -0500

> On Feb 5, 2018, at 3:49 PM, Jerome Martinez <[email-masked]> wrote:
> 
>> At this point, all issues in Github related to “FFV1 Version 0, 1, and 3” are resolved,
> 
> A bit late on it, but a question: how will be handled FFV1 v3.5, if we decide to have such version? FFV1 v4 is for incompatible changes, but micro_version seems planned for compatible changes (e.g. adding metadata like matrix coefficients for YUV in the configuration record part)

Others may know better, but since FFV1 version 0,1,3 is an informational specification then IIUC an updated revision can be created by the cellar working group. Such post-stable minor_version updates for version 4 may be more involved, not sure if it would need a new IESG review.
Dave