Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Creazione di manifesti HLS ridondanti
Quando si crea un gruppo di output HLS in un MediaLive canale standard, è possibile abilitare i manifesti ridondanti. I manifest ridondanti consentono al sistema a valle (che legge i manifest) di gestire meglio un errore di output da MediaLive.
Quando la funzione dei manifest ridondanti è abilitata, il manifest principale per ogni pipeline fa riferimento sia ai propri manifest figlio che ai manifest figlio per l'altra pipeline. Il sistema a valle trova il percorso dei manifest figlio per una pipeline. Se c'è un problema con quella pipeline, allora ci sarà un problema con i manifest figlio per quella pipeline. Il sistema a valle può quindi fare riferimento al manifest principale per trovare il manifest figlio per l'altra pipeline. In questo modo, il sistema a valle può sempre continuare con la sua elaborazione del manifest e dei file multimediali.
Per implementare correttamente i manifest ridondanti, devi assicurarti che il sistema a valle sia in grado di gestire i manifest ridondanti nei modi descritti nella specifica HLS.
**Nota**
Le informazioni in questa sezione sui manifest HLS presuppongono che tu conosca la procedura generale per la creazione di un canale, come descritto in [Creare un canale da zero](creating-channel-scratch.md).
I campi chiave della console correlati a questa funzionalità si trovano nel raggruppamento **Manifests and segments (Manifest e segmenti)** della sezione **HLS output group (Gruppo di output HLS)** nella pagina **Create channel (Crea canale)** . Per rivedere la fase in cui si completano questi campi, consulta [La procedura](creating-hls-output-group.md#hls-create-procedure).
**Topics**
+ [Procedura per impostare i manifest ridondanti](hls-rm-procedure.md)
+ [Il contenuto multimediale di un manifest HLS](hls-rm-manifests-contents.md)
+ [Regole per la maggior parte dei sistemi a valle](hls-redundant-manif-most-systems.md)
+ [Regole per Akamai CDNs](hls-redundant-manif-akamai.md)
+ [Combinazione di manifest ridondanti con altre funzionalità](hls-redundant-manif-combine.md)
# Procedura per impostare i manifest ridondanti
La configurazione dei manifesti ridondanti nelle uscite HLS è suddivisa in due parti. MediaLive È necessario attivare la funzione nel gruppo di output. È inoltre necessario apportare modifiche alla progettazione dei nomi di output e dei percorsi di destinazione (rispetto agli output HLS che non implementano manifesti ridondanti).
Il seguente campo si riferisce specificamente ai manifest ridondanti:
+ Campo **HLS output group – Manifests and Segments – Redundant manifests (Gruppo di output HLS – Manifest e segmenti – Manifest ridondanti)**
**Per impostare i manifest ridondanti**
1. Parla con l'operatore del sistema a valle per scoprire se supporta manifesti ridondanti.
1. Consulta le informazioni in [Campi per la destinazione di output: invio a un server HTTP](hls-destinations-http.md). I manifesti sono considerati emessi da. MediaLive Pertanto, le regole generali sulle destinazioni di output si applicano ai manifest ridondanti.
1. Progetta il URLs per le due condotte. Esistono requisiti speciali URLs per i file HLS. Consulta la sezione appropriata:
+ [Regole per la maggior parte dei sistemi a valle](hls-redundant-manif-most-systems.md)
+ [Regole per Akamai CDNs](hls-redundant-manif-akamai.md)
Queste regole integrano le informazioni contenute in [Campi per la destinazione di output: invio a un server HTTP](hls-destinations-http.md).
1. Se hai anche bisogno di percorsi personalizzati per i manifest, assicurati di leggere le informazioni in [Come funzionano i percorsi personalizzati](hls-manifests-how-work.md#hls-custom-manifest-paths). È necessario considerare le regole per i percorsi personalizzati quando si progetta il URLs.
1. Nella sezione **HLS output group (Gruppo di output HLS)** per **Manifest and segments (Manifest e segmenti)**, per **Manifest ridondanti**, scegli **ENABLED (ABILITATO)**. Questo campo si applica a tutti gli output del gruppo di output.
1. Completa questi campi in base alla tua progettazione:
+ Sezione **Output group – HLS group destination (Gruppo di output — Destinazione gruppo HLS)**
+ Sezione **Output group – HLS settings – CDN (Gruppo di output — Impostazioni HLS — CDN)**
+ **Output group – Location – Directory structure (Gruppo di output — Posizione — Struttura delle directory)**
+ **Output group – Location – Segments per subdirectory (Gruppo di output — Posizione — Segmenti per sottodirectory)**
+ **Uscite HLS - Impostazioni di output - Modificatore di nome**
+ **Uscite HLS — Impostazioni di uscita — Modificatore di segmento**
+ **Gruppo di output HLS — Location —Base URL Manifest** (se state impostando anche percorsi personalizzati)
+ **Gruppo di output HLS — Location — Base URL Content** (se state impostando anche percorsi personalizzati)
Per informazioni su come questa funzionalità modifica il contenuto dei manifest HLS, consulta [Il contenuto multimediale di un manifest HLS](hls-rm-manifests-contents.md).
## I risultati di questa configurazione
Di seguito sono riportate informazioni sul funzionamento dei manifest ridondanti in tre scenari di errore.
### Scenario A — L'azione di perdita di input consiste nell'emettere un output
Se l'input viene perso su una delle pipeline e il [campo di **azione Input loss**](hls-other-features.md#hls-resiliency) è impostato su **EMIT\$1OUTPUT**, MediaLive continua ad aggiornare i manifesti padre e figlio.
Dal punto di vista del sistema a valle, non vi è alcuna modifica ai manifesti principale o secondario per nessuna delle due pipeline. Il contenuto all'interno dei file multimediali è contenuto di riempimento, ma ciò non influisce sul modo in cui il sistema a valle legge i manifesti.
### Scenario B — L'azione di perdita dell'input consiste nel mettere in pausa l'output
Se l'input viene perso su una delle tubazioni (ad esempio, sulla pipeline 0) e il campo di **azione Input loss** è impostato su **PAUSE\$1OUTPUT**, esegue le seguenti operazioni: MediaLive
+ Rimuove l'elenco per i manifest figlio per la pipeline 0.
+ Invia una richiesta alla posizione del manifest figlio per la pipeline 0 per eliminare i manifest figlio.
Il risultato per il sistema a valle che sta leggendo il manifest principale sulla pipeline 0: il sistema non troverà più un elenco per i manifest figlio per la pipeline 0. Il sistema cercherà nel manifest principale della pipeline 0 per un manifest secondario alternativo. Se trova il manifest figlio per la pipeline 1, passerà alla lettura di quel manifest figlio.
I sistemi a valle che stanno leggendo il manifest principale per la pipeline 1 non sono interessati perché questi sistemi stanno probabilmente leggendo i manifest figlio per la pipeline 1 (perché questi appaiono per primi nel manifest).
### Scenario C — Guasto della tubazione
È anche possibile che una pipeline fallisca. Questo errore non è lo stesso di un errore di input. Quando si verifica un errore della pipeline (ad esempio, la pipeline 0), accade quanto segue:
+ L'output si arresta.
+ Il manifest principale per la pipeline 0 non viene eliminato. Contiene ancora un elenco per i manifest figlio per la pipeline 0.
+ I manifest figlio non vengono aggiornati perché non vengono prodotti nuovi file multimediali. I manifest figlio sono *statici*.
+ Il manifest principale per la pipeline 1 non cambia. Contiene ancora un elenco per i manifest figlio per la pipeline 0 (e per la pipeline 1).
Il risultato per il sistema a valle che sta leggendo il manifest principale per la pipeline 0: il sistema troverà un elenco per i manifest figlio per la pipeline 0, ma il manifest sarà obsoleto. Se il sistema è in grado di rilevare che il manifest è obsoleto, può tornare al manifest principale della pipeline 0 e cercare un manifest figlio alternativo. Se trova il manifest figlio per la pipeline 1, passerà alla lettura di quel manifest figlio.
I sistemi a valle che stanno leggendo il manifest principale per la pipeline 1 non sono interessati. Questi sistemi stanno presumibilmente leggendo i manifest figlio per la pipeline 1 (dato che questi appaiono per primi nel manifest).
**Nota**
Se il sistema a valle per l'uscita HLS è AWS Elemental MediaStore, è possibile impostare l'eliminazione degli input MediaStore obsoleti. Vedi [Componenti di una politica del ciclo di vita degli oggetti](https://docs.aws.amazon.com/mediastore/latest/ug/policies-object-lifecycle-components.html). Dopo l'eliminazione del manifesto secondario, MediaStore torna a seguire la logica «il manifesto è stato eliminato» dello scenario B.
# Il contenuto multimediale di un manifest HLS
Quando si impostano manifesti ridondanti in un output HLS, MediaLive modifica il contenuto del manifesto. Cambia le informazioni multimediali (informazioni video, audio e didascalie) all'interno dei manifest. Tutte queste informazioni vengono visualizzate come tag `#EXT-X-STREAM-INF`.
Nelle sezioni seguenti viene descritto il numero di questi tag e il loro contenuto in un manifest standard (non ridondante) e in un manifest ridondante.
## Come appare un manifest standard
Con un canale standard, ci sono due pipeline. Ogni pipeline produce il proprio insieme di manifest. Pertanto, per la pipeline 0, è presente un manifest principale, un set di manifest figlio e un set di file multimediali. Allo stesso modo, la pipeline 1 presenta il medesimo set di file. I manifest fanno riferimento solo ai file per la propria pipeline.
Le informazioni video nel manifest principale per ogni pipeline potrebbero avere il seguente aspetto:
```
#EXT-X-STREAM-INF:BANDWIDTH=629107 ...
curling-high.m3u8
```
## Come appare un manifest ridondante
Quando la funzione dei manifest ridondanti è abilitata, ogni manifest principale fa riferimento al manifest figlio per la propria pipeline e per l'altra pipeline.
Questa funzione non influisce sui manifest figlio. I manifest figlio fanno riferimento solo ai propri file multimediali.
Di seguito è riportato un esempio di come potrebbero apparire le informazioni video nel manifest. **Supponiamo che BaseFileName per la pipeline 0 sia il primo arricciamento e per la pipeline 1 l'arricciatura per altri.**
Il manifest per la pipeline 0 potrebbe essere simile a questo (con le informazioni del manifest figlio per la pipeline 0 che appaiono per prime):
```
#EXT-X-STREAM-INF:BANDWIDTH=629107 ...
first-curling-high.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=629107 ...
other-curling-high.m3u8
```
Le informazioni video nel manifest per la pipeline 1 potrebbero essere simili a quanto segue (con le informazioni del manifest figlio per la pipeline 1 che appaiono per prime):
```
#EXT-X-STREAM-INF:BANDWIDTH=629107 ...
other-curling-high.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=629107 ...
first-curling-high.m3u8
```
# Regole per la maggior parte dei sistemi a valle
È possibile impostare manifesti ridondanti in un gruppo di output MediaLive HLS purché il sistema a valle possa funzionare con regole specifiche. Consulta questa sezione se stai configurando manifest ridondanti con qualsiasi sistema a valle ad eccezione di Akamai. Se il sistema a valle è una CDN Akamai, consulta [Regole per Akamai CDNs](hls-redundant-manif-akamai.md).
È necessario assicurarsi che il sistema a valle possa funzionare con le seguenti regole.
+ MediaLive invia i file da entrambe le pipeline nella stessa posizione (). protocol/domain/path
+ Dato che la posizione è la stessa, i nomi dei file di base per le pipeline devono essere diversi.
+ Se stai inoltre implementando anche [percorsi dei manifest personalizzati](hls-manifests-how-work.md#hls-custom-manifest-paths), l'URL all'interno dei manifest deve essere identico.
| Campo | Regola |
| --- | --- |
| Protocol/domain/pathparte delle due destinazioni URIs (A e B) | Deve essere identico in entrambi i campi. |
| parte relativa al nome del file di base delle due destinazioni URIs (A e B) | Deve essere diverso in ogni campo. *Non è possibile* utilizzare [identificatori di variabili](variable-data-identifiers.md) che includono la data o l'ora. |
| NameModifier per ogni uscita | C'è solo un'istanza di questo campo. Entrambe le pipeline utilizzano lo stesso valore. *Non è possibile* utilizzare [identificatori di variabili](variable-data-identifiers.md) che includono la data o l'ora. |
| Modificatore segmento | C'è solo un'istanza di questo campo. Entrambe le pipeline utilizzano lo stesso valore. *É possibile* utilizzare [identificatori di variabili](variable-data-identifiers.md) che includono la data o l'ora. |
| Manifesto URL di base A e Manifesto URL di base B | Questi campi si applicano solo se stai anche implementando [percorsi dei manifest personalizzati](hls-manifests-how-work.md#hls-custom-manifest-paths). Completa entrambi i campi. |
| Contenuto URL di base A e Contenuto URL di base B | Questi campi si applicano solo se stai anche implementando [percorsi dei manifest personalizzati](hls-manifests-how-work.md#hls-custom-manifest-paths). Completa entrambi i campi. |
# Regole per Akamai CDNs
È possibile configurare manifesti ridondanti in un gruppo di output MediaLive HLS purché il sistema a valle possa funzionare con regole specifiche. Leggete questa sezione se state configurando manifesti ridondanti con una CDN Akamai. Se il sistema a valle non è una CDN Akamai, consulta [Regole per la maggior parte dei sistemi a valle](hls-redundant-manif-most-systems.md).
È necessario assicurarsi che il sistema a valle possa funzionare con le seguenti regole.
| Campo | Regola |
| --- | --- |
| Protocol/domain/pathparte delle due destinazioni URIs (A e B) | Possono essere diversi l'uno dall'altro oppure uguali. |
| BaseFilename parte delle due destinazioni URIs (A e B) | Possono essere diversi l'uno dall'altro oppure uguali. *Non è possibile* utilizzare [identificatori di variabili](variable-data-identifiers.md) che includono la data o l'ora. La combinazione di protocol/domain/path e BaseFileName deve essere univoca in A e B. Questa regola assicura che i file di output delle due pipeline non si sovrascrivano a vicenda. |
| Modificatore nome | C'è solo un'istanza di questo campo. Entrambe le pipeline utilizzano lo stesso valore. *Non è possibile* utilizzare [identificatori di variabili](variable-data-identifiers.md) che includono la data o l'ora. |
| Modificatore segmento | C'è solo un'istanza di questo campo. Entrambe le pipeline utilizzano lo stesso valore. *É possibile* utilizzare [identificatori di variabili](variable-data-identifiers.md) che includono la data o l'ora. |
| Manifesto URL di base A e Manifesto URL di base B | Questi campi si applicano solo se stai anche implementando [percorsi dei manifest personalizzati](hls-manifests-how-work.md#hls-custom-manifest-paths). In genere, con Akamai CDNs, si implementano percorsi manifest personalizzati. Completa entrambi i campi. |
| Contenuto URL di base A e Contenuto URL di base B | Questi campi si applicano solo se stai anche implementando [percorsi dei manifest personalizzati](hls-manifests-how-work.md#hls-custom-manifest-paths). Completa entrambi i campi. |
# Combinazione di manifest ridondanti con altre funzionalità
## Combinazione di manifest ridondanti e funzionalità dei percorsi personalizzati
Quando impostate manifesti ridondanti in un gruppo di output MediaLive HLS, potete anche impostare percorsi personalizzati. [[Assicuratevi di seguire le regole [per i percorsi personalizzati e per](hls-custom-paths-rules.md) i manifesti ridondanti per il sistema a valle, che si tratti di un CDN Akamai o di un altro sistema downstream.](hls-redundant-manif-most-systems.md)](hls-redundant-manif-akamai.md)
## Combinazione di manifest ridondanti con gruppi di rendering audio
**Nota**
Le informazioni contenute in questa sezione presuppongono che tu abbia familiarità con i manifest per i gruppi di rendering audio. Per ulteriori informazioni, consulta [Manifesto di esempio](sample-manifest.md).
Di seguito sono riportate informazioni sull'elaborazione che viene MediaLive eseguita quando si configurano manifesti ridondanti in un gruppo di output HLS che include un gruppo di riproduzione audio.
MediaLive regola automaticamente i riferimenti ai gruppi di resa audio nei manifesti principali.
In ogni coppia di righe (ad esempio, `#EXT-X-STREAM-INF` per il video ad alta risoluzione), MediaLive regola il nome dei gruppi di rappresentazione. In questo modo, i riferimenti ai gruppi di rendering sono diversi per ogni pipeline, il che garantisce che quando il lettore client legge il manifesto, scelga il video e l'audio dalla stessa pipeline.
`#EXT-X-STREAM` per il video per la pipeline 0. Prendi nota del valore per *AUDIO*:
```
#EXT-X-STREAM-INF:BANDWIDTH=541107,...AUDIO="aac-audio-0", ...
```
`#EXT-X-STREAM` per il video per la pipeline 1. Prendi nota del valore per *AUDIO*:
```
#EXT-X-STREAM-INF:BANDWIDTH =541107, ...AUDIO="aac-audio-1",...
```