JPEG XL

libjxl doesn't seem to, for 30 image sequences it currently needs 4 seconds (`-m 0 -e 1 -brotli_effort 0`, lossy VarDCT)

cwebp takes 1 or 2 seconds (`-m 0`, lossy)

is there an example on using fjxl?

The fjxl codepath activates at effort 1 lossless. IIRC fast lossy is essentially just jpegli

Also define high quality and size reduction. What resolution? Reduction compared to what?

what are you feeding it?

Also use the MP/s, not time measurements. Input decoding isn't the fastest with cjxl

A quick test on my laptop is 15fps on ffmpeg but afaik ffmpeg does not make use of frame parallel encoding

17-20fps with -xyb 0

not the fastest thing, but way faster then 4 seconds

I get ~45fps for 1080p at d1

Could be usable

when you do frame parallel encoding you gain a lot of speed

SSIMU2, less than 50% from the original bitstream

PNGs, but I now think it's a bad idea...

png with cjxl is slow

what is your intended use case?

for context ``` ➜ Pictures hyperfine --runs 15 'cjxl -d 1 -e 1 --disable_output output.png.pfm' Benchmark 1: cjxl -d 1 -e 1 --disable_output output.png.pfm Time (mean ± σ): 85.0 ms ± 2.1 ms [User: 120.8 ms, System: 42.7 ms] Range (min … max): 81.7 ms … 89.6 ms 15 runs ```

after converting to a pfm using magick

remote viewing/access or virtual machine control

VNC sucks, SPICE consumes too much bandwidth

none supported HDR

What is hyper fine

https://github.com/sharkdp/hyperfine

QOI?

If you have reasonably fast hardware can you try ffmpeg encoding? I got over 30fps easily, but I have top hardware

Why not use a video codec for this?

well, if all intra is necessary, then an image codec is typically superior

HTJ2K and JPEG XS are both aiming at fast all-intra

because near-uncompressed quality is *required*

Increase the bitrate further and use 4:4:4 full-range 🙂

first time hearing about HTJ2K, only knew about regular J2K prior

any video codec that has an encoding and decoding latency below 20ms?

JPEG XS has a latency expressed in _rows_, if ultra low latency is what you need, it can do 4 row latency which at 30 fps full HD boils down to 4/1080/30 seconds = 0.123 ms

