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á.
# Processamento de conteúdo ao vivo
No fluxo de processamento de conteúdo ao vivo, os codificadores enviam fluxos HLS ao vivo para. MediaPackage MediaPackage em seguida, empacota o conteúdo, formatando-o em resposta às solicitações de reprodução dos dispositivos downstream.
As seções a seguir descrevem os fluxos de processamento ao vivo.
**Topics**
+ [Fluxo geral de processamento MediaPackage ao vivo](what-is-flow-gen.md)
+ [Fluxo de processamento de redundância AWS Elemental MediaPackage de entrada ao vivo](what-is-flow-ir.md)
# Fluxo geral de processamento MediaPackage ao vivo
A seguir, descrevemos o fluxo geral do conteúdo ao vivo em: MediaPackage
1. Um codificador upstream (como AWS Elemental MediaLive) envia uma transmissão ao vivo HLS com autenticação resumida via WebDAV para o URL de entrada do canal e inclui as MediaPackage credenciais de acesso do canal (conforme fornecido em). MediaPackage Se você estiver usando redundância de entrada, o codificador envia duas transmissões ao vivo HLS idênticas para MediaPackage, uma para cada URL de entrada no canal. MediaPackage usa o stream de um URL de entrada como conteúdo de origem. Se MediaPackage parar de receber conteúdo no URL de entrada ativo, ele mudará automaticamente para o outro URL de entrada do conteúdo de origem. Além disso, AWS aumenta e reduz os recursos para lidar com o tráfego de entrada.
Para obter mais informações, consulte [Fluxo de processamento de redundância AWS Elemental MediaPackage de entrada ao vivo](what-is-flow-ir.md).
**nota**
Para permitir o suporte a recursos como visualização com mudança de horário, MediaPackage armazena todo o conteúdo recebido por um tempo limitado. Esse conteúdo armazenado só ficará disponível para reprodução se estiver dentro da **startover window (janela de reinício)** definida no endpoint. O conteúdo armazenado não ficará disponível para reprodução se estiver fora da janela de reinício ou se você não tiver definido uma janela no endpoint. Para obter mais informações, consulte [Referência de visualização com mudança de horário em AWS Elemental MediaPackage](time-shifted.md).
1. Um dispositivo downstream solicita conteúdo MediaPackage por meio do URL de saída do endpoint. Um dispositivo downstream é um reprodutor de vídeo ou uma CDN. O URL de saída está associado a um endpoint para um formato específico de fluxo (Apple HLS, DASH-ISO, Microsoft Smooth Streaming ou CMAF).
1. Quando MediaPackage recebe a solicitação de reprodução do dispositivo downstream, ele empacota dinamicamente o stream de acordo com as configurações que você especificou no endpoint. O empacotamento pode incluir a adição de criptografia e a configuração de saídas de áudio, vídeo e legendas ou trilha de legendas.
Certifique-se de ordenar suas entradas para que sua reprodução de áudio preferida seja listada primeiro na seção de áudio do manifesto principal. Faça o mesmo com as legendas ou legendas. Ao empacotar faixas de áudio e legendas ou legendas, MediaPackage designa a primeira faixa de áudio e legendas ou legendas como e. `DEFAULT=YES` `AUTO-SELECT=YES` Esse pacote substitui as configurações padrão e de seleção automática da entrada.
1. MediaPackage entrega o fluxo de saída via HTTPS para o dispositivo solicitante. Assim como acontece com a entrada, AWS aumenta e diminui os recursos para lidar com as mudanças no tráfego.
1. MediaPackage registra atividades por meio da Amazon CloudWatch. Você pode visualizar informações como o número de solicitações de conteúdo e a quantidade de conteúdo MediaPackage recebido ou entregue. Para obter informações sobre a visualização de MediaPackage métricas em CloudWatch, consulte[Monitoramento AWS Elemental MediaPackage com CloudWatch métricas da Amazon](monitoring-cloudwatch.md).
Em todos os processos de entrada e saída de conteúdo, MediaPackage detecta e mitiga possíveis falhas na infraestrutura antes que elas se tornem um problema para os espectadores.
A ilustração a seguir mostra o processo geral.
![\[MediaPackage fluxo de trabalho\]](http://docs.aws.amazon.com/pt_br/mediapackage/latest/ug/images/bbl_flow1.png)
# Fluxo de processamento de redundância AWS Elemental MediaPackage de entrada ao vivo
Obtenha redundância de entrada AWS Elemental MediaPackage enviando dois fluxos para uma entrada separada URLs em um canal de entrada. MediaPackage Um dos streams torna-se o primário, a origem ativa do conteúdo para os endpoints, enquanto o outro continua a receber passivamente o conteúdo. Se MediaPackage parar de receber conteúdo do fluxo ativo, ele mudará para o outro fluxo de entrada para que a reprodução do conteúdo não seja interrompida.
Se você usa MediaPackage with AWS Elemental MediaLive (por exemplo), aqui está o fluxo de redundância de entrada:
1. Você cria um canal em MediaPackage, conforme descrito em[Criar um canal](channels-create.md). Ao MediaPackage provisionar o canal, ele cria duas entradas URLs para o canal. Se não estiver usando redundância de entrada, você pode enviar um stream para qualquer URL de entrada. Não há exigência de que você envie conteúdo para ambos URLs.
**nota**
Quando a redundância de entrada ficou disponível, MediaPackage adicionou uma segunda URL de entrada aos canais existentes e atualizou a URL existente para um novo formato. Você pode usar o URL existente ou o novo URLs para entrada de conteúdo.
1. Você cria um endpoint MediaPackage conforme descrito em[Criar um endpoint](endpoints-create.md).
**Importante**
Se você usar segmentos de saída curtos, dependendo do seu dispositivo de reprodução, poderá ver um buffer ao MediaPackage alternar as entradas. Você pode reduzir o armazenamento em buffer usando o recurso de tempo de atraso no endpoint. Esteja ciente de que usar um atraso de tempo introduz latência na end-to-end entrega do conteúdo. Para obter informações sobre como habilitar o tempo de atraso, consulte [Criar um endpoint](endpoints-create.md).
1. Você cria uma entrada e um canal AWS Elemental MediaLive de entrada e adiciona um grupo MediaPackage de saída ao canal de entrada MediaLive. Para obter mais informações, consulte [Como criar um canal a partir do zero](https://docs.aws.amazon.com/medialive/latest/ug/creating-channel-scratch.html) no *Guia do usuário do AWS Elemental MediaLive *.
Se você usar um grupo de saída HLS em AWS Elemental MediaLive, a ação de perda de entrada nas configurações do grupo HLS deverá ser definida para pausar a saída se o serviço não receber entrada. Se MediaLive enviar um quadro preto ou algum outro quadro de preenchimento quando falta a entrada, não MediaPackage consegue dizer quando os segmentos estão faltando e, posteriormente, não consegue realizar o failover. Para obter mais informações sobre como configurar a ação de perda de entrada em MediaLive, consulte [Campos do grupo HLS](https://docs.aws.amazon.com/medialive/latest/ug/hls-group-fields.html) no *Guia do AWS Elemental MediaLive usuário*.
**Importante**
Se você usar um codificador diferente (não AWS Elemental MediaLive) e enviar dois streams separados para o mesmo canal MediaPackage, os streams deverão ter configurações de codificador e nomes de manifesto idênticos. Caso contrário, a redundância de entrada poderá não funcionar corretamente e a reprodução poderá ser interrompida se as entradas mudarem.
1. Você inicia o canal AWS Elemental MediaLive para enviar as transmissões para MediaPackage.
1. MediaPackage recebe conteúdo em ambas as entradas URLs, mas somente um dos fluxos é usado como conteúdo de origem por vez. Se o stream ativo não tiver nenhum segmento, o failover MediaPackage automaticamente para o outro stream. MediaPackage continua usando esse fluxo até que o failover seja necessário novamente.
A fórmula usada para determinar se há segmentos ausentes em uma entrada é baseada nos comprimentos do segmento nas entradas e dos endpoints. Se uma entrada estiver dando falta de segmentos e recuperá-los rapidamente, um endpoint com mais comprimentos de segmento não alterna as entradas. Isso pode resultar em diferentes endpoints no canal usando entradas diferentes (se um endpoint muda e o outro não). Esse comportamento é esperado e não deve afetar o conteúdo do fluxo de trabalho.