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

[Tom Kristensen <[e-mail]>]

As a heads up:  I'm about to submit a revival version of the H.241
max-fps draft, fixed according to this previous discussion and
mailing-list conclussions in the AVT WG. Therefore, I've digged up the
old thread.

Cf. thread starting with:
http://www.ietf.org/mail-archive/web/avt/current/msg13902.html

-- Tom

> On 27/11/2010, Roni Even <[e-mail]> wrote:
>> Hi Guys,
>>
>> I am OK too. I will see when we can progress it.
>>
>> Roni Even
>>
>> AVT co-chair
>>
>>
>>
>> From: [e-mail] [mailto:[e-mail]] 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
>>
>>
>>
>> I also support this and agree with the text.
>>
>>
>>
>> Mo
>>
>>
>>
>>   _____
>>
>> From: [e-mail] [mailto:[e-mail]] 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
>>
>>
>>
>> Fine with me, I support this.
>>
>> BR, Stephen Botzko
>>
>> On Fri, Nov 26, 2010 at 6:05 PM, Ye-Kui Wang <[e-mail]>
>> 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
>>
>>
>>> -----Original Message-----
>>> From: Tom Kristensen [mailto:[e-mail]]
>>> 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,
>>> 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
>>>
>>
>>
>> _______________________________________________
>> Audio/Video Transport Working Group
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/avt
>>
>>
>>
>>
>
>
> --
> # Cisco                         |  http://www.cisco.com/telepresence/
> ## [e-mail]  |  http://www.tandberg.com
> ###                               |  http://folk.uio.no/tomkri/
>


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