V1.0.0, 7 September 2018

>The only reason av1 exists is to save money for the netflixes of this world.
FTFY
Bandwidth can already be easily saved with HEVC. AV1 is just so they don't have to pay royalties.

We don't give a shit about HW encoding. If AV1 can't match HEVC SW encoding performance and time then I won't even bother with it. 90% of my chink toons are 1080p blu-ray muxes and I don't want to wait a decade for them to be tranacoded to smaller file sizes of similar quality.

MPEG is greedy and corrupt and everyone is sick of their monopoly.

There's a lot of big names behind the development of AV1. A codec plans for cpu hardware support before release is unprecedented. Intel and AMD already knew what was coming.

Its also open source, so its a win win for everyone except MPEG LA

>MPEG is greedy and corrupt
>implying Google, Microsoft et al. aren't

>Its also open source, so its a win win for everyone
I want AV1 to succeed because of this, but so far it looks like their codec is made by literally blind people.

>implying Google, Microsoft et al. aren't
In this context they offered their patent licenses for free and open sauce code.

>I want AV1 to succeed because of this, but so far it looks like their codec is made by literally blind people.
Wat. AV1 looks pretty great from the comparisons we've seen so far...?

Brainlet consumer.

It won't match x265's encoding speed, just like x265's encoding speed doesn't match x264's.
There aren't any efficient (or even non-experimental) encoders for AV1 out yet, but if they come you have to make the same decision as before. Do you want to stay with the older codec that can be encoded faster or the newer one which offers a better compression.

would it be possible to have an av1 encoding asic designed

That's what a Codec is. enCOding en DECoding. that's why AMD/Nvidia hardware can record so fast without any performance hit. They are using proprietary codecs to do so.

x265 is literal pajeet software though, still with unfixed bugs.
bitbucket.org/multicoreware/x265/issues/214/ghosting-artefacts-even-with-low-crf-when

Daiz Ajin x265 encode was famously shit
diff.pics/e1yaUO5lSsbL/3

HEVC gains are noticeable at LOW bitrates like 1080p@24 1Mbit/s. If you are reencoding a BD mux, a x264 10-bit 1080p@24 6-7Mbit/s encode would be virtually identical to x265 at same bitrate.

Play with different settings here

mattgadient.com/results-encoding-8-bit-video-at-81012-bit-in-handbrake-x264x265/

>Being such a stupid ass that you don't realize they pass their costs onto the consumer

Have you even used the latest x265 encoder? Because I've been using an old 2018 july release and have had none of the problems you mentioned.

builds.x265.eu

Attached: 32_crop.jpg (450x450, 23K)

>"Notice: This set of test encodes was done over the course of a few months in 2017 before being published in Jan 2018. Newer versions of x264/x265 may exhibit different behavior. Always run your own short test encodes (at least 10-30 seconds) to ensure you're happy with the result before hunkering down to do a long encode."

Attached: 1420565690261.jpg (274x321, 26K)

Ok, so say most of your media devices support, AVI,MKV, H.264,Xvid/Divx, MP4, (most common types). Why would any company release some new codec or film encoded with said codec if there was no user base that could play it/use it? You'd be shooting yourself in the foot. Not everything can be "upgraded" via a downloadable patch you know, so again, why bother releasing content in a format that most devices cannot support.

Did you just compare a 10-bit precision encoder to an 8-bit one and expected the 8-bit one to look better? You know we've had 10-bit precision HEVC encoders for a while now, right?

Attached: 1530704649090.png (446x344, 119K)

imagine 1.1.1 release

Because freetards want communism. If it was up to them electronics would cost 10X as much to support their freetarded garbage.

Not much changed in x265 land this year aside from AVX512 speed optimizations.

No, I compared 10-bit HEVC to 10-bit h264.

>Not much changed in x265 land this year aside from AVX512 speed optimizations.
Source? Because at least for me the CRF bugs have essentially been eliminated in 8-bit AND 10-bit precision encoders. 12- bit I'm not sure though.

A lot of it I think has to do with file size/screen size. Most of your "torrents" or hell even some of your own rips were based on the fact that the device they were viewed on was only XX inches wide. So you didn't need them to be say 1GB each in order to look great on said device. Now we have sets that are 65, 75,etc wide. Those same rips look like shit on them. It's not the codec's fault. The problem is the small file size of your rip.

>Not much changed in x265 land this year aside from AVX512 speed optimizations.
So does this essentially mean AV1 is DOA? All that's left is for AMD to add AVX-512 to their silicone.

Attached: skl_vs_bdw_speedup-768x498 (1).png (768x498, 148K)

>AV1
>only takes 6 months to encode a 15 minute clip

Or depending on age of the ripped show, large ass sets didn't even exist. 4x3 CRT's were still common and they topped out at 32, 40 inches. So yeah viewing a ripped show that looked great on such devices then now on today's massive HD sets of course the results will look like shit.

At 480p maybe. We're getting 8K monitors and 16K TVs to become mainstream soon too.

Shame, I guess we all expected way too much from AV1.

I looked at their git log for relevant changes. You might be right about CRF bugfix but I was commenting on their lack of bug report response.

HEVC is practically nonexisting on web streaming where low bitrate quality is the most important. For home archival use I don't see any point switching from x264 to x265 or AV1 frankly.

