[asterisk-dev] Video packetization proposal

[Sergio Garcia Murillo]

----- Original Message ----- 
From: "Mihai Balea" <mihai at hates.ms>
To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
Cc: <asterisk-video at lists.digium.com>
Sent: Saturday, June 02, 2007 12:32 AM
Subject: Re: [asterisk-dev] Video packetization proposal


>
> On Jun 1, 2007, at 6:22 PM, Sergio Garcia Murillo wrote:
>
> > 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.
>
> Theora does not support packetization and it is, unfortunately, the
> only free (as in beer and speech) video codec.  I believe that if we
> fail to address the issue of packetization, then we stunt the
> development of open source video solutions.  That being said, I tried
> to leave video specific information out of the generic header and
> into the extended portion.  The video specific flags I describe in
> the document should be interpreted as a suggestion, as some codecs
> like h264 might not need them.
>

Then, create another document to adress the theora packetization
independently
of IAX, so we could use it also for rtp.


> >
> > 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.
> Yes, but if one extra bit makes my life as a programmer easier, I
> would go for that.

Avoiding "if"s are going to make your life as a programer easier?
And you should put those same to ifs whe dealing rtp>IAX translation.
Duplicating information on the header I think it's not a good idea.

>
> > I,P,B framet indication is not needed as it should the decoder the
> > one who
> > is in charge of that.
> Some application benefit from knowing the type of frame without
> actually decoding it.  One example would be video conferencing
> applications, and more specifically app_conference.  When you want to
> switch the video stream from one person to another, you want to do it
> on a key frame, otherwise you get garbage.
>

Yes, It will make life easier for app_conference, but again it will make
very
difficult the rtp>IAX transaltion as you'll have to dig into the encoded
bitstream
to get that info.

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

>
> > 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?
> My proposal does not allow multiple video frames in one IAX2 frame.
> RTP packetization for h264 and theora (at least xiph's proposal) does
> allow for that, but I believe that video frames are large enough to
> be transported one per IAX frame (or one per multiple IAX frames).

I wasn't saying to allow multiple video frames in a packet, just what asking
how
the ts would be handled for the all the packets of the frame.
But this arise another wuestion, what are you going to do with h264? I
haven't still
have got much time to study the h263 packetization, but if seen that it
allows many
NALS to be send in one rtp packet. How would you set the I/P bit then? Are
you
proposing to split that frame into multiple ones?


Greetings
Sergio