JPEG XL

I have played lots of music video games and keysounds are really important for them (though they are hard to produce), playing 100s of them is not that uncommon...

Not sure if this is the right channel, but for a project of mine (a simple game), I’m looking for a simple image format that I can use to compress images. The format should be relatively simple, but still be able to decompress images easily and efficiently (compression complexity doesn’t matter). I’m looking to implement the decompression myself. I don’t mind coming up with a format myself, but I don’t want to invest a long time writing an implementation. The images aren’t very big, and they use a predetermined 256‐color palette. Yet, as I (by preference) have them in the project in C source form, they end up taking more than I hope they would, besides being uncompressed in the binaries themselves, which, albeit currently not so, seems to be increasingly growing more significant, specially because I serve the files to be playable in a browser.

Why not just use any format a browser supports and let the browser do the decoding? You want the game to be portable and compilable to native code too?

Yes.

browsers are not particularly good for game engines

Also, I have the rendering set up in a specific way that (by design) doesn’t allow colors ourside of my palette to be represented without modifications.

depending on kind of game ofc

if you need browser support then something like lossless webp or png sounds kinda okay

but if you wanna offline game to be packaged w your own format then it's a bit different...

It is a pixel‐art game, so rendering is done on the CPU, and that works sufficiently well. It renders to a 512×256 bytes buffer (one byte per color), then JavaScript code takes that buffer and converts it to an `ImageData` and puts into into the canvas.

Ah, sorry, I changed it in the last version and forgot (like an idiot). It actually converts it to a 4‐byte per color RGB buffer in C code, (which is then set to an `ImageData` and to a canvas from JavaScript like before). (Though it’s not like this matters for my purposes.) At any rate, I don’t want to have the images be separate from the binary file, because I want for the binary file to be enough to run the game (or at most have a small driving code).

Maybe just some simple RLE like PackBits could work for you? That's quite easy to implement, compression is of course not great but it's not horrible either for pixel art...

Does QOI use RLE? it's conceptually very simple

Back in the day, PCX format was pretty popular. Decoder could be easily written in assembly as well.

Audio is sort of a done thing compression wise. You use opus for lossy and FLAC for lossless.

Can someone translate this? What part of AV1 is he asking about?

aom fork and like how much better the extra parameters can be https://github.com/Clybius/aom-av1-lavish

Oh god.

aom-av1-lavish = aom-av1-psy continued 🙂

Thank you three for your suggestions, I will take a look into those options! I feel like QOI isn’t the most suitable for what I want because my images are not arbitrary “truecolor” RGB, but rather one‐byte indexed into a color palette. I don’t know if PCX would be similar in this regard.

PackBits is very simple and works ok for planar byte-based data. It's just one byte to say either "run of 2..128 same values" followed by one byte (which is repeated that many times when decoding) or "now come 1..127 literals" followed by that many raw bytes.

This is what TIFF and PSD often use

(they can also do just uncompressed, or deflate with optional Left filtering, but PackBits is what I see a lot, for 8-bit images at least)

lossless is bigger than lossy 😳 😳 😳 😳 😳

ZPEG ?

https://gdcc.tech/results2020/

pglz looks very interesting: much faster than Brotli and Zstd, and compression is better 🤔

some old talk, but on the topic arguing formats complexity and about av1/av2 https://youtu.be/3qL5FdEBiGA

🤔 https://svgwg.org/svg2-draft/

🥱 It's all the lie

svt-av1 -preset 10 enable-cdef=0 SPEED be like x264 veryslow on 960x540

there is no indication what exactly the parameters are used. as well as the complete absence of the designation of the properties of the video, what is the frame size, what kind of content. what functions were used for parallelization. these are not tests, this is bullshit

so I did tests with the owner of AVX, and it turned out that my SSE AV1 encodes 20% slower than AVC, but AVX AV1 has the same parameters 30% faster than AVX AVC - and how to create presets with "the same speed" in such a situation No how, welcome

this is old video, so the graphs are not very relevant anyway, also it's a 48-core cpu, but the main point is that the new gen formats should be better even with the same complexity as the old ones, not just increasing efficiency at the expense of complexity

that doesn't mean anything to me

AV1 be like if you have the strength to lift 100 kg at a time, I congratulate you, but real people prefer to take 2x6 liters in bottles maximum

for me svt-av1 is pretty fast, faster and better for low bitrates than x264 and x265, but, for high fidelity I still prefer x265/x264, but only because the encoders have more options for tweaking and better psy-rd modes current av1 encoders are faster for any relatively modern systems, if taking a 30-year old cpu, then like anything more complex than mpeg1 will be bad and slow, it doesn't work that way

according to my small test for ~100 people, people do not see the ass at all, between AVC and AV1 At the same encoding speed and identical file size

ofc av1 is better

<@794205442175402004> <@1034873369314730065> the problem will be much more obvious there is just asking where is AVC and where is AV1. Without asking which picture is better

👉 👀

