Subject: [AVT] Definition of max-fps - related to draft-kristensen-avt-rtp-h241param discussion

From: Tom Kristensen <[email-masked]>
Date: Tue, 23 Nov 2010 09:59:58 +0100

AVT folks in general,
YK, Mo and Charles in particular;

You'll find my suggestion for text defining max-fps aimed for inclusion 
in RFC3984bis, as proposed by YK Wang. Please, change the text as needed 
for clarity, correctness and so on.

I earlier assumed it was too late to have any chance including max-fps 
in RFC3984bis, but as long as it's fine with YK Wang, the other authors 
of RFC3984bis, the authors of the SVC draft (where RFC3984bis is a 
normative reference) and the AVT chairs - I agree that having max-fps in 
RFC3984bis together with the rest of the "fmtp parameters" for H.264 is 
the best and indeed the ideal solution.

Proposal text:
       ------
       max-fps: The value of max-fps is an integer indicating the 
maximum frame rate in units of hundredths of frames per second that can 
be efficiently received.  The signaled highest level is conveyed in the 
value of the profile-level-id parameter or the max-recv-level parameter. 
The max-fps parameter MAY be used to signal that the receiver has a 
constraint in that it is capable of decoding video at a lower frame rate 
than is implied by the signaled highest level and, if present, one or 
more of the parameters max-mbps, max-smbps or max-fs.

       Notice that the value of max-fps is not necessarily the frame 
rate at which the maximum frame size can be sent, it constitutes a 
constraint on maximum frame rate for all resolutions.

            Informational note: The max-fps parameter is semantically 
different from max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br 
in that max-fps is used to signal a constraint, lowering the maximum 
frame rate from what is implied by the signaled MaxMBPS and MaxFS.

       The encoder MUST use a frame rate equal to or less than this 
value.  In cases where the max-fps parameter is absent, or not 
understood, the encoder is free to choose any frame rate according to 
the highest signaled level and any signaled optional parameters.
       ------

Some comments:

- Not possible to align with the "extending above level" semantics of 
existing max-* parameters.

- If integrated in RFC3984bis; may need to mention max-fps in Section 
14. Backward Compatibility to RFC 3984

- Don't see a need to add text pointing out the absolute maximum picture 
rate of 172 fps for all levels, as the encoder obviously has to follow 
the H.264 spec. (MaxMBPS/MaxFS) here.

- Don't mention a=framerate in RFC3984bis, as the SDP attribute applies 
to all video codecs in general anyway.

- Nobody raised any need for having the H.241 "... or the maximum 
picture rate that can be sent" semantics in SDP land during the 
discussion. Therefore, max-fps MUST NOT be present when the direction 
attribute is sendonly. max-fps is not usable as stream property (in 
declarative descriptions).

-- Tom

---

From: Ye-Kui Wang <[email-masked]>
Date: Fri, 26 Nov 2010 18:05:53 -0500

Basically OK to me, as an individual, co-author of RFC3984bis and co-author
of the SVC draft. What do AVT Chairs' and others think?

BR, YK 