So, would effort 1 lossless work? (May need a clang build https://discord.com/channels/794206087879852103/803645746661425173/1348861631836323871)

At least for a hardware implementation where the additional latency due to coding itself is negligible

~~iirc JPEG XS has patent requirements, that's why I'm looking for alternatives~~

time to find out at the next opportunity!

Libjxl E1 lossless should be able to reach about 500 Mpx/s easily on a typical CPU, so about 250 fps for full HD.

Main problem with it will be that decoding is actually slower

I was seeing 6ms encode time at 1080p with the exe uploaded just above the link

On an 8 year old Ryzen 1700

~~next up: low-latency JPEG XL~~

that's actually quite impressive...

Slower than encode, but still twice as fast as PNG

Probably with more specialization we could get E1 decode quite a bit faster than it is now, but still a little slower than encode

The funny thing is that at the super high speeds, encode is inherently easier to SIMDify since it already knows all pixels while the decoder only knows them after decoding.

It's a shame --faster_decoding is bugged/has negligible impact. It should really use the fixed MA trees of e1 and e2 at least, then with further options like g0

It seems to just disable the MA tree and predictors entirely at 1 and 2 https://github.com/libjxl/libjxl/issues/3532

does JXL have the concept of restart markers? I wonder if you could speed up decoding by processing each group of blocks in parallel

It does tiling in groups already so you can do MT decode

aah I got you

how small can those tile groups get? like for JPEG-like encoding effort scenarios

128x128

At least for modular

128x128, 256x256, 512x512 and 1024x1024 for lossless. VarDCT can do classic JPEG

IIUC lossless JPEG recompression works by rearranging coefs so they fit VarDCT tile groups, by breaking some DC prediction dependencies, am I right?

anyway, sounds like 128x128 is still small enough for reasonable parallelism in practice

JPEG is basically just a special case of VarDCT where all blocks happen to be DCT8x8 and the adaptive quantization weights are constant. Like with all VarDCT, for the DC there is a modular subbitstream for 256x256 groups of DC coefficients (this corresponds to regions covering 2048x2048 pixels). At the boundaries of those groups there is poor prediction to avoid data dependencies between groups, but overall the DC prediction in jxl will be a lot better than what you have in JPEG...

VarDCT has a fixed group size of 256x256 for both DC and AC.

thanks for the explanation, <@794205442175402004>!

Anyone heard of AVCI and AVCS files?

AVCI is h264 in a HEIF container iirc

And I would guess AVCS is the same but animated (sequence)

How do I remux AVC/H.264 videos to AVCI/ACVS files?

Maybe libheif has a way to do that? I dunno, never tried...

> The I in AVCI is for Intra-frame encoding [...] as opposed to Inter-frame encoding totally makes sense <:kekw:808717074305122316>

jpeg xs software is free for "evaluation" whatever that means, they don't elaborate. Presumably they don't give permission to use it in a commercial product.

But they don't elaborate what they mean by "evaluation" so maybe I'm wrong to presume that.

Also it looks like the intended use is hardware, not software. Like in camera sensors and cars and whatever.

As a replacement for uncompressed video

You can't remux normal AVC videos to AVC**I**. I = All-intra. Normal videos are not all-intra.

What about this, then? https://en.wikipedia.org/wiki/High_E...I:_AVC_in_HEIF

JXS does have patents from Fraunhofer and Intopix, it's mainly meant to be used in video production hardware.

Oh, there's nothing preventing you from shoving normal video into an HEIF container. Same thing with AVIF: you can have pictures, all-intra and normal video.

Presumably if you want to use interframe you have to call it AVCS. Likely software implementations will not care if the brand name is correct.

I wouldnt be so sure, ff used to poop itself with avif if you used the wrong brand

no idea if it still does

JXS is super pointless.

I wouldn't say pointless, it's just a pretty specific niche thing

Internet sites do just fine with video codec streaming.

JXS targets way higher quality and bitrate than internet video streaming

It is meant for production, not delivery

How do I do that?

MP4Box

JXS should be treated more as a way to reduce bandwidth when sending uncompressed video. Think of it as more like ADPCM than something like Opus

Confirmed. QOI can be uploaded as a lossy compressed image or original file

How would that work?

https://manpages.org/mp4box

I don't get it

Conversion from PNG to AVCI (example): ffmpeg -i IMG_4086.png -an -vframes 1 -vf format=yuv420p -preset veryslow IMG_4086.h264 MP4Box -add-image IMG_4086.h264:id=1:primary -ab avci -ab miaf -ab MiAB -ab mif1 -brand avci -new IMG_4086.avci

https://forums.macrumors.com/threads/turn-any-macos-folder-into-an-image-converter-heres-how.2453484/

> can it handle webp into png/jpgs? > I do it all the time to convert those stupid and annoying webp files into jpgs. What a stupid and annoying format. /rant over.

A simplified "Dynamic Wallpaper" .heic that just contains 2 images for Light and Dark modes. I can't get the ones based on sun and time to correctly switch however SSIMULACRA2 85.85117936 for the "Light" image

What about for videos?

Swap the input from PNG your Video file

"ffmpeg -i input.mkv -an -vframes 1 -vf format=yuv420p -preset veryslow output.h264" Won't this be lossy?

`-qp 0`

you can replace `-vf format=yuv420p -preset veryslow` with `-c:v copy`, but it would only work with videos that are already h264

that too

<@184373105588699137> <@207980494892040194> What about -an -vframes 1? Do I keep or remove that?

-an just means no audio

Is Avif2 dead?

It depends on AV2

unless dav1d extends support forAV2 IMO it's going to be a hard sell

https://tenor.com/view/how-about-that-dave-lee-dave2d-what-do-you-think-what-do-you-say-gif-26881293

davxd

No.

AV2 hasn't been released at all <:KekDog:805390049033191445>

AV2 does not exist This is a government conspiracy

It means adult video No. 2

I assume libjpegli defaults to the older API because it's more common? <https://github.com/google/jpegli/blob/main/CMakeLists.txt#L125> No mention of being able to use the newer one either, causing some confusion <https://github.com/google/jpegli?tab=readme-ov-file#usage> <https://github.com/RawTherapee/RawTherapee/issues/7125#issuecomment-2745142117>

Seems the latest Jpegli repo finally adds a black background to an image with a transparent background

How do I make HEIC/HEIF files writable in ImageMagick?

You want to encode to HEIC? Why?

https://cdn.discordapp.com/attachments/862482711729012747/1341604925385216072/programmerhumor-io-stackoverflow-memes-backend-memes-7d5256a5e6b92cb.png?ex=67e36d74&is=67e21bf4&hm=e59856f7c88c2fc609886bec2184ac8a04a22db2c0f209fc3d7d29e436fe36de&

<@207980494892040194> <@184373105588699137> <@886264098298413078> What image viewers can play AVCI/AVCS files in Windows?

None as far as I know, it's an apple thing really

Mpv?

I couldn't even get it to work even with ffplay...

`ffmpeg -i input.avci output.jxl`

try that out with this: https://drive.google.com/file/d/1UgVsgmocsO0dB0TfZKLFfNY-cVsVGXZP/view?usp=sharing

https://github.com/libjxl/libjxl/releases - is it the correct place to download the latest binaries of jpegli? Looks like there are no binaries on https://github.com/google/jpegli

You can still build from that jpegli repo

Though they're identical currently IIRC

that generates executables not dlls. anyone got prebuilt dlls that can be dropped in place of an existing mozjpeg?

That's been a request for a very long time. Having prebuilt DLLs for the 6 and 8 API would help a lpt

its literally the point of jpegli existing too - being able to swap in DLLs for software you use or even your own, without needing to bother with the source code yourself and passively gaining higher quality without changing your workflows - would be huge for sites serving compressed jpgs and thumbnails but native windows apps need consideration as well. Improving your use of jpg reduces the attractiveness of considering formats like webp, reduces the need for their reluctant adoption and keeps a forward migration path open for images to be eventually losslessly transcoded to jxl

are there difficulties in generating those libraries/dlls? a nightly or even monthly would be handy to get the public contributing feedback and adoption

All I know is that everyone who tried has failed to build them

xnviewmp ships a jpegli dll though ?

really? last I tried they compiled in msys perfectly fine

I would highly reccomend making a pkgbuild for it, I wouldnt mind doing so if someone has a windows machine I can remote into, VM or real doesnt matter, my system isnt setup yet

if anyone wants to make their own, iirc it would be easier to for https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-libjxl/PKGBUILD according to https://github.com/google/jpegli/blob/main/doc/developing_in_windows_msys.md and then for packaging you can use reference from https://github.com/Quackdoc/msys-pkgbuild/tree/Master/olive-pkgbuild

With the DLLs?

yes

but it was a while ago indeed

Not many people knowing the existence of "Lossless JPEG" https://www.reddit.com/r/jpegxl/comments/1jrj4ke/file_size_on_iphone/

The messaging is disjointed. Not easy to find in one place and fans can only bring attention to what little they themselves know, assuming they do so correctly

take progressive loading. I vaguely knew that images could start displaying once at least 10-15% of the file was downloaded but according to someone (jxl oxide dev's?) libjxl is capable of displaying images even much earlier and this is just disabled in libjxl so imgs dont start partially loading in ridiculously low quality

to me, lossless recompression should be pushed for as a major incentive for adoption/migration. Almost all conversion apps do slow full conversions that also sacrifice some quality without even guaranteeing smaller filesize and even bloating it several fold in the case of lossless from a lossy source

apps should consistently use the quasi-instant fast path for lossless *reversible* compression from jpeg when the original image is a jpeg AND has not been edited, in addition to no longer locking conversion jobs to only one thread because of old compromises they chose 15 years ago and never revisited since

yeah, especially the single threaded thing. Why do so many apps still only use less and 10% of my cpu

Either they use 1 thread, or they use all and starve the system of resources. Very few use all **cores** so the system remains responsive

xnviewmp until last week used a low accuracy decode method for jpegs...

jpegli integration is still not complete too. For instance, thumbnail generation and exporting to greyscale still seem to use the ancient jpeg encoder even though you asked to process it using jpegli

on encoding performance, those issues are almost always just old decisions that were never revisited since the dawn of dual cores and images encoded fast on everything because resolutions were small then and it made more sense resizing down images first

https://netflixtechblog.com/hdr10-now-streaming-on-netflix-c9ab1f4bd72b

HDR10 confuses me, HDR10+ just doubles the confusion lol

what about hdr10 do you find confusing?

the "hdr" part

how the metadata is supposed to be used

as far as I can tell, I cant even find a reccomendation outside of one paywalled tonemapper

"objective tests"

https://www.winxdvd.com/video-transcoder/h266-vvc-vs-av1.htm

libvpx (vp9) was losing to x264 while being 130 times slower so yeah it's easy to believe that a codec made by the same guys is also worse than vvc

Everything here is either outdated or plain wrong

Av1 is now faster to encode than hevc for a given achieved bitrate,quality

Vvc is very very very very bad rn

Currently worse than av1

bruh

It's just a lie, a lying test

This is also a lie

are you aware that the vvc encoder has been added to ffmpeg? Go ahead and test it. I tested it all day yesterday. and you know what, to compress the gameplay of the game at 720p and bitrate 500 "preset medium". it shows better results than av1 in "a unit of time". but this is only a very specific case with Cyberpunk 2077. when tested at higher bitrates or faster presets or on a Minecraft game, av1 is better.

qp 38-40

The problem with VVC is that it is not as shared as AVC, it is just another stage of development, because HEVC was made before that, and "they" are already working on the new H267.

and of course it will be even slower, and even slower.

your user tests mean little there is not even a single mention of BD rate in your testing

for example, on this test (not mine) and to add to the fire x265 was suuuuper slow while av1 was fast

on this one, vvc has only 4 sample points because it was just too slow to do more for the tester without dying on its weak ryzen 9 9950x cpu

this is the vvc in ffmpeg you spoke about

I don't have a graph of BD-rate encoding time from the same source

so here is one from the april fool joke (you ll understand why it s april fool joke)

xDSV3 corresponds in reality to x266 and for the april fool joke, the "lower left is better" is the joke; on that graph, higher is better quality

these tests are still not enough to completely prove my point there is the question of multiple presets and ... but well, that s at least part of it

I also don't know how you encoded in av1, which is rather important. Was it svt-av1-psy? was it using ffmpeg instead of av1an?

also, on your article, they contradict themselves

something is wrong somewhere

this

meh

I'm on the internet and I'm not interested in anything higher than 1000 bitrate at 8k

this is very small gain for the time spent and the patent situation and the no support situation

better wait for av2

💀

and no one would ever use the bitrate of these samples

we are talking about a score of 40 ssimu2

it s unwatchable

I have very big doubts that av2 will be able to show a better result for the same encoding time. at least by 5 percent. considering that most people use not even average presets, but even faster

I am very unsure about av2 as well

I don't know anything about it

I can only hope it ll be good

but vvc is hopeless to my opinion they might improve in encoding speed and higher bitrate quality (their encoder is probably a bit too immature yet)

but the patent situation is so bad I don't want to touch it at all

AV2 does not exist This is a government conspiracy

x)

av1 is not as expensive as it seems to decode, especially if you use the fast-decode option during encoding

but it will always be more expensive than x264

x264 was a great codec for its time

x264 is still a great codec, the whole problem is in the encoding resolution. for example, at 640x360 with maximum parameters, it encodes a picture better than HEVC and VP9 for the same encoding time. but if you take 1280x720, then yes, the codec has eliminated it. I use it for 540p at maximum

that low resolutions... I wouldn't even think of using them

720p hurts already and I would consider it only for handheld devices

but we probably have different goals in mind

the tests above were for 1080p

so that might be why your experience differ

In general, I spent a very long time testing to switch from AVC to HEVC. The problem was that it is too demanding to DEcode, so I created a hevc preset exclusively specifically for 1280x720, which in terms of decoding speed is almost equal to vp9 and avc at 720p resolution. I didn't think it was possible, and yet, it is. -vf "hqdn3d=luma_spatial=1:chroma_spatial=1:chroma_tmp=2:luma_tmp=3,zscale=w=1280:h=-2:filter=spline36" -c:v libx265 -preset placebo -bf 5 -refs 4 -crf 26 -g 900 -x265-params "open-gop=1:me=star:rskip=0:tskip=0:scenecut=0:rc_lookahead=60:aq-mode=3:lookahead-slices=0:wpp=1:ctu=32:b-intra=1:qg-size=32:subme=7:qpstep=10:aq-mode=3:weightp=0:weightb=0:aq-strength=1.4:tu-intra-depth=4:tu-inter-depth=4:early-skip=1:rd=6:qcomp=0.7:rect=0:amp=0:psy-rd=0:rdoq=0:psy-rdoq=0:cbqpoffs=-2:crqpoffs=-4:min-cu-size=16:no-deblock=1:max-merge=5:merange=92:frame-threads=1"

compression of streams, streamers, in telegram, for viewing mainly on smartphones. A lot of restrictions.

maybe you d like to try svt-av1-psy with --fast-decode=2 svt has its own parameter to improve decoding perf I saw some graphs about decoding speed and quality loss but overall people thought it was a good way to have fast av1 decode

also it will be faster to encode than x265 placebo

This can't help even in theory, in practice it turned out that the complexity of decoding av1 is inevitably 5 to 10 times greater

The encoding speed is the same. Decoding speed on the processor: 100% avc 55% vp9 50% hevc (my preset, on a normal preset like veryslow about 20-30%) 6% av1

what 6% on av1

on my computer x265 slower is already slower than svt-av1-psy preset 2

by a good margin

decode ?

there are some weird artifacts in some

ho sorry I read encode, for decoding on phone I never tried

this is something that nobody usually fucking talks about. the more complex the encoding preset. the more small blocks, more separation, more motion vectors

but if you use libdav1d I m surprised a random phone cannot manage it

for the 1st one it s really present on my screen but well on a phone I don't know if I d see them

on av1 it would never happen though

Since I also created my own fork for encoding av1. I inevitably encountered the fact that on preset, for example, 0. The DEcoding speed of AV1 is still 3-4 times slower than on preset 5

av1 prefers to blur everything

it is a fork of what?

😨

svt-av1 fork

using svt-av1-psy would be better

let me try to play av1 on my terrible phone

argg I cannot decrypt my ssd on my phone

I use MPV for reference

I made bigger changes to the settings of the parameters of work. Although I took from psy the algorithm of increasing QP during shading. Still, I selected the curve of staring myself

which version is it from?

I don't remember. I made the initial fork from version 2.0.0

a little later there was a global optimization of the work, which I considered crap. And I separated into my fork, and separated my fork into another fork, which I call the best possible av1 encoder. True, I never found people who could prove it

my normal fork https://discord.com/channels/794206087879852103/805176455658733570/1277346077451882638 my "plcebo" fork https://discord.com/channels/794206087879852103/805176455658733570/1278073368612175894 https://discord.com/channels/794206087879852103/805176455658733570/1312052368560623717

the last one was made due to complete dissatisfaction with the work of "preset -1" in original svt-av1

I m currently viewing a 1080p 24000/1001 fps av1 encode without fast-decode nor tile-column

my phone cost me 200 euros

and the quality is unmatched for the size

seeking is instant as well

👍

What preset is it encoded on?

it was first episode of this

https://nyaa.si/view/1745023

so preset 2

after preset 2 the efficiency gain is little to none compared to the time increase

anime

yes yes

99% static frame

I don't think I got a live action at hand, I ll test that once back home

I ll need to encode it too

encode any Minecraft gameplay. on preset 0 or -1. 10-20 seconds will be enough

I m not going to use preset 0 or -1 it s waste

using preset 2 with special techniques (NB) is far better

more use of my computer time x)

