[Asterisk-video] Re: [asterisk-dev] Video packetization proposal

Peter Grayson jpgrayson at gmail.com
Mon Jun 4 15:31:10 MST 2007

On 6/4/07, Sergio Garcia Murillo <sergio.garcia at fontventa.com> 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".
> >
> For video it should be always the presentation time. It's a nosense to
> implement a jitterbuffer for video, you should send the video as soon as
> you can (taking into account your bandwith limit). A pause in video is
> not as critical as in audio and introducing an artificiall delay between
> audio and video is not a good idea for lip sincronization.

The jitterbuffer is only used when iax frames are received, not before
they are sent. Video frames do need to go through the jitter buffer.
If they did not, audio frames would be delayed relative to video
frames and video frames might received out-of-order. Both of these are
pretty bad problems.

> > 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.
> Obviously having a good clock is the better, but an error of 1 ms i don't
> see much problem.

I think you are right here. The iax rfc does not really specify what
the timestamp means. I think the right solution would be to clarify
the iax rtp to include an rtp-like definition to the timestamp. From
rfc 3550:

      The timestamp reflects the sampling instant of the first octet in
      the RTP data packet.

This would apply equally well to both audio and video timestamps. I
think this is what Sergio has in mind.


More information about the asterisk-dev mailing list