PEC2: Codificación y distribución

Descargar todos los archivos

Si prefieres descargar todos los videos, imágenes y archivos de la PEC de una sola vez, puedes usar el siguiente enlace:

Contenido del archivo ZIP (71.5 MB):

• 📹 Videos originales: asset-01.MOV, asset-02.MOV
• 📹 Videos HEVC: hevc-75.mkv, hevc-50.mkv, hevc-50-gop-35.mkv, hevc-50-gop-15.mkv
• 📹 Videos DVD: pec2_dvd.mpg, pec2_dvd_m3_n9.mpg
• 🖼️ Todas las imágenes de análisis (.png)

Tarea 1.1

Se ha usado el códec H264, o AVC, es un codificador con perdidas, tal como se indica en los apuntes de la asignatura, p.10, y en la entrada de la wikipedia.

Tarea 1.2

1080x1920, con 29,985 fps, con una duración de 10,638 segundos, por tanto el tamaño sería sin comprimir seria:

1080x1920*29,985 por cada segundo, como son 10,638 sería multiplicarlo por esa cantidad, teniendo en cuenta los bytes por pixel de color (3 bytes = 24 bits) (p. 62 de los apuntes de la asignatura)

Tamaño total: 1080x1920x29,985x3(bytes)x10,638 = 1.984.313.458,94 bytes ==> 1.892 GB

Tarea 1.3

Con el tamaño en bytes, que son 13.483.693 bytes (información del archivo en Mac OS), y con el tamaño total en bytes el factor de compresión es:

Factor = 1.984.313.458,94 / 13.483.693 =~ 147

Por tanto es de 147:1.

Tarea 1.4

El contenedor es el QuickTimeFileFormat(QTFF), con extensiones *.qt o *.mov (este caso), es un contenedor propietario de Apple y cuadra con la tabla del punto 3.3 del módulo.

Tarea 1.5

El primer fotograma es I-FRM y el segundo I-BRM.

Tarea 1.6

Hay 11 frames tipo I-FRM.

Al ser una imagen estática necesita, teóricamente, menos cuadros I para poder usar esos como referencia para construir el vídeo entero, a más movimiento en la imagen más cuadros I necesarios para estimar el resto del vídeo. Lo que se observa en el vídeo es que cuando me ha temblado el pulso, hay un Frame I porque detecta un movimiento, si hubiera usado un trípode quizás no hubiera pasado.

Tarea 1.7

Podemos decir que se basa en una estructura de I/P/B, típica de compresión. Se estructura en 11 GOP: 1 IFRM, diversos P-FRM y B-FRM, unos predictivos y los bidireccionales. Esto se ajusta a la forma en que el H.264 se aprovecha de la redundancia temporal entre imágenes consecutivas para comprimir mejor el vídeo. Dado que el contenido del vídeo es muy estático, la diferencia entre fotogramas es muy poca y se puede apoyar en más frames P y B, y menos I, con lo que se reducen los GOP.

Tarea 1.8

Si, hay que tener en cuenta no cortar el video en mitad de un GOP, conviene hacerlo desde el I-FRM anterior o posterior para no provocar errores en los frames P y B en medio del GOP cortado, te obligaría a recodificar.

En los foros de Avidemux te indican que uses el modo copy para editar y que estos puntos se hagan desde I-FRM o al menos desde P-FRM.

Tarea 1.9

Da bastante más información. Coincide en todo lo esencial, códec, contenedor, propietario, pero Mediainfo te da información del perfil High@L4, los ajustes del formato CABAC y 4 ref Frames, la velocidad variable de fotogramas, la tasa de bits y muchos metadatos de la forma, la hora y el dispositivo de grabación.

Tarea 2.1

1080x1920, con 30 fps. Duración 10,466 segundos.

Tamaño total: 1080x1920x30x3(bytes)x10,466 = 1.953.206.784 bytes

En GB, son 1.862,72 GB.

Tarea 2.2

En cuanto a características formales, son las mismas y da más información. Me ha llamado la atención que este vídeo ha pasado por un proceso: grabado con un iPhone 14 Pro Max, subido a Google Fotos y migrado a Immich (self-hosted), no me he descargado el vídeo original, lo he perdido, Google lo ha convertido con sus librerías y códecs. El formato del vídeo es AVC, el perfil es High@L4 como el H.264 pero en General de Mediainfo sale:

Formato: MPEG-4

Formato del perfil: Base Media / Version 2

ID códec: mp42 (isom/mp42)

Nota: Estoy realmente molesto por esto.

