Media Server

The roMediaStreamer object allows you to configure a pipeline of multimedia processing elements for execution. This may involve streaming the results over RTP or UDP, but it is not capable of behaving as a true server, which listens for connections and then acts upon them. This is the job of the Media Server, represented by the roMediaServer object.

The Media Server waits for requests, deals with any negotiation, and ultimately creates a Media Streamer pipeline which it executes to fulfill the request. The Media Server currently supports the RTSP protocol (as used, for example, by VLC), and HTTP requests. These requests from the client must take the following form:

• protocol: Either rtsp or http

• IP_address:port: The IP address of the BrightSign player and the port number on which the Media Server is running. For more information, refer to the example below.

• media_streamer_pipeline: A Media Streamer pipeline as given in previous examples, but without the final destination component (as the destination is implicit in the request from the client).

Media Server features are currently not available in BrightAuthor, but you can set up a streamer/server using the Media Server plugin.

Initializing the Media Server

An RTSP Media Server can be started as follows:

This will start an RTSP server listening on port 554. The port number and streaming protocol can be customized: For example, an HTTP server can be started on port 8080 instead as follows:

The media server supports a number of optional parameters after the port parameter, which may be appended to the command string with an "&" (ampersand):

• port: Specifies a port number for the server. If this parameter is not specified, the server defaults to 554 for RTSP and 8080 for HTTP.

• trace: Displays a trace of messages in the negotiation with the client. This parameter is useful primarily for debugging RTSP sessions. For example: rtsp:port=554&trace

• maxbitrate: Sets the maximum instantaneous bitrate (in Kbps) of the RTP transfer initiated by RTSP. This parameter has no effect for HTTP. The parameter value 80000 (i.e. 80Mbps) has been found to work well. The default behavior (also achieved by passing 0) is to not limit the bitrate at all. For example: rtsp:port=554&trace&maxbitrate=80000

• threads: Sets the maximum number of threads the server is prepared to have running. Each thread handles a single client request. The default value is 5. For example: http:port=8080&threads=10

To stop the Media Server, use the Stop() method. This actually signals all the threads to stop, but does not wait for this to happen. To block until everything has truly finished, either use s.Terminate() (which may also be used on its own), or simply allow the Media Server object to be subject to garbage collection.

Media Server Examples

These examples are client-side URLs that can be pasted into VLC for testing. Note that spaces between the Media Streamer pipeline components, as well as filenames containing commas, are not permitted.

Requesting a File To Be Streamed

Use the following URL to request the server to stream a file from local storage.

The loop parameter can be appended to loop the file indefinitely:

Use the following to stream the file.ts using HTTP instead:

Requesting an Encoded HDMI Input Stream

Use the following URL to request the server stream its HDMI^® Input:

Requesting a Memory Stream

Memory streams that have been previously configured can be requested either by RTSP or HTTP. The following example will stream the memory stream named name, which has been previously set running:

Note that /stream.ts is appended to denote the entire stream, rather than merely portions of it (as in the HLS case).

Requesting an HLS Stream

An indexed (i.e. non-simple) memory stream component must be already running to service an HLS request. HLS streaming can be initiated by requesting the following URL:

This will fetch the playlist file for the memory stream named name. Observe that /index.m3u8 must be appended to denote the index file, rather than the stream itself. Alternatively, if the HLS index and segment files have been pre-saved onto the storage of the server, they can be accessed by regular HTTP requests.

URL Syntax for an RTSP Client

When specifying the URL, a BrightSign player acting as a client may interpret parts of the URL after a "?" (question mark) as options for it to parse; likewise, the stages on the Media Server that fulfill the client request may expect the same. For example, in the following URL, it may be ambiguous whether the loop parameter is destined for the player on the client side or the media streamer on the server side:

To clarify this ambiguity, the client-side player will look for parameters after the final "?", though it will ignore parameters that it does not recognize. To ensure that all parameters are going through to the server side, append an additional final "?" to the URL:

Multi-Device Pipeline Stages

When one player is acting as the streaming client, and another player is acting as the Media Server, it may at times be necessary for the client to define pipeline stages on the Media Server. For example, the client may require the Media Server to encode its HDMI Input before streaming it over HTTP (because a server cannot stream raw HDMI video frames over the network). In these cases, you can use parentheses in the client request to delineate pipeline stages on the server:

In the above example, the client-side code instructs the Media Server to encode HDMI input and stream it to the client, which then saves it as a file.

Remote Pipelines

It is possible to have a client player specify pipeline stages on the Media Server only. For example, the client can have the Media Server initialize a multicast stream, without actually connecting to the stream. The following code will command the Media Server to initialize a multicast stream using a file on its local storage:

The remote: protocol and encompassing parentheses indicate to the server that this is a fully self-contained pipeline to execute. No media is streamed to the client, but any signals (including end-of-stream and error messages) are forwarded across the socket to the client, which can use the roMessagePort object to receive such messages.

Resetting the roMediaStreamer instance on the client side will force the socket connection to close, and will thus terminate the pipeline on the server as well.