Subject: [AVT] Question about draft-kristensen-avt-rtp-h241para

From: Cullen Jennings <[email-masked]>
Date: Sat, 6 Nov 2010 18:14:33 -0600

I'm trying to understand the places where one would use this new max-fps instead of framerate. The drafts mentions in section 1.2 about a case where different codecs in the same media section would have different max frame rates. Could you tell me a bit more about the uses cases where this would practically happen within the context of it is all H.264? I'm trying to think about if the limit is the actually the Max MBPS or frame rate or what exactly is the semantic level information we need to be able to signal.

---

From: Stephen Botzko <[email-masked]>
Date: Sat, 6 Nov 2010 22:40:26 -0400

On the use cases, here is the most common scenario:  You have a decoder
which can receive 1080p30 but cannot receive 720p60.  Some systems like this
do exist.  Within the normal level/profile signaling, you cannot signal this
exclusion, the max-mbps alone is not enough.  However, if this proposal is
accepted, you can signal it as Level 3.1 by adding both max-mbps and the
proposed max-fps.

Also note that in most commercial video conferencing systems, there are
usually two video streams available - one for normal camera, the second for
a presentation stream.  Often the presentation decoder is optimized for PC
screens, using high resolution and and low frame rates.  For instance, some
systems are limited to 5 fps for their presentation video. This makes use of
the global frame rate parameter very problematic.

As far as semantic level information goes, the main reason for doing it this
way is to maintain functional equivalence with H.241.  We are seeing a lot
of interest in building SBCs and other devices that convert H.323 signaling
to SIP, but which do not touch the RTP streams.  If the H.323 system signals
max-fps, then it is desirable for the converted SDP messages to use fully
equivalent semantics.  I see no reason to create new semantics, I think that
creates more problems than it solves.

Max-fps offers precise equivalence with H.241, allows the presentation
stream to be regulated separately from the main video channel, and has no
side effects on other codec signaling.

Stephen Botzko

On Sat, Nov 6, 2010 at 8:14 PM, Cullen Jennings <[email-masked]> wrote:

>
> I'm trying to understand the places where one would use this new max-fps
> instead of framerate. The drafts mentions in section 1.2 about a case where
> different codecs in the same media section would have different max frame
> rates. Could you tell me a bit more about the uses cases where this would
> practically happen within the context of it is all H.264? I'm trying to
> think about if the limit is the actually the Max MBPS or frame rate or what
> exactly is the semantic level information we need to be able to signal.
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Tom Kristensen <[email-masked]>
Date: Sun, 7 Nov 2010 16:30:53 +0100

Well, if you are limiting the interesting use cases to H.264 only
calls some of the descriptions in the draft are not that - eh -
interesting. I don't have an use case where a system adding multiple
H.264 payloads is likely to use different max-fps amongst them.

<speculations>Of course, it might happen of reasons my brain is too
restricted imaging just now. The only thing I'm able to think of is a
case where the H.264 payloads have different profiles, where the
Baseline profile aimed at interactive traffic might desire higher
frame rate than a payload using the Main profile. Here the
application/system logic and policies might decide to use different
H.264 profiles (and frame rate) depending on traffic characteristics,
call type (video conference in lecture mode/general "meeting mode") or
something else. </speculations>

Back to reality: A more compelling argument for max-fps in an H.264
only scenario is to facilitate signalling translation between H.323
and SIP.

Regarding whether MaxMBPS is sufficient, a quick look at the nice :-)
ASCII art graphs in the draft might be worth it. MaxFPS was added to
H.241 (and hopefully adopted in the world of SDP) also to optimise the
resolution choices.

-- Tom

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 8 Nov 2010 21:06:28 -0700

Tom & Stephen - thanks for the answers - these and the presentation in the meeting helped me understand. One comment inline ...

On Nov 6, 2010, at 8:40 PM, Stephen Botzko wrote:

