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á.
# 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](hls-specify-destination.md).
**Para projetar o caminho**
1. Colete as informações que você [obteve anteriormente](origin-server-http.md) 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.
1. 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](hls-redundant-manifests.md) e, em seguida, retorne a esta seção.
+ Se você estiver implementando caminhos personalizados para manifestos, consulte [Personalizar os caminhos dentro dos manifestos HLS](hls-manifest-paths.md) e, em seguida, retorne a esta seção.
+ Se você não estiver implementando nenhum desses recursos, continue lendo esta seção.
1. Crie as partes dos caminhos de destino que seguem os buckets. Para obter detalhes, consulte a seção a seguir.
**Topics**
+ [A sintaxe dos caminhos para as saídas](#hls-syntax-http)
+ [Projetar as pastas e baseFilename](#hls-baseFilename-design)
+ [Projetar o nameModifier](#hls-nameModifier-design)
+ [Projetar o segmentModifier](#hls-segmentModifier-design)
## 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ê](origin-server-http.md) 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](hls-opg-redundant-manifest.md), 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](hls-opg-redundant-manifest.md).
## 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](variable-data-identifiers.md).
## 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 **\$1t\$1-**. 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.