JPEG XL

Anyone know about the QOI codec?

qoi, actually not that bad for image sequences decent perf is nice

it's pleasant to implement

i think on big modern CPUs it's generally worse than cjxl e1 (slower and worse compression ratio), but it could be a good option on platforms like microcontrollers where code size is limited and you have no floating point/SIMD

i haven't tested how much ram cjxl lossless e1 needs but that would probably be an advantage for qoi as well

just use deflate (png)

isn't that slower than qoi? how much ram does it use?

super easy to implement and can do row-wise so tiny amount of ram

iirc the mandatory state that a qoi encoder must track as it processes the image is... 196 bytes?

and the systems will already have zlib

<:trollface:834012731710505011>

> QOI is fast. It losslessly compresses images to a similar size of PNG, while offering 20x-50x faster encoding and 3x-4x faster decoding.

we already had this conversation

https://discord.com/channels/794206087879852103/805176455658733570/966934603044646952

lol i forgot about that

what's "density"? lower/farther right is better?

up and right is better

i know that i just don't understand the x axis unit

higher and right is better

QOI is missing important features, but the simplicity makes it easy to implement your own encoder/decoder from scratch. It seems to be incredibly difficult to even merely write a decoder for JXL because of how complicated it is. But it beats QOI by a huge margin in speed and efficiency at the same time, as well as features

There is a huge amount of potential in the creativity of jpegxl encoders in the future... Assuming people in the future can implement their own encoder, or not be intimidated by signing a Google CLA and getting down and dirty with C++.

I feel like C is far more welcoming to read someone else's code in.

whats wrong with c++

if you dont like some extra features just dont use them

i for one appreciate smart pointers and most of the stl

That advice doesn't help when you're reading someone else's code and wanting to comprehend it quickly without wasting time thinking about how the language works

but you dont have to think

I find you have to think harder with c when there's manual memory crap

i mean, it's called c++ not d

the languages don't work differently outside of syntactic sugar

Takes a couple of days to learn C but a couple lifetimes for C++ because it seems they have a juvenile tendency to add every single feature they can think of on top of the C language for compatibility reasons, like they are compulsively ticking features off a checklist before actually thinking about how it fits into the rest of the language or how to actually design a distinct language that's quick to read and comprehend.

<:autistThinking_WA:347470937727172626>

I did a custom ssimulacra

But I don't know how to compile

Microsoft azure they compile in a hour a day

I'm not a dev

And the compile process for a recent vspck build looks difficult

Like very lot

I can read ssimulacra2 readme

The software is small

But I don't know anything

I have a ssimulacrac file and i want to use a compiler

Compiling should be easy. If a project is difficult to compile then it usually means something is wrong with the project.

A lot of so called build systems are complete soydev

Do you know how to change ssimulacra c in ssimulacra2 source and build the exe

I haven't read the project source for that

Shouldn it encode for JPEG XL

Ah you use powershell and you don't like input exe

Only thing worse than soydev software is "enterprise" software

I don't do for ffmpeg

Or for qoa

I just type ffmpeg or qoa

I can't help rn fab. Maybe later if you send me a link to where you got the original sources to compile

I'll teach you how to compile

If I have time later

c is like english. fab is speaking english++ but it doesnt mean it's easier or harder for us to understand it.

C was designed. It was designed to be very quick to learn. The textbook to learn it is extremely thin, and it is the best computer science textbook ever written (the k&r book).

C++ was not designed at all, to be anything, except to add every feature you can think of and duct tape it to C grotesquely

Thoughtlessly

It's a juvenile mentality

it's a language and like english, it evolves over time

And it's very enterprise-ready because the investors love the check boxes and buzzwords like "object oriented"

it's designed by and for humans who also change and adapt over time

I don't claim to like the language as a whole but I can appreciate the efforts made by humans and all you have done is badmouth them

So is fake maple syrup. Doesn't mean it's any good...

that's subjective

like anything "fake", it has its purpose

I'm canadian and I have no issue with fake maple syrup

