jpeg-xl VS rav1e

I believe JXL's reference implementation isn't even to version 1 yet. 0.8.1 appears to be the latest. I could see them revisiting this once the reference implementation is considered complete.

I asked for this a while ago, not sure how things have progressed since then.

That license doesn't say anything about patents. This one does: https://gitlab.com/wg1/jpeg-xl/-/blob/main/PATENTS and only says that patents owned by Google are covered. So it may be that other companies patent the technology. The information in the repository is not enough to decide whether JPEG XL is safe to use.

The GIMP plugin is a great thing. But it still can't open/save images with special chars in their filenames. French, German and many other languages are affected. Could this be fixed soon? https://gitlab.com/wg1/jpeg-xl/-/issues/184

https://gitlab.com/wg1/jpeg-xl/-/blob/main/doc/developing_in_windows.md It's not as straight-forward to build as it is on Linux. I'm not sure if there are official binaries somewhere, sorry.

I'm guessing the reference implementation with complete git history is soon to follow? https://gitlab.com/wg1/jpeg-xl

The file format was 'frozen' last December: https://gitlab.com/wg1/jpeg-xl/-/tags/v0.2 Which is why FF can start implementing its usage.

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).