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 queiram adicionar suporte para ingestão de HLS aos produtos deles. HLS é uma boa opção para conteúdo premium que requer alta alta qualidade e alta resolução a uma latência relativamente maior. Resumo comparação dos diferentes protocolos de processamento do YouTube ao vivo Suporte para streaming, veja Comparação do protocolo de transferência de transmissão ao vivo do YouTube.

Para transmitir dados ao vivo usando HLS, o codificador precisa enviar uma série de Playlists e segmentos de mídia para o endpoint HLS do YouTube usando HTTP PUT ou POST solicitações. 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 por um breve trecho que dura de um a quatro segundos. Cada playlist de mídia descreve como recriar os segmentos de mídia na ordem correta do stream.

Requisitos de formato de mídia

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

  • 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 suportados até 60 fps.
  • Só há suporte para GOP fechado.
  • O codec de áudio compatível é o AAC, e apenas o áudio de faixa única é compatível.

Veja 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 a 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 Chroma 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 conhecido como ARIB STD-B67).
    • As cores primárias precisam ser Rec. de 2020.
    • Os coeficientes da matriz devem ser Rec. 2020 luminância não constante.
  • Amostras de alcance limitado (ou MPEG-range) e de alcance completo (ou JPEG-range) são aceitos. É importante que o intervalo seja definido de acordo com o o intervalo de valor de amostra usado pelo conteúdo. Valores de amostra de intervalo limitado são recomendado.

Como conseguir um URL de ingestão de HLS

Conseguir um URL de transferência de HLS com a API do YouTube

Para obter o URL de processamento completo, os codificadores podem usar o YouTube Live Streaming API para inserir uma transmissão ao vivo recurso com os seguintes propriedades:

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

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

Encontrar um URL de transferência de HLS no YouTube Creator Studio

Na interface da Web do YouTube Estúdio de Criação, depois que o criador de conteúdo clicar em "Criar Stream", o YouTube exibe uma "Chave de transmissão" compostos por caracteres alfanuméricos caracteres e hifens. Essa chave secreta identifica o criador transmitir no YouTube.

É possível construir um URL HLS 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 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 maior confiabilidade, é possível transmitir uma segunda cópia redundante do arquivo 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= mudou. A ingestão de backup precisa enviar um valor de parâmetro copy= diferente da ingestão principal para evitar corrompendo o stream.

Como preencher o URL de ingestão de HLS

Os URLs obtidos por meio de qualquer um dos métodos são modelos incompletos. cada uma termina com um parâmetro de consulta file= vazio. Para formar o URL final, o codificador precisa anexar o nome do arquivo de uma lista de reprodução de mídia ou segmento de mídia ao final do URL, completando assim 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 de mídia ou segmento de mídia a partir de caracteres alfanuméricos, sublinhados, barras, hifens e pontos; nenhum outro caractere é aceito.
  • O codificador não deve codificar para URL o nome do arquivo.
  • 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 deve fazer referência ao mesmo caminho no entrada de lista de reprodução correspondente.

Requisitos do protocolo HLS

As listas de reprodução de mídia e os segmentos de mídia enviados pelo codificador devem estar de acordo com a HTTP Live Streaming 2a edição Especificação.

