Subject: [AVTCORE] I-D Action: draft-ietf-payload-vp9-11.txt

From: [email-masked]
Date: Tue, 02 Feb 2021 07:29:03 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF.

        Title           : RTP Payload Format for VP9 Video
        Authors         : Justin Uberti
                          Stefan Holmer
                          Magnus Flodman
                          Danny Hong
                          Jonathan Lennox
	Filename        : draft-ietf-payload-vp9-11.txt
	Pages           : 24
	Date            : 2021-02-02

Abstract:
   This memo describes an RTP payload format for the VP9 video codec.
   The payload format has wide applicability, as it supports
   applications from low bit-rate peer-to-peer usage, to high bit-rate
   video conferences.  It includes provisions for temporal and spatial
   scalability.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-payload-vp9/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-payload-vp9-11
https://datatracker.ietf.org/doc/html/draft-ietf-payload-vp9-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp9-11

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 2 Feb 2021 10:41:12 -0500

This version removes the frame marking section, as discussed in last week’s interim.

The only other change is to update the reference for SDP, now that RFC 8866 is published.

I believe this should resolve everything raised during WGLC.

> On Feb 2, 2021, at 10:29 AM, [email-masked] wrote:
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Feb 2021 19:30:17 +0000

Hi,

I don't know if the document will be sent to the SDP directorate, so I will give a few comments here:

Q1:

In Section 6.2.1.1., please place the m= lines and each attribute on separate lines.

Q2:

In Section 6.2.1, my understanding is that max-fs and max-fr are optional. Section 6.2.2 says that the answerer must maintain all configuration parameters. Does that apply to max-fs and max-fr too? If so, if the offer does not contain max-fs and max-fr, the answer cannot contain them either?

Q3:

Is there a reason why profile-id is optional, since a value will always be assumed?

Q4:

Section 6.2.2. does not define any restrictions on what can be modified in a subsequent offer, so I guess one can modify max-fs, max-fr and/or profile-id in a subsequent offer?

Regards,

Christer

-----Original Message-----
From: avt <[email-masked]> On Behalf Of Jonathan Lennox
Sent: tiistai 2. helmikuuta 2021 17.41
To: IETF AVTCore WG <[email-masked]>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-payload-vp9-11.txt

> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> Audio/Video Transport Core Maintenance [email-masked]

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 4 Feb 2021 11:25:55 -0500

Hi, Christer - thanks for your comments.

> On Feb 2, 2021, at 2:30 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

Apologies, this was an xml2rfc formatting error.  I’ll fix it for the next version.

> Is there a reason why profile-id is optional, since a value will always be assumed?

Since profile-id negotiation was developed relatively late in the process of writing the spec, existing implementations don’t always send it.  It seemed best to maintain compatibility here.

> Section 6.2.2. does not define any restrictions on what can be modified in a subsequent offer, so I guess one can modify max-fs, max-fr and/or profile-id in a subsequent offer?

Hm.  For these, I think the best thing to do would be to see how the existing (browser) implementations handle these, since there’s deployed code here.  Justin, would you be able to ask inside Google?  And since as I understand it the SDP parsing code is separate for the different browsers, is there someone at the other browser implementations who could check those as well?

Thanks!

Jonathan

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 4 Feb 2021 08:33:48 -0800

Jonathan said:

"Hm.  For these, I think the best thing to do would be to see how the
existing (browser) implementations handle these, since there’s deployed
code here.  Justin, would you be able to ask inside Google?  And since as I
understand it the SDP parsing code is separate for the different browsers,
is there someone at the other browser implementations who could check those
as well?"

[BA] Since there is no WebRTC API to set maxfs/maxfr, the values emitted in
subsequent Offers won't change.

On Thu, Feb 4, 2021 at 8:26 AM Jonathan Lennox <[email-masked]>
wrote:

> Since profile-id negotiation was developed relatively late in the process
> of writing the spec, existing implementations don’t always send it.  It
> seemed best to maintain compatibility here.
>
> > Q2:
> >
> > In Section 6.2.1, my understanding is that max-fs and max-fr are
> optional. Section 6.2.2 says that the answerer must maintain all
> configuration parameters. Does that apply to max-fs and max-fr too? If so,
> if the offer does not contain max-fs and max-fr, the answer cannot contain
> them either?
>
> > Q4:
> >
> > Section 6.2.2. does not define any restrictions on what can be modified
> in a subsequent offer, so I guess one can modify max-fs, max-fr and/or
> profile-id in a subsequent offer?
>
> Hm.  For these, I think the best thing to do would be to see how the
> existing (browser) implementations handle these, since there’s deployed
> code here.  Justin, would you be able to ask inside Google?  And since as I
> understand it the SDP parsing code is separate for the different browsers,
> is there someone at the other browser implementations who could check those
> as well?
>
> Thanks!
>
> Jonathan
>

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 4 Feb 2021 11:36:57 -0500

Do you know what the browsers will do if they change in a subsequent offer, whether due to SDP munging or a non-browser peer?  Or if they’re received in an answer which doesn’t match the offer?

> On Feb 4, 2021, at 11:33 AM, Bernard Aboba <[email-masked]> wrote:
> 
> Jonathan said: 
> 
> "Hm.  For these, I think the best thing to do would be to see how the existing (browser) implementations handle these, since there’s deployed code here.  Justin, would you be able to ask inside Google?  And since as I understand it the SDP parsing code is separate for the different browsers, is there someone at the other browser implementations who could check those as well?"
> 
> [BA] Since there is no WebRTC API to set maxfs/maxfr, the values emitted in subsequent Offers won't change. 
> 
> On Thu, Feb 4, 2021 at 8:26 AM Jonathan Lennox <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On Feb 2, 2021, at 2:30 PM, Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > Hi,
> > 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/avt <https://www.ietf.org/mailman/listinfo/avt>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Feb 2021 18:48:29 +0000

Hi Jonathan,

> Since profile-id negotiation was developed relatively late in the process of writing the spec, existing implementations don’t always send it.  It seemed best to maintain compatibility here.

Ok. Perhaps it would be useful to add a note indicating that?

>> In Section 6.2.1, my understanding is that max-fs and max-fr are optional. Section 6.2.2 says that the answerer must maintain all configuration parameters. Does that apply to max-fs and max-fr too…

A little more on this: the draft says that max-fs and max-fr are only used to indicate capabilities. AFAIU, it is not used to negotiate anything, so I see no reason why endpoints would not be able to insert different values.

Also, Section 6.2.1 of the draft says:

   "The parameters "max-fs", and "max-fr", MUST be included in the
     "a=fmtp" line of SDP if SDP is used to declare receiver capabilities."

The "if SDP is used to declare receiver capabilities" sounds strange. Do you mean to say "MUST be included if the user wants to declare its receiver capabilities"?

Also, there is no text on what an endpoint does when receiving those values by the peer. I assume the user should not exceed the indicated frame rate/size, but that is not specified anywhere.

Regards,

Christer