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

[Sergio Garcia Murillo]

----- Original Message ----- 
From: "Mihai Balea" <mihai at hates.ms>
To: "Development discussion of video media support in Asterisk"
<asterisk-video at lists.digium.com>
Cc: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
Sent: Monday, June 04, 2007 5:20 PM
Subject: Re: [Asterisk-video] Re: [asterisk-dev] Video packetization
proposal


>
> On Jun 2, 2007, at 5:53 AM, Sergio Garcia Murillo wrote:
> > Then, create another document to adress the theora packetization
> > independently
> > of IAX, so we could use it also for rtp.
>
> People have already came up with proposals for Theora packetization
> for RTP. Here's a draft from Xiph:
>
> http://svn.xiph.org/trunk/theora/doc/draft-ietf-avt-rtp-theora-00.txt
>
> I borrowed liberally from that draft when I wrote my proposal, but
> there are things in there that I believe are not necessary.  For
> example they allow multiple video frames per RTP frame.  I believe
> that it is far more likely to have video frames that are too big to
> fit in one network frame than to have video frames small enough to
> warrant coalescing them.
>
> As far as I know that draft hasn't got a lot of circulation and I'm
> not aware of any implementations.  As such, I don't think it should
> be considered gospel.
>
> >> 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.
> Actually it will make my life easier, especially in the case when we
> have to deal with lost or miss-ordered frames.

Sorry to seem pedantic, but really theese if are so difficult??

if (prevSN>curSN)
    //Missorder
if (prevSN+1<CurSN)
    //Lost packet
if (prevTS!=curTS)
    //Different packet


> Why exactly do you think it is a bad idea? You could easily
> encapsulate the specific video/Theora bits into a RTP frame making
> the IAX2-RTP translation almost trivial.
Generally speaking having the same inforamation in two fields don't seem
a good idea for me, it could be a source of inconsistences.
Imagine there is one implementation wrong which set one correct
and the other wrong, but your client software only checks the good
one, you wouldn't notice it till you find another client which is affected
by that. And if that happens, the problem could be very difficult
to find.

>
> >> 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.
> What I am trying to avoid is digging into the encoded bitstream in
> application like app_conference.  Again, if we make this bits part of
> the video/Theora payload, then moving the payload between IAX and RTP
> stream should be easy.

If it's on the payload data then It could seem ok to me (but again you
should
cover that in another paper).