JPEG XL

For AOMENC in ffmpeg i use ```ffmpeg.exe -i ... -pix_fmt yuv420p10le -map 0 -ac 2 -c:a libopus -b:a 87k -vbr on -application audio -apply_phase_inv 0 -c:s copy -vf "scale=704:396:flags=spline" -c:v libaom-av1 -cpu-used 4 -crf 25 -lag-in-frames 64 -tune ssim -g 1200 -threads 1 ...``` or non-song ```ffmpeg.exe -i ... -pix_fmt yuv420p10le -an -vf "scale=704:396:flags=spline" -c:v libaom-av1 -cpu-used 4 -crf 25 -lag-in-frames 64 -tune ssim -g 1200 -threads 1 ...```

I've already spent a week and compressed 6 seasons of different anime with these parameters, and I'm watching now. they all have absolutely a problem with the fact that the key frame is BEFORE the key frame, and it's not fucking funny

SVT-AV 1 acted even funnier, at speed parameter 6 it simply did not recognize any correct keyframes, and at speed parameter 4 it did not recognize any frames at all and made all 17 seconds of video in one keyframe.

ahahah

Rav1e just Work

<:AV1:805851461774475316>

but Rav1e just has a ugly coding quality.

I was able to solve this problem, now I will find out which of the encoding parameters is reason, it's actually just a **fatal bug**, but I do not know what to report

-lag-in-frames 64

this parameter breaks the algorithm for analyzing keyframes, but I want to note that the default parameter of 25 is very small.

I found: Another effect of lag-in-frames is the kind of scene detection the encoder decides to choose. 0-18: No scene-detection. 19-32: Scene detection mode 1 is active(due to limited future frame prediction) 33 and higher: Scene detection mode 2 is active due to large number of future references allowing for the highest level of scene detection present in aomenc and more information is gathered.

WELL aomenc Scene detection mode 2 does not work correctly - some programmer missed ONE digit in the code and the keyframe is assigned with a shift back to another frame

Wait, how are you using this setting? <:kekw:808717074305122316>

This is not present in mainline aomenc, just in aom-av1-psy.

until recently, there was a maximum of 48, but recently, six months ago, it was expanded to 96

but it doesn't matter because this shit is BROKEN

Uh, that's only a thing in aom-av1-psy. It was never expanded to 128 max in mainline aomenc... It's still 48.

128 in aom-av1-psy

i just set and just use

all works

Anyway, I'm surprised you're having issues with scene detection honestly. Never had a problem with it.

damn, I'm so angry because I fkd up a week of work and the whole result with each KEYscene is a MISTAKE

Okay, I've tested it now, 32 works well, and I'll stop there.

by the way, detector 2 works really better, for example, the transition to blackness, the last frame before there is nothing in the frame, it was correctly identified as the key. BUT the error with the shift of all frames make all this useless, I hope someone will notice it and fix it.

Do you think there will be a VIF (Verasatile Image Format) a la HEIF (High efficiency Image Format)?

would that be needed now that AVIF and JXL exist?

who knows. they will still release it just for format wars...

HEIF is already used for 3 codecs, another wouldn't "hurt"

VVC in HEIF, why not. But I don't think anyone really believes that patent-encumbered still image formats can get widespread adoption.

vvc🤣 hevc<:ReeCat:806087208678588437> heif<:kekw:808717074305122316> heic

HE**V**C is even used in 2 image formats <:PeepoDiamondSword:805394101340078092>

man what is the point of heif

if none of the heifs are interchangeable

i guess maybe it's kind of like bmp

and how jpeg and png can be in bmp

heif is just a container that allows you to do some stuff like layering, tiling, orientation, embedding ICC profiles, etc with payloads that do not necessarily support those things

also worth noting: Nokia claims it has patents on heif itself (the container format, regardless of payload)

heif does have ways to signal what will be the payload, so it's relatively easy to see what kind of decoder you'll need

in a way it's not that different from how video containers work: they also typically allow you to use various payload codecs

will we see jxl in heif

that was a question actually at the previous jpeg meeting

my opinion was: no, we don't need that

all the functionality of heif is already supported natively by jxl so there really is no point having an orthogonal mechanism to do things like layers, tiles, orientation etc

also heif is patent-encumbered and quite verbose - it has a pretty large overhead, which for video is fine but for small images is an issue

now i want jxl in mkv

so the conclusion was: no, we're not going to do anything to define jxl in heif

thank god

yeah making 1482 byte avifs was kinda hard

jxl tracks in a video container could make sense... why not have a nice picture or slideshow of pictures that comes with an audio track and maybe even some subtitles

it looks like mkv facilitates anything given a codec id/name and just the data

how is adding a codec done for heif?

or will i have to pay to find out

ironically the heif spec is not behind a paywall

somehow they managed to convince iso to drop the paywall on it

(but if you want to deploy it, presumably you need to pay licensing fees to Nokia)

bmp is kinda funny but the wikipedia page is my favorite among formats <https://en.wikipedia.org/wiki/BMP_file_format>

AVI is partially based on BMP.

VVC in HEIF as VIF/VIC would be interesting performance wise though. Not sure how much of the claimed ~50% improvement would be relevant once you take away the tricks for video and only have the still image improvements.

Everything always claims 50% improvement but that's usually only using some irrelevant metric like PSNR, and comparing the slowest possible encoder of [new thing] against the worst possible encoder of [old thing].

