Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Procédure de configuration des manifestes redondants
La configuration de manifestes redondants dans les MediaLive HLS sorties comporte deux étapes. Vous devez activer la fonctionnalité dans le groupe de sortie. Vous devez également apporter des modifications à la conception des noms de sortie et des chemins de destination (par rapport aux HLS sorties qui n'implémentent pas de manifestes redondants).
Le champ suivant concerne spécifiquement les manifestes redondants :
-
HLSgroupe de sortie — Manifestes et segments — Champ de manifestes redondants
Pour configurer des manifestes redondants
-
Parlez à l'opérateur du système en aval pour savoir s'il accepte les manifestes redondants.
-
Veuillez lire les informations disponibles dans Champs pour la destination de sortie — envoi à un HTTP serveur. Les manifestes sont considérés comme issus de MediaLive. Par conséquent, les règles générales relatives aux destinations de sortie s'appliquent aux manifestes redondants.
-
Concevez le URLs pour les deux pipelines. Il existe des exigences particulières URLs pour les HLS fichiers. Lisez la section appropriée :
Ces règles complètent les informations contenues dans Champs pour la destination de sortie — envoi à un HTTP serveur.
-
Si vous avez également besoin de chemins personnalisés pour les manifestes, assurez-vous de lire les informations de la section Fonctionnement des chemins personnalisés. Vous devez tenir compte des règles relatives aux tracés personnalisés lorsque vous concevez leURLs.
-
Dans la section Groupe HLS de sortie, pour Manifeste et segments, pour Manifeste redondant, sélectionnez ENABLED. Ce champ s'applique à toutes les sorties du groupe de sortie.
-
Remplissez ces champs, en suivant votre conception :
-
Groupe de sortie — section HLS de destination du groupe
-
Groupe de sortie — HLS paramètres — CDN section
-
Groupe de sortie — Emplacement — Structure du répertoire
-
Groupe de sortie — Emplacement — Segments par sous-répertoire
-
HLSsorties — Paramètres de sortie — Modificateur de nom
-
HLSsorties — Réglages de sortie — Modificateur de segment
-
HLSgroupe de sortie — Emplacement — URL Manifeste de base (si vous configurez également des chemins personnalisés)
-
HLSgroupe de sortie — Emplacement — URL Contenu de base (si vous configurez également des chemins personnalisés)
-
Pour plus d'informations sur la façon dont cette fonctionnalité modifie le contenu des HLS manifestes, consultezLe contenu médiatique d'un HLS manifeste.
Les résultats de cette configuration
Vous trouverez ci-dessous des informations sur le fonctionnement des manifestes redondants dans trois scénarios de défaillance.
Scénario A — L'action de perte d'entrée consiste à émettre une sortie
Si l'entrée est perdue sur l'un des pipelines et que le champ d'action Perte d'entrée est défini sur EMIT_ OUTPUT, la mise à jour des manifestes parent et enfant se MediaLive poursuit.
Du point de vue du système en aval, aucune modification n'est apportée aux manifestes parent ou enfant pour l'un ou l'autre des pipelines. Le contenu des fichiers multimédias est un contenu de remplissage, mais cela n'affecte pas la façon dont le système en aval lit les manifestes.
Scénario B — L'action de perte d'entrée consiste à suspendre la sortie
Si l'entrée est perdue sur l'un des pipelines (par exemple, sur le pipeline 0) et que le champ d'action Perte d'entrée est défini sur PAUSE_ OUTPUT, MediaLive effectue ce qui suit :
-
Il supprime la liste des manifestes enfants pour le pipeline 0.
-
Il envoie une demande à l'emplacement du manifeste enfant pour le pipeline 0 pour supprimer les manifestes enfants.
Résultat pour le système en aval qui lit le manifeste principal sur le pipeline 0 : le système ne trouvera plus de liste pour les manifestes enfants pour le pipeline 0. Le système cherchera dans le manifeste principal 0 du pipeline pour un manifeste enfant alternatif. S'il trouve le manifeste enfant pour le pipeline 1, il passera à la lecture de ce manifeste enfant.
Les systèmes en aval qui lisent le manifeste principal pour le pipeline 1 ne sont pas affectés car ces systèmes lisent probablement les manifestes enfants pour le pipeline 1 (car ceux-ci apparaissent en premier dans le manifeste).
Scénario C — Défaillance du pipeline
Il est également possible qu'un pipeline échoue. Cet échec n'est pas le même qu'un échec d'entrée. Lorsqu'un pipeline échoue (par exemple, pipeline 0), ce qui suit se produit :
-
Arrêts de sortie.
-
Le manifeste principal pour le pipeline 0 n'est pas supprimé. Il contient toujours une liste pour les manifestes enfants pour le pipeline 0.
-
Les manifestes enfants ne sont pas mis à jour car aucun nouveau fichier multimédia n'est produit. Les manifestes de l'enfant sont obsolètes.
-
Le manifeste principal pour le pipeline 1 ne change pas. Il contient toujours une liste pour les manifestes enfants pour le pipeline 0 (et pour le pipeline 1).
Résultat pour le système en aval qui lit le manifeste principal pour le pipeline 0 : Le système trouvera une liste pour les manifestes enfants pour le pipeline 0, mais ce manifeste sera obsolète. Si le système peut détecter que le manifeste est obsolète, il peut retourner au manifeste principal du pipeline 0 et rechercher un manifeste enfant alternatif. S'il trouve le manifeste enfant pour le pipeline 1, il passera à la lecture de ce manifeste enfant.
Les systèmes en aval qui lisent le manifeste principal du pipeline 1 ne sont pas affectés. Ces systèmes lisent probablement les manifestes enfants pour le pipeline 1 (car ceux-ci apparaissent en premier dans le manifeste).
Note
Si le système de HLS sortie est situé en aval AWS Elemental MediaStore, vous pouvez le configurer MediaStore pour supprimer les entrées périmées. Voir Composants d'une politique de cycle de vie des objets. Une fois le manifeste enfant supprimé, on MediaStore recommence à suivre la logique « le manifeste a été supprimé » du scénario B.
