JPEG XL

it's talking about jpeg compression not image compression

Because these are different things, WebP will not be able to encode any already lossy Jpeg in lossless quality into a guaranteed smaller size as other formats from this paper

wait a minute. is someone creating another tools to compress an already compressed jpeg? despite the fact that the only format that will be used is only JPEG XL

are you drunk

does that make sense? without competition, this is just one of the small functions inside jpeg xl

maybe now I see some kind of waste of time on scientific research

that's 99% of scientific research

it wont be used now

maybe later

maybe already be outdated

yeah...

Lepton has been used by Dropbox for a very long time https://dropbox.tech/infrastructure/lepton-image-compression-saving-22-losslessly-from-images-at-15mbs

why do people talk about AV2, stop it, it's stupid

but of course it's a little sad, big companies need a lot

Video formats... I want my videos to be playable on most devices, so AVC is the only wise choice.

avc is generally a good choice, and the best if we are talking about video size up to 720p

Is AV1 acually deployed at scale by anyone yet? I haven't really come across any usage in the wild, despite decode support having been there for a couple years. YouTube doesn't seem to serve it except for a few test videos, and even the certain "media sharing sites" basically have no usage of it.

i've seen it on a lot of youtube videos, mostly popular ones

90% of videos I watch on YouTube are in av1.

Also on sites like 9gag, I see av1 webm.

For video it makes sense if there are enough views

i wonder what % of youtube's _views_ are: - on videos where they have av1, or - actually served in av1

I think youtube does cheap h264 first, then slower h264, then vp9, then av1, each next step only if the video is sufficiently popular

some videos are encoded in av1 even with very few views (especially if they are 4k+) https://youtu.be/0UzBMqlZ-_A

av1 videos: https://www.youtube.com/playlist?list=PL8I8CQ7kay7tCmyR1YUJSPjVSM3GWUnGV&jct=X5zYd95wNogac-Nc3hpSK4T5f6EC9g

You can add videos

Is collaborative

Got trolled

yea, that' the idea

the idea is that you'd put videos in an <img> tag and they'd be treated like "GIFs"

with no controls, discarded audio, and loop by default

Because they don't want to reinvest time in a vp9 encode as many videos they are

didn't see this HN comment until just now, but I meant exactly the same thoughts about the img tag (that we can just specify to the browser that it is an image, without creating a separate format) https://news.ycombinator.com/item?id=33392287

Looking back through my RSS feed I can see a few that are AV1, but most are VP9. I probably don't have H.264 because I'm on Fedora currently, so I guess most of the ones I watch aren't popular enough to have the AV1 conversion. That and I often watch them soon after launch because of the RSS feed, so the conversion may not have been done.

85 kb | cjxl -e 9 -E 3 -d 0.95 | avifenc --min 20 --max 20 -s 0 -y 444 -r f -d 10 -c aom 50 kb | cjxl -e 9 -E 3 -d 1.9 | avifenc --min 30 --max 30 -s 0 -y 444 -r f -d 10 -c aom 23 kb | cjxl -e 9 -E 3 -d 4.6 | avifenc --min 40 --max 40 -s 0 -y 444 -r f -d 10 -c aom

That kind of image content is not very typical and I think it works very well for av1's directional prediction modes.

I think if the libjxl encoder effectively used splines it could be improved quite a lot though

I figure that's on the todo list

does anyone know of a CLI tool to normalize audio files in batch? including the ones that are louder than 0db like I wanna normalize several 32-bit audio files based on max peak to something like -6db I tried ffmpeg but volumedetect command returns 0db when the max peak is higher like this

and SoX just flattens peaks louder than 0db so it causes horrible clipping like that

so I need a CLI tool that does the same thing as Audacity's Amplify, which by default brings the loudest peak down to 0db without cutting/flattening peaks

https://gitlab.com/AOMediaCodec/avm/-/merge_requests/488 GitLab C071 Subblock MV from Local Warp (!488) · Merge requests · Alliance... Initial test merge STATS_CHANGED Immagine Debargha approved it.

https://en.wikipedia.org/w/index.php?title=AV1&diff=prev&oldid=1120020199

https://engineering.fb.com/2022/11/04/video-engineering/instagram-video-processing-encoding-reduction/

https://engineering.fb.com/2022/11/04/video-engineering/instagram-video-processing-encoding-reduction/

<:FeelsSadMan:808221433243107338> ```In early 2021, we ran projections that showed that within 12 months we would not have enough capacity to provide video uploads for everyone```

