Re: H.263 (Was Re: Cornell CUSeeMe Version 1.0 Locks Up)

Scott Lacroix (slacroix@wpine.com)
Fri, 26 Jun 1998 14:44:35 -0400


At 12:47 PM 6/26/98 -0400, Kevin McCormick wrote:
>Hey Streak and Jason,
>
>Let me find out for ya. I'll see if I can get you an answer here shortly.

Caught me sleeping 'till I saw Kevin's name.... :)

>At 10:13 AM 6/26/98 -0500, you wrote:
>>On Fri, 26 Jun 1998, The Mad Scientist! wrote:
>>> On Thu, 25 Jun 1998, Jason Williams wrote:
>>> > I didn't know that...I do know that from talking with Brian Godette,
>H.263
>>> > is much more susceptible to packet loss. If there's high packet loss,
>the
>>> > frame rate plummets.

It's not the frame rate that plummets. It's the quality. You still get the
same number of frames, but (as I understand it, and I could be wrong) H.263
is alot like LZH encoding: data is affected by surrounding data. So pixel
data AROUND a pixel holds a certain amount of wieght when decoding. Thus,
if you lose a packet in the middle of a frame, it can cause corruption
outward from that point. Obviously it only holds a limited amount of
wieght, since corruption stops after a point...
At least I'm sure that's the EFFECT I'm seeing. :)
So, you're right, but it's not frame rate that suffers. Your frame rate is
the same, but it gets all garbled until the next IFrame or GOB comes in and
cleans it up.

>>> Yes, I've had that happen too while using H.263. I guess it really needs
>>> to be used with RTP, as happens with H.323 systems.

RTP or CUSM-VPH, doesn't matter. They are both UDP protocols and suffer
the same packet-loss problems. RTP is a (much) smaller header so you may
see less packet loss, but it should be pretty much the same.

>>That would be a good question for a White Pine employee...Does the current
>>3.1.X versions of Enhanced CU use RTP with a video payload (H.263 codec).
>>>From what I remember reading in the docs/readme's, Enhanced CU only uses
>>RTP with the G.723 audio codecs when communicating either with a MPCS
>>reflector or point to point with another 3.1.X client.

Uhm... first question: why does it matter? :)
Next: yes and no.
Depending on WHO you connect to, the client or the server may translate
the RTP datastream to CUSM-VPH and ship it that way. That's why 3.X clients
can send H.263 through 2.X reflectors (which don't speak RTP) and 3.X
clients can send RTP H.263 to a 3.X server and it will be seen by 2.X
clients that have the codec available (which also don't speak RTP).
You always gotta think about backwards compatability issues, right?
(<sarcasm> Contrary to popular opinion on this list, we actually DO
consider backwards compatability here... *G* </sarcasm>)

Good 'nuff? :)

- Scott

--

,-==================================-.-==================================-. | I haven't lost my mind, it's backed | Scott LaCroix (slacroix@wpine.com) | | up on tape around here somewhere... | Sr. Software Engineer ___ | | - Author Unknown | White Pine Software ./_ -\. | | #include<disclaimer/std.h> | http://www.wpine.com q| o O |p | `-==================================-^-=====================oOOo=~U~=oOOo-'