It's also only true at very high resolutions(4k+), but that's perfectly fine for images since they can easily be as large or much larger than that. To be fair though, they compare reference implementations vs reference implementations. To get 50% coding gain from AVC to HEVC in video for example, MPEG members tested HM(h.265) vs JM(h.264) at 4k, which is how they got the 45-50% better coding gains(according to PSNR and SSIM). The gains are lower for 1080p(25-30%).

ok, but still, PSNR and SSIM are pretty easy to fool

Oh I know, but it makes sense if you look at how they evaluate stuff 😄

What you said on Twitter is very interesting in that regard though.

are there any reasons why you are seriously talking about AVC and HEVC? lol

only Apple and *torrents* use hevc

for obvious reasons, some TVs support HEVC

the latest versions of SVT-AV1 at speeds of 9-13 are ahead of AVC in both speed and quality, almost comparable to HEVC

this is such a gigantic reach that now I don't even know why HEVC continues to exist

AVC remains as the fastest encoder on its minimum preset - SLOW and below

uhdbd uses hevc

well, it will be difficult to change it, to decode 4k AV1, you need more player power, and this is already ten years of use history

(In fact, I have never touched BD discs in my life, so I have nothing to say here, high-speed Internet appeared in Russia so early that after the DVD we immediately switched to using the Internet only)

TV broadcasters are very good friends with MPEG so they won't change their mind any time soon. They will be using their beloved AVC, HEVC, VVC and AAC forever. That means support for those codecs is mandatory in TVs to decode terrestrial and satellite TV signals. Similar situation is in digital radio which relies on AAC and AAC HE.

I wonder how slow the rollout of VVC will be, would broadcast TV even be relevant by then?

Like here (Australia) the rollout has been so slow that it's been eclipsed by streaming

Here in the middle of the Europe, terrestrial TV is still relevant and it's a reliable way to let people watch ads. Terrestrial TV is free to air. Most channels are in SD, only the state TV is HD. Who needs more HD channels, can rent a cable, satellite, IPTV service. I suppose there will be motivation to switch to newer codec so more TV channels would fit in the spectrum and TV stations could sell more ads. The next logical step is VVC, most of the content would be still in SD though.

How much compression advantage does vvc really bring though in SD? Assuming realistic encoders, no superslow software encoders...

Not much but as long as people are will to watch it, it's worth it.

HEVC is used for SD as well.

After switching to VVC they will just cut the bitrate to half and call it a day.

Most people are using some kind of paid TV service anyway. Internet providers usually provide Internet, TV and telephone in one service. So FTA TV is meant for people who don't use internet or don't want to pay for TV.

In my country satellite tv is popular and the satellite setup boxes come with hevc support.

only the fhd channels use h265 though.

Satellite TV is paid as well. Getting TV and internet in one service is usually better value.

yeah I'm going for internet+tv from next year.

Speaking of Bluray, this seems to be pretty niche product as optical drives are disappearing from computers and game consoles. I wouldn't use Bluray movies as a good example of codec usage. After all, a Bluray movie can be also encoded in MPEG2 or VC-1 aka Windows Media Video.

I personally use x265 for encoding my own videos

my phone can record to hevc as well

4K Blu-rays (required for HDR) use H.265

My old camera was recording 720p video in MJPEG. The video files were huge. I needed some way to shrink those videos using "visually lossless" compression. There were few codecs to choose from. There was XviD but it was already too obsolete. Also hardware decoders were pretty buggy with XviD. Then there was AVC with decent hardware support and x264 encoder was already well developed. Then there was HEVC, very new, poorly supported in HW. And AV1 was not a thing yet. So AVC was the perfect choice. At that point, ffmpeg didn't have a stable AAC encoder yet, there was only some experimental one. So I just used libmp3lame for audio. MP3 doesn't seem to be a problem in MP4 files.

nowadays, my go-to AAC encoder is fdk, but unfortunately it means having to build ffmpeg from source because of the license

Yeah there were some external AAC codecs available but using MP3 was easy enough. Honestly at 128kbps for mono audio from the camera mic it doesn't make much difference.

i think a lot of streaming services use hevc for 4k and/or hdr

That makes sense, it's pretty much the only option that will work in most TV's. CPUs in TVs are pretty underpowered, so relying on software decoding wouldn't be a good idea.

I can imagine that another option to deal with Motion-JPEG would be lossless transcoding to Motion-JXL. I'm not sure if MJXL is a thing of if it would be useful at all. I also suppose it wouldn't include JPEG reconstruction data as it would make things much more complicated.

There was some talk about it a few months ago here. It was mostly decided that ffv1 is better for most lossless video purposes, but there may be a place for a stream of jxl frames for low latency applicatons, especially with something like fjxl's encode speed.

too expensive, I read about the progress of EVC in the TV industry

read about EVC

on the Release the advantage of 1 percent was declared before AV1, but now we have such graph for 4k video, and here you can see that the efficiency of VVC appears only at an ultra-low-speed coding with of 10% best compress then av1. this is so slow that it will take about a day for 360p 60 seconds video on a threadripper 64 core

I am simply amazed by the metrics that for VVC is "faster" at the SVT-AV1 speed 4 level, I use 4 as the maximum quality metric after which there is already an unbearably long coding, and with all this, there is no point in VVC because it loses AV1 in quality on its "FAST" capabilities

(slight off-topic: do all of them scale well to 96 cores after all?)

no one scales at all

AVC scales well, HEVC is also not bad, but starting with VP9 to improve compression, codecs began to take into account all parts of the image for efficiency, and therefore parallelization now always leads to a direct division of the frame into parts and degrades the quality noticeably