I'm confused by that statement and the article. If they want to reduce capacity, wouldn't they lower the file size to get the same junky quality as H264 with lower bandwidth? They are suggesting the opposite - use the same capacity but increase quality. That appears to contradict. > Traditionally, we have created both ABR and progressive encodings from the original file the client uploaded to our back end. Sounds more like they were just doing more work than they needed to and only now went back to take a look. So it's not about bandwidth, it's about compute capability and they were obviously doing way more than was necessary and nobody noticed until now. 🤦 > This approach frees up compute for advanced encoding production... This is where the contradiction comes in - since AV1 requires much more compute resources than H264. Now the question is - aren't they still in roughly the same capacity boat? They freed up resources... so they could use them on AV1. > This is especially important in providing a great experience to people in countries that have slower internet connections. If they are keeping the same file size and increasing quality, that doesn't help on slower connections. I assume they are also encoding at lower size with the same junky quality they were getting on their previous H264 as well...

yeah, they did double encode instead of just repackaging and that's why they wasted so many resources they also don't seem to use custom ASIC/FPGAs for encoding as many other companies do who need to encode massive amounts of video content quickly

well there's really no beating x264 when it comes to quality per bpp

so using x264 instead of a hardware encoder lets them serve lower bitrate files at the same quality

so it's a tradeoff

I would like to add AV1 in the telegram as soon as possible so that I would never use AVC again (and of course in Discord)

it used to be, but now almost all large video platforms with a lot of user generated content have moved to hardware encoding, I can't find a paper where it was described that H264 hardware encoding quality was comparable or only slightly worse than x264, but was much faster and energy efficient

but, for something like Netflix, spending a lot more resources to achieve maximum quality is reasonable

ffmpeg.exe -i VidroIN.mp4 -movflags +faststart -pix_fmt yuv420p -c:a libopus -b:a 87k -application audio -apply_phase_inv 0 -vf "scale=960:540:flags=spline" -c:v libx264 -preset placebo -bf 5 -refs 5 -g 300 -qp 24 -x264-params "keyint_min=30:rc-lookahead=250:me=tesa:scenecut=20:chroma-qp-offset=-4:me_range=16:mvrange=512:psy=0:nr=100:deblock=1,1:subme=9:b_bias=100" -f mp4 VideoOUT.mp4 harder me_range=16 -> me_range=32 -> me_range=64 simpler me=tesa -> me=esa verysimpler -> me=umh LOW RAM lookahead=250 -> lookahead=60

this is my personal function for compressing streamers' streams in telegram

after tests, I found out that with respect to quality/time it is better than using HEVC

Improved quality qp=24 -> qp=20

only ffmpeg 5.1+

> crhoma-qp-offset=-4

is this unnecessary? or does it offset the 4:2:0 mostly

Discord can embed AV1 with some hacks https://stolen.shoes/embedVideo?video=https://valve-software.com/videos/Chainsaw_Man_OP_AV1_8MB.webm&image=https://i.dailymail.co.uk/i/pix/2014/06/14/article-2657825-1EC067C600000578-213_634x423.jpg

this is extremely important.

for anime, I use -6 or -8

personally I'd just rather encode in 4:4:4

2 x time slower

and decode

you're using me=tesa

you don't care about encode time

I mean when I'm encoding anime I generally expect it to be played back on a desktop, not on a phone

so 4:4:4 works fine

this does not mean that I am wasteful, but still mostly I use ESA

if your users can't play back 4:4:4 then i see

but if they can it's better to just use 4:4:4

esa is also pretty wasteful

what I typically use is something like

I just noticed that UMH is just shit, it's just forbidden to use it for anything with a resolution lower than 1080p

UMH is not shit

I typically use `preset=veryslow bf=16 aq-mode=3 aq-strength=0.8 qcomp=0.7 chroma-qp-offset=-2` as my base settings

but I also encode in 4:4:4

also depdending on content I often use `deblock=-1:-1 psy-rd=0.8:0.0`

ok. and i Only use qp (aka cqp aka cq)

but I also typically target crf=16

since I don't see the point of forcing qcomp=1

aq-mode aq-strength qcomp also shit

?????

do you even know what those settings do

those are tunable parameters

you can't say "qcomp is shit" that's like saying "me_mode is shit"

I absolutely don't like how these outdated motion compression algorithms work. disgusting

??????

you're not making any sense

none of those have anything to do with motion compensation

Maybe we won't get along

??????

I'm not saying you're *wrong* I'm saying you're *not making sense*

qcomp is a tunable parameter, it's the name of a setting

you can't say "qcomp is shit"

<@853026420792360980> how does QP differ from CRF?

that doesnt' make any sense

CQP always picks the same quantization parameter regardless of whether those bits are actually needed

it stands for "constant quantization parameter"

