Untitled

people.xiph.org/~xiphmont/demo/av1/demo1.shtml

Attached: av1-logo.png (250x139, 10K)

Other urls found in this thread:

boards.Jow
flif.info/
flif.info/example.html
uprootlabs.github.io/poly-flif/
flif.info/lossy.html
wyohknott.github.io/image-formats-comparison/#moscow&webm=ll&flif=ll
people.xiph.org/~xiphmont/demo/av1/demo1.shtml
aomediacodec.github.io/av1-spec/av1-spec.pdf
aomediacodec.github.io/av1-avif/#biblio-isobmff
aomediacodec.github.io/av1-avif/
twitter.com/enginetankard/status/916509333176819713
twitter.com/AnonBabble

This. This is the future.

Give it 5 years before AV1 properly takes off.

Tbqh I really want the AV1 still image format to take off too.
We don't really have any free high-performance alternative for pictures, given the failure that was WebP.

JPG is like MP3, it's too entrenched to be replaced

Yeah, but that's just the thing. MP3 has been fully deprecated by Opus.
Even if MP3 sticks around forever, it's still clearly legacy now.

There's nothing comparable for JPG that puts it to legacy status.

The only company that can push the AV1 image format and succeed is Apple and their iPhones. Google can't do it, Android is too fragmented.

Once every iPhone starts pushing AV1 images out, everything will be updated extremely quickly.

i watch whatever the anime encoders use

boards.Jow Forums.org/g/thread/65439779#t65439779

jpeg is more like mp1

what about flif.info/ taking over png?

FLIF is HEVC isn't it?
It's patent encumbered and unusable.

umm sweetie you can just do

I don't think so. it's under GPL and the decoder is under apache 2.0

I see no reference of hevc at all

did you read the site?

>Unlike some other image formats (e.g. BPG and JPEG 2000), FLIF is completely royalty-free and it is not known to be encumbered by software patents. At least as far as we know. FLIF uses arithmetic coding, just like FFV1 (which inspired FLIF), but as far as we know, all patents related to arithmetic coding are expired. Other than that, we do not think FLIF uses any techniques on which patents are claimed. However, we are not lawyers. There are a stunning number of software patents, some of which are very broad and vague; it is impossible to read them all, let alone guarantee that nobody will ever claim part of FLIF to be covered by some patent. All we know is that we did not knowingly use any technique which is (still) patented, and we did not patent FLIF ourselves either.


The reference implementation of FLIF is Free Software. It is released under the terms of the GNU Lesser General Public License (LGPL), version 3 or any later version. That means you get the “four freedoms”:

The freedom to run the program, for any purpose.
The freedom to study how the program works, and adapt it to your needs.
The freedom to redistribute copies.
The freedom to improve the program, and release your improvements to the public, so that the whole community benefits.
The reference FLIF decoder is also available as a shared library, released under the more permissive (non-copyleft) terms of the Apache 2.0 license. Public domain example code is available to illustrate how to use the decoder library.

Moreover, the reference implementation is available free of charge (gratis) under these terms.

HEIF is HEVC

FLIF is not the same thing

Oh yeah no, I was confusing it with BPG.

FLIF is the progressive thing were you can just truncate the file anywhere and it gives a reasonable result.

Except it's lossless only, so no one's gonna bother where they could have a format that does both instead.

HEIF is just a container, tho. You can put JPEG or H.264 in a HEIF file.

It's lossless, but it supports lossy encoding similar to how PNG does with PNGQuant, but better. Ie, instead of actually doing lossy encoding, a pre-processor modifies the input image to make out more easily compressible by the lossless encoder.

This means you can do "lossy" encoding, but without any generational loss.

Except the performance on that, is abysmal.

AV1 may (might) be worse at lossy than FLIF, but to a much smaller degree than FLIF lossy is worse than AV1 lossy.

yes, but it would be png replacement as said
it also has a lossy one as mentioned already. but that really isn't it's focus.

idk that's what he was asking about.. FLIF has nothing to do with HEVC

they have a js library that makes FLIF work in every browser

