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
Pour configurer des manifestes redondants, vous activez l'entité dans le groupe en sortie. Vous effectuez également des ajustements dans la conception des noms de sortie et des chemins de destination (par rapport aux sorties HLS qui n'implémentent pas de manifestes redondants).
Le champ suivant concerne spécifiquement les manifestes redondants :
-
Champs Groupe de sortie HLS — Manifestations et segments — Manifestes redondants
Pour configurer des manifestes redondants
-
Parlez au système en aval pour savoir s'ils prennent en charge 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 les URL des deux pipelines. Il existe des exigences particulières pour les URL des fichiers HLS. 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 pour les chemins d'accès personnalisés lorsque vous concevez les URL.
-
Dans la section Groupe de sortie HLS pour Manifeste et segments, pour Manifeste redondant, choisissez ACTIVÉ. Ce champ s'applique à toutes les sorties du groupe de sortie.
-
Remplissez ces champs, en suivant votre conception :
-
Section Groupe de sortie — Destination du groupe HLS
-
Section Groupe de sortie — Paramètres HLS — CDN
-
Groupe de sortie — Emplacement — Structure du répertoire
-
Groupe de sortie — Emplacement — Segments par sous-répertoire
-
Sorties HLS — Paramètres de sortie — Modificateur de nom
-
Sorties HLS — Paramètres de sortie — Modificateur de segment
-
Groupe de sortie HLS — Emplacement — Manifeste d'URL de base (si vous configurez également des chemins personnalisés)
-
Groupe de sortie HLS — Emplacement — Contenu de l'URL de base (si vous configurez également des chemins personnalisés)
-
Pour de plus amples informations sur la manière dont cette fonctionnalité modifie le contenu des manifestes HLS, veuillez consulter Contenu multimédia d'un manifeste HLS.
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, MediaLive continue de mettre à jour les manifestes parent et enfant.
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 en aval pour la sortie HLS l'est 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 que le manifeste enfant a été supprimé, MediaStore on recommence à suivre la logique « le manifeste a été supprimé » du scénario B.
