Reliable RTP:by QuickTime Streaming Server Modules

[출처]http://netmedia.kjist.ac.kr/courses/dic1698-2002sp/reports/streamingproject-misc.htm

Reliable RTP: This article is written in the QuickTime Streaming Server Modules.

Reliable RTP is a set of features for RTP that improve the protocol’s ability to present a good quality stream to the RTP client even in the event of packet loss and network congestion. Reliable RTP also includes congestion control, so streams behave in a TCP-friendly fashion without disturbing the real-time nature of the

protocol. To work well with TCP traffic on the Internet, Reliable RTP uses retransmission and congestion control algorithms that are similar to the algorithms used by TCP. Additionally, those algorithms are time tested to utilize available bandwidth in a near optimal fashion.

RTP features include

_ Client acknowledgment of packets sent by the server to the client

_ Windowing and congestion control so the server does not exceed the currently available bandwidth

_ Server retransmission to the client in the event of packet loss

_ Faster than real-time streaming known as “overbuffering”

Whether a client uses Reliable RTP is determined by the content of the client’s RTSP SETUP request. Acknowledgment Packets The Reliable RTP server expects to receive an acknowledgment for each RTP packet it sends. If the server does not receive an acknowledgment for a packet, it may retransmit the packet. The client does not need to send an acknowledgment packet for each RTP packet it receives. Instead, the client can coalesce acknowledgments for several packets and send them to the server in a single packet.

The Reliable RTP acknowledgment packet format is a type of RTCP APP packet. After the standard RTCP APP packet headers, the payload for an acknowledgment packet consists of an RTP sequence number followed by a variable length bit mask. The sequence number identifies the first RTP packet that the client is

acknowledging. Each additional RTP packet being acknowledged is represented by a bit set in the bitmask. The bit mask is an offset from the specified sequence number, where the high order bit of the first byte in the mask is one greater than the sequence number, the second bit is two greater, and so on. Bit masks must be sent in multiples of four octets. Setting a bit to 0 in the mask simply means that the client does not wish to acknowledge this sequence number right now and does not imply a negative acknowledgment.

Streaming QuickTime Over RTP or HTTP

QuickTime 4 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 4 supports RTP streaming of video, audio, text, and MIDI. To stream a movie with other media types, such as sprites, you should use HTTP.

Features In QuickTime 4

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.

Earlier versions of QuickTime supported unicast streaming of whole movie files using HTTP. QuickTime 4 adds support for Realtime Transport Protocol (RTP), which can be used for multicasts and for transmission of live content, as well as unicast of stored movies. QuickTime 4 also adds the ability to stream individual tracks via RTP, allowing developers to incorporate live or remotely-stored content in a local movie.

This release of QuickTime supports streaming using RTP transport for media and RTSP protocol for control.

This release of 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.

This release of QuickTime understands SDP files, which are used to "tune into" multicast streaming sessions.

This release of QuickTime supports RTP streaming of audio, video, MIDI, text (including HREF tracks), and tweens. RTP streaming of other media types is not supported in this release, but movies with other media types can now incorporate streaming content.

This release of QuickTime supports IETF standard payload types for RTP:

	Video H.261 H.263+ DVI JPEG
	Audio Qualcomm QCELP GSM (receive only) Raw audio -law a-law

This release also supports QuickTime in RTP packing (IETF draft) 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.

This release of QuickTime extends the QuickTime File Format to include 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.

This release of QuickTime adds the ability to export QuickTime movies to hinted movies that can be streamed over RTP.

This release of QuickTime does not support RTP streaming of track references. Some QuickTime features, such as effects, chapter lists, and various applications of tweens, make use of track references. These features can be included in client movies that incorporate RTP streaming content, as described in the section Creating Streaming Movies .

Serving Streaming Movies

To serve QuickTime movies over RTP, your movie server must be equipped with RTP server software that understands the QuickTime file format, including the structure of hint tracks , which are described in the section "Hint Track Structure" . Your server also needs an RTSP controller application.

Your server does not need to have QuickTime software installed to serve streaming movies.

If your server is merely acting as a reflector for multicasts, no special software is required to reflect QuickTime movies. Forward the RTP streams on request in the usual way.

Your server uses the hint tracks in a streaming QuickTime movie to packetize the movie's media into RTP streams. Hint tracks are added to QuickTime movies to prepare them for streaming over RTP. One hint track is added to the movie for each track whose media will be streamed, as illustrated below.

Figure8 Streaming a hinted movie