svt-av1 removed decoding level legacy because can't comply

I m going back home now so I ll try that this evening

wow I cannot possibly download a clip from youtube they are already bad quality

I ll reinstall minecraft and try to get raws myself

Once in a while I'll stumble across someone on Discord streaming in AV1 at 1440p or 4K. It cripples my computer and maxed out all cores, so god help my poor phone if I ever tried

<:galaxybrain:821831336372338729> 1440p 2000 kbps

Yeah avc is not designed for high res and low bitrates. Hevc adds more varblock sizes and VVC adds rectangular blocks

I think jxl has rectangular blocks too

Yes, jxl has blocks with aspect ratio 1:1, 1:2 and 2:1 for every block size, and also 8x32 / 32x8

okay so it was not trivial especially when there was entities on the screen, here is my little summary (for --preset 2) - 1080p 60fps had a lot of trouble - --fast-decode=2 was clearly not enough - --fast-decode=2 --tile-columns=1 helped visibly but wasnt enough to watch a flawless av1 on my phone - --fast-decode=2 --tile-columns=2 --tile-rows=1 was almost enough, I almost could watch it nicely. This is due to the fact that phone uses ARM so each core is quite weak and tiles allows to improve multithreaded decoding - same but applied for 720p 60 fps which was sadly still not enough for some specific scenes - same but applied for 720p 30 fps, this time finally it worked flawlessly [result](https://discord.nfp.is/?v=https%3A%2F%2Ffiles.catbox.moe%2Fyceto2.mp4) my conclusion is: av1 is harder to decode on phone than I thought, I admit that I still think that for 720p 30 fps, the compression is great here but I cannot say about other codecs because I did not have a proper comparison on that

okay on my phone it looks alright, on 4K full screen it s x) different

