vipsdisp VS rav1e

if you're using linux (which it doesn't seem so) there's also vispdisp https://github.com/jcupitt/vipsdisp which is based on https://github.com/libvips/libvips which will likely take over how images are decoded in the future for everything, at least methodology wise.

Yes, I based it partly on visual programming system that Canon made back in the 90s. I loved the interactive development, but I really disliked that style of visual programming. Lines between boxes seems very hard to reason about, to me.

nip2 tries to do something similar, but using expressions, like a spreadsheet. Unlike graphical plugs and wires, expressions allow things like copy-paste, smart refactoring, referential transparency, and progressive rewriting.

nip2 is ancient now (I finished it way back in 2002, I think). I've started a rewrite for gtk4 -- the image display window is here:

https://github.com/jcupitt/vipsdisp

It's quite fancy -- it has a sparse pyramid of image tiles which get composited to your display by the GPU, and computed asynchronously by a libvips pipeline as you zoom and pan around. You should get a smooth 60 fps even with enormous (eg. 300,000 x 300,000 pixel) images.

Sure. You'll see it very often in codec implementations. From rav1e, a fast AV1 encoder mostly written in Rust: https://github.com/xiph/rav1e/tree/master/src/x86

Large portions of the algorithm have been translated into assembly for ARM and x86. Shaving even a couple percent off something like motion compensation search will add up to meaningful gains.

Or the current reference implementation of JPEG: https://github.com/libjpeg-turbo/libjpeg-turbo/tree/main/sim...

Again, if anything AOM would be the one restricting licenses to AV1 (if they chose to) except AOM has stated and also published AV1 in a way to allow license free access to development (which allows people to make forks of the official build like it's open source) and usage. (1)(2) I don't see why they would suddenly change this.

You can speed up the sampling process with --vmaf n_subsample=5, which in my experience works more accurately than either 2 or 4, possibly due to this bug/feature present in multiple encoders. You might also need to manually set the number of threads used for VMAF calculation with --vmaf n_threads=16, but YMMV.

That remember me of https://github.com/xiph/rav1e which is an AV1 encoder

I put in the request for ffmpeg passthrough mastering-display data a few years ago and haven't heard of any support yet.

It's getting there.. Initial steps for FFmepg: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8444 rav1e: https://github.com/xiph/rav1e/pull/3000

It's entirely possible to re-use bits of other HW encoders for the first pass (motion estimation, etc).