> On the use cases, here is the most common scenario:  You have a decoder which can receive 1080p30 but cannot receive 720p60.  Some systems like this do exist.  Within the normal level/profile signaling, you cannot signal this exclusion, the max-mbps alone is not enough.  However, if this proposal is accepted, you can signal it as Level 3.1 by adding both max-mbps and the proposed max-fps.
> 
> Also note that in most commercial video conferencing systems, there are usually two video streams available - one for normal camera, the second for a presentation stream.  Often the presentation decoder is optimized for PC screens, using high resolution and and low frame rates.  For instance, some systems are limited to 5 fps for their presentation video. This makes use of the global frame rate parameter very problematic.

It seems like in this one case where you had on video stream for the normal camera at say 30fps and the second stream for presentation at say 5fps, they could both have seperate framerate attributes so I'm not sure I see this case being a driver.

> 
> As far as semantic level information goes, the main reason for doing it this way is to maintain functional equivalence with H.241.  We are seeing a lot of interest in building SBCs and other devices that convert H.323 signaling to SIP, but which do not touch the RTP streams.  If the H.323 system signals max-fps, then it is desirable for the converted SDP messages to use fully equivalent semantics.  I see no reason to create new semantics, I think that creates more problems than it solves.  
> 
> Max-fps offers precise equivalence with H.241, allows the presentation stream to be regulated separately from the main video channel, and has no side effects on other codec signaling.
> 
> Stephen Botzko
> 
>

---

From: Stephen Botzko <[email-masked]>
Date: Tue, 9 Nov 2010 13:44:06 +0800

It seems like in this one case where you had on video stream for the
normal camera at say 30fps
and the second stream for presentation at say 5fps, they could both
have seperate framerate attributes
so I'm not sure I see this case being a driver.

The "a=framerate" attribute applies to all video payloads in the media
section to which it belongs.

Stephen Botzko

On Tue, Nov 9, 2010 at 12:06 PM, Cullen Jennings <[email-masked]> wrote:

>
>
> Tom & Stephen - thanks for the answers - these and the presentation in the
> meeting helped me understand. One comment inline ...
>
>
> It seems like in this one case where you had on video stream for the normal
> camera at say 30fps and the second stream for presentation at say 5fps, they
> could both have seperate framerate attributes so I'm not sure I see this
> case being a driver.
>
> >
> > As far as semantic level information goes, the main reason for doing it
> this way is to maintain functional equivalence with H.241.  We are seeing a
> lot of interest in building SBCs and other devices that convert H.323
> signaling to SIP, but which do not touch the RTP streams.  If the H.323
> system signals max-fps, then it is desirable for the converted SDP messages
> to use fully equivalent semantics.  I see no reason to create new semantics,
> I think that creates more problems than it solves.
> >

---

From: Roni Even <[email-masked]>
Date: Tue, 09 Nov 2010 08:21:27 +0200

Cullen,
Maybe it can be described similar to what we have in H.261 and H.263 where
we can specify a max frame rate per resolution.

The use case is if you have distinct points that can be supported that are
not linear. 
If you use the a=framerate with the maxmbps you have a linear relation. 

If you need another relation you need to specify in the same m-line
different payload type numbers each with a different frame rate

m=video 49170 RTP/AVP 98 99
      a=rtpmap:98 H264/90000
      a=fmtp:98 profile-level-id=42A01E; max-fps=2997  
      a=rtpmap:99 H264/90000
      a=fmtp:99 profile-level-id=42A01E; max-fps=6000

This is not feasible with a=framerate , using maxmbps will not solve it
since you can have the same frame rate with different reolutions.

I think that the draft should describe such a use case and show it in the
appendix

Roni
 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Cullen Jennings
> Sent: Sunday, November 07, 2010 2:15 AM
> To: IETF AVT WG
> Subject: [AVT] Question about draft-kristensen-avt-rtp-h241para
> 
> 
> I'm trying to understand the places where one would use this new max-
> fps instead of framerate. The drafts mentions in section 1.2 about a
> case where different codecs in the same media section would have
> different max frame rates. Could you tell me a bit more about the uses
> cases where this would practically happen within the context of it is
> all H.264? I'm trying to think about if the limit is the actually the
> Max MBPS or frame rate or what exactly is the semantic level
> information we need to be able to signal.
> 
>