but that s to be expected for 918 kbps

av1 on phone is weird right now because most phones use libgav1 when no hwdec is present

ho god it s so bad on my desktop XDD

new android changes this. but... well, its not common'

to share the ssimu2 score if some people want to vomit 👀

how were you playing the videos on phone?

yeah the point was to get a minecraft gameplay that was fluid on my 200 euros phone ^^

doesnt excuse the low bitrate- but it seems that this is what the person I was talking to would target

comparing with other codec would be interesting now

what player are you using on what phone?

I used both the default player in google files app and MPV

there was no significant difference between them

the phone is relatively random, let me find the name

moto g54 5G

interesting, mpv should be significantly faster seems like it uses dual core a78 and 6 core a55, so it shouldnt be slow [Hmm](https://cdn.discordapp.com/emojis/1113499891314991275.webp?size=48&name=Hmm)

yeah I have an LG G7 thinq which uses 4 Kryo 385 Gold and 4 Kryo 385 Silver which are based on A75 and A55. so you shouldnt really be having issues decoding av1 too much

I wonder why that was then

decoding anime was easy

but minecraft gameplay with entities in front of me wasnt as easy

and I believe the options I tried should have been quite good at helping decoding

but it s weird because something like the opening of charlotte plays nicely

and it is NOT an easy opening

I wonder why this specific video was so hard

maybe I should have tried 1080p 24 fps since the beginning

instead of 720p 60 fps

didn't a google play update replace that with dav1d?

on some devices

<:Stonks:806137886726553651>

so far I'm making far-reaching conclusions: "guys, because of ARM we're stuck at 720p" <:kekw:808717074305122316> for 1080p use vp9 only

hevc and av1 overload the decoder too much due to complex motion vectors vp8 avc have too small blocks. vp9 well this is the perfect choice for 1080p in 2025. especially considering that this codec compresses minecraft the best. After all, according to my theory, also because of the hype of minecraft on youtube, engineers made vp9 for youtube based on minecraft. but this is just my schizo-theory

google claimed that all android 12+ phones get it, is that not accurate?

they get it, ita just not prioritized , apps have to opt in

a15+ should be dav1d by default

ah

I've thought about libvpx is still being update, improved. It's not the same encoder that came out in 2013... Maybe there's no point in AV1, due to the global stagnation of technologies... I'll never live to see av1 streaming... <:SadCheems:890866831047417898>

iinm you should force an update to google play services. oddly it can stay pinned on a year old version otherwise

On my phone, an HDR 1080p 60 fps AV1 video plays better with software decoding than hardware decoding in mpv. Libdav1d is truly magical. 😅

[av1_woag](https://cdn.discordapp.com/emojis/852007419474608208.webp?size=48&name=av1_woag)

Woah, google photos can play back 4k AV1 video better than mpv, never thought I would see the day

well, mpv does have a button to easily disable hwdec at least so it should be the same, but iirc mpv-android changed some defaults around so may need to change some settings

For mpv I turned on low quality video decoding and set upscaling/downscaling to bilinear_fast and it still struggles

Google photos just about manages to play the 4k video smoothly, maybe a dropped frame here and there

interesting, any chance it's a mali device?

Pixel 8, idk if that answers your question

yeah, not mali I dont think... weird

No wait, Google Tensor G3 uses Mali-G715 MP7

so yes it is a mali device

Okay I downloaded the apk from Github and it's perfoming better compared to google play's mpv apk

mpv is dropping less frames but still not quite watchable

ahhh, yeah. mali and mpv are not exactly great with eachother. there are work arounds but I cant think of them off the top of my head

Is it a driver issue? The pixel 8's performance was really hampered by crappy drivers on launch.

yeah, mali in general has terrible drivers, iirc you could probably enable vulkan, but im not sure if you need a patched build on the G3 or not

Still, mpv playing 1440p 60 fps HDR AV1 video flawlessly despite suboptimal drivers is kinda nuts. Libdav1d really is doing a ton of heavy lifting 💪

What about the format makes it seem optimised for Minecraft?

this is just an observation. There is a fact of testing - minecraft is the most incompressible game for compression. And I suddenly noticed that with identical encoding speed VP9 gives a better result than HEVC on all parameters. And also on all parameters better than AV1 (everything lower the "best" parameter)

What makes it specifically so impossible for compression? It’s just blocks isn’t it?

Or is it the complex motion vectors

well, these are the test results I've seen. Among all the codecs after AVC, minecraft is the game with the least compression gain between vp9 hevc av1 codecs. I've compressed it a lot myself, I'll say that's true. And it's all about a lot of factors, very active gameplay and very complex vector geometry due to the 3D world with sharp block edges

And also the impossibility of using deblock filter, in general, the algorithm cannot be used in this game

Ah so it’s less incompressible and more it goes against all commonly used compression techniques?

Like you could probably write a Minecraft-specific dedicated compression algorithm but it wouldn’t be like most others?

<:galaxybrain:821831336372338729> I AM ?

Well, I created a fork of svt-av1 in order to compress games and minecraft

but if you need to compress Minecraft quickly, vp9 suddenly becomes the best solution, no compromise

and one more important thing. vp9 motion vectors are much simpler, about 2-3 times easier to decode than hevc, so in very dynamic scenes in minecraft this will not cause problems with decoding

JPEG-XM Extended Minecraft

https://discord.com/channels/794206087879852103/794206087879852106/1323400503765237811

Issue is the pixel fine detail on far away blocks, sharp edges everywhere and transparent foliage

hey, I'm developing a bitmap compression codec

it's called Pixcrumb, it's meant for planar low-bpp bitmaps, and I'm trying to design it to be relatively fast to decompress while also having good compression ratio

I'm having trouble with developing it...

the first coder I made for it used a combination of 4-bit zero terminated literals + exp-Golomb-coded zero-RLE, just like the Pokémon compression codec... and everything else I tried performs worse than that...

I've tried variable-length coding for the literals and I've tried LZ77 instead of RLE... all 3 combinations of that almost always perform worse than my first coder

is this the right channel for talking about this?

Yeah, this channel is right, we're not strict about this kind of stuff as long as it's not super off topic

What do you mean by low-bpp? Lossy or low bit depth? Assuming it is low bit depth since you are mentioning RLE: does it have to be planar? You might be better off doing it interleaved and doing palette or something like lossless webp's color cache...

I mean low bit depth, low bitplane count (usually 2-4bpp). It could actually be non-planar, but I designed it to be planar because it's an image codec targeting old video game consoles that use planar graphics formats.

I'll think about it, thanks for the feedback!

for low-bpp dithered art LZ compression works well, for low-bpp non-dithered art, try 2D RLE

MPV support hardware?!

Yes. Ctrl+H

LMAO

i didn't know

A lot of people here have experience with codecs and stuff like reconstruction, so a quick question: I want to create a virtual filesystem that allows editing FLAC metadata without affecting the original files. The difference between what is written to the virtual fs and what is in the underlying fs must be stored, and this must be enough to reconstruct the data that was written to the virtual fs. A plain binary diff could work, but *might* result in excessively large diffs. A file format aware diff would produce the smallest possible difference, but would be more effort to implement. So, does anyone have any idea how hard the latter variant would be to implement? I figure I'll try the binary diff approach first, but I'm curious what people think.

FFmpeg can now decode APV so we should benchmark it against JXL, of particular interest is fastdecode

https://www.phoronix.com/news/FFmpeg-Merges-APV-Decoder

so I was playing a bit with WavPack encoders to reach best compression and `wavpack -hhx6` was always heavier than FFmpeg's own WV encoder (`-compression_level 12`), but apparently it is because it uses old WV 4.0 and does not embed CRC checks (?)

too bad we can't disable CRC calculation in `wavpack`

Are the CRC checks actually that much data?

`115000597` bytes `115071869` bytes problem is: I don't really know because apparently it saves the space of CRC blocks, but it has worse compression > I ran ffmpeg's WavPack encoder, and similar happens. With -optimize-mono it can produce smaller files than reference WavPack - I guess due to missing block checksums, which takes up space - and without it is naturally quite a bit worse; size orders are > 8, 7, 4, 6=5 (bit-identically), (here are reference WavPack -hx6 down to -fx3), 1, 2, 3, 0 with -optimize-mono > 8, 7, 4, 6=5 (bit-identically), 2, 3, 1, 0 without. > "0" is ffmpeg's default and encodes dual mono, so on this signal it is twice as big as WavPack -x https://hydrogenaud.io/index.php/topic,123655.msg1025694.html#msg1025694

71kb...

more than that since FFmpeg should compress worse than `wavpack`

I doubt that...

you definitely want those CRC checksums

well I quite like how FLAC handled this a simple single MD5 hash for the *whole* file instead of a CRC for each packet or sample or whatever

But packet-based checksums also have their place - they give you more granularity - in case of data corruption you can see which parts of the data have been damaged, and which can be salvaged

except for streaming purposes I don't see the point

bc if you want to have some "extra safety" for local storage, then go for disk backup or RAID 5 or whatever I don't want evety format to implement their own data-corruption detector

that's personal taste ofc

JXL inherently has error detection thanks to the ANS runs

<@184373105588699137> I did a short test with streaming to youtube. SVT@25000kbit/s and fastest preset. According to yt-dlp all available streams are AVC but youtube's stats for nerds says the video delivered to viewers is VP9. So same as when I last tested

Apparently the Windows file explorer `Rotate right` and `Rotate left` options add both sRGB and gAMA chunks to PNGs...

Yet another reason why files keep popping up with Gamma applied to sRGB images I suppose

I'm still only getting vp9 on 1440p t.t

I also only get VP9 on youtube. But I get VP9 no matter what I am streaming to youtube. They are transcoding everything to VP9

their live VP9 encoder craps on their live avc encoder so that is a win

yeah even just opening a random live stream im getting AVC on ff

Interesting. If I myself stream to youtube I receive a VP9 stream. Though I haven't tried extensively on how I could get an AVC stream

maybe live moide matters? dunno

I have tried different latency modes in youtube's livestream settings, no difference

the streamed codec also doesn't seem to matter, I tried both AVC and AV1, both are transcoded into a VP9 stream by youtube

weird

I wonder if it depends on injest datacenter load

No idea

bitrate also makes no difference, I tried 25000kbit/s and 250kbit/s, still nets me a VP9 stream

I have clicked through a few livestreams, all of them are VP9 for me

maybe this is a firefox skill issue lmao

I don't think so, the same happens with chromium

Ok, after clicking through a few more streams I found one with AVC, which it is in firefox and chromium

yeah I wonder if injest is the issue then

weird

then again, I only watch streamers with 40-200 viewers usually so it might be that

So in conclusion, no idea why

lol

yup lmao

Ye, I it's a preference thing - in my case I like those things to be able to work "transparently" and independent of the storage medium. It would be cool if this wouldn't have to be done at a file format level - eg. via built-in function in filesystem which could do create/verify data blocks checksums.

<@184373105588699137> <@167354761270525953> you may need to enable AV1 in account settings/preferences under playback on desktop

yeah those are set

Same

There isn't even an option anymore to not have AV1 enabled

doesn't seem like vulkan video can encode or decode RGB encoded videos lol

openapv has finally be merged into ffmpeg https://www.phoronix.com/news/FFmpeg-Adds-APV-Encoder when this lands in stable, im gonna have a lot of fun comparing this to jxl

man I wish I didn't need to patch ffmpeg <:SadCheems:890866831047417898>

I just hope that it really does land with Android 16

it will be optional but yes it's in A16

https://developer.android.com/about/versions/16/features#apv

Hopefully it'll be implemented by most vendors

I don't see why it wouldn't be tbh, it will likely be default, but some vendors may choose to disable it on lower end hardware because A) it's software encoding so it's really going to hammer the CPU B) it targets bitrates up to gbps, even at lower settings its still going to do 200+mbps which will really kill storage on low end devices