video encoding, if it is large, is now done like this - we divide the video into pieces for 1 minute and encode each piece into one thread on One core, then glue everything together and get an ideal video

I would be very surprised if next generation DVB used AV1 and Opus. They are using industrial hardware encoders.

oh, if it made sense to change the DVB standard at all

There will be need for higher density codecs as frequencies used for TV broadcast are repurposed for mobile data.

people want HD channels, this is no longer a problem, because if there was some kind of Bandwidth Deficit, 4 ordinary SD channels would work instead of HD. in addition, changing the entire system that has been going on for the second decade is well, so-so, for SD content AVC shows itself perfectly

They changed the DVB standard once, so they can do it again.

it's been so long<:H264_AVC:805854162079842314>

We have SD in HEVC now.

ha ha, no

AVC is better than HEVC on SD content, this is the bitter truth. even so, AVC is encoded about 10 times faster

Yes but they're using HEVC anyway.

well money moment

Indeed, it forced people to replace their TVs or buy conversion boxes.

new technologies mean need to change everything replace everything reconstruct everything and pay for everything

<:Stonks:806137886726553651>

Still better than MPEG2 that was used before. AVC was in fact completely skipped.

what are you talking about now?

Before HEVC, DVB was running in MPEG2.

Yes, that's right. That's how it should be, it's wise

no

DVB-T 1997 use MPEG2 DVB-T2 2003 use AVC aka h.264

DVB-S2X is an extension of DVB-S2 satellite digital broadcasting standard. 2014 can use HEVC

Yes it was. As you said, it's necessary to change everything, so they were using DVB-T MPEG2 until recently and then they switched to DVB-T2 HEVC. Completely fresh start.

DVB-T2 came out in 2003 and hevc in 2013 what's wrong with you?

Because my country was using DVB-T long after it's obsolence.

u from france?

I'm from Czechia

https://www.mpo.cz/en/guidepost/for-the-media/press-releases/czechia-switched-to-2nd-generation-of-digital-broadcasting-and-completed-the-transition-to-dvb-t2--257698/#:~:text=The%20Czech%20Republic%20has%20completely,a%20better%2Dquality%20digital%20broadcasting.&text=It%20concerned%20at%20least%202.5,used%20a%20free%20terrestrial%20television

this is extremely unique

yes....so before that you didn't even have HD TV

We did not. HD is considered premium, you have to pay for it. Only the state TV is HD in DVB-T2.

well...okay

Me too, I used to, then I just thought why am I doing this. and I started recording original videos on my smartphone in 640x480 resolution because I don't need to anymore

the valuable of a pixel is more important than their quantity

they also true when designing television

128 for mono is really more than enough, and there is not much of a problem with the sound because the quality of the microphones is also so-so

I actually used only 96 kbps as the camera mic was recording only 22050 Hz

What is this font i seem to know

It's LCD font used by those basic character LCD screens.

Motion-JPEG this is the fastest way to create video in general, which is why it was used in video surveillance in the 1990s because of its cheapness. now, of course, we can say that AVC is the fastest on its low-power ULTRAFAST-VERYFAST. my OLD processor has JPEG hardware Encoding and I used it when I experimented with rendering in SONY VEGAS 13 when a giant-sized video and AVC just encodes it extremely slowly, jpeg coped several times faster, then stitched hundreds of thousands of pictures into MJPEG via FFMPEG, attached a aac track, and sent it to YouTube. surprisingly, there was not even any desynchronization.

https://t.me/my_content/5514

Font used in HD44780

pf

Don't say insult

<:PeepoDiamondSword:805394101340078092>

I guess the reason was the camera already had JPEG codec so they used it for video as well.

I don't think JPEG XL can be fast enough to compete in speed with jpeg for creating hundreds of thousands of images in a video

the reason was still in the absence of alternative technologies or their complexity

Watched but didnt joined

I don't know czech

heh

2.0.0 - Applejack 3.0.0 - Braeburn 3.1.0 - Celestia 3.2.0 - DaringDo 3.3.0 - Electric-Sky 3.4.0 - Fluttershy (libaom version naming)

Minecraft indeed uses font based on HD44780.

(and GNU Unifont I think?)

It seems so.

too much difference

It's the same idea. There's not much you can do with 5x8 pixels.

in fact, the minecraft font now is a giant unicode database, with a bunch of characters for all European languages, for Asian languages, and a lot of things in it are funny, that's why it weighs so much

and the minecraft font exists only as a picture in minecraft game, but here are the instructions

in general, the font itself cannot be bought anywhere, and since minecraft > mojang > microsoft owns it all, it cannot be massively distributed

The unicode font in Minecraft actually seems to be based on https://unifoundry.com/unifont/

fjxl can do about 75 fps at 4K based on the numbers veluca posted with their CPU. I can't find and benchmarks of libjpeg-turbo on similar hardware though, though I imagine it will beat fjxl by a bit. It isn't really a direct comparison though, as fjxl is lossless.

interesting choice

except for me, its nearly all clips recorded with replay buffer from obs, usually with 2 monitors in the video, leading to 3840x1080, so I don't think I would ever record in a lower res for that

libjpeg-turbo doesn't do multithreaded encode afaik, and I don't think it does more than ~200 Mpx/s

🤔

almost everywhere on the Internet I can upload these videos as source quality, for YouTube I increased them by 2 times by spline, although it was possible to choose better algorithms, it was important that YouTube did not squeeze my amazing 640x480 into a block-pixel mess

