A primeira parte:
Que? Un códec de vídeo é unha peza de software/hardware que comprime e/ou descomprime o vídeo dixital.
Para que? A pesar de certas limitacións tanto en canto a ancho de banda como
e en canto ao espazo de almacenamento de datos, o mercado esixe vídeo de calidade cada vez máis superior. Lembras como no último post calculamos o mínimo necesario para 30 fotogramas por segundo, 24 bits por píxel, cunha resolución de 480x240? Recibimos 82,944 Mbit/s sen compresión. A compresión é actualmente a única forma de transmitir en xeral HD/FullHD/4K ás pantallas de televisión e a Internet. Como se consegue isto? Agora vexamos brevemente os principais métodos.
A tradución realizouse co apoio de EDISON Software.Estamos comprometidos E .
Codec vs Container
Un erro común que cometen os novatos é confundir o códec de vídeo dixital e o contenedor de vídeo dixital. Un recipiente é un determinado formato. Un envoltorio que contén metadatos de vídeo (e posiblemente de audio). O vídeo comprimido pódese considerar como unha carga útil de contedores.
Normalmente, a extensión dun ficheiro de vídeo indica o tipo de contedor. Por exemplo, o ficheiro video.mp4 probablemente sexa un contedor MPEG-4 Parte 14, e un ficheiro chamado video.mkv é máis probable . Para estar completamente seguro do formato do códec e do contenedor, podes usar ou .
Un pouco de historia
Antes de chegar Como?, imos mergullo un pouco na historia para comprender un pouco mellor algúns códecs máis antigos.
Códec de vídeo H.261 apareceu en 1990 (tecnicamente - en 1988) e foi creado para operar a unha velocidade de transferencia de datos de 64 Kbps. Xa utilizaba ideas como submostraxe de cores, macrobloques, etc. O estándar de códec de vídeo publicouse en 1995 H.263, que se desenvolveu ata 2001.
A primeira versión foi completada en 2003 H.264 / AVC. Ese mesmo ano, TrueMotion lanzou o seu códec de vídeo con perdas gratuíto chamado VP3. Google comprou a empresa en 2008, lanzándoo VP8 o mesmo ano. En decembro de 2012, Google lanzou VP9, e é compatible con preto de ¾ do mercado de navegadores (incluídos os dispositivos móbiles).
AV1 é un novo códec de vídeo gratuíto e de código aberto desenvolvido por Alianza para os medios abertos (AOMedia), que inclúe as empresas máis famosas, como: Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel e Cisco. A primeira versión do códec, 0.1.0, publicouse o 7 de abril de 2016.
Nacemento de AV1
A principios de 2015, Google estaba a traballar VP10Xiph (que é propiedade de Mozilla) estaba traballando Daala, e Cisco fixo o seu propio códec de vídeo gratuíto chamado Thor.
Logo MPEG LA primeiros límites anuais anunciados para HEVC (H.265) e unha taxa 8 veces superior á de H.264, pero pronto cambiaron as regras de novo:
sen límite anual,
taxa de contido (0,5% dos ingresos) e
a tarifa unitaria é unhas 10 veces superior á H.264.
Alianza para os medios abertos foi creada por empresas de diferentes ámbitos: fabricantes de equipos (Intel, AMD, ARM, Nvidia, Cisco), provedores de contidos (Google, Netflix, Amazon), creadores de navegadores (Google, Mozilla) e outros.
As empresas tiñan un obxectivo común: un códec de vídeo sen dereitos de autor. Despois aparece AV1 cunha licenza de patente moito máis sinxela. Timothy B. Terryberry fixo unha presentación abraiante que se converteu na orixe do concepto AV1 actual e do seu modelo de licenza.
Sorprenderás saber que podes analizar o códec AV1 a través dun navegador (os interesados poden ir a).
Codec universal
Vexamos os principais mecanismos subxacentes ao códec de vídeo universal. A maioría destes conceptos son útiles e úsanse en códecs modernos como VP9, AV1 и HEVC. Advírtovos de que moitas das cousas explicadas simplificaranse. Ás veces empregaranse exemplos do mundo real (como con H.264) para demostrar as tecnoloxías.
1º paso - dividir a imaxe
O primeiro paso é dividir o cadro en varias seccións, subseccións e máis alá.
Para qué? Hai moitas razóns. Cando dividimos unha imaxe, podemos predecir con máis precisión o vector de movemento usando pequenas seccións para pequenas pezas móbiles. Mentres que para un fondo estático podes limitarte a seccións máis grandes.
Os códecs normalmente organizan estas seccións en seccións (ou anacos), macrobloques (ou bloques de árbores de codificación) e varias subseccións. O tamaño máximo destas particións varía, HEVC configúrao en 64x64 mentres que AVC usa 16x16 e as subparticións pódense dividir ata 4x4.
Lembras os tipos de cadros do último artigo?! O mesmo pódese aplicar aos bloques, polo que podemos ter un fragmento I, un bloque B, un macrobloque P, etc.
Para quen queira practicar, observe como se divide a imaxe en seccións e subseccións. Para iso, podes utilizar o xa mencionado no artigo anterior. (a que é de pago, pero cunha versión de proba gratuíta limitada aos 10 primeiros fotogramas). Seccións analizadas aquí VP9:
2º paso: previsión
Unha vez que teñamos seccións, podemos facer previsións astrolóxicas para elas. Para Previsións de INTER debe ser trasladado vectores de movemento e o resto, e para a predición INTRA transmítese dirección de previsión e o resto.
3º paso: transformación
Unha vez que temos un bloque residual (sección prevista → sección real), é posible transformalo de tal xeito que saibamos que píxeles se poden descartar mantendo a calidade xeral. Hai algunhas transformacións que proporcionan o comportamento exacto.
Aínda que hai outros métodos, vexámolos con máis detalle. transformada coseno discreta (DCT - de transformada coseno discreta). Funcións principais do DCT:
- Converte bloques de píxeles en bloques de igual tamaño de coeficientes de frecuencia.
- Condensa a potencia para axudar a eliminar a redundancia espacial.
- Ofrece reversibilidade.
2 de febreiro de 2017 Sintra R.J. (Cintra, RJ) e Bayer F.M. (Bayer FM) publicou un artigo sobre unha transformación tipo DCT para a compresión de imaxes que require só 14 adicións.
Non te preocupes se non entendes os beneficios de cada punto. Agora usemos exemplos específicos para ver o seu valor real.
Tomemos este bloque de 8x8 píxeles:
Este bloque represéntase na seguinte imaxe de 8 por 8 píxeles:
Aplica DCT a este bloque de píxeles e obtén un bloque de coeficientes de 8x8:
E se renderizamos este bloque de coeficientes, obteremos a seguinte imaxe:
Como podes ver, non se parece á imaxe orixinal. Podes ver que o primeiro coeficiente é moi diferente de todos os demais. Este primeiro coeficiente coñécese como coeficiente DC, que representa todas as mostras da matriz de entrada, algo así como unha media.
Este bloque de coeficientes ten unha propiedade interesante: separa os compoñentes de alta frecuencia dos de baixa frecuencia.
Nunha imaxe, a maior parte da potencia concéntrase en frecuencias máis baixas, polo que se convertes a imaxe nos seus compoñentes de frecuencia e descartas os coeficientes de frecuencia máis altos, podes reducir a cantidade de datos necesarios para describir a imaxe sen sacrificar demasiada calidade da imaxe.
A frecuencia refírese á rapidez con que cambia o sinal.
Intentemos aplicar os coñecementos adquiridos no caso de proba convertendo a imaxe orixinal á súa frecuencia (bloque de coeficientes) mediante DCT e despois descartando parte dos coeficientes menos importantes.
Primeiro convertémolo no dominio da frecuencia.
A continuación, descartamos parte (67%) dos coeficientes, principalmente a parte inferior dereita.
Por último, reconstruímos a imaxe a partir deste bloque de coeficientes descartado (lembra que debe ser invertible) e comparámola coa orixinal.
Vemos que se asemella á imaxe orixinal, pero hai moitas diferenzas coa orixinal. Tiramos un 67,1875% e aínda obtivemos algo parecido ao orixinal. Foi posible descartar máis coidadosamente os coeficientes para obter unha imaxe de mellor calidade aínda, pero ese é o seguinte tema.
Cada coeficiente xérase usando todos os píxeles
Importante: cada coeficiente non está directamente asignado a un píxel, senón que é unha suma ponderada de todos os píxeles. Este sorprendente gráfico mostra como se calculan os coeficientes primeiro e segundo utilizando pesos exclusivos de cada índice.
Tamén podes tentar visualizar o DCT mirando unha simple formación de imaxe baseada nel. Por exemplo, aquí está o símbolo A xerado usando cada peso coeficiente:
4º paso - cuantificación
Despois de botar algúns coeficientes no paso anterior, no último paso (transformación) realizamos unha forma especial de cuantización. Nesta fase é aceptable perder información. Ou, máis sinxelamente, cuantificaremos os coeficientes para conseguir a compresión.
Como se pode cuantificar un bloque de coeficientes? Un dos métodos máis sinxelos é a cuantificación uniforme, cando tomamos un bloque, dividilo por un valor (por 10) e redondea o resultado.
Podemos inverter este bloque de coeficientes? Si, podemos, multiplicando polo mesmo valor polo que dividimos.
Este enfoque non é o mellor porque non ten en conta a importancia de cada coeficiente. Poderíase usar unha matriz de cuantizadores en lugar dun valor único, e esta matriz podería explotar a propiedade DCT cuantificando a maioría da parte inferior dereita e a minoría da parte superior esquerda.
Paso 5: codificación de entropía
Unha vez cuantificados os datos (bloques de imaxes, fragmentos, fotogramas), aínda podemos comprimilos sen perdas. Hai moitas formas algorítmicas de comprimir datos. Imos botar unha ollada rápida a algúns deles, para unha comprensión máis profunda podes ler o libro Understanding Compression: Data Compression for Modern Developers ("").
Codificación de vídeo mediante VLC
Digamos que temos un fluxo de personaxes: a, e, r и t. Nesta táboa preséntase a probabilidade (de 0 a 1) da frecuencia con que aparece cada carácter nun fluxo.
| a | e | r | t | |
|---|---|---|---|---|
| Probabilidade | 0,3 | 0,3 | 0,2 | 0,2 |
Podemos asignar códigos binarios únicos (preferentemente pequenos) aos máis probables, e códigos máis grandes aos menos probables.
| a | e | r | t | |
|---|---|---|---|---|
| Probabilidade | 0,3 | 0,3 | 0,2 | 0,2 |
| Código binario | 0 | 10 | 110 | 1110 |
Comprimimos o fluxo, asumindo que acabaremos gastando 8 bits por cada personaxe. Sen compresión, serían necesarios 24 bits por carácter. Se substitúes cada carácter polo seu código, conseguirás aforros.
O primeiro paso é codificar o carácter e, que é igual a 10, e o segundo carácter é a, que se engade (non de xeito matemático): [10][0], e finalmente o terceiro carácter t, o que fai que o noso fluxo de bits comprimido final sexa igual a [10][0][1110] ou 1001110, que require só 7 bits (3,4 veces menos espazo que o orixinal).
Ten en conta que cada código debe ser un código único cun prefixo. axudarache a atopar estes números. Aínda que este método non está exento de defectos, hai códecs de vídeo que aínda ofrecen este método algorítmico para a compresión.
Tanto o codificador como o descodificador deben ter acceso a unha táboa de símbolos cos seus códigos binarios. Polo tanto, tamén é necesario enviar unha táboa como entrada.
Codificación aritmética
Digamos que temos un fluxo de personaxes: a, e, r, s и t, e a súa probabilidade preséntase nesta táboa.
| a | e | r | s | t | |
|---|---|---|---|---|---|
| Probabilidade | 0,3 | 0,3 | 0,15 | 0,05 | 0,2 |
Usando esta táboa, imos construír intervalos que conteñan todos os caracteres posibles, ordenados polo número máis grande.
Agora imos codificar un fluxo de tres caracteres: comer.
Primeiro seleccione o primeiro carácter e, que está no subintervalo de 0,3 a 0,6 (sen incluír). Collemos este subrango e dividímolo de novo nas mesmas proporcións que antes, pero para este novo intervalo.
Continuemos codificando o noso fluxo comer. Agora toma o segundo personaxe a, que está no novo subintervalo de 0,3 a 0,39, e despois toma o noso último carácter t e repetindo de novo o mesmo proceso, obtemos o subintervalo final de 0,354 a 0,372.
Só necesitamos seleccionar un número no último subrango de 0,354 a 0,372. Escollemos 0,36 (pero podes escoller calquera outro número neste subintervalo). Só con este número poderemos restaurar a nosa emisión orixinal. É coma se estivésemos debuxando unha liña dentro dos intervalos para codificar o noso fluxo.
A operación inversa (é dicir, decodificación) é igual de sinxelo: co noso número 0,36 e o noso rango inicial, podemos executar o mesmo proceso. Pero agora, usando este número, identificamos o fluxo codificado mediante este número.
Co primeiro rango, observamos que o noso número corresponde á porción, polo que este é o noso primeiro carácter. Agora dividimos de novo este subrango seguindo o mesmo proceso que antes. Aquí podes ver que 0,36 corresponde ao símbolo a, e despois de repetir o proceso chegamos ao último personaxe t (formando o noso fluxo codificado orixinal comer).
Tanto o codificador como o decodificador deben ter unha táboa de probabilidades de símbolos, polo que é necesario enviala tamén nos datos de entrada.
Bastante elegante, non? Quen se lle ocorreu con esta solución foi malditamente intelixente. Algúns códecs de vídeo usan esta técnica (ou polo menos ofrécena como opción).
A idea é comprimir sen perdas un fluxo de bits cuantizado. Seguramente a este artigo faltan toneladas de detalles, razóns, compromisos, etc. Pero se es un programador, deberías saber máis. Os novos códecs intentan usar diferentes algoritmos de codificación de entropía como ANS.
Paso 6: formato bitstream
Despois de facer todo isto, só queda desempaquetar os fotogramas comprimidos no contexto dos pasos realizados. O descodificador debe ser informado explícitamente das decisións tomadas polo codificador. O decodificador debe estar provisto de toda a información necesaria: profundidade de bits, espazo de cor, resolución, información de predición (vectores de movemento, predición INTER direccional), perfil, nivel, frecuencia de fotogramas, tipo de fotograma, número de fotograma e moito máis.
Botaremos unha ollada rápida ao bitstream H.264. O noso primeiro paso é crear un fluxo de bits H.264 mínimo (FFmpeg engade por defecto todas as opcións de codificación como SEI NAL - Descubriremos o que é un pouco máis adiante). Podemos facelo usando o noso propio repositorio e FFmpeg.
./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264
Este comando xerará un fluxo de bits en bruto H.264 cun cadro, resolución 64×64, con espazo de cor YUV420. Neste caso, a seguinte imaxe úsase como marco.
Fluxo de bits H.264
Estándar AVC (H.264) determina que a información se enviará en macroframes (no sentido de rede), chamados nal (este é un nivel de abstracción de rede). O obxectivo principal de NAL é proporcionar unha presentación de vídeo "amigable coa web". Este estándar debería funcionar en televisores (baseados en fluxo), Internet (baseados en paquetes).
Hai un marcador de sincronización para definir os límites dos elementos NAL. Cada token de sincronización contén un valor 0x00 0x00 0x01, agás o primeiro, que é igual a 0x00 0x00 0x00 0x01. Se lanzamos hexdump para o fluxo de bits H.264 xerado, identificamos polo menos tres patróns NAL ao comezo do ficheiro.
Como se dixo, o descodificador debe coñecer non só os datos da imaxe, senón tamén os detalles do vídeo, cadros, cores, parámetros utilizados e moito máis. O primeiro byte de cada NAL define a súa categoría e tipo.
| Identificador de tipo NAL | Descrición |
|---|---|
| 0 | Tipo descoñecido |
| 1 | Fragmento de imaxe codificado sen IDR |
| 2 | Sección de datos de corte codificado A |
| 3 | Sección de datos de corte codificado B |
| 4 | Sección de datos de corte codificado C |
| 5 | Fragmento IDR codificado dunha imaxe IDR |
| 6 | Máis información sobre a extensión SEI |
| 7 | Conxunto de parámetros de secuencia SPS |
| 8 | Conxunto de parámetros de imaxe PPS |
| 9 | Separador de acceso |
| 10 | Fin da secuencia |
| 11 | Fin do fío |
| ... | ... |
Normalmente o primeiro NAL dun fluxo de bits é PLC. Este tipo de NAL encárgase de informar sobre variables de codificación comúns como perfil, nivel, resolución, etc.
Se saltamos o primeiro marcador de sincronización, podemos decodificar o primeiro byte para descubrir que tipo de NAL é o primeiro.
Por exemplo, o primeiro byte despois do token de sincronización é 01100111, onde o primeiro bit (0) está no campo forbidden_zero_bit. 2 bits seguintes (11) dinos o campo nal_ref_idc, que indica se este NAL é un campo de referencia ou non. E os 5 bits restantes (00111) dinos o campo tipo_unidade_nal, neste caso é o bloque SPS (7) NAL.
Segundo byte (binario=01100100, feitizo=0x64, decembro=100) en SPS NAL é o campo profile_idc, que mostra o perfil que utilizou o codificador. Neste caso, utilizouse un perfil alto limitado (é dicir, un perfil alto sen soporte bidireccional do segmento B).
Se miras a especificación de bitstream H.264 para SPS NAL, atoparemos moitos valores para o nome do parámetro, a categoría e a descrición. Por exemplo, vexamos os campos pic_width_in_mbs_minus_1 и pic_height_in_map_units_minus_1.
| Nome do parámetro | categoría | Descrición |
|---|---|---|
| pic_width_in_mbs_minus_1 | 0 | ue (v) |
| pic_height_in_map_units_minus_1 | 0 | ue (v) |
Se realizamos algunhas operacións matemáticas cos valores destes campos, obteremos resolución. Pódese representar 1920 x 1080 usando pic_width_in_mbs_minus_1 cun valor de 119 ((119 + 1) * macroblock_size = 120 * 16 = 1920). De novo, para aforrar espazo, en lugar de codificar 1920, fixémolo con 119.
Se seguimos comprobando o noso vídeo creado en forma binaria (por exemplo: xxd -b -c 11 v/minimal_yuv420.h264), entón podes ir ao último NAL, que é o propio cadro.
Aquí vemos os seus primeiros valores de 6 bytes: 01100101 10001000 10000100 00000000 00100001 11111111. Dado que se sabe que o primeiro byte indica o tipo NAL, neste caso (00101) é un fragmento IDR (5), e despois podes exploralo máis:
Usando a información da especificación, será posible decodificar o tipo de fragmento (tipo_porción) e número de cadro (cadro_num) entre outros campos importantes.
Para obter os valores dalgúns campos (ue(v), me(v), se(v) ou te(v)), necesitamos decodificar o fragmento usando un decodificador especial baseado en . Este método é moi eficiente para codificar valores variables, especialmente cando hai moitos valores predeterminados.
Os valores tipo_porción и cadro_num deste vídeo son 7 (fragmento I) e 0 (primeiro fotograma).
Un bit stream pódese pensar como un protocolo. Se queres saber máis sobre o bitstream, debes consultar a especificación ITU H.264. Aquí tes un diagrama macro que mostra onde están os datos da imaxe (YUV en forma comprimida).
Pódense examinar outros fluxos de bits, como VP9, H.265 (HEVC) ou mesmo o noso mellor bitstream AV1. Son todos semellantes? Non, pero unha vez que entendes polo menos un, é moito máis doado entender o resto.
Queres practicar? Explore o fluxo de bits H.264
Pode xerar un só fotograma de vídeo e utilizar MediaInfo para examinar o fluxo de bits H.264. De feito, nada impide sequera mirar o código fonte que analiza o fluxo de bits H.264 (AVC).
Para a práctica, pode usar Intel Video Pro Analyzer (xa dixen que o programa é de pago, pero hai unha versión de proba gratuíta cun límite de 10 fotogramas?).
Comentar
Teña en conta que moitos códecs modernos usan o mesmo modelo que acabamos de estudar. Aquí, imos dar un ollo ao diagrama de bloques do códec de vídeo Thor. Contén todos os pasos polos que pasamos. O obxectivo desta publicación é polo menos darche unha mellor comprensión das innovacións e da documentación nesta área.
Anteriormente, calculábase que serían necesarios 139 GB de espazo en disco para almacenar un ficheiro de vídeo dunha hora de duración con calidade de 720p e 30 fps. Se usas os métodos discutidos neste artigo (predicións internas e entre cadros, transformación, cuantización, codificación de entropía, etc.), entón podes conseguir (segundo o feito de que gastamos 0,031 bits por píxel) un vídeo dunha calidade bastante satisfactoria. , ocupando só 367,82 MB, non 139 GB de memoria.
Como logra H.265 mellor relación de compresión que H.264?
Agora que sabemos máis sobre como funcionan os códecs, é máis fácil entender como os códecs máis novos poden ofrecer resolucións máis altas con menos bits.
Se comparamos AVC и HEVC, paga a pena lembrar que esta é case sempre unha opción entre unha maior carga da CPU e relación de compresión.
HEVC ten máis opcións de sección (e subsección) que AVC, máis direccións de predición internas, codificación de entropía mellorada e moito máis. Todas estas melloras fixéronse H.265 capaz de comprimir un 50% máis que H.264.
A primeira parte:
Fonte: www.habr.com