Projetar o caminho para o destino da saída

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

Para projetar o caminho

1. Colete as informações que você obteve anteriormente do operador do sistema downstream:

   • O tipo de conexão do sistema downstream: Akamai, Basic PUT ou WebDAV.

   • As configurações dos campos de conexão, se o sistema downstream tiver requisitos especiais.

   • O protocolo de entrega: HTTP ou HTTPS.

   • O nome de usuário e senha para acessar o sistema downstream, se o sistema downstream exigir solicitações autenticadas. Observe que essas credenciais de usuário estão relacionadas à autenticação do usuário, e não ao protocolo. A autenticação do usuário é sobre se o sistema downstream aceitará sua solicitação. O protocolo é sobre se a solicitação será enviada por meio de uma conexão segura.

   • Todos ou parte dos caminhos de destino, possivelmente incluindo os nomes dos arquivos.

   • Se você precisa configurar subdiretórios separados.

2. Como parte do planejamento com o operador do sistema downstream, você deve ter determinado se deseja implementar manifestos redundantes. Também deve ter determinado se o sistema downstream requer manifestos personalizados. Considerando essas duas decisões, leia a seção apropriada:

   • Se você estiver implementando manifestos redundantes, consulte Criar manifestos HLS redundantes e, em seguida, retorne a esta seção.

   • Se você estiver implementando caminhos personalizados para manifestos, consulte Personalizar os caminhos dentro dos manifestos HLS e, em seguida, retorne a esta seção.

   • Se você não estiver implementando nenhum desses recursos, continue lendo esta seção.

3. Crie as partes dos caminhos de destino que seguem os buckets. Para obter detalhes, consulte a seção a seguir.

A sintaxe dos caminhos para as saídas

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 thatMediaLive enviar 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.

Arquivo	Sintaxe do caminho	Exemplo
Arquivos de manifesto principais	protocolo domínio caminho baseFilename extensão	O URL de um manifesto principal com o nome de arquivo /index: http://203.0.113.55/sports/delivery/curling/index.m3u8
Arquivos de manifesto filhos	protocolo domínio caminho baseFilename nameModifier extensão	Por exemplo, o URL do manifesto filho para as representações em alta resolução da saída http://203.0.113.55/sports/delivery/curling/index-high.m3u8
Arquivos de mídia (segmentos)	protocol domain path baseFilename nameModifier optionalSegmentModifier counter extension	O URL do arquivo do 230º segmento pode ser: http:// 203.0.113.55/sports/delivery/curling/index-high-00230.ts

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

• O operador do sistema downstream deveria ter fornecido a você o protocolo, o domínio e parte do caminho. Por exemplo:

  http://203.0.113.55/sports/

  O protocolo é sempre HTTP or HTTPS.

• O operador pode ter fornecido as informações a seguir. Caso contrário, você deverá decidir:

  • As pastas

  • O baseFilename

  • O modificador

  • O segmentModifier

  Consulte 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 e .mp4 para arquivos em um MP4 contêiner f

Projetar as pastas e baseFilename

Para as partes folder e baseFilename do caminho de destino, siga estas diretrizes:

• Para um canal de pipeline único, você precisa apenas de um baseFilename.

• Para um canal padrão quando não está implementando manifestos redundantes, você precisa de dois baseFilenames. Os dois baseFilenames podem ser idênticos ou diferentes. Antes de criar baseFilenames diferentes, certifique-se de que o sistema de downstream pode funcionar com essa configuração.

• Para obter um canal padrão quando estiver implementando manifestos redundantes, consulte Campos para manifestos redundantes.

Projetar o nameModifier

Projete as partes nameModifier 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, -aac ou -webVTT.

• É uma boa ideia incluir um delimitador para separar claramente baseFilename de nameModifier.

• O nameModifier pode incluir variáveis de dados.

Projetar o segmentModifier

Projete a parte segmentModifiers do caminho de destino. O 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 nome /index-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.