---

From: Tom Kristensen <[email-masked]>
Date: Wed, 10 Nov 2010 15:22:42 +0100

To summarize:
(i) The need for signalling the decoder's max framerate preference is
agreed upon, given
(ii) the super-flexible H.264 signalling approach and parameter set.
(iii) Use of MaxMBPS and MaxFS underspecifies the stream with
potential consequences as mentioned in the draft (non-optimal
resolution choices, resource waste).
(iv) The need for H.264 max-fps fmtp parameter is not clearly understood.
(v) Using max-fps to facilitate straight forward signalling
translation H.323 <=> SIP seems plausible.

However, we have the existing a=framerate attribute for video in SDP.
As Jonathan Lennox pointed out in the AVT session on Monday, the use
of MPI for H.261/H.263 as an example in the draft may very well be
used to contradict the other arguments for a=framerate not always
being usable. I didn't quite get that point during the presentation,
and our aim was to use this as an example of _that_ other codecs have
a way to signal framerate, so why not allow H.264 to have one.

However, as Jonathan pointed out; if all other codecs has a way to
signal framerate limit the a=framerate can still be usable for H.264
in a sense. This makes - to a certain degree - only sense until a new
codec potentially is introduced with framerate support way above
H.264.

I will use Roni's sketch below to make an example of how max-fps might
be useful even for cases where H.264 is the only codec present in the
media section. This will be included as an example in the appendix as
additional motivation for adding max-fps in the next version of the
draft:

Some video endpoints have a setting to indicate preference for
"motion" or "sharpness", based on type of input device (camera, VCR,
...) or type of scene the camera typically will capture (meeting room,
martial art performance, ...). Based on this the endpoint will trade
between amongst other things framerate (for motion) and resolution
(for sharpness). Something along the lines of:

  m=video 49170 RTP/AVP 98 99
  a=rtpmap:98 H264/90000
  a=fmtp:98 profile-level-id=42A0<High Level>; max-fps=2997; max-fs=<High level>
  a=rtpmap:99 H264/90000
  a=fmtp:99 profile-level-id=42A0<Lower Level>; max-fps=6000;

Hope this makes sense,
-- Tom

-- 
# Cisco                         |  http://www.cisco.com/telepresence/
## [email-masked]  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 10 Nov 2010 16:31:28 -0500

I doubt that the "preference" use of the proposed max-fps parameter makes
much sense. 

First, per RFC3984bis, max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and
max-br MAY be used to signal the capabilities of a receiver implementation
and they MUST NOT be used for any other purpose. It would be weird to have
all those max-* being capability parameters and this one being preference.
There can be many other types of preferences, and this one is surely not the
more urgent one needing a signailng. Second, even if there is a need for
indicating such a preference, it is not codec specific, and a generic
signaling should be pursued. Third, whether a video content is better in the
form of higher frame rate or higher resolution really depends mainly on the
characteristics of the content itself and may also slightly depend on the
encoding method, and figuring this out itself is not easy, and moreover, the
receiver has no way to have an indication of this before receiving the
content, and the encoder has no way to have indication of this before the
content is available/captured. Fourth, if the semantics of the correponding
parameter in H.241 indicate capability (which is the case in my
understanding), the intended signaling translation is then not possible.

Therefore, I still don't see a need of this new parameter, though adding it
is easy. 

