馃嚭馃嚫 馃嚚馃嚦 馃嚡馃嚨 馃嚠馃嚬 馃嚢馃嚪 馃嚪馃嚭 馃嚙馃嚪 馃嚜馃嚫
Esto es una breve introducci贸n a la tecnolog铆a de v铆deo, principalmente dirigido a desarrolladores o ingenieros de software. La intenci贸n es que sea f谩cil de aprender para cualquier persona. La idea naci贸 durante un breve taller para personas nuevas en v铆deo.
El objetivo es introducir algunos conceptos de v铆deo digital con un vocabulario simple, muchas figuras y ejemplos pr谩cticos en cuanto sea posible, y dejar disponible este conocimiento. Por favor, si茅ntete libre de enviar correcciones, sugerencias y mejoras.
Habr谩n pr谩cticas que requiere tener instalado docker y este repositorio clonado.
git clone https://github.com/leandromoreira/digital_video_introduction.git
cd digital_video_introduction
./setup.shADVERTENCIA: cuando observes el comando
./s/ffmpego./s/mediainfo, significa que estamos ejecutando la versi贸n contenerizada del mismo, que a su vez incluye todos los requerimientos necesarios.
Todas las pr谩cticas deber谩n ser ejecutadas desde el directorio donde has clonado este repositorio. Para ejecutar los ejemplos de jupyter deber谩s primero iniciar el servicio ./s/start_jupyter.sh, copiar la URL y pegarla en tu navegador.
- Detalles sobre sistemas DRM
- Versi贸n 1.0.0 liberada
- Traducci贸n a Chino Simplificado
- Ejemplo de FFmpeg oscilloscope filter
- Traducci贸n a Portugu茅s (Brasil)
- Traducci贸n a Espa帽ol
- Introducci贸n
- Tabla de contenidos
- Terminolog铆a B谩sica
- Eliminaci贸n de Redundancias
- 驴C贸mo funciona un c贸dec de v铆deo?
- Online streaming
- 驴C贸mo usar jupyter?
- Conferencias
- Referencias
Una imagen puede ser pensada como una matriz 2D. Si pensamos en colores, podemos extrapolar este concepto a que una imagen es una matriz 3D donde la dimensi贸n adicional es usada para indicar la informaci贸n de color.
Si elegimos representar esos colores usando los colores primarios (rojo, verde y azul), definimos tres planos: el primero para el rojo, el segundo para el verde, y el 煤ltimo para el azul.
Llamaremos a cada punto en esta matriz un p铆xel (del ingl茅s, picture element). Un p铆xel representa la intensidad (usualmente un valor num茅rico) de un color dado. Por ejemplo, un p铆xel rojo significa 0 de verde, 0 de azul y el m谩ximo de rojo. El p铆xel de color rosa puede formarse de la combinaci贸n de estos tres colores. Usando la representaci贸n num茅rica con un rango desde 0 a 255, el p铆xel rosa es definido como Rojo=255, Verde=192 y Azul=203.
Otros modelos pueden ser utilizados para representar los colores que forman una imagen. Por ejemplo, podemos usar una paleta indexada donde necesitaremos solamente un byte para representar cada p铆xel en vez de los 3 necesarios cuando usamos el modelo RGB. En un modelo como este, podemos utilizar una matriz 2D para representar nuestros colores, esto nos ayudar铆a a ahorrar memoria aunque tendr铆amos menos colores para representar.
Observemos la figura que se encuentra a continuaci贸n. La primer cara muestra todos los colores utilizados. Mientras las dem谩s muestran a intencidad de cada plano rojo, verde y azul (representado en escala de grises).
Podemos ver que el color rojo es el que contribuye m谩s (las partes m谩s brillantes en la segunda cara) mientras que en la cuarta cara observamos que el color azul su contribuci贸n se limita a los ojos de Mario y parte de su ropa. Tambi茅n podemos observar como todos los planos no contribuyen demasiado (partes oscuras) al bigote de Mario.
Cada intensidad de color requiere de una cantidad de bits para ser representada, esa cantidad es conocida como bit depth. Digamos que utilizamos 8 bits (aceptando valores entre 0 y 255) por color (plano), entonces tendremos una color depth (profundidad de color) de 24 bits (8 bits * 3 planos R/G/B), por lo que podemos inferir que tenemos disponibles 2^24 colores diferentes.
Es asombroso aprender como una imagen es capturada desde el Mundo a los bits.
Otra propiedad de una images es la resoluci贸n, que es el n煤mero de p铆xeles en una dimensi贸n. Frecuentemente es presentado como ancho 脳 alto (width 脳 height), por ejemplo, la siguiente imagen es 4脳4.
Puedes jugar con una imagen y colores usando jupyter (python, numpy, matplotlib, etc).
Tambi茅n puedes aprender c贸mo funcionan los filtros de im谩genes (edge detection, sharpen, blur...).
Trabajando con im谩genes o v铆deos, te encontrar谩s con otra propiedad llamada aspect ratio (relaci贸n de aspecto) que simplemente describe la relaci贸n proporcional que existe entre el ancho y alto de una imagen o p铆xel.
Cuando las personas dicen que una pel铆cula o imagen es 16x9 usualmente se est谩n refiriendo a la relaci贸n de aspecto de la pantalla (Display Aspect Ratio (DAR)), sin embargo podemos tener diferentes formas para cada p铆xel, a ello le llamamos relaci贸n de aspecto del p铆xel (Pixel Aspect Ratio (PAR)).
La resoluci贸n del formato de DVD es 704x480, igualmente mantiente una relaci贸n de aspecto (DAR) de 4:3 porque tiene PAR de 10:11 (704x10/480x11)
Finalmente, podemos definir a un v铆deo como una sucesi贸n de n fotogramas en el tiempo, la cual la podemos definir como otra dimensi贸n, n es el frame rate o fotogramas por segundo (FPS, del ingl茅s frames per second).
El n煤mero necesario de bits por segundo para mostrar un v铆deo es llamado bit rate.
bit rate = ancho * alto * bit depth * FPS
Por ejemplo, un v铆deo de 30 fotogramas por segundo, 24 bits por p铆xel, 480x240 de resoluci贸n necesitar铆a de 82,944,000 bits por segundo o 82.944 Mbps (30x480x240x24) si no queremos aplicar ning煤n tipo de compresi贸n.
Cuando el bit rate es casi constante es llamado bit rate constante (CBR, del ingl茅s constant bit rate), pero tambi茅n puede ser variable por lo que lo llamaremos bit rate variable (VBR, del ingl茅s variable bit rate).
La siguiente gr谩fica muestra como utilizando VBR no se necesita gastar demasiados bits para un fotograma es negro.
En otros tiempos, unos ingenieros idearon una t茅cnica para duplicar la cantidad de fotogramas por segundo percividos en una pantalla sin consumir ancho de banda adicional. Esta t茅cnica es conocida como v铆deo entrelazado (interlaced video); b谩sicamente env铆a la mitad de la pantalla en un "fotograma" y la otra mitad en el siguiente "fotograma".
Hoy en d铆a, las pantallas representan im谩genes principalmente utilizando la t茅cnica de escaneo progresivo (progressive v铆deo). El v铆deo progresivo es una forma de mostrar, almacenar o transmitir im谩genes en movimiento en la que todas las l铆neas de cada fotograma se dibujan en secuencia.
Ahora ya tenemos una idea acerca de c贸mo una imagen es representada digitalmente, c贸mo sus colores son codificados, cu谩ntos bits por segundo necesitamos para mostrar un v铆deo, si es constante (CBR) o variable (VBR), con una resoluci贸n dada a determinado frame rate y otros t茅rminos como entrelazado, PAR, etc.
Puedes verificar la mayor铆a de las propiedades mencionadas con ffmpeg o mediainfo.
Aprendimos que no es factible utilizar v铆deo sin ninguna compresi贸n; un solo v铆deo de una hora a una resoluci贸n de 720p y 30fps requerir铆a 278GB*. Dado que utilizar 煤nicamente algoritmos de compresi贸n de datos sin p茅rdida como DEFLATE (utilizado en PKZIP, Gzip y PNG), no disminuir铆a suficientemente el ancho de banda necesario, debemos encontrar otras formas de comprimir el v铆deo.
* Encontramos este n煤mero multiplicando 1280 x 720 x 24 x 30 x 3600 (ancho, alto, bits por p铆xel, fps y tiempo en segundos).
Para hacerlo, podemos aprovechar c贸mo funciona nuestra visi贸n. Somos mejores para distinguir el brillo que los colores, las repeticiones en el tiempo, un v铆deo contiene muchas im谩genes con pocos cambios, y las repeticiones dentro de la imagen, cada fotograma tambi茅n contiene muchas 谩reas que utilizan colores iguales o similares.
Nuestros ojos son m谩s sensibles al brillo que a los colores, puedes comprobarlo por ti mismo, mira esta imagen.
Si no puedes ver que los colores de los cuadrados A y B son id茅nticos en el lado izquierdo, no te preocupes, es nuestro cerebro jug谩ndonos una pasada para que prestemos m谩s atenci贸n a la luz y la oscuridad que al color. Hay un conector, del mismo color, en el lado derecho para que nosotros (nuestro cerebro) podamos identificar f谩cilmente que, de hecho, son del mismo color.
Explicaci贸n simplista de c贸mo funcionan nuestros ojos El ojo es un 贸rgano complejo, compuesto por muchas partes, pero principalmente nos interesan las c茅lulas de conos y bastones. El ojo contiene alrededor de 120 millones de c茅lulas de bastones y 6 millones de c茅lulas de conos.
Para simplificar absurdamente, intentemos relacionar los colores y el brillo con las funciones de las partes del ojo. Los bastones son principalmente responsables del brillo, mientras que los conos son responsables del color. Hay tres tipos de conos, cada uno con un pigmento diferente, a saber: Tipo S (azul), Tipo M (verde) y Tipo L (rojos).
Dado que tenemos muchas m谩s c茅lulas de bastones (brillo) que c茅lulas de conos (color), se puede inferir que somos m谩s capaces de distinguir el contraste entre la luz y la oscuridad que los colores.
Funciones de sensibilidad al contraste
Los investigadores de psicolog铆a experimental y muchas otras disciplinas han desarrollado varias teor铆as sobre la visi贸n humana. Una de ellas se llama funciones de sensibilidad al contraste. Est谩n relacionadas con el espacio y el tiempo de la luz y su valor se presenta en una luz inicial dada, cu谩nto cambio se requiere antes de que un observador informe que ha habido un cambio. Observa el plural de la palabra "funci贸n", esto se debe a que podemos medir las funciones de sensibilidad al contraste no solo con blanco y negro, sino tambi茅n con colores. El resultado de estos experimentos muestra que en la mayor铆a de los casos nuestros ojos son m谩s sensibles al brillo que al color.
Una vez que sabemos que somos m谩s sensibles a la luminancia (luma, el brillo en una imagen), podemos aprovecharlo.
Primero aprendimos c贸mo funcionan las im谩genes en color utilizando el modelo RGB, pero existen otros modelos tambi茅n. De hecho, hay un modelo que separa la luminancia (brillo) de la crominancia (colores) y se conoce como YCbCr*.
* hay m谩s modelos que hacen la misma separaci贸n.
Este modelo de color utiliza Y para representar el brillo y dos canales de color, Cb (croma azul) y Cr (croma rojo). El YCbCr se puede derivar a partir de RGB y tambi茅n se puede convertir de nuevo a RGB. Utilizando este modelo, podemos crear im谩genes a todo color, como podemos ver a continuaci贸n.
Algunos pueden preguntarse, 驴c贸mo podemos producir todos los colores sin usar el verde?
Para responder a esta pregunta, vamos a realizar una conversi贸n de RGB a YCbCr. Utilizaremos los coeficientes del est谩ndar BT.601 que fue recomendado por el grupo ITU-R*. El primer paso es calcular la luminancia, utilizaremos las constantes sugeridas por la ITU y sustituiremos los valores RGB.
Y = 0.299R + 0.587G + 0.114B
Una vez obtenida la luminancia, podemos separar los colores (croma azul y croma rojo):
Cb = 0.564(B - Y)
Cr = 0.713(R - Y)
Y tambi茅n podemos covertirlo de vuelta e incluse obtener el verde utilizando YCbCr.
R = Y + 1.402Cr
B = Y + 1.772Cb
G = Y - 0.344Cb - 0.714Cr
* Los grupos y est谩ndares son comunes en el v铆deo digital y suelen definir cu谩les son los est谩ndares, por ejemplo, 驴qu茅 es 4K? 驴qu茅 FPS debemos usar? 驴resoluci贸n? 驴modelo de color?
Generalmente, las pantallas (monitores, televisores, etc.) utilizan solo el modelo RGB, organizado de diferentes maneras, como se muestra a continuaci贸n:
Con la imagen representada en componentes de luminancia y crominancia, podemos aprovechar la mayor sensibilidad del sistema visual humano a la resoluci贸n de luminancia en lugar de la crominancia para eliminar selectivamente informaci贸n. El chroma subsampling es la t茅cnica de codificar im谩genes utilizando menor resoluci贸n para la crominancia que para la luminancia.
驴Cu谩nto debemos reducir la resoluci贸n de la crominancia? Resulta que ya existen algunos esquemas que describen c贸mo manejar la resoluci贸n y la combinaci贸n (color final = Y + Cb + Cr).
Estos esquemas se conocen como sistemas de subsampling y se expresan como una relaci贸n de 3 partes: a:x:y, que define la resoluci贸n de la crominancia en relaci贸n con un bloque a x 2 de p铆xeles de luminancia.
aes la referencia de muestreo horizontal (generalmente 4).xes el n煤mero de muestras de crominancia en la primera fila deap铆xeles (resoluci贸n horizontal en relaci贸n cona).yes el n煤mero de cambios de muestras de crominancia entre la primera y segunda filas de a p铆xeles.
Una excepci贸n a esto es el 4:1:0, que proporciona una sola muestra de crominancia dentro de cada bloque de
4 x 4p铆xeles de resoluci贸n de luminancia.
Los esquemas comunes utilizados en c贸decs modernos son: 4:4:4 (sin subsampling), 4:2:2, 4:1:1, 4:2:0, 4:1:0 y 3:1:1.
Puedes seguir algunas discusiones para aprender m谩s sobre el Chroma Subsampling.
Fusi贸n YCbCr 4:2:0
Aqu铆 tienes una parte fusionada de una imagen utilizando YCbCr 4:2:0, observa que solo utilizamos 12 bits por p铆xel.
Puedes ver la misma imagen codificada por los principales tipos de chroma subsampling, las im谩genes en la primera fila son las YCbCr finales, mientras que la 煤ltima fila de im谩genes muestra la resoluci贸n de crominancia. Es realmente una gran ganancia con una p茅rdida tan peque帽a.
Anteriormente hab铆amos calculado que necesit谩bamos 278 GB de almacenamiento para mantener un archivo de video con una hora de resoluci贸n de 720p y 30 fps. Si usamos YCbCr 4:2:0, podemos reducir este tama帽o a la mitad (139 GB)*, pero a煤n est谩 lejos del ideal.
* encontramos este valor multiplicando el ancho, alto, bits por p铆xel y fps. Anteriormente necesit谩bamos 24 bits, ahora solo necesitamos 12.
Puedes observar el histograma YCbCr con ffmpeg. Esta excena tiene una mayor contribuci贸n de azul la cual se muestra en el histograma.
Mira este incre铆ble video que explica qu茅 es la luma y aprende sobre luminancia, gamma y color.
V铆deo en Ingl茅s
Puedes visualizar la intensidad Y (luma) para una l铆nea espec铆fica de un v铆deo utilizando el filtro de osciloscopio de FFmpeg.
ffplay -f lavfi -i 'testsrc2=size=1280x720:rate=30000/1001,format=yuv420p' -vf oscilloscope=x=0.5:y=200/720:s=1:c=1
Ahora podemos continuar y tratar de eliminar la redundancia en el tiempo, pero antes de hacerlo, establezcamos algunas terminolog铆as b谩sicas. Supongamos que tenemos una pel铆cula con 30 fps. Aqu铆 est谩n sus primeros 4 fotogramas.
Podemos ver muchas repeticiones dentro de los fotogramas, como el fondo azul, que no cambia del fotograma 0 al fotograma 3. Para abordar este problema, podemos categorizarlos abstractamente en tres tipos de fotogramas.
Un I-frame (reference, keyframe, intra, en espa帽ol fotograma o cuadro de referencia) es un fotograma aut贸nomo. No depende de nada para ser renderizado, un I-frame se parece a una fotograf铆a est谩tica. Por lo general, el primer fotograma es un I-frame, pero veremos I-frames insertados regularmente entre otros tipos de fotogramas.
Un P-frame (en espa帽ol, fotograma o cuadro predictivo) aprovecha el hecho de que casi siempre la imagen actual se puede renderizar utilizando el fotograma anterior. Por ejemplo, en el segundo fotograma, el 煤nico cambio fue que la pelota se movi贸 hacia adelante. Podemos reconstruir el fotograma 1, utilizando solo la diferencia y haciendo referencia al fotograma anterior.
<- 
Dado que un fotograma P utiliza menos datos, 驴por qu茅 no podemos codificar un video entero con un solo I-frame y todos los dem谩s siendo P-frames?
Despu茅s de codificar este v铆deo, comienza a verlo y busca una parte avanzada del v铆deo; notar谩s que toma algo de tiempo llegar realmente a esa parte. Esto se debe a que un P-frame necesita un fotograma de referencia (como un I-frame, por ejemplo) para renderizarse.
Otra prueba r谩pida que puedes hacer es codificar un v铆deo utilizando un solo I-frame y luego codificarlo insertando un I-frame cada 2 segundos y comprobar el tama帽o de cada versi贸n.
驴Qu茅 pasa si hacemos referencia a los fotogramas pasados y futuros para proporcionar una compresi贸n a煤n mejor? Eso es b谩sicamente lo que hace un B-frame.
<- ->
Puedes generar dos versiones, una con B-frames y otra sin ning煤n B-frame en absoluto y verificar el tama帽o del archivo y la calidad.
Estos tipos de fotogramas se utilizan para proporcionar una mejor compresi贸n. Veremos c贸mo sucede esto en la pr贸xima secci贸n, pero por ahora podemos pensar en un I-frame como costoso, un P-frame como m谩s econ贸mico y el m谩s econ贸mico es el B-frame.
Vamos a explorar las opciones que tenemos para reducir las repeticiones en el tiempo, este tipo de redundancia se puede resolver con t茅cnicas de interpredicci贸n.
Intentaremos utilizar menos bits para codificar la secuencia de los fotogramas 0 y 1.
Una cosa que podemos hacer es una resta, simplemente restamos el fotograma 1 del fotograma 0 y obtenemos lo que necesitamos para codificar el residual.
Pero, 驴qu茅 pasa si te digo que hay un m茅todo mejor que utiliza incluso menos bits? Primero, tratemos el fotograma 0 como una colecci贸n de particiones bien definidas y luego intentaremos emparejar los bloques del fotograma 0 en el fotograma 1. Podemos pensar en ello como una estimaci贸n de movimiento.
"La compensaci贸n de movimiento por bloques divide el fotograma actual en bloques no superpuestos, y el vector de compensaci贸n de movimiento indica de d贸nde provienen esos bloques (una idea err贸nea com煤n es que el fotograma anterior se divide en bloques no superpuestos y los vectores de compensaci贸n de movimiento indican hacia d贸nde se mueven esos bloques). Los bloques de origen suelen superponerse en el fotograma fuente. Algunos algoritmos de compresi贸n de v铆deo ensamblan el fotograma actual a partir de piezas de varios fotogramas previamente transmitidos."
Podr铆amos estimar que la pelota se movi贸 de x=0, y=25 a x=6, y=26, los valores de x e y son los vectores de movimiento. Un paso adicional que podemos dar para ahorrar bits es codificar solo la diferencia del vector de movimiento entre la 煤ltima posici贸n del bloque y la predicci贸n, por lo que el vector de movimiento final ser铆a x=6 (6-0), y=1 (26-25).
En una situaci贸n del mundo real, esta pelota se dividir铆a en n particiones, pero el proceso es el mismo.
Los objetos en el fotograma se mueven de manera tridimensional, la pelota puede volverse m谩s peque帽a cuando se mueve al fondo. Es normal que no encontremos una coincidencia perfecta con el bloque que intentamos encontrar. Aqu铆 hay una vista superpuesta de nuestra estimaci贸n frente a la imagen real.
Pero podemos ver que cuando aplicamos la estimaci贸n de movimiento, los datos a codificar son m谩s peque帽os que cuando simplemente usamos t茅cnicas de fotograma delta.
Esta t茅cnica se aplica a todos los bloques, muy a menudo una pelota se dividir铆a en m谩s de un bloque.
Fuente: https://web.stanford.edu/class/ee398a/handouts/lectures/EE398a_MotionEstimation_2012.pdf
Puedes experimentar con estos conceptos utilizando jupyter.
Podemos generar un v铆deo con la interpredicci贸n (vectores de movimiento) con ffmpeg.
O podemos usar el Intel Video Pro Analyzer (que es de pago, pero hay una versi贸n de prueba gratuita que te limita a trabajar solo con los primeros 10 fotogramas).
Si analizamos cada fotograma en un v铆deo, veremos que tambi茅n hay muchas 谩reas que est谩n correlacionadas.
Vamos a trav茅s de un ejemplo. Esta escena est谩 compuesta principalmente por colores azules y blancos.
Este es un I-frame y no podemos usar fotogramas anteriores para hacer una predicci贸n, pero a煤n podemos comprimirlo. Codificaremos la selecci贸n de bloques en rojo. Si observamos a sus vecinos, podemos estimar que hay una tendencia de colores a su alrededor.
Vamos a predecir que el fotograma continuar谩 extendiendo los colores verticalmente, lo que significa que los colores de los p铆xeles desconocidos mantendr谩n los valores de sus vecinos.
Nuestra predicci贸n puede ser incorrecta, por esa raz贸n necesitamos aplicar esta t茅cnica (intra prediction) y luego restar los valores reales, lo que nos da el bloque residual, lo que resulta en una matriz mucho m谩s compresible en comparaci贸n con la original.
Existen muchos tipos diferentes de este tipo de predicci贸n. La que se muestra aqu铆 es una forma de predicci贸n plana recta, donde los p铆xeles de la fila superior del bloque se copian fila por fila dentro del bloque. La predicci贸n plana tambi茅n puede tener una componente angular, donde se utilizan p铆xeles tanto de la izquierda como de la parte superior para ayudar a predecir el bloque actual. Y tambi茅n existe la predicci贸n DC, que implica tomar el promedio de las muestras justo arriba y a la izquierda del bloque.
Puedes generar con ffmpeg un v铆deo con macrobloques y sus predicciones. Por favor verifica la documentaci贸n de ffmpeg para comprender el significado de cada bloque de color.
O puedes usar Intel Video Pro Analyzer (que es de pago, pero hay una versi贸n de prueba gratuita que te limita a trabajar solo con los primeros 10 fotogramas).
驴Qu茅? Es un software o hardware que comprime o descomprime v铆deo digital. 驴Por qu茅? El mercado y la sociedad demandan v铆deos de mayor calidad con ancho de banda o almacenamiento limitados. 驴Recuerdas cuando calculamos el ancho de banda necesario para 30 fps, 24 bits por p铆xel, resoluci贸n de un v铆deo de 480x240? Fueron 82.944 Mbps sin aplicar compresi贸n. Es la 煤nica forma de entregar HD/FullHD/4K en televisores e Internet. 驴C贸mo? Echaremos un vistazo breve a las t茅cnicas principales aqu铆.
CODEC vs Contenedor
Un error com煤n que cometen los principiantes es confundir el CODEC de v铆deo digital y el contenedor de v铆deo digital. Podemos pensar en los contenedores como un formato que contiene metadatos del v铆deo (y posiblemente tambi茅n audio), y el v铆deo comprimido se puede ver como su contenido.
Por lo general, la extensi贸n de un archivo de v铆deo define su contenedor de v铆deo. Por ejemplo, el archivo
video.mp4probablemente es un contenedor MPEG-4 Part 14 y un archivo llamadovideo.mkvprobablemente es un matroska. Para estar completamente seguro sobre el c贸dec y el formato del contenedor, podemos usar ffmpeg o mediainfo.
Antes de adentrarnos en el funcionamiento interno de un c贸dec gen茅rico, echemos un vistazo atr谩s para comprender un poco mejor algunos c贸decs de v铆deo antiguos.
El c贸dec de v铆deo H.261 naci贸 en 1990 (t茅cnicamente en 1988) y fue dise帽ado para trabajar con tasas de datos de 64 kbit/s. Ya utilizaba ideas como el chroma subsampling, el macrobloque, etc. En el a帽o 1995, se public贸 el est谩ndar de c贸dec de v铆deo H.263 y continu贸 siendo extendido hasta 2001.
En 2003 se complet贸 la primera versi贸n de H.264/AVC. En el mismo a帽o, On2 Technologies (anteriormente conocida como Duck Corporation) lanz贸 su c贸dec de v铆deo como una compresi贸n de v铆deo con p茅rdida libre de regal铆as llamada VP3. En 2008, Google compr贸 esta empresa y lanz贸 VP8 en el mismo a帽o. En diciembre de 2012, Google lanz贸 VP9, el cual es compatible con aproximadamente el 戮 del mercado de navegadores (incluyendo m贸viles).
AV1 es un nuevo c贸dec de v铆deo libre de regal铆as y de c贸digo abierto que est谩 siendo dise帽ado por la Alliance for Open Media (AOMedia), la cual est谩 compuesta por empresas como Google, Mozilla, Microsoft, Amazon, Netflix, AMD, ARM, NVidia, Intel y Cisco, entre otras. La primera versi贸n, 0.1.0 del c贸dec de referencia, se public贸 el 7 de abril de 2016.
A principios de 2015, Google estaba trabajando en VP10, Xiph (Mozilla) estaba trabajando en Daala y Cisco lanz贸 su c贸dec de video libre de regal铆as llamado Thor.
Entonces, MPEG LA anunci贸 por primera vez l铆mites anuales para HEVC (H.265) y tarifas 8 veces m谩s altas que H.264, pero pronto cambiaron las reglas nuevamente:
- sin l铆mite anual,
- tarifa por contenido (0.5% de los ingresos) y
- tarifas por unidad aproximadamente 10 veces m谩s altas que H.264.
La Alliance for Open Media fue creada por empresas de fabricantes de hardware (Intel, AMD, ARM, Nvidia, Cisco), distribuci贸n de contenido (Google, Netflix, Amazon), mantenimiento de navegadores (Google, Mozilla) y otros.
Las empresas ten铆an un objetivo com煤n, un c贸dec de v铆deo libre de regal铆as, y as铆 naci贸 AV1 con una licencia de patente mucho m谩s simple. Timothy B. Terriberry hizo una excelente presentaci贸n, que es la fuente de esta secci贸n, sobre la concepci贸n de AV1, el modelo de licencia y su estado actual.
Te sorprender谩 saber que puedes analizar el c贸dec AV1 a trav茅s de tu navegador, visita https://arewecompressedyet.com/analyzer/
PD: Si deseas aprender m谩s sobre la historia de los c贸decs, debes comprender los conceptos b谩sicos detr谩s de las patentes de compresi贸n de v铆deo.
Vamos a presentar los mecanismos principales detr谩s de un c贸dec de v铆deo gen茅rico, pero la mayor铆a de estos conceptos son 煤tiles y se utilizan en c贸decs modernos como VP9, AV1 y HEVC. Aseg煤rate de entender que vamos a simplificar las cosas MUCHO. A veces usaremos un ejemplo real (principalmente H.264) para demostrar una t茅cnica.
El primer paso es dividir el fotograma en varias particiones, sub-particiones y m谩s all谩.
Pero, 驴por qu茅?. Hay muchas razones, por ejemplo, cuando dividimos la imagen, podemos trabajar las predicciones de manera m谩s precisa, utilizando peque帽as particiones para las partes m贸viles y particiones m谩s grandes para un fondo est谩tico.
Por lo general, los c贸decs organizan estas particiones en slices (o tiles), macrobloques (o unidades de 谩rbol de codificaci贸n) y muchas sub-particiones. El tama帽o m谩ximo de estas particiones var铆a, HEVC establece 64x64 mientras que AVC usa 16x16, pero las sub-particiones pueden alcanzar tama帽os de 4x4.
驴Recuerdas que aprendimos c贸mo se clasifican los fotogramas? Bueno, tambi茅n puedes aplicar esas ideas a los bloques, por lo tanto, podemos tener I-Slice, B-Slice, I-Macroblock, etc.
Podemos usar Intel Video Pro Analyzer (que es de pago, pero hay una versi贸n de prueba gratuita que limita el trabajo a los primeros 10 fotogramas). Aqu铆 se analizan las particiones de VP90.
Una vez que tenemos las particiones, podemos hacer predicciones sobre ellas. Para la inter prediction, necesitamos enviar los vectores de movimiento y el residual, y para la intra prediction, enviaremos la direcci贸n de predicci贸n y el residual tambi茅n.
Despu茅s de obtener el bloque residual (partici贸n predicha - partici贸n real), podemos transformarlo de tal manera que nos permita saber cu谩les p铆xeles podemos descartar mientras mantenemos la calidad general. Hay algunas transformaciones para este comportamiento espec铆fico.
Aunque existen otras transformaciones, examinaremos m谩s de cerca la transformada coseno discreta (DCT). Las principales caracter铆sticas de la DCT son las siguientes:
- convierte bloques de p铆xeles en bloques del mismo tama帽o de los coeficientes de frecuencia.
- compacta la energ铆a, lo que facilita eliminar la redundancia espacial.
- es reversible, es decir, se puede revertir a p铆xeles.
El 2 de febrero de 2017, Cintra, R. J. y Bayer, F. M publicaron su art铆culo DCT-like Transform for Image Compression Requires 14 Additions Only.
No te preocupes si no comprendiste los beneficios de cada punto, intentaremos realizar algunos experimentos para ver el valor real de esto.
Tomemos el siguiente bloque de p铆xeles (8x8):
Lo cual se representa en la siguiente imagen de bloque (8x8):
Cuando aplicamos la DCT a este bloque de p铆xeles, obtenemos el bloque de coeficientes (8x8):
Y si representamos este bloque de coeficientes, obtendremos esta imagen:
Como puedes ver, no se parece en nada a la imagen original, podr铆amos notar que el primer coeficiente es muy diferente de todos los dem谩s. Este primer coeficiente se conoce como el coeficiente DC, que representa todas las muestras en el array de entrada, algo similar a un promedio.
Este bloque de coeficientes tiene una propiedad interesante, que es que separa los componentes de alta frecuencia de los de baja frecuencia.
En una imagen, la mayor parte de la energ铆a se concentrar谩 en las frecuencias m谩s bajas, por lo que si transformamos una imagen en sus componentes de frecuencia y eliminamos los coeficientes de frecuencia m谩s altos, podemos reducir la cantidad de datos necesarios para describir la imagen sin sacrificar demasiada calidad de imagen.
La frecuencia significa cu谩n r谩pido cambia una se帽al.
Intentemos aplicar el conocimiento que adquirimos en la prueba, convirtiendo la imagen original a su dominio de frecuencia (bloque de coeficientes) usando DCT y luego descartando parte (67%) de los coeficientes menos importantes, principalmente la parte inferior derecha.
Primero, lo convertimos a su dominio de frecuencia.
A continuaci贸n, descartamos parte (67%) de los coeficientes, principalmente la parte inferior derecha.
Finalmente, reconstruimos la imagen a partir de este bloque de coeficientes descartados (recuerda, debe ser reversible) y la comparamos con la original.
Como podemos ver, se asemeja a la imagen original pero introduce muchas diferencias con respecto a la original. Descartamos el 67.1875% y a煤n as铆 pudimos obtener algo similar a la original. Podr铆amos descartar de manera m谩s inteligente los coeficientes para tener una mejor calidad de imagen, pero eso es el pr贸ximo tema.
Cada coeficiente se forma utilizando todos los p铆xeles
Es importante destacar que cada coeficiente no se asigna directamente a un solo p铆xel, sino que es una suma ponderada de todos los p铆xeles. Este gr谩fico asombroso muestra c贸mo se calcula el primer y segundo coeficiente, utilizando pesos 煤nicos para cada 铆ndice.
Tambi茅n puedes intentar visualizar la DCT mirando una imagen simple formada sobre la base de la DCT. Por ejemplo, aqu铆 tienes c贸mo se forma el car谩cter A utilizando el peso de cada coeficiente.
Puedes jugar con la transformaci贸n DCT.
Cuando descartamos algunos de los coeficientes en el 煤ltimo paso (transformaci贸n), de alguna manera hicimos una forma de cuantizaci贸n. En este paso es donde elegimos perder informaci贸n (la parte perdida) o, en t茅rminos simples, cuantificamos coeficientes para lograr la compresi贸n.
驴C贸mo podemos cuantificar un bloque de coeficientes? Un m茅todo simple ser铆a una cuantificaci贸n uniforme, donde tomamos un bloque, lo dividimos por un valor 煤nico (10) y redondeamos este valor.
驴C贸mo podemos revertir (re-cuantificar) este bloque de coeficientes? Podemos hacerlo multiplicando el mismo valor (10) por el que lo dividimos inicialmente.
Este enfoque no es el mejor porque no tiene en cuenta la importancia de cada coeficiente. Podr铆amos usar una matriz de cuantizadores en lugar de un solo valor. Esta matriz puede explotar la propiedad de la DCT, cuantificando m谩s los coeficientes de la parte inferior derecha y menos los de la parte superior izquierda. El JPEG utiliza un enfoque similar; puedes consultar el c贸digo fuente para ver esta matriz.
Puedes experimentar con la cuantizaci贸n aqu铆.
Despu茅s de cuantificar los datos (bloques/slices/fotogramas de im谩genes), a煤n podemos comprimirlos de manera sin p茅rdida. Hay muchas formas (algoritmos) de comprimir datos. Vamos a experimentar brevemente con algunos de ellos. Para una comprensi贸n m谩s profunda, puedes leer el incre铆ble libro Understanding Compression: Data Compression for Modern Developers.
Supongamos que tenemos una secuencia de s铆mbolos: a, e, r y t; y su probabilidad (de 0 a 1) se representa en esta tabla.
| a | e | r | t | |
|---|---|---|---|---|
| probabilidad | 0.3 | 0.3 | 0.2 | 0.2 |
Podemos asignar c贸digos binarios 煤nicos (preferiblemente peque帽os) a los m谩s probables y c贸digos m谩s grandes a los menos probables.
| a | e | r | t | |
|---|---|---|---|---|
| probabilidad | 0.3 | 0.3 | 0.2 | 0.2 |
| c贸digo binario | 0 | 10 | 110 | 1110 |
Comprimamos la secuencia eat, asumiendo que gastar铆amos 8 bits para cada s铆mbolo, gastar铆amos 24 bits sin ninguna compresi贸n. Pero en caso de que reemplacemos cada s铆mbolo por su c贸digo, podemos ahorrar espacio.
El primer paso es codificar el s铆mbolo e, que es 10, y el segundo s铆mbolo es a, que se agrega (no en un sentido matem谩tico) como [10][0], y finalmente el tercer s铆mbolo t, lo que hace que nuestra secuencia de bits comprimida final sea [10][0][1110] o 1001110, que solo requiere 7 bits (3.4 veces menos espacio que el original).
Observa que cada c贸digo debe ser un c贸digo 煤nico y prefijado Huffman puede ayudarte a encontrar estos n煤meros. Aunque tiene algunos problemas, todav铆a hay c贸decs de v铆deo que ofrecen este m茅todo y es el algoritmo para muchas aplicaciones que requieren compresi贸n.
Tanto el codificador como el decodificador deben conocer la tabla de s铆mbolos con sus c贸digos, por lo tanto, tambi茅n debes enviar la tabla.
Supongamos que tenemos una secuencia de s铆mbolos: a, e, r, s y t; y su probabilidad se representa en esta tabla.
| a | e | r | s | t | |
|---|---|---|---|---|---|
| probabilidad | 0.3 | 0.3 | 0.15 | 0.05 | 0.2 |
Con esta tabla en mente, podemos construir rangos que contengan todos los posibles s铆mbolos ordenados por los m谩s frecuentes.
Ahora codifiquemos la secuencia eat, tomamos el primer s铆mbolo e, que se encuentra dentro del subrango 0.3 a 0.6 (pero no se incluye), y tomamos este subrango y lo dividimos nuevamente utilizando las mismas proporciones utilizadas anteriormente, pero dentro de este nuevo rango.
Continuemos codificando nuestra secuencia eat, ahora tomamos el segundo s铆mbolo a, que est谩 dentro del nuevo subrango 0.3 a 0.39, y luego tomamos nuestro 煤ltimo s铆mbolo t y hacemos el mismo proceso nuevamente y obtenemos el 煤ltimo subrango 0.354 a 0.372.
Solo necesitamos elegir un n煤mero dentro del 煤ltimo subrango 0.354 a 0.372, elijamos 0.36, pero podr铆amos elegir cualquier n煤mero dentro de este subrango. Con solo este n煤mero podremos recuperar nuestra secuencia original eat. Si lo piensas, es como si estuvi茅ramos dibujando una l铆nea dentro de rangos de rangos para codificar nuestra secuencia.
El proceso inverso (tambi茅n conocido como decodificaci贸n) es igualmente sencillo, con nuestro n煤mero 0.36 y nuestro rango original, podemos realizar el mismo proceso pero ahora usando este n煤mero para revelar la secuencia codificada original detr谩s de este n煤mero.
Con el primer rango, notamos que nuestro n煤mero encaja en la porci贸n, por lo tanto, es nuestro primer s铆mbolo, ahora dividimos este subrango nuevamente, haciendo el mismo proceso que antes, y notamos que 0.36 encaja en el s铆mbolo a, y despu茅s de repetir el proceso llegamos al 煤ltimo s铆mbolo t (formando nuestra secuencia original codificada eat).
Tanto el codificador como el decodificador tienen que conocer la tabla de probabilidades de los s铆mbolos, por lo tanto, tambi茅n debes enviar la tabla.
驴Bastante ingenioso, verdad? Las personas son realmente inteligentes para idear una soluci贸n as铆. Algunos c贸decs de v铆deo utilizan esta t茅cnica (o al menos la ofrecen como opci贸n).
La idea es comprimir sin p茅rdidas el flujo de bits cuantificados. Sin duda, este art铆culo carece de muchos detalles, razones, compensaciones, etc. Pero puedes aprender m谩s. Los c贸decs m谩s nuevos est谩n tratando de utilizar diferentes algoritmos de codificaci贸n de entrop铆a como ANS.
Puedes generar 2 streams, uno con CABAC y otro con CAVLC y compara cu谩nto tiempo toma generar cada uno de ellos, como as铆 tambi茅n el tama帽o final.
Despu茅s de completar todos estos pasos, necesitamos empaquetar los fotogramas comprimidos y el contexto de estos pasos. Debemos informar expl铆citamente al decodificador sobre las decisiones tomadas por el codificador, como el bit depth, el espacio de color, la resoluci贸n, la informaci贸n de predicciones (vectores de movimiento, direcci贸n de intra prediction), perfil, nivel, fps, tipo de fotograma, n煤mero de fotograma y mucho m谩s.
Vamos a estudiar superficialmente el bitstream de H.264. Nuestro primer paso es generar un bitstream H.264* m铆nimo, lo podemos hacer utilizando nuestro propio repositorio y ffmpeg.
./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264
* fmpeg agrega, por defecto, todos los par谩metros de codificaci贸n como un SEI NAL, pronto definiremos qu茅 es un NAL.
Este comando generar谩 un bitstream H.264 en bruto con un 煤nico fotograma, de 64x64 p铆xeles, con espacio de color yuv420, utilizando la siguiente imagen como fotograma.
El est谩ndar AVC (H.264) define que la informaci贸n se enviar谩 en macro frames (en el sentido de red), llamadas NAL (Network Abstraction Layer). El objetivo principal de la NAL es proporcionar una representaci贸n de v铆deo "amigable para la red". Este est谩ndar debe funcionar en televisores (basados en transmisi贸n) y en Internet (basado en paquetes), entre otros.
Hay un marcador de sincronizaci贸n para definir los l铆mites de las unidades NAL. Cada marcador de sincronizaci贸n tiene un valor de 0x00 0x00 0x01, excepto el primero, que es 0x00 0x00 0x00 0x01. Si ejecutamos el comando hexdump en el flujo de bits H.264 generado, podemos identificar al menos tres NAL al principio del archivo.
Como mencionamos antes, el decodificador necesita conocer no solo los datos de la imagen, sino tambi茅n los detalles del v铆deo, el fotograma, los colores, los par谩metros utilizados y otros. El primer byte de cada NAL define su categor铆a y tipo.
| NAL type id | Description |
|---|---|
| 0 | Undefined |
| 1 | Coded slice of a non-IDR picture |
| 2 | Coded slice data partition A |
| 3 | Coded slice data partition B |
| 4 | Coded slice data partition C |
| 5 | IDR Coded slice of an IDR picture |
| 6 | SEI Supplemental enhancement information |
| 7 | SPS Sequence parameter set |
| 8 | PPS Picture parameter set |
| 9 | Access unit delimiter |
| 10 | End of sequence |
| 11 | End of stream |
| ... | ... |
Normalmente, el primer NAL de un flujo de bits es un SPS (Sequence Parameter Set). Este tipo de NAL es responsable de proporcionar informaci贸n sobre las variables de codificaci贸n generales como perfil, nivel, resoluci贸n y otros.
Si omitimos el primer marcador de sincronizaci贸n, podemos decodificar el primer byte para saber qu茅 tipo de NAL es el primero.
Por ejemplo, el primer byte despu茅s del marcador de sincronizaci贸n es 01100111, donde el primer bit (0) es el campo forbidden_zero_bit, los siguientes 2 bits (11) nos indican el campo nal_ref_idc, que indica si este NAL es un campo de referencia o no, y los siguientes 5 bits (00111) nos informan sobre el campo nal_unit_type, en este caso, es un NAL de tipo SPS (7).
El segundo byte (binary=01100100, hex=0x64, dec=100) de un NAL SPS es el campo profile_idc, que muestra el perfil que el codificador ha utilizado. En este caso, hemos utilizado el high profile. Adem谩s, el tercer byte contiene varias banderas que determinan el perfil exacto (como restringido o progresivo). Pero en nuestro caso, el tercer byte es 0x00 y, por lo tanto, el codificador ha utilizado solo el high profile.
Cuando leemos la especificaci贸n de flujo de bits H.264 para un NAL SPS, encontraremos muchos valores para el parameter name, category y description. Por ejemplo, veamos los campos pic_width_in_mbs_minus_1 y pic_height_in_map_units_minus_1.
| Parameter name | Category | Description |
|---|---|---|
| pic_width_in_mbs_minus_1 | 0 | ue(v) |
| pic_height_in_map_units_minus_1 | 0 | ue(v) |
ue(v): unsigned integer Exp-Golomb-coded
Si realizamos algunos c谩lculos con el valor de estos campos, obtendremos la resoluci贸n. Podemos representar 1920 x 1080 usando un valor de pic_width_in_mbs_minus_1 de 119 ((119 + 1) * macroblock_size = 120 * 16 = 1920), nuevamente ahorrando espacio, en lugar de codificar 1920, lo hicimos con 119.
Si continuamos examinando nuestro v铆deo creado con una vista binaria (por ejemplo, xxd -b -c 11 v/minimal_yuv420.h264), podemos saltar al 煤ltimo NAL que es el propio cuadro.
Podemos ver los valores de sus primeros 6 bytes: 01100101 10001000 10000100 00000000 00100001 11111111. Como ya sabemos, el primer byte nos dice qu茅 tipo de NAL es, en este caso, (00101) es un IDR Slice (5) y podemos inspeccionarlo m谩s a fondo:
Utilizando la informaci贸n de la especificaci贸n, podemos decodificar qu茅 tipo de slice (slice_type), el n煤mero de fotograma (frame_num) y otros campos importantes.
Para obtener los valores de algunos campos (ue(v), me(v), se(v) o te(v)), debemos decodificarlos utilizando un decodificador especial llamado Exponential-Golomb. Este m茅todo es muy eficiente para codificar valores variables, sobre todo cuando hay muchos valores predeterminados.
Los valores de slice_type y frame_num de este v铆deo son 7 (I slice) y 0 (el primer fotograma).
Podemos ver el bitstream como un protocolo, y si deseas aprender m谩s sobre este bitstream, consulta la especificaci贸n ITU H.264. Aqu铆 tienes un diagrama macro que muestra d贸nde reside los datos de la imagen (YUV comprimido).
Podemos explorar otros bitstreams como el bitstreams VP9, H.265 (HEVC) o incluso nuestro nuevo mejor amigo el bitstream AV1, 驴se ven todos similares, no? Pero una vez que aprendes uno, puedes entender f谩cilmente los dem谩s.
Podemos generar un video de un solo fotograma y usar mediainfo para inspeccionar su bitstream H.264. De hecho, incluso puedes ver el c贸digo fuente que analiza el bitstream h264 (AVC).
Tambi茅n podemos utilizar el Intel Video Pro Analyzer que es de pago, pero hay una versi贸n de prueba gratuita que limita el trabajo a solo los primeros 10 fotogramas, lo cual est谩 bien para fines de aprendizaje.
Es evidente que muchos de los c贸decs modernos utilizan el mismo modelo que aprendimos. De hecho, echemos un vistazo al diagrama de bloques del c贸dec de v铆deo Thor, que contiene todos los pasos que estudiamos. La idea es que ahora deber铆as ser capaz de al menos comprender mejor las innovaciones y los documentos de esta 谩rea.
Anteriormente calculamos que necesitar铆amos 139GB de almacenamiento para mantener un archivo de v铆deo de una hora a una resoluci贸n de 720p y 30 fps si utilizamos las t茅cnicas que aprendimos aqu铆, como inter e intra predictions, transformaci贸n, cuantizaci贸n, codificaci贸n de entrop铆a y otras. Podemos lograrlo, asumiendo que estamos utilizando 0.031 bit por p铆xel, el mismo v铆deo de calidad perceptible requiriendo solo 367.82MB en lugar de 139GB de almacenamiento.
Elegimos usar 0.031 bit por p铆xel bas谩ndonos en el ejemplo de v铆deo proporcionado aqu铆.
Ahora que sabemos m谩s sobre c贸mo funcionan los c贸decs, es f谩cil entender c贸mo los nuevos c贸decs pueden ofrecer mayores resoluciones con menos bits.
Compararemos AVC y HEVC, ten en cuenta que casi siempre hay un equilibrio entre m谩s ciclos de CPU (complejidad) y la velocidad de compresi贸n.
HEVC tiene m谩s opciones de particiones (y sub-particiones) que AVC, m谩s direcciones/谩ngulos de intra predictions, codificaci贸n de entrop铆a mejorada y m谩s, todas estas mejoras hicieron que H.265 fuera capaz de comprimir un 50% m谩s que H.264.
[TODO]
[TODO]
Podemos utilizar un sistema de tokens simple para proteger el contenido. El usuario sin un token intenta solicitar un video y la CDN (Red de Entrega de Contenido, del ingl茅s Content Delivery Network) le proh铆be el acceso, mientras que un usuario con un token v谩lido puede reproducir el contenido, funciona de manera bastante similar a la mayor铆a de los sistemas de autenticaci贸n web.
El uso exclusivo de este sistema de tokens todav铆a permite que un usuario descargue un video y lo distribuya. Es aqu铆 d贸nde, los sistemas de DRM (gesti贸n de derechos digitales, del ingl茅s digital rights management) se pueden utilizar para tratar de evitar esto.
En los sistemas de producci贸n del mundo real, a menudo se utilizan ambas t茅cnicas para proporcionar autorizaci贸n y autenticaci贸n.
- FPS - FairPlay Streaming
- PR - PlayReady
- WV - Widevine
DRM significa Digital Rights Management o gesti贸n de derechos digitales, es una forma de proporcionar protecci贸n de derechos de autor para medios digitales, como v铆deo y audio digitales. Aunque se utiliza en muchos lugares, no es universalmente aceptado.
Los creadores de contenido (principalmente estudios) desean proteger su propiedad intelectual contra la copia para prevenir la redistribuci贸n no autorizada de medios digitales.
Vamos a describir una forma abstracta y gen茅rica de DRM de manera muy simplificada.
Dado un contenido C1 (por ejemplo, un v铆deo en streaming HLS o DASH), con un reproductor P1 (por ejemplo, shaka-clappr, exo-player o iOS) en un dispositivo D1 (por ejemplo, un tel茅fono inteligente, una televisi贸n, una tableta o una computadora de escritorio/port谩til) utilizando un sistema DRM llamado DRM1 (widevine, playready o FairPlay).
El contenido C1 est谩 encriptado con una clave sim茅trica K1 del sistema DRM1, generando el contenido encriptado C'1.
El reproductor P1, de un dispositivo D1, tiene dos claves (asim茅tricas), una clave privada PRK1 (esta clave est谩 protegida1 y solo la conoce D1) y una clave p煤blica PUK1.
1Protegida: esta protecci贸n puede ser mediante hardware, por ejemplo, esta clave puede almacenarse dentro de un chip especial (de solo lectura) que funciona como una caja negra para proporcionar la descifrado, o por software (menos seguro), el sistema DRM proporciona medios para saber qu茅 tipo de protecci贸n tiene un dispositivo dado.
Cuando el reproductor P1 quiere reproducir el contenido C'1, debe interactuar con el sistema DRM DRM1, proporcionando su clave p煤blica PUK1. El sistema DRM DRM1 devuelve la clave K1 cifrada con la clave p煤blica del cliente PUK1. En teor铆a, esta respuesta es algo que solo D1 es capaz de descifrar.
K1P1D1 = enc(K1, PUK1)
P1 utiliza su sistema local de DRM (puede ser un SOC, hardware especializado o software), este sistema es capaz de descifrar el contenido utilizando su clave privada PRK1, puede descifrar la clave sim茅trica K1 de la K1P1D1 y reproducir C'1. En el mejor caso, las claves no se exponen a trav茅s de la RAM.
K1 = dec(K1P1D1, PRK1)
P1.play(dec(C'1, K1))
Aseg煤rate de tener docker instalado, ejecuta ./s/start_jupyter.sh y sigue las instrucciones en la consola.
- DEMUXED - puedes mirar las ediciones pasadas aqu铆..
El contenido m谩s rico se encuentra aqu铆, es de donde se extrajo, bas贸 o inspir贸 toda la informaci贸n que vimos en este texto. Puedes profundizar tu conocimiento con estos incre铆bles enlaces, libros, v铆deos, etc.
Cursos online y tutoriales:
- https://www.coursera.org/learn/digital/
- https://people.xiph.org/~tterribe/pubs/lca2012/auckland/intro_to_video1.pdf
- https://xiph.org/video/vid1.shtml
- https://xiph.org/video/vid2.shtml
- https://wiki.multimedia.cx
- https://mahanstreamer.net
- http://slhck.info/ffmpeg-encoding-course
- http://www.cambridgeincolour.com/tutorials/camera-sensors.htm
- http://www.slideshare.net/vcodex/a-short-history-of-video-coding
- http://www.slideshare.net/vcodex/introduction-to-video-compression-13394338
- https://developer.android.com/guide/topics/media/media-formats.html
- http://www.slideshare.net/MadhawaKasun/audio-compression-23398426
- http://inst.eecs.berkeley.edu/~ee290t/sp04/lectures/02-Motion_Compensation_girod.pdf
Libros:
- https://www.amazon.com/Understanding-Compression-Data-Modern-Developers/dp/1491961538/ref=sr_1_1?s=books&ie=UTF8&qid=1486395327&sr=1-1
- https://www.amazon.com/H-264-Advanced-Video-Compression-Standard/dp/0470516925
- https://www.amazon.com/High-Efficiency-Video-Coding-HEVC/dp/3319068946
- https://www.amazon.com/Practical-Guide-Video-Audio-Compression/dp/0240806301/ref=sr_1_3?s=books&ie=UTF8&qid=1486396914&sr=1-3&keywords=A+PRACTICAL+GUIDE+TO+VIDEO+AUDIO
- https://www.amazon.com/Video-Encoding-Numbers-Eliminate-Guesswork/dp/0998453005/ref=sr_1_1?s=books&ie=UTF8&qid=1486396940&sr=1-1&keywords=jan+ozer
Material de onboarding:
- https://github.com/Eyevinn/streaming-onboarding
- https://howvideo.works/
- https://www.aws.training/Details/eLearning?id=17775
- https://www.aws.training/Details/eLearning?id=17887
- https://www.aws.training/Details/Video?id=24750
Especificaciones de Bitstream:
- http://www.itu.int/rec/T-REC-H.264-201610-I
- http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=12904&lang=en
- https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf
- http://iphome.hhi.de/wiegand/assets/pdfs/2012_12_IEEE-HEVC-Overview.pdf
- http://phenix.int-evry.fr/jct/doc_end_user/current_document.php?id=7243
- http://gentlelogic.blogspot.com.br/2011/11/exploring-h264-part-2-h264-bitstream.html
- https://forum.doom9.org/showthread.php?t=167081
- https://forum.doom9.org/showthread.php?t=168947
Software:
- https://ffmpeg.org/
- https://ffmpeg.org/ffmpeg-all.html
- https://ffmpeg.org/ffprobe.html
- https://mediaarea.net/en/MediaInfo
- https://www.jongbel.com/
- https://trac.ffmpeg.org/wiki/
- https://software.intel.com/en-us/intel-video-pro-analyzer
- https://medium.com/@mbebenita/av1-bitstream-analyzer-d25f1c27072b#.d5a89oxz8
C贸decs Non-ITU:
- https://aomedia.googlesource.com/
- https://github.com/webmproject/libvpx/tree/master/vp9
- https://ghostarchive.org/archive/0W0d8 (was: https://people.xiph.org/~xiphmont/demo/daala/demo1.shtml)
- https://people.xiph.org/~jm/daala/revisiting/
- https://www.youtube.com/watch?v=lzPaldsmJbk
- https://fosdem.org/2017/schedule/event/om_av1/
- https://jmvalin.ca/papers/AV1_tools.pdf
Conceptos de codificaci贸n:
- http://x265.org/hevc-h265/
- http://slhck.info/video/2017/03/01/rate-control.html
- http://slhck.info/video/2017/02/24/vbr-settings.html
- http://slhck.info/video/2017/02/24/crf-guide.html
- https://arxiv.org/pdf/1702.00817v1.pdf
- https://trac.ffmpeg.org/wiki/Debug/MacroblocksAndMotionVectors
- http://web.ece.ucdavis.edu/cerl/ReliableJPEG/Cung/jpeg.html
- http://www.adobe.com/devnet/adobe-media-server/articles/h264_encoding.html
- https://prezi.com/8m7thtvl4ywr/mp3-and-aac-explained/
- https://blogs.gnome.org/rbultje/2016/12/13/overview-of-the-vp9-video-codec/
- https://videoblerg.wordpress.com/2017/11/10/ffmpeg-and-how-to-use-it-wrong/
Ejemplos de v铆deos para pruebas:
- http://bbb3d.renderfarming.net/download.html
- https://www.its.bldrdoc.gov/vqeg/video-datasets-and-organizations.aspx
Miscel谩nea:
- https://github.com/Eyevinn/streaming-onboarding
- http://stackoverflow.com/a/24890903
- http://stackoverflow.com/questions/38094302/how-to-understand-header-of-h264
- http://techblog.netflix.com/2016/08/a-large-scale-comparison-of-x264-x265.html
- http://vanseodesign.com/web-design/color-luminance/
- http://www.biologymad.com/nervoussystem/eyenotes.htm
- http://www.compression.ru/video/codec_comparison/h264_2012/mpeg4_avc_h264_video_codecs_comparison.pdf
- https://web.archive.org/web/20100728070421/http://www.csc.villanova.edu/~rschumey/csc4800/dct.html (was: http://www.csc.villanova.edu/~rschumey/csc4800/dct.html)
- http://www.explainthatstuff.com/digitalcameras.html
- http://www.hkvstar.com
- http://www.hometheatersound.com/
- http://www.lighterra.com/papers/videoencodingh264/
- http://www.red.com/learn/red-101/video-chroma-subsampling
- http://www.slideshare.net/ManoharKuse/hevc-intra-coding
- http://www.slideshare.net/mwalendo/h264vs-hevc
- http://www.slideshare.net/rvarun7777/final-seminar-46117193
- http://www.springer.com/cda/content/document/cda_downloaddocument/9783642147029-c1.pdf
- http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/A-Progress-Report-The-Alliance-for-Open-Media-and-the-AV1-Codec-110383.aspx
- http://www.streamingmediaglobal.com/Articles/ReadArticle.aspx?ArticleID=116505&PageNum=1
- http://yumichan.net/video-processing/video-compression/introduction-to-h264-nal-unit/
- https://cardinalpeak.com/blog/the-h-264-sequence-parameter-set/
- https://cardinalpeak.com/blog/worlds-smallest-h-264-encoder/
- https://codesequoia.wordpress.com/category/video/
- https://developer.apple.com/library/content/technotes/tn2224/_index.html
- https://en.wikibooks.org/wiki/MeGUI/x264_Settings
- https://en.wikipedia.org/wiki/Adaptive_bitrate_streaming
- https://en.wikipedia.org/wiki/AOMedia_Video_1
- https://en.wikipedia.org/wiki/Chroma_subsampling#/media/File:Colorcomp.jpg
- https://en.wikipedia.org/wiki/Cone_cell
- https://en.wikipedia.org/wiki/File:H.264_block_diagram_with_quality_score.jpg
- https://en.wikipedia.org/wiki/Inter_frame
- https://en.wikipedia.org/wiki/Intra-frame_coding
- https://en.wikipedia.org/wiki/Photoreceptor_cell
- https://en.wikipedia.org/wiki/Pixel_aspect_ratio
- https://en.wikipedia.org/wiki/Presentation_timestamp
- https://en.wikipedia.org/wiki/Rod_cell
- https://it.wikipedia.org/wiki/File:Pixel_geometry_01_Pengo.jpg
- https://leandromoreira.com.br/2016/10/09/how-to-measure-video-quality-perception/
- https://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping
- https://softwaredevelopmentperestroika.wordpress.com/2014/02/11/image-processing-with-python-numpy-scipy-image-convolution/
- https://tools.ietf.org/html/draft-fuldseth-netvc-thor-03
- https://www.encoding.com/android/
- https://www.encoding.com/http-live-streaming-hls/
- https://web.archive.org/web/20150129171151/https://www.iem.thm.de/telekom-labor/zinke/mk/mpeg2beg/whatisit.htm
- https://www.lifewire.com/cmos-image-sensor-493271
- https://www.linkedin.com/pulse/brief-history-video-codecs-yoav-nativ
- https://www.linkedin.com/pulse/video-streaming-methodology-reema-majumdar
- https://www.vcodex.com/h264avc-intra-precition/
- https://www.youtube.com/watch?v=9vgtJJ2wwMA
- https://www.youtube.com/watch?v=LFXN9PiOGtY
- https://www.youtube.com/watch?v=Lto-ajuqW3w&list=PLzH6n4zXuckpKAj1_88VS-8Z6yn9zX_P6
- https://www.youtube.com/watch?v=LWxu4rkZBLw
- https://web.stanford.edu/class/ee398a/handouts/lectures/EE398a_MotionEstimation_2012.pdf
- https://sander.saares.eu/categories/drm-is-not-a-black-box/