really sucks how much you have to pay extra for more storage on high end phones

and they don't have sd card support anymore...

worst offender might be the pixel phones, the 9 pro xl starts at 128 gb and you need to pay 100€ extra for 256 gb

some do some don't, I refuse to buy a phone that doesn't, but tbh, Im kinda digging usb storage lately, some real high perf small usb keys that can be strapped to the back for recording

i've seen people record log footage directly to an external ssd from an iphone

I have done that lol

Also on Android with Motioncam

nice

motioncam dev went closed source [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&name=av1_dogelol) oh well, not much benefit to using it over mcpro or blackmagic cam

Sadly they did, but the app is still good, leagues ahead of any other camera app I've tested. Blackmagic Cam is a joke, seeing as the bitrate selction is super low

I mean, it gives you what makes sense for smartphone encoders

I think I still have the open source motioncam APK lying around, but the new Pro version is much more advanced

afaik I do have a fork with the latest source availible on my repo i managed to grab before it was taken down

nice

well, mcpro24fps is still out there ~~and cracked~~ so generally I reccomend either using blackmagic if you want a free app, or mcpro24fps which does provide some greater customizability

the thing I dislike about blackmagic app the most is the absurdly low max iso when in manual mode

What CPU do you have again?

on my desktop? ryzen 2600

