Servidor multimedia

el objeto romediastreamer le permite configurar una canalización de elementos de procesamiento multimedia para su ejecución esto puede implicar transmitir los resultados a través de rtp o udp, pero no es capaz de comportarse como un servidor verdadero, que escucha conexiones y luego actúa sobre ellas este es el trabajo del media server, representado por el objeto romediaserver el media server espera solicitudes, gestiona cualquier negociación y, en última instancia, crea una canalización de media streamer que ejecuta para satisfacer la solicitud actualmente, el media server admite el protocolo rtsp (como el utilizado, por ejemplo, por vlc) y solicitudes http estas solicitudes del cliente deben tener la siguiente forma protocol //ip address\ port/media streamer pipeline protocolo rtsp o http ip address\ port la dirección ip del reproductor brightsign y el número de puerto en el que se ejecuta el media server para obtener más información, consulte el ejemplo siguiente media streamer pipeline una canalización de media streamer como las mostradas en ejemplos anteriores, pero sin el componente de destino final (ya que el destino está implícito en la solicitud del cliente) no utilice los puertos 8888 o 9999, ya que estos puertos pueden ser utilizados por brightsignos las funciones de media server actualmente no están disponibles en brightauthor classic, pero puede configurar un streamer/servidor usando el complemento media server https //github com/brightsign/brightauthor plugins/tree/master/media server inicializar el media server un rtsp media server puede iniciarse de la siguiente manera s = createobject("romediaserver") s start("rtsp\ port=554") esto iniciará un servidor rtsp que escucha en el puerto 554 el número de puerto y el protocolo de transmisión se pueden personalizar por ejemplo, se puede iniciar un servidor http en el puerto 8080 de la siguiente manera s = createobject("romediaserver") s start("http port=8080") 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) puerto especifica un número de puerto para el servidor si este parámetro no se especifica, el servidor usa de forma predeterminada 554 para rtsp y 8080 para http rastro muestra un rastreo de mensajes en la negociación con el cliente este parámetro es útil principalmente para depurar sesiones rtsp por ejemplo rtsp\ port=554\&trace maxbitrate establece la tasa de bits instantánea máxima (en kbps) de la transferencia rtp iniciada por rtsp este parámetro no tiene efecto para http un valor de 80000 (es decir, 80mbps) funciona bien el comportamiento predeterminado (también logrado pasando 0) es no limitar la tasa de bits en absoluto por ejemplo rtsp\ port=554\&trace\&maxbitrate=80000 hilos establece el número máximo de hilos que el servidor está preparado para ejecutar cada hilo gestiona una única solicitud de cliente el valor predeterminado es 5 por ejemplo http port=8080\&threads=10 para detener el media server, use el método stop() esto realmente indica a todos los hilos que se detengan, pero no espera a que esto ocurra 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 ejemplos de media server 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 solicitar un archivo para transmitir 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 reproducir el archivo indefinidamente rtsp\ //ip address\ port/file ///file ts?loop use lo siguiente para transmitir file ts usando http en su lugar http //ip address\ port/file ///file ts solicitar un flujo de entrada hdmi codificado use la siguiente url para solicitar que el servidor transmita su entrada hdmi® rtsp\ //ip address\ port/hdmi ,encoder solicitar un flujo de memoria flujos de memoria docid\ ob0v0vpr y qim6acte0i que se hayan configurado previamente pueden solicitarse mediante rtsp o http el siguiente ejemplo transmitirá el flujo de memoria llamado name, que se ha puesto previamente en ejecución http //ip address\ port/mem /name/stream ts tenga en cuenta que /stream ts se agrega para indicar el flujo completo, en lugar de solo partes de este (como en el caso de hls) solicitar un flujo 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 agregarse para indicar el archivo de índice , en lugar del flujo en sí como alternativa, 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 este flujo de prueba se puede usar en reproductores brightsign http //qthttp apple com edgesuite net/1010qwoeiuryfg/sl m3u8 http //qthttp apple com edgesuite net/1010qwoeiuryfg/sl m3u8 sintaxis de url para un cliente rtsp 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; del mismo modo, las etapas en el media server que satisfacen 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 en el lado del cliente o al transmisor de medios en el 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, agregue un "?" final adicional a la url rtsp\ //ip address\ port/file ///file ts?loop? etapas de pipeline de múltiples dispositivos 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 pipeline en el media server por ejemplo, el cliente puede requerir que el media server codifique su hdmi input antes de transmitirlo por http (porque un servidor no puede transmitir cuadros de video hdmi sin procesar por la red) en estos casos, puede usar paréntesis en la solicitud del cliente para delimitar las etapas de pipeline 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 pipelines remotos es posible que un reproductor cliente especifique etapas de pipeline solo 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 circundantes indican al servidor que este es un pipeline completamente autónomo para ejecutar no se transmite ningún medio al cliente, pero cualquier señal (incluidos los mensajes de fin de flujo y de error) se reenvía a través del socket al cliente, que puede usar el objeto romessageport para recibir dichos mensajes restablecer la instancia de romediastreamer en el lado del cliente forzará el cierre de la conexión del socket y, por lo tanto, también terminará el pipeline en el servidor