I think it is a little offensive that people are trying to get other people to put literal fake food into their mouths to save a few dollars

it's more offensive to deny the luxury to those who can't afford it

if you really want to get into the politics of it we can

At a certain point, certainly there is a line that would be crossed where it is simply in bad taste and offensive to try to convince people to eat garbage to save money

no

i mean

wow you just solved poverty, obesity, and world hunger

If you want to take it to an extreme, you could offer to poop directly into someone's mouth since it will be cheaper than buying real food

and some people do

But most people will, and should, be insulted by that offer

I think it crosses the line sooner than that though

obviously eating shit is more obviously harmful

I get slightly insulted, when I am dining out, and I ask for butter and get brought margarine to my table instead... Especially when it's an expensive place.

ok margarine is different

Why try to make me eat fake garbage? It's unkind to me.

do you have any idea

what margarine is

it's not fake butter

And not just me either. It's just unkind

it has its uses in cooking

Well, a packet called "vegetable spread"

And no it really has no use in cooking at all

Last time I tried to cook with it, it smelled horrible as soon as it softened and melted

It doesn't work like cooking oil does

???

https://tenor.com/view/im-not-surprised-surprise-o-meter-surprise-measure-meter-gif-16407723

And the ingredients are usually horrid, like hydrogenated rape oil and other things that your body can't even deal with.

i gotta say this message caught me off guard while reading the c/c++ debate

i don't remember if xpsnr has been tested since then, or is it not really worth it? <https://github.com/fraunhoferhhi/xpsnr> at least how much better or worse than vmaf, being a less ml metric also recent jpegli comparisons would be interesting to see, since development is not very active or finished at the moment (though I still can't get a dll for a quick libjpeg replacement) or is there no free time for such tests right now?

http://www.ecodis.de/xpsnr.htm

I've done a good amount of testing with XPSNR, and I think it is strong for video because of how fast it is, but it isn't really very useful for still images unless you're comparing across the same codec

Aggressive PSNR tunes will make XPSNR think your encode is better than it actually is in my experience, but other than that it is great as a secondary benchmark along something like SSIMULACRA2. AFAIK if it has any problematic shortcomings (like VMAF currently does) they haven't been discovered & widely exploited yet, besides maybe tuning heavily for PSNR which clearly hurts visual fidelity but XPSNR won't think so

TIL about lossless JPEG editing <https://www.betterjpeg.com/download.htm>

seems legit, I guess?

is there a better way to tell for sure or did I get pranked?

Intriguing...

technically sound, but there are lots of caveats

so the idea must be to manipulate images as a set of already quantized JPEG blocks. the website doesn't exactly say this, only says that it doesn't touch unaltered pixels, but then retouching doesn't make much sense, so there would have to be something more

> BetterJPEG allows for brightness and color correction of JPEG images without recompression, avoiding loss of quality. The lossless brightness and color correction is done by adjusting so-called zero-frequency (DC) coefficients in a corresponding color component.

oh yeah, that should be it

lossless resizing and cropping is already well known, jpegtran did it for decades

https://blogs.loc.gov/thesignal/2023/12/embracing-ffv1-matroska-container-preferred/

Hmmmm armv7 ffmpeg 6.1 has a problem with the dav1e decoder for av1😮‍💨

I wonder how rav1d does

but I don't have it... actually I'm looking at the list of items. it looks like I can't decode av1 at all lol

weird

I wanted to compare the decoding speeds of av1 with and without cdef. and also with the number of keyframes. in fact, I have such a problem that I got my hands on a redMI 9a device, and it decodes av1 Hardware worse than on the processor! It's lagging! HW on scenes with a lot of movement, it just decodes 5 frames at sec, but on CPU all is fine, what the

720p 24 fps av1

Is that what you were trying to decode? Or the stable performance it achieved?

My friend wrote me a message: A convenient service for visualizing commands in ffmpeg, with clear descriptions. There are also presets that cover 90% of the ffmpeg experience. https://alfg.dev/ffmpeg-commander/ And I wrote to him: Where is the x264 setting of the aq parameter fucking this is one of the most important parameters that saves the codec in 2023 and it is not there 90% of the programs that make ffmpeg gui do the same shit, what the fuck is the news?

