Programming Flash Communication Server

This is the Title of the Book, eMatter Edition

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

162

|

Chapter 5: Managing Streams

• Decides what data to drop if the client and network cannot keep up. Video data

requires more bandwidth and is generally rated as less important than audio to

most observers. Video data is therefore dropped before audio. Under extreme

circumstances, if dropping video data does not reduce the amount of data to

what the network can handle, audio data will also be dropped. ActionScript data

is never dropped.

RTMP does not provide on-the-fly adjustments of video compression in order to

dynamically adapt to bandwidth limitations. However, the

NetStream.currentFps

property returns the actual video frame rate being published, and the quality settings

of the Camera object can be adjusted to change the level of video compression or

even the video resolution.

As RTMP adapts to the difference between the amount of data it is trying to send

and the capacity of the network, video may be delayed more than the audio, causing

them to get out of sync. RTMP gives preference to delivering audio because it is

important to hear a conversation with as little latency as possible. Audio latency and

video synchronization were improved in FlashCom 1.5.

RTMP has to adapt to bandwidth twice during the publishing and playing of a

stream. The Flash Player publishing the stream must adapt to the network band-

width available between the Player and the FlashCom Server. When the server sends

the stream on to each subscribing movie, it must also adapt to the bandwidth avail-

able to each subscriber. It is important to remember this when designing applica-

tions. An incoming high-bandwidth stream may arrive at the server without

problems but lose most of its video frames on its way out to viewers. Stream band-

width therefore must often be optimized for the slowest viewing connection and not

for live publishing.

The amount of bandwidth any client is allocated can be capped on the server using

Client.setBandwidthLimit( ). See “Capping client bandwidth usage” later in this chap-

ter for more details.

Buffering When Publishing

When recording streams, buffering is a good idea to minimize dropped video frames.

Instead of dropping frames that cannot be sent immediately, they can be stored in a

buffer until they can be sent. If the buffer overflows, video and audio are eventually

dropped, but buffering helps to improve quality, especially when video data rates

fluctuate depending on changes in the scene being captured. By default, a NetStream

object being used for publishing has a buffer time of 0 seconds (no buffering is per-

formed). To change it, use NetStream.setBufferTime( ). For example, to set the buffer

time to 2 seconds:

out_ns.setBufferTime(2);