Envio de conteúdo ao vivo do YouTube por HLS

Este documento explica como usar o protocolo HTTP Live Streaming (HLS) para transmitir dados ao vivo no YouTube usando um codificador. Este documento é destinado a fornecedores de codificadores que querem adicionar suporte à ingestão de HLS aos produtos. A transferência de HLS é uma boa escolha para conteúdo premium que exige alta qualidade e alta resolução com uma latência relativamente maior. Para uma breve comparação dos diferentes protocolos de ingestão compatíveis com o YouTube Live Streaming, consulte Comparação de protocolos de ingestão do YouTube Live Streaming.

Para transmitir dados ao vivo usando o HLS, o codificador precisa enviar uma série de playlists de mídia e segmentos de mídia para o endpoint HLS do YouTube usando solicitações HTTP PUT ou POST. Do ponto de vista do codificador, o endpoint HLS do YouTube parece ser um servidor HTTP passivo.

Cada segmento de mídia representa o conteúdo multimídia real de uma parte breve do stream com duração de um a quatro segundos. Cada playlist de mídia descreve como remontar os segmentos de mídia na ordem correta do fluxo.

Requisitos de formato de mídia

A transferência HLS do YouTube tem os seguintes requisitos para conteúdo de vídeo e áudio:

• O vídeo e o áudio precisam ser mesclados no formato M2TS.
• Os codecs de vídeo compatíveis são H.264 e HEVC.
• A taxa de frames é compatível com até 60 fps.
• Somente o GOP fechado é aceito.
• O codec de áudio aceito é AAC, e apenas áudio de faixa única é aceito.

Consulte os requisitos mais detalhados na seção Segmentos de mídia.

HDR

O vídeo em HDR é compatível com o codec HEVC e tem os seguintes requisitos adicionais:

• Os padrões de cores compatíveis são PQ de 10 bits e HLG com luminância não constante. Mais especificamente:
  • O formato da croma precisa ser YUV 4:2:0 de 10 bits.
  • A função de transferência precisa ser PQ (também conhecida como SMPTE ST 2084) ou HLG (também conhecida como ARIB STD-B67).
  • As cores primárias precisam ser Rec. 2020.
  • Os coeficientes da matriz precisam ser Rec. 2020 luminância não constante.
• Os valores de amostra de faixa limitada (ou MPEG) e de faixa completa (ou JPEG) são aceitos. É importante que o intervalo seja definido de acordo com o intervalo de valor de amostra usado pelo conteúdo. Valores de amostra de faixa limitada são recomendados.

Como receber um URL de transferência HLS

Como conseguir um URL de transferência HLS da API YouTube

Para receber o URL de ingestão completo, os codificadores podem usar a API YouTube Live Streaming para inserir um recurso liveStream com as seguintes propriedades:

"cdn": {
  "ingestionType": "hls",
  "frameRate": "variable",
  "resolution": "variable"
}

Na resposta da API, o campo cdn.ingestionInfo.ingestionAddress especifica o URL de transferência principal, e o campo cdn.ingestionInfo.backupIngestionAddress especifica o URL de transferência de backup. Para mais detalhes, consulte a documentação do recurso liveStreams.

Como conseguir um URL de transferência HLS no YouTube Studio

Atenção: esse método de recebimento de URLs de transferência HLS é um recurso Beta e pode mudar no futuro.

Na interface da Web do YouTube Studio, depois que o criador de conteúdo clica em "Criar transmissão", o YouTube mostra uma "chave de transmissão" que consiste em caracteres alfanuméricos e hifens. Essa chave secreta identifica o criador e a transmissão para o YouTube.

É possível criar um URL HLS com base nessa chave de transmissão da seguinte maneira:

https://a.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY&copy=0&file=

... em que $STREAM_KEY é a chave de transmissão exibida na interface da Web. Por exemplo: https://a.upload.youtube.com/http_upload_hls?cid=abcd-efgh-ijkl-mnop-qrst&copy=0&file=

Para maior confiabilidade, transmita uma segunda cópia redundante da transferência para este URL de backup:

https://b.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY&copy=1&file=

O backup tem duas diferenças em relação ao URL principal: o nome do host e o parâmetro copy= foram alterados. A transferência de backup precisa enviar um valor de parâmetro copy= diferente da transferência principal para evitar a corrupção do stream.

Como preencher o URL de transferência com HLS

Os URLs obtidos usando os dois métodos são modelos incompletos. Cada um deles termina com um parâmetro de consulta file= vazio. Para formar o URL final, o codificador precisa anexar o nome de um segmento ou playlist de mídia ao final do URL, concluindo o parâmetro file=.

As regras a seguir se aplicam ao valor do parâmetro file=:

