🚀 go-pugleaf

In message <2136.907855267@cs.ucl.ac.uk>,
Jon Crowcroft writes:
>
I fully agree with your points, except:

>6/ a lot of the CODECs in mbone tools and a lot of the playout
>adaption algorithms are WAY better than allegedly commercial products
>(esp. in ip telephony) - there are a few notable exceptions....someone
>ought to list these....

I've seen the quality that a PictureTel H.320 terminal at 3xISDN can
achieve (that is 384 Kbit/s for video *and* audio).

Then coding the same content with vic on a Digital-alpha Workstation
(500MHz) was a very disappointing experience.  Even at 600 Kbit/s you
cannot obtain the same quality.

I think that the absence of motion estimation in vic's H.261
implementation is probably most responsible for this, but I don't
really have the expertise to make a final judgment on this matter.

I understood that the motivation of vic's authors not to include
motion estimation was to make the codec more robust in the face of
packet losses.  I wondered if this is the case in the H.261
implementations of the new H.323 conferencing products (which will be
susceptible to the same packet losses) ??

I think that the way to go for both commercial and non-commercial
software is to use "hardware" H.261 compression (or whatever standard)
on the video-capture board.  I also guess that then I wouldn't be
so annoyed with the delay that the video has with respect to the
audio (very annoying on my SGI-O2, or am I doing something wrong?).

Patrick De Muynck

BELNET, the Belgian National Research Network

Patrick.DeMuynck@belnet.be  |	DWTC - BELNET
Tel : +32/2/238.36.76	    |	Wetenschapsstraat, 4
Fax : +32/2/513.57.30	    |	B-1000 Brussel