[asterisk-dev] Video packetization proposal

Sergio Garcia Murillo sergio.garcia at fontventa.com
Fri Jun 1 15:22:40 MST 2007

----- Original Message ----- 
From: "Mihai Balea" <mihai at hates.ms>
To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
Sent: Wednesday, May 30, 2007 4:30 PM
Subject: [asterisk-dev] Video packetization proposal

> Hello all,
> As discussed at the Asterisk Developer Conference, I am attaching a
> proposal for IAX video packetization.  While video is the primary
> focus of this document, it can be easily extended to cover other
> types of large, realtime media.
> I am really looking forward to hearing your comments and suggestions.
> Cheers,
> Mihai

Hi Mihai, just a few comments.

IMHO video packetization should be transparent to IAX (as is in rtp) so I
would only
allow the data to be only a full video packet (not transmit partiall video
packets or mix
several packets in one IAX packet). If a codecs doesn't support
pacektization the
specification should be outside of the scope of this document.

As in rtp, only one bit is really needed to signal the last packet of a
frame. You can detect
packets losses and frame changes with secuence numbers and timestamps.

I,P,B framet indication is not needed as it should the decoder the one who
is in charge of that.

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.

Also, it has another problem, if a frame has more than one packet, you're
going to set the duration on
the first one? or in every one?
If you use the first and the packet is lost, then you lost the time
reference of the frame.
If you use the second one and you skip the last packet of a frame and the
first of the following you won't
be able to know that there has been a frame change (you will know that
you've lost packets but as both
will be marked the FT to 2 you won't be able to tell).
Neither problem is present if you work with timestamp as in rtp.

I also copied the asterisk-video mailing list in the mail


More information about the asterisk-dev mailing list