Subject: [AVTCORE] Confirmation of consensus: way forward on framemarking

From: Jonathan Lennox <[email-masked]>
Date: Tue, 2 Feb 2021 14:45:15 -0500

This is to confirm the consensus we had on the way forward on the framemarking document in last week’s virtual interim meeting.

The rough consensus of the group was to publish the document as Experimental.  We’ll make any necessary easy fixes to the document, but no major changes before we request publication.

We’ll also move the section on framemarking for VP9 back into this document, now that it’s been removed from the VP9 payload.

If anyone disagrees with this consensus, or has further comments to make, please respond here on the AVTCore mailing list.

Thank you!

Jonathan Lennox
AVTCore co-chair

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 2 Feb 2021 11:52:41 -0800

I agree with the consensus.

The only additional comment (other than the ones I previously posted to the
list) is to request that the issue experienced with VP8 PictureID and
TL0PICIDX be documented. This wasn't an issue with framemarking per se, but
it did imply that SFUs needed to parse and modify VP8 payloads and so could
not operate based on framemarking alone. Subsequently, I have heard the
problem being attributed to a deficiency in framemarking (e.g. that a new
RTP header extension can address the problem) when in fact the issue will
also be encountered by other forwarding extensions and a better way forward
is to make VP8 implementations more robust.

On Tue, Feb 2, 2021 at 11:45 AM Jonathan Lennox <[email-masked]>
wrote:

> This is to confirm the consensus we had on the way forward on the
> framemarking document in last week’s virtual interim meeting.
>
> The rough consensus of the group was to publish the document as
> Experimental.  We’ll make any necessary easy fixes to the document, but no
> major changes before we request publication.
>
> We’ll also move the section on framemarking for VP9 back into this
> document, now that it’s been removed from the VP9 payload.
>
> If anyone disagrees with this consensus, or has further comments to make,
> please respond here on the AVTCore mailing list.
>
> Thank you!
>
> Jonathan Lennox
> AVTCore co-chair
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 2 Feb 2021 20:24:39 +0000

Hi,
I couldn’t make it to the interim, sorry.
Did you guys discuss the need of a mandatory section in future video payload formats in support of framemarking?  Given that the mapping for VP9 is removed from the payload format, can we assume the same thing for other future payload formats (VVC and EVC come to mind, obviously).  That would be reversing a previous consensus.  Can we EVC/VVC payload authors work under that assumption?
Thanks,
Stephan

From: avt <[email-masked]> on behalf of Bernard Aboba <[email-masked]>
Date: Tuesday, February 2, 2021 at 11:53
To: Jonathan Lennox <[email-masked]>
Cc: IETF AVTCore WG <[email-masked]>
Subject: Re: [AVTCORE] Confirmation of consensus: way forward on framemarking

The only additional comment (other than the ones I previously posted to the list) is to request that the issue experienced with VP8 PictureID and TL0PICIDX be documented. This wasn't an issue with framemarking per se, but it did imply that SFUs needed to parse and modify VP8 payloads and so could not operate based on framemarking alone. Subsequently, I have heard the problem being attributed to a deficiency in framemarking (e.g. that a new RTP header extension can address the problem) when in fact the issue will also be encountered by other forwarding extensions and a better way forward is to make VP8 implementations more robust.

On Tue, Feb 2, 2021 at 11:45 AM Jonathan Lennox <[email-masked]<mailto:[email-masked]>> wrote:
This is to confirm the consensus we had on the way forward on the framemarking document in last week’s virtual interim meeting.

Thank you!

Jonathan Lennox
AVTCore co-chair
_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/avt

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 2 Feb 2021 15:50:13 -0500

We didn’t explicitly call consensus on this, but personally I feel that an Experimental RFC can’t impose requirements on future Standards-Track documents.

My suggestion would be that the framemarking document should change to say that future payloads MAY specify how they’re used for framemarking.

(Note though that for VP9 we’re moving its framemarking use back into the framemarking document, rather than dropping it completely.)

> On Feb 2, 2021, at 3:24 PM, Stephan Wenger <[email-masked]> wrote:
> 
> Hi,
> From: avt <[email-masked] <mailto:[email-masked]>> on behalf of Bernard Aboba <[email-masked] <mailto:[email-masked]>>
> To: Jonathan Lennox <[email-masked] <mailto:[email-masked]>>
> Cc: IETF AVTCore WG <[email-masked] <mailto:[email-masked]>>
> On Tue, Feb 2, 2021 at 11:45 AM Jonathan Lennox <[email-masked] <mailto:[email-masked]>> wrote:
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/avt <https://www.ietf.org/mailman/listinfo/avt>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 3 Feb 2021 14:57:35 -0600

Hi, Bernard,

On Tue, Feb 2, 2021 at 1:53 PM Bernard Aboba <[email-masked]>
wrote:

> The only additional comment (other than the ones I previously posted to
> the list) is to request that the issue experienced with VP8 PictureID and
> TL0PICIDX be documented.
>

Was it obvious where that experience would be documented? I THOUGHT it
might be in the framemarking draft, but I could be wrong about that.

Best,

Spencer

> This wasn't an issue with framemarking per se, but it did imply that SFUs
> needed to parse and modify VP8 payloads and so could not operate based on
> framemarking alone. Subsequently, I have heard the problem being attributed
> to a deficiency in framemarking (e.g. that a new RTP header extension can
> address the problem) when in fact the issue will also be encountered by
> other forwarding extensions and a better way forward is to make VP8
> implementations more robust.
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 3 Feb 2021 13:46:32 -0800

On Feb 3, 2021, at 12:58 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> 
> Hi, Bernard,
> 
> Was it obvious where that experience would be documented? I THOUGHT it might be in the framemarking draft, but I could be wrong about that.
> 
> Best,
> 
> Spencer

[BA] It is really a VP8 issue, but that RFC is published. So framemarking came to mind. Do you think some other document would be better?

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 3 Feb 2021 16:17:53 -0600

Hi, Bernard,

On Wed, Feb 3, 2021 at 3:46 PM Bernard Aboba <[email-masked]>
wrote:

> [BA] It is really a VP8 issue, but that RFC is published. So framemarking
> came to mind. Do you think some other document would be better?

That's what I thought, but I was just making sure.

Best,

Spencer

---

From: "Roni Even" <[email-masked]>
Date: Fri, 5 Feb 2021 09:21:26 +0200

I have no strong view about it but are there any views from SFUs guys about changing it to MAY.

Roni

From: avt [mailto:[email-masked]] On Behalf Of Jonathan Lennox
Sent: Tuesday, February 02, 2021 10:50 PM
To: Stephan Wenger
Cc: IETF AVTCore WG
Subject: Re: [AVTCORE] Confirmation of consensus: way forward on framemarking

Hi,

Thanks,

Stephan

On Tue, Feb 2, 2021 at 11:45 AM Jonathan Lennox <[email-masked]> wrote:

Thank you!

Jonathan Lennox
AVTCore co-chair