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

Figure 1-1  Unicast streaming using RTSP

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

Figure 1-2  Movie controller with thumb

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.

Figure 1-3  QuickTime lets your computer join a multicast by opening an SDP file.

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.

Figure 1-4  You can also receive a multicast through a reflector

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.

Figure 1-5  Movie controller without thumb

Streaming QuickTime Over RTP or HTTP

QuickTime supports streaming over RTP and HTTP. The main advantages of streaming over RTP are:

The main advantages of streaming over HTTP are:

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:

QuickTime supports QuickTime in RTP packing for all QuickTime encodings of

Special packing is included for optimized transmission of some QuickTime codecs, including

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.