of course, about 90% of people say simply - yes, there is no difference here

if someone knows what artifacts are typical for a specific encoder, it is not too difficult, if it is not very high bitrates and not transparent quality (when any encoding is difficult to differ from the source)

yehh.... I can distinguish about ~6 video codecs only by artifacts

The First is SVT

I'm fully decided

I looked at hair

And it has heavy svt artifacts

Looks like an old version

1.4.0?

lasted

Last you mean the second image or latest svt

Second is avc?

I agree. If new codecs can't do more than old codecs can when given the same amount of wall time to work with, then it's not a very impressive algorithm.

If they require 10x the amount of time but only barely at best get 2x better compression, then "maybe one day it will be useful"

the "maybe one day it will be useful" is definitely worth it. see machine learning

50% better efficiency in reality is also mostly only for very high resolutions and lower bitrates, for higher fidelity the current encoders may be even worse than the old ones (but I think if comparing theoretically perfect encoders, they will be better, but still marginally)

What is useful or not depends a lot on the use case. Storage has a cost that is proportional to how long you want to store it, while encode is a one-time cost. For long-time storage, spending a lot of compute to save a few percent of space can be worth it, and latency is not very important. For realtime one-to-one communication, the trade-offs are very different.

Grain synthesis is a good example of making smaller, having decent fidelity and not increasing complexity very much. I've tried different settings, but seems like x264-265 simply can't beat av1 in grain settings. Quite often it's double size difference at the same speed and quality.

yeah, but it's still not high fidelity and there is a lot of content where the grain is noticeably different from synthesized, at higher bitrates x264/x265 preserves the original grain and details much better, which any of the av1 encoders without grain synthesis can't and especially on very heavy grain the synthesized patterns become very noticeable also svt-av1 has better grain synthesis than other av1 encoders

How’s the workflow when using grain synthesis? Is there an automated process or do you have to manually denoise the video and configure the correct amount of noise?

automated or by manually specifying photon-noise or with some tools, but this is a very approximate synthesis

https://www.phoronix.net/image.php?id=2023&image=fosdem_vvenc_1

xpsnr?

XPSNR? What is that?

`The logarithmic XPSNR output values are in a similar range as those of traditional PSNR assessments but better reflect human impressions of visual coding quality` https://github.com/fraunhoferhhi/xpsnr

Also: why another patent encumbered codec?

Interesting. I will have to check if XPSNR is any good for still images.

I doubt it though, looks like it is very much aimed at video

~14:00 about XPSNR https://mirrors.dotsrc.org/fosdem/2023/K.3.401/om_vvc.webm

and why make a codec for VVC/H.266? i think because it's Fraunhofer HHI

Open source software for patent-encumbered codecs feels a bit silly imo. You can see the code, but if you want to use it, you possibly have to pay royalties, or at least get a lawyer involved to check...

yeah, but it's nothing new though, the same as for mp3, aac, avc, hevc, ... there is a lot of open source software and I don't think anything will change for patent-encumbered formats

vvc probably won't be widely used for streaming (although afaIk it's already used in china and india by some big streaming services) but for other professional uses I don't think everyone will refuse mpeg and other proprietary formats in the near future

do you have the power to encode aomenc speed 8 (maximum fast) - use it. don't use svt-av1 <:AV1:805851461774475316>

Aomenc cpu 8 is much better for colours

Better White

Compared to svt preset 12

Svt hasn't surprised me

But now weight half

Off cdef, use hierarchical-levels=2. For use preset 9 or minimum 10

preset 12 is just bullshit

aomenc also has faster modes with `--rt` and at comparable speeds svt-av1 is usually better at fast and medium encoding speeds and has better multithreading, also depending on content at higher bitrates svt-av1 might be better at the slowest modes, have less smoothing, better details also svt-av1 has better grain synthesis but, aomenc has better tuning potential, has some forks with additional options and better on average at slower speeds (like 1-4), though for some videos I got better results with svt-av1 (preset 1-2)

But I'll just say ATOM -cpu-used 8 destroys any SVT-AV1 mode from 5 to 12

But I'll be honest, in the 5 years I've been working with AV1, this is the first time I've heard that AOM has a Real Time mode

I want to say that even in conditions when SVT-AV1 is encoded slower than AOM, for some reason it has such a large number of stupid artifacts, problems with color gradient, problems with the rendering of the cell/grid, problems with block Jitter, it's all very noticeable....

I checked this mode, and yes, as I thought, it just like bullshit

And AOM encodes 2-4 times faster flat 2d frames

yeah, and mostly such problems on live streaming speeds 8-10 and `tune=0` (modes -2-0, 11-13 shouldn't be used in general, it's like debug dev modes), though some are fixed in new versions I still notice some random blocking or even corrupted blocks on some frames, but it's almost unnoticeable during normal viewing, only when comparing static frames also only svt-av1 is capable for real time encoding with good quality, aom is much worse and slower on --rt modes on slow svt-av1 modes and higher bitrates I haven't noticed any problems yet, also I usually disable some of this filtering: `--film-grain-denoise 0 --film-grain 0 --enable-cdef 0 --enable-restoration 0`, but at low bitrates quality might get worse