BR, YK

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Tom Kristensen
> Sent: Wednesday, November 10, 2010 9:23 AM
> To: Roni Even
> Cc: Cullen Jennings; IETF AVT WG
> Subject: Re: [AVT] Question about draft-kristensen-avt-rtp-h241para
> 
> To summarize:
> (i) The need for signalling the decoder's max framerate 
> preference is agreed upon, given
> As Jonathan Lennox pointed out in the AVT session on Monday, 
> the use of MPI for H.261/H.263 as an example in the draft may 
> very well be used to contradict the other arguments for 
> a=framerate not always being usable. I didn't quite get that 
> point during the presentation, and our aim was to use this as 
> an example of _that_ other codecs have a way to signal 
> framerate, so why not allow H.264 to have one.
> 
> However, as Jonathan pointed out; if all other codecs has a 
> way to signal framerate limit the a=framerate can still be 
> usable for H.264 in a sense. This makes - to a certain degree 
> - only sense until a new codec potentially is introduced with 
> framerate support way above H.264.
> 
> I will use Roni's sketch below to make an example of how 
> max-fps might be useful even for cases where H.264 is the 
> only codec present in the media section. This will be 
> included as an example in the appendix as additional 
> motivation for adding max-fps in the next version of the
> draft:
> 
> Some video endpoints have a setting to indicate preference 
> for "motion" or "sharpness", based on type of input device 
> (camera, VCR,
> ...) or type of scene the camera typically will capture 
> (meeting room, martial art performance, ...). Based on this 
> the endpoint will trade between amongst other things 
> framerate (for motion) and resolution (for sharpness). 
> Something along the lines of:
> 
> > Maybe it can be described similar to what we have in H.261 
> and H.263 
> > where we can specify a max frame rate per resolution.
> >
> > The use case is if you have distinct points that can be 
> supported that 
> > are not linear.
> > This is not feasible with a=framerate , using maxmbps will 
> not solve 
> > it since you can have the same frame rate with different reolutions.
> >
> > I think that the draft should describe such a use case and 
> show it in 
> > the appendix
> >
> > Roni
> >
> >> different max frame rates. Could you tell me a bit more about the 
> >> uses cases where this would practically happen within the 
> context of 
> >> it is all H.264? I'm trying to think about if the limit is the 
> >> actually the Max MBPS or frame rate or what exactly is the 
> semantic 
> >> level information we need to be able to signal.
> >>
> >>
> ## [email-masked]  |  http://www.tandberg.com ###         
>                       |  http://folk.uio.no/tomkri/

---

From: Stephen Botzko <[email-masked]>
Date: Thu, 11 Nov 2010 07:31:12 +0800

Fourth, if the semantics of the correponding
parameter in H.241 indicate capability (which is the case in my
understanding), the intended signaling translation is then not possible.

The H.245 capability set would include two H.264 capabilities, one for each
mode.  The appropriate capability is also placed in OLC command.  Therefore
the normal translation between offer/answer and OLC/OLC-ACK works.

I agree that this particular example is somewhat contrived.

But I support adding max-fps. There are use cases for it. For instance there
are deployed H.323 systems that cannot receive 720p60 but can receive
1080p30.  Another example is a system designed to send PC content with a
high resolution but very low frame rate.  The most direct way to ensure
interoperability for such systems through non-transcoding gateways is to add
max-fps.

Perhaps a=framerate can be made to work in many scenarios.  The logic for
finding the lowest frame rate for every offered codec, and then setting
a=framerate to the minimum in the set is somewhat messy.  And forcing the
framerate for *every* offered video stream to be the lowest frame rate found
in  the entire set of offers is a bad signaling design.

Clearly it does no harm, and it does improve interoperability on some
calls.  As you point out, it is easy to do.  As Tom points out, every other
video codec used in videoconferencing has a parameter to set the framerate
ceiling for a specific payload type.  Personally, I think we should just add
it.

Stephen Botzko

---

From: Roni Even <[email-masked]>
Date: Thu, 11 Nov 2010 01:39:11 +0200

Hi YK,
The major problem is that a non codec specific parameter applies to all the
offered configuration in the same m-line while if you want to show a
different capability (or preference ) for each configuration in the m-line
it should be a codec parameter. You can do it currently for H.261 and H.263
but not for H.264

Roni

> From: Ye-Kui Wang [mailto:[email-masked]]
> Sent: Wednesday, November 10, 2010 11:31 PM
> To: 'Tom Kristensen'; 'Roni Even'
> Cc: 'Cullen Jennings'; 'IETF AVT WG'
> Subject: RE: [AVT] Question about draft-kristensen-avt-rtp-h241para
> 
>

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 11 Nov 2010 07:50:45 +0800

