Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt

From: Harald Alvestrand <[email-masked]>
Date: Wed, 14 Aug 2013 14:28:37 +0200

On 07/19/2013 10:17 PM, Cullen Jennings wrote:
> These can't be optional otherwise a device that is hardware limited can't know that the other side will use them. Thus there is no way to build solutions that interoperate by design instead of luck.

A device that has announced a=imageattr:97 recv [x:640,y:480] and 
a=framerate:60 has stated that max-fr is >= 60 and that max-fs is >=  1200.

These parameters were added because people on this list asked for them.
So far, I do not think they have been added to any existing 
implementation, and we don't seem to be seeing many interoperability 
problems because of that.

I don't think this is because of "luck". I think it's because these are 
not the constraints that are the most constraining in most practical 
situations - other constraints make sure we never reach the limits that 
might have been encoded using max-fr and max-fs.

>   
>
>
> On Jul 17, 2013, at 7:06 AM, Harald Alvestrand <[email-masked]> wrote:
>
>> On 07/10/2013 10:28 PM, Stephan Wenger wrote:
>>> Hi,
>>> I read through the diff file.  The main change seems to be to reduce the
>>> PartitionID field by one bit, which is now reserved.  This is fine.
>>> While reading through the diff file (without checking against the main
>>> text--too lazy or too busy, take your choice :-), I noticed that max_fr
>>> and max_fs are optional, and could not see a default being defined.
>> The theory is that there would be external constraints (such as an application-wide configuration, or an out-of-SDP signalling mechanism) that gave the constraints in question.
>>
>> Quote from 6.2.2:
>>
>>   In many practical applications, the max frame size and
>>   max frame rate are known from other information; if they are not
>>   constrained by other means, the max-fs and max-fr parameters MUST be
>>   used to establish these limits.
>>
>> We did not see a compelling reason to make non-compliant the present applications that do not use these parameters.
>>
>>
>>
>>>   Is
>>> this prudent?  How does a decoding system decide whether it is able to
>>> decode a stream without any indication of the complexity of the stream?
>>> Start decoding and reject once the header tells you that this stream is
>>> beyond your capacity?
>>> Stephan
>>>
>>> On 7.10.2013 08:50 , "[email-masked]" <[email-masked]>
>>> wrote:
>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>> This draft is a work item of the Audio/Video Transport Payloads Working
>>>> Group of the IETF.
>>>>
>>>> 	Title           : RTP Payload Format for VP8 Video
>>>> 	Author(s)       : Patrik Westin
>>>>                          Henrik F Lundin
>>>>                          Michael Glover
>>>>                          Justin Uberti
>>>>                          Frank Galligan
>>>> 	Filename        : draft-ietf-payload-vp8-09.txt
>>>> 	Pages           : 30
>>>> 	Date            : 2013-07-10
>>>>
>>>> Abstract:
>>>>   This memo describes an RTP payload format for the VP8 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.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8
>>>>
>>>> There's also a htmlized version available at:
>>>> http://tools.ietf.org/html/draft-ietf-payload-vp8-09
>>>>
>>>> A diff from the previous version is available at:
>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp8-09
>>>>
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________
>>>> payload mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/payload
>>> _______________________________________________
>>> payload mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/payload
>> _______________________________________________
>> payload mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/payload

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Wed, 14 Aug 2013 05:41:15 -0700

> might have been encoded using max-fr and max-fs.

I respectfully disagree. I think it's because implementations on 
resource-constrained mobile devices are still somewhat immature (ours 
certainly is). Earlier in this thread I pointed you to where we are 
adding support for these parameters for precisely this use-case. I 
thought we had agreement from the Chrome team that they would support 
them as well (c.f. our WebRTC office hours call on June 10th, where I 
recall you saying something to the effect of, "If we put them in the 
spec, then we should support them."). If that is not the plan, then we 
have a problem.

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Wed, 14 Aug 2013 05:42:58 -0700

> them as well (c.f. our WebRTC office hours call on June 10th, where I

Correction, June 12th.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 15 Aug 2013 16:21:06 +0200

> spec, then we should support them."). If that is not the plan, then we

I fully think we should support them in our implementations (as in -
parse them and obey the constraints they imply).

I just don't think we should, in the spec, mandate sending them.

To be specific: The change I think Cullen is suggesting is:

== OLD ==

   Required parameters:  none

   Optional parameters:

      max-fr, max-fs  These parameters MAY be used to signal the
         capabilities of a receiver implementation.  These parameters
         MUST NOT be used for any other purpose.

== NEW ==

   Required parameters: 

      max-fr, max-fs  These parameters MUST be used to signal the
         capabilities of a receiver implementation.  These parameters
         MUST NOT be used for any other purpose.

     Optional parameters: none

== END ==

If that's not the change you're suggesting, Cullen, please clarify.

(note: the MUST NOT language means that the parameters are not allowed in a
sendonly a=fmtp line, so they should probably be formally optional
anyway - either that, or my change proposal is incomplete.)

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 26 Aug 2013 16:57:19 +0200

Note that this is still awaiting:

1) Verification by Cullen that this change would satisfy his request
2) Consensus call by the chairs about whether or not this change should 
be made

---

From: "Roni Even" <[email-masked]>
Date: Thu, 29 Aug 2013 13:28:10 +0300

Hi Harald,
As individual I think this change make sense. H.264 has the level parameter
and a default value for it. So having these two parameters as required or
defining a default value if they are optional both work for.

Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Harald Alvestrand
> Sent: 15 August, 2013 5:21 PM
> To: [email-masked]
> Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt
> 
> >> I don't think this is because of "luck". I think it's because these
> >> are not the constraints that are the most constraining in most
> >> practical situations - other constraints make sure we never reach the
> >> limits that might have been encoded using max-fr and max-fs.
> >
> I fully think we should support them in our implementations (as in - parse
> them and obey the constraints they imply).
> 
> (note: the MUST NOT language means that the parameters are not allowed
> in a sendonly a=fmtp line, so they should probably be formally optional