--film-grain-denoise 0 --film-grain 0 Deflaut Off

`--film-grain` is needed for grain synthesis (with non-zero values), but it noticeably slows down encoding and also decoding `--enable-restoration` does not affect visually as much, but sometimes, also disabling it usually lowers the most metrics scores

I know all this

cdef really strained me when AV1 just came out, both then and now it Use too much when decoding, an inconceivably much, about half of the entire decoding time is a CDEF filter

no, denoise is on by default, but synthesis is off `--film-grain-denoise Apply denoising when film grain is ON, default is 1 [0: no denoising, film grain data is still in frame header, 1: level of denoising is set by the film-grain parameter]`

it's on, but it doesn't work

same like enable-restoration

they are working, but in auto mode, maybe they are turned off when not needed or at very high speeds enable-restoration also works, disabling/enabling it slightly changes the metrics scores

no, they don't work. they just don't work.

while the other modes are off, these modes simply don't work. they can't work on their own

AOM sharpness=0 is good function

same bitrate, same settings (except film-grain-denoise and film-grain not specified) preset 6 film-grain-denoise 0

film-grain-denoise 1

Are you sure it's called working?

works, but it doesn't mean it always does something good, also it's a limited bitrate just for testing

meh

and also `enable-restoration` on and off graphs so something is changing

film-grain: Invalid parameter hm for aom another name?

yeah, aom has different options ```--denoise-noise-level=<arg> Amount of noise (from 0 = don't denoise, to 50) --enable-dnl-denoising=<arg>```

what

which of these functions is responsible for disabling the generation of noise?

something like that `--film-grain-denoise` = `--enable-dnl-denoising` `--film-grain` = `--denoise-noise-level`

so for aomenc `--enable-dnl-denoising=0 --denoise-noise-level=0`

denoise-noise-level=0:enable-dnl-denoising=0 denoise-noise-level=0:enable-dnl-denoising=100

aomenc does not make grain synthesis by default, afaIk

I think it's not necessary to say that the frames are completely identical

and what?

the noise reduction function does not work without generating noise

It does nothing

exactly the same result with enable-cdef=0:enable-restoration=1 enable-cdef=0:enable-restoration=0

In general, I have never checked it, only spent time on it. It's already written in the documentation why check it?

I haven't compared these settings for aomenc, but `enable-dnl-denoising` can still do denoising for slower modes, even without synthesis, as far as I've seen other comparisons (but this needs to be tested for the current version)

well I just did it on the newest version. it doesn't work the way you think it does.

maybe it works only on SVT-AV1, because they have poor noise reduction algorithms.

