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

[Jonathan Lennox <[e-mail]>]

There was one open issue that I’m not 100% sure we resolved in the WG meeting - whether a sender violating the signaled max-fs and max-fr is “SHOULD NOT” or “MUST NOT”.

In particular, in the spoken conversation we converged on “SHOULD NOT”, on the grounds that existing implementations are fine with it, and there are cases (like pre-encoded video or SFUs) where it’s helpful, but then Mo raised an concern in the chat (after the meeting itself had moved on) as to whether that would be a problem for hardware implementations, which are fairly rare now but might be more common going forward.

Because the spoken conversation and the minutes went with “SHOULD NOT”, I’ll submit an update with that unless I hear otherwise, but if you want to advocate for “MUST NOT” now’s the chance to do that.

> On Mar 29, 2021, at 6:53 AM, Christer Holmberg <[e-mail]> wrote:
> 
> Any news on this?
> 
> Regards,
> 
> Christer
> 
> -----Original Message-----
> From: Jonathan Lennox <[e-mail]> 
> Sent: keskiviikko 3. maaliskuuta 2021 15.53
> To: Christer Holmberg <[e-mail]>
> Cc: Justin Uberti <[e-mail]>; IETF AVTCore WG <[e-mail]>
> Subject: Re: [AVTCORE] I-D Action: draft-ietf-payload-vp9-11.txt
> 
> The use cases I’m thinking about are things like SFUs, or pre-encoded video.
> 
> I guess the question is whether the semantics of max-fs and max-fr are “this is the maximum that is useful to me”, or whether they are “this is the maximum I am physically capable of”.
> 
> Browser vendors, what do your implementations do if they receive a stream violating the signaled max-fs or max-fr?
> 
>> On Mar 2, 2021, at 3:26 PM, Christer Holmberg <[e-mail]> wrote:
>> 
>> Hi,
>> 
>> Thank you for the reply! You suggestions look good to me.
>> 
>> Regarding, Q4, I leave it up to you and other payload experts to decide whether it should be "SHOULD NOT" or "MUST NOT".  Is there a valid use case where one would use bigger values than have been indicated by the peer?
>> 
>> Regards,
>> 
>> Christer
>> 
>> -----Original Message-----
>> From: Jonathan Lennox <[e-mail]> 
>> Sent: tiistai 2. maaliskuuta 2021 17.45
>> To: Christer Holmberg <[e-mail]>
>> Cc: Justin Uberti <[e-mail]>; IETF AVTCore WG <[e-mail]>
>> Subject: Re: [AVTCORE] I-D Action: draft-ietf-payload-vp9-11.txt
>> 
>> 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?
>