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

[Jonathan Lennox <[e-mail]>]

Hi, Christer — thanks again for your comments.

My response here is based on what I personally think would be the ideal solution; however, given that there is substantial amount of running VP9 code, if any of these would cause problems for the existing implementations it may need to be restricted.  If any browser implementors could check how their existing implementations handle SDP parameter updates in remote descriptions, that’d be very helpful.

> On Feb 4, 2021, at 1:48 PM, Christer Holmberg <[e-mail]> wrote:
> 
> Hi Jonathan,
> 
>>>> Q3:
>>> 
>>> 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.
> 
> Ok. Perhaps it would be useful to add a note indicating that?

Ok.

>>> 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?
> 
> 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.

Yes, agreed.  I think the spec should say that each side MAY set max-fs and max-fr independently based on their own receiver capabilities, and these two parameters MAY be present in the answer even if they’re not present in the offer.

[Quoting from your previous e-mail:]
> 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?

I would propose that profile-id MUST be maintained in subsequent offers (i.e., to negotiate a different profile-id, change payload type numbers), but max-fs and max-fr can be changed freely by either side.

> 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"?

Yes, that’s better wording.

> 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.

Agreed.  An important question - should this be SHOULD NOT or MUST NOT?