Retired Document
Important: Apple recommends that developers explore QTKit and Core Video for new development in this technology area. See QTKit Framework Reference and Core Video Programming Guide for more information.
About QuickTime Streaming
This chapter discusses the basics of QuickTime streaming and the variety of protocols that can be used to stream QuickTime movies.
Streaming involves sending movies from a server to a client over a network such as the Internet. The server breaks the movie into packets that can be sent over the network. At the receiving end, the packets are reassembled by the client and the movie is played as it comes in. A series of related packets is called a stream.
QuickTime Streaming extends the QuickTime software architecture to support the creation, transmission, and reception of multimedia streams. This allows QuickTime programmers to create applications that receive multimedia in real time, and to create authoring and editing tools that work with streaming content. Existing applications that play QuickTime movies can play real-time streaming movies with little or no code change.
Streaming is different from simple file transfer, in that the client plays the movie as it comes in over the network, rather than waiting for the entire movie to download before it can be played. In fact, a streaming client may never actually download a streaming movie; it may simply play the movie’s packets as they come in, then discard them.
QuickTime movies can be streamed using a variety of protocols, including
HTTP (Hyper Text Transport Protocol)
FTP (File Transfer Protocol)
RTP (Realtime Transport Protocol).
HTTP and FTP are essentially file transfer protocols. Any QuickTime movie saved using the QuickStart option can be streamed using these protocols because the QuickTime client software is able to start playing the movie before the entire file has arrived.
RTP is used for real time streaming. The movie packets are sent in real time, so that a one-minute movie is sent over the network in one minute. The packets are time-stamped, so they can be displayed in time-synchronized order. Because packets are sent in real time, RTP streaming works with live content in addition to previously-recorded movies. It can even carry a mixture of the two.
Real-time streams can be sent one-to-one (unicast) or one-to-many (multicast).
Unicast Streaming
In a unicast, the client contacts the server to request a movie using RTSP (Real Time Streaming Protocol). The server then replies to the client over RTSP with information describing the movie as a streaming session. A streaming session consists of one or more streams of data, such as a video stream and an audio stream. The server tells the client how many streams to expect and gives details on each stream, such as the media type and codec. The actual streams are then sent to the client over RTP. When a QuickTime movie is streamed over RTP, each track in the movie is sent as a separate stream as shown in Figure 1-1.

A stream can contain live content, such as a stock ticker or a radio broadcast, or stored content, such as a video track from a QuickTime movie. When a client is receiving unicast streams from stored content, the client’s movie controller includes a “thumb” that allows the user to jump to any point in the movie. This gives the client random access to long movies without having to download an entire movie or store it locally. The client simply asks the server to begin streaming the movie from a new point (see Figure 1-2).

Multicast Streaming
In a multicast, one copy of each stream is sent over each branch of a network. This reduces the amount of network traffic required to send the streams to large numbers of clients. A client receives the streams by “joining” the multicast.
The client finds out how to join the multicast by opening an SDP (Session Description Protocol) file. The SDP file contains the information needed to join the multicast, such as group address and port number, as well as the stream description information that would come over RTSP for a unicast. See Figure 1-3. SDP files are commonly posted on web servers to announce upcoming multicasts.

Not all routers support multicasting. QuickTime clients behind routers that don’t implement multicasting can still receive a multicast by requesting the streams from a reflector. A reflector is an RTSP server that joins a multicast, then converts the multicast into a series of unicasts, passing the streams to clients who request them (see Figure 1-4). The original server may be sending live content, such as a concert or a news broadcast, or a previously-recorded movie. The reflector is always sending “live” data, passing the streams in real time.

When a QuickTime client is viewing a multicast or a live unicast, the user’s movie controller has no “thumb” control (see Figure 1-5). The user can stop or resume the display, and may have audio controls if the movie includes a sound stream, but there is no way to skip forward or back in a live transmission or a multicast.

Streaming QuickTime Over RTP or HTTP
QuickTime supports streaming over RTP and HTTP. The main advantages of streaming over RTP are:
RTP can be used for live transmission and multicast.
Real-time streaming allows the user to view long movies or continuous transmissions without having to store more than a few seconds of data locally.
Using RTP transmission under RTSP control, a user can skip to any point in a movie on a server without downloading the intervening material.
You can stream a single track over RTP, whereas HTTP streams only whole movies. RTP streams can be incorporated in a movie using streaming tracks. A streaming track is a track in a QuickTime movie that contains the URL of the streaming content.
A QuickTime movie that contains streaming tracks can also include non-streaming tracks whose media exist on the client’s computer. This allows a live transmission, or data stored on the Internet, to be incorporated into a movie along with material stored on the client’s hard drive or distributed over CD-ROM.
RTP uses UDP/IP protocol, which doesn’t attempt to retransmit lost packets. This allows multicasts as well as live streams, both cases where retransmission would not be practical.
The main advantages of streaming over HTTP are:
HTTP uses TCP/IP protocol to ensure that all movie packets are delivered, retransmitting if necessary.
HTTP does not attempt to stream in real time. To stream in real time, the bandwidth of the network must be greater than the data rate of the movie. If there is not enough bandwidth to transmit the movie in real time, streaming by HTTP allows the client to store the data locally and play the movie after enough has arrived.
Most firewalls and network configuration schemes will pass HTTP without modification.
Any QuickTime movie can be streamed using HTTP. QuickTime supports RTP streaming of video, audio, text, and MIDI. To stream a movie with other media types, such as sprites, you should use HTTP.
Multimedia Streaming
Early versions of QuickTime supported unicast streaming of whole movie files using HTTP.
QuickTime now supports Realtime Transport Protocol (RTP), which can be used for multicasts and for transmission of live content, as well as unicast of stored movies. QuickTime also provides the ability to stream individual tracks via RTP, allowing developers to incorporate live or remotely-stored content in a local movie.
QuickTime supports using RTSP for streaming control. QuickTime includes client software that can receive multicasts directly from routers. This software is standards-based and is interoperable with products such as VIC, VAT, or Cisco’s IP/TV. QuickTime understands SDP files, which are used to “tune into” multicast streaming sessions.
QuickTime supports RTP streaming of audio, video, MIDI, text (including HREF tracks), and tweens. RTP streaming of other media types is not supported, but movies with other media types can incorporate streaming content.
QuickTime supports IETF standard payload types for RTP:
Video
H.261
H.263+
H.264
DVI
JPEG
Audio
Qualcomm QCELP
GSM (receive only)
Raw audio
a-law
QuickTime supports QuickTime in RTP packing for all QuickTime encodings of
video
audio
text
MIDI
tween
Special packing is included for optimized transmission of some QuickTime codecs, including
Sorenson video
Qualcomm Purevoice audio
QDesign music
If you have your own codec, you can design special packing for it by writing a packetizer and a reassembler, as described later in this chapter.
The QuickTime File Format supports hint tracks, which simplify the process of packetizing QuickTime movies into RTP streams. Hint tracks allow QuickTime movies to be served from RTP servers without requiring the servers to have QuickTime software installed or to know about QuickTime media types or codecs.
QuickTime includes the ability to export QuickTime movies as hinted movies that can be streamed over RTP.
Copyright © 2005, 2009 Apple Inc. All Rights Reserved. Terms of Use | Privacy Policy | Updated: 2009-06-01