experimentally pouring dozens of videos, I found out that 480x640 magnified by 2 times vertical 960x1280 is recognized by YouTube as "1080p"

I was looking into TIFF as some people still use it. TIFF offers multiple codecs, so I've tried them out. There are multiple codecs optimized for B&W images but those are all pretty much worthless. Some of them produced even bigger file than the uncompressed image. JPEG encapsulated in TIFF doesn't make much sense to me. From the supported lossless codecs, Deflate seems to be the best. Although TIFF doesn't seem to be using filtering like PNG does and the compression suffers from that.

TIFF only has West (Left) filtering, like jpeg DC

> WebP still only has one implementation (libwebp) as far as I know, and I don't know of any efforts to change that situation.

Jon said this in the Chromium issue, and I want to mention that image-rs does have its own webp decoder implementation (I'm very surprised about that)

unfortunately (for webp) though, that decoder doesn't do chroma yet and has caused lots of headaches for years (cf. https://github.com/image-rs/image/issues/1648)

Oh, interesting, I didn't know there was a WebP reimplementation there.

There's a webp decoder written in Go too: https://pkg.go.dev/golang.org/x/image/webp (with https://pkg.go.dev/golang.org/x/image/vp8 and https://pkg.go.dev/golang.org/x/image/vp8l )

wait, not just webp but also the entirety of vp8?

heh

how were these created though? independently from spec, or by taking libwebp source code and transpiling it to a different programming language?

ImageSharp has a WebP decoder/encoder written entirely in C#. https://github.com/SixLabors/ImageSharp

oh wow indeed

and even looks like they did it from spec

Looks like just the necessary bits for webp, but I only skimmed, I didn't read the whole thing.

The spec is referenced, but I don't know if it's a reimplementation from scratch or a manual conversion of the C code. It's far too clean to be an automatic transpile.

automatic transpiling is improbable for anything except emscripten-style stuff. But it makes a big difference if you start from the reference code (using the spec only in a secondary way, e.g. to help understand the reference code), or if you start from the spec and basically don't look at the reference code

Looking through the git history, I found an instance where the author filed a bug against the spec where it didn't match libwebp. So I'm thinking golang.org/x/image/webp et al was probably implemented from the spec rather than the code. https://bugs.chromium.org/p/webp/issues/detail?id=205

(at least for lossless)

important point though is that these implementations were done post-browser-adoptation, i think

certainly post chrome adoption

modern x264 wins vp9 at any settings up to 720p at the same encoder speeds 🍖

modern x264 wins vp9 and x265 and svt-av1 at any settings up to 720p at the same encoder speeds🍖 🍖 🍖

svt-av1 at a speed of 10-12 has so many problems, even on the qualities of CRF "1" there are gross errors with the movement of blocks, even on an ideal almost lossless picture there may simply be the grossest noticeable artefact of incorrect block movement that makes it completely useless to use SVT-av1 for coding **intermediate **ANYWHERE

VP9 has a giant problem with the movement of blocks, I would say this is the problem of Lack of movement information, that is, the encoder spends a lot of bytes on information inside the blocks, the image itself, and there are extremely few bytes for the correct movement and motion vectors, I even I don't know how it could be fixed

x265 is just a shame, even in comparison placebo x264 placebo x265 turns out worse. how so. and at the same time much slower.

all this concerns the size of the frame 540p 480p 360p 240p 144p

AOMENC starts coding better at speeds of 4-6 while being hundreds of times slower

for fullHD quality/speed content, it is better to use SVT-AV1 at speed 6 than AOMENC at speed 8

Aomenc above speed 6 is... ew anyways <:KekDog:884736660376535040> ~~personally I don't want to go lower than 4 and prefer to stay at 2 or 3 which is slow af XD~~

288x144 the same FILE size the same encoding time the last frame before the new key aomenc speed 5 hevc slow avc placebo+

sigh, so much oversmoothing in both av1 and hevc (but more in hevc)

I think video codec devs have been way too focused on appeal (avoiding visible compression artifacts) and on bad objective metrics like PSNR (which is very tolerant for smoothing)

Yeah, it's a giant problem. but the worst thing is that a large number of old and fast technologies in AVC work better than a few Power and New ones in AV1 and HEVC, vp9 is built on this - several large free technologies, but in the end it looks disgusting than a seemingly overloaded AVC

it's quite similar to how a good jpeg encoder (mozjpeg) can be quite competitive with some way more modern formats (webp,avif)

webp is much more complicated than jpeg if we compare it, it seems like XVID and AVC - webp can be faster than JPEG, while it is better to compress

I am now checking the webp At maximum speed and mozjpeg at the same

How old is AVC? Would AV2 or 3 be able to take its best bits?

after squeezing 1000 photos, I found out that the fastest webP is 1.7 times slower than the "slow" jpeg, the quality is mostly better with WEBP, but for example, everything is not so clear in this picture, there is no question in the photos Jpeg q30 Webp q30

AVC? maybe AV1?

AVC = h264 is from 2004

I have no confidence that AV2 will be released in the next 10 years at all. There are many problems with the fact that progress stops, it is as inevitable as the fact that for the production of processors the most advantageous limit of nanometers was 28(after all, the most profitable thing in terms of speed and price that you can buy now are the very Xeon 28 nanometers that are already 7+ years old), when the price of the board was the cheapest in production, since then processors are more expensive and require more cooling, everything is so bad that buying a powerful laptop will turn off 3 of 4 cores so that it would work at least a day and not burn out at the same time. oh, how difficult everything is now. the problem with AV1 is simply terrifying, at speeds when it is effective in compression Power, it is **hundreds **of times not effective in speed. and this is already now and already at the parameters FAR from the maximum

as it was 4 years ago, so it remains now, the real power of av1 remains only in the hands of those 50+ corporations that made it, who have enough power and who give their content to millions of people at once, like Netflix and YouTube

I made an agreement with a friend and took his Ryzan with 16 cores to compress AV1 several movies and anime, a whole week of work, is really good, wonderful quality and file size, but the speed of work is so expensive that I don't even know if it made sense, the same power could be compressed 100 times more video watches that would weigh 50% more but same quality...

I don't even know what to do with this content now

Given that, there shouldn't be any patent issue with nabbing the best bits of AVC for AV2 then.

Which will be nice, though I don't know if the underlying models are compatible in a way where that would be useful.

you confuse

I think AV1 probably already includes the best bits of AVC — it was published in 2004 but any patents related to it would be older, most probably old enough to already have been expired (or close enough to being expired) when AV1 was created

this is completely wrong, even HEVC does not include many parts from AVC

Ah, good to know.

this is the problem, the codecs are thoroughly not old, and they take only the most powerful and Expensive new tools, it is obvious that all codecs have DCT as a base, but for example some prediction of 4 by 4 pixels and an analysis that gave 1-2% efficiency - new codec just did not Have it, we hope that another BIG tool will be better

for a very long time it was not clear to me personally why everything is like this??? now that they have made an MPEG-5 EVC codec that, according to the idea, uses all the free Old technologies and is a competitor to HEVC, but even so AVC is still faster and better at its speeds

but it annoys me that NO ONE supports it, it's a free codec with open documentation, but I can't even play it anywhere

2 years

https://github.com/mpeg5/xeve

I am talking about bitstream coding tools, not about clever encoder implementation stuff.

I would say it's **literally **AVC FOR FULL HD

Wait, what's the difference?

for example, there are the same tools that the AOMENC SVT-AV1 RAV1E codecs use in different ways

AVC has a lot of patent encoders, but as you know, the most powerful and free at this time is x264

do you know what annoys me? here principle of building codes now. How was it before? Took the technology, and over time they improved it, made it faster and more efficient, squeezing the maximum out of the algorithms, the same JPEG as an example. And now, being taken extremely powerful, excessive technology, and it is being **cut**, they are trying to **cut **it so much that it could at least be used, it seems to me that it is because of this approach that there are a lot of problems with the performance of codecs right now

av1 is a good codec, but you need a supercomputer to unleash it real abilities, because that's exactly the level of technology in it

I don't know much about video codecs, but e.g. in image codecs: DCT and coefficient quantization are bitstream-level coding tools, but how an encoder makes use of it (just naively, doing deadzone quantization, trellis quantization, etc) is something else.

E.g. mozjpeg is doing some fancy encoder tricks that could also be applied in libjxl but are currently not used (yet)

so basically there's 1) the bitstream expressivity and 2) the clever heuristics and tricks encoders use to perform good compression (perceptually optimized etc)

1) is something that tends to only improve, but 2) is something that tends to get reset to zero in each new codec generation