> -----Original Message-----
> From: Tom Kristensen [mailto:[email-masked]] 
> Sent: Tuesday, November 23, 2010 4:00 AM
> To: 'IETF AVT WG'
> Cc: Ye-Kui Wang; Mo Zanaty (mzanaty); Charles Eckel 
> (eckelcu); Tom Kristensen
> Subject: Definition of max-fps - related to 
> draft-kristensen-avt-rtp-h241param discussion
> 
> AVT folks in general,
> You'll find my suggestion for text defining max-fps aimed for 
> inclusion in RFC3984bis, as proposed by YK Wang. Please, 
> change the text as needed for clarity, correctness and so on.
> 
> I earlier assumed it was too late to have any chance 
> including max-fps in RFC3984bis, but as long as it's fine 
> with YK Wang, the other authors of RFC3984bis, the authors of 
> the SVC draft (where RFC3984bis is a normative reference) and 
> the AVT chairs - I agree that having max-fps in RFC3984bis 
> together with the rest of the "fmtp parameters" for H.264 is 
>        max-fps: The value of max-fps is an integer indicating 
> the maximum frame rate in units of hundredths of frames per 
> second that can be efficiently received.  The signaled 
> highest level is conveyed in the value of the 
> profile-level-id parameter or the max-recv-level parameter. 
> The max-fps parameter MAY be used to signal that the receiver 
> has a constraint in that it is capable of decoding video at a 
> lower frame rate than is implied by the signaled highest 
> level and, if present, one or more of the parameters 
> max-mbps, max-smbps or max-fs.
> 
>        Notice that the value of max-fps is not necessarily 
> the frame rate at which the maximum frame size can be sent, 
> it constitutes a constraint on maximum frame rate for all resolutions.
> 
>             Informational note: The max-fps parameter is 
> semantically different from max-mbps, max-smbps, max-fs, 
> max-cpb, max-dpb, and max-br in that max-fps is used to 
> signal a constraint, lowering the maximum frame rate from 
> what is implied by the signaled MaxMBPS and MaxFS.
> 
>        The encoder MUST use a frame rate equal to or less 
> than this value.  In cases where the max-fps parameter is 
> absent, or not understood, the encoder is free to choose any 
> frame rate according to the highest signaled level and any 
> signaled optional parameters.
>        ------
> 
> 
> Some comments:
> 
> - Not possible to align with the "extending above level" 
> semantics of existing max-* parameters.
> 
> - If integrated in RFC3984bis; may need to mention max-fps in 
> Section 14. Backward Compatibility to RFC 3984
> 
> - Don't see a need to add text pointing out the absolute 
> maximum picture rate of 172 fps for all levels, as the 
> encoder obviously has to follow the H.264 spec. (MaxMBPS/MaxFS) here.
> 
> - Don't mention a=framerate in RFC3984bis, as the SDP 
> attribute applies to all video codecs in general anyway.
> 
> - Nobody raised any need for having the H.241 "... or the 
> maximum picture rate that can be sent" semantics in SDP land 
> during the discussion. Therefore, max-fps MUST NOT be present 
> when the direction attribute is sendonly. max-fps is not 
> usable as stream property (in declarative descriptions).
> 
> 
> -- Tom
>

---

From: Stephen Botzko <[email-masked]>
Date: Fri, 26 Nov 2010 21:32:25 -0500

Fine with me, I support this.

BR, Stephen Botzko

On Fri, Nov 26, 2010 at 6:05 PM, Ye-Kui Wang <[email-masked]> wrote:

> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 26 Nov 2010 20:51:52 -0600

I also support this and agree with the text.

Mo

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Botzko
Sent: Friday, November 26, 2010 9:32 PM
To: Ye-Kui Wang
Cc: Tom Kristensen; IETF AVT WG; Tom Kristensen
Subject: Re: [AVT] Definition of max-fps - related to
draft-kristensen-avt-rtp-h241param discussion

BR, Stephen Botzko

On Fri, Nov 26, 2010 at 6:05 PM, Ye-Kui Wang <[email-masked]>
wrote:

Basically OK to me, as an individual, co-author of RFC3984bis and
co-author
of the SVC draft. What do AVT Chairs' and others think?

BR, YK

---

From: Roni Even <[email-masked]>
Date: Sat, 27 Nov 2010 16:28:09 +0200

Hi Guys,

I am OK too. I will see when we can progress it.

Roni Even

AVT co-chair

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mo
Zanaty (mzanaty)
Sent: Saturday, November 27, 2010 4:52 AM
To: Stephen Botzko; Ye-Kui Wang
Cc: Tom Kristensen; IETF AVT WG; Tom Kristensen
Subject: Re: [AVT] Definition of max-fps - related to
draft-kristensen-avt-rtp-h241param discussion

Mo

  _____  

BR, Stephen Botzko

BR, YK

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sat, 27 Nov 2010 20:21:03 -0800

This looks good, and I am glad to see we have consensus to move forward
with it.

Cheers,
Charles

Roni Even
> Sent: Saturday, November 27, 2010 10:28 PM
> To: Mo Zanaty (mzanaty); 'Stephen Botzko'; 'Ye-Kui Wang'
> Cc: 'Tom Kristensen'; 'IETF AVT WG'; 'Tom Kristensen'
> Subject: Re: [AVT] Definition of max-fps - relatedto
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mo Zanaty (mzanaty)
>   ;< =MsoNormal align=center style='text-align:center'>
Stephen Botzko
wrote:
> 
> 
> Basically OK to me, as an ind ividual, and co-author
> > ; with Y of RFC3984bis, the authors of
> > level and, if present, one or more of the parameters< br>> x-fs.
> >
> & gt;
> & :
> > ; -- Tom __________________________________________

---

From: Peter Musgrave <[email-masked]>
Date: Sun, 28 Nov 2010 06:42:16 -0500

I also support this. 

I have a minor comment on the wording. 

