Re: Re usable video/audio

Jason Williams (
Thu, 13 Nov 1997 21:20:17 -0600 (CST)

On Thu, 13 Nov 1997, Ross Binnie wrote:
> 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.

I can certainly try :)

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

This is a generalization which just isn't true from what I've seen.
CU-SeeMe achieves its speed (or lack thereof in your case) by sending
differences in frames..only sending a key frame when necessary. But
that's also only the Cornell gray codec. The MJPEG codec doesn't send out
differences in frames but entire frames that's one reason why I like
MJPEG. You can get fairly decent color (or B&W MJPEG) without pieces of
the image lacking.

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

You're relating data rate to size of data packets? I don't believe this
to be true. Just because you're receiving 28.8kbps per second doesn't
mean you receive one packet a second thereby defining there to be
28.8kbits in that packet. If I recall some discussion earlier (definitely
not my field though), routers break down messages to 1500 bytes per
packet. (1500 bytes/packet * 8 bits/byte = 12000 bits/packet) So the
maximum any connection can handle is 12kbits in a packet regardless of the
bandwidth. Universities and large corporations can send more packets per
second but the size of the packets doesn't change.

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

(Tracert is a win95 port of traceroute) That sounds more like routing
problems and congestion at the routers than it is an ISP problem. An ISP
can only do so much. It can provide high speed connections, but if the
routers are congested, there's not anything anyone can do. It's the same
with the university here...Our only connection to the outside world is
Sprint. The Sprint routers are often congested so lag time connecting
elsewhere can be rather large. Even though the University has a T3 from
Sprint, the congestion renders the connection useless.

> The point being that
> attempting to provide relatively good video (within the existing
> infra-structure) over the Net is almost impossible.

Even WITH congestion from Sprint, I can often obtain 3-4fps MJPEG color
from CU-SeeMe users...and 1-2fps in B&W. It's not impossible, but from
your point of view it probably is.

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

I do the same thing..simply because I use the 16kbps Delta-mod codec with
the Cornell version. Without pausing, audio is hopeless. More bandwidth
helps that usually.

> Sadly, even audio
> suffers from lost data resulting in poor < unacceptable audio
> quality.

packet loss can have far more drastic you not being able to
reach your destination at all. The University of Texas has been having
some network problems lately that basically isolates it from the rest of
the yeah, audio quality is affected as well.

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

"works consistently"? when your network connection is consistently
horrible? That's asking a lot. There's a lot of packages which work
consistently given decent network conditions.

> Even so, the quality of each connection varies widely. This
> brings me to my questions / suggestions.

The quality of internet service varies widely from second to second :)

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

You probably don't REALLY want this...instead of getting parts of imagines
that may total a picture within a minute or so, you'd then not get ANY
image for 10-15 minutes at a that acceptable to you?
As I understand it, this is what MJPEG does..and one reason why I think
it's so susceptible to packet loss. With a high packet loss, a frame is
never completed and is therefore never shown (though I'm no expert on the
MJPEG codec..just an educated guess). This means if you watch 4 MJPEG
windows, they all will halt since they don't have the bandwidth to
complete the frames and the packet loss shoots up.

In your case, that would mean maybe not EVER getting a frame of
video...acceptable? don't's not to me...but it works great where
you have a good 15-20kbps receiving window.

The only videoconferencing programs I know which display differences in
frames are CU-SeeMe and iVisit...everyone else seems to compress the vid
enough to send the entire frame each time.

> 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 <>. However running the software
> in point to point video connections produces very poor results.

I haven't tried xtx in about a year, but I imagine the trouble is
determining what a bite is. If the problem with the network connection is
packet loss, it doesn't matter how you define a bite, the problem
persists. Sound and video are continuous streams..dividing it up into
blocks like "bites" doesn't make sense. That's like sending video for 2
seconds then stopping. While it happens more in audio, you can't assume
everyone will talk in 2 second chunks..pausing every 2 seconds for it to
send. It's real-time multimedia.

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

FTP is able to transmit and retransmit because it's using TCP, not UDP. I
don't know of any videoconferencing applications which use TCP to transfer
its data. There's a lot of overhead in TCP..imagine how slow everyone's
vid would be if each bit had to be correct and packets were constantly
resent to try and get a perfect "transfer". This renders real time
traffic useless. That's why it's up to the application, not the transport
layer to handle packet loss/corruption/etc. The time it takes to
retransmit packets and verify their correctness is usually so great in
live traffic that it's easier just to allow for packet loss and continue
sending. But then, UDP wasn't exactly built to handle real time streaming
of video and audio. IP version 6 is. I've heard some good things about
the future of the net with respect to bandwidth reservation. The ability
to reserve bandwidth from point A to point B for a set amount of time
(RSVP, etc) and all the routers in between. Some see that as a godsend
for videoconferencing since you'd be guaranteed to have bandwidth into and
out of every router in between. Videoconferencing has a chance to really
take hold then. But then others point out that the overhead of bandwidth
reservation renders it useless. I'm no expert on it..just interested in
it. Needless to say, the videoconferencing world is changing and will
continue to change for quite sometime.

--    * Jason Williams -- Austin, Tx.  |     |       * University of Texas at Austin  | ___ |         * BS Computer Science             \_|_/
*************** **************|