[Asterisk-video] IAX timestamps, presentation vs transmission time Re: [asterisk-dev] Video packetization proposal

[Steve Kann]

picking up on a subset of this thread:


Peter Grayson wrote:
>
> You are right that the obvious conversion would be trivial. However,
> there is a semantic difference between RTP and IAX. The RTP timestamp
> is the presentation time for the media. The IAX timestamp is the
> transmission time. Presentation time and transmission time may or may
> not be related. I really don't know. For asterisk, the transmission
> time is important for dejittering the packet stream. There seems to be
> an implicit assumption that presentation time is "upon receipt" which
> is different than "when the packet says".
I think that we can define this more clearly and come up with a workable 
definition.  In both cases, these times are relative, are they not?  And 
if they are relative, does it matter what their difference is, as long 
as it is constant?

In iaxclient, as well as in most media presentation systems for 
real-time media, the goal is not to present frames "upon receipt", but 
as soon as possible, honoring as best as possible the inter-frame 
spacings.  This is the job of the jitterbuffer.

In RTP, there may be a mechanism (I don't remember how this works) for 
transmitting frames with timestamps which don't (relatively) follow 
real-time -- this is used more in RTSP than in SIP, where you can ask an 
RTSP server to send you media, but send it at a multiple of real-time 
(2x as fast, 1/2 as fast), and Quicktime uses this in some cases 
(probably both for buffering, and for fast/forward, rewind, and other 
controls).

>
> Also, the RTP timestamp uses a 90kHz clock. The IAX timestamp is
> measured in milliseconds which is effectively a 1kHz clock. There is a
> rather large difference in precision between these two thus
> information would be lost in RTP to IAX mappings and IAX obviously
> does not have sufficient information to match RTP's precision in the
> IAX to RTP mapping case. Does this matter? Seems like it is worth
> consideration.
That's a good question.  I think that it wouldn't make much of a 
difference, if a frame was actually presented +- 1/2 msec from another 
frame (in the video case), and in the audio case practically all codecs 
use integral numbers of milliseconds to sample. 

RTP already has to deal with this for the NTSC case (29.97fps with the 
90khz clock).  IAX will need to deal with this for 15fps or 30fps, which 
_would_ divide neatly into a 90khz clock, but don't divide neatly into 1khz.

-SteveK