flif.info/example.html

uprootlabs.github.io/poly-flif/

I wouldn't say it's abysmal. The stats they publish (which I haven't verified, are pretty old, and don't include all the information I'd like) show FLIF as competitive, especially at >1 bit per pixel: flif.info/lossy.html

>images are lossless and have smaller sizes than gif

someone tell me why anyone would use gif ever?

It's supported everywhere.

most new smart tv's and roku tv's don't even support AVI anymore which is fucking great.

Why'd you even buy a meme TV

I don't own a tv

What's a TV?

>wall of text
miss me

Attached: file.png (1478x944, 205K)

That thing you get with your internet package but don't really ever watch. Yknow, like youtube except they don't have any users.

finally.

Because there are no 4k hdr "dumb" TVs and roku is the least worst smart. At least it doesn't force ads on you like some of the others.

Also because I watch movies with other people not huddled around my 30" monitor.

You might be looking for a "computer" and a "screen".

I'm told, and don't quote me on that, but I'm pretty sure you can display movies with a whole lot of Ks on those.

wyohknott.github.io/image-formats-comparison/#moscow&webm=ll&flif=ll

av1 images beat flif on both fields: lossy and lossless

sorry to break it to you

That's dangerously optimistic

>About two years ago, AOM voted to base the fundamental structure of the new codec on VP9, rather than Daala or Thor. AOM member companies wanted the shortest path to shipping a useful codec without royalty or licensing strings, and VP9 was decided to be the lowest-technical-risk choice.
>Daala was a contender, but I also think both the lapping approach and frequency-domain techniques required by Daala weren't (and still aren't) mature enough for deployment. There were still technical unknowns in Daala, and choosing VP9 as a starting point avoided most of them.

>As a result of starting with VP9, AV1 (the AOM Video Codec 1) is a mostly familiar codec built along traditional block-based transform coding lines.

FUCKING DROPPED

AV1 = same shit as usual, confirmed.

people.xiph.org/~xiphmont/demo/av1/demo1.shtml

Happy to hear that, actually

And yet we've had effective VP9 hardware cores for some time now.. What's the problem? AV1 Hardware will be here and there are obvious improvements in AV1. Can you please expand on your point of view a little further? Genuinely don't understand what you mean.

Did you even read the post you linked to?
AV1 is full of new ideas incorporated from Daala and Thor. Just because it's based on VP9 doesn't mean shit, look at the results not at the memes.

CfL, CDEF, the Warped Motion / OBMC features just to name a few are all new, and together responsible for a good 15% bitrate reduction over HEVC.
In total up to 40% reduction over HEVC, so that's pretty fucking awesone.

Truth is, Daala was and is just not ready. Frequency domain is just too different and hard to work with at this point in time.

>implying people here read anything before shitposting and not the other way around

>implying those people shouldn't get out of my Jow Forums

Attached: extremeProgramming.png (801x704, 184K)

*blocks your path*

Attached: .jpg (750x469, 126K)

Doesn't HEIF have royalty requirements?

AV1 was a horrible name. Everyone will confuse it with AVI.

Attached: Screenshot_2018-04-10-19-21-02-1.png (1920x361, 64K)

Who cares, it's all just gonna be in a .mkv anyways. There's no gonna be a .av1

AV1 is taking too long... h265 cancer will be the standard by the time AV1 is usable.

>confusing a codec with a container
L M A O

Normies think that videos are just mp4, webm, and avi.
Heck, most don't even care. Netflix just werks.

I always download HEVC movies instead of YIFY. He's so much better at getting movies than YIFY. (I'm a bit of an audiophile so I can tell the difference)

YIFFY always has "a 10" though

AAC pretty much replaced mp3 on iTunes and similar stores, and every streaming website uses either AAC or Opus.
mp3 is still used in the ripping scene, basically.

Good thing Apple is part of the AOM, then.

HEIF is, i shit you not, just ISOMBFF (AKA, mp4). They somehow thought it was a good idea to use fucking ISOMBFF as container for an image format, instead of something sane like RIFF, or just tidying up HEVC's Main Still Picture profile.