streamingmedia.com/Articles/Editorial/Featured-Articles/Jury-Levels-$7.7-Million-Judgment-Against-Huawei-for-H.264-Patent-Infringement-127140.aspx

>However, both of these judgments indicate that the standard-setting process is broken. A company should be able to deploy a technology knowing absolutely how much it will cost; it’s how we buy everything from gas to groceries. The current standard-setting process not only prevents this, but it promotes contrary behavior like the appearance of patent pools four years after the technology is finalized.

>This is why groups like the Alliance for Open Media exist. It’s also why HEVC is foundering, and why the next-generation Versatile Video Coding (VVC) codec will similarly fail, or at least fail to reach its full potential unless MPEG revamps how it makes their technologies available for commercialization.

All MPEG H.264 licensees getting FUCKED soon

MPEG is a dead piece of shit with terrible greedy Non Practicing Entities(NPEs) just wanting to collect rent

That's why it's so important for a new codec to have the backing of hardware manufacturers. It'll never take off without it.
At the same time you shouldn't overestimate the importance of legacy support. Especially nowadays people buy new devices at least every few years.

Really?

streamingmedia.com/Articles/Editorial/Featured-Articles/Netflix-Finds-x265-20-More-Efficient-than-VP9-113346.aspx

>Posting outdated shit

streamingmedia.com/Articles/Editorial/Featured-Articles/AV1-A-First-Look-127133.aspx

>As you can see, AV1 was the clear leader, H264 the clear laggard, and x265 and VP9 neck and neck in the middle. No surprises there.

Attached: 117646-Ozer-AV1-Fig2.png-ORG.png (1010x620, 47K)

Netflix serve HEVC to a very limited number of users last I checked, mainly 4K and HDR Smart TV users. Other main benefactors are Apple iTunes and Amazon for 4k. Bulk of streaming is done for 1080 and lower.

>"The AV1 encode took 62 hours and 48 minutes, which was 45,216 times longer than real time."
LMFAO, fuck that.

Attached: 1531019938269.gif (320x240, 2.65M)

Oh boy so when 16K res TVs become mai stream AV1 will come to save us, right?

How do you like your DRM for 16K? Hollywood would literally bug your home for access

Nice!
Now Daala when?

Attached: 1520612134767.gif (1200x1200, 479K)

>63 hours to encode a 5 second video

At that speed a feature length movie would take 53 years to encode. YEARS.

Who the fuck thinks this is useful? Even IF they get a 1000 fold speed increase with further development, it will literally take weeks to encode things.

Nope, not for AV1. WebM is pretty much dropped and they are supporting it on a best effort basis. Google is also planning on deploying mp4 DASH instead of WebM DASH for it as well.
The ISO binding was designed by Google employees and the final spec agreed by consensus in a AOMedia meeting, whereas the Matroska/WebM spec was left to Matroska devs with zero overseeing from AOMedia, and the Google devs cared little when it looked like it was deviating too much from the ISO one at first.

So in short, WebM is on its way out, same with WebP, which is being replaced by AVIF (also ISO based) for AV1 still pictures. Simply look at the comment in chromium.googlesource.com/webm/libwebm/ /361aec07c44599e812db9a3907634080d290ab6c^!/ and the fact the libwebm repo barely got any development in months.
My guess is that the big names in AOMedia would rather use a standard from ISO rather than Google's "inhouse" container. Especially Apple, since they don't even support WebM.

The reference encoder wasn't made to be fast, it was made to be correct and to easily add or remove features during the experimentation phase.

>For home archival use I don't see any point switching from x264 to x265 or AV1 frankly
x265 is the best choice for home archival with 1080p and 4k movies. Stick with x264 if you only want to store anime. And AV1 is meant for streaming, not storing.

It's still a reference to what encoding speeds we can expect. In the end AV1 outside of streaming for companies who can spend 1,000X more on encoding hardware is going to be a meme.

I predict more streaming services will just switch over to VP9 until the successor to HEVC comes alone in a few years.

Attached: 1536189875350.jpg (673x768, 88K)

>It's still a reference to what encoding speeds we can expect
Look at the reference HEVC encoder. It's slow as shit, infinitely worse than x265. Similarly, look at the reference VP9 decoder, and compare it to the native ffmpeg VP9 decoder.

Reference implementations are meant to be correct first, fast second.

Whatever man, I've given up on AV1 desu. Might switch to VP9 but that's as freetarded as I'll go video encoding wise. Do we have any hardware 10-bit video decoders yet?

According to one of its devs github.com/xiph/rav1e is getting close to VP9 encoding perfs now but I haven't tested it yet.

>Giving up on something before it's even properly out
And hardware decoding for VP9 has been available for years. Even your phone supports it if you bought it in the past two or so years.

SW encoding? I don't give a shit about HW encoding.

>gives up on AV1
>rather uses VP9 and the trash fire that is libvpx
Sry mate, but I'm seriously questioning your knowledge on the topic.

Still a meme codec until at least 2022.

>Daa
The last commit to their github was in Janurary so it's a long time coming if ever

probably never, I remember one of the daala devs saying it's gonna be a test bed for new algorithms as opposed to a new separate codec

it's mostly been absorbed into AV1 anyway

>There aren't any efficient (or even non-experimental) encoders for AV1 out yet
No, but rav1e produces streams and passed x264 quality this week...

SW. Written in Rust.