El backend de autorización ahora puede actualizar la configuración de la transmisión para cada sesión Hemos implementado 2 nuevos mecanismos en el contexto de la autorización. On_publish es un mecanismo para autorizar sesiones de publicación y on_play es para sesiones de reproducción. Ambas opciones son útiles para usar con plantillas. On_publish. Al interactuar con una plataforma UGC, los streamers (quienes publican) usan diferentes cámaras y diferentes equipos para publicar. Además, las plataformas UGC pueden monetizar el servicio ofreciendo a los streamers varios planes de tarifas y funciones: DVR, reenvío a YouTube, etc. Si el streamer, por ejemplo, cambia a un plan de tarifas diferente o simplemente cambia su dispositivo para su publicación, el backend de autorización lo hará y transmitirá esta información. Devolverá la configuración actualizada antes de que comience la transmisión (antes de que comience la publicación del video). Al mismo tiempo, el archivo de configuración de los servidores de ingesta de Flussonic permanece estático y no se modificará con el cambio en el número de usuarios. Esto permitirá agregar recursos rápidamente, sin configuraciones adicionales, cuando la carga en el servicio aumente (por ejemplo, durante los fines de semana). Además, on_publish permite un equilibrio preciso y rápido del grupo de transcodificadores a cargo de los servidores de ingesta. On_play. En una de nuestras versiones anteriores, se implementó el mecanismo wildcard (conocido como "rewrite") para crear transmisiones de reproducción con un nombre dinámico (previamente desconocido). Sin embargo, rewrite era una opción separada dentro de la configuración de Flussonic: era necesario especificar explícitamente "rewrites" para cada transmisión/ubicación de publicación, etc. El uso de On_play., a diferencia de wildcards, permitirá tener una configuración estática en todos los servidores de restreamer. Los parámetros de configuración son cambiado solo una vez en la capa de backend de autorización. El backend de autorización proporcionará rápidamente información relevante como dónde está el transcodificador con la transmisión requerida para una sesión de reproducción específica. Esto es especialmente importante en el contexto de grandes plataformas de transmisión con decenas de miles de sesiones abiertas. En este caso, el uso de mecanismos de fuentes de origen (source) y pares (peer) se traduciría en una búsqueda larga del flujo correcto a través de la lista de servidores. Descubre cómo utilizar estas opciones. Se ha introducido un nuevo mecanismo para insertar anuncios mediante la sustitución de segmentos de transmisión dentro de la sesión de reproducción. El segmento de la transmisión cambia en tiempo real a un segmento del comercial en cada sesión de reproducción. La URL del segmento con el anuncio sigue siendo la misma para todos los espectadores de la transmisión. Al mismo tiempo, se pueden mostrar diferentes anuncios a diferentes espectadores desde la misma URL. Es imposible distinguir la URL del segmento de flujo principal de la URL del segmento publicitario. Esto además protege el anuncio para que no se interrumpa. Disponible para HLS y DASH (tanto para manifiestos de período múltiple como de período único). Permite crear anuncios únicos orientados a cada usuario o sesión sin transcodificación. La equitativa duración de los segmentos de la transmisión original y el comercial garantiza un cambio sutíl entre los segmentos (la transmisión no se bloqueará durante las pausas comerciales). Es necessario tener en cuenta que se requiere preprocesar los clips de los anuncios publicitarios antes de usarlos en la inserción de anuncios. Esta nueva forma de insertar anuncios es el primer paso para mejorar todo el módulo de monetización a través de la publicidad. En un futuro cercano, vamos a implementar los marcadores de inserción de anuncios SCTE y también construiremos un sistema conveniente para preparar comerciales para la inserción. El nuevo mecanismo para insertar anuncios reemplazando segmentos de transmisión está habilitado por la opción v2 en la configuración del backend de autorización. Descubre cómo hacerlo. Se implementó un nuevo diseño de API con la especificación OpenAPI 3.0 Hay algunos principios que hemos seguido: Garantizar métodos de acceso estandarizados a diferentes sistemas. Formalizar una lista de métodos de servicio y los formatos de datos de entrada y salida. Rechazo de reglas de análisis de strings de consulta supercomplejas a favor del lenguaje de consulta JSON. Proporcionar datos que cambian dinámicamente en cualquier momento (Ej, Velocidad de transmisión de bits). Obtén más información sobre la API HTTP de Flussonic.