and CQP not use all this algorithms aq-mode aq-strength qcomp

on the other hand, CBR always discards the extra bits, regardless of whether those bits are actually needed

CRF or "cosntant rate factor" uses a psychovisual model to determine whether those bits are needed or not

CBR is full bullshit

it's for streaming and nothing else

`qcomp=0` ends up working exactly like `CBR`, i.e. the extra bits are considered never necessary `qcomp=1` ends up working exactly like `CQP`, i.e. the extra bits are considered always necessary

CRF controls that decision according to the qcomp curve

I streamed on twitch via FFMPEG CQP with bitrate from 100 to 10000 kbps

k

bad idea

WHY do I need to have a 6000 bitrate on a static monitor frame

networking reasons mostly

if the bitrate drops it causes latency when it rises again

This is complete bullshit, your life is a lie

that's pretty rude considering twitch has a whole article explaining the concept

https://help.twitch.tv/s/article/broadcast-guidelines

"A higher bitrate takes up more of your available internet bandwidth"

read the section on CBR vs VBR

the one right below that

it's not for video quality reasons but rather for the reality of streaming video over a network

wait, but there's just a lie written there

lowering the bitrate has absolutely no effect on anything or where

k

I'm sure twitch publishes articles recommending people increase their momentary bitrate which causes them to have higher overhead intentionally just to screw with people and themselves

<:thonk:853085643092918283>

this is called capitalism

yea and companies always increase their own overhead for capitalism reasons <:holyfuck:941472932654362676>

youtube takes your stream and compresses it into a variable bitrate regardless of whether you want it or not

because youtube does not stream live

what

twitch doesn't re-encode your stream

youtube does

your argument that twitch recommends suboptimal settings for "capitalism" reasons just doesn't make sense

this conversation is pointless it's like I'm talking to a wall I explain, cite sources, and you just tell me I'm lying

well they raise costs from scratch

well, of course, because you have never stream CQP variable bitrate on twitch

take FFMPEG and do it, because after that I absolutely do not understand why someone on the Internet is still using CBR. We're not on TV

CBR is more predictable and stable for the network, also if there are any lags, the buffering or frame drops will be more consistent VBR for streaming is useful maybe to save some traffic or VODs size, but since most platforms have upper bitrate cap, it makes little sense to save it on static scenes, besides CBR is usually not pure CBR, the bitrate also changes, just these changes are smaller

I don't understand at all what "stable for the network" means

I'm not suggesting VBR, I'm suggesting CQP, which means that in active scenes and games there will be a bitrate like CBR, but in all other frames the bitrate will be much lower

by the way, even youtube sometimes has very large bitrate peaks (given that it is already transcoded video), which cause lags for many users, e.g. ```Woooow, 6:25 at 4k even now caused my ~250 Mbps connection to buffer... interesting! 🤔``` https://youtu.be/Zc-rZkrSD5E?t=385

4k in youtube is 8 mbps

and yes, the noise. and why? no codec can cope with this, AV1 smooths everything into flat and draws artificial noise if desired

I didn't really understand what the point of the test was, just to increase random entropy

I didn't have any problems downloading on my 20 mbit internet, but my processor just doesn't pull more than 1080p vp9 so I can't say anything. Of course, I can only say that this test is meaningless, and whatever such stupidest tests are done, AV1 Will smooth out all the noise into a flat.

to compress 500.000 images generated by a neural network, I used this function: ```avifenc --min 30 --max 32 -s 1 -y 420 -r f -d 10 -c aom 1.png 1.avif```

Most video codecs don't seem to support grayscale mode (4:0:0). Why is that? Grayscale is done just by omitting Cb and Cr channels, there's nothing special about it. AVC and AV1 do support grayscale mode. There are use cases that could take advantage of grayscale encoding, like recordings from security cameras or transfers of black and white movies.

Or using it to encode extra channels like alpha

I guess that is the case in AVIF.

And HEIC

HEVC seems to support grayscale too, so there are total 3 video codecs supporting 4:0:0

Still not necessarily all implementations support it, e.g. I think svt-av1 is still limited to 4:2:0, so can't use it to make images with alpha (or 4:4:4 for that matter).

That's kinda lame, 4:2:0 decoder should be able to decode 4:0:0 as well.

how strong is the difference between 4:0:0 and 4:2:0 for a black and white image?

Empty Cr and Cb won't reduce to nothing, there's always some overhead.

considering that there will be one zero values on the C band Cr channels, blocks of 0-2 bytes of information

Decoding should be faster too, the decoder could skip the color transformation.

They do however.

