[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology

Name
Options
Comment
Verification
4chan Pass users can bypass this verification. [Learn More] [Login]
File
  • Please read the Rules and FAQ before posting.
  • You may highlight syntax and preserve whitespace by using [code] tags.

08/21/20New boards added: /vrpg/, /vmg/, /vst/ and /vm/
05/04/17New trial board added: /bant/ - International/Random
10/04/16New board for 4chan Pass users: /vip/ - Very Important Posts
[Hide] [Show All]


[Advertise on 4chan]


File: ssimnorm-vs-crf-value.png (71 KB, 1254x800)
71 KB PNG
All these Dalit threads on AV1 are shitting me off, so I wasted hours of my time to make this script for the BRAHMAs out there. It targets SSIM, only 1 input video file per folder though.

@echo off & mkdir temp
:loop
set /p crf="CRF? (30-50 reccomended): "
for %%f in (*.mkv, *.mp4, *.mov) do (
ffmpeg -i "%%f" -c:v libsvtav1 ^
-crf %crf% -preset 4 -pix_fmt yuv420p10le -svtav1-params ^
keyint=2s:lookahead=120:tune=0:enable-variance-boost=1:variance-boost-strength=3:variance-octile=4 ^
-c:a libopus -b:a 64k -y "%%f_CRF-%crf%_AV1.webm"

echo: & echo SSIM result:
ffmpeg -hide_banner -loglevel error -i "%%f" -c:v libx264 -pix_fmt yuv420p10le ^
-preset ultrafast -crf 0 -y temp/temp_source_2_10b.mkv
ffmpeg -hide_banner -i "%%f_CRF-%crf%_AV1.webm" -i temp/temp_source_2_10b.mkv ^
-lavfi ssim -f null - 2>&1 | findstr "[Parsed_ssim"
echo:
)
goto loop


1 problem: AV1 cheats in SSIM. It intelligently preserves the structure of video but destroys fine detail. However these disable SSIM cheating:
tune=0 Prioritizes perceptual/visual quality
enable-variance-boost=1
allocates more bits to low-contrast areas (such as skin, clouds, or foggy scenes) that typically suffer from blurring and artifacting in fixed-quantization encoding.
variance-boost-strength=3
Applies medium strength variance boost, enough to improve quality but not bloat bitrate.
variance-octile=4
Applies medium strength for the new 8x8 variance algorithm, which is used for adaptive quantization.

All of these not only give you better/accurate SSIM scores but allow AV1 to create subjectively medium to high quality AV1 encodes, not just compete in objective metric pissing contests.

Now that there's a place to post AV1 videos, I'll post them directly on https://umigalaxy.com/explore/general/494
>>
File: Nobara Kugisaki.png (802 KB, 1920x1080)
802 KB PNG
Now comes the hard part: What SSIM score should a "high quality" and "medium quality" video have? At launch AV1 prioritized low quality at very low bitrates. With new parameters that's not the case anymore.
Thus my OP image to get a rough idea because we do have 2 data points universally agreed upon:
1. CRF 18-20 x264 encodes are the golden standard for visually lossless video. 99% of people cannot tell the original and lossy video apart. 0.99 SSIM common here.
2. x264 encodes using a CRF above 30 look like ass, no reputable encoding group has ever actively advocated for anyone to use an x264 CRF above 30.

Ignoring the difficult case x264 results, the average SSIM for a CRF 30 x264 encode is about 0.97 SSIM so I think this should be labeled as "medium quality".
High quality is going to be somewhere between CRF 30 and 18, (30+18)/2= CRF 24. I don't know if it subjectively fits well but for testing purposes today I'll assume 0.98 SSIM is "high quality".

Of course this thread wouldn't be complete without video encodes so I've thought of a fun little scavenger hunt, on /wsg/ there's an abundance of Dalits uploading bloated H.264 MP4 videos.
So if you want, help me find them, they'll usually have stupid high bitrates of 2-4 Mbps despite being lowres. Then my script can be used to find a high quality 0.98 SSIM encode from that.

Here's the first Dalit H264 encode: 7.3 Mbps for 720p 60 FPS >>>/wsg/6145313
umigalaxy 0.98 SSIM AV1 rip: 1.1 Mbps with CRF 60 + Preset 4 used or ~85% smaller filesize https://media.umigalaxy.com/general/1778717601906.webm

BTW I forgot to mention that x264 and SVT-AV1 CRF scales are completely incompatible with each other, so keep that in mind.
>>
I have no idea what any of this means.
>>
>>108817945
op is the epitome of "half-knowledge is worse than ignorance". so you should consider yourself lucky, as you still come on top.
>>
Retard here. Handbrake has these settings in all of it's AV1 presets, are they any good?
enable-variance-boost=1
enable-qm=1
ac-bias=1
tf-strength=1
qp-scale-compress-strength=1
sharpness=1
keyint=10s
>>
File: leaf-test-image_proc.jpg (665 KB, 1920x1080)
665 KB JPG
>>108817969
In dumbed down terms what did he get wrong though? All I really understand is that variance boost is supposed to be a big deal.

https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Appendix-Variance-Boost.md
>>
>>108817969
OP here: are you gonna elaborate or just shamelessly troll?
>>
File: pixDAIZ is here.webm (94 KB, 360x270)
94 KB
94 KB WEBM
>>108817905
>>
>>108817945
>I have no idea what any of this means.
OP is an indian.
>>
Sorry I can't be bothered to take your thread seriously if you're going to start dropping those slop caste terms. The civilized world doesn't believe in them, sorry.
>>
I used handbrake to encode some anime in av1 and it looks better at half the bitrate than h264, so I use av1
>>
>>108817905
>At launch AV1 prioritized low quality at very low bitrates.
And that's how most people use it. Nobody uses libaom with psy tuning because it's slow as fuck. All SVT AV1 does is shit out ~x265 tier encodes with 10 times the computational decode complexity.

Anyone using AV1 for anything other than 8K VR is delusional, insane, or both.
>>
>>108818684
>All SVT AV1 does is shit out ~x265 tier encodes with 10 times the computational decode complexity.
...while also being royalty free and not a patent encumbered mess that barely works anywhere because of it
>Anyone using AV1 for anything other than 8K VR is delusional, insane, or both.
anyone using h265 for anything is a jew.
>>
File: 1777773296671.png (171 KB, 1080x1170)
171 KB PNG
>>108818684
>with 10 times the computational decode complexity.
Source? Even cheap phones seem to be able to decode it just fine now.

https://desuarchive.org/g/thread/108741354
>>
I tried making a 240 fps av1 video and my gpu % went to like 50

I guess it is a bit heavy to run
>>
>>108818684
None of that is true, are you being paid cash money by mpeg-la?

Anyway second Dalit H264 encode: 2.8 Mbps for 960x540 30 fps >>>/wsg/6147518
umigalaxy 0.98 SSIM AV1 rip: 1.6 Mbps with CRF 40 + Preset 4 (~43% smaller) https://media.umigalaxy.com/general/1778730256830.webm
>>
Encoding autism is a real decease
>>
File: images (4).jpg (16 KB, 529x580)
16 KB JPG
>>108818855
>"Nah bro, don't worry about using storage space more efficiently, crf 16 x264 all your shit and just wait for your 14TB HDD to randomly bite the dust and lose all your shit in one go bro!"

Anyway the real point of this thread is to just point out that AV1 can now do high quality encodes. Like it used to not be something you could do and now it is a thing you can do...
>>
Third Dalit H264 encode: 1.2 Mbps for 576x1024 30 fps >>>/wsg/6142111
umigalaxy 0.98 SSIM AV1 rip: 0.5 Mbps with CRF 60 + Preset 4 (~58% smaller) https://media.umigalaxy.com/general/1778733182907.webm
>>
File: 200.gif (807 KB, 200x200)
807 KB GIF
Fourth Dalit H264 encode: 1.3 Mbps for 1280x720 24 fps >>>/wsg/6136744
umigalaxy 0.99 SSIM AV1 rip: 0.3 Mbps with CRF 55 + Preset 4 (~77% smaller) https://media.umigalaxy.com/general/1778739998519.webm
>>
Use case for lossy-to-lossy encoding?
You lose quality and in exchange you get... what?
>>
>>108819545
You move upward in Indian caste.
>>
Which AV1 encoder isn't pure shit though? Is svt it?
>>
>>108819545
A massive reduction in wasted space. Some x264 rips really are that terrible, probably anons just punching in random bitrates in the encoder even though CRF mode exists.

Good x264 rips (ie CRF ~24) can't be compressed further though, AV1 will often require higher bitrates to achieve 0.98 SSIM. Those should be left alone.
>>
>>108819562
So is crf 18 placebo then?
>>
File: images (12).jpg (36 KB, 495x619)
36 KB JPG
>>108819561
For the most part yeah. You might be able to squeeze out another 5-10% better quality with AOM but SVT-AV1 is faster to encode.

The problem is it cheats in SSIM, which can now be fixed with variance boost/tune 0. Or use something other than SSIM, your call.
>>
>>108819571
Yup, at least to us humans, the tiny specs of detail being preserved at low x264 CRF values like that just don't register. That's why objective metrics like SSIM were created.
>>
>>108818709
Alright, freetard. Tard because the patents are literally only a fucking problem to cucked GPL idiots like you.
>be on Windows
>install "non-free" LAVFilters or MS Store extension
>just WERKS
Macfags don't even have to do anything it just works out of the fucking box.
>>108818729
>decoding in a vacuum
Try with a device from 2 years ago - or try watching YouTube and watch the frames drop. It makes my craptop cry blood. I can't force the newest build of dav1d (another way your "benchmark" is misleading bullshit) in browser, and YouTube's own jeetbloat already makes the site alone gobble half my fucking CPU. AV1 --on YouTube-- decodes at like 15 FPS. I had to find some userscript to force VP9.
>>
>>108819545
Smaller video.
>>
File: av1 decode over time.png (16 KB, 601x403)
16 KB PNG
>>108819614
Youtube cryptomining your computer has nothing to do with AV1.
>>
>>108819562
If you consider higher quality as "wasted space", then why save it in the first place?
If the video is such garbage that you don't care about quality, why keep it?

Not storing slop makes more room for archiving good stuff in its original quality.
>>
>>108819660
I do genuinely appreciate the work the dav1d devs have done. I can actually watch 1080p60 AV1 on fucking Ivy Bridge now, provided I use MPV. And there's no grain synth.
I still won't use it for anything I encode myself, I have x265 settings that work fine and too much "set top" hardware from the early days of HEVC HW decode that isn't due for replacement any time soon.
>>
>>108819721
Why are you crying over a small hit in quality? If encode A reduces the "purity" of a video from 100 to 90 and encode B further drops it down to 80, it's still usable, especially for porn.

If people thought like this about things in real life they would be paying $2,000/month new car leases they couldn't afford instead of used cars.
>>
GPU AV1 is worse than GPU HVEC
>>
>>108819746
And? Encoding video with a GPU is AIDS. Why are you surprised? Did you really think you could get good compression efficiency at 300 FPS encode speed?
>>
>>108819746
And then there's AMD RDNA/RDNA2 HEVC somehow being worse than Sandy Bridge QSV AVC kek
>>
>>108819739
Why would i want lower quality if i can have the higher quality?
>>
>>108817526
>SSIM vs. CRF
Meaningless graph, at least make it SSIM vs. bitrate.
>temp/temp_source_2_10b.mkv
No need to create an intermediate file, just do:
ffmpeg -i distorted.ext -i reference.ext ... -lavfi [1:v]format=yuv420p10le[r];[0:v][r]ssim ... 

>AV1 cheats in SSIM
All visual quality metrics suck, more news at 11.
>>
>>108820729
I'm deliberately exposing CRF results because there's a lot of retards that believe "CRF 20 for x264 good! So CRF 20 for SVT-AV1 also good!". This whole legal dance of wits with mpeg la jewry was caused mass confusion with AV1.

The reason I converted the original to a lossless 10-bit (but compressed with x264) file is because comparing the original 8-bit H.264 sometimes yielded timing/corruption errors because anons here sometimes seem to fuck up video encodes (maybe using 2012 version of ffmpeg like 4chan devs lol?).

Most objective metrics are probably "trust me bro!" but once you add tune 0 and variance boost to AV1, it seems to mimic x264 output while keeping bitrates down.

AND! AND! I was able to prove here that AV1 can now do high quality encodes. If this were false then it should not be possible to recompress existing H264 rips without catastrophic amounts of artefacting. This is a real world use-case thing because not all H.264 rips out there are equal. That's a great thing for AV1 because now its use extends beyond blu-ray to AV1 rips, it can now be used to "repair" the internet of some H.264 bloat.
>>
OP here: keep in mind that that the reason I'm shilling tune0/variance boost is because I want to create a "fair" battlefield for SSIM results. You can forego these things if you prefer AV1s default supression of high frequency detail, it will lead to higher "compression" but this isn't something us autists like. Maybe you're not as autistic...
>>
>>108817526
>many words about av1
>graph has x264 and x265 (hevc)
huh?
>>
>>108821750
x264 and AV1 CRF values aren't compatible, see all of the examples I'm posting here. CRF 60 but SSIM 0.98? You can't do that with x264.
>>
>>108821781
ok but why would you post a graph comparing h264 with hevc if you’re autistically angry about av1?
who on earth encodes anything at fucking av1 crf60 for that matter? if you argue that its pratically visually lossless, using libsvtav1, then whatever methodology is clearly nonsense or it’s some cheaty file av1 does wildly better on. i wouldn’t believe it at crf40 - anybody with eyes can tell between crf32 and crf40.
>>
>>108819614
>be on Windows
>install "non-free" LAVFilters or MS Store extension
>just WERKS
https://arstechnica.com/gadgets/2025/11/hp-and-dell-disable-hevc-support-built-into-their-laptops-cpus/
yeah just werks, as long as you don't care about having working hw decode i guess...
it als doesn't change the fact that pretty much no streaming service will serve hevc to you for the same reason.
>>
>>108817969
/thread
>>
>>108821831
CRF VALUES BETWEEN x264 and SVT-AV1 ARE NOT COMPARABLE WITH EACH OTHER you dumb fuck
>>
>>108817945
Me neither.
How do I start learning about video compression and stuff
>>
>>108821856
What a homo response to this thread, jack shit to contribute. Just a #metoo parrot shit for brains that won't tell us why he agrees with the anon's statement about OP being a halfwit.
>>
>>108819759
>>108819787
most normies watching youtube are using gpu decoder and the gpu quality is ass
>>
I just use NVENC AV1
>>
>>108821962
Focus on GUI programs for now. Staxrip and ffprobe can do most of what's being discussed in the OP. Just make sure when encoding AV1 video you select svt-av1-spyex in the drop down menu as show in this umigalaxy thread:

https://umigalaxy.com/explore/general/275-i-made-a-video-tutorial-of-how-to-encode-av1

When you've wasted enough of your time on this autistic timesink of a shit ass "hobby", your next stop will be setting up ffmpeg and turning advanced svt-av1 parameters individually.
>>
>>108821992
>"Just buy a $5 non-stick pan from Temu bro, same thing as that 10 year old mirror polished cast iron skillet with 200 layers of avocado seasoning!"
>>
>>108822008
>ffprobe
FUCK, sorry, I meant FFMETRICS.
>>
>>108822026
You can't tell the difference in a double blind test
>>
>>108817969
this
>i downloaded an HVEC remux
>i converted it to VP9 two-pass, because that is more efficient
>AV1 is now a thing, so i converted the converted VP9 into an AV1, because this is more efficient
>AV2 is here now. I wrote a batch script to convert all my AV1 to AV2! Here are my benchmark results!
Anybody with no knowledge, would just keep the original format.
Anybody with knowledge, would keep the original format because he understands generational loss and knows that a reencode always has lower quality than the input

But OP? Well, look at those benchmark results i digged out from a Google advertisement paper and all those terms i heard! I am super smart and convert lossy-to-lossy the whole day!
>>
>>108822090
Maybe if the test screen is a fucking iPhone SE. Not all of us are Dalits, some of us have big 50 inch 4K TVs in our living rooms.

>>108822094
I'm not advocating that thought, I'm specifically talking about bloated, think CRF 18 x264 rips, converted to a high quality AV1 rip. Because no shit generational loss is a horrible thing that should be avoided as much as possible...

BUTT sometimes it's not so bad. Like for example do you truly want ALL your porn to be visually lossless? Are you that concerned about making sure every facial pore stays in perfect crisp/clear detail as it gets splattered with cum?
>>
>>108822094
>benchmark results i digged out from a Google advertisement paper
op tard is much worse than this. op picrel uses crf values in one dimension, and ssim for the other. op tard mentions that ssim is a shit metric, but continues to use it because..."reasons". but what's even funnier is the other dimension! crf is not an indicator of a single value of bitrate vs. quality, even within the same encoder, let a lone different encoders for different codecs.
all of this is just initial destructuring of picrel alone. this is why i don't bother with half-knowledge tards. because it's layers upon layers of ignorance in every sentence, all covered by a facade of technical talk.
>>
>>108821837
>it als doesn't change the fact that pretty much no streaming service will serve hevc to you for the same reason.
What are HBO Max and Netflix?
>HP and Dell
Two brands I haven't bought anything from in over a decade.
>>
File: sunflower_vmaf.png (54 KB, 1920x1080)
54 KB PNG
>>108821930
They aren't even directly comparable within their own format.
>>
>>108822424
You don't believe these deactivate SSIM cheating? I'm not saying SSIM is a bad metric, it's miles ahead of PSNR/MSE/etc BUTT AV1 cheats in SSIM. Make AV1 stop cheating with these parameters and now you get a usable non-inflated SSIM score!

Am I really wrong here?

tune=0:enable-variance-boost=1:variance-boost-strength=3:variance-octile=4
>>
>show a normie a pirated A: 10 V: 10 YIFY encode
>show a normie an AV1 downloaded from youtube, encoded by the creators of AV1
>the normie can't tell the difference
>he says that both look shit
>>
>show a normie an HEVC remux torrented from the worst tracker possible
>let the normie watch Netflix in comparison, in its highest served quality
>the normie says the remux looks much much better
>>
>>108821967
Some retard who takes months to discover encoding settings claims to know more about it than the creators of the codec.
>GOOGLE IS JUST USING AV1 WRONG
>GOOGLE DOESNT KNOW ABOUT THOSE SECRET SETTINGS THEY THEMSELVES MADE
>>
>>108822511
Google is literally secretly installing 4GB AI LLMs on people's computers through Chrome WITHOUT their consent. You'd have to be smoking crack to trust them. Cheating in metrics is not above them.

I'm no AV1 dev but early youtube AV1 encodes used to look like melted butter so I went out of my way to disable AV1 even though my computer could easily handle it...
>>
>>108822511
1. google isn't the only company that has worked on av1, that was the entire point of AOM, netflix and other streamslop services which serve way different content and have way different needs than google does have contributed just as much
2. google uses av1 to encode a bijillion videos everyday, with dedicated hardware encoding asics/fpgas, of course they cannot take full advantage of the codec they themselves made, they for sure aren't using libaom-av1 with slow presets and tweaked settings, have you ever seen a youtube av1 encode with film grain synthesis? of course not, for obvious reasons.
daiz is a complete fucking retard but your argument behind it makes even less sense than his schizofrenic post.
>>
>>108822570
Who the fuck is daiz and should I give a fuck? I can't keep up with all the eceleb cocksucking here on /g/.
>>
>>108822579
>Who the fuck is daiz
op.
>>
>>108822590
Very clarifying, eye opening even. Your post has sent shockwaves of immense information and I have gained an IQ point. You dick.
>>
>SSIM for moving images
RETARD ALERT
>>
>>108822653
Better than VMAF, purpose built by Netflix for low quality streaming slop. The next step up would be ssimulacra2 but that requires a threadripper and 128GB of RAM...

https://www.reddit.com/r/AV1/comments/1jpku0s/codec_encoder_comparison/
>>
>>108818709
I dont care about patents. I never paid anything to encode shit and AV1 doesnt change anything.
>>
File: 1716927520028.jpg (98 KB, 512x512)
98 KB JPG
>>108819559
saar why do u say go up caste is metric?
>>
>>108822787
You can think of AV1 as being against "you will own nothing and be happy". Same thing as using a stainless steel mixing bowl made in the US. Sure you could get the chink one and it would probably be functionally the same (ignoring the magnesium poisoning lol) but it just feels wrong, you know.
>>
>>108822787
see: >>108821837
you are still encoding your shit in a format that has a very uncertain future (it barely has a past/present) while av1 is most likely here to stay.
>>
>>108822590
pixDAIZ wouldn't be shitting on VMAF.
https://desuarchive.org/g/thread/99052673/#99055828
>>
>>108822834
in the future you talk about, the patent for h265 will have expired like h264 ones.
>>
File: 1769218992008951.jpg (101 KB, 1000x1400)
101 KB JPG
>>108822715
wtf I thought VVC was like 50% better than AV1...
>>
>>108822862
yeah sure, in like another decade or two
...why the fuck would platforms and users go back to using h265 by that point? av1 will already have way higher adoption at that point, and av3 will be releasing soon.
has the expiration of h264 patents increased its adoption rate relative to vp9/av1? don't think so... it might slow things down at best but av1 is still going to come on top eventually, especially as 4k adoption increases.
>>
>>108822834
>av1 is most likely here to stay
It's getting replaced as we speak, its successor is developed and it will die just how vp8 died.

When its about preservation, the library of congress accepts H264. They don't accept any of the Google formats, vp8, vp9, av1, none of them.
If you want something that will be here forever and that you can still watch in 50 years, then pic related are your options.
>>
>>108822919
>pic related are your options
>>
>>108822927
GOD DAM, what the fuck happened to the whole Department of Government Efficiency thing? Was that really just another distraction so people would stop asking about trump being involved with Epstein?
>>
>>108822919
>It's getting replaced as we speak, its successor is developed and it will die just how vp8 died.
...has vp9 died when av1 reached a good adoption rate?
nope it didn't, it's still widely used on youtube, netflix, and so on, vp8 died because it was dogshit, way worse efficiency than h264 and h264 licensing wasn't that big of an issue to make the trade off worthwile
not to mention... vp8 is still supported and used by lots of sites, browsers still have full support for it, and gpus/mobile SoCs still ship with hardware decode (often encode also) despite it being a very light codec to encode/decode in software... what's dead about it exactly? there's nothing preventing you from using it
>When its about preservation, the library of congress accepts H264
...so?
they don't accept h265 either so i really don't see your point, a regular consumer doesn't have such requirements, pretty much all major ffmpeg builds currently still ship vp 3-7 decoders even, you'll be long dead before av1 is "forgotten"
lots of devices are just barely getting av1 support now, the fact you seriously think they're going to phase it out as soon as av2 releases instead of being a fallback like vp9 was is truly beyond retardation.
>>
>>108822981
>...has vp9 died when av1 reached a good adoption rate?
VP8 died.
VP8 dies so fucking fast it's unreal. It's as if it never existed. It's gone.
>>
>>108822981
>they don't accept h265 either
But we know that they will accept it once its patents run out.

Because they already accept MPEG-2 stuff and H264. Both on the basis that they actually got used in original productions.
It is very likely that some footage may be available as MPEG-2 or H264 that isn't available in any other form another. DVB, DVD, BluRay,..

HEVC will be accepted in the future. We know that.
Meanwhile there is absolutely no reason to believe that AV1 will make it in if neither VP8 or VP9 made it and AV2 is on its way.

btw. jpeg-xl is accepted while avif is not
>>
>>108822991
Webp uses VP8 and currently ~20% of websites in the world use Webp. I'd say VP8 has another solid decade of life extension.

>>108823020
Of course AVIF isn't accepted because it requires hardware accelerated decoding, which virtually doesn't exist yet. You'd have to be a moron to adopt AVIF in it's current low-hardware support state.

Also you're forgetting that HEVC kike paptents won't expire for another gorrillion years and that VP9 vide has a lower decoding conplexity compared to AV1.

What's realistically going to happen is governments will move onto VP9 BEFORE they move to HEVC, because they need something to replace H264 RIGHT NOW.
>>
>>108823114
you are changing subject
>>
>>108822991
you could've read the rest of my comment, how the fuck is vp8 dead when it's still supported everywhere? no idea, but again, different scenario. you keep ignoring the fact that vp9 hasn't had the same fate and still haven't explained why av1 would be another vp8 rather than another vp9.
>>108823020
except mpeg-2 doesn't have any free equivalent/alternative and has been the native format lots of content was delivered in, same goes for h264 since vp8 was kind of ass compared to it.
vp9 is only like 10% less efficient than hevc, pretty much the same codec but completely free, why would they choose hevc? they give 0 fucks about storage requirements and i'm pretty sure they actually just store all of their video in lossless formats for this reason.
they moved from h264 (which is still excellent at lossless compression) to ffv1, there's no reason they're going to adopt hevc ever.
>btw. jpeg-xl is accepted while avif is not
...and? jpeg-xl isn't a proprietary format in case you didn't know...
why would they pick avif which sucks at lossless compression (the thing they use the most) and has no backwards compatibility with jpeg which they've already accepted for decades? you just blabber pointless stuff without any reasoning as to why that is relevant.
>>
File: download.png (117 KB, 1200x630)
117 KB PNG
>>108823135
Let's say you're right and HEVC gets accepted in the future instead of VP9. It would basically be an admission that the US government is actually being controlled by corporations.

THINK about picrel. People are paying FROM THEIR POCKET to own a computer and corporations can just wave a magic wand and disable parts of that computer making it clear that THEY OWN YOU.

If the US accepts HEVC, even after patents expire, what kind of message do you think that sends?
>>
>>108823135
we are two different anons but besides... can you make an effort and read more than the first line of whatever you're replying to?
sure, he started by talking about image formats (which are closely linked to the video codec they're based on of course) and you don't care about that despite being a good point against "vp8 is dead"
...but then he moved onto video codecs and you completely ignored that whole part.
he's right btw, you have yet to explain why a government would prefer to wait another decade for hevc patents to expire when vp9 has already been out for a decade+, has widespread support, is a completely open standard, and is less complex.
all that hevc gives you over vp9 is 5-10% more efficiency, and a fast encoder which vp9 still lacks, the rest is all downsides, vp9 is the better format.
>>
>>108823146
Not him but ideally, if things go right, AVIF hardware accelerated decoding is going to show up on 90% of consumer devices (royalty free of course). That alone would in practical terms make it more universal vs jpeg xl since say a 100 megapixel jpeg xl will cause low end devices to be DDOS'd while a hardware decoded 100 megapixel AVIF will be fully decoded in 0.1 seconds.
>>
>>108823208
They're images. Nobody hardware decs images. Enc? Sure. Are we getting hardware av1 encoding in phones? It would be great if we were, but no, we aren't.
>>
>>108823208
>the retard that thinks images are hardware decoded and hwdec is required for images has come back
jesus fucking christ kys already
>>
File: Untitled.png (24 KB, 794x472)
24 KB PNG
>>108823246
>>108823275
Hardware decoding and hardware encoding images literally exists and is used extensively worldwide today though. Why do you think a modern day iPhone is able to save a 50 megapixel HEIC image in 0.1 seconds? I don't want to derail the thread too much but like it or not, video codecs can leverage existing video encoding hardware to both encode and decode images using same said video codec, and that's pretty useful.
>>
>>108823333
>Why do you think a modern day iPhone is able to save a 50 megapixel HEIC image in 0.1 seconds?
because of enc, not dec. where is the hardware enc for av1/avif? i would be very happy to have this, so i am excitedly waiting for you to tell me where i can find it
>>
>>108823333
>chatgpt response screenshot
i'm done.
>>
File: 1750529307078.png (1.01 MB, 2220x1080)
1.01 MB PNG
>>108823368
>[5.1/H-1-17] MUST have at least 1 hardware image decoder supporting AVIF Baseline Profile.

https://source.android.com/docs/compatibility/14/android-14-cdd

However I cannot find any mentions of hardware encoding specifically so I guess 2 more weeks! for that.
Bluedot made an AVIF encoder for an FPGA so maybe future AVIF hardware encoders will be based on this.
It really blows because if you want small 50MP camera images immediately you have to suck Apple's cock, buy an iPhone and deal with HEIC aids.
>>
>>108823114
>AVIF isn't accepted because it requires hardware accelerated decoding
it doesnt.

>Webp uses VP8 and currently ~20% of websites in the world use Webp
webp also uses vp9 and av1. you're talking nonsense.
>>
>>108823333
>i dont understand the difference between encoding and decoding
you shouldn't post here.
>>
>>108823541
>webp also uses vp9 and av1
webm supports all three. Webp only supports vp8 and a custom codec for lossless mode.
>>
>>108822460
beyond the half knowledge, the fact that you didn't make the trivial logical connection between SSIM being "cheatable", and it being shit, is a special kind of retardation.
>>
File: Untitled2.png (37 KB, 1189x567)
37 KB PNG
>>108823556
>>
>>108823185
>Let's say you're right and the corporate format from the smaller corporations gets accepted in the future instead of the format of the larger corporation. It would basically be an admission that the US government is actually being controlled by corporations.
>>
I'm doing a DVD encode right now, and I didn't realize how fast SVT AV1 is. Thanks for the tips for the config stuff though, OP.
>>
>>108821603
>So CRF 20 for SVT-AV1 also good!".
so...what is good then? seems like some say something around 30 for SVT-AV1...
>>
>>108823637
He is targeting newfags.
Every anon who saw this samefagging shitfest already multiple times, won't even read any of this drivel.
>>
>>108817526
>Dalit
>BRAHMAs
SAAAAARRR!!!!!!!!!!
>>
File: snow-white-nikke.gif (2.36 MB, 498x498)
2.36 MB GIF
>>108823578
I mean you can test it out for yourself. Without tune 0/variance boost, YOU WILL see video turn into butter and SSIM scores go up. I've had 0.999 SSIM results show up with CRF 60 + preset 4 below 1 Mbps for 1080p video. Everything turns into butter. Punch in tune 0/variance boost and BAM, SSIM score drops to 0.97 (while video quality improves).

Like AFAIK it makes sense because SSIM is just telling you how structurally similar things are, it doesn't really give a fuck about smart bluring of tiny detail.

>>108823631
What I've found works, at least with my parameters, is a CRF of 30-50, somewhere in there you'll probably be happy. Like do a few encodes at CRF 40, if that makes you happy then you're done desu. It's just lunatics like us keep going the extra mile to fine tune shit until we end up spending more time making video encoding threads all day long instead of actually encoding our libraries...
>>
>>108823612
ok. I did one test dvd encode, and it is coming up really warm, color wise... idgi.
>>
>>108823637
>>108823661
What does your eceleb onsession have to do with the thread topic?
>>
>>108823700
Are you using OP settings? If you're using some stupid beginner shit like handbrake just stick with x264 for now, AV1 hasn't teen retard-proofed enough yet.
>>
>>108823661
no, it's working, especially because there'sa a tranny banning people for trying to help newfags.

newfags on 4cuck are very vulnerable due to being insecure and desperately trying to fit in.
>>
>>108823717
no. I'm retarded. the episode definitely has a piss filter. no I don't use handgay. I'm experimenting with replacing libvpx because VP9 DVD encodes are retard slow, but usually half the size for similar quality of AVC.
>>
File: goyware.png (464 KB, 697x646)
464 KB PNG
Fifth Dalit H264 encode: 0.6 Mbps for 852x480 24 fps >>>/wsg/6143499
umigalaxy 0.99 SSIM AV1 rip: 0.35 Mbps with CRF 55 + Preset 4 (~42% smaller) https://media.umigalaxy.com/general/1778787732274.webm
>>
>>108823702
Why are you samefagging, being shielded by da tranny, and making multiple off-topic threads for, Daiz?
>>
>>108822862
The difference is that HEVC encodes almost as slow as VP9 while AV1 encodes faster than H264.
I'll pick AV1 every day of the week.
>>
>device doesn't support 10bit AV1
when will this become the norm, bros?
>>
File: 1777595398561.png (90 KB, 1349x632)
90 KB PNG
>>108823853
>AV1 encodes faster than H264.
This part is wild. Like it makes sense on CPUs that have AVX-512 (ie 9800X3D), AV1 greatly benefits from that. Old CPUs from 10 years ago should not be encoding AV1 video faster than H.264 video at all. Either x264 dev team is suffering from DEI and they re-wrote the encoder is rust or some shit or AV1 devs found a super secret speed hack nobody noticed.

>>108823894
There's something wrong on your end because both Dav1d software decoding and hardware AV1 decoders support 10-bit AV1 as the absolute bare minimum.
>>
>>108823914
it's a target device that runs nonfree gayware. likely does not support software decode. reminds me of Andjeet and their absolute shit ass Exoplayer too.
>>
>>108821930
I’m talking about two av1 files with different crf, which should be obvious even to a bharat gentleman >>108821856
like you
>>
>crf 28 for very high quality
>crf 34 for decent quality
>crf 40 for okay-ish quality
>h264, h265: boomer shit, don’t use it
>av2: too early, don’t bother yet
why the fuck does this board need endless threads about it
>>
>>108824004
Because it's genuinely not that simple. You can get very high quality with Anime using CRF 50 with AV1 but to do the same with live footage you need CRF 40 or lower. What AV1 encoding preset you use also alters the kid of artefacting that you'll see during motion.

Anyway what we really need is someone to make an AV1 encoder that automatically adjusts itself to generate video for a target VMAF score, all hidden behind a GUI. Then people would just punch a number they're done.
>>
>>108823803
If it would be working, we would see newfags adopting his stance. But we don't.
It's still the same samefagging schizo show it always was.

...there aren't any newfags on 4chan much anyway, especially because they get greeted by schizo spam on every board.
>>
>>108817526
>All these Dalit threads on AV1 are shitting me off, so I wasted hours of my time to make this script for the BRAHMAs out there. It targets SSIM, only 1 input video file per folder though.
In english, retard?
Not reading the rest until then
>>
>>108824239
Not OP but thread quality discussing AV1 has been really dogshit for a while and ragebait threads don't get deleted so it's hard to have a good discussion about AV1 seriously. Not to mention there's a spammer calling everyone "daiz" all the time.
>>
File: 1762473181883354.png (64 KB, 1391x385)
64 KB PNG
>>108824270
>>
File: 1773979075189791.webm (728 KB, 640x480)
728 KB
728 KB WEBM
>>108824280
I'm fucking stuck here man, every place I've tried going to has like 2 active users. I can't bring myself to accept normie social media either. I often wonder about just fucking leaving society completely and living in the woods desu.
>>
>>108824280
The Google shill threads are completely unaffected from this, because the samefag isn't going to samefag less just because less other people are here.

If anything, it makes his threads stand out more, making it more obvious that its just one mentally ill brainfucked retard.
>>
>>108824332
Why would an AV1 be a "google shill thread" you stupid motherfucker? Even fucking Xilinx is involved in AV1. Are you just here to make AV1 look bad and get a paycheck from mpeg-la?
>>
>>108824371
kill yourself, Daiz

Go back to your fingol shithole
>>
>>108824371
Sundar Pichai isn't going to give you analsex just because you spam on 4chan a lot
>>
>>108824270
>trust me perkele
>im not OP
>im not daiz
>even though i am obsessively defending him, using the same posting style and using words not used by anyone else
>>
>>108817526
@grok rewrite this into powershell
>>
File: 1744144979907.png (707 KB, 1600x1324)
707 KB PNG
Sixth Dalit H264 encode: 1.1 Mbps for 942x720 30 fps >>>/wsg/6138102
umigalaxy 0.99 SSIM AV1 rip: 0.5 Mbps with CRF 60 + Preset 4 (~55% smaller) https://media.umigalaxy.com/general/1778799072609.webm



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.