If your server is sending a unicast of a hinted movie, the QuickTime movie controller will provide the client with the ability to pause the movie and to skip backward and forward in movie time. This will be communicated to your server over RTSP.

The RTP server does not need to know about QuickTime media types or codecs. The hint tracks within the movie file provide the information needed to turn QuickTime media into RTP packets. Each hint track contains the data needed to build packet headers for a specific track's media. The hint track also supplies a pointer to the media data that goes into each packet.

The RTP server needs to be able to parse a QuickTime movie file sufficiently to find each hint track, then to find the track and sample data that the hint track points to. The hint track contains any precalculated values that may be needed, making it easier for the server to create the RTP packets.

Hint tracks offload a great deal of computation from the RTP server. Consequently, you may find that an RTP server is able to send data more efficiently if it is contained in a QuickTime movie, even if the RTP server already understands the media type, codec, and RTP packing being used.

For example, the H.263+ video codec is an IETF-standard RTP format which your server may already understand, but creating an H.263+ stream from video data requires complex calculations to properly determine packet boundaries. This information is precalculated and stored in the hint track when H.263+ video is contained in a QuickTime movie, allowing your server to packetize the data quickly and efficiently.

If you are writing QuickTime extensions to an RTP server application, you will need to read the QuickTime File Format , as well as the Hint Track Format section of this document.

Receiving Streaming Movies

An application receives streaming content by opening a movie and playing it.

Opening A Streaming Movie

In general, opening a streaming movie is like opening any QuickTime movie. You can open a streaming movie by opening

	a movie file that contains streaming tracks
	an SDP file
	a URL

You can open a movie file that contains streaming tracks, or open an SDP file, by calling NewMovieFromFile in the usual way.

You open a movie from a URL by calling NewMovieFromDataRef with a URL data reference. The URL for a real-time streaming movie will use RTSP:// protocol. The following is a code sample for opening a movie from an RTSP URL:

char url[] = "rtsp://www.mycompany.com/mymovie.mov";
Handle urlDataRef;

urlDataRef = NewHandle(strlen(url) + 1);
if ( ( err = MemError()) != noErr) goto bail;

BlockMoveData(url, *urlDataRef, strlen(url) + 1);

err = NewMovieFromDataRef(&movieInfo->theMovie, newMovieActive,
nil, urlDataRef, URLDataHandlerSubType);
DisposeHandle(urlDataRef);

It's also possible to open a movie file from an HTTP:// or FTP:// URL, and for that movie file to contain streaming tracks.

If you open a streaming movie from a URL or an SDP file, the Movie Toolbox will call the appropriate movie importer. If you open a movie file that contains streaming tracks, stream importers will be called.

Figure6 Opening a streaming movie

Opening a streaming movie typically takes more time than opening a movie with purely local content. Each track in the movie on the server is transmitted as an RTP stream, so the client computer must establish a network connection with the server for each track, and often must establish a connection for RTSP control as well. This takes time, particularly if a dial-up connection must be established.

It also means the Movie Toolbox can return connection status messages or networking errors in the process of opening a movie.

Playing A Streaming Movie

Applications that can already play QuickTime movies need to take the following steps to play real-time streaming movies reliably:

	Open movies with high-level Movie Toolbox calls or a movie importer.
	Do not assume that the track structure of the movie you play reflects the track structure of the original movie; a streaming track can contain sound, video, text, MIDI, or all of these.
	Use a movie controller to play the movie, or use the new PrePrerollMovie function to set up any streams before playing the movie.
	Display status messages returned by the movie controller.
	Be prepared to deal with network errors when your application plays a movie (see "Common Streaming Error Codes" ).
	Be prepared for movie characteristics to change dynamically; the height, width, duration, and whether or not the movie has audio or video can all change as the movie plays.
	Do not assume that the movie will begin immediately.

The following sections describe some of these steps in more detail.

Track Structure

Unlike other QuickTime movies, streaming movies consist of two distinct movie files--one on the server and the other on the client machine--often with different track structures. You sometimes need to distinguish between the server movie and the client movie .

The media of each track in the server movie is transmitted as a separate RTP stream. On the client side, multiple RTP streams can be combined into a single streaming track.

If you open a movie from a URL, for example, the movie importer may create a client movie that contains only a streaming ( 'strm' ) track. Unlike most other QuickTime track types, a streaming track can contain multiple media streams of different types. A streaming track in a client movie may contain the URL of a server movie with audio, video, text, and/or MIDI tracks.

Figure7 Server movie and client movie

