O que é largura de banda de vídeo?

A largura de banda de vídeo é a capacidade de transferência da rede necessária ou consumida para entregar vídeo ao longo do tempo. A necessidade depende da taxa de bits da codificação, da sobrecarga do protocolo, dos fluxos simultâneos e da variação na taxa de transferência disponível.

O termo abrange duas grandezas diferentes, e confundi-las causa a maioria dos erros de planejamento. Uma é o que um fluxo exige: os bits por segundo de que uma versão precisa, ou seja, a taxa de bits do vídeo codificado somada à sobrecarga de áudio e do contêiner. A outra é o que uma conexão fornece: a taxa de transferência que a rede de um espectador consegue sustentar, que muda a cada momento. Os formatos de streaming publicam a primeira para que os players possam compará-la com sua própria medição da segunda. No HLS, cada variante da playlist multivariante (principal) contém um atributo obrigatório BANDWIDTH em bits por segundo, definido como a taxa de bits de pico dos segmentos, e um AVERAGE-BANDWIDTH opcional; ambos incluem a sobrecarga do contêiner, mas não a de HTTP, TCP ou IP. No MPEG-DASH, cada Representation contém um valor @bandwidth, que as diretrizes do DASH-IF explicam com um modelo de balde furado em conjunto com o tempo mínimo de buffer. Um player estima a taxa de transferência com base nos downloads recentes de segmentos e seleciona uma versão cuja taxa declarada cabe nessa estimativa. Para um operador, esses mesmos valores por fluxo, multiplicados pelo número de espectadores simultâneos, fornecem a taxa de transferência agregada de entrega na borda, e essa taxa multiplicada pelo tempo de exibição fornece o volume de entrega.

Qual número entra na playlist, a média ou o pico? No HLS, BANDWIDTH é o pico: para uma variante com uma única playlist de mídia, a maior taxa de bits de qualquer sequência contígua de segmentos cuja duração esteja entre 0,5 e 1,5 vezes a duração-alvo. AVERAGE-BANDWIDTH é o tamanho total dos segmentos dividido pela duração da playlist. Quando o áudio ou outras versões são empacotados separadamente, a RFC 8216 exige que cada valor seja a maior soma entre as combinações de versões que podem ser reproduzidas. Portanto, medir apenas a playlist de vídeo subestima o valor declarado da variante. Essas medições precisam de segmentos concluídos. Quando a playlist é publicada antes de todos os segmentos serem codificados, como em um evento ao vivo, a RFC orienta usar o valor de um período representativo de conteúdo semelhante codificado com as mesmas configurações. Ela também alerta que um valor impreciso pode causar interrupções na reprodução ou impedir que os clientes reproduzam a variante. Com codificação de taxa de bits variável, os dois valores divergem: para conteúdo sob demanda, a especificação de autoria da Apple orienta que o pico seja de no máximo 200% da média e exige que o pico medido varie no máximo 10% em relação ao BANDWIDTH declarado. A configuração de taxa de bits de vídeo de um codificador não corresponde a nenhum desses valores, porque os valores da playlist são calculados a partir dos segmentos empacotados e incluem áudio e sobrecarga do contêiner.
Quanto a taxa de transferência da conexão de um espectador precisa superar a taxa de bits de uma versão? Ela precisa superá-la pela margem de segurança do player, e não apenas igualá-la. O hls.js, por exemplo, documenta dois fatores padrão: sua verificação normal de seleção do nível atual ou de um nível inferior exige que 0,95 vezes sua estimativa de largura de banda exceda a taxa de bits do nível, e ele só sobe de nível quando 0,7 vezes a estimativa excede a taxa de bits do nível superior. Para um nível comparado a 5 Mbit/s, a condição para subir de nível é uma estimativa acima de cerca de 7,1 Mbit/s. A taxa de bits usada na comparação depende do buffer: por padrão, o código-fonte do hls.js usa AVERAGE-BANDWIDTH, quando a playlist o declara, enquanto houver pelo menos duas durações de segmento no buffer e não se esperar uma pausa para recarregá-lo, e BANDWIDTH nos demais casos. Ele também aplica verificações adicionais, como o tempo esperado para buscar um segmento. A estimativa é uma média móvel dos downloads recentes, por isso demora a acompanhar uma rede que acabou de se recuperar. Trate o resultado como uma condição sobre a estimativa do player, e não como uma velocidade de conexão garantida. Os fatores são os valores padrão das configurações abrBandWidthFactor e abrBandWidthUpFactor; outros players aplicam suas próprias regras, então confira o que você distribui.
Como estimar o volume de entrega para um público? Multiplique a taxa média de bits de cada versão pelo número de espectadores que a assistem para obter a taxa de transferência e, depois, pelo tempo de exibição para obter o volume; use os valores de pico para dimensionar a capacidade para rajadas. Por exemplo, 1.000 espectadores simultâneos de uma versão com média de 3 Mbit/s precisam de cerca de 3 Gbit/s de taxa de transferência na borda, o que equivale a aproximadamente 1,35 TB por hora. Esse valor descreve o que a borda envia aos espectadores. Ele não descreve o tráfego de origem, que depende de quantas requisições a CDN atende a partir do cache, e não inclui a sobrecarga de HTTP, TCP e IP, excluída das definições de taxa de bits do HLS. Os espectadores também se distribuem pelos níveis da escada de codificação, por isso a proporção de espectadores por versão obtida nas análises do player fornece um valor mais próximo do real do que presumir que todos assistem à versão do nível mais alto.
Qual deve ser a taxa de bits da versão na base da escada? Para iOS, a especificação de autoria HLS da Apple exige que uma playlist multivariante entregue por redes celulares contenha uma variante cujo pico de BANDWIDTH seja de 192 kbit/s ou menos. Inclua essa variante de fallback para espectadores que usam redes celulares em dispositivos iOS; a especificação não estabelece isso como regra geral para outras plataformas.

Estime a largura de banda total ao dimensionar a capacidade da CDN e construir uma escada de versões adaptativas. Versões com taxas superiores à taxa de transferência disponível para os espectadores causam interrupções na reprodução, enquanto taxas conservadoras demais reduzem a qualidade.

A Transloadit produz as versões e playlists que esses números descrevem. O Robot /video/encode codifica uma versão por Step, com as predefinições hls/ e dash/ em resoluções fixas, e o Robot /video/adaptive reúne esses Steps em uma saída HLS, MPEG-DASH ou CMAF e gera os arquivos de manifesto e playlist. Sua escada é, portanto, o conjunto de Steps do Robot /video/encode que você passa para /video/adaptive. Qualquer configuração de predefinição, incluindo a taxa de bits, pode ser substituída pelo parâmetro ffmpeg, e segment_duration no Robot /video/adaptive define a duração dos segmentos.

A tabela de predefinições lista as predefinições hls/ e dash/ como VBR, sem informar uma taxa de bits, e as páginas dos Robots não explicam como os atributos de largura de banda da playlist gerada são calculados. Inspecione a playlist gerada para consultar os valores declarados e confira esses valores com os tamanhos dos segmentos antes de usá-los em estimativas de capacidade.

Explore os recursos de entrega da Transloadit

O que é largura de banda de vídeo?

Como funciona a largura de banda de vídeo

Informações essenciais

Quando a largura de banda de vídeo é importante

Como a Transloadit ajuda com a largura de banda de vídeo

Fontes

Transforme conhecimento sobre mídia em um pipeline funcional