[Asterisk-video] Re: [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: "Development discussion of video media support in Asterisk"
<asterisk-video at lists.digium.com>
Sent: Monday, June 04, 2007 4:48 PM
Subject: Re: [Asterisk-video] Re: [asterisk-dev] Video packetization
proposal


>
> On Jun 3, 2007, at 1:08 PM, Sergio Garcia Murillo wrote:
> >
> > h263-1998/2000 behaves exactly the same way and it has make my
> > life much more easier than h263-1996.
> > Also, if you miss one packet (I've never seen an missordered one) or
> > you add data redundancy to the stream or your next frames will
> > be displayed incorrectly.
>
> That is correct.  However, dropping one p-frame will result in less
> crappiness than using an incomplete or screwed-up one.
> I thought about adding redundancy using some sort of FEC, but the
> reality is that dropped packets usually happen when there is some
> sort of network congestion, and pushing even more data on the pipe
> does not help in that situation.  I have not done any real testing in
> this area, so I'm not speaking from experience here.  If you, or
> anybody else for that matter, have played with video data redundancy,
> I'd be very interested in hearing about your results.

I have always worked with low bandwidth so it was not an option for
video. On audio, we build an implementation of gsm that sent a copy
of the last frame with the new one, and the quality was really very good.
And i usually let the decoder decode the screwed frame, or at least
the good part you've got. If you're suffering congestion you could get
several frames damaged so i think it's preferably to let the user see
something that freeze the image until the frames arrive perfectly.

>
> >
> >> Compare to H.264 which does have built in packetization and is
> >> resistant to lost or miss-ordered packets.
> >
> > Video packetizating is thigthly coupled with the encoding and the
> > decoding
> > process. If your going to offer good error correction capabilities
> > you'll
> > have
> > to implement it directly into de encoder/decoder (have you ever
> > tried to
> > packetize h263-1996?) and don't mix it with the transport.
>
> I agree that this should be handled at the codec level.  However,
> Theora doesn't do it so we have to work with what we have.
> Unfortunately, I am not a DSP expert, so I cannot really dig into
> Theora's internals to add these features myself.
>

I had to work with h263-1996 and there were not funy times. In theory
it sounds good, in each packet you've got the motion vectors so you can
decode each packet separatelly. In practice, implementing into an existing
codec was not an option, so we just ignore that data and recompose the
frame as it's done in h263-1998.

Greeting
Sergio