Desde el punto de vista de la fiabilidad, una de las grandes ventajas de la transcodificación VOD es la posibilidad de volver a intentarlo. Si algo va mal durante el proceso de transcodificación, podemos volver a ejecutarlo desde el principio. El peor efecto de un contratiempo es que el trabajo tarda un poco más, lo cual es lamentable, pero el resultado final es un archivo transcodificado que se entrega al cliente y todo va bien.
Sin embargo, durante un evento en directo no podemos permitirnos el lujo de volver a intentarlo. Dado que estos eventos se transcodifican en tiempo real, sólo tenemos una oportunidad de ofrecer una transcodificación perfecta a los usuarios finales; un fallo en cualquier punto del proceso puede significar una interrupción. Por muy fiable que sea el sistema, nunca se sabe cuándo va a fallar algo como una fuente de alimentación o una tarjeta de red, por lo que la redundancia es crucial para los eventos de alto nivel.
Para tenerlo en cuenta, anunciamos la transcodificación redundante de las transmisiones en directo. En pocas palabras, si redundant_transcode
está activada, y al menos una secondary_url
Zencoder creará de forma transparente un nuevo trabajo utilizando cualquier URL secundaria especificada en los resultados de la solicitud original. Este trabajo tiene la misma configuración que el original, con la importante diferencia de que se ejecuta en la región de transcodificación más cercana de un proveedor en la nube totalmente distinto.
Veamos un ejemplo:
{
"redundant_transcode": true,
"live_stream": true,
"region": "us-virginia",
"output": [
{
"label": "super-important-stream",
"url": "rtmp://primary.example.com/live/stream",
"secondary_url": "rtmp://backup.example.com/live/stream",
"live_stream": true
},
{
"label": "not-as-important-stream",
"url": "rtmp://primary.example.com/live/stream",
"live_stream": true
}
]
}
Esto devolverá un nombre de flujo, pero dos URL de flujo: una primaria y otra redundante.
{
"stream_name": "as230d982389askdfsdkjf2380ejd93d93dj",
"outputs": [
{
"label": "super-important-stream",
"url": "rtmp://primary.example.com/live/stream",
"id": 260281679
},
{
"label": "not-as-important-stream",
"url": "rtmp://primary.example.com/live/stream",
"id": 260281680
}
],
"stream_url": "rtmp://live01.us-va.zencoder.io:1935/live",
"redundant_job_id": 12345678,
"redundant_stream_url": "rtmp://backup-endpoint.zencoder.io:1935/live",
"id": 98091238
}
A continuación, puede configurar su codificador para transmitir a ambos simultáneamente. En el ejemplo siguiente se utiliza Flash Media Live Encoder, pero la mayoría de los codificadores admiten una url de transmisión principal y otra de copia de seguridad con poca configuración adicional.
Con esta configuración, si Amazon Este se cayera, el flujo de copia de seguridad continuaría felizmente en Google Compute Engine sin ningún problema. Suponiendo que estés utilizando una CDN con urls de copia de seguridad adecuadas, como Akamai, las URL de reproducción seguirían funcionando como si no hubiera pasado nada.
Para simplificar, sólo hemos hablado de añadir una URL de copia de seguridad a un único codificador. Esto mitigaría cualquier problema aguas abajo del codificador, pero el flujo sigue estando en riesgo si el codificador no puede publicar por cualquier motivo. La URL de respaldo, sin embargo, podría configurarse en un codificador separado, que podría estar en una red completamente diferente para ser lo más seguro posible.
Notas
- Dado que un flujo debe enviarse tanto al punto final principal como al de reserva, esto duplicará el ancho de banda necesario para publicar un flujo.
- El trabajo de copia de seguridad se factura como un trabajo independiente a las tarifas estándar en directo.
- Akamai intentará alinear los flujos primario y de reserva antes de la reproducción, por lo que puede producirse una breve interrupción durante la transición entre flujos.