A mágica do H.264 (2016)
(sidbala.com)- H.264, usado em vídeo na internet, Blu-ray, celulares, câmeras de segurança e drones, é um padrão de compressão de vídeo que evoluiu para transmitir vídeo em movimento total com uma largura de banda realista
- Um vídeo 1080p 60Hz sem compressão chega a cerca de 370MB/s com base em
1920×1080×60×3, o que significa que até mesmo um disco Blu-ray de 50GB mal consegue armazenar cerca de 2 minutos - O núcleo da compressão é a compressão com perdas, que reduz detalhes menos perceptíveis ao olho e diminui o volume de dados com transformação para o domínio da frequência, quantização e subamostragem de crominância
- A compressão temporal divide os quadros em I-frame, P-frame e B-frame, e reconstrói as mudanças usando vetores de movimento de macroblocos de 16×16 pixels em vez de restaurar o quadro inteiro
- No exemplo, um vídeo H.264 de 5 segundos a 60fps com 300 quadros tinha 175KB, enquanto uma única captura de tela em PNG tinha 1015KB, e o vídeo original de 1,2GB foi reduzido para 175KB
Os dados que o H.264 tenta reduzir
- H.264 é um padrão de codec de compressão de vídeo amplamente usado em vídeo na internet, Blu-ray, celulares, câmeras de segurança, drones e muito mais
- O objetivo é reduzir a largura de banda necessária para a transmissão de vídeo em movimento total
- Muitos dos conceitos abordados aqui se aplicam não só ao H.264, mas à compressão de vídeo em geral
Por que vídeo sem compressão é tão grande
- Um arquivo de vídeo simples sem compressão é um arranjo de buffers 2D contendo os dados de pixels de cada quadro, e pode ser visto como um arranjo 3D de bytes com duas dimensões espaciais e uma dimensão temporal
- Cada pixel usa 3 bytes para representar as três cores primárias: vermelho, verde e azul
- Um vídeo 1080p 60Hz gera cerca de 370MB/s de dados brutos pelo cálculo a seguir
1920 × 1080 × 60 × 3
- Nesse tamanho, um disco Blu-ray de 50GB comporta apenas cerca de 2 minutos, além de dificultar transporte e armazenamento
Um vídeo de 5 segundos menor que uma imagem PNG
- O exemplo da tela da homepage da Apple mostra de forma intuitiva o efeito da compressão H.264
- O vídeo de 5 segundos a 60fps tem 300 quadros, mas o tamanho do arquivo é cerca de um quinto de um único quadro em PNG
- Na aparência, o vídeo contém 300 vezes mais dados, mas é menor, então o H.264 parece muito mais eficiente que PNG
Informações descartadas pela compressão com perdas
- H.264 é um codec de compressão com perdas que descarta bits menos importantes e preserva apenas os mais importantes
- PNG é um codec de compressão sem perdas, então é possível recuperar bit a bit a imagem-fonte original a partir da imagem codificada
- O H.264 não reduz a imagem cortando partes ou descartando certos quadrantes; como outros algoritmos de imagem com perdas, ele reduz informações de detalhe
- Na imagem de exemplo, detalhes como os furos da grade do alto-falante do MacBook Pro desaparecem, mas sem ampliar é difícil perceber a diferença
- Só essa etapa já reduz a imagem para cerca de 7% do tamanho original
Entropia e remoção de redundância
- Entropia da informação é a quantidade de bits necessária para representar uma informação, e não é a mesma coisa que o tamanho bruto do conjunto de dados
- Dá para entender isso como o número mínimo de bits necessário para representar estados possíveis, como em resultados de lançamento de moeda
- Se uma moeda lançada 10 vezes cair cara em todas, em vez de escrever
HHHHHHHHHH, é possível representar isso de forma mais curta como “10 vezes, todas cara” - Esse processo não altera a informação em si; apenas reduz a forma de representação, removendo redundância
- Esse tipo de codificador sem perdas de propósito geral é chamado de codificador de entropia
Domínio da frequência e quantização
- Dados que variam no espaço ou no tempo podem ser convertidos para outro sistema de coordenadas, e valores de brilho de uma imagem também podem ser representados no domínio da frequência
- No domínio da frequência, os componentes de baixa frequência ficam mais perto do centro, e os de alta frequência, mais perto das bordas
- Padrões detalhados como uma grade fina em uma imagem correspondem a componentes de alta frequência, enquanto mudanças suaves de cor e brilho correspondem a componentes de baixa frequência
- Ao aplicar uma máscara nas bordas de uma imagem no domínio da frequência, é possível descartar informações de alta frequência; ao reconverter para o sistema x-y normal, obtém-se uma imagem parecida com a original, mas com menos detalhes
- Ao mudar o tamanho da máscara, também se ajusta o nível de detalhe da imagem de saída
- No exemplo, mesmo com a entropia da informação em apenas 2% da original, é difícil notar a diferença sem ampliar
- Na compressão com perdas, esse processo é chamado de quantização (quantization)
Subamostragem de crominância
- O olho humano e o cérebro detectam bem mudanças de brilho, mas distinguem com menos precisão pequenas diferenças de cor
- Em sinais de TV, os dados de cor RGB são convertidos para Y+Cb+Cr
Y: luminância, essencialmente o brilho em preto e brancoCb,Cr: crominância, ou seja, os componentes de cor
- RGB e YCbCr são equivalentes do ponto de vista da entropia da informação
- Na era da TV em preto e branco, existia apenas o sinal Y; quando a TV colorida surgiu, passou-se a codificar as informações de cor em Cb e Cr e transmiti-las junto com Y
- TVs em preto e branco usam apenas o componente Y, enquanto TVs coloridas usam também os componentes de crominância e os convertem internamente para RGB
- No H.264, o método usado é armazenar o componente Y em resolução total e os componentes C em um quarto da resolução
- A subamostragem de crominância descarta parte das informações de cor e reduz a largura de banda total pela metade, mantendo uma diferença visual pequena
- Essa técnica não é exclusiva do H.264; ela é amplamente usada há décadas
Compensação de movimento e compressão temporal
- H.264 é um padrão de compressão com compensação de movimento
- Ele vai além da compressão espacial dentro de um único quadro e trata vários quadros juntos na dimensão temporal
- Em um vídeo como uma partida de tênis, em que a câmera está fixa e só a bola se move, não há necessidade de armazenar o fundo inteiro a cada quadro
- Em geral, a imagem é dividida em macroblocos de 16×16 pixels, e o movimento é estimado nessa unidade
- Há três tipos principais de quadros
- I-frame: quadro que contém todos os bits necessários para compor o quadro inteiro
- P-frame: quadro preditivo que codifica os vetores de movimento de cada macrobloco a partir do quadro anterior
- B-frame: quadro preditivo bidirecional que faz previsão tanto a partir de quadros passados quanto futuros
- O decodificador começa no último I-frame e compõe o quadro atual somando os deltas dos vetores de movimento dos quadros seguintes
- No vídeo de exemplo da homepage da Apple, a compressão funciona muito bem porque ele é basicamente formado por três I-frames com macroblocos se deslocando
Por que há uma pausa rápida ao voltar o vídeo
- Em vídeos como os do YouTube, quando se volta alguns segundos, às vezes a reprodução não recomeça imediatamente e há uma pequena pausa; isso está relacionado à estrutura do H.264
- Quando o usuário salta para um quadro arbitrário, o decodificador precisa recalcular a partir do I-frame mais próximo
- Depois disso, ele precisa acumular os deltas dos vetores de movimento até o quadro desejado para montar o quadro atual, o que tem custo computacional
- Esse método é muito eficiente em espaço, mas exige processamento na decodificação
A etapa final de compressão sem perdas
- Mesmo nos I-frames após as etapas com perdas, ainda sobra informação redundante
- Os vetores de movimento dos macroblocos em P-frames e B-frames também podem formar grupos com valores idênticos
- Especialmente em vídeos de teste com panorâmica da tela, vários macroblocos se movem exatamente na mesma quantidade
- O codificador de entropia trata essa redundância
- Como o codificador de entropia é um codificador sem perdas de propósito geral, os dados de entrada podem ser recuperados
Taxa de compressão do exemplo
- O vídeo original do exemplo foi capturado em uma resolução atípica de
1232×1154 - Considerando 5 segundos a 60fps, o tamanho original é de cerca de 1,2GB pelo cálculo abaixo
1232 × 1154 × 60 × 3 × 5
- O vídeo H.264 comprimido tem 175KB
- Na analogia com carros usada no texto, isso equivale a reduzir um carro de 3000 libras para 0,4 libra, ou seja, 6,5 onças
- Essa explicação da taxa de compressão simplifica bastante décadas de pesquisa; mais detalhes podem ser vistos em H.264/MPEG-4 AVC Wikipedia Page
1 comentários
Opiniões no Hacker News
AV1 é um codec com licenciamento melhor e ainda mais mágico
A Meta está gradualmente levando streams VP9/AV1 a se tornarem a linha de base no streaming de vídeo: https://www.streamingmedia.com/Producer/Articles/Editorial/F...
Também está usando AV1 em chamadas de vídeo: https://engineering.fb.com/2024/03/20/video-engineering/mobi...
A Microsoft também começou a usar AV1 no Teams, e o AV1 tem ferramentas de codificação de vídeo especialmente úteis para compartilhamento de tela: https://techcommunity.microsoft.com/t5/microsoft-teams-blog/...
Hoje em dia, a maioria dos vídeos que vejo no YouTube está em VP9 ou AV1, e H.264 só aparece de vez em quando
H.264 ainda vai permanecer por bastante tempo, mas parece bem provável que o AV1 se torne a nova linha de base para vídeo na internet
Do ponto de vista de desenvolvedor, isso precisa estar acessível a todos, mas por enquanto estamos esperando esse recurso chegar à maioria dos usuários
Seria bom se mais usuários comprassem hardware com codificação/decodificação AV1, e parece que precisamos de um logotipo tipo “AV1 inside”
Por exemplo, na linha iPhone, por enquanto só o iPhone 15 Pro oferece decodificação por hardware
Eu precisava gravar vídeos de aulas e enviá-los como arquivos relativamente pequenos em 720p, mas eram vídeos de uma pessoa se movendo devagar diante de linhas finas e nítidas em uma lousa branca, com iluminação mais ou menos, então o perfil padrão de codificação do x264 não se ajustava bem
Mesmo assim, depois de um ou dois dias mexendo nas configurações, consegui fazer rodar durante a noite seguinte à aula em um notebook de cerca de 2014 com apenas uma iGPU, e subir o resultado no dia seguinte
Já o libaom dizia que levaria cerca de uma semana para renderizar um vídeo de 3 horas, e os padrões eram tão ruins que eu não tinha margem para experimentar
Isso foi há 4 anos, então deve ter melhorado, mas eu não esperaria milagres
Isso não é necessariamente um problema, mas o verdadeiro problema do AV1 é que a compressão exige cálculo demais
Ou talvez meus olhos tenham melhorado
Seria bom encontrar um texto que se aprofundasse nesse assunto
Textos relacionados:
H.264 is Magic (2016) - https://news.ycombinator.com/item?id=30710574 - março de 2022, 219 comentários
H.264 is magic (2016) - https://news.ycombinator.com/item?id=19997813 - maio de 2019, 180 comentários
H.264 is Magic – a technical walkthrough - https://news.ycombinator.com/item?id=17101627 - maio de 2018, 1 comentário
H.264 is Magic - https://news.ycombinator.com/item?id=12871403 - novembro de 2016, 219 comentários
Agora, 8 anos depois de aquele texto ter sido escrito, uma parte considerável das patentes do H.264 deve expirar em breve, em cerca de 1 a 2 anos: https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_M...
Isso não surpreende, considerando que a primeira versão do padrão H.264 saiu em 2003 e que patentes normalmente valem por 20 anos
A geração anterior, H.263 e MPEG-4 ASP, já teve suas patentes expiradas e está em domínio público
Então e o H.265? O número é um a mais, não é? https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
A codificação em H.265 exige computação extra demais em relação ao espaço que economiza
É algo como um arquivo que levaria 1 hora para reduzir para 1 GB com H.264 levar 12 horas para reduzir para 850 MB com H.265
Dependendo do uso, talvez você precise de qualquer forma de uma versão H.264, que tem suporte muito mais amplo nos clientes
Se você tiver recursos computacionais de nível datacenter, ou operar um serviço de streaming em que economizar 150 MB por vídeo se acumula, provavelmente entraria no H.265, mas em muitos casos práticos é difícil justificar
Ele fica quase no mesmo nível do VP9, mas por causa dos problemas de licenciamento ainda foi difícil ser adotado em todos os lugares
O VVC/H.266 parece sofrer do mesmo problema, e o AV1 é quase tão bom quanto e já está sendo adotado muito mais amplamente
Codecs mais modernos comprimem melhor, mas a complexidade cresce de forma não linear
O tamanho dos arquivos ficou muito menor do que em H.264
O padrão também é 10 anos mais novo que o H.264: H.264 é de 2003 e H.265 é de 2013
No exemplo “se você lançar uma moeda 10 vezes e todas derem cara, não precisa dizer HHHHHHHHHH; basta dizer ‘foram 10 lançamentos e todos deram cara’”, parece que há um pouco de compressão com perda nessa string de Hs
Lembro de quando o H.264 apareceu pela primeira vez
Na época eu estava viciado em mplayer e costumava baixar e compilar as versões mais recentes com frequência
Quando baixei meu primeiro arquivo H.264, o mplayer não conseguiu lê-lo, então tive que baixar e compilar a versão de desenvolvimento
Funcionou, e percebi duas coisas: a qualidade de imagem era impressionante, e meu Athlon 1800+ não dava conta
Depois disso, o desempenho melhorou muito em versões do mplayer ou do libavcodec, mas ainda me lembro daquele dia
Faz muito tempo que não uso mplayer, mas na época ele era o melhor
Antigamente trabalhei em uma empresa que desenvolvia produtos baseados em vídeo, e outra empresa de Las Vegas vendeu aos nossos executivos um “codec de vídeo inovador” e um player; para usá-los era preciso assinar um NDA
Quando testei, ele se comportava como o mplayer — igual até demais
Mais 5 minutos de investigação e a farsa foi descoberta, e os executivos que tinham pago uma fortuna àquela empresa passaram vergonha
Mesmo na área de tecnologia, é surpreendentemente fácil enganar tomadores de decisão não técnicos
Porque eles têm medo demais de ficar para trás
Pessoas inteligentes chamam bons engenheiros para avaliar; os alvos do efeito Dunning-Kruger entram na fila com a carteira na mão
Houve uma época em que eu estava prestes a sair de uma startup adquirida em 1999 e, na época, eu trabalhava com codificação MPEG
Uma das empresas onde fiz entrevista disse que tinha criado um novo método de compressão de vídeo e, depois de assinar um NDA, me mostrou um clipe curto codificado/decodificado com um codec de software não em tempo real
Eu estava sendo entrevistado para criar uma versão ASIC daquele algoritmo, mas bastou ver 1 ou 2 minutos da saída para eu ter uma ideia do que ele fazia
Achei que o exemplo tinha sido escolhido para favorecer os pontos fortes do algoritmo, então sugeri uma cena mais difícil e também expliquei o que eu achava que era a abordagem
Eles não confirmaram nem negaram, mas me chamaram para uma segunda entrevista
Na segunda, conversei com o casal de fundadores, CEO/CTO, e o plano deles não era vender ASICs, e sim manter o codec em segredo e usar o ASIC para construir uma rede de TV a cabo baseada em DSL para distribuição de vídeo
Eu disse: “parece que vocês inventaram um carburador melhor e querem construir uma fábrica de carros para competir com a GM”, e eles não receberam isso muito bem
O ponto em que essa história se conecta ao H.264 é que a alegação deles era: “a compressão existente chegou ao limite, então só o nosso codec consegue enviar vídeo de alta qualidade por uma linha DSL”
Eu respondi que compressores continuariam melhorando e que, mesmo que isso não acontecesse, quando uma internet mais rápida chegasse às casas, o próprio limiar que eles achavam que conseguiriam superar desapareceria
Eles disseram que, pelas leis da física, havia um limite para a taxa de bits que podia ser enviada por um fio e que esse limite já tinha sido atingido
Não recebi uma proposta de emprego, e também não queria uma
A empresa recebeu dinheiro de VC, mas fechou alguns anos depois; outras pessoas criaram codecs muito mais eficientes, e uma conexão de internet de 2 Mbps não era o limite
O algoritmo real provavelmente tinha muita matemática inteligente e força algorítmica, então eles não eram idiotas tecnicamente; faltava-lhes senso de negócios
Recontado assim, pareço um sabe-tudo arrogante, mas foi uma das duas vezes na minha vida em que vi algo e, em poucos segundos, entendi qual era o molho secreto
Os exemplos em que fui idiota são muito mais numerosos
Nunca tive confirmação sobre o algoritmo, mas pelos artefatos de silhueta ele parecia bastante evidente
MPEG, como JPEG, comprime imagens em pequenos blocos (8x8, 16x16 etc.), o que limita o alcance em que a redundância espacial é aproveitada, mas também limita o custo computacional de encontrar essa redundância
O codec deles parecia semelhante ao que a Microsoft havia proposto no fim dos anos 1990 para a arquitetura gráfica Talisman
Em vez de dividir em blocos fixos, parecia analisar sequências de frames para encontrar regiões estruturalmente coerentes com fronteiras semi-arbitrárias
Por exemplo, em uma partida de tênis, o fundo é razoavelmente próximo de um “corpo rígido”: se a câmera faz uma panorâmica e um pixel se move, é provável que os pixels ao redor sofram a mesma transformação espacial
O jogador muda de um frame para outro, mas aquele agrupamento tem correlações de iluminação e posição
Depois de identificar essas regiões, eles provavelmente comprimiam a imagem daquela região de forma parecida com JPEG e, no frame seguinte, analisavam como uma região sofria uma transformação afim, ou uma transformação mais geral, para o próximo frame, codificando isso com alguns parâmetros
Isso se torna a base da previsão do próximo frame e, se encaixar bem, não são necessários muitos bits para corrigir o erro de previsão
Dizem que receberam US$ 32 milhões de VCs e saíram do modo stealth em 2002
Não consegui encontrar o que aconteceu depois
O texto é muito legal, mas usar a expressão Information Entropy como se fosse um termo separado está entre os exemplos mais irritantes do tipo “ATM machine”
O texto em si é bom, mas a expressão é realmente forte
Em 02016, H.264 era uma mágica amarrada por patentes em vários países
Hoje, o padrão foi publicado em agosto de 02004, após um ano de trabalho aberto de padronização; patentes duram apenas 20 anos a partir da data de depósito; e não é possível patentear o que já foi divulgado, então a maioria já expirou ou vai expirar em poucos meses
Nos EUA há um período de carência de 1 ano quando a divulgação é feita pelo próprio autor, mas, se houver uma exceção, eu realmente gostaria de saber
userbinator apontou para https://meta.m.wikimedia.org/wiki/Have_the_patents_for_H.264..., mas a maioria das patentes ali tem datas de prioridade posteriores à finalização do padrão H.264, então não pode ser essencial para implementar o próprio H.264
A menos que alguém argumente que, na época da padronização, não se sabia que a implementação era possível; mas isso é bem pouco convincente
O surpreendente é que, nos últimos 20 anos, surgiram coisas que podem ser consideradas um pouco melhores, mas, pelos meus testes com implementações do ffmpeg, nada foi muito melhor
Se o status livre de patentes ficar garantido, parece bem provável que, goste-se ou não, o H.264 se consolide ainda mais como codec padrão por algum tempo
AV1 tem qualidade visual um pouco melhor na mesma largura de banda, mas é muito mais lento e vulnerável até a patentes depositadas tão tarde quanto 02018
“Como você mandou o decodificador pular para um frame arbitrário, ele precisa começar pelo I-frame mais próximo e refazer o cálculo de somar os deltas dos vetores de movimento até o frame atual, então dá uma travadinha” é coisa de 2016
Hoje em dia é porque o YouTube sabe que você está usando Firefox