• O codificador pode construir um nome de arquivo de playlist ou segmento de mídia usando caracteres alfanuméricos, sublinhados, barras, hifens e pontos. Nenhum outro caractere é aceito.
• O codificador não pode codificar o nome do arquivo para URL.
• O codificador pode incluir componentes de caminho relativo ou absoluto em nomes de arquivos, mas isso nunca é necessário. Se o codificador incluir um componente de caminho em um nome de arquivo de segmento de mídia, ele precisará referenciar o mesmo caminho na entrada de playlist correspondente.

Requisitos do protocolo HLS

As playlists de mídia e os segmentos de mídia enviados pelo codificador precisam estar em conformidade com a especificação do HTTP Live Streaming 2ª edição.

A especificação HLS define dois tipos de playlist: playlist de mídia e playlist mestre. Como o YouTube faz a transcodificação do conteúdo transmitido para diferentes resoluções e taxas de bits, o codificador não precisa enviar conteúdo com taxas de bits diferentes para o YouTube. Como resultado, o YouTube oferece suporte apenas a playlists de mídia para transferência de HLS, e as playlists master são ignoradas. Uma playlist principal fornece um conjunto de transmissões variantes, cada uma descrevendo uma versão diferente do mesmo conteúdo.

O codificador precisa:

• Envie exatamente um fluxo codificado com a resolução mais alta que você quer oferecer aos usuários (resolução e codec únicos).
• Mux áudio e vídeo.
• use HTTPS e uma conexão persistente para todas as solicitações.

As seções a seguir contêm requisitos mais específicos para playlists de mídia e segmentos de mídia.

Playlists de mídia

Uma playlist de mídia contém uma lista de segmentos de mídia que podem ser concatenados para representar um stream multimídia contínuo e decodificável. A playlist de mídia informa ao servidor quais segmentos de mídia esperar e como ordená-los corretamente no stream remontado.

Requisitos

• O nome do arquivo da playlist de mídia precisa terminar com .m3u8 ou .m3u.

• A primeira playlist de mídia enviada para um stream precisa começar no número de sequência 0, e o número de sequência precisa aumentar de forma monotonicamente.

• A tag EXT-X-MEDIA-SEQUENCE precisa identificar o número de sequência do primeiro segmento de mídia listado na playlist.

• Uma playlist de mídia não pode conter mais de cinco segmentos pendentes. Um segmento está pendente se o servidor não o recebeu ou não confirmou o recebimento.

  Além dos segmentos pendentes, inclua também alguns segmentos reconhecidos em cada playlist de mídia. Essa prática torna menos provável que um segmento seja pulado se uma playlist de mídia for perdida no lado do servidor. Por exemplo, é possível incluir até dois segmentos confirmados e até cinco segmentos pendentes em cada playlist de mídia.

  O servidor confirma o recebimento de um segmento de mídia retornando uma resposta 200 (OK) ou 202 (Accepted) no upload desse segmento. Uma resposta 202 indica que o servidor recebeu o segmento antes de uma playlist identificar esse segmento.

• Envie uma playlist de mídia atualizada para cada segmento de mídia para que o servidor possa se recuperar rapidamente se uma playlist de mídia for perdida.

• À medida que o servidor confirma o recebimento dos segmentos de mídia, é possível incrementar o valor da tag EXT-X-MEDIA-SEQUENCE para evitar que a playlist de mídia fique muito longa. Por exemplo, se o servidor já tiver confirmado o recebimento dos primeiros nove segmentos de mídia, a próxima lista de reprodução de mídia poderá listar os segmentos de mídia 8, 9 e 10.

• As tags EXT-X-KEY e EXT-X-SESSION-KEY não são compatíveis.

Exemplos

A lista a seguir mostra um exemplo dos arquivos que o codificador precisa enviar:

Media Playlist file with seqnum #0
Media Segment file #0
Media Playlist file with seqnum #0-#1
Media Segment file #1
Media Playlist file with seqnum #0-#2
Media Segment file #2
Media Playlist file with seqnum #1-#3
Media Segment file #3
...

O exemplo a seguir mostra uma playlist de mídia enviada no meio de uma transmissão de vídeo ao vivo. Como o exemplo é do meio de um stream, a tag EXT-X-MEDIA-SEQUENCE tem um valor diferente de zero.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:2680

#EXTINF:3.975,
fileSequence2680.ts
#EXTINF:3.941,
fileSequence2681.ts
#EXTINF:3.975,
fileSequence2682.ts

Segmentos de mídia

A lista a seguir identifica os requisitos para os segmentos de mídia:

• Nomes de arquivos
  • Os nomes de arquivo do segmento de mídia no URL precisam ter a extensão de nome de arquivo .ts e corresponder aos nomes de arquivo na playlist.
  • Os nomes dos arquivos de segmento de mídia precisam ser exclusivos em todas as reinicializações do codificador e reinícios de transmissão.
