[asterisk-dev] Video packetization proposal

[Sergio Garcia Murillo]

> > > > The timpestamp conundrum, this is quite a hard problem.
> > > > As you have defined in your document the iax field would be a timer
> > > > reference or frame duration instead of a timespamp. I've do it that
why
> > > > youll have a big problem if you want to translate from rtp to IAX.
The
> > > > only way you can do it is storing all the packets of a frame till
you've
> > > > got the first packet of the next video frame, then (and only then)
you
> > > > could calculate your "timestamp" field.
> > > It is not the frame duration, it is the time difference (in ms)
> > > between the time of transmission of this frame and the time of
> > > transmission of the first frame in the call.
> >
> > Ok, I understood wrong the header, but then there should be no problem
> > converting from one value to another at all.
>
> 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.

> 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.


Greetings
Sergio