El objeto roMediaStreamer le permite configurar una canalización de elementos de procesamiento multimedia para su ejecución. Esto puede implicar la transmisión de los resultados mediante RTP o UDP, pero no es capaz de comportarse como un servidor verdadero, que escucha conexiones y luego actúa sobre ellas. Esta es la función del Media Server, representado por el objeto roMediaServer .

El Media Server espera solicitudes, se encarga de cualquier negociación y, en última instancia, crea una canalización de Media Streamer que ejecuta para satisfacer la solicitud. El Media Server actualmente admite el protocolo RTSP (como el utilizado, por ejemplo, por VLC) y solicitudes HTTP. Estas solicitudes del cliente deben tener el siguiente formato:

protocol://IP_address:port/media_streamer_pipeline

Las funciones de Media Server actualmente no están disponibles en BrightAuthor Classic, pero puede configurar un streamer/servidor mediante el plugin Media Server.

Un RTSP Media Server puede iniciarse de la siguiente manera:

Esto iniciará un servidor RTSP que escucha en el puerto 554. El número de puerto y el protocolo de transmisión pueden personalizarse: por ejemplo, se puede iniciar un servidor HTTP en el puerto 8080 de la siguiente manera:

El media server admite varios parámetros opcionales después del parámetro puerto , que pueden añadirse a la cadena de comandos con un "&" (ampersand):

Para detener el Media Server, use el método Stop() . Esto en realidad envía una señal a todos los hilos para que se detengan, pero no espera a que esto suceda. Para bloquear hasta que todo haya finalizado realmente, use s.Terminate() (que también puede usarse por sí solo), o simplemente permita que el objeto Media Server esté sujeto a la recolección de basura.

Estos ejemplos son URL del lado del cliente que pueden pegarse en VLC para realizar pruebas. Tenga en cuenta que no se permiten espacios entre los componentes de la canalización de Media Streamer, ni nombres de archivo que contengan comas.

Use la siguiente URL para solicitar al servidor que transmita un archivo desde el almacenamiento local:

rtsp://IP_address:port/file:///file.ts

El parámetro loop puede añadirse para repetir el archivo indefinidamente:

rtsp://IP_address:port/file:///file.ts?loop

Use lo siguiente para transmitir el archivo file.ts mediante HTTP en su lugar:

http://IP_address:port/file:///file.ts

Use la siguiente URL para solicitar al servidor que transmita su entrada HDMI®:

rtsp://IP_address:port/hdmi:,encoder:

Flujos de memoriaMemory streams configurados previamente pueden solicitarse mediante RTSP o HTTP. El siguiente ejemplo transmitirá el flujo de memoria denominado name, que se había iniciado previamente:

http://IP_address:port/mem:/name/stream.ts

Tenga en cuenta que /stream.ts se añade para indicar el flujo completo, en lugar de solo partes de este (como en el caso de HLS).

Un componente de flujo de memoria indexado (es decir, no simple) ya debe estar en ejecución para atender una solicitud HLS. La transmisión HLS se puede iniciar solicitando la siguiente URL:

http://IP_address:port/mem:/name/index.m3u8

Esto recuperará el archivo de lista de reproducción para el flujo de memoria llamado name. Observe que /index.m3u8 debe añadirse para indicar el archivo de índice, en lugar del flujo en sí. Alternativamente, si los archivos de índice y segmentos HLS se han guardado previamente en el almacenamiento del servidor, se puede acceder a ellos mediante solicitudes HTTP normales.

Al especificar la URL, un reproductor BrightSign que actúa como cliente puede interpretar partes de la URL después de un "?" (signo de interrogación) como opciones para analizar; asimismo, las etapas del Media Server que atienden la solicitud del cliente pueden esperar lo mismo. Por ejemplo, en la siguiente URL, puede ser ambiguo si el parámetro bucle está destinado al reproductor del lado del cliente o al transmisor multimedia del lado del servidor:

rtsp://IP_address:port/file:///file.ts?loop

Para aclarar esta ambigüedad, el reproductor del lado del cliente buscará parámetros después del último "?", aunque ignorará los parámetros que no reconozca. Para garantizar que todos los parámetros se envíen al lado del servidor, añada un "?" final adicional a la URL:

rtsp://IP_address:port/file:///file.ts?loop?

Cuando un reproductor actúa como cliente de transmisión y otro reproductor actúa como Media Server, en ocasiones puede ser necesario que el cliente defina etapas de canalización en el Media Server. Por ejemplo, el cliente puede requerir que el Media Server codifique su HDMI Input antes de transmitirlo a través de HTTP (porque un servidor no puede transmitir fotogramas de video HDMI sin procesar a través de la red). En estos casos, puede usar paréntesis en la solicitud del cliente para delimitar etapas de canalización en el servidor:

(http://IP_address:port/hdmi:,encoder:),file:///hdmi.ts

En el ejemplo anterior, el código del lado del cliente indica al Media Server que codifique la entrada HDMI y la transmita al cliente, que luego la guarda como un archivo.

Es posible que un reproductor cliente especifique etapas de canalización únicamente en el Media Server. Por ejemplo, el cliente puede hacer que el Media Server inicialice un flujo multicast, sin conectarse realmente al flujo. El siguiente código ordenará al Media Server inicializar un flujo multicast utilizando un archivo en su almacenamiento local:

(remote://IP_address:port/filesimple:///file.ts,rtpsimple://239.192.0.0:5004/)

El protocolo remoto: y los paréntesis que lo abarcan indican al servidor que esta es una canalización completamente autónoma para ejecutar. No se transmite ningún medio al cliente, pero cualquier señal (incluidos mensajes de fin de flujo y error) se reenvía a través del socket al cliente, que puede usar el objeto roMessagePort para recibir dichos mensajes.

Restablecer la instancia roMediaStreamer en el lado del cliente forzará el cierre de la conexión del socket y, por lo tanto, también terminará la canalización en el servidor.