I've tested several codecs available in ffmpeg: MPEG1, MPEG2, XviD, h263, VP8, VP9, WMV1, WMV2, those all converted grayscale to 4:2:0. Only AVC, AV1 and HEVC preserved grayscale.

depends on what you're counting and what you aren't counting

almost all lossless codecs, such as ffv1, support it

Haven't looked into lossless yet, actually. I'd suppose lossless should be bit exact, so no conversion should take place there.

Alright, ffv1 is indeed bit exact as expected. So it of course preserves the grayscale pixel format. One more thing I've observed, the file encoded in ffv1 is quite a bit smaller than my optimized PNG.

that's because ffv1 is pretty good

avc fasted of all this

Old codecs ≠ fast

vp9 is completely ineffective And vp8 is shit

ffv1 beat lossless webp as well, in both speed and file size.

> Sisvel, a Luxembourg-based company, has formed a patent pool, and are selling a patent license for AV1. The pool was announced in early 2019,[210] but a list of claimed patents was first published on 10 March 2020.[211] This list contains over 1050 patents.[211] The substance of the patent claims remains to be challenged.[212] Sisvel has stated that they won't seek content royalties, but their license makes no exemption for software.[211][212] > > As of March 2020, the Alliance for Open Media has not responded to the list of patent claims. Their statement after Sisvel's initial announcement reiterated the commitment to their royalty-free patent license and made mention of the "AOMedia patent defense program to help protect AV1 ecosystem participants in the event of patent claims", but did not mention the Sisvel claim by name.[213] (https://en.wikipedia.org/wiki/AV1#Patent_claims)

> According to The WebM Project, Google does not plan to alter their current or upcoming usage plans of AV1 even though they are aware of the patent pool, and third parties cannot be stopped from demanding licensing fees from any technology that is open-source, royalty-free, and/or free-of-charge.[214] > On July 7, 2022, it was revealed that the European Union's antitrust regulators had opened an investigation into AOM and its licensing policy. It said this action may be restricting the innovators' ability to compete with the AV1 technical specification, and also eliminate incentives for them to innovate.[215] > "The Commission has information that AOM and its members may be imposing licensing terms (mandatory royalty-free cross licensing) on innovators that were not a part of AOM at the time of the creation of the AV1 technical, but whose patents are deemed essential to (its) technical specifications"

I hope the EU is not going to mess with AOM's licensing terms, because that's one of the things they do get right: not allowing patent-encumbered contributions and defensive patents to deter patent trolls.

although *if* patented technologies are critical to AV1's technical specification and those patented technologies were invented by people who were not members of AOM at the time, that's a big screwup on the AOM's part

That is also true - at least if it's not a bogus patent we're talking about here

It's also antitrust, which has nothing to do with patents. Doesn't even the suggestion of monopoly go against the ideals of AOM?

monopolistic abuse of the weak and just patent-moneys collecting entities by releasing widely-used and nice open-source code with the license which auto-terminates upon patent threats?

for these people patent extortion probably feels like a natural right

https://discord.com/channels/794206087879852103/840831132009365514/1040212331323478066 I conducted tests and found out that JPEG XL in q90 quality at e3 speed is very much ahead of Jpeg XR

on q80 at e3, it produces very qualities indistinguishable from the original <:Thonk:805904896879493180>

Butteraugli is good work

sigh, we are getting reports that Safari fails to decode some images when encoded in WebP or JPEG 2000 (while most webp and j2k images decode just fine)

and AVIF hasn't landed yet in most Safari users (requires the most recent OS version)

so Safari is basically back to JPEG only, if we cannot figure out how to predict whether a given webp/j2k image will decode or not

we as in cloudinary?

yeah, but I guess the same applies for anyone

bugs like this are very annoying because safari does signal that it supports webp and j2k, and 99.9% of the time it does, but then there are 0.1% of images where all you get is a broken image icon

And it's not smart enough to fall back when you use the <picture> tag?

Haven't tried, but we use content negotiation, since we don't control the html

<@794205442175402004> about hw avif encoders, maybe ask Cloudinary to get an Intel Arc A310/A380 for comparisons, this is the cheapest option, but all models have the same encoder (and most likely server versions) and it seems that at the moment this is the best quality hw encoder Intel is very popular in cloud solutions and most likely a similar encoder will be widely used, so this will be the rough hw avif quality (or single-frame av1, at least)

Cloudinary does nearly all processing on AWS, we don't have any on premise infrastructure

let me check if AWS has instances like that

https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing

looks like their GPU instances are mostly NVIDIA and mostly aimed at deep learning stuff

nvidia hw av1 has slightly worse quality at the moment (amd encoders most likely too, they have not been released yet), av1 is still very new and hw encoders are only available in the latest gen or will only be available in the next, for example for intel CPUs with apu they are mostly used for video transcoding (also hybrid methods with apu), for images I think with older formats no such need yet, but for avif theoretically it will be possible intel arc is the cheapest av1 encoder available (~100 usd) with the highest quality, i mean it could be used as an example of hw avif encoders for comparison (because others would be about the same or slightly worse)

why are so many image codecs based on video codecs?

Because a lot of research is happening in video codecs and there's always this temptation to say "oh, an image is just a single-frame video so let's get two for one and define an image format based on this video codec"

sounds like a terrible idea, but thanks for answering my question <:PepeOK:805388754545934396>

Maybe MIDI should be a really short WAV? 🤔

It's a bit like designing a race car and then trying to use it as a tractor. Superficially it makes sense since both are vehicles with four wheels and a combustion engine, but in practice, it doesn't work very well. And then when you come with an actual tractor and demonstrate how its big wheels and torque can prevent it from getting stuck in the mud and allows it to work on difficult terrain, they will insist on putting it on a race track to see how fast it can go.

FFV1 has much better compression than PNG, it can do all kinds of pixel formats and it's fast. I had a fun idea that FFIF could be a thing.

FLIF -n (non-interlaced) is basically that

Ah I see.

and modular jxl is basically a superset of a tiled version of FLIF -n with the CABAC replaced by rANS (so faster to decode)

Alright, so my imagination was actually real.

Thanks for explanation.

<:garfieldsurprised:823250154319773727>

Is it true that jpeg2000 is still used for storing sources in film production?

It's used for digital cinema packages, basically a movie you see in a movie theatre is a hard drive with intra-only j2k.

Video codecs are not used for digital cinema afaik. Nobody wants inter artifacts on the big screen...

Does it support HDR? Jpeg2000 edit: yes

Yes, but I mean archival storage of sources

J2K even goes up to 38-bit, which is kind of a crazy inconvenient number

No idea but I would assume so.

I was also able to watch this file firsthand in the cinema, it size be 200 gigabytes

Obviously more than bd

It's interesting, if use av1 for movies, then it's quite possible to go back to dvd<:KekDog:805390049033191445>

Will jxl replace jpeg2000 for cinema? 🤔

I kind of doubt it. Why update all their existing systems just to get better compression? It's one hard drive per movie now, it will be one hard drive per movie with jxl too. Why bother?

What if I future 8k comes to theatres and need new systems for 8k playback? Won't they need higher compression?

they'll just get bigger drives

which already exist

I think j2k filled that niche because jpeg couldn't do the bit depth they need there. Same for medical.

Better compression is nice in both cases but probably not a game changer and probably not really something you'd want to break interoperability with existing systems for...

perhaps wavelet compression is also less affected by unexpected visible artifacts for high fidelity

<:monkaMega:809252622900789269> https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/AOM-Statement.pdf ```“Qualcomm is a leader in foundational video compression technology. For over 20 years, we have invented technology widely used in video codecs implemented and used by devices and content services. Our patent portfolio is used in multiple codecs and includes standard essential patents to H.265/HEVC, H.266/VVC, and MPEG-5/EVC video coding standards, as well as the proprietary VP9 and AV1 video codecs. Regarding the Alliance for Open Media (AOM) Patent License 1.0, Qualcomm has not accepted the unilateral terms asserted by AOM with respect to Qualcomm’s intellectual property and has notified AOM of this position. Qualcomm reserves all its intellectual property rights, including with respect to the use of any of Qualcomm’s patented technology to implement any AOM specification.”```

Oh boy

Why are video codecs such a patent minefield

that's a really good question. why are video codecs so riddled with patents, but not less so for images or audios?

because that's qualcomm's business model

(there *are* of course patented image formats or audio formats, but eventually they somehow died off)

One thing is that there are 'good enough' royalty-free image formats available

complexity probably, also most research is sponsored for video codecs since improving their efficiency has the biggest impact on reducing overall traffic consumption

Video compression has big impact for a relatively small number of big players (youtube, netflix, broadcast companies etc). Image compression has smaller impact for a relatively large number of players.

The median web page has 1 mb worth of images and zero videos.

But overall bandwidth for video is probably larger than for images (no idea though, tbh)

Anyway there's more "concentration" (of companies making profits off of the technology) in videoland than in imageland, and concentration in capitalism generally leads to more ethically questionable behavior like patent trolling.

At least that's my take on it

Isn't Qualcomm releasing a SoC with AV1 decode like, really soon?

If they're openly admitting to not agreeing to AOM's license, aren't they straight up saying "yeah we're violating the patents for AV1 held by every AOM member"

yeah, that's the statement after they announce av1 hw decoder about traffic ```Cisco recently declared that by 2022, online videos will make up more than 82 per cent of all consumer internet traffic — 15 times higher than it was in 2017``` but there are also tv, satellite and other where bandwidth and storage has a cost

ohhh boy that's going to be fun

https://tenor.com/view/movie-night-movie-time-pop-corn-eat-intense-gif-17272497

I wonder how this is even possible. Did they not agree to the terms even before AV1 was created?

Oh. Qualcomm is not an AOM member...

Is there anything in AV1 that Qualcomm actually holds patents on? I would expect AOM to have avoided anything patent-encumbered unless the patents are held by AOM members...

https://www.reddit.com/r/AV1/comments/yxrpes/qualcomm_announces_av1_chipset_while_at_the_same/iwqak6z/

So as long as Qualcomm doesn't start litigating, they still get to use AOM's defensive patents

The problem is that they might not even need to litigate to get smaller players to not "risk it", or to extort them into paying them royalties...

I doubt they have any patents on any software. It's likely they took out a patent on their hardware encoding so that they can resell it to other vendors. I doubt it's a big issue.

I suspect it's not particularly hard to accidentally use something that is patented (but I don't really know that, of course)