it would be nice to have a lot of algorithms that Bruteforce on which one would be better to compress each individual block or fragment

better wrt what metric?

I would like to understand what "better" means

also: full bruteforce is computationally not feasible anymore for the modern codecs, the combinatorial explosion is too much

when you compare images, you immediately see errors that it would be better not to see, AVI is very good at destroying Noticeable artifacts, what metrics does it use? standard PNSR? I don't think so

that's right, it's enough to see once how long JPEG guetzli has been running

Why are so many programs so dumb so they enforce alpha channel in PNG even if it's not actually used?

I've seen that so many times. 🤦‍♂️ And that's where optimization comes in. 😀

Indeed, I always optimize PNGs I've got.

Apple's built-in screenshot thing does that iirc. It's very silly since screenshots are always opaque.

The same thing in Windows.

it has an ability to capture a single window in which case borders are generally transparent. but I agree that when you don't have a single transparent pixel it's silly to signal alpha channels.

ah right well at least they could do something different for screenshots of (crops) of the screen than for screenshots of windows

There's also option to use tRNS chunk for single color transparency kinda like in GIF.

It's actually possible to use the "rectangle selection" screenshot mode in macOS and end up with an image with transparent pixels (because of bugs of course), it basically just dumps the buffer from the compositor and whatever alpha values it has survive as-is

tRNS can do neat tricks in paletted images, it practically expands palette entries from RGB to RGBA.

in cWEBP.exe, which I took to consider for the first time, I discovered a new experimental function -af (auto-adjust filter strength), which uses new algorithm for creating the filter deblocks, and it works better than a regular filter, but it is slow, during the time it processes the image, it was possible to encode 3 more of the same webp pic. It's good that the format has not been abandoned and is still kept up to date because of things like this

**As of November 2021, web browsers that support WebP had 96% market share.**

Is the webp bug in safari fixed already?

I can't understand why there is not a single image in the entire AV1 documentation to understand how and what works

but in AVC **patents **there are hundreds of detailed images and principles of operation

bug?

just to clarify for those who are not aware (since it could be a source of confusion), AVC = H.264

the name “AVC” is to H.264 as “HEVC” is to H.265

(and “VVC” to H.266)

a small fraction of webp images just don't display at all in safari due to some weird bug

patent clerks like to see diagrams, while spec editors usually prefer to avoid them

