Menu Close

Tag: eficiencia

Jugando con h265

Con toda la llegada del mundo de resoluciones actualmente ridículas pero que en un futuro van a ser estándar para dar lugar a nuevas resoluciones ridículas (lease 4K) se vio necesario el desarrollo de nuevos codecs para seguir haciendo “mas” con “menos” e increíblemente lo han logrado. O en realidad, no tan increíblemente porque siempre te pasa que tenes un codec hermoso y te hacen otro mas eficiente aun. Este es el caso de h265 (HEVC), que viene a responder a las necesidades de “bandwidth” del vídeo en 4K.

Básicamente h265 promete mejor relación tamaño de archivo vs. calidad que h264 (a cambio de complejidad o sea, uso de recursos de la maquina) lo cual no solamente lo hace ideal para guardar y mandar esos gloriosos 8 millones de pixeles de vídeo, sino que también sigue siendo más eficiente que h264 para el viejo y querido vídeo en 720p y 1080p.

Y lo único que hice para probar fue agarrar un batch de 8 videos filmados directamente de la cámara, sin edición, sin correcciones de color, sin títulos, sin nada raro y pasarlos por el encoder de Adobe. Los originales son 1080p30 y se encodearon a 720p30 con h264 (AVC) y luego en 1080p30 y 720p30 en h265. No creo que los resultados sean realmente representativos ya que tiré los bitrates a “ojimetro” basándome en los presets del Adobe Media Encoder, por lo cual hay lugar para optimizar más aun. Lo que si te puedo decir es que el tiempo de encoding se dispara considerablemente (bastante mas del doble pero soy manco y me olvide de medir) usando h265 que h264.

Pero de todas formas, el titulo de este post es dice “Jugando” así que tampoco te estabas esperando un análisis en profundidad. Capaz que algún día lo hago, pero ya hay gente que sabe en serio de esto y ya lo hizo, como por ejemplo ExtremeTech. Mis resultados chanchos son los siguientes (en naranja los originales):

Comparacion poco seria entre h264 y h265
Comparacion poco seria entre h264 y h265

Anecdoticamente agrego que estos mismos vídeos tal cual tomados por la cámara pesan unos 5GB aproximadamente [1], esto se debe en parte a que las cámaras no pueden andar desperdiciando recursos en encoding y en otra parte porque usa un formato retardado llamado Quicktime. En realidad Quicktime no tiene nada que ver, pero me gusta darle palo.

Bueno no se si te esperabas menos, o te esperabas más. Para mi bajar cerca de 60MB en ambos casos no esta nada mal considerando que no me puse a jugar con los parámetros. Te diría que es compresión “gratis” siempre y cuando el tiempo de encoding no sea drama (o que no tengas un CPU muy polenta, esto lo hice en un i7-6700k).

Aca te van los tamaños reales de los archivos para cada caso:

En cuanto a que encoders hay en la vuelta, esta lleno de encoders pagos, pero gratuitos… … …

La gente de VideoLAN está manteniendo el codigo fuente de x265 y un programa que lo implementa es el gratuito y fácil de usar Handbrake que ademas también implementa x264. En cuanto a los pagos obviamente no he probado ninguno y no pienso perder el tiempo. Si tenes acceso a la suite de Adobe CC, el Adobe Media Encoder anda muy bien, es cómodo de usar (sobre todo en batches) y ya viene con un montón de presets (ademas de dejarte ser granular con unas cuantas cosas).

En cuanto a si le voy a dar uso, depende. Por ahora probablemente voy a seguir pasando todo lo de la cámara a h264 [2] ya que la reproducción obviamente también consume mas recursos en h265. Prueba de esto es que tenemos un Intel Compute Stick conectado en la TV del Living y parece costarle reproducir vídeos encodeados en h265 1080p30. En una de esas le tiro un 4K a ver como se prende fuego.

[1], [2]: En realidad de la cámara ya vienen en H264/AVC dentro de un contenedor Quicktime, pero tienen un bitrate ridículamente alto y el encoder de la cámara no es muy complejo, porque requeriría que las cámaras pasen a ser computadoras prácticamente. La conversión que hago es usar el preset de mas alta calidad en Adobe Media Encoder donde generalmente los vídeos resultantes me quedan del 10% o menos del tamaño original.