it takes lawyers and judges to determine if doing something constitutes infringement on a patent, and even if you don't infringe or if the patent was bogus to begin with, it can be quite costly to defend — this is why patent trolls can actually get paid even when their victims know for sure that they're not infringing on any valid patents, it's cheaper/easier to pay a troll a few thousand $ than it is to pay tens or hundreds of thousands of $ in lawyers and legal fees and maybe get the patent invalidated (or maybe not, depending on the judge)...

Yes, but it decodes quite slowly without any HW decoding.

i think video formats have a lot of similarities, but not to be an exact copy for something patented they try to change in some way and the differences may not be enough i remember when after google bought on2 the first revisions of the vp* source code had a lot of copied code directly from x264, there were also golden frames because b-frames had patents or something like that

this sort of bullshit brings forth my hate for capitalism at full force... fucking patents on mathematical algorithms... charging people to use algorithms they somehow "own"... oh well sorry for the mini vent

<:PepeGlasses:878298516965982308> ALIFE

heh

Crafty font

<:PeepoDiamondSword:805394101340078092>

<@823713976780193863> I'm not really on a side on this issue, I feel like their are shades of grey like on 1 side you have things that have been around forever and trying to patent them is absurd, however on the other side you have things like the Unreal Engine. I feel the the line the separates the 2 that you have to cross would be if the articulate the exact nuance or discovery for that piece of the engine that makes it run faster for instance take a look at: FISR(Fast inverse square root) used in Quake 3 engine; The algorithm was often misattributed to John Carmack, but in fact the code is based on an unpublished paper by William Kahan and K.C. Ng circulated in May 1986. The original constant was produced from a collaboration between Cleve Moler and Gregory Walsh, while they worked for Ardent Computing in the late 1980s. but if FISR actually was patented actual engineers or companies who paid them to design a piece of software would fall into the category of patentable. but only on that specific piece of their software. but yes on the other side of the spectrum you have idiots trying to patent the generic idea of websites that look like ebay. Maybe I need to find a better example of a piece of software that does deserve patent protection, sorry this is the only instance I can recall off the top of my head. and no one that wrote it was even payed for it.