then I went to the first glance search results for information about the x264 keys This guy didn't test anything at all https://silentaperture.gitlab.io/mdbook-guide/encoding/x264.html

It's just bullshit, where it from Psy and deadzone-intra/inter are responsible for the noise Ahaha, how can he even know about this if he just doesn't have a fucking written about the last parameter 👏 ||And so I studied on these fucking guides 3 years ago||

man r/av1 sucks ass

> this is a different approach to the weekly posts with a similar question. Ah, a true connoisseur of questions, going with the monthly delicacy

can r/av1 not be put in this channel

or even in this server

there has not been a single useful/meaningful post

Av2 is going to be out

well the iamf post is nice for audio nerds, iamf is some pretty dope stuff

Untrue. When I post, it's somewhat useful.

To be fair though, when I post something good, people notice.

I mainly mean the bot that posts everything from r/av1

I don't mind if an individual shares a post to discuss it or whatnot

2 -pass vp9 realtime speed 8 - breaks the frame in a random place with noticeable frequency. the broken codec.

I found that exporting (x264 FFmpeg 6.0) to mkv on the second pass completely breaks the frame chain, making a shift of 2 frames, everything that was received on 1 pass (that is, in the original file, the key-frame positions are shifted by 2 frames relative to the actual frame change) pass1 ```[out#0/mp4 @ 000001d07fa2b440] video:1605kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.494954% **frame= 602** fps= 80 q=-1.0 Lsize= 1613kB time=00:00:10.00 bitrate=1321.2kbits/s dup=2 drop=0 speed=1.33x``` pass 2 ```[libx264 @ 000001dea52c7480] specified frame type is not compatible with max B-framesed=1.24x [libx264 @ 000001dea52c7480] slice=P but 2pass stats say B [out#0/matroska @ 000001dea4a92e80] video:1726kB audio:172kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.441943% **frame= 600 **fps= 75 q=-1.0 Lsize= 1907kB time=00:00:10.00 bitrate=1562.0kbits/s speed=1.25x```

when using mp4, everything works good.

Since I'm doing Twitch Stream encoding, in which a variable number of frames* is possible*, I understand why the value dup=2 is written - because it seems to be correct. But why it depends on the container mp4/mkv is not entirely clear to me.

https://hydrogenaud.io/index.php/topic,125248.msg103720 `HALAC, like the HALIC, focuses on a reasonable compression ratio and high processing speed`

I'm too lazy to do my own tests, but it usually kills any codec and project: ```flac.exe -peml 12 -r 8 -A subdivide_tukey(5) IN.wav```

it's more speed codec than for maximum possible compression

Although the speed looks tempting, it reminds me of the project of wavelet-based image codec, which will never be popular, because speed is not as important as quality nowadays. To be honest, among the codecs that take exclusively speed, I know only 3 examples, AVC for video, Vorbis for sound in game, and webp as a replacement for jpg. But I don't see any reason why lossless audio storage might need the speed of its packaging. As far as I know from my experience, audio compression to the original flac is performed only once in the history of the sound itself. You don't need to work with him more than once. Using a speed-specific codec for lossless compression looks completely hopeless Its only hope is to be a significant percentage stronger to compress than flac... But it's not like that... It would be better if HALAC was encoded 100 times longer, producing better results than flac... but at the moment, when the codec is not superior to its competitor, No one will pay attention to his speed this is not the ZSTD way, this is not the Vorbis way, and even more so not the JXL way. When speed is not the main advantage, but only a very good addition to an already best codec

lol

wow! opusenc is genuis Using the built-in parameter **--set-ctl-int 4008=1104** gives better top quality than if you resampling to 24000 hz in advance apparently the codec uses information about the frequencies that are being cut off to make a block of frequencies for them

And also, I noticed this a long time ago, but I want to say in particular that libopus ffmpeg encoding always makes everything worse than opusenc, even though it should be identical in quality, it is far from the case