well, maybe need a noisy or grainy source or a slower mode (but maybe that doesn't work by default for aom)

I don't want to check SVT-AV1 because in the last month of tests I realized only that it is shit, suitable exclusively for streaming on 6+ core processors

I would say that SVT-AV1 is a replacement for Real Time AOM

libaom v3.0.0 2021 Added option --enable-dnl-denoising to skip applying denoising with denoise-noise-level. **This option only takes effect when --denoise-noise-level > 0.** When --enable-dnl-denoising is 1 (default), the encoder denoises the frame for noise modeling and encodes the denoise frame with film grain synthesis. When 0, the encoder denoises the frame for noise modeling, but encodes the original (noisy) frame with film grain synthesis.

fun stat

that's why I'm using the latest ffmpeg build

and I want to remind you how many things AOM has that SVT-AV1 doesn't have https://api.encoding.com/reference/adv-av1-libaom

of course, I have check almost all these parameters, and I think that the AOM Engineers have set everything perfectly by default

what is this chat... the denoise options are *for* film grain. SVT: apply denoise *when* film grain. aom: it's in the name, dnl= denoise noise level

also I'm pretty sure they're in the visual diagrams for their pipelines

the thing is that denoise in some encoders works without using grain synthesis, for better compression, but this is not always needed and good, it makes everything too smoothed and also grain synthesis works without denoise, I sometimes use something like `enable-dnl-denoising=0 denoise-noise-level=15` or `film-grain-denoise=0 film-grain=20`, so the artificial grain is applied without trying to remove the original grain

yeah but the options enable-dnl-denoising=0 and film-grain-denoise=0 dont do anything unless you have denoise-noise-level=>0/film-grain=>0

those options are for using the denoised clip (acquired when calculating the noise for noise synth) to encode

you wouldnt have a denoised clip if you dont have noise synth on

maybe it should work that way, but for svt-av1 above I showed that it doesn't and `film-grain-denoise 1` works even without film-grain https://canary.discord.com/channels/794206087879852103/805176455658733570/1074264702672195675

you sure it's not just quantization noise

great another reason to not use svt-av1

maybe the encoder does something else, but the results are different, and just in case I always add `film-grain-denoise=0 film-grain=0` when I don't need denoise or grain synthesis, or if the default settings will change in some version and actually denoise is very rarely needed, only for very low bitrates or mini-encodings, even if grain synthesis is used, almost all av1 encoders are very bad at retaining small details even without denoising, unless it is very heavy and big grain

Av1 automatically denoises whether you want that or not

and svt-av1 has its best sides, basically there is no single av1 encoder that is best for everything, so I use several svt-av1 is the fastest and best in quality/speed balance, also it can smooth less when bitrate is enough when aom keeps smoothing, rav1e is only good at slowest speeds and for higher fidelity, but it's very slow svt-av1 is also only for yuv420, it cannot encode yuv422/444/...

It's a messy situation from an end-user perspective. There's also the proprietary av1 encoder by visionular (aurora). One of the things I am currently investigating at Cloudinary is leveraging AI to choose which avif encoder and what settings to use for a given image and fidelity target...

https://www.adorama.com/alc/what-is-codec/

🥹

<:BlobYay:806132268186861619>

AVIF XYB? <:ReeCat:806087208678588437>

yes XYB AVIF

and.... in fact, there is almost zero difference with the standart AVIF

why does the xyb version look noticeably worse then?

No, I don't see any difference in quality

I do. The xyb version is slightly more smeared and blurry for some reason.

it will be obvious to say - AVIF is not made for XYB

Although as far as I know, AVIF uses an objective quality metric, so there should be no difference.

If you look at the parts of grass that have the finest texture, and if you look at some of the tiny clouds that get smeared away in the XYB version

https://discord.com/channels/794206087879852103/1020724883241574472/1075038909140045834

here I did tests with guetzli

There's no such thing an objective quality :)

it uses a subjective quality metric. And he turned everything into a blurred

Are you serious?

there is mathematics. mathematics is objective. based on it, there are 2 objective metrics: PNSR and SSIM. learn the theory

there are many subjective metrics, like VMAF, MSA (hevc), Butteraugli (jpeg xl)

they destroy details based on the fact that the human eye may not see them

<@1028567873007927297> ✍️

I don't like all these metrics, of course. personally, I use SSIM wherever possible

Mathematics does seem to be pretty objective.

These are known as "objective metrics" not subjective because they are defined by math.

SSIM is the best thing that has been invented so far, no one else has done other objective metrics, because SSIM itself is already very complex. but PNSR, though old, and worse than SSIM. it can easily be represented by different formulas depending on the situation

no, these are subjective metrics. Do you not understand why this is so?

Everyone else calls them "objective metrics." Because it is calculated by a computer algorithm

The RGB color space is objective, and the XYB color space is subjective.

Math is objective remember? :)

You don't know what you're talking about

You sure?

When people say "subjective" they usually mean it's judged by humans and not computer vision.

well, look, suppose if you take all the colors of the image, and swap them. then an objective metric will say that the quality has not changed. But the subjective metric will say that there is not the same quality as it was before

in the context of image comparison

"subjective analysis" = "human analysis"

Typically a blind test with human judges.

That is why you should understand that nowadays it is what Subjective algorithms create, which ideally should coincide with the quality of evaluation from real people.

subjective algorithm sounds like an oxymoron. Didn't you just say math is objective?

you found fault with the words and did not understand the essence

<@1028567873007927297> this math

That is a good way of saying it.

Still, I have heard VMAF etc being referred to as "objective metrics"

in scientific papers

Because technically they ARE objective.

*It predicts subjective video quality based on a reference and distorted video sequence.*

The GOAL is to STRIVE to predict subjective video quality.

But you can say the same thing with simpler metrics too

Like you said it's a problem with words.

I just consider ALL of those to be classified as "objective metrics"

And that's how I have personally seen the term being used in literature

I don't think it's good to assume that VMAF etc are special

I don't think they are special either.

I don't like that VMAF uses neural networks.

at any step of creating a metric

and I like that the metric is just the formula

Having studied this topic for more than 7 years, I can't turn my tongue to say that VMAF is an Objective metric.

by the way, Butteraugli does not use any of these concepts, neither subjective nor objective, not a word on their github

"psychovisual"

be like subjective

"Objective comparison" = computers, "subjective comparison" = people

"neural network" = matrix multiplication

That's my undestanding anyways.

The NN weights are a value matrix.

"psychovisual" ?

psychovisual = how does your brain and eyes process visual stimuli.

psychovisual model = a model of (see above)

models are theoretical and objective

But they are not necessarily correct

Isn't that more about goals? If we want to preserve, it would be better to use lossless or something close to it. Less about perception and more about mathematical similarity. But if we want to simply reduce size, then it's less about math and more about perception, we aim to get maximum reduction without significant visual difference. Like if we move some object in a frame, mathematically it's awful, because all values are different, but visually it might be fine.