Tarea 2.3

El factor de compresión es:

Factor = 1.953.206.784 bytes / 11.324.620 bytes = 172,47.

Podemos determinar un factor de 172:1 de compresión.

Tarea 2.4

El primer frames es I-FRM y el segundo B-FRM.

En este vídeo solo hay 6 I-FRM, tengo peor pulso que un géiser en acción. Voy a ir al neurólogo, definitivamente.

La relación es la comentada en la tarea 1.6. Necesita esos I-FRM para reconstruir el vídeo con los B-FRM (bidireccionales) y P-FRM (predictivos).

En el clip se pueden observar los mismo elementos: un I-FRM, seguido de varios B-FRM con bastantes P-FRM por grupo (hasta 8 he contado en un GOP).

Tarea 2.5

Pues como he comentado, creo que las diferencias son que mi pulso no ha sido el mejor y creo que ha pasado por procesos de estabilización de imagen en el proceso de subida a Google Fotos y eso ha influido, creo yo. Aunque las características de subida eran "conservar la imagen original" quizás no se ha cumplido.

Tarea 3.1

El formato para DVD es el MPEG-2. Si se solicita BlueRay sería el H.264/MPEG-4 AVC pero sería mejor, a día de hoy ya, hacerlo con H.265/HEVC, por ser un formato más moderno y asociado a calidades de 4k.

Tarea 3.2

Restablecer FPS. Cambiar FPS puede implicar añadir o eliminar fotogramas, cambiando la duración del video y lo que se pide es pasar de 30 a 25, y para eso mejor restablecer los fps.

Tarea 3.3

El pec2_DVD ahora pesa 8,45 MiB (según Mediainfo), por tanto el factor de compresión es:

Factor = 1.953.206.784 bytes / 8.860.467 bytes = 220,44.

Es una compresión 220:1.

Tarea 3.4

A ver si M=3 y N=9, 9 es la distancia entre dos I-FRM, por tanto en tamaño del GOP es 9. Y como M es la distancia entre uno I-FRM y un P-FRM, entonces si la distancia es 3, el numero de B-FRM es 2.

Tarea 3.5

Ahora tiene un tamaño de 9,30MiB, por tanto el factor es:

Factor = 1.953.206.784 bytes / 9.751.756 bytes = 200,29.

Es una compresión 200:1. Es normal porque hemos limitado el tamaño del GOP y le hemos dejado menos margen al codificador para optimizar la compresión.

Tarea 4.1

HEVC significa High Efficiency Video Coding, también conocido por H.265 y ofrece una doble compresión de datos, mejor calidad y mismo bitrate. Soporta resoluciones de 8k y se usa mucho para reproducciones 4k.

Tarea 4.2

En H.265, los perfiles principales son Main, Main 10 y Main Still Picture, aunque se añaden muchos perfiles de extensión para manejar la profundidad del color, escalabilidad y el contenido en pantalla. Sus niveles van del 1 al 6.2, con ampliaciones hasta 7.2 y 8.5 en revisiones.

En H.264, los perfiles principales son Baseline, Main y High, y los niveles van del 1 al 6.2.

Comparándolos, H.265 tiene un conjunto acotado de perfiles de uso común y extensiones más modernas orientado a contenido de alta definición y de transmisión.

Tarea 4.3

El nivel de codificación es el campo IDC Level.

Tarea 4.4

Para H.264, baseline, main, high, high10, high422 y high444.

Para H.265, main, main10 y mainstillpicture.

Tarea 4.5

El Mediainfo creo que nos da la tasa de bitrate.

Tasa de bits general: 8 602 kb/s

Voy a calcularlo, el tamaño del asset-02 en bytes son 11.324.620, eso tengo que pasarlo a bits, y dividirlo entre los 10,466 segundos.

Son 90.596.960 bits entre 10,466 segundos == 8.656.311,87 bits

Pasado a Kb, son 8656 kb/s. Parecido a la información del Mediainfo.

75% = 6492 kb/s | 50% = 4328 kb/s

Ahora si, el factor de compresión respecto al asset-02:

Factor = 11.324.620 / 8.367.636 = 1,35:1

Tarea 4.6

Sería:

Factor = 1.953.206.784 bytes / 8.367.636 bytes = 233,42

Es un factor de 233:1.

Tarea 4.7

Ahora el tamaño, con el dos pasadas y 50% es:

Tamaño de archivo: 5,51 MiB

Factor = 11.324.620 bytes / 5.777.653 bytes = 1,96

Factor = 1.953.206.784 bytes / 5.777.653 bytes = 338,06