The client movie file never contains audio or video media from the server movie; they are displayed and discarded. If a client movie is saved, the saved movie contains information such as the URL of the server movie and the currently-displayed movie time. The client movie can also contain local tracks and local media, but the media samples in the server movie remain on the server except when playing.

Pre-Prerolling

Before any movie is played, QuickTime needs to allocate buffers and open appropriate media handlers. This process is called prerolling the movie. Before a streaming movie can be played, additional steps need to be taken, such as establishing RTP streams between the client and the server. This setup process is called pre-prerolling . Pre-prerolling is performed automatically when a streaming movie is played using a movie controller. If your application uses movie controllers to play movies, you do not need to take any special steps to pre-preroll a streaming movie.

If you are playing movies using lower-level commands, you will need to use the new PrePrerollMovie function to set up the network connections for a streaming movie before you can preroll or play the movie. The PrePrerollMovie function does nothing unless a movie contains streaming content, so it's safe to call it for all movies. A code sample follows.

PrePrerollMovie(myMovie, 0, GetMoviePreferredRate(myMovie),
NewMoviePrePrerollCompleteProc(MyMoviePrePrerollCompleteProc),
(void *)0L);

PrePrerollMovie operates either synchronously or asynchronously, depending on whether you specify a completion procedure when you call it.

If called asynchronously, it returns almost immediately, even if the movie contains streaming content. This allows your application to perform other tasks while awaiting the completion of the pre-prerolling. You need to call MoviesTask periodically to grant time for the task of pre-prerolling when using it asynchronously.

When the pre-prerolling is finished, PrePrerollMovie calls the completion procedure whose address you pass in the NewMoviePrePrerollCompleteProc parameter. In the simplest case, the completion procedure will want to preroll and start the movie.

If no completion procedure is specified, PrePrerollMovie returns when the pre-preroll process is complete

Reacting to Changes in Movie Characteristics

One feature of streamed movies is that their characteristics may change dynamically during playback. For example, when you open a movie from a URL you may not know the actual height and width of the movie, its duration, how many streams it contains, whether it has a sound track, or whether it is an audio-only movie.

QuickTime will assign default values to these characteristics if they are unknown. QuickTime can notify your application when the movie characteristics become known or are changed.

In most cases, your application will want to adjust the size of the window or pane that contains the movie to reflect such changes. You make these adjustments by implementing a movie controller action filter proc.

To do this, you first need to indicate to the Movie Toolbox that you want to be informed of any changes. You do this by setting a movie playback hint:

SetMoviePlayHints(myMovie, hintsAllowDynamicResize,
hintsAllowDynamicResize);

Changes in the movie size are announced to your filter proc by the mcActionControllerSizeChanged selector. Changes in other movie characteristics are announced through the mcActionMovieEdited selector.

Size Changes

Whenever the size of the movie changes, the associated movie controller sends the mcActionControllerSizeChanged action to your movie controller action filter procedure. You can intercept that action and respond to it as follows:

pascal Boolean MyMCActionFilterProc (MovieController theMC, short theAction, void *theParams,
long theRefCon)

{
MoviemyMovie = MCGetMovie(theMC);

switch (theAction) {
// handle window resizing
case mcActionControllerSizeChanged:
MyResizeWindow(myMovie);
break;

default:
break;
}

return(false);
}

Duration Changes

The duration of a streaming movie or a streaming track may not be initially known. A track or movie whose duration is not known is assigned an indefinite duration : x7FFFFFF . If you do not treat this as a special case, a streaming movie will appear to your application as a very long movie indeed.

Once the pre-preroll process is complete, QuickTime should know the actual duration of the streams. If you set an action filter proc and call SetMoviePlayHints , your application will be called with the mcActionMovieEdited selector when QuickTime determines the actual duration.

If the movie contains live content, it may not have a specific duration. In this case, the duration remains indefinite: x7FFFFFF . You might want to set a timeout in your code that detects the fact that QuickTime has not adjusted the duration from x7FFFFFF after a few seconds of movie play. QuickTimePlayer uses such a timeout and displays a "Live Transmission" message where the slider would be for a movie with a known duration.

Sound and Video Changes

Whether a streaming movie has sound ( 'ears' ) or is sound-only (no video) may not be initially known or may change dynamically. If you set an action filter proc and call SetMoviePlayHints , your application will be called with the mcActionMovieEdited selector when the sound or video characteristics change.

Other Playback Considerations

Streaming movies only play back at a rate of 1 . Other playback rates, such as playing backward, are not supported.