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

[Dave Singer <singer at apple.com>]

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.

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

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



At 16:38  +0200 30/05/07, Magnus Westerlund wrote:
> Boudani Ali skrev:
> > > Can you please clarify why it isn't enough with a 90 kHz clock even for
> >
> > > professional video? When is their need for time jitter related to when
> > a
> > > frame was sampled needs to be smaller than what a 90kHz clock 
> > > provide. specially considering that most of the frame rates used 
> > > will have perfect match to a particular tick increment per frame. 
> > > I don't think
> > we
> > > have heard any such issues being raised in AVT before. If we do 
> > > miss a critical motivation then this applies to all our video 
> > > payload formats,
> >
> > > not only one.
> >
> > I didn't say smaller. The RTP timestamp in the draft is used also as a
> > presentation time. So in that case, if you want to mix two frames, you
> > need the pixel precision (The clock frequency used in SD is 27MHz).
> > That's why I am saying that 90KHz (one and only) is not enough. If you
> > put "SHOULD be 90 KHz", that may be a solution since the user could then
> > put its frequency value in rtpmap (a=rtpmap:..../frequency) in the SDP
> > session.
>
> I don't really see how this is applicable. Why would you use the RTP 
> timestamp to accomplish analog video signal synchronization to pixel 
> level when you can mix the video frames in the digital domain and 
> then send the mixed video frames to the digital to analog 
> transmission converter? That way you only need to accomplish the 
> association of the frames from the different streams that needs to 
> go together. That synchronization can be accomplished even if one 
> used a clock ticking at the frame-rate.
>
> Also, are you really expecting these operations to happen on the 
> JPEG-2000 video format? I can maybe understand if we where talking 
> about the uncompressed video format that handles individual pixels.

--
David Singer
Apple Computer/QuickTime

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