From my experience, metrics like PSNR aren't always good. For example, if we change subsampling, PSNR might give a decent number, but bad visual result. The reason for that is a huge PSNR difference between layers. It's very common with a text on magazine covers. In such cases if we want to convert something in auto mode, we need to use some kind of analyzer. For example, in case of jpeg, the best result I had with checking a picture on presence of gradient, sharp edges, color and other things. Gradient can produce blocking artifacts, sharp edges can produce mosquito noise and in case of color we need to check PSNR on all layers. I had to check for all kinds of artifacts in places where it's common to occur, and my program was doing something similar to subjective visual test. If we don't use lossless, then metrics like PSNR simply can't judge such artifacts at all.

AOM magic

3.6.0 update

Not much new for avif though, seems mostly stuff that makes realtime video coding faster...

AOM realtime mode be like shit. real. But I consider cpu-used 8 to be The key of the future for the next 5 years

For avif, I think aom at s6 is quite good now, in terms of speed vs compression.

But consistency is an issue, some images look great at some cq setting, others look fake and plastic

It's like libjpeg q70 can be fine or it can be crap, depending on the image content — but there at least you kind of know it's things like hard edges and text that will cause ringing artifacts

With avif it's harder to know what will happen

**now** I do not know what to use AVIF for at all. it's too long.

no it's not, it corrects for gamma twice, which is not something you want to or should be doing

Any metric has adversarial examples like that (though ones that use low norms like psnr and ssim will allow crazier stuff than ones that use high norms like butteraugli and ssimulacra2). If you make an encoder that optimizes very well for a metric, you will find some of those examples 🙂

(of course with classical codecs you won't find the cat changing into a dog, more like certain artifacts that the metric doesn't mind will be introduced and others that are maybe visually not too bad but the metric hates will be avoided at the cost of lots of bits)

(with AI based codecs you might also find artifacts of the "face turns into different face" kind, which are kind of fun but makes me very hesitant to trust such codecs)

Sounds good!

It may well be. But only in video codecs, ssim is counted for each block separately👍

well...

well well

what kind of compilation hell do have to go through to get ffmpeg.exe on windows with libaom butteraugli

just use wsl

& I'd use the aom-lavish fork which has had butteraugli quantization for a while, & the mainline patch was prob merged from there

yeah, tune=butteraugli is very slow anyway, doesn't work for 10-bit and needs tuning in the mainline libaom so it is better to use aom-lavish and psnr, ssim and other simpler metrics are used by the encoders internally for some choices, but not because they are best, but because they are fast and it's better than nothing

<:AngryCry:805396146322145301> no

fair enough

https://discord.gg/EP6ZV4GX

they provide community builds, so maybe you'll find an exe here. idk, im on linux

dead

you have to use the endless_merging branch

I know the dev, it is VERY not dead lol

<:Thonk:805904896879493180> well. i'll have to do it.

butteraugli maybe only for 10 bit

I'd prefer tune=ssim at cpu 3 over tune=butteraugli at cpu 4

it looks pretty dead

last time i tried that fork it did effectively nothing

<@138804598365224961> lmao

maybe it does something for smaller files, but at larger, default tune ssim was better

I mean, the main aom does not work with 10-bit butteraugli support for windows (fork works) and it's not for fast encodings (faster than 4), these modes are very slow, even with 2x downscaling

i use only cpu used 8

I would only use 4 or below

for some encodings tune=butteraugli gives much more stable results, but this is still a very experimental mode and needs further tuning

at these speeds, use svt-av1

no. he's shit. complete shit.

compared to aomenc speed 8? lmao

so much for our "compression specialist"

just use nvenc

absolutely right.

EVEN if SVT-AV1 is encoded slower

I'll compare ssimu2 scores tomorrow between the two

an equivalent svt-av1 speed to aom speed 8

I do not know what kind of shit those who test it smoke. on SVT-AV1, it allows such stupid artifacts that I do not know what the developers are doing there

we'll see what ssimu2 says tomorrow :)

I definitely definitely read on the SVT-AV1 gitlab that they are very far from AOM. it's good that the main developer says this

SVT-AV1 is exclusively an option when AOM is too slow, and for some reason there is an idea to use AOM real time mode (dont do it just use SVT-AV1)

have 🥹 4090

yeah it's great

I agree, but just use cpu4

No, I only have gt440

CPU 8 is way too fast

...?

Anything above speed 6 is realtime mode

So ur using realtime mode

dont use realtime mode

obviously cpu 7 is too slow

so they use cpu 8

realtime mode turns AV1 into VP8

This is what I am telling you <:kekw:808717074305122316>

BRUH

Use av1an. Anything above cpu4 is a waste

Anything above cpu6 is automatically realtime mode

the problem is you are assuming they can use anything lower than cpu8

I am assuming they have a device with more than two cores

that is the problem

I encoded with rav1e on my phone

phones are powerful nowaday

Then why is svt-av1 not viable

it's so annoying when people use real time as performance measure

Using av1an with even just two aom workers at a lower speed will dramatically increase your encoding efficiency as opposed to using speed 8. Additionally, rav1e is faster & better at higher speeds (like speed 6+) & svt-av1 will produce better results than aom rt

