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

Jason Williams (streak@ccwf.cc.utexas.edu)
Fri, 26 Jun 1998 18:11:05 -0500 (CDT)


On Fri, 26 Jun 1998, Scott Lacroix wrote:
> Caught me sleeping 'till I saw Kevin's name.... :)

Hope it was a good nap :)

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

Thanks for the clarification. :) I never know how H.263 worked :)

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

I figured that RTP perhaps offered better support for packet loss..but I
guess you're right, it's the way the codec work, not the means of
transportation for it.

> >>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? :)

It doesn't really matter at all to me. I've just always heard that CU
3.X uses RTP for the audio. I never heard anything about it using RTP for
video as well. I guess it matters in the long run so that version 4 can
be H.323 compliant for point to point conferencing as well as via a
reflector. I've been reading a lot of stuff in comp.dcom.videoconf about
Netmeeting doing things their own way as they're not H.323 compatible at
all (which was news to me).

> Depending on WHO you connect to, the client or the server may translate
> the RTP datastream to CUSM-VPH and ship it that way.

Ahh..so there's some way of saying "yoohoo, I'm H.323-aware". I guess it
does make sense that there'd be signalling like that.

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

That's cool really...I didn't realize 2.X clients could see H.263 if they
had the codec. Since the Cornell 1.0 client came out, I haven't touched
2.1.2. :)

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

Nope..actually wasn't thinking backwards compatibility at all..was just
trying to broaden my knowledge and wondered why I never heard of 3.X's
capability of doing video thru RTP as well.

I know WP tries hard to keep things backwards compatible..unfortunately,
releases like 3.1.0.25 and 3.1.1.004 doesn't seem to show it. Rushing
products out the door before carefully testing them seems to be what's
been happening (ie: 3.0, 3.1.0.25, 3.1.1.004). I'm hoping that's why a
3.1.1 release is taking so long. So hopeflly White Pine can iron out the
bugs and get a fairly bug free product out. I know 3.1.0 went thru quite
a number of releases for beta testers, but things changed right before
build 25 was released. It looks like 3.1.1.016 fixes most of the problems
(except for the chat bugs).

> Good 'nuff? :)

Yep..satisfactory :)

--
streak@ccwf.cc.utexas.edu    * Jason Williams -- Austin, Tx.  |     |
streak@mail.utexas.edu       * University of Texas at Austin  | ___ |
streak@cs.utexas.edu         * BS Computer Science             \_|_/
*************** http://ccwf.cc.utexas.edu/~streak/ **************|