Just thinking if lossless would decode fast enough for video https://discord.com/channels/794206087879852103/803645746661425173/1365676466586783755

It can be, even for mobile, but mostly at e1

but testing with fast decode sounds like an idea, why not

will try if I have time later

Napkin maths says FD4 can handle 1080p120

ohhhh

we'll see

it was fast enough before the older regression

That was based on my CPU, using your djxl results, you should be able to hit 4K60 (Possibly... maybe)

I will try and report back later

You mean the faster decoding one, or something else?

yeah faster decoding, one sec

this was my decode speed https://cdn.discordapp.com/attachments/673202643916816384/1182221413856313384/image.png?ex=6819b97d&is=681867fd&hm=1c695c546eac3ec87a8fddcce0cff862e5f1bca77aa060c978c458e07e880c81& https://media.discordapp.net/attachments/673202643916816384/1182221277776314398/image.png?ex=6819b95d&is=681867dd&hm=63c4d77c4d2019d74165b9f27517686a218eb3b02c8aa86c29a28ca1742bc800&

iirc they were both with faster decoding 4

i plan on restesting, I just need to recompile libjxl git, openapv git, and ffmpeg git

ah, 98fps is without faster decoding mb

https://media.discordapp.net/attachments/673202643916816384/1182221278430634014/image.png?ex=6819b95d&is=681867dd&hm=22bbe28d27031b57a35ac25597f1b4d71714375cf924a7403c5f9a1ab1eeb63a&=&format=webp