+1

Peter Musgrave

On 2010-11-11, at 7:31 AM, Stephen Botzko wrote:

> But I support adding max-fps. There are use cases for it. For instance there are deployed H.323 systems that cannot receive 720p60 but can receive 1080p30.  Another example is a system designed to send PC content with a high resolution but very low frame rate.  The most direct way to ensure interoperability for such systems through non-transcoding gateways is to add max-fps.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 10 Nov 2010 19:12:16 -0800

I think max-fps is needed, but I do tend to agree that treating it as a capability rather than as a preference is more natural in the context of the H.264 offer/answer model. Of course, including max-fps in your offer/answer does not guarantee it will be honored since the other side may not understand this new parameter, but assuming it does understand it, I think it is best to say it MUST honor it.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ye-Kui Wang
> Sent: Thursday, November 11, 2010 5:31 AM
> Cc: Cullen Jennings (fluffy); 'IETF AVT WG'

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 10 Nov 2010 22:40:49 -0500

I have one more concern about what the semantics would be if it is treated
as capability. IMO, the semantics must not conflict with the level part of
the profile-level-id, max-fs, and max-mbps, as these three parameters in
combination already imply a maximum frame rate. Related to this, for the
other max-* parameters, the current rule is that, when present, the
corresponding signaled capability must be higher than what is implied by the
level, the rule for max-fps needs also to be clearly specified (I guess it
is impossible to align with other max-* parameters herein). Could the
authors clarify this issue?

If many people support to have the parameter (as it seems so) and if the
above issue is not a problem, then I would not insist my objection. If the
consensus is positive, I'd prefer to 1) treat it as capability, as Charles
also agreed, and 2) add it directly to RFC3984bis, quickly, such that it is
included in the soon-to-be published RFC.

BR, YK 

> From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
> Sent: Wednesday, November 10, 2010 10:12 PM
> To: Ye-Kui Wang; Tom Kristensen; Roni Even
> Cc: Cullen Jennings (fluffy); IETF AVT WG
> I think max-fps is needed, but I do tend to agree that 
> treating it as a capability rather than as a preference is 
> more natural in the context of the H.264 offer/answer model. 
> Of course, including max-fps in your offer/answer does not 
> guarantee it will be honored since the other side may not 
> understand this new parameter, but assuming it does 
> understand it, I think it is best to say it MUST honor it.
> 
> Cheers,
> Charles
> 
> Behalf Of 
> > Ye-Kui Wang
> > I doubt that the "preference" use of the proposed max-fps parameter 
> > makes much sense.
> > 
> > First, per RFC3984bis, max-mbps, max-smbps, max-fs, 
> max-cpb, max-dpb, 
> > and max-br MAY be used to signal the capabilities of a receiver 
> > implementation and they MUST NOT be used for any other purpose. It 
> > would be weird to have all those max-* being capability 
> parameters and this one being preference.
> > There can be many other types of preferences, and this one 
> is surely 
> > not the more urgent one needing a signailng. Second, even 
> if there is 
> > a need for indicating such a preference, it is not codec 
> specific, and 
> > a generic signaling should be pursued. Third, whether a 
> video content 
> > is better in the form of higher frame rate or higher 
> resolution really 
> > depends mainly on the characteristics of the content itself and may 
> > also slightly depend on the encoding method, and figuring this out 
> > itself is not easy, and moreover, the receiver has no way 
> to have an 
> > indication of this before receiving the content, and the 
> encoder has 
> > no way to have indication of this before the content is 
> > available/captured. Fourth, if the semantics of the correponding 
> > parameter in H.241 indicate capability (which is the case 
> in my understanding), the intended signaling translation is 
> then not possible.
> > 
> > Therefore, I still don't see a need of this new parameter, though 
> > adding it is easy.
> > 
> > BR, YK
> > 
> > > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > > Of Tom Kristensen
> > > and our aim was to use this as an example of _that_ other codecs 
> > > have a way to signal framerate, so why not allow H.264 to 
> have one.
> > >
> > > in a sense. This makes - to a certain degree
> > > I will use Roni's sketch below to make an example of how max-fps 
> > > might be useful even for cases where H.264 is the only 
> codec present 
> > > in the media section. This will be included as an example in the 
> > > appendix as additional motivation for adding max-fps in the next 
> > > version of the
> > > draft:
> > >
> > > ...) or type of scene the camera typically will capture (meeting 
> > > room, martial art performance, ...). Based on this the 
> endpoint will 
> > > trade between amongst other things framerate (for motion) and 
> > > resolution (for sharpness).
> > > > If you need another relation you need to specify in the same 
> > > > m-line different payload type numbers each with a 
> different frame 
> > > > rate
> > > >
> > > >
> > > >
> > > >> Audio/Video Transport Working Group [email-masked] 
> > > > Audio/Video Transport Working Group [email-masked]

