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

# Criar manifestos HLS redundantes
<a name="hls-redundant-manifests"></a>

Ao criar um grupo de saída HLS em um MediaLive canal padrão, você pode ativar manifestos redundantes. Os manifestos redundantes permitem que o sistema de downstream (que lê os manifestos) lide melhor com uma falha de saída do MediaLive.

Quando o recurso de manifesto redundante está habilitado, o manifesto principal para cada pipeline faz referência tanto a seus próprios manifestos filhos como aos manifestos filhos do outro pipeline. O sistema de downstream localiza o caminho dos manifestos filhos de um pipeline. Se houver um problema com esse pipeline, haverá um problema com os manifestos filhos desse pipeline. O sistema de downstream pode, então, fazer referência ao manifesto principal para localizar o manifesto filho do outro pipeline. Dessa forma, o sistema de downstream pode sempre continuar com seu processamento do manifesto e da mídia.

Para implementar manifestos redundantes, você deve ter certeza de que o sistema de downstream pode lidar com manifestos redundantes das maneiras descritas na especificação HLS.

**nota**  
As informações desta seção em manifestos HLS pressupõem que você esteja familiarizado com as etapas gerais para criar um canal, conforme descrito em [Criar um canal do zero](creating-channel-scratch.md).   
Os principais campos no console relacionados a esse recurso estão no agrupamento **Manifests and segments (Manifestos e segmentos)** da seção **HLS output group (Grupo de saída HLS)** na página **Create channel (Criar canal)**. Para revisar a etapa em que você preenche esses campos, consulte [O procedimento](creating-hls-output-group.md#hls-create-procedure).

**Topics**
+ [Procedimento para configurar manifestos redundantes](hls-rm-procedure.md)
+ [O conteúdo de mídia de um manifesto HLS](hls-rm-manifests-contents.md)
+ [Regras para a maioria dos sistemas de downstream](hls-redundant-manif-most-systems.md)
+ [Regras para a Akamai CDNs](hls-redundant-manif-akamai.md)
+ [Combinar manifestos redundantes com outros recursos](hls-redundant-manif-combine.md)

# Procedimento para configurar manifestos redundantes
<a name="hls-rm-procedure"></a>

Há duas partes na configuração de manifestos redundantes nas MediaLive saídas HLS. Você deve ativar o recurso no grupo de saídas. Além disso, é necessário fazer ajustes no design dos nomes de saída e caminhos de destino (em comparação com saídas HLS que não implementam manifestos redundantes).

O campo a seguir se relaciona especificamente a manifestos redundantes:
+ Campo **HLS output group – Manifests and Segments – Redundant manifests (Grupo de saída HLS – Manifestos e segmentos – Manifestos redundantes)**

**Como configurar manifestos redundantes**

1. Fale com o operador do sistema downstream para descobrir se ele oferece suporte a manifestos redundantes.

1. Leia as informações em [Campos do destino da saída: envio para um servidor HTTP](hls-destinations-http.md). Os manifestos são considerados saídos de MediaLive. Portanto, as regras gerais sobre destinos de saída se aplicam a manifestos redundantes.

1. Projete o URLs para as duas tubulações. Existem requisitos especiais URLs para os arquivos HLS. Leia a seção apropriada:
   + [Regras para a maioria dos sistemas de downstream](hls-redundant-manif-most-systems.md) 
   + [Regras para a Akamai CDNs](hls-redundant-manif-akamai.md)

   Essas regras complementam as informações em [Campos do destino da saída: envio para um servidor HTTP](hls-destinations-http.md).

1. Se você também precisar de caminhos personalizados para manifestos, leia as informações em [Como os caminhos personalizados funcionam](hls-manifests-how-work.md#hls-custom-manifest-paths). Você deve considerar as regras para caminhos personalizados ao criar URLs o.

1. Na seção **HLS output group (Grupo de saída HLS)**, para **Manifest and segments (Manifesto e segmentos)**, em **Redundant manifest (Manifesto redundante)**, selecione **ENABLED (Habilitado)**. Esse campo se aplica a todas as saídas do grupo de saídas.

1. Preencha estes campos de acordo com seu projeto:
   + Seção **Output group – HLS group destination (Grupo de saída – Destino do grupo HLS)**
   + Seção **Output group – HLS settings – CDN (Grupo de saída – Configurações HLS – CDN)**
   + **Output group – Location – Directory structure (Grupo de saída – Local – Estrutura de diretórios)**
   + **Output group – Location – Segments per subdirectory (Grupo de saída – Local – Segmentos por subdiretório)**
   + **Saídas HLS — Configurações de saída — Modificador de nome**
   + **Saídas HLS — Configurações de saída — Modificador de segmento**
   + **Grupo de saídas HLS — Local — Manifesto do URL base** (se você também estiver configurando caminhos personalizados)
   + **Grupo de saídas HLS — Local — Conteúdo do URL base** (se você também estiver configurando caminhos personalizados) 

Para obter informações sobre como esse recurso altera o conteúdo dos manifestos HLS, consulte [O conteúdo de mídia de um manifesto HLS](hls-rm-manifests-contents.md).

## Os resultados dessa configuração
<a name="hls-redundant-manif-results"></a>

Veja a seguir informações sobre como os manifestos redundantes funcionam em três cenários de falha.

### Cenário A: a ação de perda da entrada é emitir saída
<a name="hls-redundant-manif-results-emit"></a>

Se a entrada for perdida em um dos pipelines e o [campo **Ação de perda de entrada**](hls-other-features.md#hls-resiliency) estiver definido como **EMIT\$1OUTPUT**, MediaLive continuará atualizando os manifestos pai e filho. 

Do ponto de vista do sistema downstream, não há nenhuma alteração nos manifestos pai ou filho para nenhum pipeline. O conteúdo dentro dos arquivos de mídia é conteúdo de preenchimento, mas isso não afeta a forma como o sistema de downstream lê os manifestos.

### Cenário B: a ação de perda de entrada é pausar a saída
<a name="hls-redundant-manif-results-pause"></a>

Se a entrada for perdida em um dos pipelines (por exemplo, no pipeline 0) e o campo **Ação de perda de entrada** estiver definido como **PAUSE\$1OUTPUT**, MediaLive faça o seguinte:
+ Removerá a listagem dos manifestos filhos para o pipeline 0. 
+ Enviará uma solicitação ao local do manifesto filho para que o pipeline 0 exclua os manifestos filhos.

O resultado para o sistema de downstream que está lendo o manifesto principal no pipeline 0: o sistema não encontrará mais uma listagem para os manifestos filhos do pipeline 0. O sistema procurará um manifesto filho alternativo no manifesto principal do pipeline 0. Se encontrar o manifesto filho do pipeline 1, ele mudará para a leitura desse manifesto filho. 

Os sistemas de downstream que estão lendo o manifesto principal do pipeline 1 não são afetados, pois esses sistemas provavelmente estão lendo os manifestos filhos do pipeline 1 (já que eles aparecem primeiro no manifesto). 

### Cenário C: falha no pipeline
<a name="hls-redundant-manif-results-pipeline-failure"></a>

Também pode ocorrer uma falha no pipeline. Essa falha não é a mesma que uma falha de entrada. Quando um pipeline falha (por exemplo, o pipeline 0), acontece o seguinte:
+ A saída é interrompida.
+ O manifesto principal do pipeline 0 não é excluído. Ele ainda contém uma listagem dos manifestos filhos do pipeline 0. 
+ Os manifestos filhos não são atualizados porque nenhum arquivo de mídia novo está sendo produzido. Os manifestos filhos ficam *obsoletos*.
+ O manifesto principal do pipeline 1 não muda. Ele ainda contém uma listagem dos manifestos filhos do pipeline 0 (e do pipeline 1).

O resultado para o sistema de downstream que está lendo o manifesto principal do pipeline 0: o sistema encontrará uma listagem de manifestos filhos do pipeline 0, mas esse manifesto ficará obsoleto. Se o sistema detectar que o manifesto está obsoleto, ele poderá retornar ao manifesto principal do pipeline 0 e procurar um manifesto filho alternativo. Se encontrar o manifesto filho do pipeline 1, ele mudará para a leitura desse manifesto filho. 

Os sistemas de downstream que estão lendo o manifesto principal do pipeline 1 não são afetados. Presumivelmente, esses sistemas estão lendo os manifestos filhos do pipeline 1 (já que eles aparecem primeiro no manifesto).

**nota**  
Se o sistema downstream da saída HLS for AWS Elemental MediaStore, você pode configurar MediaStore para excluir entradas obsoletas. Consulte [Componentes de uma política de ciclo de vida de objetos](https://docs.aws.amazon.com/mediastore/latest/ug/policies-object-lifecycle-components.html). Depois que o manifesto secundário for excluído MediaStore , volte a seguir a lógica de “o manifesto foi excluído” do cenário B.

# O conteúdo de mídia de um manifesto HLS
<a name="hls-rm-manifests-contents"></a>

Quando você configura manifestos redundantes em uma saída HLS, MediaLive altera o conteúdo do manifesto. Ela altera as informações de mídia (as informações de vídeo, áudio e legendas) dentro dos manifestos. Todas essas informações aparecem como tags `#EXT-X-STREAM-INF`.

As seções a seguir descrevem o número dessas tags e o conteúdo dessas tags em um manifesto padrão (não redundante) e em um manifesto redundante.

## Como seria um manifesto padrão
<a name="hls-redundant-manif-what-standard-like"></a>

Com um canal padrão, existem dois pipelines. Cada pipeline produz seu próprio conjunto de manifestos. Portanto, para o pipeline 0, há um manifesto principal, um conjunto de manifestos filhos e um conjunto de arquivos de mídia. Da mesma forma, o pipeline 1 tem o mesmo conjunto de arquivos. Os manifestos fazem referência apenas aos arquivos do seu próprio pipeline.

As informações de vídeo no manifesto principal para cada pipeline podem ser semelhantes a estas:

```
#EXT-X-STREAM-INF:BANDWIDTH=629107 ... 
curling-high.m3u8
```

## Como seria um manifesto redundante
<a name="hls-redundant-manif-what-redundant-like"></a>

Quando o recurso de manifesto redundante está habilitado, cada manifesto principal faz referência aos manifestos filhos do seu próprio pipeline e do outro pipeline. 

Esse recurso não afeta manifestos filhos. Os manifestos filhos fazem referência apenas aos seus próprios arquivos de mídia.

Veja a seguir um exemplo de como as informações de vídeo no manifesto podem aparecer. Suponha que o baseFilename do pipeline 0 seja *first-curling* e o do pipeline 1 seja *other-curling*. 

O manifesto do pipeline 0 pode ser assim (com as informações do manifesto filho do pipeline 0 aparecendo primeiro):

```
#EXT-X-STREAM-INF:BANDWIDTH=629107 ... 
first-curling-high.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=629107 ... 
other-curling-high.m3u8
```

As informações de vídeo no manifesto do pipeline 1 podem ser assim (com as informações do manifesto filho do pipeline 1 aparecendo primeiro):

```
#EXT-X-STREAM-INF:BANDWIDTH=629107 ... 
other-curling-high.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=629107 ... 
first-curling-high.m3u8
```

# Regras para a maioria dos sistemas de downstream
<a name="hls-redundant-manif-most-systems"></a>

Você pode configurar manifestos redundantes em um grupo de saída MediaLive HLS, desde que o sistema downstream possa trabalhar com regras específicas. Leia esta seção se você estiver configurando manifestos redundantes com qualquer sistema de downstream, exceto o Akamai. Se o seu sistema de downstream for uma CDN do Akamai, consulte [Regras para a Akamai CDNs](hls-redundant-manif-akamai.md).

Certifique-se de que o sistema downstream possa funcionar com as regras a seguir.
+ MediaLive envia os arquivos dos dois pipelines para o mesmo local ()protocol/domain/path. 
+ Considerando que o local é o mesmo, os nomes dos arquivos base dos pipelines devem ser diferentes.
+ Se você também estiver implementando [caminhos de manifesto personalizados](hls-manifests-how-work.md#hls-custom-manifest-paths), o URL dentro dos manifestos deverá ser idêntico.


|  Campo  |  Regra  | 
| --- | --- | 
|  Protocol/domain/pathparte dos dois destinos URIs (A e B)  |  Deve ser idêntica em ambos os campos.  | 
|  Parte do nome do arquivo base dos dois destinos URIs (A e B)  |  Deve ser diferente em cada campo. Ele *não pode* usar [identificadores de variáveis](variable-data-identifiers.md) que incluem a data ou a hora.  | 
|  NameModifier para cada saída  |  Há apenas uma instância desse campo. Ambos os pipelines usam o mesmo valor. Ele *não pode* usar [identificadores de variáveis](variable-data-identifiers.md) que incluem a data ou a hora.  | 
|  Modificador de segmento  |  Há apenas uma instância desse campo. Ambos os pipelines usam o mesmo valor. Ele *pode* usar [identificadores de variáveis](variable-data-identifiers.md) que incluem a data ou a hora.  | 
| Manifesto de URL base A e Manifesto de URL base B  |  Esses campos se aplicam somente se você também estiver implementando [caminhos de manifesto personalizados](hls-manifests-how-work.md#hls-custom-manifest-paths).  Preencha os dois campos.  | 
| Conteúdo de URL base A e Conteúdo de URL base B  |  Esses campos se aplicam somente se você também estiver implementando [caminhos de manifesto personalizados](hls-manifests-how-work.md#hls-custom-manifest-paths).  Preencha os dois campos.   | 

# Regras para a Akamai CDNs
<a name="hls-redundant-manif-akamai"></a>

Você pode configurar manifestos redundantes em um grupo de saída MediaLive HLS, desde que o sistema downstream possa trabalhar com regras específicas. Leia esta seção se você estiver configurando manifestos redundantes com uma CDN do Akamai. Se o seu sistema de downstream não for uma CDN do Akamai, consulte [Regras para a maioria dos sistemas de downstream](hls-redundant-manif-most-systems.md).

Certifique-se de que o sistema downstream possa funcionar com as regras a seguir.


|  Campo  |  Regra  | 
| --- | --- | 
|  Protocol/domain/pathparte dos dois destinos URIs (A e B)  | Pode ser diferente um do outro, ou pode ser o mesmo.  | 
|  BaseFilename parte dos dois destinos URIs (A e B)  |  Pode ser diferente um do outro, ou pode ser o mesmo. Ele *não pode* usar [identificadores de variáveis](variable-data-identifiers.md) que incluem a data ou a hora. A combinação do protocol/domain/path e do BaseFileName deve ser exclusiva em A e B. Essa regra garante que os arquivos de saída dos dois pipelines não se sobrescrevam.   | 
|  Modificador de nome  |  Há apenas uma instância desse campo. Ambos os pipelines usam o mesmo valor. Ele *não pode* usar [identificadores de variáveis](variable-data-identifiers.md) que incluem a data ou a hora.   | 
|  Modificador de segmento  |  Há apenas uma instância desse campo. Ambos os pipelines usam o mesmo valor.  Ele *pode* usar [identificadores de variáveis](variable-data-identifiers.md) que incluem a data ou a hora.  | 
| Manifesto de URL base A e Manifesto de URL base B  |  Esses campos se aplicam somente se você também estiver implementando [caminhos de manifesto personalizados](hls-manifests-how-work.md#hls-custom-manifest-paths). Normalmente, com a Akamai CDNs, você implementa caminhos de manifesto personalizados. Preencha os dois campos.  | 
| Conteúdo de URL base A e Conteúdo de URL base B  |  Esses campos se aplicam somente se você também estiver implementando [caminhos de manifesto personalizados](hls-manifests-how-work.md#hls-custom-manifest-paths).  Preencha os dois campos.   | 

# Combinar manifestos redundantes com outros recursos
<a name="hls-redundant-manif-combine"></a>

## Combinar manifestos redundantes e recurso de caminho personalizado
<a name="hls-redundant-manif-with-custom-paths"></a>

Ao configurar manifestos redundantes em um grupo de saída MediaLive HLS, você também pode configurar caminhos personalizados. Certifique-se de seguir as regras [para caminhos personalizados](hls-custom-paths-rules.md) e manifestos redundantes para o seu sistema downstream, seja uma [CDN do Akamai](hls-redundant-manif-akamai.md) ou [outro sistema downstream](hls-redundant-manif-most-systems.md).

## Combinar manifestos redundantes com grupos de versões de áudio
<a name="hls-redundant-manif-with-args"></a>

**nota**  
As informações desta seção pressupõem que você esteja familiarizado com os manifestos dos grupos de versões de áudio. Para obter mais informações, consulte [Manifesto de exemplo](sample-manifest.md).

Veja a seguir informações sobre o processamento que é MediaLive executado quando você configura manifestos redundantes em um grupo de saída HLS que inclui um grupo de reprodução de áudio.

MediaLive ajusta automaticamente as referências aos grupos de reprodução de áudio nos manifestos principais.

Em cada par de linhas (por exemplo, `#EXT-X-STREAM-INF` para o vídeo de alta resolução), MediaLive ajusta o nome dos grupos de representação. Dessa forma, as referências aos grupos de representação são diferentes para cada pipeline, garantindo que o player cliente escolha o vídeo e o áudio do mesmo pipeline ao ler o manifesto. 

O `#EXT-X-STREAM` para o vídeo do pipeline 0. Observe o valor de *AUDIO*:

```
#EXT-X-STREAM-INF:BANDWIDTH=541107,...AUDIO="aac-audio-0", ... 
```

 O `#EXT-X-STREAM` para o vídeo do pipeline 1. Observe o valor de *AUDIO*:

```
#EXT-X-STREAM-INF:BANDWIDTH =541107, ...AUDIO="aac-audio-1",... 
```