Entre el asset-02 original y el x265 al 50% se ha pasado de una proporción de 1,3 a 1, a una de casi 2 a 1, al reducirse a la mitad, ahí el cambio.

Con respecto al original sin comprimir, se ha pasado de 233 a 338.

Con mis ojos yo no distingo ninguna pérdida de calidad entre el vídeo original y los dos videos generados de 75% y 50%, me parecen bastante parecidos. Pero bueno, tampoco soy el mejor ejemplo. Creo que es así porque el original estaba ya en buena codificación y que no hemos rebajado tanto la calidad del bitrate para perder fotogramas. Si hubiéramos puesto 1500 quizás si lo notaría.

Tarea 4.8

Sinceramente, no veo diferencia. Se ven las olas del agua al explosionar, las sombras de las nubes. No acabo de ver la diferencia. No veo que se pierda nada. Pero sin duda soy yo, no tengo ojos para este tipo de cosas, la verdad. Veo al Minecraft un juego con unos grandes gráficos, la verdad.

Tarea 4.9

En el de 15, los I-FRM son cada medio segundo, en el de 50 solo había dos en todo el vídeo. En el de 35 son cada 1,2 o así, si ha variado bastante.

En cambio, la compresión del fichero no ha variado mucho:

• 50 - 5,8MiB
• 50 y 35 - 5,7MiB
• 50 y 15 - 5,8MiB

AWS

En el caso de AWS toda la distribución parte de su servicio de AWS Cloudfront. Debajo existen servicios para la generación, codificación y transcodificación, empaquetado y finalmente, distribución.

Estos sistemas en lugar de tener una única copia del vídeo, generan diferentes copias con diferentes códecs, resoluciones y bitrates y la distribuyen al usuario en función del dispositivo conectado. Es el proceso antes mencionado como transcodificación, no es lo mismo servir 1920x1080 a un móvil, que a una pantalla de 65 pulgadas de una tele. Servicios selfhosteados como Jellyfin realizan el transcoding en vivo cuando se pide el fichero por un navegador web y usa recursos propios como la tarjeta gráfica del host servidor. AWS lo hace a lo grande y así no lo tiene que hacer en vuelo mientras se distribuye el contenido.

Para el caso de VOD Amazon tiene el servicio Elemental MediaConvert, un servicio de procesamiento de vídeo basado en archivos, pensado para propietarios y distribuidores de contenidos con bibliotecas de cualquier tamaño. Su objetivo es transcodificar un original a diversas salidas (web, móvil, televisión). Ofrece servicios de compatibilidad, HDR o DRM.

Para la emisión en directo, y deben saberlo bien que dominan el mercado con Twitch, tienen el servicio AWS Elemental MediaLive, que a partir de una señal origen en vivo, genera varias salidas para Broadcasting o multipantalla. Después de la codificación, la señal pasa a MediaPackage para el empaquetado en vuelo que comentaba antes y derivarlo a los diferentes dispositivos y se traspasa a Cloudfront que es el punto cercano al usuario para reducir la latencia.

Como se puede ver, según la documentación de AWS, el servicio no solo es el servicio o codificación de un archivo, es un end-to-end para un flujo profesional: creación de múltiples perfiles de calidad, entrega adaptativa, protección del contenido, integración con almacenamiento y analítica, y soporte tanto para vídeo en directo como en diferido. Es una plataforma muy útil para streaming, televisiones, eventos en directo, catálogo VOD.

Los costes como es habitual en AWS tienen una estructura de pago por uso y unos límites gratuitos bastante correctos. Hay demasiadas cifras que no creo que aporten valor referencia aquí.

En cuanto a las ventajas, permite escalar rápidamente, sin grandes inversiones en servidores o codificadores, almacenamiento para tener las diferentes copias de los archivos y este tipo de economías de escala. Permite llegar a clientes de todo el mundo, con baja latencia asegurando la propiedad intelectual y la accesibilidad, vía subtítulos. Como hemos visto, separa cada parte del flujo de transmisión.

Pero también existen los problemas, el primero, el habitual, la falta de claridad en la factura, el coste variable es un dolor de cabeza para las empresas ligadas a AWS. La complejidad de montar toda la infra necesaria también implica la contratación de personal especializado en este servicio lo que se asocia a la dependencia de un proveedor, lo cual también es un hándicap.

Como conclusión, vemos que AWS tiene una plataforma end-to-end, que facilita la puesta en marcha de proyectos pero que tiene asociado unos requisitos que se deben analizar.