Etapa 1: Projete o caminho para o destino de saída - MediaLive
A sintaxe dos caminhos para as saídasComo MediaLive constrói os caminhosProjetando as pastas e baseFilenameProjetando o nameModifierProjetando o segmentModifier

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Etapa 1: Projete o caminho para o destino de saída

Execute essa etapa se você ainda não tiver projetado o caminho ou caminhos de destino completos. Se você já projetou os caminhos, acesseEtapa 2: preencher os campos no console.

Para projetar o caminho

  1. Colete o endpoint de dados para o contêiner ou contêineres. Você já obteve essas informações do MediaStore usuário. Por exemplo: .

    a23f.data.mediastore.us-west-2.amazonaws.com

  2. Projete as partes dos caminhos de destino que seguem o ponto final de dados (para MediaStore).

A sintaxe dos caminhos para as saídas

Uma HLS saída sempre inclui três categorias de arquivos:

  • O manifesto principal

  • A criança se manifesta

  • Os arquivos de mídia

A tabela a seguir descreve as partes que compõem os caminhos de destino dessas três categorias de arquivos.

Os caminhos de destino para essas três categorias de arquivos são idênticos, incluindo o baseFilename, o que significa que MediaLive envia todas essas categorias de arquivos para a mesma pasta. Os modificadores e as extensões de arquivo são diferentes para cada categoria de arquivo. Ao enviar para MediaStore, você deve enviar todos os arquivos para a mesma pasta. Os sistemas posteriores esperam que todos os arquivos estejam juntos.

Arquivo Sintaxe do caminho Exemplo
Arquivos de manifesto principais protocol dataEndpoint path baseFilename extension

O caminho para um manifesto principal na entrega do caminho no contêiner e com o índice do nome do arquivo:

mediastoressl://a23f.data.mediastore.us-west-2.amazonaws.com/delivery/index.m3u8
Arquivos de manifesto secundário protocol dataEndpoint path baseFilename nameModifier extension O caminho para o manifesto secundário para as representações de alta resolução da saída

mediastoressl://a23f.data.mediastore.us-west-2.amazonaws.com/delivery/index-high.m3u8
Arquivos de mídia (segmentos) protocol dataEndpoint path baseFilename nameModifier optionalSegmentModifier counter extension

O caminho para o arquivo do 230º segmento pode ser:

mediastoressl://a23f.data.mediastore.us-west-2.amazonaws.com/delivery/index-high-00230.ts

Como MediaLive constrói os caminhos

Esses caminhos são construídos da seguinte forma:

  • O usuário do AWS serviço deveria ter fornecido os nomes dos contêineres.

  • Para MediaStore isso, você deve determinar o seguinte:

    • As pastas

    • O baseFilename

    • O modificador

    • O segmentModifier

    Veja as seções a seguir.

  • MediaLive insere o sublinhado antes do contador.

  • MediaLive gera o contador, que sempre tem cinco dígitos começando em 00001.

  • MediaLive insere o ponto antes da extensão.

  • MediaLive seleciona a extensão:

    • Para arquivos de manifesto — sempre .m3u8

    • Para arquivos de mídia — .ts para arquivos em um fluxo de transporte ou.mp4 para arquivos em um contêiner f MP4

Projetando as pastas e baseFilename

Crie um caminho de pasta adequado baseFilename às suas finalidades.

Se você tiver dois destinos para cada saída, os caminhos de destino devem ser diferentes um do outro de alguma forma. Siga estas diretrizes:

  • Pelo menos uma das partes de um caminho deve ser diferente da outra. É aceitável que todas as porções sejam diferentes.

    Portanto, se os buckets ou contêineres forem diferentes, o caminho da pasta e os nomes dos arquivos dos dois destinos podem ser diferentes um do outro ou podem ser iguais. Por exemplo: .

    mediastoressl://a23f.data.mediastore.us-west-2.amazonaws.com/delivery/index.m3u8

    mediastoressl://fe30.data.mediastore.us-west-2.amazonaws.com/delivery/index.m3u8

    ou

    mediastoressl://a23f.data.mediastore.us-west-2.amazonaws.com/delivery/index.m3u8

    mediastoressl://fe30.data.mediastore.us-west-2.amazonaws.com/redundant/index.m3u8

  • Se os buckets ou contêineres forem iguais, o caminho da pasta e os nomes dos arquivos dos dois destinos devem ser diferentes um do outro. Por exemplo: .

    mediastoressl://a23f.data.mediastore.us-west-2.amazonaws.com/delivery/index.m3u8

    mediastoressl://a23f.data.mediastore.us-west-2.amazonaws.com/redundant/index.m3u8

Projetando o nameModifier

Crie as nameModifier partes do nome do arquivo. Os manifestos filhos e os arquivos de mídia incluem esse modificador em seus nomes de arquivo. Esse nameModifier distingue cada saída uma da outra, então ele deve ser exclusivo em cada saída. Siga estas diretrizes:

  • Para uma saída que contém vídeo (e possivelmente outros streams), você normalmente descreve o vídeo. Por exemplo, -high ou -1920x1080-5500kpbs (para descrever a resolução e a taxa de bits).

  • Para uma saída que contém apenas áudio ou apenas legendas, você normalmente descreve o áudio ou as legendas. Por exemplo, o -aac ou o -webVTT.

  • É uma boa ideia começar nameModifier com um delimitador, como um hífen, para separar o do. baseFilename nameModifier

  • O nameModifier pode incluir variáveis de dados.

Projetando o segmentModifier

Projete a segmentModifiers parte do caminho de destino. segmentModifier É opcional e, se você incluí-lo, somente os nomes dos arquivos de mídia o incluirão.

Um caso de uso típico para esse modificador é usar uma variável de dados para criar um time stamp, com o intuito de evitar que segmentos se substituam se o canal for reiniciado. Por exemplo, suponha que você inclua o time stamp $t$-. O segmento 00001 pode ter o nomeindex-120028-00001. Se a saída for reiniciada alguns minutos depois (o que faz com que o contador de segmentos seja reiniciado), o novo segmento 00001 terá o nome. index-120039-00001 O novo arquivo não substituirá o arquivo do segmento original 00001. Alguns sistemas de downstream podem preferir esse comportamento.