And yes, opusenc is much more careful to observe the set bitrate over a long period of time, while ffmpeg always gives a little lower than the set one (while the parameters of the stereo frequency distribution are directly linked to the digits of the bitrate set during encoding)

VVC dec in ffmpeg now

<:H266_VVC:805858038014672896>

logo not far from wc, is it a sign ?

Is there any windows/linux video player with vvc support?

https://github.com/MartinEesmaa/VVCEasy

https://fxtwitter.com/FFmpeg/status/1742599774203691222

ffvvcdec has no support for palette and intra-block coding yet, also slower than vvdec but it is good that ffmpeg has a native decoder

> this is the most sophisticated decoder ever written in FFmpeg! An achievement and a concern, 1080p AV1 already stresses my CPU

Also why VVC? No GPUs for desktop support it yet even.

hehe vvc

can't wait for the shenanigans relating to it being distributed in gpl binaries

mp3 320 opus 320 aac 320 When inverting a track with the original

this basically means Opus has worse PSNR

well, almost

How you got Nino D'Angelo flaca alaC

I want that website

Which Browser to use: Guide https://chat.openai.com/share/f7ffb38e-0590-4e96-8e1a-e2ae69efb2da

<@1048625218190585988> emma development stopped in 2019, the main author Marcio Pais also contributed to paq8px, both are general purpose compressors optimised for some image formats, but this discord is not about the smallest lossless encoder, but about jxl, which is a best take on image compression, with some compromise

What's paq8px? Is it better than EMMA? Where can I find it?

Well, I made 1 MB PNG files with VirtualDub2, but it's INCREDIBLY slow. Is there a faster way to make them?

Try using an easier format like BMP or if possible set png compression to low.

vp9 2-pass is real rofl. random frames randomly lose the unblocking filters in the middle of the scene. incomprehensible quality jumps down in the middle of a static scene. 2pass avc looks better than 2pass vp9

as I understand it, av1 has the same problems. although I just don't have time to do aomenc 2 pass tests when parallelizing into 3 damn Threads. it is much better to use hevc for 2pass. or even faster, avc

https://evanhahn.com/worlds-smallest-png/

Reminds me of this: https://cloudinary.com/blog/one_pixel_is_worth_three_thousand_words

how big was the smallest jxl again?

The smallest valid jxl file is 12 bytes iirc, but it's not 1 pixel. Not sure what's the smallest 1 pixel jixel file, maybe 14 bytes or so.

512x256 The base64 encoding is the filename

https://embed.moe/https://cdn.discordapp.com/attachments/805176455658733570/1202692404457504789/wrBwiDBAwASyAY.jxl?ex=65ce6196&is=65bbec96&hm=bcf90527b9b84e386cb9e1236901a39caff92d3847f0ba15fe7f3e439f490fc4&

So 1 million times more black pixels per byte than PNG ;P

Well jxl can do multiple-of-8 dimensions a bit more concisely, and 512x256 is the largest dimension it can do in a short header 🙂

1x1 would need more bytes than 8x8 or 512x256

Considering the header size for a packet is larger than that file, you can't get a whole lot smaller overall

