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 ingestão de HLS é uma boa opção 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 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 pequena parte do stream, com duração entre um e quatro segundos. Cada playlist de mídia descreve como remontar os segmentos de mídia na ordem correta do stream.

Requisitos de formato de mídia

A ingestão de HLS do YouTube tem os seguintes requisitos para conteúdo de vídeo e áudio:

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

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

HDR

Os vídeos em High Dynamic Range (HDR) são compatíveis com o codec HEVC e têm os seguintes requisitos adicionais:

  • Os padrões de cores compatíveis são PQ e HLG de 10 bits com luminância não constante. Mais especificamente:
    • O formato de 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 de matriz precisam ser Rec. 2020 luminância não constante.
  • Valores de amostra de intervalo limitado (ou intervalo MPEG) e intervalo completo (ou intervalo JPEG) são aceitos. É importante que o intervalo seja definido de acordo com o intervalo de valores de amostra usado pelo conteúdo. É recomendável usar valores de amostra de intervalo limitado.

Como conseguir um URL de transferência com HLS

Como conseguir um URL de transmissão HLS da API do 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 ingestão principal, e o campo cdn.ingestionInfo.backupIngestionAddress especifica o URL de ingestão de backup. Para mais detalhes, consulte a documentação do recurso liveStreams.

Como conseguir um URL de ingestão HLS no YouTube Studio

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" com caracteres alfanuméricos e hífens. Essa chave secreta identifica o criador de conteúdo e a transmissão para o YouTube.

Você pode criar um URL HLS com base nessa chave de stream 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 aumentar a confiabilidade, transmita uma segunda cópia redundante da ingestão para este URL de backup:

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

Observe que o backup tem duas diferenças em relação ao URL principal: o nome do host e o parâmetro copy= foram alterados. A ingestão de backup precisa enviar um valor de parâmetro copy= diferente da ingestão principal para evitar corromper o fluxo.

Como preencher o URL de transferência com HLS

Os URLs obtidos usando qualquer um dos métodos são modelos incompletos. Cada um termina com um parâmetro de consulta file= vazio. Para formar o URL final, o codificador precisa anexar o nome de arquivo de uma lista de reprodução de mídia ou de um segmento de mídia ao final do URL, concluindo assim o parâmetro file=.

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

  • O codificador pode criar um nome de arquivo de lista de reprodução de mídia ou segmento de mídia com caracteres alfanuméricos, sublinhados, barras, hífens e pontos. Nenhum outro caractere é aceito.
  • O codificador não pode codificar o nome do arquivo por 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 listas de reprodução 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 principal. Como o YouTube transcodifica o 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. Por isso, o YouTube só aceita playlists de mídia para ingestão de HLS, e as playlists master são ignoradas. Uma playlist principal fornece um conjunto de fluxos de variantes, cada um descrevendo uma versão diferente do mesmo conteúdo.

O codificador precisa:

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

As seções a seguir contêm requisitos mais específicos para playlists 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 lista de reprodução de mídia informa ao servidor quais segmentos de mídia esperar e como ordená-los corretamente no fluxo remontado.

Requisitos

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

  • A primeira lista de reprodução de mídia enviada para um stream precisa começar com o número de sequência 0, e esse número precisa aumentar de forma monotônica.

  • 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 ter mais de cinco segmentos pendentes. Um segmento está pendente se o servidor não o recebeu ou não confirmou o recebimento dele.

    Além dos segmentos pendentes, inclua também alguns segmentos reconhecidos em cada playlist de mídia. Assim, é menos provável que um segmento seja ignorado se uma playlist de mídia for perdida no lado do servidor. Por exemplo, é possível incluir até dois segmentos confirmados e até cinco 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 que o identificava.

  • Envie uma playlist de mídia atualizada para todos os segmentos 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 aumentar 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 nove primeiros segmentos de mídia, a próxima lista de reprodução de mídia poderá listar o oitavo, nono e décimo segmentos de mídia.

  • 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 lista de reprodução 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 segmentos de mídia:

  • Nomes de arquivos
    • Os nomes de arquivo do segmento de mídia no URL precisam ter a extensão .ts e corresponder aos nomes de arquivo na playlist.
    • Os nomes dos arquivos de segmento de mídia precisam ser exclusivos em reinicializações do codificador e reinícios de stream.
  • Formato
    • Os segmentos de mídia precisam estar no formato M2TS e ser autoinicializados.
    • Cada segmento M2TS precisa conter um único programa MPEG-2.
    • O segmento M2TS precisa conter uma PAT e uma PMT, e os dois primeiros pacotes de stream de transporte em um segmento precisam ser uma PAT e uma 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).
    • São aceitas taxas de até 60 fps.
    • Somente GOP fechado é aceito.
    • O codec de áudio compatível é AAC, e apenas áudio de faixa única é compatível.
    • 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 ingestão de HLS seja usada para conteúdo premium que exige alta qualidade e alta resolução. A ingestão de HLS geralmente tem latência maior do que as ingestões 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 menores pode resultar em latência mais baixa, embora com um custo de taxa de rebuffer mais alta e eficiência de codificação mais baixa. Como observado na seção anterior, os segmentos de mídia não podem ter mais de cinco 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 taxa de bits 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 seguinte sintaxe, que inclui o nome do fabricante, o nome do modelo e a versão:

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

Closed captions

A ingestão de HLS oferece duas opções para envio de legendas descritivas:

  • Envie legendas descritivas usando solicitações HTTP POST separadas. Isso funciona para todas as transmissõ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 ingestões que usam o codec de vídeo HEVC. Para mais detalhes, consulte os requisitos de legendas instantâneas 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 a segmentos de mídia e playlists de mídia entregues usando 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 de exclusão. Por motivos de desempenho, o YouTube recomenda que os clientes não enviem comandos DELETE.

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 o contenha. Isso indica ao cliente que ele precisa enviar a lista de reprodução de mídia contendo esse segmento de mídia o mais rápido 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
  • Não é possível analisar a playlist ou ela contém tags sem suporte
401 (Não autorizado)

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

405 (Método não permitido)

Uma resposta HTTP 405 (Method Not Allowed) indica que a solicitação não era 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 de novo com espera exponencial.