Para efeito desta pergunta, baixei o vídeo em:
Ele foi baixado como "3Uyndrm.mp4", 4.762 kB
No Windows 11, usei File Explorer > Details para visualizar suas propriedades:
Nestes dados, Data rateé a taxa de bits do vídeo e
Total bitrate= ÁudioBit rate+ VídeoData rate
Isso é confirmado calculando o tamanho do arquivo a partir destes números:
File size = 1,765,000 bits/sec * 22 second / 8 / 1024 = 4,740 kB
Mas há algo que não entendo sobre esses números.
Podemos calcular o número de pixels por segundo no vídeo:
(854 * 480) pixels/frame * 30 frames/sec = 12,297,600 pixels/sec
A partir disso, podemos obter o número de bits de vídeo por pixel:
1,635,000 bits per sec / 12,297,600 pixels/sec / 8 = 0.017 byte/pixel
Isso faz sentido? Isso significa que os dados do vídeo são uma pequena fração de byte por pixel em cada quadro. Eu teria pensado que cada pixel exigiria pelo menos três bytes para seus valores de cores. Reduzir isso de 3 para 0,017 seria mais de 99% de compactação, que é maior do que qualquer taxa de compactação de que já ouvi falar.
Há algo errado com meu cálculo?
Dependendo do vídeo, eles podem ter um quadro principal que é essencialmente uma imagem compactada em formato com perdas semelhante a JPEG. Este é um arquivo
i-frameque contém dados de imagem reais.O JPEG já atinge algo na ordem de compressão 10:1 com perda mínima de qualidade; os codecs de vídeo mais recentes são provavelmente pelo menos tão bons.
Se os próximos quadros contiverem muitos dados muito semelhantes, mas uma pequena quantidade de movimento, você poderá simplesmente ter um pouco de dados que diz "mover essas áreas da imagem em x pixels" e então compactar apenas os novos dados reais da imagem que foram ' ainda não está na tela. Este é um
p-framequadro previsto com base em um quadro anterior.Se você tiver uma série de quadros sucessivos,
p-framespoderái-frameessencialmente eliminar uma série inteira de quadros. Você estaria reduzindo 8 quadros completos de dados para 1 único quadro compactado junto com uma pequena quantidade de dados fornecendo transformações e cálculos matemáticos.A 25 quadros por segundo, se você tiver um i-frame a cada oito quadros, poderá reduzir a quantidade de dados em uma quantidade muito significativa. Potencialmente, isso poderia reduzir os dados para algo em torno de 1/8, além de algumas novas partes da imagem.
Depois, há
b-framesquadros previstos bidirecionais. Estes podem olhar para o passadoi-frames, mas também podem olhar para o próximoi-frame. Se você sabe que há novos dados na próxima imagem completa, você pode usar esses dados para codificar ainda menos dados na imagem atualb-framee contar com uma imagemi-frameainda mais avançada.Esses quadros previstos podem reduzir enormemente a quantidade de dados codificados reais, mas ao custo do aumento do poder de processamento necessário para codificar e decodificar o vídeo. Você precisa de muito poder de processamento para olhar para frente e para trás na série de imagens e descobrir todas as semelhanças e diferenças e aplicar transformações, mesclagens, desfoques, movimentos e assim por diante.
Também custa o decodificador porque você precisa armazenar em buffer pelo menos dois
i-framespara recriar todos os quadros intermediários.Ao descarregar muitos dados em equações que detalham transformações e movimentos, você pode reduzir a taxa de bits muito, muito abaixo do esperado e obter taxas de compressão muito mais altas, especialmente para vídeo sem muito movimento ou mudanças entre os quadros.
O vídeo que você vinculou mostra alguns artefatos altamente compactados
i-framese tem muito pouco movimento. Poderia facilmente obter taxas de compressão muito altas.Você pode obter mais informações sobre os fundamentos do processo na Wikipedia: Tipos de imagens de compressão de vídeo