According to [the JPEG XL overview presentation](https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit#slide=id.gde87dfbe27_0_43) you can get a white pixel in 17 bytes, and a transparent one in 19.

Ah nice, thanks for reminding me of that table 🙂

From trying to manually encode an image, I think it might be possible you can shave another byte off. I'll have to actually construct that to see if I've missed anything though.

URL: `data:image/jxl;base64,/wr/BwiDBAwASyAY` the slashes get lost in the filename lol

much better than the PNG `data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABAQAAAAA3bvkkAAAACklEQVR4AWNgAAAAAgABc3UBGAAAAABJRU5ErkJggg==`

The slashes and the colons got removed, so I thought I'd just make it the bare string rather than `dataimgagejxlbase64` Although now I see what you mean too

WebKit has officially removed support for JPEG2000: https://commits.webkit.org/273978@main

Sad for J2K, though I guess it will still work in Safari, right?

I doubt.

J2K was never designed as a web format so it's odd they added support. But they at least gave it a good long run and now see that it is not going to pick up any steam.

So far it appears to be supported up to 17.4 - but that commit was made yesterday so Apple likely already solidified the version of WebKit they are using in that version of Safari. The commit only affects Nightly at the moment. As far as I can tell, Safari doesn't use a proprietary backend for handling media like Windows/Edge does. Once the commit lands in a future WebKit version and Safari comes out with a new major version supporting the newer WebKit version, I expect support in that version to turn red: https://caniuse.com/jpeg2000

when we asked about jpeg xl in webkit, they said: > The most important point you need to know is that Safari doesn't use WebKit's image decoders at all, so if you want JPEG XL to work in Safari, contributing JPEG XL support to WebKit is not likely going to achieve your goal.

> This is pretty much accurate as far as the Apple port is concerned; image format support depends on OS library support, rather than anything in WebKit.

afaik only playstation and gnome web/epiphany use webkit for image support. some smaller things probably too

Interesting, so it is based on an OS-specific library. So it will really be up to Apple as to whether they continue to support J2K.

I see no real reason not to support it. I assume they want to keep OS support for J2K, so it's not like keeping support in Safari really costs anything.

This also brings about another potential question: could the other browsers use the OS-specific library? I wonder if Firefox could add support for these libraries and fall-back to the built-in image support if the format is not supported by the OS or vice-versa (use the OS-library even if the format is not supported by the browser). Chrome probably won't do this but I wonder if there would be a way to do it via an extension. Granted, at least Firefox would likely not do this due to potentially supporting patent-encumbered formats - would that somehow cause an issue for them?

Using OS libraries is mostly just inconvenient for portability, if you want it to run on Windows/macOS/Linux...

Not really inconvenient. They already have quite a bit of OS-specific code to support various things like DX, OpenGL, Wayland, etc. When they built it for an OS, it just leaves out all the OS-specific code for other OSes. It would mostly just be annoying that one OS may support format X while other OSes don't. Granted, if major OSes started supporting a given format it would likely put pressure on the browser devs to add support if other OSes can't use the format.

using os libraries as fallback would be also convinient in case of patented formats (especially video), since the OS may have a license for them

It has pros and cons, its nice to ensure a "uniform ecosystem". something android and apple actually care about :D

IIRC Chrome does have support for HEVC only if you happen to have hardware support for it (so the hardware covers the patent licensing)

https://cdn.discordapp.com/emojis/721359241113370664.webp?size=48&name=yep&quality=lossless

oh, that makes sense

Edge does this. It uses Window's supported formats on Windows but uses Chromium's formats on other OSes.

But I don't think it falls back when something isn't supported.

Wait, then does Edge actually support JXR?

On Windows?

isn't JXR completely uncompressed?

JXR is somewhere between JPEG and J2K in terms of compression

oh, I think I confused it with EXR

Wikipedia claims that Edge doesn't support JXR anymore since the Chromium switch, but using WIC would throw a wrench into that.

exr has compression, it can even do lossy, exr my beloved

I think I only came across uncompressed ones...

makes more sense for production I guess

According to the Microsoft documentation, JXR appears to only be supported as a desktop background and only if the monitor is capable of HDR. So my guess is that it is some sort of "hacked-in" support? My guess it that it won't work with WIC.

huh? JXR has been a built in WIC codec in Windows for years and years https://learn.microsoft.com/en-us/windows/win32/wic/jpeg-xr-codec

Wow, their documentation is so fragmented. I must have been looking at something older.

also a lot of things Microsoft have done or added to Windows ever since Win10 are horrible horrible unnecessary hacks

But they don't even list the AV1/AVIF extension and this document was updated last month. https://learn.microsoft.com/en-us/windows/win32/wic/native-wic-codecs

I know Edge doesn't support AV1/AVIF unless you have the extension installed.

On my Win11 machine, I can open JXR files just fine on Photos (built-in photos app), but not Edge. Edge just downloads the file.

Any programs that can open BMF and EMMA files?

Emma is not a graphical format, just a general compressor. Only original apps can open them

It was made by marcio pais long time ago and is not developed anymore https://encode.su/threads/2459-EMMA-Context-Mixing-Compressor

and BMF?

I find the Library of Congres's preferred format lists quite interesting. Here is what they prefer for video, with the caveat that they always prefer the original format (i.e., for motion pictures, they'd want a big bag of J2K image files, since that's how movies are distributed to theatres): 1. Interoperable Master Format. I have never heard of this, but apparently it involves a lot of XML and apparently uses J2K? 2. FFV1. Open source represent, hell yeah! They specifically want it in MKV, which makes sense. 3. ProRes. Um, Apple represent, I guess? 4. MPEG-2. Lol. 5. XDCAM. Isn't this just MPEG-2 in a Sony-shaped container?

lol for textual works they want either certain XML-based markup stuff like EPUB3, BITS, DocBook, or PDF. They dislike but will accept XHTML, HTML, other XML-based document formats like DOCX (OOXML 2012), SGML, other even worse XML formats, other even even worse XML formats, web optimized PDFs, and finally, RTF, plain text, or "Widely-used proprietary word-processing formats"

For still images they prefer TIFF, J2K, PNG, and JPEG. Dislike but accept PSD, J2K part 2, DNG, proprietary raw formats, and finally, GIF.

Archival is an interesting use case...

to be frank any file format would be fine for archival provided that a working implementation is bundled

so the problem is the implementation itself

for example, if you can compile that implementation to wasm, the only thing matters now would be the wasm specification

and the wasm itself would be allowed to be arbitrarily complex

Looks like MS Edge supports AVIF now. That was kinda weird, all other companies claimed that they can't deviate from upstream, meanwhile MS deviated just fine.

at the very least, MS actually had experience with web browser devel and resources, so thats not really that out there

Huh, I noticed this in the gif2webp tool > -mixed ................. for each frame in the image, pick lossy or lossless compression heuristically Wonder if it's actually smart, or just brute forces and tries both

in `anim_encode.c`

it seems to do it based on the amount of colors?

Huh, I suppose that is a rather fast and easy way to check, even if not very exhaustive

How do I make jpgs without any artifacts?

The original JPEG is lossy even at q100 AFAIK, which means that even at the highest quality you'd have SOME compression artifacts, this is just how lossy codecs work, either you learn to live with them, and find a quality level that you're comfortable with, or you jump to lossless and eat the storage and transmission cost

with cjxl and -d 0.0 you won't have a single artifact

Isn't jxl d0 q100?

indeed, both activate the lossless compression

Is that for jpgs or jxls?

jxl, with -d 0.0 you will convert png to jxl losslessly

the next version of libwebp (whenever it comes out) is going to re-enable usage of the color cache feature when encoding lossless alpha channels after it being disabled for around 9 years: https://github.com/webmproject/libwebp/commit/34c807491586d047586ef3b14ebaf945c188d1f0

I had my own personal fork where I enabled this but it's great to see it actually getting enabled in mainline libwebp!

I honestly thought they might have forgotten about it after 9 years

How much of an effect does it have?

it means this can now be used by the encoder for alpha channels. as for how much of an effect it has? I'm not really sure how useful it is for alpha channels specifically but I do remember it making one of my test images larger at the default effort level which is kinda a bad thing...

so uh mixed I guess? with some images getting larger by the encoder being dumb at the default effort level

I really haven't done much tests at all with it soo I don't have enough data for proper results

Yeah... I mean a 'color cache' on an alpha channel doesn't exactly sound promising based on the name alone

also the size/output was the exact same at higher effort since the encoder figured out it was not beneficial to use the color cache on the image I gave it so it just turned it off

yeah I figured the same thing. it will probably only really be useful for images with uncommon like alpha channels

as for why it was disabled 9 years ago it's because the 0.4.x series of libwebp had problems like this: https://bugs.chromium.org/p/webp/issues/detail?id=291

What's a good lossless GPU accelerated codec I can use to keep images compressed in memory?

any derivative of binomial's basis, uastc in particular

Encoding vp9 is difficult I tried like 50 integral transforms to get this at 2mbps using my quantizer

3840x2160px

I did 32% better than this 17:03

Even betta,r sound

I don't think my brain can do better than this, i have short attention span

I recall reading that the fastest growing web image format after 2010 was progressive jpeg. Might have even seen a graph to that effect. Does anyone have a link to that data, or perhaps even to such a graph?

This is perfect, thank you!

On another note: what would be a good method for (visually) losslessly re-encoding 4k 10bit 4:2:2 h265 files out of my camera? My G9 has had some firmware updates since its initial 2018 release, but I'm assuming it's still using old codecs that are also optimized for compression speed than file size

I don't mind some information loss, as long as it's relatively uniform along the luminance and chrominance channels as these are flat profile videos

is the endgoal reducing the final filesize? if not, keeping the og files as they are is better than recompressing

Yep, that's the end goal

Whats the average video bitrate? Need it playable somewhere particular?

150-200 Mb/s. I'm just looking for a newer and less speed vs quality compromised container format

That's less a limit of the format and just a limit of the hardware

what has the container format to do with this....

im pretty sure container format is not really the bottleneck

a 11gb mkv file has overhead of `0.06%` (7mb)

unless you're using mpeg-ts, then container overhead is pretty much nothing

mpeg ts has `3.2%`

which is around 300MB for an 11GB video

I think it was just imprecise language

not really a strong conviction that it was specifically the container that was to blame and not the codec

Netflix adopts AV1 codec for streaming content on its Android app In a recent announcement, the publisher Netflix revealed that they have begun online streaming of content using the AV1 codec on their Android app. This high-performance codec offers a 20% improvement in compression performance compared to VP9. AV1 is a next-gen video codec developed to replace the VP9 standard by the Alliance for Open Media, with founding members including Google, Netflix, Amazon, and other prominent content providers. Netflix emphasizes their plan to roll out AV1 content on all their platforms. The company notes that this codec is well-suited for mobile platforms as mobile networks can be unreliable, and their customers may have limited data plans. The increased compression performance results in relatively lower data consumption, making the integration of the AV1 standard into the mobile app a sensible move. Netflix now utilizes the AV1 codec for streaming content on its Android app - Download Netflix for Android. - Download Netflix for iPhone. Netflix reveals that their AV1 codec 'utilizes the dav1d open-source decoder developed by the Videolan, VLC, and FFmpeg communities, and is sponsored by the Alliance for Open Media'. The company mentions optimizing the decoder to stream Netflix's 10-bit color content. Netflix is also working to 'further optimize 10-bit performance' to enhance all applications using the codec. Currently, streaming with AV1 is limited to selected titles. Users wanting to try AV1 content or reduce mobile data usage can do so by enabling the Save Data feature in the app. With the gradual adoption of this video codec, both hardware-level and contributor-driven improvements, it will be interesting to see how AV1 will replace VP9, or even HEVC/H.265 in the future. https://Mytour.vn/netflix-bat-dau-dung-av1-codec-de-stream-noi-dung-tren-ung-dung-cho-android-26331n.aspx BurnAware Free is an efficient CD and DVD burning tool that

only lossless way is to archive the original files on burnable bluray discs or a spare hard drive/NAS from which you can stream any bit you need ondemand (ie for video editing or rebroadcasting in current formats or different output)

then compress to a format that minimizes deviation from the source material

anyway youre starting with bitrate so high you could easily compress it down. try a sample video in av1ador with different outputs and visually confirm wich parameters give you a result youre fine with

its a tool leveraging ffmpeg to run paralel encodes with preview/compareason

just make sure you use software codecs, theyll consistently preserve more detail for your chosen bitrate compared to hardware encoders

Thanks for your tutorial

Obs developer denny working on huge progress

more recently (1-2 years ago) I was laughing at svt-av1. But the current version 1.8.0 is currently superior to vp9 at an identical encoding speed. (tests on preset 12 and preset 13) for encode video-game-gameplay

svt-av1 still has blockiness artifact issues but, has become more useful for higher quality encoding, especially with the community fork https://github.com/gianni-rosato/svt-av1-psy

these community "psy" forks need to stop

despite the name, without this fork, svt-av1 is less usable for higher quality encodings, because it's over-tuned for metrics and streaming quality and blockiness is a core issue in svt-av1, something wrong with bit distribution though, some not very hacky changes from the community are accepted in the svt-av1 main branch, unlike aom, which has very close development

the forks will stop when they don't need to exist [lul](https://cdn.discordapp.com/emojis/853492073301540894.webp?size=48&quality=lossless&name=lul)

yeah, rav1e doesn't have such forks because community based from the beginning <:KekDog:805390049033191445>

i just mean that they are all garbage

it's all just copium

nope, these are much more significant visible changes than the x26x forks (although they can be useful too, for better fine-tuning) but when these changes will be merged, this fork will be less needed, maybe tune 3 and sharpness adjustment other than that, just if needed Dolby Vision and some fancy features https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2105

nuh uh

It's a significant difference [yep](https://cdn.discordapp.com/emojis/1075610585141628928.webp?size=48&quality=lossless&name=yep) it helps a lot indeed

literally the only response

followed by 1 bitrate comp that only shows noise in encoder

or cherry picked 100000 bitrate comp

response is enough, svt-av1 is pretty cooperative for community changes and plenty have already been accepted for me without these changes svt-av1 was completely useless for higher quality

then there's no point in using the psy fork

but blockiness is still a major issue, although it's less of an issue for usual live or anime content, more for game content and high fps for some reason

no point only if there is no point using svt-av1 or av1 at all

ill stick to mainline aom

<a:trollform:771932238748712979>

mainline aom is more stable in quality, but there are still a lot of issues with detail smoothness maybe for some anime that originally doesn't have high detail density and it's production upscaling it's ok, but for any content with a lot of high frequency details, it's a big issue

rav1e supremacy

I always disable psy when encoding use x264 x265 :ChizuWink:

"Uncompressed screenshots as AVIF" In Steam terms that's meant to mean lossless, but we all know that AVIF doesn't have *real* lossless either... Hmm

Is psy the perceptual encoding thing?

no it's just a term they throw around for no reason

Presume that's short for psychovisual?

So it’s marketing nonsense?

yes

What’s the point of it then?

this, but yes, marketing nonsense

So it’s **meant** to help optimise the video to human perception?

In theory isn’t that a good thing

?

but if it doesnt?

it's always subjective

therefore nonsense

Oh yeah, psychological tuning is inherently subjective

yeah its tunning to on average score better on various psy metrics and direct eye comparisons

its pretty well needed in stuff like svtav1 that has a tendency to make really stupid decisions sometimes if you want high quality snd consistent encodes

Are you saying x264 is nonsense? Though I could believe that "community forks" don't do it well.

Wait you're just using metrics mostly? Using metrics is the problem. Even the best metric is nowhere near good enough.

99% of them are about tuning it for the last bit

to me that's nonsense

🤔

tuning it for the last bit for the same vmaf or some shit

What exactly do you mean by "last bit"?

3 bytes smaller stuff like that

Oh lmao

to squeeze out the bd rates shit like that

makes the unknowing user wonder why the fork that's supposed to "fix" it doesn't work when it's a problem with the core design of the encoder

AVIF can compress losslessly

it can encode straight RGB

limited to 12 bpc of course

in the end, unless you can pay thousands of people, yes. Metrics might not be "good enough" but its the best we got. In the end, it works very well, you can retain a lot more quality when you properly tune an encoder

x264 and JXL have managed quite well with usually just a few people making evaluations.

Steam is using libavif and from what I saw libavif doesn't support RGB

once I found Steam was using libavif I tired to check if it supported RGB and all I found was a warning saying it didn't

I know something only had 4:2:0...

here's an exiftool output from a AVIF made with Steam