https://css-ig.net/wavif

looks like it's by the pingo guy

but it's windows only and not open-source

Ah Windows only

On en wikipedia i wrote the name of the author

But poor grammar and not specified the operative operating system

I mean there's no source available and only a binary for windows

but you could run it through wine probably

but it's still windows only

es wikipedia?

isn't `es` spanish?

eg. `es_MX`

who's behind pingo? is (presumably) he active in other venues?

I don't know, I just know that this is that person's website

En Wikipedia

Grammar is not there. Plus I didn't describe OS

PNG in phone sometimes weight much. This on

I'm sending is 2.8MB

It also likely just uses an existing encoder. Considering they are, they are currently breaking license terms.

nm time

according to `strings` it statically links libaom

and the author didn't provide the disclaimer required by the license

it also statically links in LodePNG without attribution but that's permitted by the license

LodePNG allows you to link it without attribution, but not with misattribution

to be fair it's an extremely common kind of (unintentional) license violation

use compare -verbose

is there alpha?

one of the channels could be modified if the alpha channel is zero at that point

since it's transparent anyway

well if alpha is 100% everywhere it shouldn't affect compare

just if it's 0% somewhere

is the original 16-bit, maybe?

cwebp will just encode that as 8-bit then

while cjxl will encode it as 16-bit

