Subject: Re: [AVT] Working group last call: JPEG-2000 payload format

From: Colin Perkins <[email-masked]>
Date: Mon, 2 Jul 2007 17:58:09 +0100

On 26 Jun 2007, at 09:03, 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

There seems to be consensus that more flexibility should be allowed  
in the choice of timestamp rate for the JPEG2000 payload format.   
Authors, could you please therefore submit an update reflecting this.

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

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

---

From: Colin Perkins <[email-masked]>
Date: Mon, 2 Jul 2007 18:01:15 +0100

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:
>>> - Senders SHOULD use 90kHz timestamp where possible, and the  
>>> draft needs to
>>>   using a 90kHz timestamp rate, with a different RTP payload  
>>> type, e.g.:
>>>
>>> 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:
>> Cheers
>> Magnus Westerlund
>> IETF Transport Area Director & TSVWG Chair
>> --------------------------------------------------------------------- 
>> -
>> Multimedia Technologies, Ericsson Research EAB/TVM/M
>> --------------------------------------------------------------------- 
>> -
>> Ericsson AB                | Phone +46 8 4048287
>> Torshamsgatan 23           | Fax   +46 8 7575550
>> S-164 80 Stockholm, Sweden | mailto: [email-masked]
>> --------------------------------------------------------------------- 
>> -
>
>
> -- 
> David Singer
> Apple/QuickTime
>

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

---

From: Satoshi Futemma <[email-masked]>
Date: Tue, 03 Jul 2007 11:03:04 +0900

Dear Colin,

Thank you for the wrapping up.
I agree with you.

All right, I will submit a new draft soon.

Best Regards,

Futemma

Colin Perkins wrote:
>>> 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.
>>> - The timestamp rate MUST be negotiated. The offer/answer considerations
>>>   using a 90kHz timestamp rate, with a different RTP payload type, e.g.:
>>>   allowing graceful fallback to 90kHz if the receiver doesn't support 
>>> the high
>>>   rate.
>>> 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.
>>
> There seems to be consensus that more flexibility should be allowed in 
> the choice of timestamp rate for the JPEG2000 payload format.  Authors, 
> could you please therefore submit an update reflecting this.
> 
> Thanks,