JPEG XL

I assume at higher resolutions x264 is overtaken by x265? Not that it really matters for streaming, Twitch still has very limited support for anything other than h264

I've been testing different combinations of x264 settings for 5 years now. In the last six months, I have started calling such presets AVC ultra - because sometimes they are at the AV1 level in quality (with identical encoding speed and same out size)

Yes. the maximum resolution when AVC has an advantage is 960x540. starting from 720p and up, it is completely loses because of the h264 service data

The twitch enhanced broadcasting beta was sadly a huge disappointment in terms of bringing support for new formats such as h265 and AV1. h264 at the maximum 6000 kbit/s is sufficient for many things, but its limitations become clear in high movement scenes and even with smaller amounts of grain.

I don't understand why twitch just can't add a damn Av1. I've been looking at this for 3 years. And I don't understand. SVT-AV1 is faster on any parameter than the current AVC tweak settings and will be faster and better in everything. But I don't understand! WHERE

av1 is the only codec that surpasses AVC in 360p resolution at the moment

It's like they don't want to save money by saving bandwith

hevc. vp9. vp8 just suck

indeed, if only NVK supported it T.T

I think the answer is the same as why Discord didn't add native AV1 support - Well they have a fucker on a technician who receives a salary

NVK and Nova (Red Hat's own implemenation of an open Nvidia userpsace driver) are under heavy development still, the only question is when they will be ready for primetime in terms of feature parity

Discord doesn't even support animated WebP (except for stickers and emotes), AVIF or any other format that could replace GIF, despite many feature requests on their support forums

I am getting mad at discord again, darn

I'd gladly use AVIF or WebP for animated content, but it remains impossible

I have a small telegram channel where I record streamers. When switching to HEVC and AV1, I encountered a non-trivial problem - it quickly drains the phones. the ratio is almost identical to the decoding codec time. The AVC 540p turned out to be the perfect option for everything, including I use the Main profile for TV legacy so that people can download the stream file and watch it on TV.

This is a dead end

IIRC most CPUs used in Android phones (Qualcomm based ones) simply did not include an AV1 decoder, this has only changed since around 2-3 years ago, but don't quote me on that

another super not obvious thing is 16 ref frames. that is, with 16 b-frames, this means that the codec can completely copy data 250 frames back in time. This is not possible with any other codec due to the excessive load. this is only possible in AVC

<:H264_AVC:805854162079842314> <:This:805404376658739230>

while true, if NVK supported the kernel, then we wouldn't need to ask that question xD

I know about it. I know about everything. I have my own fork of SVT-AV1 so I know everything.

indeed. many qualcomm refresh models still dont have hwdec, and android 12-android 14 use libgav1 and not libdav1d

I think there might be a magisk module to override this comming?

this is still funny/interesting to me https://bugzilla.mozilla.org/show_bug.cgi?id=327074 19 years ago when Firefox version 1.5 was the newest this was reported and it was only fixed 2 years ago in Firefox version 107

i guess who tf is using 8BPP RLE BMPs when PNG exists

so it didn't get that much attention

the thing that gets me is that it was fixed randomly 17 years after it was reported which is way after it was relevant

Maybe some dev was just bored and decided to fix it?

I think some people go around looking at random old reported bugs for Firefox and try to fix them, I remember there was an instance of that happening that some tech news sites started reporting about

Some people just like seeing squeaky clean bug trackers

It has always baffled me that BMP is a universally supported web format. And I don't get why it doesn't get deprecated like XBM was deprecated.

Better to add BMP to this comparison

Maybe it would be good to make a new version of that comparison table, some things could be quantified a bit better now the various implementations are getting more stable...

Is there any software capable of writing RLE BMP? Even Microsoft is using just the uncompressed variant.

Gimp does RLE BMP

Ah yes, Gimp implements BMP format completely, including alpha transparency. Windiows can read 32 bpp BMP images but ignores the alpha.

New table underway for the website! Maybe put feedback here and I'll implement. I guess BMP needs to be added?

And any other debates? Maybe HEIC should be 3.5 stars for Photos?

Maybe add the fact that avif images can exceed the listed dimensions using tiles?

I'm wondering if we should add a notes field?

Not a bad idea imo

Maybe too much effort, but would it be useful to add BPP for the compression items?

Be gentle. We also need to build this in HTML and make it work in mobile size <:AngryCry:805396146322145301>

Sure, I can add another column if you think it's worth it.

I was thinking an info hover for fields with an asterisk, but then mobile becomes an issue

Just have the asterisk listed on the bottom the chart

For example `* = can exceed listed dimensions with tiling`

~~Also the defacto jpeg standard only has three channels.~~ I was wrong.

I thought the 4 was CMYK

I'm also going to flip the order so XL is next to the header column

Then we can lock those in place and the others can scroll

CMYK is a color space? ~~Defacto Jpeg encoders still maps everything in YUV or RGB. Still three channels.~~

cmyk is a colour model, not a color space

colour space means primaries, transfer and white point

Ah, thanks for clearing that up

~~Anyways my point still stands, defacto jpeg is 3 channels only.~~

The jpg animation feature field has a typo, it should be MJPEG

Ahh, no alpha.

For consistency rename "Precision Max Depth" to "Maximum Bit Depth"

Considering other categories start with the word "maximum"

it just sounds better to me ¯\\_(ツ)\_/¯

Was just changing "Can do (lossy) 4:4:4" to Lossy 4:4:4

So Maximum Bit Depth = color depth in this case?

(thinking out loud)

OK someone with lots of BMP knowledge is going to have to help out here, cause https://cloudinary.com/guides/image-formats/bmp-vs-png-4-key-differences-and-how-to-choose this https://en.wikipedia.org/wiki/BMP_file_format say different things.

Realistically no one is using BMP, it has long been deprecated. I would not add it to the comparison chart

If anything, PNG or TIFF are used

ha

funny

I still occasionally see bmp in assets

Yeah, but not due to its compression, but rather backwards compatibility I reckon. Or old assets

The only BMPs I have are from software that is well over 15-20 years old

sure, but its still used occasionally whether regretfully or now

Fair point, but I still would not add it to the comparison chart

If BMP is added, TIFF could be as well

etc. etc.

Yeah, as a mostly Mac guy, I rarely run into them. If we don't have to put it on, let's not…

Probably go for the most common formats in general (Jpeg, GIF, PNG, ect), most common on the web (WebP, AVIF, ect), and most common for 'Professionals' (DNG/TIFF, EXR, ect) Then at a glance, everyone can tell where their usecase lies

We have this on the website right now.

We weren't adding AVIF at the time cause we didn't think anyone was that crazy. But maybe we should? Anyone know the number?

It varies depending on the encoded material

There should be some datasets you can take a look at, or run a benchmark yourself using the cloudinary image set which is linked somewhere on this server IIRC

tiff should absolutely be added

Tbh, I agree

tiff is pretty much "the" image format for professional work

Yeah

Instead of adding DNG as its own category, a note linking to the DNG 1.7 spec should suffice? DNG is using jxl compression nowadays after all

Yeah, I don't think DNG make sense to put on

Yeah, I have a list several miles long. Looking for a bit of a shortcut. I think <@794205442175402004> supplied the other numbers. They were an average from somewhere.

Really at this point we just have to worry about whether it should be included or not.

THe actual number can come later.

Maybe it would make also sense to add a list element for current adoption? Or just linking to caniuse to compare browser support

DNG *is* TIFF with extensions, hence why I put DNG/TIFF, but I agree only the latter would suffice, but it is very complex

I'd say it's worth having AVIF listed, then we have somewhere to point to when people bring it up (Happened a lot this past week...)

Agreed, AVIF and JXL are the two most modern formats we have at this time, so it makes sense to put AVIF in the comparison

So I'm guessing worse than WebP but better than PNG for placement? They're animated, so… would be nice to know the order.

AVIF and WebP are not necessarily animated

No, no. Those images on the website are animated.

ahh ok, sorry

nice

Found it! https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/edit?gid=174429822#gid=174429822

63% it is.

Actually just realized those are % larger, so I'll have to calc the reciprocal to calc % smaller.

I would recommend replacing bmp with tiff in that section, most people are more familiar with tiff as a lossless alternative to png

At least in the photography world

NASA also still distributes tiff files

yeah but man, saying it's "X" smaller then tiff is a shit show, at least PNG is somewhat standardized in this point

thats true, tiff is kinda a mess 😅

tiff is closer to a container like mp4 rather than a specific codec

Does Lightroom still ask everytime if TIFF should export using compression which "may make it not backwards compatible"?

Can’t tiff store anything from raw pixels to JPEG?

it's more than just that, look at all the extensions tiff 6.0 part 2 includes

https://en.wikipedia.org/wiki/TIFF#Part_2:_TIFF_Extensions

and thats just one tiff spec lol

> Private tags Have fun implementing everything

Yeah, I think that's why TIFF was originally left off the Battle of the Codecs card. Like what the hell do you even do?

simplicity and reliability section lol

Theoretically you could throw a JXL code stream in a TIFF

(If an extension is made)

Would the JPEG column be addressed with Jpegli as well?

CMYK JPEG actually has four channels. It's encoded as YCCK.

BMP is still the default format for pictures embedded inside Windows executables.

Windows clipboard is using it as well.

Windows 11 supports alpha in BMP. It didn't work in Win10 IIRC.

Some would consider CMYK part of the de facto JPEG standard. Most JPEG implementations (like libjpeg-turbo) have no problem decoding CMYK jpegs. But it is a bit of a gray area, because proper application support is often lacking...

Wikipedia has better information. Cloudinary is considering only the older BMP versions.

Would you consider CMYK jpegs as a definitive feature as a 4 channel defacto jpeg?

I would not include BMP since it's basically a Windows-specific thing. TIFF makes more sense to include since it's meant for interchange. Maybe best to stick to baseline TIFF v6 or something, otherwise it gets a bit tricky to define what TIFF actually is.

JPEG itself supports up to 4 components, and it does not care what they are (the original spec does not talk about component interpretation). De facto, it does not support RGBA but it does support CMYK.

I understand now, when I saw 4 channels I thought of RGBA instead of CMYK. Thanks for clearing that up for me. <:Stonks:806137886726553651> <:Hypers:808826266060193874>

lossless AVIF 🤣

the way caniuse tallies adoption is only a starting point for impressions but misleading since it doesnt go into detail. take jxl, when only the tracked mobile users are displayed, 30-35% of *all* mobile users in us, uk, canada and japan support jxl. caniuse also track *actual* usage of browsers, not idle installs capable of decoding jxl. decoding by OSes is not tallied either and we know macos has like hundreds millions active installs decoding jxl out of the box

I think BMP should be listed. It's the native format in the most popular OS on desktop. It's ubiquitous. Web browsers support it, although nobody sane would use BMP on the web.

people know BMP to mean "uncompressed image"

so it's a good way to show compression ratio

disagree. everything is far better than bmp, the baseline reference are jpg and png

That's true. It's the uncompressed format people are familiar with.

BMP can do RLE but only for paletted images so RLE can't be used for truecolor images..

most people's understanding of image formats: BMP: uncompressed, really big JPEG: standard, not amazing quality, good for photos PNG: transparency, good for graphics GIF: animated, good for looping memes WebP: get out of my face HEIC: Apple fanboy alert AVIF: what? another one?

Can confirm that macOS supports BMP with the Alpha channel

By the way the identical lossless JXL is 2.6 MB

BMP supported alpha since WinXP but it was implemented in Windows only in ICO at the time. ICO is very close to BMP but there are some differences.

BMP even supports ICC profiles.

BMP is just bad TIFF at this point

The size of uncompressed PNG is equal to BMP

It's like PPM/PAM

uncompressed PNG?

It's doable with GIMP

oh

at that point why bother

Yes, you can use gzip strategy "store"

Maybe they added the option for completeness.

TIFF never appealed to me personally.

TIFF is one one of the very few image formats that can do both high bitdepth content, proper colormanagement, as well as proper alpha support

I think EXR can as well

EXR kinda can, there are a lot of baked in assumptions which make it ideal for some things but not others, for instance EXR images are expected to be stored in linear float. they are also entirely scene refereed images more or less by design, and allow greater then 0.0..1.0 range

I mean that's because TIFF is every format under the sun with some metadata attached

while true, before JXL there was nothing that could really serve in it's place.

does JXL truncate to 0.0..1.0?

what's the PGX image format?

cjxl can't read TIFF unfortunately.

it would probably be a nightmare to implement every little detail

if it did, it would probably just use a 3rd party library

TIFF can do anything but it's overwhelming.

Have anybody tried encoding deflate TIFF using zopfli? I couldn't find any project like that. There are several for PNG.

indeed, when transcoding tiff images, ill just being using oiiotool

Looks like a similar idea like Imagemagick. Didn't find any mention about zopfli, though.

oiiotool isnt very fancy, it's designed to be accurate first and foremost

oiio is also what Blender uses... One day we'll have JXL... one day...

jxl was added to oiio a while ago

[Hmm](https://cdn.discordapp.com/emojis/1113499891314991275.webp?size=48&quality=lossless&name=Hmm)

Yeah, but then this happened https://projects.blender.org/blender/blender/pulls/118989

https://projects.blender.org/blender/blender/pulls/119257

And nothing since

I thought there could be something like ECT that would do TIFF.

maybe its wroth bumping

No. You can represent out of range values in jxl. When requesting float32 buffers from libjxl you will get the result as out of range values. When requesting uint buffers then it will be clamped to nominal range.

thats useful, it would be interesting to see some EXR tooling get ported to libjxl

which tooling do you have in mind?

viewing support in tev? support in pfstools? something like exrnormalize?

One of the tools I used a little bit is DJV https://darbyjohnston.github.io/DJV/ which was used for previewing renders

ah found the video, I think doing a video like this for JXL would be a neat demo https://www.youtube.com/watch?v=-UjJqwwMJc8

Ahh, I remember that video. Makes me want to do some comparisons in Blender against JXL

ah weird

ffmpeg doesn't work with this image

sadly it doesn't look like ffmpeg (6.1) supports working in jxl like this

this was just using `cjxl -d 0 -e 4 Tree.exr Tree.exr.jxl`

another example

https://openexr.com/en/latest/test_images/index.html images are here for testing

What program is that?

olive video editor

Looks interesting

its good

as far as I can tell its still the only open source video editor that handles color right

So my fork is SVT-AV1 v2 What is taken from svt-av1 2.2.0 1. Switching from YASM to NASM (https://gitlab.com/AOMediaCodec/SVT-AV1/-/commit/4095469a8ff516053bc7ba10d4938d37f9499d30 ?view=parallel) (tafuck) 2. AVX2 microfixes (https://gitlab.com/AOMediaCodec/SVT-AV1/-/commit/a4bd642290e028e97282833722bbe98371f846bb ) 3. Load optimization for 2-5 cores (https://gitlab.com/AOMediaCodec/SVT-AV1/-/commit/911c76502938498c34af50865b2279fa575c7811 ) That is all. The rest of the committees are shit. But since I've been using my fork for 3 months now, hardcode has made significant changes that work on all presets: 1. Use a 64x64 superblock instead of 128x128 (instead of (https://gitlab.com/AOMediaCodec/SVT-AV1/-/commit/9d6572dc4fa256d5daff9de3b222931ceb75ae3e ?view=parallel#8d0aaf3e3054aa9edddd62214850756d026f7b44)) 2. De-block the filter to maximum quality by cutting out all optimizations in which its calculation was skipped (instead of (https://gitlab.com/AOMediaCodec/SVT-AV1/-/commit/20c8dcc29b1230bc36e558a911f389654eb9ec78 )) 3. CfL (https://gist.github.com/luctrudeau/e12497a081b94bbbe5bb889b3f169417 ) counts 2 iterations instead of 1 or skips — Increases the complexity of color compression (instead of (https://gitlab.com/AOMediaCodec/SVT-AV1/-/commit/9d6572dc4fa256d5daff9de3b222931ceb75ae3e ?merge_request_iid=2253#55b67158b0326e8442be9307de2707b12447a39c)) X speed difference on presets ``` old p new 0.47 3 0.41 1.06 5 0.87 1.45 7 1.20 1.82 9 1.51 ```

<:This:805404376658739230>

old new preset 3 crf 63

— I manually looked at all *hundreds *of commits in 3 months and decided that some kind of bullshit there, like disabling superblocks at high quality for 480p (https://gitlab.com/AOMediaCodec/SVT-AV1/-/commit/9d6572dc4fa256d5daff9de3b222931ceb75ae3e?view=parallel#8d0aaf3e3054aa9edddd62214850756d026f7b44 ) or reduced vector search radius for some quality options (https://gitlab.com/AOMediaCodec/SVT-AV1/-/commit/3a7b34c75c81784fbade35e23c1332a396514e5b?expanded=1#8dee898a87eca47a71a7212ddc73a3ed6d2973e5_7687_9105) — But they reported on +performance (https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases#220---2024-08-19 ) (which repeatedly drops at lower quality because fuck (img № 1) (https://wiki.x266.mov/blog/svt-av1-second-deep-dive )) in fact, 90% of the comits look like this

ah found a video I wanted to share https://cdn.discordapp.com/attachments/587033245061873759/1200779163162910840/out.mp4?ex=66cc74bd&is=66cb233d&hm=b99c06cc26c95e46c5369e0be5c2c9f2842a4a08d6f38ed8a330c8bef73ad730&

this is olive scrubbing perf when using jxl d0.5 with faster_decoding=2

I was actually being held back by the raw render performance since this is a 32bit 1080p render on a undervolted rx 580 lol

looking through ffmpeg code, I think this is happening because in 6.1 it only supports integer, seems to not be the case for ffmpeg 7.x, but olive doesn't build against that due to some API changes in ffmpeg

<@174118775753408512> <@1028567873007927297>

Here is good

continuing from <#822105409312653333>

> sure, you need a codec library for whatever codec you're using I would count that as making them different formats

you don't need a different program for JXL modular and VarDCT

from https://discord.com/channels/794206087879852103/822105409312653333/1277957551451013182 to be exact

Sure, they're different formats, the same way ogg opus and ogg vorbis are different.

Still ogg though

that's a container

not a format

or an mp4 with hevc or avc

The payload is different but most of the external structure is the same.

the external structure is the same, sure, however the payload is over 99% of the content of the file

TIFF can contain different codecs too

but we still call it TIFF

well we can all agree tiff is a mess

well jxl has different boxes that can contain completely different payloads and ways to encode image data. I don't really see that as conceptually much different from how a container can have different codecs.

sure, i'll rephrase my original question Which codec is better for image compression, HEVC or AV1?

I'm not an expert but I think av1 was designed to surpass hevc. But x265 seems to do a decent job and is way faster than any av1 encoder I've seen.

I would be kind of surprised if x265 was significantly behind av1. My impression so far is that av1 has been a very bad tradeoff in complexity.

anime scene is cutting edge at av1. the way they encode is not representative of general av1 performance. they encode every short scene separately with ML compares and mux back the whole

sounds like the anime scene tbh

they still badmouth avif at every ocasion hoho. the ressource consumption cost of acceptable filesizes is brutal whatever you use

Jyrki seems really good at what he does and really motivated. He improves jxl/jpegli quality all the time :)

av1 is generally better then HEVC for quality at medium to low fidelity. svtav1 is generally better then hevc for encode speed and fidelity when working within the constraints of yuv420p. no encoder right now cares really about high fidelity compression except for rav1e which, calling it on life support would be an understatement. it's slow as molasses because of that.

one of the issues with high fidelity encoding with av1 right now is you have to really wrangle the encoders. svt-av1-psy does a decent job at that, but a dedicated fork shouldn't be necessary for this

rav1e was good at still images (avif)

but recently libaom improved a lot so idk if rav1e is still better

probly not

the other day I made a fork of svtav1 "super-placebo" for myself. the search radius of the vector is 256x256 and the number of iterations of CfL=100. it is 3 times slower than the minimum preset -1. and yet it gives a slightly better picture, visible even to the eye when comparing 2 images. it's strange why it's not in the encoder.

how slow is this?

like 25 seconds per frame on 1080p?

for only intra I would doubt it. but it may be still, not sure I don't test it very often, don't really have a reason too since I only use av1 on images where yuv420p makes sense, so it's svt all the way

AV1 can really be better (the encoding speed for 6 "zen 4" cores is about 100 times slow than the input duration)

<:AV1:805851461774475316>

for 1080p, I would probably increase the search radius even more by killing the speed. but personally, I stick to the rule — 10 bit 1280x720 30 fps, or 8 bit 1280x720 60 fps, or 10 bit 960x540 60 fps. everything above is absolute death, both encoding and decoding, since my goal is strong compression in telegram for smartphones, 1080 is a waste of pixels.

it is better to make 720p by increasing the quality and low preset — the quality of pixels is more important than their quantity <:This:805404376658739230>

nah, what about my 1mbps 8k stream?

you're telling me that was a waste of time?

absolutely. I wouldn't even be able to play it.

At 1 fps

yep

Not sure about that. I think it's more like av1 was meant to be a royalty-free alternative to hevc, with roughly equivalent compression performance (while avoiding the patent minefield).

lie

the aomenc just suck

SVT-AV1 surpasses all other encoders, both in speed and quality/speed and in quality limit

I can't speak for the spec because I really can't be bothered to read through av1's behemoth of a spec, but the actual encoders themselves are out performing x265 in compression:quality by quite a large margin now for medium and low fidelity. and for higher fidelity, if you can manage to wrangle aomenc it's decent too

Not as long as SVT-AV1 only supports yuv420

avc vp9 hevc av1 maximum possible parametr ( avg speed 0,005x)

and 10 bits.

true

That's full enough

i cri ery tiem [pepehands](https://cdn.discordapp.com/emojis/1075509930502664302.webp?size=48&quality=lossless&name=pepehands)

svtav1's 420 limitation blows

avc vp9 hevc av1 10 bit

all looks gread 👍

It's not too bad if the source is 444 or RGB, but 420 to 420 via AV1 is recognizably worse looking, even without zooming in a lot

It's not "bad" by any means, but still visible

I don't understand why this is a problem. in my super-placebo fork, I set a brute force (100 iterations) CfL and now no problems with the colors in my usual fork, I do 2 iterations on all presets and have no more problems with colors.

Maybe the defaults are not ideal?

because 420 is unacceptable for stuff like text

420 is also mostly alright for non-animated content, since red is not too prevalent in real life footage

svt-av1 cfl 0-2 iterations by default do not save color so well, although the function consumes almost nothing

HEIF is indeed only a container, though it somewhat blurs the boundary between container and payload codec since it does bring some functionality that would be codec functionality in an image codec (but since the payload codec is not necessarily an image codec, it has to be brought to the container level). For example: alpha, orientation, tiling, color profiles, blending multiple layers. Those are things jxl does at the codec level, but video codecs don't support these things and HEIF bridges that gap.

increasing the number of iterations also solves this problem.

So it is a container that does bring some functionality of its own, and requires significant implementation effort, to the extent that Nokia is claiming it has patents relevant to it.

the color problem is solved by a stupid increase in the number of CfL iterations

this is crf 60

It was certainly difficult. And it killed as much as 5% of the performance on preset 3 and 10% of the performance on preset 7

And no more complaints about yuv420. because yuv444 1. Slow encoding performance much more 2. Slow Decoding speed 3. Not included in the main profile av1

Im working with VDI, I need a lot higher fidelity then a game

<:megapog:816773962884972565> then a game

This is understandable, for pixel-to-pixel streaming is really a very specific request. And yes, there is nothing better than avc x264 for this.

with -x264-params deadzone-inter=0:deadzone-intra=0:trellis=0

and aq-mode=3:aq-strength=1.40:qpstep=10:qcomp=0.70 for dark game

In all other codecs, it is impossible to disable functions that destroy details, noise (and everything else that harms compression). Only in AVC there are functions like that that are absolutely not documented anywhere, and you will not find a description of what they do anywhere on the Internet (because lies are written everywhere)

It doesn't seem to be quite right. Because before that, Google had already made Vp9 (which should be superior to HEVC, but not lol) Judging by the fact that there are so many companies, patents in the Aomedia alliance, and the fact that the final documentation has never been updated over the past 6 years. The goal was precisely that everyone was tired of different codecs that compete with themselves, and all are bad. Therefore, after collecting all the patents, they chose the most versatile functions that it was possible to collect from all existing developments. So that AV1 is the best in everything at the same time. Both movies and animation, 1080p and 360p. And it should all be uncompromisingly better. The best technologies that were just invented at that time. And super innovations in the form of CfL and CDEF filter

The best algorithm for finding motion vectors, the best deblocking filter, the best temporal filter

The best noise reduction filter, at the NLMeans level

Timing-wise, av1 sits between hevc and vvc, like vp8 sits between h264 and hevc.

And all sorts of very complex things like encoding motion vectors after the movement. When the object is in the future, but the codec saw it, and took information about it from the future. I don't remember, but it seems like it was in HEVC

I don't think it makes sense to talk about vp8 in general. This codec is completely dead. Unlike x264, which is still being dev, and which is much much wider in its capabilities (yes, take at least the search area of the vector that x264 can set to 512x512)

(pic with last x264 commits)

Any codec is only as good as the best encoder that is available.

And no, HEVC has such a problem - on presets less than Medium, it play in quality like AVC, which will be encoded at the same speed. Moreover, at 360p resolution, AVC completely outperforms HEVC at any speed when they are equal. This is also due to the monstrous bad parallelization of HEVC

The parallelization of SVT-AV1 is much much better, it is even better than that of AVC. This is the most parallelizable codec in general.

I don't agree with that. Zstandard is better than Deflate. Absolutely wherever possible.

isnt that a different codec though <@226977230121598977>

currently we are using both h264 and vp9, typically we use 444p but for lower bandwidth reqs we do drop down to 422p most people care about quality more then they do frame rate so 25-30fps on the low end is fine.

ok

Is this a problem?

yes because you disagreed with the statement "any codec is only as good as the best encoder that is available"

that statement is true if the codec is the same but the encoder is different

your example is of two different codecs

well vp8 has only libvpx

And from AVC, I just choose the best one (x264)

I understand what you mean, but I don't look at the world that way. There is a task, and I need to solve it, and there are tools that can solve it. And I'm just taking the best tool I have. And it absolutely will never be vp8. because it wasn't made to be the best. it was made at the time to be at least some kind of the only alternative, before the patent codes. The same way as Vorbis. Only LibVorbis was not abandoned as vp8. And vorbis is still the fastest audio codec in terms of decoding speed, and has been used in all games for compress music for over 20 years

Yeah that's what wb is saying

You wouldn't be using h264 if x264 wasnt really good

and even though vp8 is better that h264 on paper its available encoder(s) are not as good as x264

despite the fact that vp8 is still being updated. I just can't understand why they can't make it better. In 2024, it would be possible to spend 100 times more calculations to get better quality. But it seems these are fundamental limitations of the documentation. Limitations that kill potential. And this is the opposite of H264, which has extremely complex and potentially better feature . There are so many different Ways that we could use much much later, 10 years later, and this is what vp8 does not have

VP9 has the same problem. Although its much bigger problem is parallelization

How much potential was killed by the lack of yuv444 in **webp**. Or a limit of 16k x 16k size

It's good that neither AV1 nor Jpeg XL have such problems - which allows them to get better and better

the next 10 years <:JXL:805850130203934781>

I was encoding 720p x264 on a dualcore CPU, that was fun.

That was the moment I realized I should get a better CPU.

Literally me. I can give you my innovative compression preset, 4 years of studying x264 Although I did it mainly for XEON 24-48 cores. It is also suitable for fewer cores. ``` fast ffmpeg -i input_file -pix_fmt yuv420p -vf "scale=960:540:flags=bicublin,hqdn3d=luma_spatial=2:chroma_spatial=2:chroma_tmp=5:luma_tmp=5" -c:a copy -c:v libx264 -profile:v main -preset veryslow -bf 3 -refs 5 -crf 25 -g 1200 -x264-params "me=dia:scenecut=40:chroma-qp-offset=-6:psy=0:subme=7:weightp=0:weightb=0:deadzone-inter=0:deadzone-intra=0:direct=none:b_adapt=0:b_pyramid=1:trellis=0:rc_lookahead=250:aq-mode=3:aq-strength=1.40:qpstep=10:ref=5:qcomp=0.70" -f -f matroska OUTPUT slow ffmpeg -i input_file -pix_fmt yuv420p -vf "scale=960:540:flags=spline,hqdn3d=luma_spatial=1:chroma_spatial=1:chroma_tmp=3:luma_tmp=3" -c:a copy -c:v libx264 -profile:v main -preset veryslow -bf 3 -refs 5 -crf 25 -g 1200 -x264-params "me=esa:scenecut=40:chroma-qp-offset=-6:psy=0:subme=9:weightp=1:weightb=0:deadzone-inter=0:deadzone-intra=0:direct=auto:b_adapt=2:b_pyramid=2:trellis=0:rc_lookahead=250:aq-mode=3:aq-strength=1.50:qpstep=8:ref=5:qcomp=0.70" -f matroska OUTPUT ```

holy

Since I have a powerful processor, I also have a "Legacy" - super preset for myself. ``` very slow ffmpeg -i input_file -pix_fmt yuv420p -vf scale=960:540:flags=spline+full_chroma_inp,hqdn3d=luma_spatial=0:chroma_spatial=0:chroma_tmp=3:luma_tmp=3 -c:a copy -c:v libx264 -profile:v main -preset veryslow -bf 9 -refs 5 -crf 25 -g 1200 -x264-params me=esa:scenecut=40:chroma-qp-offset=-4:psy=0:subme=9:weightp=1:weightb=1:deadzone-inter=0:deadzone-intra=0:direct=auto:b_adapt=2:b_pyramid=2:trellis=0:rc_lookahead=250:aq-mode=3:aq-strength=1.50:qpstep=8:ref=5:qcomp=0.70:fast_pskip=0:me_range=64:lookahead_threads=1 -f matroska OUTPUT ```

Meanwhile I moved to 6 cores, 12 threads, although I could always use more.

I was using just simple slow preset with satisfactory results.

Try mine, compare the speed, the quality. You may be surprised<:H264_AVC:805854162079842314>

It was a while. ffmpeg didn't yet have a stable AAC encoder back then so I was using libmp3lame for audio, making Frankenstein mp4s with AVC video and MP3 audio.

It's quite normal

Actually cursed. I still have some old encodes lying around with that codec-combo

In very rare cases, I use MP3 for some super-legacy moments, for example, LCD TV from 2007 or something like that

Or for example, I have a 2013 TV. and for some reason, about once every 1 hour, the stream from the twitch, from which I copied the AAC track, has a glitch sound, or playback is completely cut off (the audio codec breaks) - I have no idea why this happens, some legacy shit - it can be useful to just take the Mp3 exclusively for yourself

I can't hear any difference between 192 kbps AAC and 192 kbps MP3 so it's fine for me.

-q 9 -b 320 leeeets go

Kinda overkill for a mono audio from a camera mic.

💀 for this, 64 kpbs will be overkill

Opus 8kbps and be square <:kekw:808717074305122316>

I think 64 kbps MP3 is the absolute minimum for mono audio. I was actually using 64 kbps for recordings from an older camera which recorded audio in 11025Hz 😄

The uncompressed PCM was 88kbps, you can't go much worse.

I have an audiobook copied from one of those "MP3 CDs", encoding is horrible at 22KHz and 80Kbps Stereo

Ah aduio books. I know these. I was copying some CDs and they were already damaged brand new. The drive was constantly slowing down as it had difficulties reading them.

Everything was readable at the end but the disks were apparently sloppily made.

standart svt-av1 placebo my super-placebo fork the great speed=0.0357x (fps=1.1 q=62.0)

It's a pity that MP3 doesn't have some kind of BruteForce mode. Although FLAC has it

flac.exe -peml 12 -r 8 -A subdivide_tukey(5) IN.wav ❤️‍🩹

I also had some audio in APE format. No idea why would anybody use it over FLAC.

No big deal, lossless formats can be converted back and forth.

As funny as ALAC

There were also funny uncompressed PCM formats. Does anybody remember VOC, for example?

🧱 wav.xz my beloved

Yay, not that great for realtime playback, though.

You could use avi.xz for lossless video as well. Did you know uncompressed AVI is basically animated BMP?

I'm fucked right now at what I'm getting at with the fork super placebo. From how super complicated the encoded picture, it completely breaks legacy-level-profile. It decodes 2-3 times slower than standard presets

<:AV1:805851461774475316>

Well, it seems that I will have to spend another couple of weeks disabling all possible elements of the encoding settings in order to understand at what point in the encoding it fills the file with something that is extremely difficult to decode. It's good that I know for sure that this is not a problem in the length of the vector search, CfL, or a strong deblock filter.

Perhaps the problem is the insane number of non-square elements like 4x8 or 8x2 or 3x2 blocks

OK, something that happens on preset 1, but doesn't happen on preset 2. Even though they should be exactly the same in terms of features enabled. Obviously SomeOne lie in the DOCS https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/CommonQuestions.md?ref_type=heads

and this "that happens" kills the decoding speed by 2-3 times

on standard svt-av1 same

The limitations of video codecs being ram-rodded into an image format are laughable and embarrassing compared to the future-minded approach of jxl

I think the shame and embarrassment of inadequacy is probably playing a factor in Jim's decision to remove competing formats.

4:2:0 color, literally unusable-bad lossless, huge bloated container, tile boundaries, size limitations, extremely slow performance...

I would be really embarrassed if I turned in an assignment like that and the guy next to me made JXL

Maybe that is playing a psychological role.

Damaged Intel CPUs seem to be often failing in data compression. Perhaps zopflifying some PNGs could be a good reliability test.

Letting ECT running overnight.

i found

I suggest comparing how the image looks after disabling this function, the same encoding time, the same bitrate, the decoding speed up is 2 times

(I'm not even going to say which picture it's on and which one it's off, lol)

I can spot MP3 at 320 kbps from anything else with music.

I cannot, but I still strongly prefer FLAC because of its lossless nature

Sure if I compare the samples decoded from 320kbps MP3 with the source PCM, there will be differences.

Hearing differences in audio is not that easy like comparing two pictures. You can't "zoom-in" the audio.

I'm also using FLAC, just not for encoding audio from a cheap noisy microphone.

I’m in the mindset of MP3 (preferably Opus) is fine for distribution, but do NOT convert your WAV/FLAC to any lossy format without keeping the original

Agreed

I’m personally a fan of WavPack hybrid

FLAC for me with Opus on mobile

Probably what I’m gonna switch to

the mobile music playing device I use is an iPod Touch, so AAC for me

(fdk-aac via ffmpeg)

I have heard very good things about the exhale encoder

https://gitlab.com/ecodis/exhale

https://gitlab.com/ecodis/exhale/-/wikis/faq

I have bunch of WAV files using ADPCM compression. It's some kind of simple lossy compression with fixed compression ratio. There are several different ADPCM codecs, not sure what are the differences between them.

seems to be for low bitrates; I’d rather just use AAC-LC

`ffmpeg -c:a libfdk_aac -vbr 5` is my go-to

QAAC is a better encoder that fdk from what I remeber, but QAAC is not open source 🤮 or rather, it requires blobs from iTunes

I'm just using the builtin AAC encoder as I don't feel like compiling ffmpeg myself.

As suggested, if I needed flawless quality, I'd use FLAC.

yeah, that’s what I keep on my PC

but realistically, for my iPod Touch, fdk with -vbr 5 should do

The ADPCM doesn't sound that great considering the relatively high bitrate, but the best option is probably just leave it.

I discovered them by accident when the `flac` utility couldn't read the wav files. `ffmpeg` would convert them without issues but it wouldn't do any good.

I have tried `adpcm-xq`, it's not actually terrible, it's not great though

This is Microsoft ADPCM in particular.

`adpcm-xq` is an IMA ADPCM encoder, which is what WAV's ADPCM setting uses

it's an ADPCM encoder with noise shaping

this is with speed setting 3 out of 6

i'm planning to try to build an adpcm hardware decoder in some hdl language as a challenge

As I said, I don't know what's the difference between individual ADPCM implementations. And I didn't encode the files, I just found them.

most of them are the same

Supposedly MS ADPCM should be the default as WAV is MS format.

hmm, apparently MS ADPCM is slightly different, but IMA ADPCM is also supported in WAV, so probably use that instead, it's apparently better

That's possible. Microsoft is not exactly good at making audio codecs.

cough cough wma

also, IMA ADPCM is more supported, as it's the de-facto standard ADPCM specification

https://tenor.com/view/vade-retro-satanas-gif-13170841

You can also force MP3 as payload inside WAV file to trick someone.

just because why not?

yep

huh, discord supports it?

Perhaps it thinks it's an mp3 file with weird padding at the beginning.

yeah

it's probably just skipping the beginning and syncing with the internal MP3 data

when downloading it from Discord, it's called an MP3 file

The structure of MP3 files varies so the software has to do more digging. As a result, it can find MP3 data like this.

like how ID3 metadata is just yeeted at the beginning?

Yes, like that

this actual MP3 has an entire JPEG at the beginning

Album art I think

I wonder if the WAV MP3 can be put inside another WAV 😄 Did you use ffmpeg? It did some cleaning, it seems. Would be fun to put the JPEG in the WAV as well.

I think FFmpeg would detect the WAV header

Yes I used ffmpeg

Ffmpeg demultiplexes the metadata and thumbnail separately

I could probably force it to stream copy everything as “Junk data”

But theoretically you can just Comcast the headers to the mp3

Concat *

MP3 is weird one as it doesn't use container.

Yeah it’s just a stream

So demuxing is just stripping non-audio data.

There are defacto headers like Xing but that’s mainly just for VBR seeking

Speaking of retro. What about MP2? In my experience, MP2 sounds actually terrible.

MP2 produces unpleasant high frequency spikes.

Or did everybody just used very bad encoders? libtwolame doesn't seem to have this issue.

Someone tried QOA?

Twolame is actually decent

The FFmpeg in build mp2 decoder SUCKS

I have no idea what encoder was used in TV broadcasting but I'm glad MP2 died with DVB-T

and DVDs

The audio was atrocious.

they technically support mp2 but i've never seen one that actually uses it

VCDs exclusively use 224 kbps mp2

Most DVDs used AC3, that's alright.

yeah

and Blu-Rays get that oh so sweet lossless audio

(most of the time)

I don't want to listen to audio where every sibilant is like a needle stabbing me in the ears.

The MP2 was that bad.

I’ve seen it claimed that MP3 doesn’t achieve full transparency at any bitrate but that MP2 can

not sure how much truth there is to it

is MP3 a strict superset of MP2?

MP2 was also used for pre-recorded announcements in public transport etc. and that's probably the only fitting use case IMO.

Musepack is supposed to be pretty good quality and it's based on mp2 and very fast

I don't think that JPEG XL is bad given its partial compatibility with JPEG. AVIF and WebP 2 are very competitive in terms of file size alone... Maybe this wasn't the case several years ago. Multimedia is much more complex than just file size...

I have a friend who designs the highest quality headphones... which he makes manually to order. And yes, I did blind tests with him, he was able to distinguish everything. Moreover, it can easily distinguish ALL mp3 qualities for 320 kbps (lame q3 q5 9) from the best to the worst But, on lame -q 0 -b 320, for the first time he was unable to do this. (as far as I know, this is the highest possible quality that MP3 can achieve in 2024)

try <:This:805404376658739230>

You can always produce smaller files, but quality must also be a factor. When you do, jpegxl is very competitive too. Even more so in lossless

I hope your friend takes care of his ears and isn't losing his powers!

I mean, it's possible.

hopefully they aren't one of those people who say they can hear the difference between WAV and FLAC

no. in addition, of course, I conducted a completely blind test.

320 kbps MP3 certainly altars the sample values in some way, so it's not impossible somebody could hear it.

After all, lossless codecs use much higher bitrate, so some loss in MP3 or MP2 is unavoidable.

I know, it’s just some people genuinely believe they can hear the difference between WAV and FLAC

You're right.

I've just pointed out, that when using a lossy codec, the integer values representing audio samples are always slightly changed.

As long as the integer values don't change, the audio is exactly the same. You can just convert FLAC to uncompressed WAV and don't tell them 😄

Also just wondering, where do you get FLAC music (if you do at all)?

is there a place where the HEIF spec is not paywalled?

steal || I also have a friend who has a database with over 200 terabytes of completely stolen source flac music. I think he has enough for a lifetime. ||

~~ah I think I found it~~ maybe not links were dead

Rather, these are the resulting consequences of the widespread Subscription System in our time. By buying a subscription, you actually become the owner of absolutely all the music on this service. A couple dozen subscriptions for everywhere. And so. All the music. Take to...

Steal = go to the store and snatch CDs, or pirate?

Streaming != owning, steaming = paid version of public library

<@386612331288723469> It's hard for me to talk about this topic because I'm Russian. I just go (in The Internet) and steal anything, because the laws of my country allow it.

|| Of course, this is exactly why my friend has 200 terabytes of data. Data can just as Suddenly delete from that place. where it on the streaming service. ||

Brb

<:PepeGlasses:878298516965982308>

This is one of the funny national facts. What, the Internet has developed so quickly that Blu-Ray has never come to us. After the DVD, there was only the Internet. And nothing else. And the shops where you can actually buy physical copies of something have simply disappeared, its do not exist at the moment. This is perceived as retro. The DVD reader died about 10 years ago. (We also completely do not have cult of physical copies, or similar collecting.) Because of this, this is what happens: something can only be legally purchased on the Internet. *And everything was fine until the events that I will not comment on took place in 2022.* But because of it, we were forbidden to give money to someone, I have money, but I can't give it. *shut up and take my money* just not work. (although I can give it on Steam)... And what should I do? Of course - torrent do brbrbrbrb This is especially funny considering that the VDSL and ADSL network is very developed in Europe. While in our country, Phone wired communication has been completely killed at the moment, which is why we have an only high-speed Internet connection.

To be honest, I have never seen this format really anywhere at all. I see being discussed. But I don't understand, but where do you use it like ?

Why is HEIF even in 2024?? If you want to compress better - use AVIF/JXL (depending on what is available) If you want to compress/decompress faster, then use WEBP (especially relevant for 4k+ photos)

it's the base format for heic and avif. avif and heic specs "modify" the heif format

basically you need to implement heif to implement heic or avif

but speaking of it, you most likely have exactly HEVC-based

prolly I dunno, couldnt say

all I know is that I cant seem to find the actual base spec for free

Yep

Okay, I just stole it <:kekw:808717074305122316> but 2017

[av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=av1_dogelol)

[dorime](https://cdn.discordapp.com/emojis/979397787970072596.webp?size=48&quality=lossless&name=dorime)

I found some LBM images. Does anybody remember that format?

https://github.com/Chocobo1/opus-tools_win32-build I went to get the latest builds of opusenc for Windows.... great! another AVX-only build project. for both x64 and 32-bit lol

the official page is certainly completely abandoned

Is the official page hosted by the xiph guys?

yes

Maybe they just died

did Xiph get absorbed into AOM?

AOM audio codec when?

The latest Tag is 1.5.2, but they have long stopped providing releases for some reason

classic. I remember kicking the JXL developers when they didn't release, it seems, the 0.7 version on github, or so

But at least they have a hidden website with builds. And xiph doesn't have anything... or?

```➜ ~ opusenc --version opusenc opus-tools 0.2 (using libopus 1.5.2) Copyright (C) 2008-2018 Xiph.Org Foundation```

they haven't updated the copyright in the version text