---

From: Tom Kristensen <[email-masked]>
Date: Thu, 11 Nov 2010 12:17:48 +0100

Hmmm. I'll have to digest this proposal.

One thing is that this is not along the lines of MaxFPS in H.241.
Where it is introduced as a constraint.

If YK's proposal makes sense, then another thing is the lack of
"normative values" for the maximum frame rate supported per level in
H.264 Table A-1. (On the other hand Table A-6 lists maximum frame
rates for selected, example resolutions - in a non-normative fashion.)
Of course, it's possible to compute the maximum frame rate from the
other parameters (to verify the signalling). There's not as easy as
when using the phrase used for the other max-* parameters:
          The value of max-* MUST be
          greater than or equal to the value of Max* given in Table
          A-1 of [1] for the highest level.

-- Tom

On 11 November 2010 04:40, Ye-Kui Wang <[email-masked]> wrote:
>> > > On Behalf Of

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 11 Nov 2010 07:31:27 -0600

Tom,
172 fps is the normative value for the maximum frame rate for all levels in the H.264 standard. See section A.3. It is not included in Table A-1, which provides normative level limits, because it is the same for all levels. Table A-6 merely provides informative values for common resolutions, but it is clear to see that it saturates at 172 fps at higher levels. If Table A-6 included a tiny resolution such as 64x32, it would be even clearer that all levels support and saturate at 172 fps.

I think YK was just pointing out that the text should clarify this new max-fps is a constraint that reduces the default level limit (172 fps), unlike other max-* parameters which extend/increase the default level limit. You could also note that it MUST be 172 fps or lower.

Mo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Kristensen
Sent: Thursday, November 11, 2010 6:18 AM
To: Ye-Kui Wang
Cc: Cullen Jennings (fluffy); Tom Kristensen; Roni Even; IETF AVT WG
Subject: Re: [AVT] Question about draft-kristensen-avt-rtp-h241para

-- Tom

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 11 Nov 2010 12:19:27 -0500

Mo,

I did not mean the 172 fps hard upper limit on frame rate, but the one
implied by max-mbps and the spatial resolution. max-mbps gives the decoding
capability in terms of the max number of MBs per second. Given max-mbps, the
implied max frame frame rate is inversely proportional to the spatial
resolution.

BR, YK