that would also explain the size difference. Those 8 least significant bits are hardest to compress since they're more noisy than the 8 most significant bits.

Is there an option in cjxl to encode files in 8bit? It would be useful for some cases

`--bits_per_sample=8`

actually wait

that's a djxl option

for `cjxl` I don't believe you can change the tagged bit depth on encoding

mpv outputs 16-bit jxls always because the buffer is 16-bit

the bit depth for jxl is just a tag though, you can decode to any depth you want

nothing internally changes

in cjxl it is `--override_bitdepth`

for xyb/lossy that is true. For lossless this is not true though 🙂

right, probably should include the tag in the mpv wrapper in case distance=0

Is there a reason why lossless webp beats lossless avif?

Lossless webp is a special-designed codec, since vp8 cannot do lossless.

Lossless avif is just av1, which can do lossless but is not particularly designed to be good at it, especially for still images.

Where can I find more info on lossless webp? Can ffvp8 decode it?

Hmm, I found some info

Lossless avif same lossless jpeg

An image is drawn from the coefficients, then it tries to compress without rounding

name is VP8L, technically it's not vp8

The same separate algorithm as modular in jpeg xl

the SAME algorithm?

Lossless AVIF works in similar way like JPEG at quality 100% , so it's pretty inefficient. VP8L is its own thing. VP8L is also used for alpha channel in lossy WebP.

it's not VP8, so no. but FFmpeg has an internal webp decoder which can

it's not the same thing as modular in JXL, since modular in JXL comes from FUIF, not from PIC

however you could probably get more info from Jyrki as he was on the team that invented lossless webp

modular jxl is a combination of elements from fuif, pik, lossless webp, and some new stuff

in webp, lossy mode and lossless mode are completely separate things, they are unrelated except that they both use the same container and name

in jxl, modular can be used on its own (which is how we do lossless), but it's also a component that is used in the vardct mode: only the high frequency coefficients are encoded in a special way, all the other image data is encoded using modular sub-bitstreams.

