Re usable video/audio

Ross Binnie (dianaros@vianet.on.ca)
Thu, 13 Nov 1997 17:20:01 -0500


This is a multi-part message in MIME format.

------=_NextPart_000_0004_01BCF058.60C765C0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Some of the readers here are aware of some of my problems with
the CU-SEEME concept. Perhaps they also know that the problems
extend into other video conferencing systems as well.

I would like to pose a few hypothetical suggestions as to how the
concept might be improved in time to come. Probably these are not
entirely new. Hopefully readers will be willing to offer some
comments.=20

In Net Video Conferencing, an image is sent and then upgraded as
the image changes. The method of upgrading the image may vary
depending on the system in use. In most cases, a terminal
receives an image that is constantly in transition. The result is
often a broken image that at times seems to compete with the art
forms of Salvador Dali.

The Net imposes limitations on the size of the data packets.
Outside of Universities and Corporations who can afford high
speed access, the rest of the world sends and receives data at
28.8 or slightly slower connect speeds to an ISP. From past
experience, ISPS also have problems maintaining high speed
connections to the Net. An example is Vianet. The IP addresses
(209.5.40. ....) are owned by Sprint. The connect carrier is Bell
Canada. Vianet claims that it supports higher speeds but Bell
connect rates are 28.8 or slightly less. The local circuits are
less than 20 years old and the switches are current. Sprint also
generates delays in transmission. TracerT (a Win95 variation on
whois) shows many slow points and timeouts on Sprint circuits
(but not limited exclusively to Sprint). The point being that
attempting to provide relatively good video (within the existing
infra-structure) over the Net is almost impossible.

To get around the existing limitations, many people (including
myself) now pause the video after a connection is made in
attempts to obtain better audio quality. Sadly, even audio
suffers from lost data resulting in poor < unacceptable audio
quality. Starting on Sept. 19 I tried every available demo
package attempting to find something that works consistently. To
date the best (from this perspective) has been MS NetMeeting 2.1.
(This observation is not meant to demean the CU-SEEME concept.)
Even so, the quality of each connection varies widely. This
brings me to my questions / suggestions.

A video frame should only show on the remote terminal when it is
complete. The determination of what constitutes a complete
opening frame needs to be defined. Subsequent frames need to be
defined so that when a complete frame is received it is then
posted on the remote terminal as a complete entity, thus
eliminating the fractured images that are now common. Audio also
needs to be defined so that a complete sound "bite" is presented
at the remote terminal. One company seems to be approaching this
in it's demo channels <www.xtx.com>. However running the software
in point to point video connections produces very poor results.

FTP is able to transmit (and correct for lost/corrupted packets)
so that the d/l file is complete. Is it possible for Video and
audio packets to achieve the same results over similar
connections.

Comments?

Ross
<dianaros@vianet.on.ca>

------=_NextPart_000_0004_01BCF058.60C765C0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">

Some of the readers here are aware = of some of my=20 problems with
the CU-SEEME concept. Perhaps they also know that the=20 problems
extend into other video conferencing systems as=20 well.
 
 
I would like to pose a few = hypothetical=20 suggestions as to how the
concept might be improved in time to come. = Probably=20 these are not
entirely new. Hopefully readers will be willing to = offer=20 some
comments.
 
 
In Net Video Conferencing, an image = is sent and=20 then upgraded as
the image changes. The method of upgrading the image = may=20 vary
depending on the system in use. In most cases, a = terminal
receives an=20 image that is constantly in transition. The result is
often a broken = image=20 that at times seems to compete with the art
forms of Salvador=20 Dali.
 
 
The Net imposes limitations on the = size of the=20 data packets.
Outside of Universities and Corporations who can afford = high
speed access, the rest of the world sends and receives data = at
28.8=20 or slightly slower connect speeds to an ISP. From past
experience, = ISPS also=20 have problems maintaining high speed
connections to the Net. An = example is=20 Vianet. The IP addresses
(209.5.40. ....) are owned by Sprint. The = connect=20 carrier is Bell
Canada. Vianet claims that it supports higher speeds = but=20 Bell
connect rates are 28.8 or slightly less. The local circuits = are
less=20 than 20 years old and the switches are current. Sprint also
generates = delays=20 in transmission. TracerT (a Win95 variation on
whois) shows many slow = points=20 and timeouts on Sprint circuits
(but not limited exclusively to = Sprint). The=20 point being that
attempting to provide relatively good video (within = the=20 existing
infra-structure) over the Net is almost=20 impossible.
 
 
To get around the existing = limitations, many=20 people (including
myself) now pause the video after a connection is = made=20 in
attempts to obtain better audio quality. Sadly, even = audio
suffers from=20 lost data resulting in poor < unacceptable audio
quality. Starting = on=20 Sept. 19 I tried every available demo
package attempting to find = something=20 that works consistently. To
date the best (from this perspective) has = been MS=20 NetMeeting 2.1.
(This observation is not meant to demean the CU-SEEME = concept.)
Even so, the quality of each connection varies widely.=20 This
brings me to my questions / suggestions.
 
 
A video frame should only show on = the remote=20 terminal when it is
complete. The determination of what constitutes a = complete
opening frame needs to be defined. Subsequent frames need to = be
defined so that when a complete frame is received it is = then
posted on=20 the remote terminal as a complete entity, thus
eliminating the = fractured=20 images that are now common. Audio also
needs to be defined so that a = complete=20 sound "bite" is presented
at the remote terminal. One = company seems=20 to be approaching this
in it's demo channels <www.xtx.com>. However running the=20 software
in point to point video connections produces very poor=20 results.
 

FTP is able to transmit (and = correct for=20 lost/corrupted packets)
so that the d/l file is complete. Is it = possible for=20 Video and
audio packets to achieve the same results over=20 similar
connections.
 
 
Comments?
 
 
Ross
<dianaros@vianet.on.ca>
------=_NextPart_000_0004_01BCF058.60C765C0--