> From: Mo Zanaty (mzanaty) [mailto:[email-masked]] 
> Sent: Thursday, November 11, 2010 8:31 AM
> To: Tom Kristensen; Ye-Kui Wang
> 172 fps is the normative value for the maximum frame rate for 
> all levels in the H.264 standard. See section A.3. It is not 
> included in Table A-1, which provides normative level limits, 
> because it is the same for all levels. Table A-6 merely 
> provides informative values for common resolutions, but it is 
> clear to see that it saturates at 172 fps at higher levels. 
> If Table A-6 included a tiny resolution such as 64x32, it 
> would be even clearer that all levels support and saturate at 172 fps.
> 
> I think YK was just pointing out that the text should clarify 
> this new max-fps is a constraint that reduces the default 
> level limit (172 fps), unlike other max-* parameters which 
> extend/increase the default level limit. You could also note 
> that it MUST be 172 fps or lower.
> 
> Mo
> 
> If YK's proposal makes sense, then another thing is the lack 
> of "normative values" for the maximum frame rate supported 
> per level in
> H.264 Table A-1. (On the other hand Table A-6 lists maximum 
> frame rates for selected, example resolutions - in a 
> non-normative fashion.) Of course, it's possible to compute 
> the maximum frame rate from the other parameters (to verify 
> the signalling). There's not as easy as when using the phrase 
> used for the other max-* parameters:
> > I have one more concern about what the semantics would be if it is 
> > treated as capability. IMO, the semantics must not conflict 
> with the 
> > level part of the profile-level-id, max-fs, and max-mbps, as these 
> > three parameters in combination already imply a maximum frame rate. 
> > Related to this, for the other max-* parameters, the 
> current rule is 
> > that, when present, the corresponding signaled capability must be 
> > higher than what is implied by the level, the rule for 
> max-fps needs 
> > also to be clearly specified (I guess it is impossible to 
> align with 
> > other max-* parameters herein). Could the authors clarify 
> this issue?
> >
> > If many people support to have the parameter (as it seems 
> so) and if 
> > the above issue is not a problem, then I would not insist my 
> > objection. If the consensus is positive, I'd prefer to 1) 
> treat it as 
> > capability, as Charles also agreed, and 2) add it directly to 
> > RFC3984bis, quickly, such that it is included in the 
> soon-to-be published RFC.
> >
> > BR, YK
> >
> treating it as 
> >> a capability rather than as a preference is more natural in the 
> >> context of the H.264 offer/answer model.
> guarantee 
> >> it will be honored since the other side may not understand 
> this new 
> >> parameter, but assuming it does understand it, I think it 
> is best to 
> >> say it MUST honor it.
> >>
> >> Cheers,
> >> Charles
> >>
> >> in my understanding), the intended signaling translation 
> is then not 
> >> possible.
> >> >

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 11 Nov 2010 12:12:07 -0600

YK,
I think the key point needed in the text is a very clear statement that max-fps only restricts and never extends the maximum frame rate implied by other parameters (level, max-mbps, max-fs).

But it is perfectly valid (and useful) to signal a max-fps higher or lower than the one implied by max-mbps and max-fs. For example, even at level 3.1 720p30 (max-fs=3600, max-mbps=108000), it is perfectly valid (and useful) to signal max-fps=6000 to indicate 60 fps is the max frame rate for all resolutions. Without signaling this, the peer is free to send CIF at 172 fps.

So the wordsmithing must clearly convey that max-fps itself is free to be anything 172 fps or lower, but senders must determine the actual maximum frame rate for a chosen resolution via: min(max-fps, implied-max-fps=max-mbps/fs). Or to be complete and consider the global a=framerate which applies to all payloads under the media line: min(framerate, max-fps, implied-max-fps=max-mbps/fs).

Mo

-----Original Message-----
From: Ye-Kui Wang [mailto:[email-masked]] 
Sent: Thursday, November 11, 2010 12:19 PM
To: Mo Zanaty (mzanaty); 'Tom Kristensen'
Cc: Cullen Jennings (fluffy); 'Tom Kristensen'; 'Roni Even'; 'IETF AVT WG'
Subject: RE: [AVT] Question about draft-kristensen-avt-rtp-h241para

Mo,

BR, YK

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 11 Nov 2010 15:09:36 -0600

Agreed on all points:
1. Needed.
2. Capability not preference.
3. Clarify semantics which differ from other max-* parameters.
4. Include (quickly) in RFC3984bis before the new RFC is published.

For 1, a real world use case where payload-specific max-fps is needed even when all payloads are H.264 would be for different configuration points (profile and packetization-mode). For example, consider an implementation that can support receiving High Profile Level 4 1080p30/720p60 using a single slice per frame via packetization-mode 1, as well as Baseline Profile Level 4 1080p30 (but not 720p60) using multiple slices via packetization-mode 0 or 2. This is not a contrived example, it actually represents a common situation in new designs where H.264 hardware is heavily optimized for consumer playback applications (like HD broadcast or Blu-ray) but not conferencing applications (FMO, ASO, H.241 packetization, or interleaved packetization are not optimized in hardware). So even though the underlying H.264 decoder may have the same max-mbps for both payloads, the overall RTP receiver/system may have different limits on maximum frame rate for each payload.

