Contents
Navigation
Home User Reference Other Resources


QuickTime 4 introduced support for receiving real–time streamed data. That is to say, QuickTime–savvy applications can receive video, audio, and other kinds of data streamed across the Internet. Real–time streaming, unlike the progressive downloading of movie files that has been available since QuickTime 3, can handle live data and does not require downloading potentially huge files onto the user’s computer; this permits QuickTime playback applications to support uses such as video–on–demand and rebroadcast streaming.

The real–time streaming provided by QuickTime 4 was a client–side technology only; it did not provide any means to serve up, or transmit, the data streams. QuickTime 5 provides a set of broadcasting functions that allow us to create transmitter applications. For example, we can take the audiovisual data captured by a camcorder attached to one computer and broadcast that data to other computers on a network. Together, the transmitter technologies provided by QuickTime 5 and the receiver technologies provided by QuickTime 4 give us the complete set of tools we need to send audiovisual streams from one computer and view them on another. The good news here is that we need to know virtually nothing about the applicable IETF specifications to do all this; the really good news is that the amount of code we need to write to create a broadcasting application is surprisingly small. Indeed, we'll be able to write this application using fewer than a dozen of these new broadcasting functions.

The Real–Time Streaming Framework featured by the QTPlugin is a set of classes that allow developers to gain access to both the transmitter and receiver technologies provided by the QuickTime APIs within the Realbasic environment.

The QTPlgStreamSessionParams utility class is part of the Real–Time Streaming Framework and is used to specify whether the audiovisual characteristics of the streams that have to be sent or received from a and the SDP data that clients and servers will use for initiating a network connection and transfer of multimedia streams.

Using this class requires QuickTime 4.0 or later.







The QTPlgStreamSessionParams class constructors are called when you create a new instance of the class, while the ˜QTPlgStreamSessionParams class destructor, is called automatically when the class is no more in use. Also, you can invoke the class destructor by setting the instance of the class to nil.

Once a new class instance is returned, it is good practice to check the class property to be sure that the new object can be used. An instance of this class is valid if you have specified a valid for the incoming (or outcoming) .


The class provides you with the following initializer methods:
()
This is the default constructor. Any class property is set to its default status
(other as QTPlgStreamSessionParams)
This is the copy constructor. The properties of the object to be copied will be used to initialize the new class instance properties

specifies the audio properties of the . In case of a , modifying these properties will affect the characteristics of the presentation even during the data transmission; otherwise, the values of this property will be used during the setup of the presentation only
specifies the video properties of the . In case of a , modifying these properties will affect the characteristics of the presentation even during the data transmission; otherwise, the values of this property will be used during the setup of the presentation only
specifies the source of the information about some of the network settings to be used by the , such as the destination (or source) IP address for the streamed data and the ports to use for the data streams. The IETF has defined a standard format for this information, called the session description protocol (SDP). SDP data are used by clients and servers for initiating a network connection and transfer of multimedia streams between a server and its clients. This data describe the types and formats of the media to be transferred, the transport protocols, and the addresses to which the media are to be streamed. The source of the SDP data can be whether an SDP file (that is, a file that conforms to the SDP) or a string; you specify the type of source by initializing a object with the appropriate . Here's a sample SDP data:
v=0
c=IN IP4 224.2.1.2/15/1
m=audio 1000 RTP/AVP 12
m=video 2000 RTP/AVP 101
a=rtpmap:101 H263-1998
The line beginning with "v=" specifies the protocol version, which currently is 0. The line beginning with "c=" specifies the connection information, which consists of a network type and address type (here, "IN IP4" for IP version 4 addressing on the Internet), the destination address (here, "224.2.1.2", which is an address reserved for multicasting), a time–to–live value (here, 15), and the number of contiguous multicast addresses (here, 1). The lines beginning with "m=" indicate which transport protocols and ports to use for specific media types. In the file shown above, the audio data is to be sent via RTP to port 1000 and the video data is to be sent via RTP to port 2000. Finally, the line beginning with "a=" specifies media attributes. In this case, the rtpmap attribute provides information about dynamic payload binding. In case of a , the source file can contain a rtsp address (that is an address in the form rtsp://) instead of SDP data

()
use this method to roll all of the class properties back to their initial state
returns nothing