Procedimento para configurar manifestos redundantes - MediaLive

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

Procedimento para configurar manifestos redundantes

Para configurar manifestos redundantes, ative o recurso no grupo de saída. Além disso, faça 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 sistema de downstream para descobrir se ele oferece suporte a manifestos redundantes.

  2. Leia as informações em Campos para o destino de saída — envio para um HTTP servidor. Os manifestos são considerados saídos de MediaLive. Portanto, as regras gerais sobre destinos de saída se aplicam a manifestos redundantes.

  3. Projetar os URLs para os dois pipelines. Existem requisitos especiais para URLs de arquivos HLS. Leia a seção apropriada:

    Essas regras complementam as informações em Campos para o destino de saída — envio para um HTTP servidor.

  4. Se você também precisar de caminhos personalizados para manifestos, leia as informações em Como os caminhos personalizados funcionam. É necessário considerar as regras para caminhos personalizados ao projetar os URLs.

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

  6. 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ída HLS — Localização — Manifesto de URL base (se você também estiver configurando caminhos personalizados)

    • Grupo de saída HLS — Localização — Conteúdo de 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.

Os resultados dessa configuração

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 de entrada é emitir saída

Se a entrada for perdida em um dos pipelines e o campo Ação de perda de entrada estiver definido como EMIT_OUTPUT, MediaLive continuará atualizando os manifestos pai e filho.

Do ponto de vista do sistema a jusante, não há alteração nos manifestos dos pais ou filhos de nenhum dos dutos. 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

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_OUTPUT, 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 na tubulação

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