At 9:15 -0700 6/06/07, Chuck Harrison wrote:Suppose
1. A compliant J2K receiver MUST accept 90kHz timestamps 2. A compliant J2K receiver MAY accept other timestamp rates 3. A compliant J2K sender SHOULD transmit 90kHz timestamps 4. The RFC warns that senders violating the SHOULD of item 3 risk interoperability problems.
I think timestamp conversion tends to be a common function in an RTP stack, doesn't it? Be that as it may, it's no good allowing me to send non-90KHz if I can't know it'll work -- standards are about interoperability.
Right - this is the problem with allowing multiple rates.
So I think that it should say
* a 90 KHz clockrate is recommended (you could even use SHOULD be used) for JPEG 2000 streams
SHOULD, I think.
* receivers MUST be able to handle other clock rates
The RFC warns that if you choose an unsuitable rate, or a rate whose conversion is difficult, error-prone (e.g. to round-off errors), or even unusual, you risk playability problems.
-- Colin Perkins http://csperkins.org/
_______________________________________________ Audio/Video Transport Working Group avt at ietf.org https://www1.ietf.org/mailman/listinfo/avt