Du point de vue de la fiabilité, l'un des grands avantages du transcodage VOD est la possibilité de recommencer. Si un problème survient au cours du processus de transcodage, nous pouvons simplement reprendre le processus depuis le début. Le pire effet d'un contretemps est que le travail prend un peu plus de temps, ce qui est regrettable, mais le résultat final est qu'un fichier transcodé est livré au client et que tout va bien.
Lors d'un événement en direct, cependant, nous n'avons pas le luxe de pouvoir simplement réessayer. Comme ces événements sont transcodés en temps réel, nous n'avons qu'une seule chance de fournir un transcodage parfait aux utilisateurs finaux. Quelle que soit la fiabilité du système, on ne sait jamais quand un élément tel qu'une alimentation électrique ou une carte réseau va tomber en panne, c'est pourquoi la redondance est cruciale pour les événements de grande envergure.
Pour en tenir compte, nous avons annoncé un transcodage redondant pour les flux en direct. En bref, si redundant_transcode
est activée, et au moins un secondary_url
est spécifié, Zencoder créera de manière transparente un nouveau travail en utilisant toutes les URL secondaires spécifiées dans les résultats de la requête originale. Ce travail a tous les mêmes paramètres que l'original, avec la distinction importante d'être exécuté dans la région de transcodage la plus proche d'un fournisseur de cloud entièrement différent.
Prenons un exemple :
{
"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
}
]
}
Cela renverra un nom de flux, mais deux URL de flux : l'une primaire et l'autre redondante.
{
"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
}
Vous pouvez ensuite configurer votre encodeur pour qu'il diffuse simultanément les deux flux. L'exemple ci-dessous utilise Flash Media Live Encoder, mais la plupart des encodeurs prennent en charge un flux principal et un flux de secours avec peu de configuration supplémentaire.
Avec cette configuration, si Amazon East devait tomber en panne, le flux de sauvegarde se poursuivrait sans problème sur Google Compute Engine. En supposant que vous utilisiez un CDN avec des URL de sauvegarde appropriées, comme Akamai, les URL de lecture continueraient à fonctionner comme si rien ne s'était passé.
Par souci de simplicité, nous n'avons parlé que de l'ajout d'une URL de sauvegarde à un seul encodeur. Cela permettrait d'atténuer tout problème en aval de l'encodeur, mais le flux est toujours menacé si l'encodeur n'est pas en mesure de publier pour une raison ou une autre. L'URL de secours pourrait toutefois être configurée sur un autre encodeur, qui pourrait se trouver sur un réseau entièrement différent pour être aussi sûr que possible.
Notes
- Étant donné qu'un flux doit être envoyé à la fois au point d'extrémité principal et au point d'extrémité de secours, la bande passante nécessaire à la publication d'un flux sera doublée.
- La tâche de sauvegarde est facturée comme une tâche distincte aux tarifs standard en vigueur.
- Akamai tentera d'aligner les flux principal et de secours avant la lecture, ce qui peut entraîner une brève interruption pendant la transition entre les flux.