Este documento apresenta diretrizes para o uso do formato de entrega Dynamic Adaptive Streaming over HTTP (DASH) para transmitir dados ao vivo no YouTube usando um codificador. O objetivo é ajudar os fornecedores de codificadores a adicionar suporte para envio DASH aos produtos deles.
Noções básicas sobre o DASH
A lista abaixo lista alguns dos principais recursos e atributos do DASH:
- Com base em padrões abertos.
- Baseado em HTTP. Como resultado, o DASH é compatível com a infraestrutura de Internet e pode passar por firewalls.
- Oferece suporte a alta taxa de bits de transferência. O DASH é compatível com várias sessões HTTP simultâneas e entrega de segmentos não sequenciais, oferecendo maior resiliência do que protocolos que dependem de uma única conexão TCP.
- Entrega segura por HTTPS.
- Entrega sem perdas por HTTP e HTTPS.
- Agnóstico de codecs.
- Compatível com MP4 contendo H264 e AAC, bem como WebM contendo VP8/VP9 e Vorbis/Opus.
Especificações
- O DASH está descrito na norma ISO/IEC 23009-1:2014 Information Technology -- Dynamic Adaptive Streaming over HTTP (DASH).
- O WebM por DASH é descrito na especificação WebM DASH.
Requisitos
As subseções a seguir explicam os requisitos do uso do DASH para transmissões ao vivo no YouTube.
Tempo
O endpoint DASH do YouTube se comporta como um servidor HTTP passivo, gravando chamadas do método PUT enviadas por um codificador.
- O endpoint DASH é compatível com conexões TCP simultâneas. É possível reutilizar conexões de acordo com HTTP/1.1.
- Os segmentos MPD e de inicialização precisam ser inseridos até três segundos após o primeiro segmento de mídia. Recomendamos que você inclua o segmento de inicialização na MPD.
- Cada segmento ou MPD precisa usar uma solicitação PUT separada. o upload de várias partes de vários segmentos não é compatível.
- As operações PUT para segmentos de mídia podem se sobrepor no tempo para melhorar a largura de banda de upload.
- Os segmentos podem ser fornecidos em ordem não sequencial em um período de aproximadamente 3 segundos.
- Os segmentos de MPD e inicialização precisam ser atualizados pelo menos a cada 60 segundos com
availabilityStartTime
estartNumber
atualizados. Conforme observado acima, o segmento de inicialização pode ser incluído na MPD. Nesse caso, uma solicitação PUT pode atualizar ambos os segmentos.
Estrutura do URL
Seu codificador precisa formar URLs PUT anexando uma string ao URL base do endpoint do YouTube. Você precisa criar o endpoint de processamento do DASH usando a API YouTube Live Streaming.
Em seguida, o codificador pode receber o URL base do endpoint de forma programática com a API YouTube Live Streaming. O URL base também pode ser visto na interface de Eventos do YouTube ao vivo se você quiser fornecer o URL manualmente ao codificador.
A string anexada ao URL base pode conter o seguinte conjunto de caracteres ASCII:
- Letras minúsculas: a-z
- Letras maiúsculas: de A a Z
- Dígitos: 0 a 9
- Caracteres especiais: _ (sublinhado), - (hífen), . (ponto)
URLs da MPD
Além do requisito acima, o URL da MPD precisa terminar com .mpd
, permitindo que o servidor do YouTube identifique facilmente a MPD.Os URLs de outros segmentos não podem terminar com .mpd
.
URLs de segmento de mídia e inicialização
O URL do segmento de inicialização e todos os URLs de segmento de mídia precisarão terminar com .mp4
se os dados estiverem em um contêiner ISO BMFF ou com .webm
se os dados estiverem em um contêiner WebM.
Conteúdo da MPD
A MPD precisa ser completa e estar em conformidade com o padrão DASH. Ele precisa conter exatamente um de cada um dos elementos a seguir. Essa lista identifica os elementos exigidos especificamente pelo YouTube, e a norma DASH pode identificar outros elementos obrigatórios. Os elementos são representados usando a sintaxe XPath e são consistentes com o padrão DASH.
/mpd:MPD/attribute::type
/mpd:MPD/mpd:Period
/mpd:MPD/mpd:Period/mpd:AdaptationSet
/mpd:MPD/mpd:Period/mpd:AdaptationSet/attribute::mimeType (video/mp4 or video/webm)
/mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate
/mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::media
/mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::initialization
/mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::startNumber
Observe os seguintes requisitos para valores de elementos:
- O atributo
minimumUpdatePeriod
do elemento<MPD>
precisa ser definido como um valor igual ou menor que 60 segundos (PT60S
). - O atributo
media
do elemento<SegmentTemplate>
precisa especificar que os URLs de segmento de mídia são gerados usando$Number$
. O atributostartNumber
identifica o número que será atribuído ao primeiro segmento de mídia.
Tamanho do segmento de inicialização
O segmento de inicialização não pode ser maior que 100 KB. Normalmente, um segmento de inicialização é muito menor que isso. Se o segmento de inicialização estiver incluído na MPD, o URL data:
, que contém o segmento, não poderá ter mais de 100 KB.
Saída do codificador
O segmento de inicialização e os segmentos de mídia precisam constituir um fluxo de arquivos ISO BMFF ou WebM multiplexado com GOPs (grupos de imagens) fechados.
- O tamanho do GOP deve ser de cerca de dois segundos e inferior a oito segundos.
- O stream multiplexado precisa conter faixas de áudio e vídeo.
Práticas recomendadas adicionais
Criptografia
O YouTube aceita criptografia de stream por HTTPS. Recomendamos que você use esse recurso.
Segmentos de inicialização na MPD
Você pode representar o segmento de inicialização diretamente na MPD usando um URL data:
, de acordo com o RFC 2397 (link em inglês). Isso simplifica a configuração da transmissão e reduz a possibilidade de que o segmento de inicialização não corresponda ao restante da transmissão.
O XPath para esse elemento é:
/mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute:data
Durações do segmento de destino
Para um bom desempenho de processamento e uma boa compensação entre capacidade de processamento e latência, a duração dos segmentos de mídia precisa estar entre 1 e 5 segundos.É altamente recomendável que você comunique a duração desejada desses segmentos na MPD usando estes dois elementos:
/mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::duration
/mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::timescale
A duração calculada desses atributos precisa estar dentro de um fator de 2 de todas as durações reais de segmento ou o desempenho de streaming pode ser afetado.
A duração desejada para o processamento não é igual à duração do trecho da transmissão ao vivo produzida pelo YouTube. O YouTube transcodifica e divide novamente a entrada, e a duração desejada da saída depende da otimização da qualidade do streaming ou da latência.
Novas tentativas e espera exponencial
Todas as solicitações HTTP PUT devem ser executadas com um tempo limite, o que recomendamos configurar para um valor 500 milissegundos a mais do que a duração do segmento.
Uma solicitação PUT de segmento de mídia que falha, seja devido a tempo limite ou outros erros, corresponde a uma lacuna no stream de vídeo. Dessa forma, você deve repetir essas solicitações usando uma espera exponencial binária aleatória:
- Após uma falha, aguarde um período aleatório entre
[0 ... 100]
milissegundos e tente fazer a solicitação novamente. - Se a solicitação falhar de novo, aguarde um período aleatório entre
[0 ... 200]
milissegundos e tente enviar a solicitação novamente. - Se a solicitação falhar de novo, aguarde um período aleatório entre
[0 ... 400]
milissegundos e tente enviar a solicitação novamente. - etc.
Observe que falhas repetidas devem ser sinalizadas para o operador do codificador, porque elas correspondem a uma falha na transmissão.
Códigos de resposta HTTP
As seções a seguir explicam os códigos de resposta que o YouTube retorna em resposta a segmentos enviados pelo DASH.
200 (OK)
Uma resposta HTTP 200 (OK) indica que o servidor do YouTube recebeu uma operação esperada e a tratou com êxito.
202 (Aceito)
Uma resposta HTTP 202 (Aceito) para qualquer operação PUT ou POST indica que ela foi inesperada e aceita para processamento adiado. No entanto, a operação adiada pode ter êxito ou falhar. Portanto, a resposta não garante que o YouTube realmente conseguirá processar a operação.
Essa resposta ocorre com mais frequência quando um segmento é entregue de forma não sequencial. Normalmente, o YouTube pode processar corretamente o segmento aceito depois de receber os segmentos anteriores, e você não precisa reenviá-lo.
Por exemplo, o YouTube pode retornar uma resposta 202 em qualquer um dos seguintes casos:
- Um segmento de inicialização é recebido antes da MPD.
- Os segmentos de mídia são recebidos antes dos segmentos MPD e de inicialização.
- Um segmento de mídia é recebido antes de um segmento anterior, como o segmento 3 sendo recebido antes do segmento 2.
No entanto, uma resposta 202 também pode indicar que o identificador do item está incorreto caso o YouTube não consiga validar totalmente o identificador ao receber a solicitação POST ou PUT. Por exemplo, uma das vezes que isso ocorre é quando o YouTube recebe e aceita um segmento de inicialização antes de receber a MPD, mas esse segmento é inválido. Nesse caso, o YouTube aceita o segmento de inicialização, retorna um 202 e determina se o segmento é válido após o recebimento da MPD. Para evitar esse cenário específico, inclua o segmento de inicialização na MPD.
400 (Solicitação inválida)
Uma resposta HTTP 400 (Solicitação inválida) indica que ocorreu um dos seguintes problemas:
- O URL está incorreto.
- A postagem é muito grande (mais de 10 MB).
- Não é possível analisar a MPD.
- O segmento de inicialização na MPD está corrompido.
401 (Não autorizado)
Uma resposta HTTP 401 (não autorizado) indica que o URL base do endpoint DASH do YouTube está corrompido ou expirou.
405 (Método não permitido)
Uma resposta HTTP 405 (Método não permitido) indica que uma solicitação diferente de POST
ou PUT
foi enviada.
409 (Conflito)
Uma resposta HTTP 409 (Conflito) para qualquer operação PUT ou POST indica que o YouTube não pode processar a solicitação. Por exemplo, essa resposta poderá ocorrer se o solicitante tiver enviado vários segmentos de mídia, mas o YouTube ainda não tiver a MPD, o segmento de inicialização ou ambos. Nesse exemplo, o codificador precisaria retransmitir os segmentos MPD e de inicialização antes de tentar novamente a solicitação com falha.
500 (Erro interno do servidor)
Uma resposta HTTP 500 (Erro interno do servidor) indica que o servidor não pôde processar a solicitação. Para esse erro, recomendamos que você tente fazer a solicitação novamente com a espera exponencial.
Exemplos
Sequência de URLs
A sequência de URL abaixo mostra uma série de solicitações PUT que seriam feitas para enviar conteúdo via DASH. A sequência presume que o URL de base do endpoint DASH do YouTube é:
http://upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=
A sequência mostra os segmentos de MPD e de inicialização enviados separadamente. No entanto, o segmento de inicialização pode ser representado diretamente na MPD, e essa prática é recomendada. Além disso, os segmentos de MPD e inicialização precisam ser atualizados pelo menos a cada 60 segundos. Assim, com o tempo, os URLs desses segmentos ocorreriam novamente nessa sequência e seriam seguidos por URLs para mais segmentos de mídia.
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=dash.mpd PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=init.mp4 PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=media001.mp4 PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=media002.mp4 PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=media003.mp4 ...
Segmentos WebM
MPD com segmento de inicialização incorporado
O exemplo de MPD a seguir tem um segmento de inicialização incorporado em um URL de dados RFC 2397. Recomendamos que você incorpore o segmento "Inicialização" dessa maneira em vez de enviá-lo separadamente.
Este exemplo está em conformidade com a ingestão de WebM (VP8 ou VP9, Opus) para o YouTube. A maior parte do URL de dados foi ocultada para facilitar a leitura:
<?xml version="1.0" encoding="UTF-8"?> <MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mpeg:dash:schema:mpd:2011" xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" type="dynamic" profiles="urn:mpeg:dash:profile:isoff-live:2011" minimumUpdatePeriod="PT60S" minBufferTime="PT12S" availabilityStartTime="2016-04-13T20:52:58" > <Period start="PT0S" id="1"> <AdaptationSet mimeType="video/webm"> <ContentComponent contentType="video" id="1"/> <SegmentTemplate timescale="1000" duration="2000" startNumber="1" initialization="data:video/mp4;base64,AAAAGGZ0eXBpc...AAA" media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=media-$Number%09d$.webm"/> <Representation id="1" width="1920" height="1080"> <SubRepresentation contentComponent="1"/> </Representation> </AdaptationSet> </Period> </MPD>
MPD
O exemplo de MPD a seguir, que não tem um segmento de inicialização incorporado, também está em conformidade com a ingestão de WebM (VP8 ou VP9, Opus) no YouTube:
<?xml version="1.0" encoding="UTF-8"?> <MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mpeg:dash:schema:mpd:2011" xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" type="dynamic" profiles="urn:mpeg:dash:profile:isoff-live:2011" minimumUpdatePeriod="PT60S" minBufferTime="PT12S" availabilityStartTime="2016-04-13T20:52:58" > <Period start="PT0S" id="1"> <AdaptationSet mimeType="video/webm"> <ContentComponent contentType="video" id="1"/> <SegmentTemplate timescale="1000" duration="2000" startNumber="1" initialization="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=init.webm" media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=media-$Number%09d$.webm"/> <Representation id="1" width="1920" height="1080"> <SubRepresentation contentComponent="1"/> </Representation> </AdaptationSet> </Period> </MPD>
Inicialização
Veja a seguir o layout de um exemplo de segmento de inicialização de WebM. Ele consiste na parte do stream do WebM até o primeiro cluster, mas não inclui.
Mídia
Veja a seguir o layout de um exemplo de segmento de mídia WebM. Ele consiste em um único cluster WebM. Como acontece com um fluxo ISO BMFF, o segmento de inicialização anexado a uma série de clusters deve produzir um fluxo WebM válido.
Segmentos ISO BMFF
MPD com segmento de inicialização incorporado
O exemplo de MPD a seguir tem um segmento de inicialização incorporado em um URL de dados RFC 2397. Recomendamos que você incorpore o segmento "Inicialização" dessa maneira em vez de enviá-lo separadamente.
Este exemplo está em conformidade com o processamento do ISO BMFF (H.264, AAC) no YouTube. A maior parte do URL de dados foi ocultada para facilitar a leitura:
<?xml version="1.0" encoding="UTF-8"?> <MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mpeg:dash:schema:mpd:2011" xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" type="dynamic" minimumUpdatePeriod="PT30S" availabilityStartTime="2016-05-04T20:47:25" minBufferTime="PT12S" profiles="urn:mpeg:dash:profile:isoff-live:2011"> <Period start="PT0S" id="1"> <AdaptationSet mimeType="video/mp4" codecs="avc1.4d401e,mp4a.40.2"> <ContentComponent contentType="video" id="1"/> <ContentComponent contentType="audio" id="2"/> <SegmentTemplate timescale="600" media="/dash_upload?cid=ug50-xg26-cbc1-2p0h&staging=1©=0&file=media$Number%09d$.mp4" initialization="data:video/mp4;base64,AAAAGGZ0eXBpc281AA...AA" duration="306" startNumber="1"/> <Representation id="1" width="640" height="360" bandwidth="526952"> <SubRepresentation contentComponent="1" bandwidth="526952" codecs="avc1.4d401e"/> <SubRepresentation contentComponent="2" bandwidth="125584" codecs="mp4a.40.2"/> </Representation> </AdaptationSet> </Period> </MPD>
MPD
O exemplo de MPD a seguir, que não tem um segmento de inicialização incorporado, também está em conformidade com o processamento do ISO BMFF (H.264, AAC) para o YouTube:
<?xml version="1.0" encoding="UTF-8"?> <MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mpeg:dash:schema:mpd:2011" xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" type="dynamic" profiles="urn:mpeg:dash:profile:isoff-live:2011" minimumUpdatePeriod="PT60S" minBufferTime="PT12S" availabilityStartTime="2016-04-13T20:51:31" > <Period start="PT0S" id="1"> <AdaptationSet mimeType="video/mp4" codecs="avc1.4d401e,mp4a.40.2"> <ContentComponent contentType="video" id="1"/> <ContentComponent contentType="audio" id="2"/> <SegmentTemplate timescale="600" duration="1200" startNumber="1" initialization="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=init.mp4" media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx©=0&file=media$Number%09d$.mp4"/> <Representation id="1" width="640" height="360" bandwidth="526952"> <SubRepresentation contentComponent="1" bandwidth="526952" codecs="avc1.4d401e"/> <SubRepresentation contentComponent="2" bandwidth="125584" codecs="mp4a.40.2"/> </Representation> </AdaptationSet> </Period> </MPD>
Inicialização
O diagrama a seguir mostra o layout de um exemplo de segmento de inicialização ISO BMFF multiplexado. O YouTube não usa necessariamente os átomos, mas este é um exemplo em conformidade. Em particular, as faixas de áudio e vídeo são representadas.
Mídia
O diagrama a seguir mostra o layout de um exemplo de segmento de mídia ISO BMFF multiplexado. O YouTube não usa necessariamente todos os átomos, mas este é um exemplo em conformidade. Em particular, as faixas de áudio e vídeo são representadas. Uma série desses segmentos pode ser anexada a um Segmento de inicialização para produzir um fluxo ISO BMFF multiplexado válido e completo.
Limitações conhecidas
Transferências de RTMP e DASH
Não é possível misturar transferências de RTMP e DASH para o YouTube.Isso se aplica à alternância entre os dois durante uma transmissão, bem como ao uso de um como método de ingestão principal e o outro para transferência de backup.