A especificação HLS define dois tipos de playlist: playlist de mídia e principal. Lista de reprodução. Como o YouTube transcodifica o conteúdo transmitido para diferentes resoluções, taxas de bits diferentes, o codificador não precisa enviar conteúdo com taxas de bits diferentes para YouTube Como resultado, o YouTube só é compatível com playlists de mídia para transferência de HLS, e as playlists principais serão ignoradas. Uma playlist master fornece um conjunto de streams, 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 deseja são exibidos aos usuários (resolução e codec únicos).
  • áudio e vídeo mux.
  • usar HTTPS e uma conexão permanente 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 representam um fluxo 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 adequadamente no fluxo 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 uma transmissão precisa começar no número de sequência 0 e o número da sequência precisam aumentar monotonicamente.

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

  • Uma playlist de mídia não pode conter mais de cinco segmentos pendentes. Um O segmento ficará pendente se o servidor não o tiver recebido ou confirmado. para recebê-lo.

    Além dos segmentos pendentes, inclua também alguns nomes reconhecidos em cada playlist de mídia. Essa prática diminui a probabilidade a ser ignorado se uma playlist de mídia for perdida no lado do servidor. Para por exemplo, é possível incluir até dois segmentos reconhecidos e até cinco segmentos pendentes em cada playlist de mídia.

    O servidor confirma o recebimento de um segmento de mídia retornando um Resposta 200 (OK) ou 202 (Accepted) no upload desse trecho. Um A resposta 202 indica que o servidor recebeu o segmento antes de um playlist que identifique o segmento.

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

  • À medida que o servidor confirma o recebimento de segmentos de mídia, você pode incrementar o Valor de tag EXT-X-MEDIA-SEQUENCE para impedir que a playlist de mídia se torne muito longo. Por exemplo, se o servidor já tiver confirmado o recebimento do primeiros nove segmentos de mídia, a próxima playlist de mídia pode listar o oitavo, nono e décimo segmento 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 deve 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 vídeo ao vivo riacho. Como o exemplo é do meio de um fluxo, a 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 arquivo
    • Os nomes dos arquivos de segmento de mídia no URL precisam ter o nome .ts. e devem corresponder aos nomes de arquivo na lista de reprodução.
    • Os nomes dos arquivos de segmento de mídia devem ser únicos nas reinicializações do codificador e reinicializações do stream.
  • Formato
    • Os segmentos de mídia precisam estar no formato M2TS e ter inicialização automática.
    • Cada segmento M2TS precisa conter um único programa MPEG-2.
    • O segmento M2TS precisa conter um PAT e um PMT, e os dois primeiros Os pacotes do Stream de transporte em um segmento devem 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.
    • É compatível com HDR com HEVC. Consulte os requisitos de HDR.
    • São suportados até 60 fps.
    • Só há suporte para GOP fechado.
    • O codec de áudio compatível é o AAC, e apenas o áudio de faixa única é suporte.
    • É recomendável que os segmentos de mídia tenham uma duração entre um e quatro em segundos, conforme discutido na seção a seguir. Os segmentos de mídia não podem tenham duração superior a 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 requer alta alta qualidade e alta resolução. A ingestão de HLS geralmente tem uma latência maior do que a do RTMP- e as ingestão baseadas em WebRTC porque a ingestão de HLS é baseada em segmento.

Recomendamos uma duração de segmento de mídia de um a quatro segundos porque ter Segmentos de mídia menores podem resultar em menor latência, embora a um custo maior taxa de rebuffer e menor eficiência de codificação. Como mencionado na seção anterior, Os segmentos de mídia não podem ter mais de cinco segundos.

Taxas de bits

Ajuda do YouTube de Ajuda fornece diretrizes para configurações de taxa de bits.

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

Outros requisitos

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

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

Legendas ocultas

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

  • Envie legendas usando solicitações POST HTTP separadas. Isso funciona para todos Transferências de HLS.
  • As legendas 608/708 incorporadas funcionam com transferências de HLS que usam a linguagem H264. codec de vídeo, mas não com transferências que usam o codec de vídeo HEVC. Para mais detalhes, consulte os Requisitos de Legenda instantânea 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 se 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 exigem que o cliente EXCLUA qualquer recurso do fluxo e ignora DELETE. Por motivos de desempenho, o YouTube recomenda clientes não envie 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 contendo esse segmento de mídia. Isso indica ao cliente que ele deve 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 que um segmento de público-alvo. Isso não será um problema se o codificador enviar uma Playlist para cada segmento de mídia.

400 (Solicitação inválida)

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

  • O URL está incorreto
  • Não é possível analisar a playlist ou ela contém tags incompatíveis
401 (Não autorizado)

Uma resposta HTTP 401 (Não autorizado) indica que o parâmetro cid na o URL de base para o 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 (Método não permitido) indica que a solicitação foi não é uma solicitação POST, PUT ou DELETE.

500 (Erro interno do servidor)

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