Multipoint Publishing

A new feature available in all editions of Flash Media Server 3, the multipoint publish feature gives flexibility and scalability to your streaming applications. Previously, if you were using a content delivery network (CDN)—for when you require massive capacity and high reliability for delivering digital media files such as video, music, games, software, and social media—to deliver your streaming content, you were unable to implement any custom server-side code or inject any data messages into the outbound stream. Now, with multipoint publishing, you can use your own Flash Media Server (or Flash Media Encoder) to control the feed to the CDN, which then broadcasts it to your clients (as shown in Figure 5).

Note: The free development edition can actually be used in commercial applications as this local live publishing point.

Multipoint publishing can be used to build large-scale live video applications or to inject metadata into a live stream. For example, you could create an Internet TV station and publish the stream to a Flash Media Development server, which would publish the stream to a larger Flash Media Interactive Server deployment, such as a CDN that pushes the stream to millions of users.

Multipoint publishing allows clients to publish to servers with only one client-to-server connection. This feature enables you to build large-scale live broadcasting applications, even with servers or subscribers in different geographic locations.

Note: To use multipoint publishing, you need to write server-side code in a main.asc file.

Metadata

One of the challenges in live video broadcast is the need for current stream metadata to be sent to viewers who are connecting midstream. Unlike an on-demand stream, where metadata can always be at the beginning of the stream and received when a user first subscribes, live streams can be subscribed to at any time. Therefore, these latecomers may never receive the live stream's metadata. Data keyframes eliminate this issue by sending metadata to new subscribers when they join the stream.

So, if you create live streams that you do not record, or you want to add additional information, you need to set the metadata yourself. The metadata you add is in the form of data keyframes. Each data keyframe can contain multiple data properties, such as a title, height, width, duration of the video, the date it was created, the creator's name, and so on. Now, any client connecting to the server receives the metadata when the live video is played.

Note: The Flash Video Exporter utility (version 1.1 or later) is a tool that embeds a video's duration, frame rate, and other information into the video file itself. Other video encoders embed different sets of metadata, or you can explicitly add your own metadata.

Client-Server Architecture

Adobe Flash Media Server applications have a client-server architecture. The client code is written in ActionScript and runs in Adobe Flash Player, Adobe AIR, or Adobe Flash Lite. The server code is written in Server-Side Action-Script, which is similar to ActionScript 1.0.

The server and the client communicate over a persistent connection using Real-Time Messaging Protocol (RTMP). RTMP is a reliable TCP/IP protocol for streaming and data services. In a typical scenario, a web server delivers the client over HTTP. The client creates a socket connection to Flash Media Server over RTMP. The connection allows data to stream between client and server in real time. This architecture is illustrated in Figure 6.

Real-Time Messaging Protocol

All server editions communicate with Flash Player, AIR, and Flash Lite over Real-Time Messaging Protocol. RTMP is optimized to deliver high-impact streams in real time. An RTMP connection can multiplex any number of streams. Each stream contains synchronized audio, video, and data channels. Remote method invocation and shared object messages are carried in a data-only stream.

There are five types of RTMP connections supported by Flash Media Server 3:

RTMP: This is the standard, unencrypted Real-Time Messaging Protocol. The default port is 1935; if a port is not specified, the client attempts to connect to ports in the following order: 1935, 443, 80 (RTMP), 80 (RTMPT).

RTMPT: This protocol is RTMP tunneled over HTTP; the RTMP data is encapsulated as valid HTTP. The default port is 80.

RTMPS: This protocol is RTMP over SSL. SSL is a protocol for enabling secure communications over TCP/IP. (Flash Media Server provides native support for both incoming and outgoing SSL connections.) The default port is 443.

RTMPE: This protocol is an encrypted version of RTMP. RTMPE is faster than SSL, does not require certificate management, and is enabled in the server's Adaptor.xml file. If you specify RTMPE without explicitly specifying a port, the Flash Player scans ports just like it does with RTMP, in the following order: 1935 (RTMPE), 443 (RTMPE), 80 (RTMPE), and 80 (RTMPTE).

RTMPTE: This protocol is RTMPE with an encrypted tunneling connection. The default port is 80.

Note: RTMP should not be confused with RTSP. RTSP (Real Time Streaming Protocol) is another protocol for use in streaming media systems that allows a client to remotely control a streaming media server, issuing VCR-like commands such as "play" and "pause," and allowing time-based access to files on a server. The References section includes two links to additional information on RTSP.

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.

Thanks for your registration, follow us on our social networks to keep up-to-date