For 2, implementations should be encouraged to use this parameter to indicate their true capability, which may be misrepresented today without this parameter. H.264 requires decoders to handle 172 fps at all levels. I'm skeptical that implementations which support RFC 3984 actually support 172 fps at all levels. (Note: YK is skeptical of my skepticism.)

For 3, max-fps differs from other max-* parameters in that it decreases the maximum limit while other max-* parameters increase the maximum limit. The draft must clearly convey that max-fps never increases the maximum limit implied by other parameters (level, max-mbps, max-fs), even when it is set to a higher value than the limit implied by other parameters.

For 4, YK makes a good point. This draft should really become part of RFC3984bis, not a separate RFC. Otherwise, dealing with the different semantics of max-fps versus other max-* parameters becomes harder to manage across two RFCs, possibly causing confusion in implementations.

Mo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ye-Kui Wang
Sent: Wednesday, November 10, 2010 10:41 PM
To: Charles Eckel (eckelcu); 'Tom Kristensen'; 'Roni Even'
Cc: Cullen Jennings (fluffy); 'IETF AVT WG'
Subject: Re: [AVT] Question about draft-kristensen-avt-rtp-h241para

BR, YK

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 12 Nov 2010 01:05:39 -0800

Hi Mo,

I agree with everything, but I want to add one thing.
As with other H.264 Max parameters, H.241 specifies that MaxFPS "indicates the maximum picture rate that can be efficiently received or the maximum picture rate that can be sent" depending on where it is used. For SIP, I think we should maintain the typical semantics of the other H.264 max parameters in that max-fps indicates the maximum picture rate that can be efficiently received but says nothing about what will be sent. This results in a difference between H.323 and SIP in terms of MaxFS vs. max-fps semantics, but it is the same difference we have for other H.264 parameters in general.

Cheers,
Charles

> From: Mo Zanaty (mzanaty)
> Sent: Friday, November 12, 2010 5:10 AM
> To: Ye-Kui Wang; Charles Eckel (eckelcu); 'Tom Kristensen'; 'Roni Even'
> For 1, a real world use case where payload-specific max-fps is needed even when all payloads are H.264
> would be for different configuration points (profile and packetization-mode). For example, consider an
> implementation that can support receiving High Profile Level 4 1080p30/720p60 using a single slice per
> frame via packetization-mode 1, as well as Baseline Profile Level 4 1080p30 (but not 720p60) using
> multiple slices via packetization-mode 0 or 2. This is not a contrived example, it actually represents
> a common situation in new designs where H.264 hardware is heavily optimized for consumer playback
> applications (like HD broadcast or Blu-ray) but not conferencing applications (FMO, ASO, H.241
> packetization, or interleaved packetization are not optimized in hardware). So even though the
> underlying H.264 decoder may have the same max-mbps for both payloads, the overall RTP receiver/system
> may have different limits on maximum frame rate for each payload.
> 
> For 2, implementations should be encouraged to use this parameter to indicate their true capability,
> which may be misrepresented today without this parameter. H.264 requires decoders to handle 172 fps at
> all levels. I'm skeptical that implementations which support RFC 3984 actually support 172 fps at all
> levels. (Note: YK is skeptical of my skepticism.)
> 
> For 3, max-fps differs from other max-* parameters in that it decreases the maximum limit while other
> max-* parameters increase the maximum limit. The draft must clearly convey that max-fps never
> increases the maximum limit implied by other parameters (level, max-mbps, max-fs), even when it is set
> to a higher value than the limit implied by other parameters.
> 
> For 4, YK makes a good point. This draft should really become part of RFC3984bis, not a separate RFC.
> Otherwise, dealing with the different semantics of max-fps versus other max-* parameters becomes
> harder to manage across two RFCs, possibly causing confusion in implementations.
> 
> Mo
> 
>