this is with faster decoding

kk, went back and verified, this is how I encoded them `cjxl -e 3 -d 1 --faster_decoding=4`

``` liboapv AVOptions: -preset <int> E..V....... Encoding preset for setting encoding speed (optimization level control) (from 0 to 4) (default medium) fastest 0 E..V....... fast 1 E..V....... medium 2 E..V....... slow 3 E..V....... placebo 4 E..V....... default 2 E..V....... -qp <int> E..V....... Quantization parameter value for CQP rate control mode (from 0 to 63) (default 32) -oapv-params <dictionary> E..V....... Override the apv configuration using a :-separated list of key=value parameters ```

it has qp controls, so weird

also presets instead of profiles

it can only be muxed in .apv rn which sucks

also <@853026420792360980> would it be possible to support a `-jxl-params` in ffmpeg?

there's no generic library option parser so individual flags would have to be mapped

[sadge](https://cdn.discordapp.com/emojis/1022473190133473381.webp?size=48&name=sadge)

is there any flag you needed in particular

none of them are hard, just require commits

the only one I actually care for atm is faster_decoding since im more interested in using it for video sequences

I imagine other people would have other interests tho

comparing `cjxl -e 6 -d 0.5 --faster_decoding=4` to `-c:v liboapv -preset fast` ```ps ➜ /tmp l out* Permissions Size User Date Modified Name .rw-r--r-- 351M quack 5 May 14:21 out.apv .rw-r--r-- 394M quack 5 May 14:29 outjxl.mkv `````` apv mpv fps avg: 490fps jxl mpv fps avg: 130fps `````` ➜ /tmp hyperfine --runs 5 'ffmpeg -i out.mkv -f null -' 'ffmpeg -i out.apv -f null -' Benchmark 1: ffmpeg -i out.mkv -f null - Time (mean ± σ): 19.710 s ± 0.198 s [User: 102.234 s, System: 5.019 s] Range (min … max): 19.493 s … 19.973 s 5 runs Benchmark 2: ffmpeg -i out.apv -f null - Time (mean ± σ): 2.870 s ± 0.053 s [User: 24.793 s, System: 0.605 s] Range (min … max): 2.819 s … 2.942 s 5 runs Summary ffmpeg -i out.apv -f null - ran 6.87 ± 0.14 times faster than ffmpeg -i out.mkv -f null - ```

apv ``` Video Score for 1439 frames Mean: 85.69301367 Median: 86.31131066 Std Dev: 1.62214221 5th Percentile: 83.13180947 95th Percentile: 86.92562095 ```

jxl ``` Video Score for 1439 frames Mean: 87.88833392 Median: 87.44315682 Std Dev: 1.54705227 5th Percentile: 86.00371500 95th Percentile: 90.30870678 ```

can for sure drop the distance a bit on jxl , but all in all, not bad

for comparison to prores standard, ``` size: 692M ffmpeg time: 2.802 mpv: 55fps Video Score for 1439 frames Mean: 90.97257053 Median: 90.35808189 Std Dev: 1.33401068 5th Percentile: 89.82873741 95th Percentile: 93.17081174 ```

<@167354761270525953> APV is actually not that bad at all

I think jxl can probably be tuned to out do it, but for now, it's solid

Very nice

If it can be competive with prores on mobile then that's all I could wish for

And 10bit

and LOG

lol

Maybe when JXL at some point supports scrubbing etc.

yeah, I will likely still continue to use jxl since thats how my workflow is setup (I just mux it into a mkv file, so my NLE is fast) but I could see this being a good competitor

Your NLE supports JXL in MKV?

I use olive which supports what ffmpeg supports

I just have a small patch to add jxl as an accepted riff type

```diff diff --git a/libavformat/riff.c b/libavformat/riff.c index df7e9df31b..16e37fb557 100644 --- a/libavformat/riff.c +++ b/libavformat/riff.c @@ -34,6 +34,7 @@ * files use it as well. */ const AVCodecTag ff_codec_bmp_tags[] = { + { AV_CODEC_ID_JPEGXL, MKTAG('J', 'X', 'L', ' ') }, { AV_CODEC_ID_H264, MKTAG('H', '2', '6', '4') }, { AV_CODEC_ID_H264, MKTAG('h', '2', '6', '4') }, { AV_CODEC_ID_H264, MKTAG('X', '2', '6', '4') }, ```

Nice nice. I hope that a new FFmpeg version with the JXL commits releases soon, it's been a while since they have been merged

what os?

In general

<@853026420792360980>'s patches were merged in january I believe

what were the patches for? iirc ffmpeg should have had a release since then

The patches introduced libjxl_anim

But these patches have not been included in releases since

You currently need to compile from source to get it

``` ffmpeg version N-118321-g4c96d6bf75 Copyright (c) 2000-2025 the FFmpeg developers built with gcc 14.2.1 (GCC) 20240910 configuration: --enable-libjxl libavutil 59. 55.100 / 59. 55.100 libavcodec 61. 31.101 / 61. 31.101 libavformat 61. 9.106 / 61. 9.106 libavdevice 61. 4.100 / 61. 4.100 libavfilter 10. 6.101 / 10. 6.101 libswscale 8. 13.100 / 8. 13.100 libswresample 5. 4.100 / 5. 4.100 Encoder libjxl_anim [libjxl JPEG XL animated]: General capabilities: dr1 threads Threading capabilities: other Supported pixel formats: rgb24 rgba rgb48le rgba64le rgbf32le rgbaf32le gray ya8 gray16le ya16le grayf32le libjxl AVOptions: -effort <int> E..V....... Encoding effort (from 1 to 9) (default 7) -distance <float> E..V....... Maximum Butteraugli distance (quality setting, lower = better, zero = lossless, default 1.0) (from -1 to 15) (default -1) -modular <int> E..V....... Force modular mode (from 0 to 1) (default 0) -xyb <int> E..V....... Use XYB-encoding for lossy images (from 0 to 1) (default 1) ```

ah rip

It's very usable already. If only JPEG transcoding were supported

It already does, it's up to viewers to implement it. IIRC VIPS example viewer supports it

It'd take quite a bit of storage, but I don't suppose you could try lossless FD4? If I recall we made it even faster than lossy

Well for lossless sometimes FD3 is faster. Depends on the image and PC.

Did we ever actually test against the same image? To see if it's only hardware or image content

I'm not sure

id have to take some time tommorow to do it and find a scratch disk

but ill try

does anyone know a good way (or anyway really) to visualize the allocation of the 4 VP8 segments in lossy WebP? aka this: https://www.slideshare.net/slideshow/the-vp8-video-codec/8468382#70

I think `-sns` in cwebp might be responsible for deciding how to split up the image but I have no way to visualize it

https://www.nature.com/articles/s42256-025-01033-7 > Here we present LMCompress, a new method that leverages large models to compress data. LMCompress shatters all previous lossless compression records on four media types: text, images, video and audio. It halves the compression rates of JPEG-XL for images, FLAC for audio and H.264 for video, and it achieves nearly one-third of the compression rates of zpaq for text. 🤔

Halves the rates for lossless? I have a hard time believing that...

That is, for photographic images, I don't think there's that much room for improvement left for lossless compression.

does it mean we now have a decoder that sizes tens of gigabytes?

I read that and their previous paper the other day. They have no actual documentation of encoder settings or encoder version. Just linking to previous papers that still don't show any numbers

They just link back to the original paper for JPEG XL

So is it getting an ai model to predict the next token and storing differences?