Programming Flash Communication Server

This is the Title of the Book, eMatter Edition

Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.

Publishing Streams in Detail

|

161

Bandwidth and Performance Problems

Network bandwidth can vary dramatically depending on the type of connection

(LAN, DSL, modem) and on the quality of all the network segments between the

publishing movie and the FlashCom Server. The bandwidth may also vary signifi-

cantly during the life of the connection. Each stream travels within a network con-

nection, and multiple publishing and subscribing streams cannot send or receive

more data than the connection is capable of carrying at any moment. For example, a

connection via modem may allow sending a total of 56 Kbps of data while receiving

56 Kbps of data. Sending a single video stream at 16 KB/s (131 Kbps because there

are 8 bits in a byte) will therefore cause a problem. Even worse, receiving three 16

KB/s streams is not possible. Most of the data will have to be dropped to reduce the

total from 48 KB/s to 56 Kbps and the arrival of data will have to be delayed. Fur-

thermore, the ideal speed of 56 Kbps is rarely achieved on a dial-up modem.

Throughput of 33 Kbps is more realistic. On the other hand, someone with a good

DSL connection will have no problems sending one video stream or receiving the

same three video streams.

The amount of data that a movie attempts to publish within a stream largely depends

on how the video and audio sources attached to the stream are configured. The reso-

lution and frame rate of the video source and sampling rate of the audio source are

just some of the adjustments that can be made to control data rates. Using the Cam-

era and Microphone classes to control the amount of data sent in a stream is

described in detail in Chapter 6. Before video data can be carried by the stream, it

has to be captured from a device and compressed. The publishing system’s CPU may

not be able to process all the video data in real time. At high video resolutions, the

system may have to drop video frames in order to avoid falling too far behind the

video source. Even when the system can capture all the audio and video data, the

stream may not have sufficient bandwidth available to it to carry all the data. Send-

ing large amounts of ActionScript data can also adversely impact performance (later,

we’ll look at ways to minimize the bandwidth required for ActionScript data).

The RTMP protocol runs over a reliable TCP connection, which means that unlike

UDP streaming protocols, any lost data packets are resent in order to guarantee they

are delivered. When a stream contains more data than can be sent because of band-

width limitations, data must be either held in a buffer until it can be sent or dropped

at the source.

For live streams, when users want to communicate in real time, buffering is not a

practical option. Therefore, for live streams, RTMP uses a scheme that does two

things:

• Prioritizes data into three classes so that audio receives the highest priority and is

therefore delivered as soon as possible. Data is given second priority, and video

the lowest priority.