Procedura per impostare i manifest ridondanti

La configurazione dei manifesti ridondanti negli output è suddivisa in due parti. MediaLive HLS È 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 HLS output che non implementano manifesti ridondanti).

Il seguente campo si riferisce specificamente ai manifest ridondanti:

• HLSgruppo di output — Manifesti e segmenti — Campo dei manifesti ridondanti

Per impostare i manifest ridondanti

1. Parla con l'operatore del sistema a valle per scoprire se supporta manifesti ridondanti.

2. Consulta le informazioni in Campi per la destinazione di output: invio a un server HTTP. I manifesti sono considerati emessi da. MediaLive Pertanto, le regole generali sulle destinazioni di output si applicano ai manifest ridondanti.

3. Progetta il URLs per le due condotte. Esistono requisiti speciali URLs per i HLS file. Consulta la sezione appropriata:

   • Regole per la maggior parte dei sistemi a valle

   • Regole per Akamai CDNs

   Queste regole integrano le informazioni contenute in Campi per la destinazione di output: invio a un server HTTP.

4. Se hai anche bisogno di percorsi personalizzati per i manifest, assicurati di leggere le informazioni in Come funzionano i percorsi personalizzati. È necessario considerare le regole per i percorsi personalizzati quando si progetta ilURLs.

5. Nella sezione del gruppo HLS di output, per Manifest e segmenti, per Manifesto ridondante, scegliete. ENABLED Questo campo si applica a tutti gli output del gruppo di output.

6. Completa questi campi in base alla tua progettazione:

   • Gruppo di output: sezione di destinazione del HLS gruppo

   • Gruppo di output — HLS impostazioni — CDN sezione

   • 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)

   • HLSuscite — Impostazioni di uscita — Modificatore di nome

   • HLSuscite — Impostazioni di uscita — Modificatore di segmento

   • HLSgruppo di output — Location —Base URL Manifest (se state impostando anche percorsi personalizzati)

   • HLSgruppo di output — Location — Base URL Content (se state impostando anche percorsi personalizzati)

Per informazioni su come questa funzionalità modifica il contenuto dei HLS manifesti, vedereI contenuti multimediali di un HLS manifesto.

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 in una delle pipeline e il campo di azione Input loss è impostato su EMIT_ OUTPUT, 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 tubazione 0) e il campo di azione Input loss è impostato su PAUSE_OUTPUT, MediaLive esegue le seguenti operazioni:

• 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'HLSuscita è AWS Elemental MediaStore, è possibile impostare l'eliminazione degli input MediaStore obsoleti. Vedi Componenti di una politica del ciclo di vita degli oggetti. Dopo l'eliminazione del manifesto secondario, MediaStore torna a seguire la logica «il manifesto è stato eliminato» dello scenario B.