I'm hoping the AV1 answer to HEIF is not as retarded.

VP9 is already at its own Phase 4. It's supported by all major browsers, media players, all modern hardware (PC and phones), and used by streaming services like Netflix and Youtube.

It's not too optimistic to think it will be available everywhere by late 2020. Although maybe 2021 is more realistic, especially for dedicated silicone and phone models using said chipsets.

>VP9 in avi
What kind of godless heathen would go and do this?

MP3 has been obsolete since Vorbis.

I would hate if a format that did decently at both lossy and lossless became common because that would probably result in a lot of art being losdly compressed for no good reason.

>Give it 5 years before AV1 properly takes off.
New Media cabal are chomping at the bit to cut out codec patent licence jews

You still need hardware encoding to get into the big leagues.

Hardware decoding I understand, but why is hardware encoding that important to you?

hardware decoding is done by users, nobody gives a fuck if you waste their CPU time. Giving that user access to petabytes~ of video to decode takes hardware encoding.

er software decoding is done by users not hardware. Also for things like cameras and stuff you'll need to actually have the encode speed to put it on disk in realtime.

They have money to make that true.

Getting TO phase 2-3 isn't that bad. Google pushed out reference implementation for a vp9(?) hardware encoder chip and gave it out free. The libraries to include all the codecs are libre enough to patch into even the most commercial of softwares. Adoption is sort of optional/reliant on end users.

gookmoot still hasn't supported vp9 but it kinda stalled at some of the optimization steps so it's not as big of a loss as AV1 would be compared to shitty old mpeg/streaming whatever. Not sure what it can tune for on the lower webm-y use case end.

>software decoding is done by users, nobody gives a fuck if you waste their CPU time.
Anyone running off batter payer (particularly phone) will.

The big push is coming from Google, where encoding only needs to be done once and decoding is done many times.

>Also for things like cameras and stuff you'll need to actually have the encode speed to put it on disk in realtime.
All that stuff runs several generations behind.

The problem with phones is that while most of them have very modern hardware encoder/decoders inside their processors they aren't always usable. They're all based on proprietary drivers which get into versioning issues and then operating system controls and then maybe maybe maybe a dozen layers down do apps get a chance to use them. Thats why nobody can make a camera app and why 3rd party shit can't compete, still a majority of that will be software even where hardware is available.

a lot of companies are involved and if they push av1 down everyone's throats (and they will) then it will be successful since everyone uses web applications and don't care about it much as long as it works anyway.

Thx, mom!

You'll probably have browser support for it within 6 months inside Chrome and Firefox, and Netflix and Youtube will probably support it within a year.
Android itself will probably be able to support it within a year, but most smartphones and smart TV's will probably take 2-3 years to catch up.

>Except the performance on that, is abysmal.
Yeah, for encodes it is. So, you won't see most people using it to encode locally or livestream for a while.

However, Youtube and Netflix will probably use it, even if it takes 500 times longer to encode. It will still be worth it for videos that get viewed millions of times.

heif is a container format

> Google can't do it, Android is too fragmented.
Of course Google can, they own Youtube AND they can just push it into Android and/or Android's Youtube app.

Apple is not that useful in this; they might as well be one of the companies that adopt it once everyone has due to efficiency and licensing reasons.
Not to say that it's not good for Apple users that they ARE part of the consortium, but it scarcely matters.

They tried to push WebP and that flopped pretty hard. There's still no full VP9 hardware decoding on AMD GPUs.

Where did they push WebP?

> There's still no full VP9 hardware decoding on AMD GPUs.
VP9 was barely good enough to beat h.264, is it's fairly obvious no one cared after h.264 was everywhere.

AV1 is sufficiently better than it easily has a chance to beat H.264. I don't have a clue if a static image format derivative also will succeed, though.

>Where did they push WebP?
AFAIK they were pushing WebP YouTube thumbnails at one point. Facebook also tried WebP as well.

AV1 will beat H.264 eventually, it'll probably take 5-6 years to get there though. The encoder is too slow and unoptimised at the moment and H/W decode support is only coming out in 2020.

