Es siempre interesante descubrir nuevas cosas, o conocimientos, tecnologias, pero llegado a cierto nivel, cansa, agota
Leyendo sobre las (des)ventajas (costos, adopcion, requerimientos de hw, etc) del nuevo estandar que lentamente se esta imponiendo en el mundo de la #transcodificacion de material #audiovisual, parece ser que no deja de ser compleja la decision
Bajo las condiciones actuales, #x264 y #x265 son mejores opciones para los usuarios finales, porque parece que consumen menos, son mas extendidos y soluciones como #jellyfin se llevan muy bien con ellas
Por el contrario, #AV1 no tiene costos de patentes, las futuras tarjetas graficas ya estan añadiendo por defecto soporte desde fabrica, PERO actualmente consume lo suyo, y si no inviertes en una grafica decente, a duras penas podras transcodificar archivos multimedia

My 4K Blurays of Westworld arrived in the mail today. I started copying and re-encoding episode 1 of season 2, because I have already watched all of season 1. It's estimated to take 17 hours. Most episodes are going to take about the same amount of time. 4K video is rough to work with! 😅

I guess it will slow down how fast I watch them ...

#Video #Encoding #x265 #4K #SciFi

I am compressing movies with ffmpeg and I don't understand why libx265 is slower than libav1 with the same settings. I have an amd rx 570 gpu and ryzen 5 3600 cpu if that makes a difference.
#x265 #av1 #av1codec #ffmpeg
I have a weird behaviour of #ffmpeg on #NetBSD: when transcoding a video (either from an existing video or from still frames, doesn't matter) with #x264, everything is fine. But when I encode with #x265, the ffmpeg process sets itself to niceness 20. I can trace the system calls, and it does indeed call setpriority with x265, and not with x264, but I cannot find it in the source code.

This happens with both ffmpeg5 and ffmpeg7 on NetBSD, but not on Ubuntu. I haven't yet tested anything else.

Normally I wouldn't mind if a CPU-hungry encoder runs "nice", but I would like to decide that for myself, and in my current setup, the CPU clock modulation daemon ignores nice processes and so doesn't raise the frequency, and so my encoding runs slow. And non-superusers cannot lower the niceness.

Another weird NetBSD problem. Please help or boost.

HandBrake 1.10.1 was released. This release fixes a visual corruption issue that could happen when encoding with x265. All users are encouraged to upgrade to the latest version because this issue occurs on all platforms.

https://github.com/HandBrake/HandBrake/releases/tag/1.10.1

#handrake #x265 #encoder

Got another box of surplus #DVDs to rip. I hadn't ripped anything lately, especially since getting our new mini PC, so this was my first chance to compare #x265 to #AV1 encode on our Minisforum UM890 Pro with a Ryzen 9 8945HS. This thing absolutely rips. AV1 encodes of DVD quality content run at hundreds of fps, depending on the movie. When using Handbrake's best recommended settings and comparing to x265, AV1 goes faster, makes smaller files and looks just as good.

https://handbrake.fr/docs/en/latest/workflow/adjust-quality.html

HandBrake Documentation — Adjusting quality

Raspberry Pi HEVC Decoder Driver Posted For Linux Kernel Review

The latest work that Raspberry Pi is working to upstream to the mainline Linux kernel is a HEVC/H.265 video decode driver that works on Raspberry Pi 4 and Raspberry Pi 5 single board computers.

x265 is considerably more efficient than x264. I just re-encoded the entirety of my copy of Farscape, from the same Bluray source discs. Here's a comparison of the final file size for each copy. Settings were as follows:

Both copies were encoded with an RF of 20, 1080p, framerate same as source. The #x264 copy only had a 160 kbps AAC stereo audio track. The #x265 copy included that, but also included an un-touched DTS-HD-MA surround sound track, as well as commentary audio tracks.

#Media

A question for any #digital #video experts out there... I'm confused as heck about the results from #libx265 (used via #ffmpeg, not the #x265 tool) regarding quality vs. preset and ratefactor.

I'm far from the first person to be confused by this, but I haven't found any real answers.

First I'll just show some analysis from some test encodes of a file; ssim and ratefactor numbers are coming from the CSV stats output of libx265.

1/x

#quality #preset #ratefactor #CRF #encode #encoding

Oooohhhhh #x265 v3.6 release notes:

"ARM64 NEON optimizations:- Several time-consuming C functions have been optimized for the targeted platform - aarch64. The overall performance increased by around 20%. SVE/SVE2 optimizations"

Thanks, y'all! I love it when codebases start coding to ARM64 NEON! #FFMPEG #FFMPEG7