so saying to use av1an is cringe

stop

Why?

it doesnt improve your encoding "efficiency"

Also, considering DZ claims to be on Windows, I think I can safely assume >2 cores are present on their system. Av1an is a fantastic utility that will increase encoding speed irrespective of circumstance (given you can parallelize)

Yeah, that's what lower encoder speeds do

no. you are suggesting using more workers

but that only saves real time

not cpu time

yeah, you're right, I'll concede there for sure

and we're talking about dzgas here

who has funny pc specs and windows install

<:troll:705997697424949249>

chunked encoding is always more efficient than using threading in the encoder, especially when there are a lot of available threads (this is true even for x264/x265)

maybe space efficient

but not time efficient :)

wait i read that wrong

it's technically always worse in cpu time

who cares tho

thxz

if there is enough memory to load all threads, it's more efficient both in quality and mostly in overall encoding speed (if there are enough cores), because encoder multithreading is limited, also quality when using frame-threads is worse, like `--frame-threads 1` for x265 will always be better in metrics and quality some like svt-av1 have very good thread scaling, but this still requires using threaded frames (so accuracy suffers), using tiles (each new tile is also worse for quality), also some better modes are very poorly parallelized

for example, i have 16 cores and if i take aomenc/rav1e as not very good scalable encoders, what will be faster when only 4-5 cores are 100% utilized or when all 16 with a chunked encoding? besides with chunked encoding I don't care about options which are good for multithreading but worse for quality it might be not better for performance per power consumption but for overall performance it's almost always better (also for quality)

I know this newfangled way - divide the video into 4 parts and encode each in 1 thread - no thanks. AOM use 3 cores per video and I'm fine with that

obviously it's faster real time if you can use more cores

but if you only have one core it's not

or if you pay per core utilization it's not

also av1an and similar tools usually have good scene change detection (for splitting), so I can worry less about wrong encoder scene detection

we're not arguing that

for this use case, maybe, but basically, except for the time for splitting, nothing changes and it's possible to encode each chunk sequentially even in single-threaded mode, and it gives more options like I can encode with different encoders or different settings and then swap the worst quality chunks for better quality chunks or reencode only the bad segments instead of reencoding the whole video it is not useful only for multi-pass encoding to the required size (actually, it's possible, but worse for quality than doing it for the whole video)

yeah i get it. i was there at the start of the whole thing

there are also interesting things using prediction (with nn or even something simpler), when each chunk is identified by type and complexity and then encoded with different settings and this gives better quality and less overall encoding time than encoding the whole video with the same slowest or fastest settings but, sadly, there are no such open source solutions

✍️ I have 4 gb of ram

Yes. Great idea. when will this appear in FFmpeg?

🙂

and I forgot another important thing, aomenc is still an unstable encoder and for very slow or some custom settings it can cause a segfault and all the encoding time wasted, and especially for slow modes the time spent can be huge, even weeks or months for long videos and av1an allows to continue encoding from unfinished chunks

Actually, because of imperfect scaling in almost all cases, you save CPU time and real time :)

some person responded to this request. he said that he would do such the thing. Well, I'll be waiting.

it seems like you know what you're talking about

bc even if u use one chunk with av1an, it can just retry

I haven't used encoding for just one chunk, but theoretically it depends for what cause the encoder is crashed and it could corrupt the encoded chunk, but at least finished chunks will be fine

oh sorry not one chunk, one worker*

1 worker x 1 thread is always less total cpu time than 2 workers x 1 thread. I am not comparing it with using more threads in the encoder

My FLAC compress key ```flac.exe -p -e -f -l 12 -b 4608 -r 0,8 -m -A tukey(0) -A tukey(5e-1) -A tukey(1) -A tukey(2) -A tukey(3) -A tukey(4) -A tukey(5) -A partial_tukey(0) -A partial_tukey(1) -A partial_tukey(2) -A partial_tukey(3) -A partial_tukey(4) -A partial_tukey(5) -A punchout_tukey(0) -A punchout_tukey(1) -A punchout_tukey(2) -A punchout_tukey(3) -A punchout_tukey(4) -A punchout_tukey(5) -A bartlett -A bartlett_hann -A blackman -A blackman_harris_4term_92db -A connes -A flattop -A hamming -A hann -A kaiser_bessel -A nuttall -A rectangle -A triangle```

nah, doing chunked encoding is always less cpu time than doing it single-threaded

cause there's some small overhead to starting a new process

it's just that the cpu time overlaps with itself cause parallelism woooo

I should have been clearer: I'm comparing against all other threading methods.

This is why the only way to compare codecs is to see what they actually look like at the same size, or alternatively, see what bitrate they end up being when you can no longer ABX them apart from the original in a blind ABX test.