> AFAIK they were pushing WebP YouTube thumbnails at one point.
You can explicitly request these but I don't remember them becoming default, ever.

> it'll probably take 5-6 years to get there though
What makes you think that? My own guess is 1-2 years; they did have a good number of hardware and software engineers thinking about implementation feasibility in AOMedia after all.

> H/W decode support is only coming out in 2020
Even if that was true [have you seen ?], just about everyone already has devices that can SW decode. The average $100 Chinese smartphone can.

If you use Chromium, it won't have support for h.264 (it's proprietary), so it uses vp9 instead.

Botnet.

Attached: leaf.jpg (623x605, 49K)

Firefox Nighly already supports AV1

I think the biggest hurdle for widespread adoption isn't going to be the decoders, it's the encoders.
I want to see a nice encoder near as good as x264 for it.

>tfw AV1 sacrifices Anime fidelity in favor of photo-realistic scenes
>tfw AV1 will become the standard in all devices
>tfw HEVC Anime will require software decoding
>tfw weeb cell phone battery dead

Attached: 1463614348980.gif (312x420, 91K)

To me the important piece would be proper ffmpeg encoding support. We currently don't have that for VP8 or VP9 so I'm not holding my breath for AV1. And by proper I mean actually usable multi-core encoding support. I've tried encoding VP9, tried all the options. It will only use a single core. Encoding takes FOREVER compared to HEVC. VP8/VP9 isn't a real choice even though smartphones do have hardware support.

x264 will be the standard for live-streaming for a long time, hardware encoding support generally lags decoding (lots of GPUs and SOCs can decode HEVC but lack encoding support)

Funny enough there's some Linux mailing list posts and patches for VP9 hardware decoding on AMD GPUs not using the UVD hardware ASIC. It hasn't amounted to anything (yet). Idea seems to be to do it in hardware using other parts of the GPU.

>Normies think that videos are just mp4, webm, and avi.
Wrong
>Heck, most don't even care. Netflix just werks.
Right

>all modern hardware (PC and phones)
AMD doesn't have a HW VP9 video decoder, it's only hybrid.

Ryzen Raven Ridge APUs have hw VP9 decoders

You realize that the AV1 developers are enormous weebs, right?

aomediacodec.github.io/av1-spec/av1-spec.pdf
>The source code is the specification.

>implying animu will ever move away from h264

Stop talking about hardware and let's talk about state of art.

It's simple, we kill DaZ

I thought that was the HEVC guy that's a massive 2hu fan

checked

>HEIF is, i shit you not, just ISOMBFF (AKA, mp4)
That's because they want to support all the crap that photos app on your smartphone might want to do.

They were that close to picking .pptx as the format.

Tough luck
aomediacodec.github.io/av1-avif/#biblio-isobmff

>The source code is the specification.
It's not though?

>An AVIF file should be a simplified and conformant version of an [HEIF] file. This is to allow for the deployment of general libraries that may be used to create and parse HEIF-based image files wrapping different coding methods for the actual image content. This should be similar to ISO-BMFF usage in the video domain.

>The AVIF file format will be built on the box-structured media interchange format introduced by the ISO Base Media File Format ([ISOBMFF]). The format specified by AVIF defines the use of a subset of box structures introduced in ISOBMFF. Where the necessary structures do not exist in ISOBMFF, structures defined as part of the High Efficiency Image File Format ([HEIF]: ISO/IEC 23008-12) that are codec neutral and can be applied in a generic manner are used. An AVIF version 1.0 file shall be compliant to the requirements of Clause 4 of the [ISOBMFF] specification, and where applicable, the recommendations in Annex I: Guidelines On Defining New Image Formats and Brands in the MPEG HEIF specification shall be followed for AVIF 1.0.

h-hh-eehe
aomediacodec.github.io/av1-avif/

Attached: serveimage[1].gif (498x280, 1.01M)

That's Dark Shikari, an old x264 developer. It's not like AV1 people aren't trying, though.

twitter.com/enginetankard/status/916509333176819713