okay. I've never seen a safari in my life <:Windows:806135372298977342>

what a problem. here comes a new young mind, and instead of understanding how everything works by watching an AV1 DOC or at least VP9 - he will have to descend to the potents of 2003, where there are these beautiful and understandable pictures

https://bugs.webkit.org/show_bug.cgi?id=219977 — looks like they fixed it, so I guess WebP can _really_ be used on iOS/Safari when everyone has upgraded (which should be quite soon, iOS doesn't have a long tail of old versions staying around like Android has)

it helps that they are still providing software updates for 7-year-old devices

it probably also helps that their typical demographic mostly include people who don't keep devices around for 7 years 🙂

fair

the windows built-in snipping tool can do this

One of our family iPhones got iOS 16.0 My first impression was that AVIF doesn't work at all but finally I was able to create one AVIF which worked in Safari. There is a huge potential of improvements, Apple's implementation appears very limited.

any idea what the limitations are?

still only, I assume? Does alpha work? Is it 4:2:0 only or also 4:4:4?

does it support HDR stills? (e.g. https://spider-mar.io/hdr/salon.avif)

oh, I can update my own phone to iOS 16

Alpha works, YUV444 works. 8bit and 10bit AVIF works. testfile in 12bit didn't work for me, AVIF with limited range didn't work. Animation didn't work. RGB AVIF (not YUV) is rendered incorrectly.

Didn't they used the implementation from Microsoft?

While one bug is common with M$, they have also different bugs. So I think it is not the same implementation.

I have noticed an increase in the number of people starring my Photoshop AVIF plugin on GitHub in the last 48 hours. I have no idea what is causing this increase in attention. I doubt that it could be Apple's AVIF support, as the plugin is currently only available for Windows.

salon.avif have somehow hallucinogenic look in my Safari.

Nope. They're using dav1d internally.

If they're willing to, they can let all features go loose.

oof, I see what you mean

Post also Chome (on Win or Linux) so people see the difference.

salon.avif has banding like artifacts at dark areas on chrome android.

Chrome on Linux, SDR display

might have slightly messed up the conversion of the screenshot to sRGB as it looks a bit more saturated than the AVIF

but you get the general idea

the safari version looks funky

what is that? discarded msb or something?

I’m going to update my MacBook and try on desktop Safari

Looks like Alien vs Predator game

The ones from Rebellion (on Atari Jaguar and, esp., first one on the PC) were excellent. Sorry for off-topic, but I just **had** to.

https://xeiaso.net/blog/avif-help-requested heh

I've tried 3 different AVIF encoders (ImageMagick, GIMP and go-avif), and none of them can do lossless encoding

I thought I was using them wrong, but go-avif has a specific `--lossless` flag that still produces colour fringing (And a larger output file than the input)

What OS Are you using? If you are on Windows, Paint.NET has lossless AVIF support.

I'll give that a try

Yep, that's worked, nice

Easy to tell, the colours are all wrong

unless you're testing or something, i wouldn't bother with lossless avif

Yeah it's purely for testing, and it basically agreed with everything I'd read about it

GIMP 2.10.x do not save lossless AVIF, GIMP 2.99.x is able. MS and Apple handle RGB AVIF incorrectly, that's why the wrong colors. But those bugs are trivial to fix so maybe they will fix it in future. The efficiency of AVIF lossless compression depends on AV1 encoders. I believe it could be improved but I think encoder developers have lot of priorities with higher importance than still lossless now.

Did YCoCg end up in AVIF or do you need to do RGB without reversible color transform?

I think avif lossless might not have that much margin for improvement, entropy coding is probably too weak and it doesn't really have very useful coding tools for lossless as far as I can tell.

still working on ycocg IIRC

Can they even still add it at this point without introducing a major interop problem?

AFAIU they'd add it to cicp

which is interesting

no idea about how interop would look like though

my guess is it would work in chrome and nowhere else for quite a while

well, it would work when something updates libavif

`s/when/if/`

https://xiph.org/flac/2022/09/09/flac-1-4-0-released.html

I wrote a giant post about video codecs here https://encode.su/threads/3953-Video-Codecs-user-experience?p=76263#post76263

interesting read

I've noticed that services like Facebook or Telegram automatically convert GIF to AVC.

https://matthias-buehlmann.medium.com/stable-diffusion-based-image-compresssion-6f1f0a399202 of course.

> It’s interesting however how the artifacts introduced by this compression scheme are affecting the image content more so than the image quality, and it’s important to keep in mind that images compressed in such a way may contain these kinds of compression artifacts.

As expected. This is the most scary part of this kind of technology: appeal without fidelity, combined with black box nonlinear behavior, means it's basically guided hallucination and not image preservation.

Such interesting image artifacts though, like faces dissolving

> It’s just that the kind of artifacts introduced are a lot less notable, since they affect image content more than image quality — which however is also a bit of a danger of this method: One must not be fooled by the quality of the reconstructed features — the content may be affected by compression artifacts, even if it looks very clear.

Very interesting, but no way this kind of technology should ever be allowed in applications where fidelity is critical, such as evidence in court or for insurance companies, medical, journalism, etc.

yuck

What about AI upscalers? Kinda similar thing, creating detail from nothing.

and this is fine, but I note that telegrams not generate YUV444 and compresses very much. But it also gives me complete freedom, I can make pixel or high-quality animation in High profile and its quality OR full video 1280x720 60 fps with baseline prosile and fastdecode tune (for maximum play optimized) it should be understood that gifs-video consume calculations, and you Can Not just take and put any video in a gif, the optimal for everything will be 640x360. but if you understand the topic, you can create an optimized AVC and make a larger frame size

better compression artifacts than what is not in the original

AND OF COURSE no AVIF tests

was the post made 4 years ago? no, today, therefore, the author deliberately keeps silent that AVIF will probably be even better in something<:Thonk:805904896879493180>

6KB AVIF (via Paint.NET)

bad compress

I actually was disappointed with the entire result. the fidelity issue is technically fixable with patching critical positions, but the compression is not strong enough to support that. ~~the post only makes use of the VAE component of SD so maybe there can be stronger systems possible in the future though.~~ (someone in HN later noted that this is not the case and it does make use of U-Net-based denoising as well)

From a bitstream-design point of view, fixing fidelity with patching is indeed a possibility. From an encoder design point of view, I think it is hard to detect where patches are needed for fidelity and where pixel-level differences are 'innocent' — in the end that is mostly a semantical question: if the codec turns some grass into different but similar looking grass, it's probably fine, while if it changes a face it's probably not fine. Fixing everything that is different at the pixel level will probably require patching nearly everything, but selecting what to patch and what to keep as is will be quite tricky. Of course relying on AI to decide where to fix fidelity and where not to just moves the problem 🙂

with a strong enough system, I can indeed see that this can be useful for specific use cases, for example when you wear HMD everything not in focus can be "faked", not really requiring full fidelity. but this system is not strong enough for that.

Who uses GIF to encode video, is apparently not interested in quality anyway. Encoding to lossy codec is effective way to deal with those large blobs of several megabytes in size. I've seen GIFs using random noise as dithering. I get it, random noise looks more appealing to eye. Floyd-Steinberg dithering looks kinda funny in motion. However, random noise is very hard to compress. Another lossy compression will look bad, but it's smaller file. Problem solved.

RTX 40 for content creators (AV1): https://www.nvidia.com/en-us/geforce/news/rtx-40-series-and-studio-updates-for-content-creation/

does anyone know how i can encode with exhale's aac? the app requires a .wav source file, but i was wondering if either .flac was usable elsewhere or there was a good method to transcode to .wav before encoding

freac only has fdk-aac but i wanna try xhe

You could use foobar2000 to do the conversion. That's what I do, anyhow.

<@284160100510466048> another question, though - what works best for conversion? should i downsample before encoding? i have to at least transcode 24/192 files to 24/96 before encoding, but i wanted to know if there was any difference in transcoding to 24/44.1 instead

Wouldn't be better to resample to the native resolution of your DAC to prevent additional resampling during playback? All DACs are capable of at least 48kHz these days.

i'm talking from a purely digital standpoint here, like i only use headphones, no fancy hardware or anything

i just play from foobar2000 now so just wanna know what's best

I would go with 48 kHz because it's a nice round number. 44,1 kHZ was chosen for audio CD as a compromise, later standards are using 48 kHz minimum.

alright

<@688076786525143117> talking about xHE-AAC in particular here though, are you familiar at all with AAC codecs?

just to ask

Kinda. AAC HE is intended for low bitrates AFAIK. That's not that interesting for me, I prefer higher quality encoding.

i'm trying to find a good middle ground between a decent-sounding desktop library and a general mobile library

found xHE-AAC 96kbps SBR to be the best fit so at this point i'm just trying to learn more about the process

96 kbps is not that low, even MP3 can sound passable if decent encoder is used. I would consider opus as well. It performs pretty well at low bitrates.

i'm actually switching off of opus

opus was my go-to for a long time

Just use Opus.

[2]

At the 96-160kbps level, Opus through libopus generally wins because of higher fidelity targets.

it's personal preference really, i did an ABX and found xHE-AAC generally performed better for me

there's no real net loss since i already losslessly archive the source folders

it's just experimentation

My only experience with AAC is that I'm using AAC LC alongside AVC video, 128kbps for mono and 192kbps for stereo, so that's it.

for video i think AV1 / .opus is just the standard so that's how i adjusted

opus being free and all

I didn't have a motivation to replace AVC as I'm working mostly with 1080p content, so I'm sticking to it. AVC has excellent hardware compatibility.

I was using MP3 alongside AVC as well. After the release of stable AAC encoder in ffmpeg, I just switched the audio codec and kept the bitrate. There's not much difference in the high end. AAC can use even higher bitrate than MP3 but that's presumably intended for hi-res/multichannel audio.

The higher sample rate in FLAC could be actually handy. I can imagine FLAC could be used to encode any one-dimensional data like signals recorded using oscilloscope etc.

just use bopus

there's no such thing as a purely digital standpoint

all auto output devices have a DAC, since a DAC is required to convert digital to analog audio

for most people most of the time the DAC will be built into the motherboard's sound card. but it still exists

oh

whoops

and most of those are going to be at 48 kHz, which is why that's ideal for lossy

to prevent resampling on playback

calling it "cd quality" vs "dvd quality" is misleading because DVD audio is usually compressed with mp2 or ac3

and CD audio is uncompressed PCM

yeah i get the idea

well i mean at the same time i do frequently see DVD-A releases with 16/48 audio

or even DVD-V sometimes

in either case, for purely playback purposes, you don't want 96 kHz, that's at best identical to 48 kHz and at worst it can mess with the DAC

i can't really show spek input since it doesn't support AAC but i'm assuming it's empty above a certain point

.opus automatically set the sample rate to 48kHz but in this case it just keeps the source's sample rate

so i'm guessing i should be downsampling from 24/96 to 24/48 then to xHE-AAC based on that assertion

in the case of 24/96+ files

most lossy formats have a hard low-pass at 20 kHz

so there's actually no point in higher sample rates

yeah i know opus did

don't forget the nyquist-shannon sampling theorem, which says that a sampling rate of 2N is enough to perfectly reconstruct a signal within the 0-N band

i 100% agree but i've always kept lossless files intact just for the sake of archival

a bit of extra working sample rate is better though because there's another rider which says that the resampling function can have compact support and will decay rapidly with a bit of extra room

but 48 kHz is plenty of extra room

for archival/storage whatever, preserve the recorded original

so would this be the way to go?

I don't believe you'll be able to hear the difference between 16 and 24-bit samples

especially without specialized hardware

I'd probably do 16/48 if you're compressing lossily

yeah i fell for the 24/44.1 placebo early on

i was like

whoa better bass!

you can try abx testing but I doubt that you'll score more than 50%

but then i checked out the 16/44.1 version of the track way later on

same dynamics

so i was like... fuck

i don't have a sound method for downsampling to a specific rate, what do you recommend?

isn't 48 kHz one of the options provided

if you're looking for software, SoX has a good algorithm for it

https://sox.sourceforge.net/

?

yes that

alright

last updated in 2015

ouch

yea it's not a super up to date project

i've got it up and running, looks pretty complicated though

<@853026420792360980> okay i'm like completely lost could you guide me through this lmao

like say i wanna convert a whole folder at a time

i don't know if `-b` would be 16 in this case since 16/48 and all

pretty sure `-r` would be 48000

`sox input.flac -b 16 output.flac rate 48k`

so i can only do individual files?

yea, but you can always use find and parallel to parallelize it

i'm not following sorry

based on what i saw online, do you mean something like this?```for i in flac/*.flac; do sox input.flac -b 16 output.flac rate 48k "$i" "$i_modified" done```

`input.flac` and `output.flac` is a placeholder for file names

yeah i'm trying to figure out as i go

i hate CLI apps with lots of parameters for this reason lmao

how about this then?```for i in flac/*.flac; do sox -b 16 rate 48k "$i" "$i_modified" done```

mind was trying to fill in the blanks and i didn't think to omit the placeholders

```i was unexpected at this time.``` well now i'm completely lost

input.flac and output.flac are the actual names of the files

you need to use them, don't put those names there literally

like i said this tool is brand new to me so i have no idea what'll work

if doing a whole folder isn't straightforward i'll find something else

it is straightforward

you're just not reading the syntax we already described

yeah but this means i'd have to do them individually right?

.... no

what

i don't have a combined .flac or anything i just have a tracklist

and you said "you can always use find and parallel to parallelize it" which i have no clue what that means

```sh for i in input/*.flac; do sox "$i" -b 16 "output/$(basename "$i")" rate 48k done ```

for example

huh, alright

alternatively ``` find input/ -name '*.flac' | parallel sox {} -b 16 output/{/} rate 48k ```

or something like that

i just realized i ran this in command prompt and not bash

amazing

that's entirely on me then i made it way harder than it was supposed to oops

if compressing lossily, it makes sense to keep the source 24-bit if it originally was, otherwise you just end up compressing some additional dither noise

compressing pianoteq output with fdk-aac and `-vbr 5`, I got slightly smaller files starting from the 24-bit output than from the 16-bit quantized version

perhaps even if it wasn’t, if you’re resampling

resampling and keeping 24 bits from the resampled signal shouldn’t be worse than resampling and then dithering again to 16 bits

(probably not that much better either, in all fairness)

<@853026420792360980> tysm for the help btw 🙏

got what i was trying to do working

not all lossy codecs work internally in high precision

for opus this would be true, but brooke's using HE-AAC which doesn't

it wouldn't be worse, but it would take up a lot more space

in practice this happens even if in theory encoders shouldn't do that

aren’t we talking temporary files here?

or am I misunderstanding?

ironically both ideal codecs (audio and cover image) don't work on my main music player while they do on foobar even though i hate foobar

now that i've been experimenting with xHE-AAC for audio and JXL for covers

but i mean the results are there after having followed everyone's advice

this is pretty fucking good for 8.6MB

not playing through Discord either, it seems

yeah discord doesn't support m4a in general i think

it does with standard AAC

oh?

let me try an example

well it has the player controls it'd show on an .mp3 / .flac

on codecs like .opus it just doesn't show anything

it might just be the specific encoder i think

probably the case

Speaking of dithering in lowering the bit depth of audio, is it actually beneficial? When i was converting some sounds for an old game to 8bit PCM, the dithering was very intrusive, a conversion without nay dithering sounded much better.

I would say yes

I think I would take broadband noise over distortion

To be fair, the game uses sounds in 22050Hz and 11025Hz, so everything was in the audible range.

At the end, in such cases, the distortion is more tolerable than dithering.

for what it’s worth, I used to use spek, but then switched to Sonic Visualiser to have a logarithmic frequency axis

i use spek because it looks cool

https://tenor.com/view/gus-fring-gus-fring-chicken-man-breaking-bad-gif-24625386

We are not the same.

Sonic Visualiser can also play the audio, which is nice to have as the playback line goes through the spectrogram

~~just use ffplay~~

after a grand total of 1 day using foobar2000 i've now switched to using a m-ab-s build

👏 👏 👏

(also not logarithmic IIRC, and you don’t get to see the spectrogram in advance)

(that's why it was a joke)