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

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

Dave Singer skrev:
> RTP payload formats may be used for all sorts of purposes and (varying) 
> frame rates.  I disagree that we in the AVT group 'know best' and that 
> any payload format should mandate a particular clock frequency.  It's 
> perfectly legitimate for me to send material at say 7 fps, and 90000 is 
> not suitable for that -- the frames would appear to have varying 
> duration, and there is risk of round-off.

I know that AVT is not knowing best. However, I asked this questions so 
that we could be educated and take an informed decision. However I think 
there are definitely an trade-off between using a fixed timestamp clock 
rate and allow any rate to be used.

> Any payload format should recommend ('should') something, but mention 
> that other possibilities exist.

As this have shown to create problems in implementations. For example it 
showed up in an interop test creating problems for the packet-based 
streaming service where people sent MPEG-4 content using RFC3016 
packetization using non 90kHz clock. This occurs because the wiggle room 
was given and most implementors do no understand the implications of 
using another clock. Sure, we didn't document well enough all the 
downsides with choosing something else. Also we really should provide 
some lower and upper boundaries on these values.

> Very high clock frequencies (e.g. 27 MHz) bring their own problems 
> (frequent wrap-around being one).  For a given program, it is usually 
> the case that one can easily find a number that
> a) doesn't wrap around too often
> b) is high enough for accurate jitter calculations
> c) is an integer multiple of the frame rate, or, for variable frame 
> rate, allows each frame to have an integer timestamp which has not been 
> rounded-off

Yes, and that have so far been 90kHz to satisfy this. If there are cases 
when this is not true I would like to know about them. But I think we 
should be clear on why we are allowing any wiggle room at all. 90kHz do 
support quite a lot of different frame rates. I am not saying that there 
doesn't exist such rate. But given a blank card on what rate to use adds 
complexities. If we rather could enumerate a small set of possible rates 
to cover the known cases that would make me much happier.

But Ali's example is not something that can be solved using the RTP 
timestamp rate if I understand this correctly. Simply because 27 MHz 
gets us into the problem with frequent wrap around.

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: magnus.westerlund at ericsson.com
----------------------------------------------------------------------

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