Unter dem Gesichtspunkt der Zuverlässigkeit ist einer der großen Vorteile der VOD-Transkodierung, dass man es einfach noch einmal versuchen kann. Wenn während des Transkodierungsprozesses etwas schief geht, können wir den Prozess einfach von vorne beginnen. Die schlimmste Auswirkung eines Schluckaufs ist, dass ein Auftrag etwas länger dauert, was bedauerlich ist, aber das Endergebnis ist eine transkodierte Datei, die dem Kunden geliefert wird und alles ist gut.
Bei einer Live-Veranstaltung haben wir jedoch nicht den Luxus, es einfach noch einmal zu versuchen. Da diese Ereignisse in Echtzeit transkodiert werden, haben wir nur eine Chance, den Endnutzern eine perfekte Transkodierung zu liefern; eine Panne irgendwo auf dem Weg kann eine Unterbrechung bedeuten. Egal wie zuverlässig das System ist, man weiß nie, wann etwas wie eine Stromversorgung oder eine Netzwerkkarte ausfällt.
Um dem Rechnung zu tragen, haben wir eine redundante Transkodierung für Live-Streams angekündigt. Kurz gesagt, wenn redundant_transcode aktiviert ist, und mindestens ein secondary_url angegeben ist, erstellt Zencoder transparent einen neuen Auftrag unter Verwendung aller sekundären URLs, die in den Ausgaben der ursprünglichen Anforderung angegeben sind. Dieser Auftrag hat dieselben Einstellungen wie der ursprüngliche Auftrag, mit dem wichtigen Unterschied, dass er in der nächstgelegenen Transcodierungsregion eines völlig anderen Cloud-Anbieters ausgeführt wird.
Schauen wir uns ein Beispiel an:
{
"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
}
]
}
Dies ergibt einen Stream-Namen, aber zwei Stream-URLs: eine primäre und eine 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
}
Sie können dann Ihren Encoder so einrichten, dass er an beide gleichzeitig streamt. Im folgenden Beispiel wird Flash Media Live Encoder verwendet, aber die meisten Encoder unterstützen eine primäre und eine Backup-Stream-Url mit wenig zusätzlichen Einstellungen.
Mit dieser Einrichtung würde der Backup-Stream bei einem Ausfall von Amazon East ohne Probleme auf Google Compute Engine weiterlaufen. Vorausgesetzt, Sie verwenden ein CDN mit korrekten Backup-URLs, wie z. B. Akamai, würden die Wiedergabe-URLs weiterhin funktionieren, als wäre nichts passiert.
Der Einfachheit halber haben wir nur das Hinzufügen einer Backup-URL zu einem einzelnen Encoder diskutiert. Dies würde alle Probleme nach dem Encoder entschärfen, aber der Stream ist immer noch gefährdet, wenn der Encoder aus irgendeinem Grund nicht in der Lage ist, zu veröffentlichen. Die Backup-URL könnte jedoch auf einem separaten Encoder eingerichtet werden, der sich in einem völlig anderen Netzwerk befinden könnte, um so sicher wie möglich zu sein.
Anmerkungen
- Da ein Stream sowohl an den primären als auch an den Backup-Endpunkt übertragen werden muss, verdoppelt sich die für die Veröffentlichung eines Streams erforderliche Bandbreite.
- Der Backup-Auftrag wird als separater Auftrag zu den üblichen Live-Tarifen abgerechnet.
- Akamai versucht, den primären und den Backup-Stream vor der Wiedergabe aufeinander abzustimmen, daher kann es beim Übergang zwischen den Streams zu einer kurzen Unterbrechung kommen.