• Formato
  • Os segmentos de mídia precisam estar no formato M2TS e serem autoinicializados.
  • Cada segmento M2TS precisa conter um único programa MPEG-2.
  • O segmento M2TS precisa conter um PAT e um PMT, e os dois primeiros pacotes de stream de transporte em um segmento precisam ser um PAT e um PMT.
• Conteúdo
  • O vídeo e o áudio precisam ser mixados.
  • Os codecs de vídeo compatíveis são H.264 e HEVC.
  • O HDR com HEVC é compatível (consulte os requisitos de HDR).
  • A taxa de frames é compatível com até 60 fps.
  • Somente o GOP fechado é aceito.
  • O codec de áudio aceito é AAC, e apenas áudio de uma faixa é aceito.
  • Recomendamos que os segmentos de mídia tenham uma duração entre um e quatro segundos, conforme discutido na seção a seguir. Os segmentos de mídia não podem ter uma duração maior que 5 segundos.
  • Os segmentos de mídia só podem ser criptografados na camada TLS/SSL com HTTPS. Outros mecanismos de criptografia não são compatíveis.

Duração do segmento de mídia

Esperamos que a transferência HLS seja usada para conteúdo premium que exija alta qualidade e resolução. A ingestão de HLS geralmente tem latência maior do que as ingestão baseadas em RTMP e WebRTC, porque é baseada em segmentos.

Recomendamos uma duração de segmento de mídia de um a quatro segundos, porque ter segmentos de mídia menores pode resultar em latência mais baixa, embora a um custo de uma taxa de rebuffer mais alta e menor eficiência de codificação. Conforme observado na seção anterior, os segmentos de mídia não podem ter mais de 5 segundos.

Taxas de bits

A Central de Ajuda do YouTube oferece diretrizes para configurações de taxa de bits.

O HEVC geralmente gera de 25% a 50% mais compactação de dados com a mesma qualidade de vídeo em comparação com o H.264. Assim, os valores de bitrate na extremidade inferior dos intervalos sugeridos podem ser usados com HEVC para economizar largura de banda, o que é especialmente útil para conteúdo 4K.

Outros requisitos

• Os codificadores precisam definir o cabeçalho User-Agent na solicitação HTTP usando a sintaxe abaixo, que inclui o nome do fabricante, o nome do modelo e a versão:

  User-Agent: <manufacturer> / <model> / <version>
  

  Observação: essas informações serão usadas apenas para fins de depuração. Ele não será usado para decisões funcionais no processamento de fluxos.

Legendas ocultas

A transferência de HLS oferece suporte a duas opções para enviar legendas:

• Envie legendas descritivas usando solicitações POST HTTP separadas. Isso funciona para todas as ingestões HLS.
• As legendas ocultas 608/708 incorporadas funcionam com ingestões HLS que usam o codec de vídeo H264, mas não com as que usam o codec de vídeo HEVC. Para mais detalhes, consulte os Requisitos de legendas em tempo real na Central de Ajuda do YouTube.

Códigos de resposta HTTP

As seções a seguir explicam os códigos de resposta que o YouTube retorna em resposta aos segmentos de mídia e listas de reprodução de mídia entregues usando o HLS.

200 (OK)

Em resposta a uma solicitação PUT ou POST, uma resposta HTTP 200 (OK) indica que o servidor do YouTube recebeu uma operação esperada e a processou com sucesso.

Em resposta a uma solicitação DELETE, uma resposta HTTP 200 (OK) indica que o servidor do YouTube recebeu e ignorou a solicitação. O servidor do YouTube não exige que o cliente exclua nenhum recurso no stream e ignora solicitações DELETE. Por motivos de desempenho, o YouTube recomenda que os clientes não enviem DELETEs.

202 (Aceito)

Uma resposta HTTP 202 (Aceito) indica que o servidor do YouTube recebeu o segmento de mídia antes de receber uma playlist de mídia que contém esse segmento. Isso indica ao cliente que ele precisa enviar a playlist de mídia que contém esse segmento de mídia assim que possível para evitar um atraso no processamento dele. Isso não será um problema se o codificador enviar uma lista de reprodução de mídia atualizada para cada segmento de mídia.

400 (Solicitação inválida)

Uma resposta HTTP 400 (solicitação inválida) indica que um dos seguintes problemas ocorreu:

• O URL está incorreto
• A playlist não pode ser analisada ou contém tags sem suporte

401 (Não autorizado)

Uma resposta HTTP 401 (não autorizada) indica que o parâmetro cid no URL base do endpoint HLS do YouTube está corrompido ou expirado. O cliente precisa atualizar o parâmetro cid para continuar.

405 (método não permitido)

Uma resposta HTTP 405 (método não permitido) indica que a solicitação não era uma solicitação POST, PUT ou DELETE.

500 (erro interno do servidor)

Uma resposta HTTP 500 (erro interno do servidor) indica que o servidor não conseguiu processar a solicitação. Para esse erro, recomendamos que você tente novamente a solicitação com a espera exponencial.