"efficiently received"  makes me think I could go higher that the max-fps, it just would not be "efficient". Can we change this to just "received"?

"capable of decoding at a lower framerate" - similar wording issue. Most systems can decode at lower framerates than their max....
How about "is limited to decoding at a lower frame rate than is implied...." etc.

Thx

Peter Musgrave

On 2010-11-23, at 3:59 AM, Tom Kristensen wrote:

> You'll find my suggestion for text defining max-fps aimed for inclusion in RFC3984bis, as proposed by YK Wang. Please, change the text as needed for clarity, correctness and so on.
> 
> I earlier assumed it was too late to have any chance including max-fps in RFC3984bis, but as long as it's fine with YK Wang, the other authors of RFC3984bis, the authors of the SVC draft (where RFC3984bis is a normative reference) and the AVT chairs - I agree that having max-fps in RFC3984bis together with the rest of the "fmtp parameters" for H.264 is the best and indeed the ideal solution.
> 
> 
> Proposal text:
>      ------
>      max-fps: The value of max-fps is an integer indicating the maximum frame rate in units of hundredths of frames per second that can be efficiently received.  The signaled highest level is conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. The max-fps parameter MAY be used to signal that the receiver has a constraint in that it is capable of decoding video at a lower frame rate than is implied by the signaled highest level and, if present, one or more of the parameters max-mbps, max-smbps or max-fs.
> 
>      Notice that the value of max-fps is not necessarily the frame rate at which the maximum frame size can be sent, it constitutes a constraint on maximum frame rate for all resolutions.
> 
>           Informational note: The max-fps parameter is semantically different from max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br in that max-fps is used to signal a constraint, lowering the maximum frame rate from what is implied by the signaled MaxMBPS and MaxFS.
> 
>      The encoder MUST use a frame rate equal to or less than this value.  In cases where the max-fps parameter is absent, or not understood, the encoder is free to choose any frame rate according to the highest signaled level and any signaled optional parameters.
>      ------
> 
> 
> Some comments:
> 
> - Not possible to align with the "extending above level" semantics of existing max-* parameters.
> 
> - If integrated in RFC3984bis; may need to mention max-fps in Section 14. Backward Compatibility to RFC 3984
> 
> - Don't see a need to add text pointing out the absolute maximum picture rate of 172 fps for all levels, as the encoder obviously has to follow the H.264 spec. (MaxMBPS/MaxFS) here.
> 
> - Don't mention a=framerate in RFC3984bis, as the SDP attribute applies to all video codecs in general anyway.
> 
> - Nobody raised any need for having the H.241 "... or the maximum picture rate that can be sent" semantics in SDP land during the discussion. Therefore, max-fps MUST NOT be present when the direction attribute is sendonly. max-fps is not usable as stream property (in declarative descriptions).
> 
> 
> -- Tom

---

From: Stephen Botzko <[email-masked]>
Date: Sun, 28 Nov 2010 07:05:13 -0500

I think the wording we already have on the first point is correct.  The
proposed parameter adds a new constraint, and it might not be understood.
So in fact the receiver should be able to receive the full frame rate even
if it signals max-fps. However, such reception might require it to drop
frames after decoding, which is certainly not bandwidth efficient.

I agree that "receiver has a constraint in that it is capable of decoding
video at a lower frame rate" is a bit awkward text.  Maybe bring back in the
e-word:"receiver has a constraint in that it is not capable of decoding
video efficiently at the full frame rate that is implied by the signaled
highest level"

Stephen Botzko

On Sun, Nov 28, 2010 at 6:42 AM, Peter Musgrave <
[email-masked]> wrote:

> "efficiently received"  makes me think I could go higher that the max-fps,
> it just would not be "efficient". Can we change this to just "received"?
>
> "capable of decoding at a lower framerate" - similar wording issue. Most
> systems can decode at lower framerates than their max....
> in RFC3984bis, as proposed by YK Wang. Please, change the text as needed for
> clarity, correctness and so on.
> >
> > I earlier assumed it was too late to have any chance including max-fps in
> RFC3984bis, but as long as it's fine with YK Wang, the other authors of
> RFC3984bis, the authors of the SVC draft (where RFC3984bis is a normative
> reference) and the AVT chairs - I agree that having max-fps in RFC3984bis
> together with the rest of the "fmtp parameters" for H.264 is the best and
> indeed the ideal solution.
> >
> >
> > Proposal text:
> >      ------
> >      max-fps: The value of max-fps is an integer indicating the maximum
> frame rate in units of hundredths of frames per second that can be
> efficiently received.  The signaled highest level is conveyed in the value
> of the profile-level-id parameter or the max-recv-level parameter. The
> max-fps parameter MAY be used to signal that the receiver has a constraint
> in that it is capable of decoding video at a lower frame rate than is
> implied by the signaled highest level and, if present, one or more of the
> parameters max-mbps, max-smbps or max-fs.
> >
> >      Notice that the value of max-fps is not necessarily the frame rate
> at which the maximum frame size can be sent, it constitutes a constraint on
> maximum frame rate for all resolutions.
> >
> different from max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br in
> that max-fps is used to signal a constraint, lowering the maximum frame rate
> from what is implied by the signaled MaxMBPS and MaxFS.
> >
> >      The encoder MUST use a frame rate equal to or less than this value.
>  In cases where the max-fps parameter is absent, or not understood, the
> encoder is free to choose any frame rate according to the highest signaled
> level and any signaled optional parameters.
> >      ------
> >
> >
> > Some comments:
> >
> rate of 172 fps for all levels, as the encoder obviously has to follow the
> H.264 spec. (MaxMBPS/MaxFS) here.
> >
> > - Nobody raised any need for having the H.241 "... or the maximum picture
> rate that can be sent" semantics in SDP land during the discussion.
> Therefore, max-fps MUST NOT be present when the direction attribute is
> sendonly. max-fps is not usable as stream property (in declarative
> descriptions).
> >
> >
> > -- Tom

---

From: Peter Musgrave <[email-masked]>
Date: Sun, 28 Nov 2010 09:21:12 -0500

Inline

Sent from my iPad

On 2010-11-28, at 7:05 AM, Stephen Botzko <[email-masked]> wrote:

> I think the wording we already have on the first point is correct.  The proposed parameter adds a new constraint, and it might not be understood.  So in fact the receiver should be able to receive the full frame rate even if it signals max-fps. However, such reception might require it to drop frames after decoding, which is certainly not bandwidth efficient.
Agreed.