there are no perfect metrics, but there are metrics that are better than others, which are confirmed by better correlation with subjective evaluations but, even the best metrics should not be the only quality indicator, but they are good as automated helpers like, i can visually compare some images or videos, and what if i need to compare millions of such images or videos? but with metrics I can notice a quality drop in an image or even some frames, same for encoders, they don't have human eyes, but with metrics they have some correlation with visual quality also subjective quality is subjective and it can't be the best estimate either, some people might like av1 smoothing more than the source, some people like over-sharpness, etc.

They're good in theory but if they can't be relied upon, then they can't be relied upon.

I guess the only exception would be if you could predict the metrics weaknesses and how it could potentially be fooled. And then, completely rule it out before measuring.

Like if you theoretically knew for a fact that the type of distortion you will be introducing is not what the metric is bad at measuring

Which in practice I doubt is possible most of the time

it feels to me as though the latter would be harder to estimate

in principle, as bitrate increases, you would expect the frequency at which people get the A/B/X test right to decrease asymptotically to 50%

you would then try to estimate what those frequencies might plausibly be at various bitrates,

and finally, determine “at roughly which bitrate does this (presumably quite horizontal) curve get ‘close enough’ to 50%?”

it seems that realistically, this would be very uncertain

whereas picking just one bitrate and estimating the frequency of getting the test right with one codec and with the other, and thereby a probability distribution of the difference, would be much more straightforward

So what you're saying is that unless a metric is perfect, then it shouldn't be used?

I mean, it might as well be the same thing for subjective visual comparisons on anything but wide gamut high contrast high brightness displays.

Metrics should be used, but always with care and with eyeballs too.

It's effectively an arms race where codecs learn to fool metrics and metrics get better at avoiding getting fooled.

nop

well. the AV1 community server turned out to be just useless. After 2 days of my tortures, I started to get something

oh well

