>>108930749
Very true, literally nobody cares about VP9 and 4troon should shut down already.

so are they gonna release a binary for this shit or do i have to compile it myself?

>>108930454
was av1 even used at all?

>>108930454
god I want av1 in mp4/webm on here so bad, it would make my video or sound fuckery so much quicker and easier, I hate vp9 so goddamn much

File: AVIF logo (rendered in 51(...).png (219 KB, 5120x3827)

219 KB PNG

An interesting question is: what is going to happen with AVIF now?

Will they treat AV2-in-AVIF as its own new format (AVIF2 or maybe AV2IF) with its own extension (“.avif2” or “.av2if”) and its own MIME type (“image/avif2” or “image/av2if”)?

Or will they treat AV2-in-AVIF as merely a new version of AVIF?

In the latter case there will be much confusion to be expected (such as “we are already supporting AVIF, why would we need any upgrade”, “the file you uploaded in not an AVIF, the magic number in its header does not match”, etc.). You will never be able to rely on “AVIF uploads are supported” from now on, it's gonna be some trial-and-error every time. That's the downside.

On the other hand, the case of “AVIF extension is whitelisted in our markup, but whitelisting an AVIF2 now needs a separate reasoning” is avoided then. (And some of the other chicken-and-egg problems are avoided, and thus the chorus of “we do not support AV2IF because we want someone else to be its early adopters” becomes somewhat thinner.)

When should we expect a standard of AV2-in-AVIF? Will that take almost a year, like the first AVIF (2019-02-19) after the first AV1 (2018-03-28), or will that happen sooner?

Will AV2-in-AVIF become a command line option of libavif, or will we have some libav2if, or will we have some “libavif built with libaom-av2 instead of libaom-av1”, perhaps unofficially at first?

How messy would be the landing of all that in the web browsers, how soon would it start the countdown to “Baseline Widely Available”? (Definitely not sooner than JXL support.)

GD in PHP does not even started any JPEG XL support, how long would it take for AV2-in-AVIF? They probably won't make it before Debian 14 (in 2027), and thus any stable support of AV2-in-AVIF on the server side is not to happen before 2029 or even 2031 (five years from now).

Will there be a backlash of “do we even need any AV2-in-AVIF, just let JPEG XL win” or something?

>>108930908
don't bother. encoding minutes of 4K content could literally take months. and the output is not even beneficial to (you).
these codecs' sales pitch is "you could save a few bucks encoding at the shittiest quality possible consoomers will still accept when content is grabbed by millions of people".
4K sort of needed a codec upgrade from h264 because of larger blocks sizes. but after that, what's on offer has been orders of magnitude increase in encoder complexity for diminishing or even negative returns for high quality personal use.
the idea is usually that encoders will mature and become good in X years. and even that is yet to be seen post-x265.

>>108930454
you don't need more than vp9 and h.264

>>108932153

> encoding minutes of 4K content could literally take months

What if my CPU has sixteen hyperthreaded cores and I am willing to use “-row-mt 1 -tile-rows 4 -tile-columns 4 -threads 32”?

(Oops, that would actually be “-row-mt 1 -tile-rows 2 -tile-columns 2 -threads 32” because that parameters are logarithmic.)

>>108930996
Used by Netflix, Meta and YouTube, pretty much all YT videos with over 100K views have AV1 encodes.

>>108932498
Actually with the 4MB limit, you do NEED more than H264/VP9, and AV1 is not only has better quality per bitrate but the SVT encoder is much faster than libvpx

who cares
>no hw decoder
DOA

>>108933730
???
Are you an LLM stuck with 2019 knowledge?
My 2020 GPU has an AV1 HW decoder.

>>108933783
Does it have av2 decoder?

>>108933846
No because standard bitstream isn't even finalized yet.

>>108933852
So the GPUs that aren’t being released to the consumers (lol AI - > lok taiwan) will be the only ones that support av2?
Very useful

>>108933730
>>108933915

> hw decoder

Wait ≈2 more years.

Meanwhile software decoders would suffice for small resolutions and also for AV2-in-AVIF (if any).

File: 1767498343664047.png (189 KB, 640x484)

189 KB PNG

>>108932684
It would be extremely painful.

>av2 gets standardized
>corpos get the av2 hardware encoders (no you cant have one due to ai and ram prices haha)
>forced to decode av2 burning 10x watts watching slop for 20% storage improvement
>energy bill skyrockets
>corpos build new datacenters with the savings
>become homeless
>stand a tent near one of the new datacenters and enjoy the raised ambient temperature
i guess it's not ALL bad

use case for codecs newer than h264?

>>108934524
Getting decent quality out of the anemic 4MB limit on here.

>>108934534
i wish the software encoders of these newer codecs weren't taking so much time to encode though

>>108934547
The AV1 encoder is faster than the VP9 one, and we can use VP9 on here.
SVT-AV1 preset 8 gives you comparable quality to libvpx-vp9 cpu-used 0

>>108934570
yeah i know but I CANT USE IT HERE REEEEEEEEEEEEE

>>108934547
>i wish the software encoders of these newer codecs weren't taking so much time to encode though
SVT-AV1 is literally faster than even x264

>>108934547
>>108934570
And don't forget that modern GPUs have HW encoders for it too, the quality is shit but if you want rapidly shitpost a webm you can encode it at lighting speed.

>>108934524
zero days

>>108934570
shame about svt-vp9

>>108932153
>hur dur he used aom instead of svt-av1, part 23123901 of the "i am retarded" series

>>108932085
Isn't webp based on VP8 of all fucking things or something, while AVIF is a huge jump forward by using AV1 as a base? Maybe AVIF2 won't happen anytime soon, as there isn't too much point for it currently, the first version is plenty powerful as things are.

File: AV2 encoding configurations.png (193 KB, 1280x1150)

193 KB PNG

>>108935225

Well, https://arxiv.org/pdf/2605.15800 says we could still have 15% smaller filesizes (with the same image quality) for AV2-in-AVIF still images.

That's not a huge jump, but that's still noticeable.

Every "new" codec opens the patent minefield for a further 20 years, "royalty free" or not. Just accept that codecs are good enough and ignore "new" ones.

>>108935397
so what you're saying is we need to get rid of patent system

>>108935387
A leap forward, sure.
A technological problem for the time being? Yes.
AVIF can probably just use existing AV1 decoder(?), so continuing that is probably a LOT easier and not worth the effort of changing everything just to get a 15% improvement going, yet.

What about AV2 vs AV1 in normal encoding by the way? Read some retarded 50% reports, but never looked into it as I'm waiting for a potential SVT-AV2 or something.

File: AV2 content types.png (271 KB, 1352x1150)

271 KB PNG

>>108935501

>>108935501
15-30%
Mean is like 21%? So pretty good… assuming reasonable encode time. Which isn’t happening for at least 2 years, likely 3+

>>108935522
>>108935524
So the usual-ish leap, figures.
>Which isn’t happening for at least 2 years
Prrrrrretty much, which is arguably the biggest issue. SVT-AV1 is fascinating in the speed/quality it can achieve, but man it took a while to get there, quality wise at least.

>>108933915
yes, that's how codec development works, retard

hardware always comes after software

>>108934593
>SVT-AV1 is literally faster than even x264
faster but it looks worse at non-starved bitrates.

Oh boy I sure can't wait for all the high quality video that will come from these newer codecs! Everything will totally not be ultra denoised at 300kbps! AV1 was blurry streamslop used by gigakike strsaming services trying to save bandwidth first and optimize quality second, why would I care about this?

>>108935826

In three words, MUCH BETTER DEBLOCKING.

(At least, that's what we are promised.

Personally I'm yet to see a Windows build of an AV2 encoder that does not crash after the very first frame.)

>>108935826
>>108935878
>People use new thing for what it's meant to be used, getting things very small
>WHOA REEE
People do the exact same thing with 264 since forever, have you faggots never seen a 500-1GB movie release?? THEY STILL MAKE THEM, THEY STILL LOOK LIKE SHIT

>>108935878
I dont have issue with blocking with av1
i do have issue with every detail being smoothed out
maybe they should focus on that instead
losing to (20yo) x264 on 10GB movies encodes is pathetic

>>108936521
AV1 was literally made so Google would have to pay less money to serve you slop. It is ridiculous how low the AV1 quality is on YT. You could make AV1 look better, but of course they won't.
You could make webp look better than jpeg too in most cases, but nobody uses it for that.

>>108930454
6MB Evangelion at DVD quality finally?

>>108930454
Can it encode a 2 hour film in 1080p resolution maintaining BluRay quality and it fits a CD-ROM?
No?
Don't care, then.

File: Sisvel actually believes this.png (1.35 MB, 1735x1838)

1.35 MB PNG

>Even though it had not yet been released as of 14 January 2026, the Luxembourg-based NPE Sisvel[7] had already announced plans to establish a patent pool, as it did for AV1.[8]

Sasuga.

>>108935878
>MUCH BETTER DEBLOCKING
I'd much rather media be jpegged to fuck than have the smeared with vaseline look new video codecs (and derived image codecs) have.

>>108937098
This. Macroblocking in early MPEG codecs like h.264 is soul. I'd fucking take MPEG-2 blocking over this terminator 2 4k shit.

>>108936568
neither can h264
checkmate atheist

>>108935208
>too retarded to realize it's actually "avm", and there is no retards' favorite meme svt-av2 yet

>>108932684
>-row-mt 1 -tile-rows 4 -tile-columns 4 -threads 32

none of those are avmenc options (and you may not need them anyway)

File: 1754237094588673.png (410 KB, 736x735)

410 KB PNG

AV1 can actually look great, but the problem is that the defaults are set to vaseline mode so it can look acceptable at starved bitrates, and websites intentionally use it in vaseline mode to cheap out on bitrate, so it leaves a bad impression
The other problem is that you need to learn all of the non-default parameters needed to make it look good (stuff like enable-variance-boost=1, enable-qm=1, ac-bias=1, tune=0, etc), instead of it looking sharp out of the box like x264

>>108937748
>akshuually real av1 hasn't been tried yet
>av2 is already out

>>108937770
I didn't say anything like that

>>108937770
>If I make shit up and put it in greentext it will make it true

>>108937748
At least in the case of SVT, the problems for me start with the default CRF value of 35, when it should be 25 or something, at least for quality sake. Funny to think that 50 used to be the defacto default early on.
Then there is of course all the bullshit you mentioned that one has to figure out.
>instead of it looking sharp out of the box like x264
I wonder how much compression you can even press out of modern encoding these days, without all the washing things out that AV1, VP9 and HEVC use to get their results.
You have to push bitrate real far to get AV1/HEVC to get super sharp, which is still a fuck ton more efficient than x264 but yeah.

>>108936604
>>108936545
>>108935387
>>108932085
daiz bots chatgpt generated posts

>lossly compression
>"same quality"

not even an insecure underage desperately trying to fit in on 4cuck will fall for your retarded propaganda

>>108937859
>>108937748
>AV1 can actually look great
>You have to push bitrate real far to get AV1/HEVC to get super sharp, which is still a fuck ton more efficient than x264 but yeah.

I wonder who is behind these posts.

[-]
Go on, post more worthless nothing burger

>>108938123
>chatgpt generated posts
it's hilarious, isn't it?
none of the /g/eet wintards here, bot/llm assisted or not, have anything related AV2/avm they can contribute, because they don't even know how to do the trivial task of building software.
so all they have is AV1 related "info" to spam.

>>108937732

I've used the FFmpeg's way of writing them, in avmenc these parameters still exist in their “--tile-rows=2 --tile-columns=2 --threads=32” form.

(However, row-mt is on by default.)

>>108938123

Haven't you ever heard what a BD-rate is?

Yes, it's fundamentally a difference in bitrates (and thus the filesizes) measured between the two results of “lossy compression” that have “the same quality”.

> b-but that's a propaganga, some unsecure underage might have misunderstood that not AV1 and AV2 but the source video also has the same quality!!

You have a very proactive imagination when it's about children.

>>108939221
what speeds are you getting?

>>108930454
No thanks, I'll wait for AV3

File: 1778273054743454.webm (1.27 MB, 720x1280)

1.27 MB WEBM

>>108930996
Being used as we speak. Also this looks like a useful AV1 encoding thread in general.

>>108938759
>>108938759
>>108938759
>>108938759

>>108932085

the feature is like 10-bit color and it is difficult outside single still frame file

i would like to see avif support but things take time

>>108934524

vp8 included in distro media default install h264 maybe in codec pack

>>108936545
https://www.youtube.com/watch?v=cxAyHGNgwcY

>>108939387

Seven minutes to encode the first frame at “--cpu-used=0”, and then the encoder crashed.

I guess I should have waited for an official Windows build.

I have 6 TB of video to convert, where the fuck is libsvtav2 that works at the av1 speed? It’s been almost 48hr already

is AV2 any easier to encode than slow-ass AV1?

>>108940156
Right now it’s several minutes per 1 frame

>>108940269
fuck that shit

>>108939658
lol
i'm the same person from
>>108932153
>>108937732
AND
https://desuarchive.org/g/thread/108764307/#q108791895
i decided to let it encode for a while today. i scaled input down to 720p, and i'm using the command:

some-pipe-out-command  | ./avmenc --cpu-used=8 --kf-max-dist=250 --aq-mode=1 --good --end-usage=cq --min-qp=86 --max-qp=98 -t 4 -y -o file.webm -

i have no idea if --cpu-used is making it go faster or not. but i'm happy to report that the encode should finish soon (well, maybe another hour lol) without issue. and it managed it in less than half a day using my humble aging workstation. impressive!
this is on linux x86_64 btw.
(i could probably make a mingw64 windows build in 2 minutes. but nah, i will let you wintards figure it out on your own.)

>see sv2 minge
>same as every other minge

>>108938123
Meds
Now

>>108940314
progress report: after 2 hours, 20 frames done so far

File: 1777595398561.png (90 KB, 1349x632)

90 KB PNG

>>108940156
>slow-ass AV1
You're confusing H.264 with AV1.

>>108940314
> i have no idea if --cpu-used is making it go faster or not.

The default value of “--cpu-used” seems to be “1” in the source:

https://github.com/AOMediaCodec/avm/blob/471fbd95b29d6795bc068d5cdbe651cafcd66758/av2/arg_defs.c#L325

These days (before the encoder is optimized) we can't be sure the encoder's good at trading features for speed.

(It may go faster with the default value of cpu-used but not apply the full power of AV2.)

>>108939467
Wait, can we post AV1 webms now?

>>108940156
AV1 is faster to encode than VP9

File: Untitled.png (24 KB, 1484x235)

24 KB PNG

>>108941053
Not on 4chan but umigalaxy fully supports AV1 uploads though to be frank the website looks like it's still under construction.

>>108941053
I wish.

>>108940269
Realistically, HD is off the table right now. Short 360p videos may be doable for some preliminary benchmarking.

To be honest, I'd happily spend 7 minutes encoding a frame even if the resulting non-animated AV2-in-AVIF is only 15% better than AV1-in-AVIF.

But then again where's my libav2if builds, and the corresponding standard, and its support in browsers and on the server side?

Five years from now in Debian 16, right?

>>108938444
It's only one deranged faggot from Finland called Daiz who wants to brainwash retards into thimking lossly compressed files are good.

These are his "anonymous" bots:
>>108940917
>>108940889
>>108939467

Incoherent posts, duplicate threads, and obsession with ffmpeg and a LLM generated imageboard. These are the hallmarks of his bots.

>>108934524
Efficiency which is literally the main reason codecs exist at all.

File: 1766855910922206.png (394 KB, 632x640)

394 KB PNG

https://desuarchive.org/g/thread/101718666/#101721228
https://desuarchive.org/g/thread/94046693/#94053491

>not supported anywhere
you know what that means? it means it's useless

File: PXL_20260411_085729999.RA(...).jpg (1.23 MB, 4080x3072)

1.23 MB JPG

>>108941426
That same circular logic was used against JPEG XL, but people thankfully saw past that grift and pressured Google into accepting a new decoder.

>>108941475
jxl is an improvement over jpeg
av1 and now av2 is a cost saving measure for google and netflix

>>108941475
wooo nice
which website uses jxl right now?

File: PXL_20260410_111737667.RA(...).jpg (288 KB, 2040x1536)

288 KB JPG

>>108941600
JXL is arguably also a cost-saving measure for CDNs desperate to shave off some bytes transparently. The Belgian JXL author literally works for Cloudinary after all.

File: PXL_20260416_134505829.RA(...).jpg (215 KB, 2040x1536)

215 KB JPG

>>108941645
The Guardian delivers JXL on supported browsers. It was also one of the early proponents.

Absolutely disgusting. So they're running out of space because they keep all the photos of the Palestinians they raped, mutilated and murdered. I wonder where they got the money to pay off developers to make JXL.

>Cloudinary was created by three co-founders:
>
>Itai Lahan
>Tal Lev-Ami
>Nadav Soferman
>
>They founded the company in Israel in 2012 after repeatedly encountering the same challenges around uploading, managing, transforming, and delivering images and videos for web applications. They built Cloudinary to automate those media-management tasks for developers and businesses.
>
>Today, Cloudinary provides cloud-based image and video management services used by millions of developers and thousands of brands worldwide.

Image niggers, this is a thread about video codecs and 4chan being stuck in the past, go away.

>>108941884
Image board, image site