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, acessePreencha os campos no console.

Para projetar o caminho

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

   • O tipo de conexão para o sistema downstream — AkamaiPUT, básico ou Web. DAV

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

   • O protocolo para entrega— HTTP ouHTTPS.

   • O nome de usuário e a 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, 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. Você também deveria ter determinado se o sistema downstream exige manifestos personalizados. Dadas essas duas decisões, leia a seção apropriada:

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

   • Se você estiver implementando caminhos personalizados para manifestos, consulte e, em seguidaPersonalizando os caminhos dentro HLS dos manifestos, 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 o compartimento ou compartimentos. Para obter detalhes, consulte as seções 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	baseFilename extensão do caminho do domínio do protocolo	O URL para um manifesto principal com o nome de arquivo /index: http://203.0.113.55/sports/delivery/curling/index.m3u8
Arquivos de manifesto secundário	baseFilename nameModifierextensão do caminho do domínio do protocolo	O manifesto URL for the child para as representações de 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 para o 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 ouHTTPS.

• O operador pode ter fornecido o seguinte. Caso contrário, você os decide:

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

Projetando as pastas e baseFilename

Para a baseFilename parte folder e o 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.

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 incluir um delimitador para separar claramente 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 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.