Timestamp rates [was Re: [AVT] Working group last call: JPEG-2000 payload format]

[Colin Perkins <[e-mail]>]

Dave, all,

I don't believe there is consensus to allow this much timestamp rate  
flexibility with the JPEG-2000 payload format, but I'd like to hear  
opinions from the group on how RTP timestamp rates should be  
specified in future payload formats. Should we be adding text to the  
"how to write an RTP payload format" draft to recommend that future  
video formats allow a wider choice of timestamp rates than just  
90kHz?  If so, what range?

Colin



On 26 Jun 2007, at 10:00, Dave Singer wrote:
> OK, most of this isn't really a point about JPEG 2000, but about  
> the evolution of RTP, and perhaps it needs to be disconnected from  
> the JPEG 2000 draft.
>
> * * * *
>
> The problem with the proposed text is that it is SIP-centric;  it  
> assumes negotiation and choice, neither of which are present in SAP  
> or RTSP (for example).  In a multicast or RTSP context, can I rely  
> on using the correct non-90kHz rate for my 7 fps stream, or not?   
> The requirement "must be negotiated" and "alternatives must be  
> offered" are not always achievable.
>
>
>
> The consequences of doing timestamp conversion badly vary greatly  
> between the sender and receiver, also.  If a receiver does poor  
> timestamp conversion (e.g. it introduces drift as a result of round- 
> off), it affects only itself.  If a sender does it badly, the RTP  
> packets have poorly formed timestamps and all receivers are  
> affected (e.g. in a multicast).
>
> Also, if the sender does conversion correctly for something that  
> isn't an integer division of 90kHz, the delta between successive  
> timestamps will vary, suggesting that the frame rate is variable,  
> when it is, in fact, constant.
>
> I still question the whole principle that RTP payload formats  
> should mandate anything at all about clock rates.  RTP receivers  
> are supposed to cope with arbitrary, suitable, clock rates, and the  
> RTP spec. has a statement that the resolution must be high enough  
> for the desired synchronization accuracy and for measuring packet  
> arrival jitter.
>
> Way back when a payload type (small number) was all you needed to  
> know to decode an RTP session (you didn't need an SDP file or  
> anything), it was necessary that the clockrate for a given payload  
> format be statically defined.  We don't have static payload types  
> any more and we don't need to statically associate clockrates with  
> payloads.
>
> The MPEG payload format uses 90 kHz because that clock rate is  
> mandated in the MPEG spec., so the payload format reasonably says  
> that it should match.  Not all applications of JPEG2000 RTP come  
> from a 90 kHz source, so that does not apply here.
>
> At 10:03  +0200 26/06/07, Magnus Westerlund wrote:
>> Colin Perkins skrev:
>>> Wrapping up, I believe the rough consensus is that the JPEG-2000  
>>> draft should be updated to allow non-90kHz timestamp rates, as  
>>> follows:
>>>
>>> - Senders and receivers MUST support a 90kHz RTP timestamp rate,  
>>> and MAY
>>>   support other rates.
>>>
>>> - Senders SHOULD use 90kHz timestamp where possible, and the  
>>> draft needs to
>>>   be updated to include strong guidance on choosing the timestamp  
>>> rate, and
>>>   the implications of using a rate other than 90kHz.
>>>
>>> - The timestamp rate MUST be negotiated. The offer/answer  
>>> considerations
>>>   should explain how this is done.
>>>
>>> - Senders that wish to use a non-90kHz rate SHOULD also offer the  
>>> same stream
>>>   using a 90kHz timestamp rate, with a different RTP payload  
>>> type, e.g.:
>>>
>>>     m=video 5004 RTP/AVP 98 99
>>>     a=rtpmap:98 jpeg2000/90000
>>>     a=rtpmap:99 jpeg2000/27000000
>>>
>>>   allowing graceful fallback to 90kHz if the receiver doesn't  
>>> support the high
>>>   rate.
>>>
>>> To check the consensus, please reply to this message by the end  
>>> of this week, stating if you agree or disagree with this  
>>> proposal, and giving your reasons. Please do this even if you  
>>> believe you have already stated your preference.
>>>
>>
>> I am fine with this. However, I think the SDP example should  
>> switch the priority order of the two payload formats to indicate  
>> that one does like to use 27 MHz rather then 90k. So if including  
>> an example with this, change the m= line to:
>> m=video 5004 RTP/AVP 99 98
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> IETF Transport Area Director & TSVWG Chair
>> --------------------------------------------------------------------- 
>> -
>> Multimedia Technologies, Ericsson Research EAB/TVM/M
>> --------------------------------------------------------------------- 
>> -
>> Ericsson AB                | Phone [phone]
>> Torshamsgatan 23           | Fax   [phone]
>> S-164 80 Stockholm, Sweden | mailto: [e-mail]
>> --------------------------------------------------------------------- 
>> -
>
>
> -- 
> David Singer
> Apple/QuickTime
>
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt



-- 
Colin Perkins
http://csperkins.org/



_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt