@niccolove @niccolo_ve

Comment on this video (which us not shown on my Fedi instance, yay federation!)

https://tube.kockatoo.org/w/63cGWTvhzqu2bwMGsh3QcF

I cannot believe that that GPU is not usable for video work. That is what GPUs are made for!

Poorly, there are a few caveats:
- there are always more DEcoders supported than ENcoders. I guess not being able to play a video (it would play but be less efficiently decoded on the CPU) is worse than being bound to #h265 instead of #av1 for recording.
- thus it makes sense that GPUs generally work flawlessly for gaming, as that is just displaying videos (or rendering content, which is kinda different, no idea why video codecs are more difficult than rendering methods)
- for every video format out there exists an encoder. If you use software rendering (on the CPU), you can use ANYTHING. Like encode to modern (and free!) AV1 using #svtav1 on any old CPU.
- if you want to encode videos on a GPU, you need drivers, but also a different encoder. On #NVIDIA you use #NVENC (NVidia ENCoder), for example nvenc_x265 for h265/HEVC videos. On #IntelArc (and afaik AMD GPUs), you use the #QSV (quick sync video) library which builds on top of #VAAPI, which is open source. So you can encode to AV1 using qsv_av1 for example.

What encoders are supported depends on the GPU a lot. Intel Arc seems to have supported the free, efficient and future-proof AV1 codec the earliest, but also the older free codecs VP9 and VP8 (also used in webm), like in a GPU I recently bought used. My older NVIDIA GPU only supports H265, which is proprietary and often less efficient than AV1 (not always, video codecs are black magic).

As OBS can use your GPU for video capture (encoding), the issue is purely in software support.

I only have experience with #ffmpeg for re-encoding videos, but that is also in many video editing tools. Try if you can get them somehow.

For NVIDIA I needed the latest proprietary drivers (#NixOS makes this extremely easy, can recommend) and ffmpeg, nvenc worked out of the box.

For intel Arc I used the regular drivers included in the kernel, but after adding the QSV runtime to my "hardware.graphics.extraPackages" I needed to recompile the entire kernel. Using a #longterm kernel (currently 6.18) makes this more viable... longterm XD.

#MicrosoftSurface #KDENlive #Shotcut #VideoEditing

I've tested SVT-AV1 and the RX7600 AV1 hardware encoder with Unbeatable recordings and for this game specifically they look nearly the same.

If I look at zoomed-in freeze frames, I'd even say the hardware encoder often wins by having less compression noise.

But while playing the video, they all look same which is still wild because the hardware encoder is of course way faster.

Maybe SVT-AV1 struggles with this game, I don't know.

(Exact settings in a reply)

#AV1 #SVTAV1 #Encoding

Okay, next big thing: get `svt-av1-psyex` packaged up for installation on Arch Linux. Figured the easiest way would be to grab the PKGBUILD for `svt-av1-psy-git` and tweak as necessary. Also, need to add Dolby Vision and HDR10+ support because reasons.

#archlinux #svtav1 #pkgbuild

Final tests in and the quality is outstanding. Going from the stock `svt-av1` encoder to the `svt-av1-psyex` encoder is already a nice bump in quality, and the encodes are faster using `av1an` due to using every ounce of the CPU. The `lsmash` speedup is nice as well as the stock method for chunking took a bit longer post-detection.

Also, can't say enough about the Ryzen 9 HX 370: did a great job with the encodes and only burned through ~24W during the encodes along with the Thinkpad that kept the temps around 68C.

#svtav1 #encoding #av1 #av1an

Doing a test with `av1an` and `SvtAv1EncApp` (`svt-av1-psyex`). This poor laptop is absolutely getting hammered at the moment...lol

#svtav1 #encoding #av1an

This is a mildly promising #Copilot #AI result - a short screencast.

It's "incogiCopilot", in a #Chromium #incognito session. I've changed my public IP address, and restarted a fresh Chromium process, prior to recording.

I've asked "how to limit the CPU load, using the #SVTAV1 software encoder in #ffmpeg" - i've down-voted + corrected some results.

I've attempted to get the proper answer, about 17 hours later, with a fresh IP.

Nope, corrections take longer - pause video, for reading.

For those venturing in AV1 via `ffmpeg`, a word of warning: if muxing to Matroska via `ffmpeg` make sure you remux afterwards. Programs like `mpv` get very pissed off when seeking the resulting Matroska file and you will pull your hair out because of it. Run it through `mkvtoolnix` and enjoy proper seeking!

With respect to quality, this is pretty good. The "film grain" is captured very well and the overall quality of the encode is great. I still think I can get the overall size numbers down, but it's a good start. #av1 #svtav1 #encoding #matroska #mpv