This includes the LF image (the "DC coefficients", except it's also some of the AC when using bigger blocks), the block selection and adaptive quantization parameters, raw quantization tables, the chroma from luma multipliers, the EPF filter strengths, and any extra channels like alpha.

same in the sense that separate inside one format...

WEBP JPEG XL OPUS they all have 2 completely different compression methods for large task coverage

opus music overall sounds better than opus voice from my tests lol, even at high opus voice quality

though I only did my tests in teamspeak 3

the voice codec is not used after the 64 kbit bitrate

interesting

to get the maximum, according to my tests, this bitrate is exactly 43

wonder what teamspeak is doing then, where I can switch between voice and music, and lower the quality of either one down quite a lot

for both music and sound, the only problem is that it is only for full good compression, with a delay of 1 second and at maximum settings

and both sound different at all levels

for voice programs, you need to make spec settings, and it is desirable that it would be possible to select Only the voice codec there. I note that music codec at bitrates below 50 is extremely bad for the voice

in any case, it will be better than anyone another codec can offer

What I dislike about CELT is, it was designed for low-delay at the expense of quality. Even in situations where the low-delay aspect is not required or useful, like storing a music collection.

The quality suffers particularly with harpsichord music, my favorite instrument

And the patch that was supposed to improve this, did not entirely fix the problem. It's still noticeably bad at achieving transparency with harpsichord

At least to my ears. And yes I have ABX tested this with the latest version of libopus

Harpsichord recordings sound unnaturally scratchy.

And this is due to the low-delay nature of the codec

If you're using opusenc to encode a file for storage and playback, the low delay design is completely useless and counterproductive

Is it possible to disable celt when encoding?

No. Lossless AV1 is its own thing, and uses a special transform.

No, it was designed to be able to be low delay and high quality at the same time. You can make CELT combine frames together and try to do better prediction with higher delay, but it won't help. What is missing here are better tonal optimizations.

<@794205442175402004> The AVIF folks are getting desperate <:KekDog:805390049033191445> `[WG-Storage-and-Transport] [avif] Slides for alternative bit depth extension approach` Imagine something like Dolby Vision Enhancement Layers, but for AVIF. Might as well use an image format that doesn't need it if you have to do sketchy stuff like this 🙂

What is this? 16-bit avif?

Essentially yes.

If they're going to do it by doing, say, two 8-bit av1 streams, one for the high bits and one for the low, compression will likely be horrible

This seems to be something they're just doing to be able to claim feature parity, not because it would be useful in any way

I think that's how they want to do it, yes. https://github.com/AOMediaCodec/libavif/pull/1215

yeah, there are also many experimental extensions for the current standard/encoder https://github.com/AOMediaCodec/libavif/pull/1222

https://github.com/AOMediaCodec/libavif/pull/999

I don't really believe in extensions

Why not add that into AVIF2? Why keep adding experimental junk into AVIF? There is plenty they could add into or fix now that could make current AVIF more useble for the wider web, yet they are focusing on extra stuff that's not supported by the spec?

because if avif2 is released anywhere within 10 years it's gonna be as DOA as webp2

too many formats

we still need to phase out bmp and webp

what we really need to phase out is gif lol

idk about webp tbh, i do like using it for lossless compression only and so it can embed in discord

No, no, this is not a task, but an opportunity. Celp is the best codec for compressing music, it just can't be used below the bitrate of 64. And the recommendations are written from 96 to 128.

Actually, I don't understand why you decided this, but when encoding for storage, the delay is the maximum possible, it's 1 second. Sound predictions for 50 packets ahead

It doesn't make sense

Oh

Ahahaha We don't even use av1 everywhere to say av2

WHY?

99% of the sound you hear anywhere in opus format is celp

🤔

Another SILK Very specific for - for voice at low bitrates

But it is much more important that slik is 3-5 times slower than celp. Therefore, if it can not be used. It is not used. For example YouTube.

For more than 5 years, all videos on YouTube are opus celp 128kbps

that's for sure, but the web still hasn't agreed on a standard to replace it. so it will "have" to stick around until then.

apng is, for practical web purposes, dead

if only it didn't also have a lossy mode that doesn't suck

or to just be a lossless only format

All I know is that at default settings and at 128kbps, harpsichord is not transparent with latest opusenc

https://people.xiph.org/~xiphmont/demo/opus/demo3.shtml

> Opus is a low-delay codec, and uses a shorter MDCT window than non-realtime audio codecs such as Vorbis or AAC. A short MDCT window has higher spectral energy leakage between bins, and this leakage decreases coding efficiency for strong tones. Samples that contain strong tones with a large number of harmonics that stand well above the noise floor are thus especially difficult. > > In addition, typical bit allocation schemes (such as used by Opus) reduce the precision of high-frequency bands, a strategy appropriate for the vast majority of audio. If the precision drops too low however, strong harmonics in the upper frequency bands wash out into an indistinct, fuzzy hiss.

That's their explanation for why.

The 1.1 update and subsequent updates did not fix the problem.

Hah, no, it's quite transparent. But according to my tests. For maximum audiophiles. I recommend exactly 141

I have no idea what is meant here. Opus uses a packet size of 20 ms. As well as mp3, and aac, and vorbis.

The only thing I discovered is that at a bitrate of 8 kbps, at a frequency of 4000 hz, vorbis is better than opus/aac/mp4

https://cdn.discordapp.com/attachments/308921309893623820/1003957967349096578/DZgas_music_tracklist.webm

vorbis on these parameters is ahead of all codecs in general that I could reach, it sounds very good compared to opus on the same bitrate. And yet I'm not an audiophile. Therefore, I have been using opus 128-141 for my entire collection for 5 years without exception

https://wiki.xiph.org/Opus_Recommended_Settings

The only thing I can say is that I noticed that opus has less accuracy in the lower frequency range, although other formats on the contrary give them so many bits

lower freqs are carrying less information

at least that's the idea

According to latest activity in the Opus codec repository (https://gitlab.xiph.org/xiph/opus/-/commits/exp_neural_fec3/), some significant improvements for low bitrates based on the https://arxiv.org/abs/1905.04628 are in development.

https://arxiv.org/abs/2212.04453

It is more likely to be a nn for packet loss correction `In this work, we propose a deep redundancy (DRED) mechanism based on speech coding techniques specifically optimized for coding redundant audio information`

I tried ABXing the harpsichord sample they had on the opus 1.1 demo page

Maybe it's transparent for everything else but not harpsichord

it's a lot harder to produce *hearable* artifacts in the bass range which is why it's prunned harder.

I don't agree, old codecs like MP3 put a lot more information into low frequencies than was necessary

https://audiocoding.ru/articles/2019-06-24-best-lossy-codecs-june-2019/diff.svg

I'm not sure that this is important, but it's just the fact that OPUS use the least quality into low frequencies compared to others, and this is directly related to the works of the codec itself

this is a test on bitrate 200, and it also shows that all codecs on this bitrate give almost identical quality, "within the margin of error", (also look attention to the fact that the graph is logorithmic)

I have no clue what both axis say.

I also have no clue how it follows that mp3 wasting bits in the bass means I am somehow incorrect.