Progetta il percorso per la destinazione di output - MediaLive

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à.

Progetta il percorso per la destinazione di output

Esegui questo passaggio se non hai ancora progettato il percorso o i percorsi di destinazione completi. Se hai già progettato i percorsi, vai aCompleta i campi sulla console.

Per progettare il percorso
  1. Raccogli le informazioni che hai ottenuto in precedenza dall'operatore del sistema a valle:

    • Il tipo di connessione per il sistema downstream: Akamai, basic PUT o Web. DAV

    • Le impostazioni per i campi di connessione, se il sistema a valle ha requisiti speciali.

    • Il protocollo di consegna— HTTP oHTTPS.

    • Il nome utente e la password per accedere al sistema a valle, se il sistema a valle richiede richieste autenticate. Tieni presente che queste credenziali utente si riferiscono all'autenticazione dell'utente, non al protocollo. L'autenticazione dell'utente riguarda l'accettazione o meno della richiesta da parte del sistema a valle. Il protocollo conferma se la richiesta viene inviata tramite una connessione sicura.

    • Tutti o parte dei percorsi di destinazione, inclusi possibilmente i nomi dei file.

    • Se è necessario configurare sottodirectory separate.

  2. Nell'ambito della pianificazione con l'operatore del sistema a valle, avreste dovuto decidere se implementare manifesti ridondanti. Avresti anche dovuto determinare se il sistema a valle richiede manifesti personalizzati. Alla luce di queste due decisioni, leggete la sezione appropriata:

  3. Progetta le porzioni dei percorsi di destinazione che seguono il bucket o i bucket. Per i dettagli, consulta le sezioni che seguono.

La sintassi dei percorsi per gli output

La tabella seguente descrive le parti che costituiscono i percorsi di destinazione per queste tre categorie di file.

I percorsi di destinazione per queste tre categorie di file sono identici fino a baseFilename, il che significa che tutte queste categorie di file vengono thatMediaLive inviate nella stessa cartella. I modificatori e le estensioni dei file sono diversi per ogni categoria di file.

File Sintassi del percorso Esempio
File manifest principali baseFilename estensione del percorso del dominio del protocollo

URLPer un manifesto principale con il nome di file /index:

http://203.0.113.55/sports/delivery/curling/index.m3u8
File manifest secondari baseFilename nameModifierestensione del percorso del dominio del protocollo Il manifesto URL for the child per le rappresentazioni ad alta risoluzione dell'output

http://203.0.113.55/sports/delivery/curling/index-high.m3u8

File multimediali (segmenti) protocol domain path baseFilename nameModifier optionalSegmentModifier counter extension

Il file URL per il 230° segmento potrebbe essere:

http:// 203.0.113.55/sports/delivery/curling/index-high-00230.ts

Questi percorsi di destinazione sono costruiti come segue:

  • L'operatore del sistema a valle avrebbe dovuto fornirti il protocollo, il dominio e parte del percorso. Per esempio:

    http://203.0.113.55/sports/

    Il protocollo è sempre HTTP oHTTPS.

  • L'operatore potrebbe aver fornito quanto segue. Altrimenti, li decidi tu:

    • Le cartelle

    • Le baseFilename

    • Il modificatore

    • Il segmentModifier

    Vedi le sezioni che seguono.

  • MediaLive inserisce il carattere di sottolineatura prima del contatore.

  • MediaLive genera il contatore, che è sempre composto da cinque cifre a partire da 00001.

  • MediaLive inserisce il punto prima dell'estensione.

  • MediaLive seleziona l'estensione:

    • Per i file manifest, sempre .m3u8

    • Per i file multimediali: .ts per i file in un flusso di trasporto e .mp4 per i file in un MP4 contenitore f

Progettazione delle cartelle e baseFilename

Per la baseFilename parte folder e il percorso di destinazione, segui queste linee guida:

  • Per un canale a pipeline singola, hai bisogno di un solo baseFilename.

  • Per un canale standard quando non implementi manifest ridondanti, sono necessari due baseFilenames. I due baseFilenames possono essere identici o diversi. Prima di creare diversi baseFilenames, assicurati che il sistema a valle possa funzionare con tale configurazione.

  • Per un canale standard quando implementi manifest ridondanti, consulta Campi per i manifest ridondanti.

Progettare il nameModifier

Progetta le nameModifier parti del nome del file. I manifest figlio e i file multimediali includono questo modificatore nei nomi dei file. Questo nameModifier distingue ogni output dall'altro, quindi deve essere univoco in ogni output. Seguire queste linee guida:

  • Per un output che contiene video (e possibilmente altri flussi), in genere viene descritto il video. Ad esempio, -high o -1920x1080-5500kpbs (per descrivere la risoluzione e il bitrate).

  • Per un output che contiene solo audio o solo didascalie, in genere si descrivono l'audio o le didascalie. Ad esempio -aac o -webVTT.

  • È una buona idea includere un delimitatore, per separare chiaramente il baseFilename. nameModifier

  • nameModifier può includere variabili di dati.

Progettare il segmentModifier

segmentModifiers Progetta la parte del percorso di destinazione. segmentModifier È facoltativo e, se lo includi, lo includono solo i nomi dei file multimediali.

Un tipico caso d'uso per questo modificatore consiste nell'uso di una variabile di dati per creare un timestamp, per evitare che i segmenti si sovrascrivano a vicenda se il canale si riavvia. Supponi, ad esempio, di includere il timestamp $t$-. Il segmento 00001 potrebbe avere il nome/index-120028-00001. Se l'output si riavvia qualche minuto dopo (il che causa il riavvio del contatore dei segmenti), il nuovo segmento 00001 avrà lo stesso nome. /index-120039-00001 Il nuovo file non sovrascriverà il file per il segmento originale 00001. Alcuni sistemi a valle potrebbero preferire questo comportamento.