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

[Chuck Harrison <cfharr at erols.com>]

Colin Perkins wrote:
> 
> On 9 Jun 2007, at 00:30, Dave Singer wrote:
> > 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 trouble with a MUST like this is that it is untestable;
therefore although compliance with the RFC *in theory*
guarantees interoperability, i.e. that a receiver will be
able to handle anything you throw at it, this may not
occur in practice. Also untestable compliance MUSTs could
interfere with progressing the document to standard (is
that so, chairs?)

If we choose a small number of specific alternate clock rates,
then the MUST becomes testable. But I do not think this is
what Dave was asking for.

> >
> > 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.
> 
> ...and the offer/answer considerations section in the draft explains
> how to negotiate the desired rate, and how to interact with receivers
> that only support 90 kHz.

If 90kHz capability is made a MUST at both senders and
receivers, then there is a baseline rate at which two
compliant implementations are guaranteed to interoperate.
This capability can be tested.

If a sender and receiver are able to negotiate (e.g. thru
offer/answer) an alternate rate that is more suitable to
the particular application environment, so much the better.

But I do not think Dave's original proposal -- that a sender
can choose an arbitrary rate and be guaranteed that any
compliant receiving implementation will handle it -- is
viable.

So is the drift of the proposal currently on the table as
follows?

- clockrate is considered as an SDP offer/answer parameter
- receiver MUST be capable of 90kHz
- sender MUST be capable of 90hKz 
- sender SHOULD use 90kHz
- receiver SHOULD accept other clockrates

Some guidance on possible alternate clockrates (e.g. a range
for the SHOULD) would make it more likely that interoperability
of independent implementations might occur. Any suggestions
for a range, Dave?

Cheers,
  Chuck

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt