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 de um codificador. Ele é 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 de streaming com suporte do YouTube ao vivo, consulte Comparação de protocolos de ingestão de streaming do YouTube ao vivo.

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 de HLS do YouTube usando solicitações HTTP PUT ou POST. Do ponto de vista do codificador, o endpoint de 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 da transmissão, com duração entre um e quatro segundos. Cada playlist de mídia descreve como remontar os segmentos de mídia na ordem correta da transmissão.

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 com suporte são H.264 e HEVC.
  • Há suporte para taxas de frames de até 60 fps.
  • Somente GOPs fechados são aceitos.
  • O codec de áudio com suporte é AAC, e apenas áudio de faixa única é aceito.

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

HDR

O vídeo em High Dynamic Range (HDR) tem suporte usando o codec HEVC e tem os seguintes requisitos adicionais:

  • Os padrões de cores com suporte 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.
  • Há suporte para valores de amostra de intervalo limitado (ou intervalo MPEG) e de intervalo completo (ou intervalo JPEG). É importante que o intervalo seja definido de acordo com o intervalo de valores de amostra usado pelo conteúdo. Recomendamos valores de amostra de intervalo limitado.

Como conseguir um URL de ingestão de HLS

Como conseguir um URL de ingestão de HLS na API YouTube

Para conseguir o URL de ingestão completo, os codificadores podem usar a API YouTube ao vivo 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 para o liveStreams recurso.

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

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

É possível criar um URL de HLS com essa 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 da transmissão mostrada 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, você pode transmitir 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=

O backup tem duas diferenças do URL principal: o nome do host e o parâmetro copy= mudaram. A ingestão de backup precisa enviar um valor de parâmetro copy= diferente da ingestão principal para evitar corromper a transmissão.

Como concluir o URL de ingestão de 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 do arquivo de uma playlist de mídia ou segmento 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 criar um nome de arquivo de playlist 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 relativos ou absolutos em nomes de arquivos, embora isso nunca seja 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 da segunda edição do HTTP Live Streaming.

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. Como resultado, o YouTube só oferece suporte a playlists de mídia para ingestão de HLS, e as playlists master são ignoradas. Uma playlist master fornece um conjunto de streams de variantes, cada um dos quais descreve uma versão diferente do mesmo conteúdo.

O codificador precisa:

  • enviar exatamente um stream codificado com a maior resolução que você quer veicular para os usuários (resolução e codec únicos).
  • mixar á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 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 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 é pendente se o servidor não o tiver recebido ou reconhecido o recebimento.

    Além dos segmentos pendentes, inclua também alguns segmentos reconhecidos em cada playlist de mídia. Essa prática reduz a probabilidade de um segmento ser ignorado se uma playlist de mídia for perdida no lado do servidor. Por exemplo, você pode incluir até dois segmentos reconhecidos e até cinco segmentos pendentes em cada playlist de mídia.

    O servidor reconhece 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 identifica.

  • 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 reconhece o recebimento de segmentos de mídia, você pode 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 reconhecido o recebimento dos nove primeiros segmentos de mídia, a próxima playlist de mídia poderá listar o oitavo, o nono e o décimo segmentos de mídia.

  • As tags EXT-X-KEY e EXT-X-SESSION-KEY não são aceitas.

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 um stream 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 arquivos de segmentos de mídia no URL precisam ter a extensão de nome de arquivo .ts e corresponder aos nomes de arquivos na playlist.
    • Os nomes de arquivos de segmentos de mídia precisam ser exclusivos em reinicializações de codificadores e reinicializações de streams.
  • Formato
    • Os segmentos de mídia precisam estar no formato M2TS e ser auto inicializáveis.
    • 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 com suporte são H.264 e HEVC.
    • Há suporte para HDR com HEVC (consulte os requisitos de HDR).
    • Há suporte para taxas de frames de até 60 fps.
    • Somente GOPs fechados são aceitos.
    • O codec de áudio com suporte é AAC, e apenas áudio de faixa única é 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 aceitos.

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 ela é 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 menor, embora com um custo de taxa de rebuffer maior e eficiência de codificação menor. 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 produz de 25% a 50% mais compactação de dados na mesma qualidade do 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>

Legenda descritiva

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

  • Envie legendas descritivas usando solicitações POST HTTP separadas. Isso funciona para todas as ingestões de HLS.
  • As legendas ocultas incorporadas 608/708 funcionam com ingestões de 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 ao vivo 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 as 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 de mídia. Isso indica ao cliente que ele precisa enviar a playlist de mídia que contém esse segmento de mídia o mais rápido possível para evitar um atraso no processamento desse segmento. Isso não será um problema se o codificador enviar uma playlist 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 não aceitas
401 (Não autorizado)

Uma resposta HTTP 401 (Não autorizado) indica que o parâmetro cid no URL de base do endpoint de 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 espera exponencial.