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.
# Création de manifestes HLS redondants
Lorsque vous créez un groupe de sortie HLS dans un MediaLive canal standard, vous pouvez activer les manifestes redondants. Les manifestes redondants permettent au système en aval (qui lit les manifestes) de mieux gérer une défaillance de sortie à partir de MediaLive.
Lorsque la fonction manifeste redondante est activée, le manifeste principal pour chaque pipeline fait référence à ses propres manifestes enfants et aux manifestes enfants pour l'autre pipeline. Le système en aval trouve le chemin d'accès aux manifestes enfants pour un pipeline. S'il y a un problème avec ce pipeline, il y aura un problème avec les manifestes enfants pour ce pipeline. Le système en aval peut alors se référer au manifeste principal pour trouver le manifeste enfant pour l'autre pipeline. De cette façon, le système en aval peut toujours poursuivre son traitement du manifeste et du média.
Pour mettre en œuvre avec succès les manifestes redondants, vous devez être sûr que le système en aval peut gérer les manifestes redondants de la manière décrite dans la spécification HLS.
**Note**
Dans cette section sur les manifestes HLS, il est supposé que vous connaissez les étapes générales de la création d'un canal, comme décrit dans [Création d'un canal de bout en bout](creating-channel-scratch.md).
Les champs clés de la console qui se rapportent à cette fonctionnalité se trouvent dans le regroupement **Manifestations et segments** de la section **Groupe de sortie HLS** de la page **Créer un canal** . Pour consulter l'étape à laquelle vous remplissez ces champs, veuillez consulter [Procédure](creating-hls-output-group.md#hls-create-procedure).
**Topics**
+ [Procédure de configuration des manifestes redondants](hls-rm-procedure.md)
+ [Contenu multimédia d'un manifeste HLS](hls-rm-manifests-contents.md)
+ [Règles pour la plupart des systèmes en aval](hls-redundant-manif-most-systems.md)
+ [Règles pour Akamai CDNs](hls-redundant-manif-akamai.md)
+ [Combinaison de manifestes redondants avec d'autres fonctionnalités](hls-redundant-manif-combine.md)
# Procédure de configuration des manifestes redondants
La configuration de manifestes redondants dans les sorties MediaLive HLS 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 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**
1. Parlez à l'opérateur du système en aval pour savoir s'il accepte les manifestes redondants.
1. Veuillez lire les informations disponibles dans [Champs pour la destination de sortie — envoi vers un serveur HTTP](hls-destinations-http.md). 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.
1. Concevez le URLs pour les deux pipelines. Il existe des exigences particulières URLs pour les fichiers HLS. Lisez la section appropriée :
+ [Règles pour la plupart des systèmes en aval](hls-redundant-manif-most-systems.md)
+ [Règles pour Akamai CDNs](hls-redundant-manif-akamai.md)
Ces règles complètent les informations contenues dans [Champs pour la destination de sortie — envoi vers un serveur HTTP](hls-destinations-http.md).
1. 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](hls-manifests-how-work.md#hls-custom-manifest-paths). Vous devez tenir compte des règles relatives aux tracés personnalisés lorsque vous concevez le URLs.
1. 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.
1. 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](hls-rm-manifests-contents.md).
## 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**](hls-other-features.md#hls-resiliency) est défini sur **EMIT\$1OUTPUT**, 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\$1OUTPUT**, 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](https://docs.aws.amazon.com/mediastore/latest/ug/policies-object-lifecycle-components.html). Une fois que le manifeste enfant a été supprimé, MediaStore on recommence à suivre la logique « le manifeste a été supprimé » du scénario B.
# Contenu multimédia d'un manifeste HLS
Lorsque vous configurez des manifestes redondants dans une sortie HLS, le contenu du manifeste est MediaLive modifié. Il modifie les informations du média (les informations vidéo, audio et légendes) à l'intérieur des manifestes. Toutes ces informations apparaissent sous forme de balises `#EXT-X-STREAM-INF`.
Les sections suivantes décrivent le nombre de ces balises et le contenu de ces balises dans un manifeste standard (non redondant) et dans un manifeste redondant.
## À quoi ressemble un manifeste standard
Avec un canal standard, il y a deux pipelines. Chaque pipeline produit son propre ensemble de manifestes. Par conséquent, pour le pipeline 0, il y a un manifeste principal, un jeu de manifestes enfants et un ensemble de fichiers multimédias. De même, le pipeline 1 a le même ensemble de fichiers. Les manifestes référencent uniquement les fichiers de leur propre pipeline.
Les informations vidéo dans le manifeste principal pour chaque pipeline peuvent ressembler à ceci :
```
#EXT-X-STREAM-INF:BANDWIDTH=629107 ...
curling-high.m3u8
```
## À quoi ressemble un manifeste redondant
Lorsque la fonction manifeste redondante est activée, chaque manifeste principal fait référence aux manifestes enfants pour son propre pipeline et pour l'autre pipeline.
Cette fonctionnalité n'affecte pas les manifestes enfants. Les manifestes enfants font uniquement référence à leurs propres fichiers multimédias.
Voici un exemple de la façon dont les informations vidéo dans le manifeste peuvent apparaître. *Supposons que le baseFileName du pipeline 0 soit le *premier curling* et que le pipeline 1 soit un autre curling.*
Le manifeste pour le pipeline 0 peut ressembler à ceci (avec les informations de manifeste enfant pour le pipeline 0 apparaissant en premier) :
```
#EXT-X-STREAM-INF:BANDWIDTH=629107 ...
first-curling-high.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=629107 ...
other-curling-high.m3u8
```
Les informations vidéo dans le manifeste pour le pipeline 1 peuvent ressembler à ceci (avec les informations de manifeste enfant pour le pipeline 1 apparaissant en premier) :
```
#EXT-X-STREAM-INF:BANDWIDTH=629107 ...
other-curling-high.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=629107 ...
first-curling-high.m3u8
```
# Règles pour la plupart des systèmes en aval
Vous pouvez configurer des manifestes redondants dans un groupe de sortie MediaLive HLS à condition que le système en aval puisse fonctionner avec des règles spécifiques. Lisez cette section si vous configurez des manifestes redondants avec n'importe quel système en aval à l'exception d'Akamai. Si votre système en aval est un CDN Akamai, veuillez consulter [Règles pour Akamai CDNs](hls-redundant-manif-akamai.md).
Vous devez vous assurer que le système en aval peut fonctionner avec les règles suivantes.
+ MediaLive envoie les fichiers des deux pipelines vers le même emplacement (protocol/domain/path).
+ Étant donné que l'emplacement est le même, les noms de fichiers de base des pipelines doivent être différents.
+ Si vous implémentez également des [chemins de manifeste personnalisés](hls-manifests-how-work.md#hls-custom-manifest-paths), l'URL à l'intérieur des manifestes doit être identique.
| Champ | Règle |
| --- | --- |
| Protocol/domain/pathpartie des deux destinations URIs (A et B) | Doit être identique dans les deux champs. |
| Portion du nom de fichier de base des deux destinations URIs (A et B) | Doit être différente dans chaque champ. Elle *ne peut pas* utiliser [des identificateurs de variables](variable-data-identifiers.md) qui incluent la date ou l'heure. |
| NameModifier pour chaque sortie | Il n'y a qu'une seule instance de ce champ. Les deux pipelines utilisent la même valeur. Elle *ne peut pas* utiliser [des identificateurs de variables](variable-data-identifiers.md) qui incluent la date ou l'heure. |
| Modificateur de segment | Il n'y a qu'une seule instance de ce champ. Les deux pipelines utilisent la même valeur. Il *peut* utiliser des [identificateurs variables](variable-data-identifiers.md) qui incluent la date ou l'heure. |
| Manifeste d'URL de base A Manifeste d'URL de base B | Ces champs s'appliquent uniquement si vous implémentez également des [chemins de manifeste personnalisés](hls-manifests-how-work.md#hls-custom-manifest-paths). Remplissez les deux champs. |
| Contenu de l'URL de base A et Contenu de l'URL de base B | Ces champs s'appliquent uniquement si vous implémentez également des [chemins de manifeste personnalisés](hls-manifests-how-work.md#hls-custom-manifest-paths). Remplissez les deux champs. |
# Règles pour Akamai CDNs
Vous pouvez configurer des manifestes redondants dans un groupe de sortie MediaLive HLS à condition que le système en aval puisse fonctionner avec des règles spécifiques. Lisez cette section si vous configurez des manifestes redondants avec un CDN Akamai. Si votre système en aval n'est pas un CDN Akamai, veuillez consulter [Règles pour la plupart des systèmes en aval](hls-redundant-manif-most-systems.md).
Vous devez vous assurer que le système en aval peut fonctionner avec les règles suivantes.
| Champ | Règle |
| --- | --- |
| Protocol/domain/pathpartie des deux destinations URIs (A et B) | Peut être différent les uns des autres, ou peut être le même. |
| BaseFilename partie des deux destinations URIs (A et B) | Peut être différent les uns des autres, ou peut être le même. Elle *ne peut pas* utiliser [des identificateurs de variables](variable-data-identifiers.md) qui incluent la date ou l'heure. La combinaison de protocol/domain/path et de BaseFileName doit être unique dans A et B. Cette règle garantit que les fichiers de sortie des deux pipelines ne se remplacent pas. |
| Modificateur de nom | Il n'y a qu'une seule instance de ce champ. Les deux pipelines utilisent la même valeur. Elle *ne peut pas* utiliser [des identificateurs de variables](variable-data-identifiers.md) qui incluent la date ou l'heure. |
| Modificateur de segment | Il n'y a qu'une seule instance de ce champ. Les deux pipelines utilisent la même valeur. Il *peut* utiliser des [identificateurs variables](variable-data-identifiers.md) qui incluent la date ou l'heure. |
| Manifeste d'URL de base A Manifeste d'URL de base B | Ces champs s'appliquent uniquement si vous implémentez également des [chemins de manifeste personnalisés](hls-manifests-how-work.md#hls-custom-manifest-paths). En général, avec Akamai CDNs, vous implémentez des chemins de manifeste personnalisés. Remplissez les deux champs. |
| Contenu de l'URL de base A et Contenu de l'URL de base B | Ces champs s'appliquent uniquement si vous implémentez également des [chemins de manifeste personnalisés](hls-manifests-how-work.md#hls-custom-manifest-paths). Remplissez les deux champs. |
# Combinaison de manifestes redondants avec d'autres fonctionnalités
## Combinaison de manifestes redondants et d'une fonction de chemin d'accès personnalisé
Lorsque vous configurez des manifestes redondants dans un groupe de sortie MediaLive HLS, vous pouvez également définir des chemins personnalisés. [Assurez-vous de suivre les règles relatives aux [chemins personnalisés](hls-custom-paths-rules.md) et aux manifestes redondants pour votre système en aval, qu'il s'agisse d'un [CDN d'Akamai](hls-redundant-manif-akamai.md) ou d'un autre système en aval.](hls-redundant-manif-most-systems.md)
## Combinaison de manifestes redondants avec des groupes de rendus audio
**Note**
Les informations de cette section supposent que vous connaissez déjà les manifestes pour les groupes de rendus audio. Pour de plus amples informations, veuillez consulter [Exemple de manifeste](sample-manifest.md).
Vous trouverez ci-dessous des informations sur le traitement effectué MediaLive lorsque vous configurez des manifestes redondants dans un groupe de sortie HLS incluant un groupe de rendu audio.
MediaLive ajuste automatiquement les références aux groupes de rendu audio dans les manifestes parents.
Dans chaque paire de lignes (par exemple, `#EXT-X-STREAM-INF` pour la vidéo haute résolution), MediaLive ajuste le nom des groupes de rendu. Ainsi, les références aux groupes de rendu sont différentes pour chaque pipeline, ce qui garantit que lorsque le lecteur client lit le manifeste, il choisit la vidéo et l'audio dans le même pipeline.
`#EXT-X-STREAM` pour la vidéo pour le pipeline 0. Notez la valeur pour *AUDIO* :
```
#EXT-X-STREAM-INF:BANDWIDTH=541107,...AUDIO="aac-audio-0", ...
```
`#EXT-X-STREAM` pour la vidéo pour le pipeline 1. Notez la valeur pour *AUDIO* :
```
#EXT-X-STREAM-INF:BANDWIDTH =541107, ...AUDIO="aac-audio-1",...
```