libaom .a(butteraugli.c.o):butteraugli.c:(.text+0x170): undefined reference to `__imp_JxlButteraugliApiCreate'

truly zero answers in google on request

I conclude that in the last 2 years no one has compiled AOM with butteraugli on windows

after spending 2 days, I came to the conclusion that AOMENC (not ffmpeg aom) with butteraugli cannot be compiled for windows at all. Neither AOM 3.1.0 nor 3.4.0 nor 3.6.0, nor with libjxl 0.6 0.7 0.8

The AV1 community server was useless? I wouldn't be so rude, they acknowledged your question & offered some guidance which I think was very nice of them

THE offered ? everything that is in the first lines of google "how to compile AOM"??

No, absolutely useless community.

they're not obligated to help you for any reason, the fact that they answered at all was just out of their interest in being kind & helpful people

I've faced roadblocks similar to the one you're facing now, & I think it's best to not be angry about it & let yourself move on

Well, if they don't have to and don't want to help about AV1, then what did they forget there?

Any 1 developer is more active here than AV1 server with 500 online

I don't understand your question, & I'm not going to entertain this conversation anymore if your only interest is to talk negatively about another community that shares goals & ideals with this one

To be a part of the community, it must be proved by deed. and I saw there only a bunch of lazy people who poke at the terminal to compress for fun.

Please don't ping me about external server drama. As I voiced above, I am not willing to entertain this conversation if your only interest is to talk negatively about them.

well, it is necessary to inform that -- when you write about help for 2 days. and when you write 3 messages. they will close access to the channel where they are build soft. and delete your message. and they will write to you, do everything yourself. here are a couple of links from Google. no one has to help you here.

i'm getting similar errors, not sure why it can't find the symbols

lmao

okay, i seem to have finally done it

needed to patch third_party libyuv (which for some reason is required by butteraugli) to build properly on msys2

now to get a static build going

maybe later... it's tiring, in short just change that file and add `-DLIBYUV_STATIC` to your CFLAGS if you wanna compile mainline aomenc (for whatever reason) with butteraugli

I think most of the people on the av1 discord are not av1 devs but rather people interested in using av1 to encode videos. The devs/users ratio is probably higher on this discord.

Look this 👉 <@557099078337560596> Why is this happening here? I write about it for 2 days on the av1 server, but the person who really wants to figure it out and do it is here.

I am continuously amazed by how many very intelligent and very friendly people are on this discord.

hm, i can't seem to replicate my success like before, i can't figure out what's going on anymore

i might need a few more days to figure this out... but there at least is some info

As I understand it, the build is not being built?

I'm encountering the same error again as before with the missing dllimport symbols. I already patched the files and I'm defining LIBYUV_STATIC, but for some reason it's just not working. I'll figure it out in a bit, but all I could figure out is posted above.

Well, I'm absolutely not a C programmer, so I'll be waiting for you

Neither am I honestly, I'm just experimenting and figuring things out. Turns out I was building in the wrong repo, for some reason the aomenc forks can't compile statically even with the patch, but the mainline ones can. Weird. Anyway, I still need to figure out how to get it to build statically. It still links to the dlls.

dlls doesn't matter at all, you have the worker aomenc.exe ?

This is my aomenc without butteraugli, it just compiled and just works

yes, but i compiled it with avx2 support, so i need to recompile it since i just looked up your processor and it does not have avx2

That is , you have set the compilation function AVX only ??

yes, i set `-march=x86-64-v3` which AFAIK sets AVX2

since usually that's what they recommend for best performance with these av1 encoders

I think it's better do it by default.

I'm pretty sure that only tests if the compiler supports -mavx2, not necessarily if your CPU supports it.

it's true. the codec works well on AVX

well?

sorry about the delay, had to take care of irl stuff, here's the shared build since i couldn't get static to work, aomenc is *really* fragile about getting butter to work on windows

not work...

how so?

simple, even as a regular encoder

i don't quite understand

the normal encoder, up, works, and your encoder - just exits the program

that's odd...

hmm

avx?

i'm not very sure what's going on

i remember turning off avx

let me check on my machine rq

👌

it works fine on my machine, let me go through the logs and see if avx was really disabled

okay it looks like aom somehow forces avx2 even if i set cflags...

using its own flags

that's annoying

heh

the surprising thing is that it build only in AVX mode, ignoring SSE, although the AOMENC assembly should be universal...

ah wait, which version of windows are you running

im pretty sure aomenc has runtime detection to see if you can use avx2 or not

not all programs do this, for some reason

Windows 10 21H2

okay, so the runtime isn't the issue either...

it doesn't pop up any errors at all when you just double click the file?

maybe windows is detecting it as a virus, i really don't know at this point

in fact, I don't even know any programs that give an error about AVX, except for paq8px

I don't have any antiviruses (and I cut out the built-in one)

the program shell is working. and even --help works, but running something causes it to be end

okay that's unusual

i really am at a loss right now...

for my universal compile i use ```cmake .. -DBUILD_SHARED_LIBS=0 -DCMAKE_BUILD_TYPE=Release -G "MSYS Makefiles" -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_CXX_FLAGS="-flto -O3 -march=native" -DCMAKE_C_FLAGS="-flto -O3 -march=native" -DCMAKE_C_FLAGS_INIT="-flto=16 -static -static-libgcc -static-libstdc++" -DCMAKE_EXE_LINKER_FLAGS="-flto -static -static-libgcc -static-libstdc++" -DENABLE_DOCS=0 -DENABLE_TESTS=0 -DCONFIG_AV1_DECODER=0```

maybe there is a key here that will help you

well it's not really universal if you use "march=native"

if anyone here can try this exe to see if it breaks on their machine too, that would be great! i can't test this on a clean environment at the moment this is just aomenc mainline compiled with x86-64-v2 as well as small patch to get it to find JXL in MinGW

I have a friend with avx, he will try

well AVX moment

**FINALLY, the first results of butteraugli AOM *- it is 5 times slower than SSIM***

aomenc.exe --cpu-used=8 -h 540 -w 960 k.yuv --tune=butteraugli --output=test2.ivf butteraugli 1.2 FPS SSIM 6 FPS

the

it may be difficult to notice, but the quality of butteraugli is really higher than SSIM. however, its speed makes it impossible to encode fast content. judging by the speed, the butteraugli setting should be applied somewhere after compression speed level 2 or 1

considering that the files have literally the same weight, it's amazing how butteraugli affects the sharp edges of the blocks, and the halo around the hair

when I was told that butteraugli was slow. they still haven't told me what time? I thought well, one and a half times, maybe 2 times slower... 100 times

Continue to use SSIM

Maybe it's faster on avx2 cpu.

Idk

it was AVX

Probably some shortcuts can be made to speed things up, but it's kind of unavoidable to be slower than super simple metrics like psnr

You can also try ssimulacra2 😁

the results you're getting with mainline aomenc are probably why everyone recommends just using the forks like aom-av1-lavish

🥴 no thx

I've seen it. But in order not to use it, it was enough for me Not to see speed time on their github page.

about ssimulacra2

<@794205442175402004> you also do the ssimulacra2 project, how many times speed is it less if use it instead of SSIM?

Computationally the main difference is the colorspace in which they operate

Is it possible to say the speed difference in a simple number?

Depends on how you implement it. If you are doing encoding in xyb, and ignore the multiscale thing, then ssimulacra2 is probably implementable with very similar speed as ssim, maybe 10% slower or something

At some point, the AOMENC encoder enters an infinite loop of calculating something, and cannot get out of it, infinitely performing some kind of cyclic calculation. unfortunately, AOMENC with butteraugli just Broke <@557099078337560596>

in any case, at least some good experiments were made

<:AV1:805851461774475316> 👍

if it interests you, here's a build which i think finally disables avx

that's probably the end of my adventures with aomenc for now, it's getting annoying trying to compile things

nope. it's also AVX and doesn't work

weird, i swear it disabled all AVX files, i didn't see any get compiled

anyway that's the end of my rope for real

I think yes you should stop already, you've done everything need to

by the way, on linux it takes 20 minutes. That is all. after I asked one person to make such a build for linux.