> 
> I agree that "receiver has a constraint in that it is capable of decoding video at a lower frame rate" is a bit awkward text.  Maybe bring back in the e-word:"receiver has a constraint in that it is not capable of decoding video efficiently at the full frame rate that is implied by the signaled highest level
Ok. (it's the addition of the "not" which makes this work for me)
> 
> Stephen Botzko
> 
> 
> On Sun, Nov 28, 2010 at 6:42 AM, Peter Musgrave <[email-masked]> wrote:
> I also support this.
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 28 Nov 2010 22:51:15 +0100

(As WG co-chair)

draft-ietf-avt-rtp-rfc3984bis has been through IETF last call and is currently back with the IESG undergoing evaluation.

Adding extra material to the document now (rather than correcting existing material) essentially stops the clock and probably puts the document back to the working group. At that point we possibly restart WG last calls, publication request and IETF last call.

And it is not just a matter of the editor being fine with the change, but a matter of the WG, as this is a working group document.

When the chairs were discussing this at the time of the last meeting, we were thinking that this would probably go into a rfc3984ter document, where we would collect enhancements that are not in the bis document. That of course assume that there might be other enhancements in the future, or that this one by itself is sufficiently important to justify the issue of a new RFC.

Therefore I would like to hear opinions expressed by the WG one way or the other - delay the existing publication, or start a new revision of RFC 3984 that will eventually reach publication in the future, but not delay the existing one.

Keith

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
	Sent: Saturday, November 27, 2010 2:28 PM
	To: 'Mo Zanaty (mzanaty)'; 'Stephen Botzko'; 'Ye-Kui Wang'
	Cc: 'Tom Kristensen'; 'IETF AVT WG'; 'Tom Kristensen'
	Subject: Re: [AVT] Definition of max-fps - related to draft-kristensen-avt-rtp-h241param discussion

	Hi Guys,

	Roni Even

	AVT co-chair

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Mo Zanaty (mzanaty)
	Sent: Saturday, November 27, 2010 4:52 AM
	To: Stephen Botzko; Ye-Kui Wang
	Cc: Tom Kristensen; IETF AVT WG; Tom Kristensen
	Subject: Re: [AVT] Definition of max-fps - related to draft-kristensen-avt-rtp-h241param discussion

	Mo

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Botzko
	Sent: Friday, November 26, 2010 9:32 PM
	To: Ye-Kui Wang
	Cc: Tom Kristensen; IETF AVT WG; Tom Kristensen
	Subject: Re: [AVT] Definition of max-fps - related to draft-kristensen-avt-rtp-h241param discussion

	BR, Stephen Botzko

	
	BR, YK

	& gt;

---

From: Peter Musgrave <[email-masked]>
Date: Sun, 28 Nov 2010 17:12:06 -0500

Hi, 

I am reluctant to restart the clock - the bis is a BIG improvement and it needs to get finished. 

I think collecting enhancements in a "ter" makes sense (or even just a short, simple doc to describe max-fps). 

Peter Musgrave

---

From: Ye-Kui Wang <[email-masked]>
Date: Sun, 28 Nov 2010 23:46:46 -0500

+1. 

While it is good to include the max-fps already in the RFC3984bis, I am very
reluctant to delay the RFC3984bis progress, which IMO has been delayed a
couple of times already. 

BR,YK 

> From: Peter Musgrave [mailto:[email-masked]] 
> Sent: Sunday, November 28, 2010 5:12 PM
> To: DRAGE, Keith (Keith)
> Cc: Roni Even; 'Mo Zanaty (mzanaty)'; 'Stephen Botzko'; 
> 'Ye-Kui Wang'; 'Tom Kristensen'; 'IETF AVT WG'; 'Tom Kristensen'
> I am reluctant to restart the clock - the bis is a BIG 
> improvement and it needs to get finished. 
> 
> I think collecting enhancements in a "ter" makes sense (or 
> even just a short, simple doc to describe max-fps). 
> 
> Peter Musgrave
> 
> > draft-ietf-avt-rtp-rfc3984bis has been through IETF last 
> call and is currently back with the IESG undergoing evaluation.
> > 
> > Adding extra material to the document now (rather than 
> correcting existing material) essentially stops the clock and 
> probably puts the document back to the working group. At that 
> point we possibly restart WG last calls, publication request 
> and IETF last call.
> > 
> > And it is not just a matter of the editor being fine with 
> the change, but a matter of the WG, as this is a working 
> group document.
> > 
> > When the chairs were discussing this at the time of the 
> last meeting, we were thinking that this would probably go 
> into a rfc3984ter document, where we would collect 
> enhancements that are not in the bis document. That of course 
> assume that there might be other enhancements in the future, 
> or that this one by itself is sufficiently important to 
> justify the issue of a new RFC.
> > 
> > Therefore I would like to hear opinions expressed by the WG 
> one way or the other - delay the existing publication, or 
> start a new revision of RFC 3984 that will eventually reach 
> publication in the future, but not delay the existing one.
> > 
> > Keith
> > 
> > 
> > 	From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Roni Even
> > 	From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mo Zanaty (mzanaty)
> > 	From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Botzko

---

From: Roni Even <[email-masked]>
Date: Mon, 29 Nov 2010 09:00:19 +0200

Hi YK,
The idea is not to add it to 3984bis but to have it as a separate document
updating it and merge it if and when we will have a new revision to the
H.264 payload.
This new document can be used to add other updates to H.264 payload if
needed.
We did this in the past for RFC3984

Roni Even
AVT co-chair

> From: Ye-Kui Wang [mailto:[email-masked]]
> Sent: Monday, November 29, 2010 6:47 AM
> To: 'Peter Musgrave'; 'DRAGE, Keith (Keith)'
> Cc: 'Roni Even'; 'Mo Zanaty (mzanaty)'; 'Stephen Botzko'; 'Tom
> Kristensen'; 'IETF AVT WG'; 'Tom Kristensen'
> Subject: RE: [AVT] Definition of max-fps - related to draft-kristensen-
> avt-rtp-h241param discussion
> 
> 
> +1.
>

---

From: Tom Kristensen <[email-masked]>
Date: Mon, 29 Nov 2010 14:50:42 +0100

Thanks to Peter for raising the issues here, and to Stephen for 
explaining and proposing new text.

The new text is fine with me. The full sentence now reads:

"The max-fps parameter MAY be used to signal that the receiver has a 
constraint in that it is not capable of decoding video efficiently at 
the full frame rate that is implied by the signaled highest level and, 
if present, one or more of the parameters max-mbps, max-smbps or max-fs."

-- Tom

On 11/28/2010 01:05 PM, Stephen Botzko wrote:
> proposed parameter adds a new constraint, and it might not be
> understood.  So in fact the receiver should be able to receive the full
> frame rate even if it signals max-fps. However, such reception might
> require it to drop frames after decoding, which is certainly not
> bandwidth efficient.
>
> I agree that "receiver has a constraint in that it is capable of
> decoding video at a lower frame rate" is a bit awkward text.  Maybe
> bring back in the e-word:"receiver has a constraint in that it is not
> capable of decoding video efficiently at the full frame rate that is
> implied by the signaled highest level"
>
> Stephen Botzko
>
>
> On Sun, Nov 28, 2010 at 6:42 AM, Peter Musgrave
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I also support this.
>
>     "efficiently received"  makes me think I could go higher that the
>     max-fps, it just would not be "efficient". Can we change this to
>     just "received"?
>
>     "capable of decoding at a lower framerate" - similar wording issue.
>     Most systems can decode at lower framerates than their max....
>     inclusion in RFC3984bis, as proposed by YK Wang. Please, change the
>     text as needed for clarity, correctness and so on.
>      >
>      > I earlier assumed it was too late to have any chance including
>     max-fps in RFC3984bis, but as long as it's fine with YK Wang, the
>     other authors of RFC3984bis, the authors of the SVC draft (where
>     RFC3984bis is a normative reference) and the AVT chairs - I agree
>     that having max-fps in RFC3984bis together with the rest of the
>     "fmtp parameters" for H.264 is the best and indeed the ideal solution.
>      >
>      >
>      > Proposal text:
>      >      ------
>     maximum frame rate in units of hundredths of frames per second that
>     can be efficiently received.  The signaled highest level is conveyed
>     in the value of the profile-level-id parameter or the max-recv-level
>     parameter. The max-fps parameter MAY be used to signal that the
>     receiver has a constraint in that it is capable of decoding video at
>     a lower frame rate than is implied by the signaled highest level
>     and, if present, one or more of the parameters max-mbps, max-smbps
>     or max-fs.
>      >
>      >      Notice that the value of max-fps is not necessarily the
>     frame rate at which the maximum frame size can be sent, it
>     constitutes a constraint on maximum frame rate for all resolutions.
>      >
>     semantically different from max-mbps, max-smbps, max-fs, max-cpb,
>     max-dpb, and max-br in that max-fps is used to signal a constraint,
>     lowering the maximum frame rate from what is implied by the signaled
>     MaxMBPS and MaxFS.
>      >
>     understood, the encoder is free to choose any frame rate according
>     to the highest signaled level and any signaled optional parameters.
>      >      ------
>      >
>      >
>      > Some comments:
>      >
>      > - Don't see a need to add text pointing out the absolute maximum
>     picture rate of 172 fps for all levels, as the encoder obviously has
>     to follow the H.264 spec. (MaxMBPS/MaxFS) here.
>      >
>      > - Don't mention a=framerate in RFC3984bis, as the SDP attribute
>     applies to all video codecs in general anyway.
>      >
>     discussion. Therefore, max-fps MUST NOT be present when the
>     direction attribute is sendonly. max-fps is not usable as stream
>     property (in declarative descriptions).
>      >
>      >
>      > -- Tom
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Tom Kristensen <[email-masked]>
Date: Mon, 29 Nov 2010 15:14:42 +0100

Severely delaying RFC3984bis is not an option, so the idea of a H.264 
RTP payload extensions/additions placeholder draft seems to be a good 
solution.

I'll update draft-kristensen-avt-rtp-h241param with the new max-fps text 
for the record and we'll consider later the form and shape of this 
RFC3984ter draft.

-- Tom

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 29 Nov 2010 09:09:20 -0800

I think that a companion document is a good idea.  We have already the
RCDO RFC-to-be that could be integrated into 3984-ter, what difference
would make another document?  It also looks like H.264 is going to be with
us for a while, which also suggests that there should be another revision.
Stephan
(I do recall the politics that made RCDO go into its own document, rather
than into 3984bis.  However, those political reasons, in contrast to the
usefulness of 3984 as a whole, have IMO rather lost their utility.)

---

From: David Singer <[email-masked]>
Date: Mon, 29 Nov 2010 12:31:31 -0800

two comments

a) RTP has per-frame timing, thus implicitly allowing variable frame rates.  you might need a formal definition of the frame rate (is it really the inverse of the minimum inter-frame time?

b) maybe parameters like this that are media-specific (video) rather than code-specific (H.264) could be documented once, centrally, and then re-used as needed?

>>> 	https://www.ietf.org/mailman/listinfo/avt

David Singer
Multimedia and Software Standards, Apple Inc.