Alliance for Open Media codecs [Archive]

dapperdan

2nd September 2015, 10:43

Alliance for Open Media Established to Deliver Next-Generation Open Media Formats

http://aomedia.org/press-release/alliance-to-deliver-next-generation-open-media-formats/

"The Alliance’s initial focus is to deliver a next-generation video format that is:

Interoperable and open;
Optimized for the web;
Scalable to any modern device at any bandwidth;
Designed with a low computational footprint and optimized for hardware;
Capable of consistent, highest-quality, real-time video delivery; and
Flexible for both commercial and non-commercial content, including user-generated content.

This initial project will create a new, open royalty-free video codec specification based on the contributions of members, along with binding specifications for media format, content encryption and adaptive streaming, thereby creating opportunities for next-generation media experiences."

The Mozilla Blog: Forging an Alliance for Royalty-Free Video

https://blog.mozilla.org/blog/2015/09/01/forging-an-alliance-for-royalty-free-video/

Comments on the Alliance for Open Media, or, "Oh Man, What a Day"

http://xiphmont.livejournal.com/67752.html

Microsoft, Google, Amazon, others, aim for royalty-free video codecs

http://arstechnica.com/information-technology/2015/09/microsoft-google-amazon-others-aim-for-royalty-free-video-codecs/

So it seems (though it's not crystal clear edit: it's a bit clearer in Xiphmont's link) that this has been setup as a parallel to the IETF's NetVC project and that the work done will be fed into that project in order to get it standardized via an org with modern patent policies. It also seems this is the first time Google has publicly committed to contributing VP10 to that effort, joining Mozilla's Daala and Cisco's Thor. Just Google joining that effort would have seemed like a big deal yesterday, having Microsoft and Netflix onboard is a radical shift in the ecosystem.

BadFrame

2nd September 2015, 11:47

This is certainly a big 'Wow!'

By pooling the video patents they have between them they should be able to create a strong contender for HEVC, particularly since Google has laid a lot of groundwork with their VP series of codecs.

And of course unlike HEVC this will be royalty free and with the Windows desktop and the Android mobile support it will cover the vast majority of users, assuming that Apple doesn't turn around and support this as well, then it will likely be THE video standard.

Now that it's official I'd love to hear if Ben Waggoner can fill in some more info as he works for one of the companies in the alliance (Amazon).

Also another big question is of course how big a blow this is for HEVC's future prospects (and particularly x265 as that's the project I worry about), it was already bad with the patent pool split, creating the situation of having to pay royalties to two different entities, one of them with huge demands. And now this.

dapperdan

2nd September 2015, 11:57

Once you've committed to this effort, it makes less sense to be pushing HEVC over VP9 as it no-longer aligns so neatly with your long term strategy. It seems Microsoft is already talking publicly about VP9 in Internet Explorer, if Netflix and Amazon switch in the short term then HEVC could take a beating and a tipping point could be reached before the new codec even arrives.

Though of course just the threat of that might be enough for HEVC licencing to be fixed, just like they clarified a few things regarding H.264 when VP8 arrived. Hopefully though, going forward, these big corps realised that the existing MPEG process is fundamentally broken if it allows the current HEVC licence issues to arise. There's rumours of third patent pool being announced!

BadFrame

2nd September 2015, 12:38

if Netflix and Amazon switch in the short term then HEVC could take a beating and a tipping point could be reached before the new codec even arrives.
Yes, a royalty free next gen codec with wide industry and platform support must be a wet dream come true for Amazon and Netflix, so I can only assume they will add support as soon as it's practical, as part of a longer term full transition.

Though of course just the threat of that might be enough for HEVC licencing to be fixed, just like they clarified a few things regarding H.264 when VP8 arrived.
I'm sure there will be some sort of response shortly, though I don't think there's any hope of them stopping this 'Alliance' effort, Google was evidently already set on making royalty free codecs, Mozilla was funding Daala and Cisco released their own codec, meanwhile Amazon and Netflix obviously want a wide platform standard around a royalty free codec, actually it's only Microsoft which I find a bit surprising in this context.

I can only assume that this alliance was formed upon binding agreements between the members in terms of commitment, particularly given the current HEVC licensing debacle.

AlexKane

2nd September 2015, 15:05

Let's hope they create a royalty free standard for multi-channel audio that translates to the end user's playback configuration as well.

dapperdan

2nd September 2015, 18:39

http://www.streamingmedia.com/Articles/News/Online-Video-News/Amazon-Google-and-More-Working-on-Royalty-Free-Codec-106091.aspx

The comments from the Google spokesperson in the above article, make it seem like it's going to be mostly VP10, but properly standardized and with some extra patents and polish from the other contributors.

dapperdan

2nd September 2015, 18:46

http://www.ietf.org/blog/2015/09/aiming-for-a-standardized-high-quality-royalty-free-video-codec-to-remove-friction-for-video-over-the-internet/

A NetVC status update blog post from yesterday, which notably makes no mention at all of the new developments. I'm assuming that's just coincidental and that blog post was in the works before this went public.

mandarinka

2nd September 2015, 22:51

I don't want to be a party pooper, but I would be conservative with the expectations.

This is surely going to be a good for royalty-less video, but it might not push boundaries of compression efficiency as such, at all. So it depends if you are mainly concerned about the former, or are more generally interested in video coding technology being moved forward.

Sure, Daala and all these projects will claim that they aim to get ahead of HEVC... but look at history of VP codecs or just any competitor to MPEG technology. There was always a lot of ambition and/or hype, but was there ever a case when things were delivered? Maybe WMV9 was kinda competitive with mpeg4 asp at some points, not much else comes to mind.
I am afraid that NetVC is far from guaranteed to beat HEVC, which seems to be what +-everybody is assuming and cheering for. And on top of that, it will only come to market in few years from now, and add to that the years that will be needed for polished encoders to appear.

I used to watch Daala development a lot (and still am), but to be blunt I think that it is HEVC that is going to be the relevant force moving video coding in next 3-4+ years. From technical point of view (ignoring royalties and ideological stuff), that's what is going to bring us good stuff.

I don't want to bash the efforts or FUD against them, but I think it is better to be conservative with our expectations.

BadFrame

3rd September 2015, 05:47

I don't want to be a party pooper, but I would be conservative with the expectations.

Nothing wrong with that.

I am afraid that NetVC is far from guaranteed to beat HEVC,
Well judging by the tests being done in this forum, it seems HEVC is far from guaranteed to beat h264 :)

Anyway, VP9 is not miles behind HEVC quality-wise as of now (although encoder performance-wise it's still far behind), but of course a lot of the problems in keeping up with HEVC is that of software patents limiting the amount of compression techniques available to VP9, with the upcoming NetVC being able to use the patents from Cisco and Microsoft as well (and chances are we'll see more companies with patents join this alliance), it can be more competitive with HEVC.

I am afraid that NetVC is far from guaranteed to beat HEVC, which seems to be what +-everybody is assuming and cheering for.

Certainly there is no such guarantee, however it doesn't have to 'beat' HEVC, it needs to be 'close enough' and widely supported. You must realize what a disaster HEVC is right now in terms of royalties, with two pools, one which demands 0.5% of all content.

With this it happening it's not just Google but also anyone else with a longterm interest in streaming video that wants out from MPEG LA's (and offshoots) grasp, and NetVC is the obvious solution.

Google was already committed to avoid MPEG LA royalty schemes (as per their continued codec development), now Amazon, Netflix, Microsoft, Cisco and Mozilla joins up, I can only assume Facebook and other services interested in streaming video will follow.

And on top of that, it will only come to market in few years from now, and add to that the years that will be needed for polished encoders to appear.

h264 is already available until then (heck Microsoft is adding VP8/VP9 to their own browsers according to recent updates), meanwhile HEVC is more or less dead as a platform for streaming video due to the current royalty debacle, sites like Youtube, Netflix, Amazon, etc can just continue to serve h264 content until the new codec is ready and widely supported.

Also not sure what you mean by 'polished encoders' ? Google themselves develop the official encoder which is very much like x264/x265 in usage/options, which anyone can slap a polished gui/framework around should they so choose.

From technical point of view (ignoring royalties and ideological stuff), that's what is going to bring us good stuff.

HEVC may end up being the technically best offering, but that doesn't really matter in a wider perspective if only the anime encode scene ends up using it ;)

As of now I see a near future where most legal content shuns HEVC due to the royalty demands and instead continues to use h264 while seeing how NetVC and the HEVC pool fiasco pans out.

However, we do know that Google, Amazon, Netflix and basically every other company with a longterm interest in streaming video DOES NOT want to be subject the MPEG LA's royalty schemes, in fact they don't want to pay royalties at all.

With this second HEVC patent pool having formed, with it's own huge demands, this has now reached a tipping point, and the result is this 'Alliance' with the clear objective of creating a competitive royalty free codec, which again is something the entire industry of streaming video REALLY want.

I see nothing that would make these companies turn around and go back into MPEG LA's fold now that they've taken this step, and I'm certain many other companies with the same interests will follow.

Note again that I'm not claiming NetVC will be a technically better solution than HEVC, atleast not in the near future (this all mainly depends on software patents they gain the use of), but the difference in quality will be no where near as large as the difference in price, given that the former is royalty free, and the latter is a royalty nightmare.

nevcairiel

3rd September 2015, 10:15

h264 is already available until then (heck Microsoft is adding VP8/VP9 to their own browsers according to recent updates), meanwhile HEVC is more or less dead as a platform for streaming video due to the current royalty debacle, sites like Youtube, Netflix, Amazon, etc can just continue to serve h264 content until the new codec is ready and widely supported

The problem is that marketing is pushing them to deliver 4K, and streaming 4K with H.264 is just going to be inefficient at best - not to mention lack of wide 10-bit support, which is mandatory for proper BT.2020 transmission.

mandarinka

3rd September 2015, 17:43

Nothing wrong with that.
Also not sure what you mean by 'polished encoders' ? Google themselves develop the official encoder which is very much like x264/x265 in usage/options, which anyone can slap a polished gui/framework around should they so choose.

It is unpolished in exactly the same sense in which you say that we didn't yet see HEVC convincingly beating H.264. x265 isn't similarly good as x264 (in that case it would be beating its output across the field in all scenarios). But libvpx from Google is much worse than that, that is not even close.

For VP9 libvpx doesn't even have decent threading (tiles, WTF? only one thread possible for each whole 512 pixels of width? Come on! Are we supposed to encode 1920x1080 with measly three threads? And add to that the compression hit of tiles).
And then there is the question of quality. No x264, that's for sure. But hopefully Google won't be the (only) source of the "go to" NetVC encoder :/

Libvpx is exactly what I had in mind when speaking about encoders being unpolished.

-------------------------------------

Anyway, what I have more hopes for here is that the rogue HEVC patent holders will either rediscover their reasoning and offer fair rolyaty rates (like MPEG-LA basically), or they will be blackmailed/contract-forced/sued/pressed to do so. Sane fair royalties aren't a problem. Who knows, maybe that is even a side goal of this Alliance - and if it serves to that goal, yay.

VDO2015

3rd September 2015, 18:18

I wonder where Apple is in all of this?

BadFrame

4th September 2015, 05:39

The problem is that marketing is pushing them to deliver 4K, and streaming 4K with H.264 is just going to be inefficient at best - not to mention lack of wide 10-bit support, which is mandatory for proper BT.2020 transmission.

The 4k push is already derailed due to the forming of a second HEVC patent pool with demands the content distributors will never accept.

As for how much pent up viewer demand there really is for 4k, it's hard to tell as the whole 4k push is a marketing campaign to sell the HEVC codec and new hardware capable of viewing it.

Let's just say I doubt a 4k delay will make a dent in Netflix and Amazon viewership, including lack of 10-bit.

For VP9 libvpx doesn't even have decent threading (tiles, WTF? only one thread possible for each whole 512 pixels of width?

I'd always assumed that the tiling was chosen due to avoiding infringing software patents, if that is the case it can only be solved by aquiring the necessary patents or being able to work around them somehow.

I know Cisco and Microsoft came with a bunch of patents pertaining to h264, hopefully those will have an impact on encoding performance.

I wonder where Apple is in all of this?

One of the mozilla devs mentioned on Hacker News that they were in talks with Apple regarding this:

-"We are absolutely talking with Apple, and hope they will decide to join.",

make of that what you will.

mandarinka

4th September 2015, 19:18

I'd always assumed that the tiling was chosen due to avoiding infringing software patents, if that is the case it can only be solved by aquiring the necessary patents or being able to work around them somehow.

That is just implementation detail of decoder/encoder. They could implement frame threading like in x264 with no problem. Perhaps WPP could be patent-covered, but x264-like frame threads don't need any explicit support in format, hence you don't have a problem.

I'm afraid it is just lack of care from Google. Threading is hard, Youtube doesn't need it, let's go shopping.

BadFrame

6th September 2015, 13:07

That is just implementation detail of decoder/encoder. They could implement frame threading like in x264 with no problem.

I'm not at all certain of that, I would expect that there are patents regarding multi-threaded encoding methods as well.

I'm afraid it is just lack of care from Google. Threading is hard, Youtube doesn't need it, let's go shopping.

But they have implemented multi-threaded encoding, if they didn't need it why bother in the first place ? The multi-threading method is obviously very resolution dependent, why settle for such a limitation if they don't have to ?

If what you say is true, they could just re-implement the method x264 has for multi-threading the encoding workload, yet they don't.

mandarinka

6th September 2015, 18:48

Tile-based threading should be very very simple to implement. My impression that they just don't care about this much comes also from the fact that it took them years since VP9 "launch" to add even this crude method. BTW VP9 actually requires this tiling for resolutions like 4K, so that decoders for them can be simpler. Yet they only made their encoder actually run the tiles independently on separate cores now (AFAIK). Idunno but to me it looks sloppy.

Basically, if I was a manager there, I would have assigned them the task as one of the first things once the encoder got out of alpha or beta stage. If I ever cared about anything else besides Youtube usage. So my conclusion is that either they really don't care or that the team developping the encoder is disorganised - as if it was running like a volunteer open source project community, where people only write code they for some reason feel like to, but when nobody feels like doing some task due to difficulty, hard debugging, or other headache hazzards, it never ever gets done.

Nintendo Maniac 64

7th September 2015, 04:12

Let's hope they create a royalty free standard for multi-channel audio that translates to the end user's playback configuration as well.

Opus supports up to 255 channels...

----------------------------------------------------------------

the whole 4k push is a marketing campaign to sell the HEVC codec and new hardware capable of viewing it.

It more than that, in particular it's a response to...

1. the commercial failure of 3D
2. LG Display's commercialization of large-sized OLED

These two factors are largely why you've got 4k, quantum dots, local dimming, HDR, curved*, "S"UHD or whatever and more all making an appearance (some being revived like local dimming) in LCDs only within the last year or two.

Remember, the current market share for LCDs is pretty much split up between LGD, Samsung, and Innolux (and a few Japanese products, like Nintendo's, that are still partial to displays made by Sharp).

Innolux's whole existence is built around manufacturing LCDs while Samsung's LCD products dominate the large sizes and their OLED products, which they've been unable to commercialize at larger sizes, dominates small screen sizes in anything that isn't an Apple product (Apple uses LG panels). Now factor in that LG and Samsung are practically the Korean business equivalent of warring factions combined with the fact that, if everybody stopped buying LCDs, Innolux would be out of business in an instant...

*while curved was originally used on LG's OLED products, LG had and still does have equivalent flat models as well. Samsung by comparison has a considerably more aggressive curve on their products and doesn't even offer flat versions in the highest-end.

benwaggoner

7th September 2015, 22:20

The 4k push is already derailed due to the forming of a second HEVC patent pool with demands the content distributors will never accept.

As for how much pent up viewer demand there really is for 4k, it's hard to tell as the whole 4k push is a marketing campaign to sell the HEVC codec and new hardware capable of viewing it.

Let's just say I doubt a 4k delay will make a dent in Netflix and Amazon viewership, including lack of 10-bit.
Given Netflix and Amazon launched UHD streaming in 2014, I don't think I'd describe the situation as "derailed" :). The number of capable TVs in homes and available content are both growing rapidly.

Also, there would have been HEVC without 4K and 4K without HEVC. "4K" (let's call it UHD, since it is really 3840x2160) was because manufacturing the panels became possible. HEVC was because it was time for the next gen MPEG/ITU codec. Timing worked out nicely because HEVC is particularly good at >1080p and streaming 2160p with H.264 wouldn't have been nearly as feasible (10 Mbps HEVC and 25 Mbps H.264 are roughly equivalent at UHD resolutions). But optical disc certainly would have provided more than enough capacity and throughput for H.264 UHD.

BadFrame

9th September 2015, 11:13

Given Netflix and Amazon launched UHD streaming in 2014, I don't think I'd describe the situation as "derailed" :). The number of capable TVs in homes and available content are both growing rapidly.

Ok, still I doubt UHD streaming is a major draw among their (Netflix, Amazon) subscribers, of course you have much better first hand knowledge of this.

Speaking of which, although I assume you have to keep your lips tight, I have to ask if there's anything you can share beyond the joint statement we've seen regarding the upcoming codec collaboration, given that Amazon is one of the companies involved ?

CruNcher

30th September 2015, 11:04

Vudu is also preparing it's launch with Dolby Vision (HEVC HDR) Layer Enhancement REC 2020

http://www.watchvudu.com/UHD/

Im really looking forward to Intel bringin in their Real Networks IPR into the AFOMC also Microsoft is of heavy value here with some parts of VC-1 ;)

Google obviously with the ON2 parts it's great seeing everything coming together after all this years merging into 1 :D

How well this will go we gonna see but im very optimistic that it will be mind blowing in terms of State of the Art vs MPEG ;)

And when we gonna see FHI and HHI joining in as well that would be some ice cream on top ;)

One common Goal no back stabbing each other that is the way to move forward :)

And who knows maybe we gonna see even the BBC with Dirac joining in :)

But first up will be optimizing the Entire Alliances Interaction Structure to even be more efficient and friendly to it's participants then MPEGs/ITUs here i see first problems arising as everyone their has their own company and OOS ideas of this ;)

Fast drafting, Fast response, low delays ect ect ect but im sure that this 1 common Goal can make those vanishing fast at least i hope for a more flexible structure.

Which then obviously gonna result in faster progression times :)

nevcairiel

30th September 2015, 11:47

Dolby Vision is annoying, they should stick to the HDR metadata that UHD Blu-ray favors (SMPTE ST- 2084/2086). It needs far less decoder changes.

kolak

30th September 2015, 14:50

Dolby Vision won't catch up, as it cost to much money in licensing.

dapperdan

4th February 2016, 16:41

Apparently work has begun:

https://chromium.googlesource.com/webm/aom/
https://chromium-review.googlesource.com/#/q/project:webm/aom

Mostly based on VP9/10 to start with.

benwaggoner

6th February 2016, 00:24

Dolby Vision is annoying, they should stick to the HDR metadata that UHD Blu-ray favors (SMPTE ST- 2084/2086). It needs far less decoder changes.
The 2086 metadata is static across an entire title, so it still requires a lot of prediction and MIPS for a display's tone mapper to adapt to per-scene changes in color volume or contrast.

And it's really not that valuable. A single flash frame from a camera flash can double the MaxFALL the whole rest of the title would use, and thus be very misleading for a tone mapper.

Nintendo Maniac 64

5th April 2016, 22:01

AMD, ARM, and Nvidia have joined, and because it apparently wasn't established before, this new upcoming in-development video codec will be an open-source project:
http://aomedia.org/press-release/the-alliance-for-open-media-welcomes-new-members-and-announces/

Hopefully AMD will finally implement VP9 hardware decoding on their upcoming APUs and GPUs...

mandarinka

5th April 2016, 22:18

All reference encoders/decoders are open source (H.264, H.265, VP8/9), so that was obvious. The distinction was never in open versus closed source anyway.

After all the development model is more or less the same, but probably with faster development and less testing/reviewing than the MPEG guys do, if libvpx traditions are any sign. So possibly there will again be few bugs in the frozen specification, like VP9/VP8 had :D

The only difference between these "libre" (or whatever term is currently in) codecs and H.264/H.265/... is really in the patent licensing requirements and usage royalties.

dapperdan

6th April 2016, 12:55

I don't think they're announcing that it's open source, but that it is available and mentioning in passing that it's open source. Though I think it's actually been available already, so this is just an official announcement that it's available.

In other oddities, the new members are being given "founder member" status, even though they're joining a while after the others.

Finally, the link seems to point just to the patent licence info (possibly the page will be updated to point to the actual code) but it appears to live here:

https://aomedia.googlesource.com/aom/

A notably non-impartial place to host the code I would have thought, though it's all git in the end.

Nintendo Maniac 64

7th April 2016, 01:08

In other oddities, the new members are being given "founder member" status, even though they're joining a while after the others.

Well they're all chip hardware designers...Intel was the only chip hardware designer that was a member, so there could have very well been several more "vacancies" for other chip hardware designers as well.

In other words, maybe because Intel was previously the only chip hardware designer, the group as a whole left the door open for other chip hardware designers?

BadFrame

10th April 2016, 03:47

AMD, ARM, and Nvidia have joined,

Interesting, seems like they got the hardware support largely covered with these new members.

mandarinka

13th April 2016, 13:44

http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=110383

When will the codec ship? The group is aiming to freeze the bitstream sometime between the end of the 2016 and March 2017. Expect to see browser-based support soon thereafter, with the first hardware support within 12 months after that.

On the one hand that is soon, on the other hand this is not much time for research/development. Hopefully it won't have bugs in spec this time, but this probably means they will have to stick with most of libvpx since that is what AV1 its currently built upon, and other IP will only be patches on the top.

Clare

13th April 2016, 18:34

http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=110383

On the one hand that is soon, on the other hand this is not much time for research/development. Hopefully it won't have bugs in spec this time, but this probably means they will have to stick with most of libvpx since that is what AV1 its currently built upon, and other IP will only be patches on the top.

Both Daala and AV1 are already well advanced if one looks at AWCY:
https://arewecompressedyet.com/?r%5B%5D=avi1-master-2016-04-12T22-04-25.017Z&r%5B%5D=jm-dering-sync-2016-04-11T19-22-42.950Z&r%5B%5D=x265-ntt-short-1.8-try-1&s=ntt-short-1

Also, the VP10 basis it is built upon does not seem to take all development happening in the nextgenv2 branch. So they could potentially add more feat. already developed from VP10 later.

I'm more concerned at the processing power needed for encoding.

mandarinka

13th April 2016, 21:20

Speed is inconsequential IMHO, even if it was 2-4x+ as slow as optimised HEVC or VP9 encoder, that would be soemthing that would be solvable - if by nothing else, by throwing more CPU cores there.

My fear is that the problems are going to be the same as with VP8/VP9 and (to a lesser degree, it has matured somewhat) x265: the encoder will be too fresh, too crude, without good rate control and lacking in utilisation of the new compression tools. The advances of format will be probably negated by poor quality encoder. This problem is hard and practice shows it takes years to improve. I think CPU requirements are nothing compared to that.

wiak

25th April 2016, 19:53

did some testing
https://nwgat.ninja/test-driving-aomedias-av1-codec/
http://screenshotcomparison.com/comparison/170492

mandarinka

25th April 2016, 21:21

did some testing
https://nwgat.ninja/test-driving-aomedias-av1-codec/
http://screenshotcomparison.com/comparison/170492

That nicely noisy output, is that with PVQ enabled? (IIRC Daala guys worked on porting it to AV1.)

wiak

26th April 2016, 16:20

That nicely noisy output, is that with PVQ enabled? (IIRC Daala guys worked on porting it to AV1.)
i dont think so, i did a mirror of the aom googlesource git repo to github for simpler reading
https://github.com/nwgat/aom/search?utf8=✓&q=Perceptual+Vector+Quantization
https://github.com/nwgat/aom/search?utf8=✓&q=PVQ&type=Code

Jamaika

29th April 2016, 08:13

Could someone compile the latest codec AOM?:thanks:

PS Is the job suspended on the development of the codec? I don't see updates (https://github.com/jmvalin/aom/commits/master).

dapperdan

29th April 2016, 13:40

The main repo is currently here:

https://aomedia.googlesource.com/aom/

which has more recent commits, though nothing in the last couple of weeks

mzso

2nd May 2016, 21:10

Isn't there some information about the internals of this codec? Does it have something innovative like lapped transfrom (was supposed to be) for Daala.

BadFrame

3rd May 2016, 11:04

Isn't there some information about the internals of this codec? Does it have something innovative like lapped transfrom (was supposed to be) for Daala.

I haven't seen any documentation, likely because the development is still in a 'let's try everything' phase, with the bitstream being locked down by the end of the year (at the earliest).

Also there are a lot of different branches where work is being done, here is a branch with Daala techniques being tested:

https://chromium-review.googlesource.com/#/q/project:webm/aom

Here is what I believe is the official AOM branch:

https://aomedia.googlesource.com/aom/

And here is the 'nextgenv2' branch, where there's a lot of work done at a rapid pace:

https://chromium.googlesource.com/webm/libvpx/+log/nextgenv2

mzso

3rd May 2016, 13:22

I was thinking more in the vein of the Daala demos. About roughly what novel/innovative ideas they have in the air. (If they have any)

dapperdan

3rd May 2016, 15:03

There was a video about VP10, I think it was linked from a thread here, which probably mostly applies.

https://www.youtube.com/watch?v=gkz1ZvejmEc

I've not watched it for a while, but I'm not sure there was anything particularly novel in the Daala sense of trying new things that won't have been patented, just the usual incremental improvements.

Jamaika

5th July 2016, 20:36

benwaggoner

6th July 2016, 00:44

First tests codec, which will be released in March 2017.
http://www.cnx-software.com/2016/07/03/aomedia-av1-is-a-royalty-free-open-source-video-codec-aiming-to-replace-vp9-and-compete-with-h-265/
I am surprised the wording.
The command will encode all y4m files in the directory at 200 kbps up to 500 kbps at a 50 kbps increment. Encoding only uses one core, my machine is powered by AMD FX8350 processor, and you can see encoding is currently very slow well under 0.5 fps for a CIF video (352 x 288 resolution), but that should be expected because VP9 encoding is already slow (its successor is expected to require even more processing power), and first software implementations are usually not optimized for speed, they are just meant to show the encoding works.
Reference encoders are always super-slow*. The official reference implementations for H.264 and HEVC are about 100th the speed of x264 and x265 and lack lots of critical features. All the SIMD and multithreading work goes into production implementations.

* The one exception being VC-1, since that was actually done from the WMV9 decoder porting kit, and thus accidentally was full of real-world features and optimizations :).

Jamaika

6th July 2016, 03:15

I didn't know that codec is reference. Supposedly it is based on the codec VP10, even Ligh once compiled, but may test off some function. In a word, there is nothing to build a codec AV1.

easyfab

6th July 2016, 07:23

It's very slow because he use run_tests that use best settings ( like placebo for x264/x265 ) and 1 thread.
He should test with more realistic setting --cpu-used=1 or 2 and add threads -t 4, with that it should be really faster.

easyfab

6th July 2016, 18:57

I made a quick test :

source : Kimono1_1920x1080_24

x264 --preset veryslow --crf 23 : file output 6.38 Mo ( bitrate 5351 kbps ) ssim 0.955018 psnr 41.056804
x265 --preset slow 2 pass : 6.28 Mo ssim 0.960803 psnr 42.029059
x265 --preset slow 2 pass : 6.42 Mo ssim 0.961065 psnr 42.070003
vp9 -cpu-used 1 2 pass : 6.29 mo ssim 0.960090 psnr 41.922800

and for av1 -cpu-used 1 2 pass : 6.43 ssim 0.961722 psnr 42.229238

so only a little better than vp9 and x265 for the moment.

benwaggoner

6th July 2016, 21:20

Jamaika

7th July 2016, 04:51

so only a little better than vp9 and x265 for the moment.
Maybe an interesting comparison, but ...
I don't know if there are any differences between the VP10 and AV1.
Nor do I know what the results seeks by the manufacturer. I don't know ranges of SSIM and PSNR. Could use a graph.
I would have also posting links encoders, because I understand that you tested the latest versions. (Next2)
https://aomedia-review.googlesource.com/#/q/status:merged
https://chromium-review.googlesource.com/#/q/vp10

PS What puzzles me? New patches codec vp10 aren't included in the codec AV1.

bstrobl

7th July 2016, 09:40

PS What puzzles me? New patches codec vp10 aren't included in the codec AV1.

As far as I know, only the best patches that have been properly tested get merged into AV1.

AreWeCompressedYet (https://arewecompressedyet.com/?s=ntt-short-1) shows minor improvements of AV1 when compared to HEVC/VP9 in areas of PSNR/PSNR-HVS/SSIM (FastSSIM seems to be more problematic). Not sure how they are going to achieve a doubling of efficiency when compared to HEVC by 2017 however.

mzso

7th July 2016, 13:42

Maybe an interesting comparison, but ...
I don't know if there are any differences between the VP10 and AV1.
Nor do I know what the results seeks by the manufacturer. I don't know ranges of SSIM and PSNR. Could use a graph.
I would have also posting links encoders, because I understand that you tested the latest versions. (Next2)
https://aomedia-review.googlesource.com/#/q/status:merged
https://chromium-review.googlesource.com/#/q/vp10

PS What puzzles me? New patches codec vp10 aren't included in the codec AV1.

VP10 is not AV1. AV1 is built only in part on VP10, at least it's supposed to be. How much of it is from Daala or Thor or whatever I can't say.

dapperdan

7th July 2016, 14:08

VP10 is not AV1. AV1 is built only in part on VP10, at least it's supposed to be. How much of it is from Daala or Thor or whatever I can't say.

I think it's fair to say that AV1 is VP10 at the moment. As tech or patents or coding contributions come from other parties now then it may grow to be something different, but as a starting point it was and mostly still is the libvpx VP10 codebase. At what percentage of code or ideas it stops being VP10 is of course debatable, and they certainly want to be a collaborative project going forward, but yeah, I don't think it's a misleading shorthand to say AV1 is VP10.

Jamaika

7th July 2016, 14:59

I think it's fair to say that AV1 is VP10 at the moment.
There was such a suggestion. Codec AOM replaces VP10, Daala, Thor, HEVC. Anyway what for they did to the alliance. VP10 disappears. I see that these are two paths of development, ie said Clare.
The AOM (Alliance of Open Media) codec is based upon VP10 (which is still in heavy development as a separate branch), but they will use any useful technology which their members have access to, for example if you look at the AOM branch, there are Daala features being added:

https://chromium-review.googlesource.com/#/q/project:webm/aom

I don't know if VP10 will actually materialise as a separate stable codec release or if it will be decprecated as it is the base of the AOM codec (depends on how long it will take to develop I guess).
It can and is based on the codec vp10, just don't know it or not version a few months ago.

Quikee

8th July 2016, 08:53

VP10 is not AV1. AV1 is built only in part on VP10, at least it's supposed to be. How much of it is from Daala or Thor or whatever I can't say.

Some things from daala and thor is in AV1 AFAICS - mainly the deringing filter (daala) and CLP filters (thor) are and multi-symbol entropy coder from daala (which might be replaced by rANS as it is faster and has similar efficiency) PVQ is still a WIP to integrate into AV1 - which might be quite interesting..

Quikee

8th July 2016, 09:07

Not sure how they are going to achieve a doubling of efficiency when compared to HEVC by 2017 however.

It may possibly be that they won't double the efficiency but just be marginally worse or better. It is much more important that they release a codec "soon" so they establish a base and offer a viable alternative to HEVC.

mzso

8th July 2016, 12:16

mandarinka

8th July 2016, 12:33

Some things from daala and thor is in AV1 AFAICS - mainly the deringing filter (daala) and CLP filters (thor) are and multi-symbol entropy coder from daala (which might be replaced by rANS as it is faster and has similar efficiency) PVQ is still a WIP to integrate into AV1 - which might be quite interesting..

I'm not sure Daala stuff is integrated in the sense that it is definitely going to land in the final format. They adapted it or are adapting it into the same codebase so that it can be evaluated at all. The tools will have to prove their worth and/or fight their way into it in the committees/politics/visions clashes :) Lots of stuff currently in the codebase will be dropped from the final format, likely.

If On2/Google has main say in development, they might hamper adoption of stuff from Mozilla/Xiph because NIH mentality. (Well, let's hope such pety things will be kept in check there, but people often tend to behave like that sadly.)

mzso

8th July 2016, 14:10

Quikee

10th July 2016, 03:48

I'm not sure Daala stuff is integrated in the sense that it is definitely going to land in the final format. They adapted it or are adapting it into the same codebase so that it can be evaluated at all. The tools will have to prove their worth and/or fight their way into it in the committees/politics/visions clashes :) Lots of stuff currently in the codebase will be dropped from the final format, likely.

I never said any of it will be final in AV1 format - just that it currently is or isn't part of the AV1 codebase yet. Of course things that won't show gains (or show gains but increase complex too much) will probably be dropped.

If On2/Google has main say in development, they might hamper adoption of stuff from Mozilla/Xiph because NIH mentality. (Well, let's hope such pety things will be kept in check there, but people often tend to behave like that sadly.)

If they want inclusive development this won't happen. If there are two tools that have similar gain they will together decide which one to keep and which to drop (that's why they have regular meetings). IPR and what hardware vendors say would be a big factor in such a decision.

Quikee

10th July 2016, 03:56

So, no chance for lapped transformation from daala?

No, lapped transform is too invasive - they would need to change almost everything, which would not make sense to select VP10 as the base.

wiak

12th July 2016, 16:17

if anyone is interested i have a compiled win64 version here
https://awesome.nwgat.ninja/aomedia/av1-daf841b-win64.7z

Jamaika

12th July 2016, 16:56

:thanks:
Test hier (http://forum.doom9.org/showthread.php?p=1773771#post1773771)

wiak

18th July 2016, 10:41

another fresh build
https://f001.backblaze.com/file/nwgat-aom/av1-git-1195a39-win64.7z

Jamaika

18th July 2016, 11:09

The problem with dropframe (CBR) (http://forum.doom9.org/showthread.php?p=1774553#post1774553). This is a test version so I close my eye.;)

PS Will there be a link to all versions? ;)

Jamaika

21st July 2016, 15:08

Interesting article: disadvantages / advantages
vp9 vs av1 vs hevc

A view on VP9 and AV1 part 1: specifications (http://www.gpac-licensing.com/2016/07/12/vp9-av1-bitstream-format/)

PS Could gpac interested in the introduction of the codec google to the container mp4?

•There is no such thing as VP9 or AV1 File Format (AVC/HEVC has raw, Annex B, and canonical/MP4). One needs to use the IVF File Format or WebM.
There is no such thing as VP9 or AV1 because it must be given the name of the codec. IVF isn't a container. It is a labor saving by decoder. You can use the MOV container.
mkvextract.exe tracks vp9/av1.webm 0:output.ivf

Nintendo Maniac 64

27th July 2016, 05:34

There is in fact such a thing as a raw VP9 - that's what YouTube uses, but they still end in a .webm extension. The biggest difference I notice is that some programs just give visual garbage when playing back raw VP9 files yet work perfectly file with a "proper" VP9/WebM video - Avidemux and VLC come to mind.

blurred

3rd August 2016, 23:25

There is a Wikipedia article:

https://en.wikipedia.org/wiki/AOMedia_Video_1

wiak

11th August 2016, 16:35

fresh build
https://f001.backblaze.com/file/nwgat-aom/av1-git-4c46278-win64.7z

Jamaika

11th August 2016, 17:33

Anyone can tell me what is aq-mode equator360?

wiak

12th August 2016, 05:52

Anyone can tell me what is aq-mode equator360?
something do do with youtube 3d mode? meybe a MVC competitor, dunno

PS: just asked on irc, lets see if i get a answer

Blue_MiSfit

13th August 2016, 01:29

Nice simple CLI.

aomenc --best --end-usage=vbr --target-bitrate=1000 --kf-max-dist=96 --width=1920 --height=1080 -o monkeys_1080p_1000.webm monkeys.yv12

This triggers an automated 2 pass encode.

Wow this is slow :D. The first pass ran at ~21fps on my 3.4 GHz quad core Skylake. The second pass is doing 18 fpm / .3 fps. No word on quality yet. I've got awhile to go :)

Threading seems to kind of work, it's getting 50% CPU usage on my box.

I'm willing to bet that the equator360 thing is related to equirectangular panoramas, which are used to deliver 360 video. It's an optical projection that lets you smash 360 degrees of video into a standard 2 dimensional frame.

If anyone knows how to optimize this sucker for perceptual quality, please share! I'm guessing turning variance AQ on will be a good idea for visual tests but not for metrics. Is this a useful feature?

Blue_MiSfit

13th August 2016, 01:30

For the lazy, here's the CLI reference:

Usage: aomenc <options> -o dst_filename src_filename

Options:
-D, --debug Debug mode (makes output deterministic)
-o <arg>, --output=<arg> Output filename
--codec=<arg> Codec to use
-p <arg>, --passes=<arg> Number of passes (1/2)
--pass=<arg> Pass to execute (1/2)
--fpf=<arg> First pass statistics file name
--limit=<arg> Stop encoding after n input frames
--skip=<arg> Skip the first n input frames
-d <arg>, --deadline=<arg> Deadline per frame (usec)
--best Use Best Quality Deadline
--good Use Good Quality Deadline
--rt Use Realtime Quality Deadline
-q, --quiet Do not print encode progress
-v, --verbose Show encoder parameters
--psnr Show PSNR in status line
--webm Output WebM (default when WebM IO is enabled)
--ivf Output IVF
-P, --output-partitions Makes encoder output partitions. Requires IVF output!
--q-hist=<arg> Show quantizer histogram (n-buckets)
--rate-hist=<arg> Show rate histogram (n-buckets)
--disable-warnings Disable warnings about potentially incorrect encode settings.
-y, --disable-warning-prompt Display warnings, but do not prompt user to continue.
--test-decode=<arg> Test encode/decode mismatch
off, fatal, warn

Encoder Global Options:
--yv12 Input file is YV12
--i420 Input file is I420 (default)
--i422 Input file is I422
--i444 Input file is I444
--i440 Input file is I440
-u <arg>, --usage=<arg> Usage profile number to use
-t <arg>, --threads=<arg> Max number of threads to use
--profile=<arg> Bitstream profile number to use
-w <arg>, --width=<arg> Frame width
-h <arg>, --height=<arg> Frame height
--stereo-mode=<arg> Stereo 3D video format
mono, left-right, bottom-top, top-bottom, right-left
--timebase=<arg> Output timestamp precision (fractional seconds)
--fps=<arg> Stream frame rate (rate/scale)
--error-resilient=<arg> Enable error resiliency features
--lag-in-frames=<arg> Max number of frames to lag

Rate Control Options:
--drop-frame=<arg> Temporal resampling threshold (buf %)
--resize-allowed=<arg> Spatial resampling enabled (bool)
--resize-width=<arg> Width of encoded frame
--resize-height=<arg> Height of encoded frame
--resize-up=<arg> Upscale threshold (buf %)
--resize-down=<arg> Downscale threshold (buf %)
--end-usage=<arg> Rate control mode
vbr, cbr, cq, q
--target-bitrate=<arg> Bitrate (kbps)
--min-q=<arg> Minimum (best) quantizer
--max-q=<arg> Maximum (worst) quantizer
--undershoot-pct=<arg> Datarate undershoot (min) target (%)
--overshoot-pct=<arg> Datarate overshoot (max) target (%)
--buf-sz=<arg> Client buffer size (ms)
--buf-initial-sz=<arg> Client initial buffer size (ms)
--buf-optimal-sz=<arg> Client optimal buffer size (ms)

Twopass Rate Control Options:
--bias-pct=<arg> CBR/VBR bias (0=CBR, 100=VBR)
--minsection-pct=<arg> GOP min bitrate (% of target)
--maxsection-pct=<arg> GOP max bitrate (% of target)

Keyframe Placement Options:
--kf-min-dist=<arg> Minimum keyframe interval (frames)
--kf-max-dist=<arg> Maximum keyframe interval (frames)
--disable-kf Disable keyframe placement

AV1 Specific Options:
--cpu-used=<arg> CPU Used (-8..8)
--auto-alt-ref=<arg> Enable automatic alt reference frames
--sharpness=<arg> Loop filter sharpness (0..7)
--static-thresh=<arg> Motion detection threshold
--tile-columns=<arg> Number of tile columns to use, log2
--tile-rows=<arg> Number of tile rows to use, log2
--arnr-maxframes=<arg> AltRef max frames (0..15)
--arnr-strength=<arg> AltRef filter strength (0..6)
--arnr-type=<arg> AltRef type
--tune=<arg> Material to favor
psnr, ssim
--cq-level=<arg> Constant/Constrained Quality level
--max-intra-rate=<arg> Max I-frame bitrate (pct)
--max-inter-rate=<arg> Max P-frame bitrate (pct)
--gf-cbr-boost=<arg> Boost for Golden Frame in CBR mode (pct)
--lossless=<arg> Lossless mode (0: false (default), 1: true)
--frame-parallel=<arg> Enable frame parallel decodability features (0: false (default), 1: true)
--aq-mode=<arg> Adaptive quantization mode (0: off (default), 1: variance 2: complexity, 3: cyclic refresh, 4: equator360)
--frame-boost=<arg> Enable frame periodic boost (0: off (default), 1: on)
--noise-sensitivity=<arg> Noise sensitivity (frames to blur)
--tune-content=<arg> Tune content type
default, screen
--color-space=<arg> The color space of input content:
unknown, bt601, bt709, smpte170, smpte240, bt2020, reserved, sRGB
--min-gf-interval=<arg> min gf/arf frame interval (default 0, indicating in-built behavior)
--max-gf-interval=<arg> max gf/arf frame interval (default 0, indicating in-built behavior)

Stream timebase (--timebase):
The desired precision of timestamps in the output, expressed
in fractional seconds. Default is 1/1000.

Included encoders:

av1 - AOMedia Project AV1 Encoder v0.1.0 (default)

Use --codec to switch to a non-default encoder.

Jamaika

13th August 2016, 08:00

If anyone knows how to optimize this sucker for perceptual quality, please share! I'm guessing turning variance AQ on will be a good idea for visual tests but not for metrics. Is this a useful feature?
Well colleague worked hard. ;)
Firstly, it isn't known how long the source you applied. If this is the first 100 frames that each test is preposterous. Too much distortion bitrate.
You have not entered the framerate. I guess after the GOP, it was 48fps or 24fps.
You mentioned about changing the functions aqmode to variance. All beautifully, it is to improve because bitrate does not make the setpoint and is 1.5 times greater.
I am an advocate for the conversion of vbr to cbr and boost 300. Otherwise they are too sharp edges.
The most important. How to excite, as there is no player.

Motenai Yoda

16th August 2016, 03:56

@Blue_MiSfit IIRC the devs suggest to use good and cpu-used 1 as it give roughtly the same quality as best (at least on vp9/10)
also on vp9 using aq degrade quality a bit (maybe overweighted?)

maybe auto-alt-ref and lag-in-frames will help.

wiak

17th August 2016, 06:48

another build
av1-git-d847070-win64.7z (https://f001.backblaze.com/file/nwgat-aom/av1-git-d847070-win64.7z)

:stupid:

easyfab

17th August 2016, 10:20

I didn't test recently, but I don't see alot of new things to test according to the commits, I hope until the release of AV1 ( december 2016 to march 2017 ) there will be some .

@wiak is your build with default settings or did you include some experimental settings ? the list (https://aomedia.googlesource.com/aom/+/master/configure#248)

wiak

17th August 2016, 19:45

Jamaika

18th August 2016, 09:19

Codec AV1-git-d847070 is still underdeveloped. Problems or inconsistencies resulting from the explanation of some functions.

The problem of different bitrates.
aomenc.exe -v --threads=4 --width=1920 --height=1080 --i420 --profile=0 --fps=30000/1001 --best --codec=av1 --cpu-used=0 --passes=2 --pass=2 --fpf=aom.pass --drop-frame=100 --kf-max-dist=60 --target-bitrate=3500 --frame-boost=1 --end-usage=cbr --gf-cbr-boost=300 --max-intra-rate=110 --bias-pct=50 --maxsection-pct=3000 --aq-mode=1 --kf-max-dist=60 --color-space=bt709
or
aomenc.exe -v --threads=4 --width=1920 --height=1080 --i420 --profile=0 --fps=30000/1001 --best --codec=av1 --cpu-used=0 --passes=2 --pass=2 --fpf=aom.pass --drop-frame=100 --kf-max-dist=60 --target-bitrate=0 --cq-level=34 --frame-boost=1 --end-usage=q --bias-pct=50 --gf-cbr-boost=200 --max-inter-rate=130 --maxsection-pct=2000 --aq-mode=1 --kf-max-dist=60 --color-space=bt709

The loss of video quality at the bitrate of 3500kbps, in fact 4000-4300kbps depending on the mode aq-mode.
For mode VBR (default) is a significant drop in compression frame {about 400KB for PNG} in relation to the original. It is synonymous with a decrease in quality. The biggest issue is slightly rough surfaces that lose their roughness and are sharp edges ex. subtitles. For the X265 {veryslow} is the order of 300kb, which is less lost data and has set value bitrate for 2pass.

Overview the functions:
"drop-frame" is correct display frame rates for movies about XX000/1001 fps. Not the task of this function is that the value fps is overvalued and is a little greater, eg. 30.033. In fact, the codec itself should adapt dropframe without the user's knowledge, but it is not. For mode CBR function "drop-frame" is with errors.
"gf-cbr-boost" mode golden frame (P or B). The construction of this frame is mysterious and complex. These frames aren't displayed and retain data for the P-frame depend on the function "auto-alt-ref". The best setting codec when turned off "auto-alt-ref". To try to match the quality of CBR to VBR is to raise bitrate golden frame by 300%. The value of the frame I by 110%. Note: Do not turn on the "frame-boost". This function is only for mode "end-usage=q".
"bias-pct" is a hash of two modes frames VBR and CBR. How not to set the best variant is 50% to 50%. Otherwise, the film is visibly pale.
"color-space" bt2020. It is now fiction. As you know ffmpeg converter converts the bt601 and then to the set. In addition, the codec is 8 bit.
"maxsection-pct" as not to describe it is a dead function. Change the value with 2000% to 3000% doesn't contribute to improving the quality of frames???

06_taro

25th August 2016, 15:36

Vanilla nightly builds for Win64, with high bit depth enabled. Should be able to output 8 / 10 / 12 bit av1. Encoder consumes too much RAM, so no 32bit build.
http://tmod.nmm-hd.org/aom/

Built daily if there are new commits. Old builds will be removed occasionally.

Also added av1 decoding (8/10/12 bit) for LAVFilters in http://tmod.nmm-hd.org/LAVFilters/ with latest libaom, thanks to Libav patches #61173 (https://patches.libav.org/patch/61173/) and #61174 (https://patches.libav.org/patch/61174/) and VFR-maniac's patch (https://github.com/VFR-maniac/LAVFilters/commit/690bf3ad551788789a5a08239d3d6e2e3b4839ae) for LAVFilters. Both were somewhat modified and placed in patches folder.

BTW, the encoder seems not stable enough that 4K encoding usually causes crashes on windows, and even 720p 10-bit encoding results in abort trap 6 on OS X. Decoding with LAVFilters seems to be fine now, but further test is still needed.

Jamaika

26th August 2016, 05:56

Vanilla nightly builds for Win64, with high bit depth enabled. Should be able to output 8 / 10 / 12 bit av1. Encoder consumes too much RAM, so no 32bit build.
I should be here more explanation of how it works new codec AV1.
--test-16bit-internal Force use of 16 bit internal buffer
--bit-depth=<arg> Bit depth for codec (8 for version <=1, 10 or 12 for version 2)
8, 10, 12
http://codecs.multimedia.cx/wp-content/uploads/2016/02/Diagram1.png

What does the function 'test-16bit-internal' and what kind has application? Is it a function input of 16bit RGB? How to create command output colormatrix 16bit sRGB? Is there a mode full range?
I also understand that the bit-depth means the quality of a signal quantization of the processing stage, eg. in the preview.
Also added av1 decoding (8/10/12 bit) for LAVFilters
Great, but the decoder must be registered in Windows. Otherwise player MPC-HC crashes. And a pity that there is no decoder Daala.;)

ls1dreams

26th August 2016, 23:49

When does everyone think we'll get hardware decoding from intel chips?

I'm really frustrated with my laptops getting super hot just playing the most simple videos, google hangouts, etc.

For example, VP9 came out in 2013, and even today, 3 years later, we still don't have a chip that does full hardware decoding (only partial). Kaby Lake will resolve this, but it will have been 4 years. The same goes for HEVC.

Having a slightly smaller stream hardly matters to me if it means my cpu is spinning up to 50% utilization or higher.

AV1 seems to have everyone on board, but when will we get an igpu (macbooks/etc) that supports it? Kaby Lake is obviously out. Cannon Lake too soon?

I'm overdue for upgrading my laptop, but don't really want to wait 2 more years for this! I just want to play 4k videos on a macbook retina without the machine overheating. (Hell, even 720p or 1080p).

mzso

27th August 2016, 11:09

mandarinka

27th August 2016, 12:15

Make sure you are using FFVP9 decoder. Chrome uses the libvpx instead (bad, inefficient). I think Firefox adopted FFVP9, but I have no idea if it is used on the Apple OS X.

No idea if the Intel drivers that implement the partial acceleration even work/are available on the platform (or Linux). If they don't, you could try under Windows and see if the partial acceleration works under 4K - not sure there.

IgorC

27th August 2016, 12:37

I have tried https://media.xiph.org/video/derf/webm/Netflix_Aerial_4096x2160_60fps_10bit_420.webm chrome was the fastest.

The solution is simple. Don't buy an intel based computer, if you want stuff supported.
Intel was first to support VP9 decoding (at least hybrid). Anyway I don't see anyone doing better. "not buying Intel" doesn't solve anything.

hajj_3

27th August 2016, 16:10

When does everyone think we'll get hardware decoding from intel chips?

I think the AV1 codec is supposed to have hardware decoding available starting at the end of 2017 iirc. That will likely be from ARM and Qualcomm i suspect. Hardware decoding is way more important for those companies than it is for laptops and desktops. I suspect that by mid-2018 all intel and amd apus will have it and all amd and nvidia gpus.

wiak

27th August 2016, 17:02

I think the AV1 codec is supposed to have hardware decoding available starting at the end of 2017 iirc. That will likely be from ARM and Qualcomm i suspect. Hardware decoding is way more important for those companies than it is for laptops and desktops. I suspect that by mid-2018 all intel and amd apus will have it and all amd and nvidia gpus.
i suspect amd navi and nvidia voltra will support it and chips based on them (it takes 2-3 years from planning to release of a new gpu)
if you want to play modern codecs, you should get a proper pc not some underpowered laptop
laptop are made to be portable and low power
:stupid:

Nintendo Maniac 64

29th August 2016, 03:56

mzso

29th August 2016, 15:18

Since AMD's Zen cores are intended to scale all the way down to power consumption levels that are similar to their Jaguar cores, it's theoretically possible that AMD will be more proactive in implementing AV1 hardware decoding in their Zen APUs since it'll be much more important for such low-power form-factors.

http://forum.doom9.org/attachment.php?attachmentid=15553

Yeah... That attachment will probably never be approved. :)

hajj_3

30th August 2016, 10:53

Since AMD's Zen cores are intended to scale all the way down to power consumption levels that are similar to their Jaguar cores, it's theoretically possible that AMD will be more proactive in implementing AV1 hardware decoding in their Zen APUs since it'll be much more important for such low-power form-factors.

http://forum.doom9.org/attachment.php?attachmentid=15553

zen apus are supposed to be out in mid 2017, can't see av1 hardware decoding being available in zen apus, possibly hybrid decoding if you are lucky. Zen+ will likely have it though.

Nintendo Maniac 64

6th September 2016, 07:20

Some presentations from VideoLAN Dev Days 2016 that may or may not be relevant:

VideoLAN Dev Days 2016: Daala (https://www.youtube.com/watch?v=AOssZFJ0EdI)

VideoLAN Dev Days 2016: Update on VPX (https://www.youtube.com/watch?v=peS2I14w8ow)

Yeah... That attachment will probably never be approved. :)

Then stand back and watch as I cheat the system! :p

http://i.imgur.com/6uS6Ab9.png

dapperdan

6th September 2016, 12:27

Another related video talk, on the Eve VP9 encoder:

https://www.youtube.com/watch?v=t_z52-CBut0

littlepox

7th September 2016, 17:29

I'd guess AMD spend half of their R&D budget on PPT design.
Really, I'd be interested to buy some templates from them for my own use.

Jamaika

11th September 2016, 06:38

New web codec AOM. Codec VP10 turned into to AV1.
https://chromium.googlesource.com/webm/libvpx/+/nextgenv2
https://github.com/mbebenita/aomanalyzer
Websites obsolete:
https://github.com/jmvalin/aom
https://github.com/smarter/aom

Clare

30th September 2016, 15:52

I do hope they will rework the encoder completely instead of relying on the current libvpx one because that encoder is way too slow.

sneaker_ger

20th October 2016, 19:58

What problem? Error message?
Please stop filling AV1/Daala/VP9 threads with your ffmpeg and color troubles. Make new threads in the newbie section.

Jamaika

20th October 2016, 22:34

Problem with conversion
https://www.sendspace.com/file/2qnw7j

Jamaika

31st October 2016, 08:58

benwaggoner

1st November 2016, 14:39

No one probably doesn't know what effect it has value of quality "min-q". The first frame is always a big mistake for added value for codec VPX and AV1.

In the VPx series, "min-q" always set the minimum quality. No frame would be encoded with a quality less than that IIRC, depending on other settings, this could lead to either dropped frames or increased bitrate (historically there wasn't a VPx "VBV" to violate, but that is changing with AOM).

Jamaika

1st November 2016, 14:58

I didn't notice dropped frames. However, the bitrate of the first frame I is 2x larger or less than others frames I. It depends on the aspect ratio video. Why is it like that? Only the creator knows.
(historically there wasn't a VPx "VBV" to violate, but that is changing with AOM).
We'll see how Elecard release free analyzer. It is only known that the AOM is based on VP9

benwaggoner

1st November 2016, 16:43

I didn't notice dropped frames. However, the bitrate of the first frame I is 2x larger or less than others frames I. It depends on the aspect ratio video. Why is it like that? Only the creator knows.
Bigger perhaps due to initial buffer fullness assumptions. This was a VPx parameter.

Why it would depend on aspect ratios is baffling. Was this different content aspect ratios in square pixel, or different SARs? If you have a repro-able bug, it should get passed on to the AOM folks.

Jamaika

1st November 2016, 17:12

Thanks for hints. Indeed AOM fixed problem first frame I. No need to to use min-q for the FullHD. To test this, I used the analyzer mkvinfo.
mkvinfo -s av1.webm >> av1.txt
Unfortunately, I can't create (profile 3) movies 4K. Encoder requires 16MB RAM. I've got too old for computer. :(
Track 1: video, codec ID: V_AV1, mkvmerge/mkvextract track ID: 0, pixel width: 2048, pixel height: 1152, yuv422p10le (profile 3), min-q=0
I frame, track 1, timecode 0 (00:00:00.000), size 166818, adler 0x00b4b52f
...
I frame, track 1, timecode 2000 (00:00:02.000), size 151294, adler 0x7c901f15
...
I frame, track 1, timecode 4000 (00:00:04.000), size 153129, adler 0xf2b726d9
...
I frame, track 1, timecode 6000 (00:00:06.000), size 163401, adler 0xb73093d4
...
I frame, track 1, timecode 8000 (00:00:08.000), size 184388, adler 0x19ddc916
Track 1: video, codec ID: V_AV1, mkvmerge/mkvextract track ID: 0, pixel width: 3840, pixel height: 2160, yuv420p10le (profile 2), min-q=0
I frame, track 1, timecode 0 (00:00:00.000), size 483939, adler 0x9517be61
...
I frame, track 1, timecode 2000 (00:00:02.000), size 379716, adler 0x3066620a
...
I frame, track 1, timecode 4000 (00:00:04.000), size 385909, adler 0x409e46ec
...
I frame, track 1, timecode 6000 (00:00:06.000), size 402404, adler 0xfe265630
...
I frame, track 1, timecode 8000 (00:00:08.000), size 380221, adler 0x36dd028a
...
I frame, track 1, timecode 10000 (00:00:10.000), size 498620, adler 0x16fbcc9d
...
I frame, track 1, timecode 12000 (00:00:12.000), size 414623, adler 0xa940b1b2
Track 1: video, codec ID: V_AV1, mkvmerge/mkvextract track ID: 0, pixel width: 3840, pixel height: 2160, yuv420p10le (profile 2), min-q=5
I frame, track 1, timecode 0 (00:00:00.000), size 346569, adler 0x2f11e1bc
...
I frame, track 1, timecode 2000 (00:00:02.000), size 340183, adler 0x2be6ca69
...
I frame, track 1, timecode 4000 (00:00:04.000), size 341161, adler 0xcdc0e26d
...
I frame, track 1, timecode 6000 (00:00:06.000), size 356605, adler 0x8767bc55
...
I frame, track 1, timecode 8000 (00:00:08.000), size 369449, adler 0xa6319ee4
...
I frame, track 1, timecode 10000 (00:00:10.000), size 369914, adler 0xb9adbcbc

CruNcher

7th November 2016, 19:49

Test Clare codec AV1 vs X165 is underestimated because preset is good, bpg has veryslow.
Preset for X265 is:
0.ultrafast
1.superfast
2.veryfast
3.faster
4.fast
5.medium (default)
6.slow
7.slower
8.veryslow
9.placebo
Preset for VPX/AOM is:
0. rt + 37% quality
5. good (default) + 50% quality
9. best + max.63% quality
I associate it mistakenly with the parameter VPX "cq-level". So you could set for veryslow quality VPX best + max.63%.
http://i64.tinypic.com/331hpmr.jpg
No one probably doesn't know what effect it has value of quality "min-q". The first frame is always a big mistake for added value for codec VPX and AV1.

Interesting is also why each encoder VPX&AOM has a different parameter of quality.
FFmpeg has CRF.
What possesses Adobe plugin 1.003? Must enter function "cq-level". Changing the value of quality means a change bitrate and the number of frames P. 37% is 2frames, 50% is 4 frames, 63% is 6 frames. It is a pity that libvpx isn't such fuction. Approached by a characteristic size of the frame to the X265. Changing good to best doesn't change the size of the bitrate, only the number of reference vectors in frame.
Edit: The function pass 2 is a falsification. There is no dynamic frame B. Analyzer video Elecard doesn't show that it has been implemented.

Huh ?

Image compression

All images are compressed losslessly and over a range of qualities for each codec:

BPG:
lossless: bpgenc -m 8 -f 420 -lossless -o [output] [input(PNG)]
between q=3 and q=45: bpgenc -m 8 -f 420 -q $q -o [output] [input(PNG)]

AV1:
lossless: aomenc --passes=2 --lossless=1 -o [output] [input(Y4M)]
between q=5 and q=63: aomenc --passes=2 --end-usage=q --cq-level=$q -o [output] [input(Y4M)]

Daala:
lossless: encoder_example -v 0 -o [output] [input(Y4M)]
between q=5 and q=85: encoder_example -v $q -o [output] [input(Y4M)]

FLIF:
lossless: flif -Q 100 [input(PNG)] [output]
between q=-329 and q=79, with a step of 12: flif -Q $q [input(PNG)] [output]

JPEG2000:
lossless: kdu_compress -no_info Creversible=yes -slope 0 -o [output] -i [input(PPM)]
between q=38912 and q=45056, with a step of 64: kdu_compress -no_info -slope $q -o [output] -i [input(PPM)]

JPEG XR:
lossless: JxrEncApp -d 1 -q 1 -o [output] -i [input(PPM)]
between q=5 and q=85: JxrEncApp -d 1 -q $q -o [output] -i [input(PPM)]

MozJPEG:
lossless: cjpeg -rgb -quality 100 [input(PNG)] > [output]
between q=5 and q=95: cjpeg -quality $q [input(PNG)] > [output]

WebP:
lossless: cwebp -mt -z 9 -lossless -o [output] [input(PNG)]
between q=5 and q=95: cwebp -mt -q $q -o [output] [input(PNG)]

Indeed if the default ist good it would be not the highest preset as bpg uses i wonder why clare decided this

Jamaika

13th November 2016, 19:43

They said that in order to achieve the 50% increase in efficiency over VP9, they are willing to accept a 40% increase in decoding complexity and a 5 to 10 times higher encoding complexity than VP9, see:
You can see increase in efficiency over the codec VP9. Certainly is an interesting alternative to HEVC codecs. In AV1 is less undulation pixels at low bitrate and better views gray. It can develop. Currently, they have time to improve the decoder LAV 10bit. Does not recognize the files AV1. And most important adding new implementations to encoding speed.
https://www.sendspace.com/filegroup/%2B1GIcza3qP6YuKA66f%2FiztpTDNDeyMc9

dapperdan

16th November 2016, 16:22

The Alliance for Open Media was also there and gave a presentation on AV1, where they said they are aiming for a 50% increase in efficiency over VP9/H.265 with AV1. They also said that AV1 in it's current state already beats VP9 by 25-30% (with not yet released Google internal tools). They said that in order to achieve the 50% increase in efficiency over VP9, they are willing to accept a 40% increase in decoding complexity and a 5 to 10 times higher encoding complexity than VP9, see:

https://youtu.be/thvSyJN1vsA

:eek:

They also target a release in the first half of 2017 for AV1.

The results on low bitrate VP9 from Netlfix were very interesting. Shows the power of automated testing of quality. Interesting to see what comes of that work. And good that they're offering to do the same with AV1 as part of the development process.

nevcairiel

20th November 2016, 16:17

A codec is not the place to lobby for your politics in format choices. If someone can't compress the image they have, then they are going to use another codec.

nevcairiel

20th November 2016, 16:28

Where else would that be then?
If they want to use such formats, the codecs exist that can handle all of it. So convince the content providers, its a political debate, not a technical one, and you can't force it on a technical level.

If there is enough demand, then hardware implementations of AV1 will also adopt support for higher chroma. Everything is a matter of demand. If content exists, hardware will come (or content is at least widely planned to roll out).

If you have a 4:2:0 limited range image, you can still encode it in 4:4:4 full range, so what exactly is your point?

That just wastes space and/or degrades quality. An image should be compressed as close to the raw material one has - and if thats 4:2:0 or 4:2:2, which a lot of content is, then don't artifically upscale chroma, just because someone is on a crusade. Cheap upscaling is almost as bad as downscaling in the first place.

huhn

20th November 2016, 17:07

3. Drop support for limited range (16-235), i.e. please support full range (0-255) only

RGB -> full range YCbCr conversation will result in overshooting so it is no real option.

mzso

20th November 2016, 17:43

RGB -> full range YCbCr conversation will result in overshooting so it is no real option.

What do you mean?

huhn

20th November 2016, 17:56

"you can get to big numbers."

which is not possible with limited range.

edit:When performing YCbCr to R ́G ́B ́ con-
version, the resulting R ́G ́B ́ values have a
nominal range of 16–235, with possible occa-
sional excursions into the 0–15 and 236–255
values. This is due to Y and CbCr occasionally
going outside the 16–235 and 16–240 ranges,
respectively, due to video processing and
noise.

http://www.compression.ru/download/articles/color_space/ch03.pdf

full range YCgCo should be fine https://en.wikipedia.org/wiki/YCgCo

mzso

20th November 2016, 19:00

"you can get to big numbers."

which is not possible with limited range.

edit:

http://www.compression.ru/download/articles/color_space/ch03.pdf

full range YCgCo should be fine https://en.wikipedia.org/wiki/YCgCo

So basically the gist of it is that a flawed algorithms, from flawed sources produce inferior results. Those outside values are technically invalid, so I don't see why they'd be relevant.

Nintendo Maniac 64

21st November 2016, 01:46

Is native YUV support really all that beneficial when using 10bit?

huhn

21st November 2016, 08:23

you need to compress the chroma channel more than the luma for proper picture quality bit deep has nothing to do with that.

GTPVHD

21st November 2016, 10:38

http://aomedia.org/about-us/

http://www.bbc.co.uk/rd/blog/2016/10/alliance-open-media-video-compression

More and more companies join the Alliance for Open Media.

nevcairiel

21st November 2016, 11:52

Is native YUV support really all that beneficial when using 10bit?

You'll always need to split RGB into another scheme for efficient encoding, because RGB has a lot of redundant information. So splitting it into Luma+Chroma makes encoding much more efficient.
On top of that this allows you to compress chroma more then luma, which plays into the nature of our eyes. With pure RGB you couldn't do that - the best you could do is compress one color channel more then the others, but thats not even close to as efficient.

YCbCr (or YUV in other terms) is what we have to do that. Some other approaches have been brought forward, like YCgCo, but they have not been adopted widely because many existing processing pipelines just know how to work with YCbCr, and the advantages of those suggested alternatives were not that great.

If someone can define a groundbreaking new scheme to split Luma and Chroma in a more efficient way (say a significant difference), reducing even more redundant information while being able to (visually) losslessly re-create the original image, I'm sure there would be industry interest eventually. But so far all the needs we had to modify YCbCr could be done with different transfer matrices to increase the colorspace.

mzso

21st November 2016, 13:01

http://aomedia.org/about-us/

http://www.bbc.co.uk/rd/blog/2016/10/alliance-open-media-video-compression

More and more companies join the Alliance for Open Media.

BBC is a good addition. They did research and released papers on what framerate requirements (with what "shutter time" ) are necessary for "perfect" motion representation...
So their input for HFR might be really useful.

CruNcher

21st November 2016, 14:27

Not only that think about Dirac VC2 Open Broadcast :)

And they're still standing a lot more on the doorstep waiting to get in ;)

Motenai Yoda

21st November 2016, 21:25

BBC is a good addition. They did research and released papers on what framerate requirements (with what "shutter time" ) are necessary for "perfect" motion representation...
So their input for HFR might be really useful.

NHK did it too and found 120fps (over 100) and 240Hz shutter time to be the right values
http://informationdisplay.org/IDArchive/2012/NovemberDecember/FrontlineTechnologySuperHiVisionasNextGen.aspx

mzso

21st November 2016, 22:05

NHK did it too and found 120fps (over 100) and 240Hz shutter time to be the right values
http://informationdisplay.org/IDArchive/2012/NovemberDecember/FrontlineTechnologySuperHiVisionasNextGen.aspx

I remember 250-300 fps. (DVB Scene #44, Richard Salmon (https://www.dvb.org/resources/public/scene/dvb-scene44.pdf))

According to "The Application of Sampling Theory to Television Frame Rate Requirements (http://downloads.bbc.co.uk/rd/pubs/whp/whp-pdf-files/WHP282.pdf)" the hard limit is at ~700fps. But that might not take into account BFI trickery.

I'd be interested to know if anyone did research which includes interpolation algorithms. It might be that something like 100 interpolated to 300 + BFI would totally fool human perception and would appear completely realistic.

CruNcher

22nd November 2016, 18:59

Interesting you would need to look into the FRC SOA :)

This part is really interesting for HVS tuning and reducing the bandwith requirements efficiently

There are, however, two forms of un-trackable motion which the brain still does not interpret as smooth, resulting in either the perception of judder, or of multiple imaging.
The eye is unable to track rotating motion, such as the juggling clubs seen in Figure 2, nor can it track multiple motions at the same time.
Thus if in a football match the eye is following the ball, the background behind it may be seen to judder.

But i guess nothing of this is really new especially as everyone of us already experienced these effects (especially the background judder effect following an object in High Motion, it always makes me crazy in subjective frametime analysis thinking latency is to high and something failing) but it could help improve some misconceptions of "motionblur helps everywhere" :)

We have some really interesting things going on like Asynchrounous Space Warping for VR :)

And i think VR is the future for this Research to be improved significantly :)

https://www.youtube.com/watch?v=xpQQmu7vquE

I can now max out setting and super sample 1.5. I was sensitive to VR sickness and this has 100% removed it even in things like 360 videos that don't have the ability to move your head in all directions properly.

And it has much major impact then ever before latency becomes so a high issue that it will transform surely also hardware architectures in becoming much much more efficient to avoid nausea efficiently.

And surely we also have to rethink about efficiency costs and energy consumption.

But if i think about HFR in total i get big headaches of the Discussion in certain areas like Cinema especially with a decade old Hollywood trained LFR crowed ;)

And im pretty sure there isn't even yet a HFR Production existing from Hollywood that would adhere to Scientific grounds and rethink how todo it from Ground up right and different in the whole production chain, it will still take years before that will work out at all.

Jamaika

26th November 2016, 20:27

No. X264 and BPG suport YCgCo, but BPG's old codec.
VPX/AOM only suport:
--yv12 Input file is YV12
--i420 Input file is I420 (default)
--i422 Input file is I422
--i444 Input file is I444
--i440 Input file is I440

Phanton_13

9th December 2016, 13:13

dapperdan

9th December 2016, 18:55

Not read it yet, but that appears to be the same group that put out a very early analysis of VP9, they took a copy of the git master branch the day that the format was finalized and talked about it as if it was released code. I think it was over a year later before there was an official VP9 release.

edit: the previous work I refer to: http://iphome.hhi.de/marpe/download/Performance_HEVC_VP9_X264_PCS_2013_preprint.pdf

CruNcher

10th December 2016, 09:30

Not sure what's so surprising the coding tools are not that efficient yet (but in case of AV1 also not fully finalized and frozen yet) but therefore also the complexity is not as high and overall lower nothing unexpected to other studies also that the RC from the HEVC Reference is pretty damn weak compared to the reference VP9 encoder so their decission to look at the raw fixed Q performance is understandable especially seeing, that this is the area where they mostly contributed themselves to MPEG/AVC/HEVC :D

Though it's raw complexity which isn't the whole truth at all and H.266 will show that they know it very well themselves, we have arrived in diminishing returns space partly already no more energy to suck of the universe from ;)

easyfab

10th December 2016, 15:41

I just made a little test (latest git for all codec) with Kimono1_1920x1080_24.y4m @2500kbits :

x264 veryslow 3.00 Mo : ssim All:0.938488 (12.110405) psnr average:38.967018
x265 slower 2.87 Mo : ssim All:0.945886 (12.666905) psnr average:40.059902
vp9 cpu-used=2 2.82 Mo :ssim All:0.946726 (12.734856) psnr average:39.988449
and
av1 cpu-used=2 2.77 Mo : ssim All:0.947562 (12.803542) psnr average:40.220836

So AV1 is better than VP9 and x265 for this clip ( and slower ). And I don't build aomenc with experimental flag that should give even better ( and even slower) result .

Clare

11th December 2016, 10:04

easyfab

11th December 2016, 10:51

What speed did you get for AV1? I'm trying to encode a small clip but I get less than 1 frame per minute! This is impossible to encode anything with such a slow speed.

I used -t 8 --good --cpu-used=2 --tile-columns=4 and get 2-3 fps, but under 30% cpu usage, I hope better multithreading in future.
I have not tested better settings cpu-used=1 or --best because it's too slow under 1fps

Clare

15th December 2016, 19:49

At constant quality (measured by VMAF and PSNR-HVS on 30 short clips), I've got some impressive 33% reduction in size compared to x264, whereas with x265, I only achieved 5-10% at best. I'm gonna test it again in 10Bit and see if there is more room for improvement.

edit: I have --enable-dering experimental flag enabled to test. With PVQ enabled, computing was too slow.

Clare

20th December 2016, 21:28

Kinda disappointed by experimental settings on pictures (dering + clpf):

http://i.imgur.com/hx95zuv.jpg

CruNcher

20th December 2016, 23:13

Jamaika

21st December 2016, 09:09

@Clare Can you present a graph of results VMAF for Daala?

Clare

21st December 2016, 09:44

Are you kinda disappointed about the Graph result or does it mirror also your HVS MOS ;) ?
Are you gonna to include the preview results in the main image compare database at the different bpp/size targets ?

Visually, there is indeed less ringing around the edges, but some details are phased out.

I'm not gonna touch the comparison tools.

@Jamaika: Graphs with Daala are included in the website in my signature/

MoSal

21st December 2016, 22:56

@Clare

Don't dering and clpf have similar functionalities?

You should try dering alone if you have the time. It's supposed to be better, especially at low bitrates.

Jamaika

22nd December 2016, 09:28

Clare

22nd December 2016, 10:37

@Clare

Don't dering and clpf have similar functionalities?

You should try dering alone if you have the time. It's supposed to be better, especially at low bitrates.
They re supposed to work together in the final product, I've even seen a patch a while back where they reversed the order of their execution because it was giving better metrics.

Clare

22nd December 2016, 10:45

@Clare @Mosal Give some commands {apps}. What are the most beneficial for vmaf?
usage: vmaf app fmt ref dis w h
apps:
adm, ansnr, motion, vif, all
How do the best on ffmpeg?
ffmpeg.exe -loglevel verbose -i "input_yuv.mp4" -an -f yuv4mpegpipe -vf scale=1920:1080,format=yuv420p - |
vmaf_main.exe ??? yuv420p - output.yuv 1920 1080 --output json
aomenc.exe --codec=av1 --good --threads=4 --cpu-used=4 --target-bitrate=6000 --kf-max-dist=60 --auto-alt-ref=1 --frame-boost=1 --aq-mode=0 --color-space=bt709 --verbose --pass=1 --passes=1 --output=output.webm output.yuv

I don't know what you're doing. I don't know what is your "vmaf_main.exe". The executable to use is vmafossexec.

Just build it like that:
git clone https://github.com/Netflix/vmaf
cd vmaf
make

The executable "vmafossexec" is then available in the wrapper directory.

Usage: ./wrapper/vmafossexec <pix_fmt> <width> <height> <ref_path> <dis_path> <model_path>

The model path to use is "resource/model/nflxall_vmafv4.pkl"

MoSal

22nd December 2016, 11:50

They re supposed to work together in the final product,

I don't know about that.

I would still use one of the two if the results i'm getting are too smooth.

leonccyiu

9th January 2017, 13:17

Does anyone have any idea as to how much longer it'll take for the av1 format to be frozen and how much work still needs to be done?

Clare

9th January 2017, 14:18

Does anyone have any idea as to how much longer it'll take for the av1 format to be frozen and how much work still needs to be done?

When will the codec ship? The group is aiming to freeze the bitstream sometime between the end of the 2016 and March 2017. Expect to see browser-based support soon thereafter, with the first hardware support within 12 months after that.
http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/A-Progress-Report-The-Alliance-for-Open-Media-and-the-AV1-Codec-110383.aspx

Although I'm personally skeptical about these delays.

mzso

9th January 2017, 14:40

Does anyone have any idea as to how much longer it'll take for the av1 format to be frozen and how much work still needs to be done?

Doubt that anyone will give anything other then guesses. They don't provide any information whatsoever on their progress or state of the codec.

So only someone within could give any information. I don't think there's anyone on this forum besides jmvalin who has any sort of attachment to AV1.

Mr.Radar

10th January 2017, 21:34

Does anyone have any idea as to how much longer it'll take for the av1 format to be frozen and how much work still needs to be done?

The last public update on AV1 I'm aware of is from Netflix's forum on royalty-free video codecs (https://youtu.be/thvSyJN1vsA?t=42m38s) back in October which mentioned a target of "H1 2017 (https://youtu.be/thvSyJN1vsA?t=51m20s)" for freezing the bitstream. A talk giving a new status update on AV1 is scheduled (https://fosdem.org/2017/schedule/event/om_av1/) for FOSDEM in early February which should hopefully provide a bit more detail.

VincAlastor

15th January 2017, 11:06

Selur

15th January 2017, 20:20

VincAlastor

16th January 2017, 10:39

@VincAlastor: I plan to add support for av1 to Hybrid shortly after I can playback such files in MPC-HC. :)
(got the general support working, but can't verify that everything is okay, since I can't decode the created files)

Thank you very much :)

i use the patched lavfilters as external filters in mpc-hc and seems to work very well, but not tested much for now.

Selur

16th January 2017, 19:57

I'll probably wait till it makes it into a nightly build of mpc-hc.

easyfab

16th January 2017, 22:28

Not as good as a gui but I create a batch file for my AV1 testing.

here the code if someone is interested ( only cpu-used and bitrate can be set ) :

for the encoder, you can drag and drop the file on the .bat icon or drag and drop when the bat is running. change the path to ffmpeg and aomenc if needed.

@echo off
Set file="%1"
if "%1"=="" Set /p file="enter file to encode (or drag and drop ) = "
FOR /F %%I IN ("%file%") DO SET filename=%%~nI

set /p bitrate="bitrate ( enter = default 250K ) without the"K" = "
if "%bitrate%"=="" set /a bitrate=250

set /p preset_AV1="AV1 Cpu-used (enter = 2) = "
if "%preset_AV1%"=="" set preset_AV1=2

ffmpeg -i "%file%" -f yuv4mpegpipe - | aomenc - --target-bitrate=%bitrate% -t 8 --good --cpu-used=%preset_AV1% --tile-columns=4 --passes=2 --pass=1 --fpf="%filename%.fpf" -o "%filename%_av1.webm"

ffmpeg -i "%file%" -f yuv4mpegpipe - | aomenc - --target-bitrate=%bitrate% -t 8 --good --cpu-used=%preset_AV1% --tile-columns=4 --passes=2 --pass=2 --fpf="%filename%.fpf" -o "%filename%_av1.webm"

and for the decoder with mpv ( you can change to ffplay )
change the path to aomdec and mpv if needed.

:start
Set file=%1
if "%1"=="" Set /p file="file to decode(drag and drop ) = "
aomdec "%file%" -o - | mpv.exe - --fs
goto start

littlepox

17th January 2017, 03:56

nevcairiel

17th January 2017, 07:40

I'll probably wait till it makes it into a nightly build of mpc-hc.

Which won't happen until av1 is officially finalized (ie. stable bitstream), and releases of libaom are made instead of just having Git master, sometime later this year, hopefully.

hajj_3

17th January 2017, 11:02

It's simply too early to take a serious look at AV1 now. My own estimation would be 3 years, before it surpasses x264 for general ripping use-case. This includes decent playback support (perfect in PC platform and good enough for mobile), excellent visual quality(with comprehensive psy optimization, tuning, on a wide spectrum of bit-rate target) and affordable performance (including different levels of performance presets)

Even x265 is not completely there arguably.

3yrs? pffft. Google and lots of other companies are working on this, development will be much faster than x265 has been. Hardware decoders for mobile will likely be ready in early 2018 and hardware decoders for pc in late 2018. I expect that in early 2019 the encoder will be good enough to replace x264, x265 and vp9.

CruNcher

17th January 2017, 11:46

Yeah the next GPU Cycle should show a first introduction as well before that we might see Hybrid solutions already, with Volta there will be definitely some kind of Decoding support 100% on Nvidias side and it could be going straight to first Hardware without any Hybrid step this time at all :)

littlepox

17th January 2017, 15:10

Playback compatibility is not a issue, as long as it remains open and hardware giants are evolved.
What the real challenge for ripping use-case is the visual quality optimization in transparent level, i.e, very high quality.
Optimization for benchmark is easy, for human eyes you really need to put in a lot of effort.
It takes 3 years for x265 to be there with x265 v2.0 as the milestone.

But still up to now, hardware support for HEVC main10 is poor and limited, and the tuning for x265 is incomplete. Majority still prefer x264 and I don't expect it changes within one year.

Let's see how AV1 progresses. Now it's still a lovely baby, may it grow up healthily.

wiak

18th January 2017, 12:01

There was such a suggestion. Codec AOM replaces VP10, Daala, Thor, HEVC. Anyway what for they did to the alliance. VP10 disappears. I see that these are two paths of development, ie said Clare.

It can and is based on the codec vp10, just don't know it or not version a few months ago.
VP10 is the basis for AV1, but then they retrofitted daala/thor stuff into it, i suspect AOMedia AV2 will be a more daala lapping based codec. but thats for another time and place

TL;DR: VP10 + small parts of daala/thor = AV1

Jamaika

18th January 2017, 14:00

This is not important, what is the basis? This may suggest that changing the name VPX on AOM. However, the contents of the files is very modified and you can no longer suggest that VP10 was base.
https://aomedia-review.googlesource.com/#/c/1008/
As regards Daala. The truth is that a handful of fixes is like one bigger patch to month. I'm afraid that Daala will not have a significant effect on the development of AV2. Unless, development Daala is out of open source technologies.

Quikee

19th January 2017, 21:35

Latest presentation about AV1 (mainly daala tech.) at LCA2017: https://www.youtube.com/watch?v=lzPaldsmJbk

AV1 bitstream freeze will be in October 2017

iwod

20th January 2017, 03:31

Latest presentation about AV1 (mainly daala tech.) at LCA2017: https://www.youtube.com/watch?v=lzPaldsmJbk

AV1 bitstream freeze will be in October 2017

So that is a further delay. Looking likely to see it pushed into 2018.

Quikee

20th January 2017, 13:42

So that is a further delay. Looking likely to see it pushed into 2018.

Well.. that's the first delay (for AV1). First deadline wasn't really realistic considering that most of the experiments didn't play together yet (VP10 experiments - the nextgen2 branch was merged not too long ago) and some experiments aren't in a state to evaluate them (PVQ).

CruNcher

21st January 2017, 11:54

Apart from the Mobile space then i see Intel and Nvidia with first Hardware ready in late 2018.
Lot of time for HEVC to flourish tough and x265 to further improve it's overall Psy Layer if the acceptance for H.264 still stays high enough it could go well if x264 by then gets overrolled @ 4K completely it will be much harder and progress on H.266 is also gonna start with a total Psy focus, though well still have to see how Trump will impact all of this.

mandarinka

22nd January 2017, 01:51

3yrs? pffft. Google and lots of other companies are working on this, development will be much faster than x265 has been. Hardware decoders for mobile will likely be ready in early 2018 and hardware decoders for pc in late 2018. I expect that in early 2019 the encoder will be good enough to replace x264, x265 and vp9.

It's as littlepox said. Google and friends ganging up won't really do some miracle in providing a high quality encoder - this has always been hard work for multiple years.

Google itself has shown with VP8's and VP9's treatment in libvpx that they basically either can't or don't care to provide high quality encoder software.

The role of other subjects that are adding into the project now is still to be evaluated, but while they will help, again you can't expect miracles (look how slowly has Daala progressed since 2010, only to find out that their proposed techniques in the end can't be made to work, in many cases. And look how much "too little, too late" has there been over the many years of theora development).

I think that the three years estimate might even be optimistic given how disappointing has libvpx been for these 7.5 years that Google has owned On2 for.

CruNcher

22nd January 2017, 15:59

Vp10 isn't disappointing in anyways it is very competitive overall vs MPEG

wiak

24th January 2017, 03:13

It's as littlepox said. Google and friends ganging up won't really do some miracle in providing a high quality encoder - this has always been hard work for multiple years.

Google itself has shown with VP8's and VP9's treatment in libvpx that they basically either can't or don't care to provide high quality encoder software.

The role of other subjects that are adding into the project now is still to be evaluated, but while they will help, again you can't expect miracles (look how slowly has Daala progressed since 2010, only to find out that their proposed techniques in the end can't be made to work, in many cases. And look how much "too little, too late" has there been over the many years of theora development).

I think that the three years estimate might even be optimistic given how disappointing has libvpx been for these 7.5 years that Google has owned On2 for.
Theora was just a fix/cleanup for VP3 (Xiph)
VP8 and VP9 are pretty good compared to AVC and HEVC (Google)
Daala still is a research project (Xiph/Mozilla)
Thor is Cisco's pet project

AOMedia consolidates VP10, Daala, Thor technologies to create a new codec and a new platform to develop AV1 and future codecs from Xiph, Mozilla, Google, Cisco and a boatload of other companies have joined

to make it clear, AOMedia doesnt only seem to be Google, Google has done some good stuff like creating WebM (Restricts Matroska to VP8/VP9 with Opus/Vorbis only)

WebM/VPx was ruled by a iron-fisted Google
AOMedia is probably more of a non-american democracy

just think back, how it was in the old days, Theora was pretty average/bad

my thoughts

Jamaika

24th January 2017, 06:04

Google has done some good stuff like creating WebM (Restricts Matroska to VP8/VP9 with Opus/Vorbis only)
For me it's just another container. Google didn't want to have anything to do in the MOV container. Now Apple is in the team, so I expect that, and MOV will be under codec VPX / AOM. WebM is a simple container. Why additionally created a container to everything from WebM to Mastroska? Probably for legal reasons.
Certainly had an impact on the implementation of Matroska to video editors and home appliances. Nothing else.
What to implement the HDR function. WebM get a patent from the Adobe DNG and for what JpegXT. Codec IVF is packaged in next container WebM and already. This isn't a new idea. Less fortunate has WebP.

mzso

24th January 2017, 12:37

Google has done some good stuff like creating WebM (Restricts Matroska to VP8/VP9 with Opus/Vorbis only)

This makes me wonder. Will they have an officially supported extension/container for AV1? Or will they just leave the situation as bad as it is, with a bunch of entities having their own preferred containers?

Quikee

24th January 2017, 13:33

This makes me wonder. Will they have an officially supported extension/container for AV1? Or will they just leave the situation as bad as it is, with a bunch of entities having their own preferred containers?

They'll most likely extend WebM (or they already did actually as aomenc already outputs WebM with AV1) . Probably they'll want to extend MP4 too (like they did it for VP9 (Netflix) and Opus).

dapperdan

24th January 2017, 14:49

For me it's just another container. Google didn't want to have anything to do in the MOV container. Now Apple is in the team, so I expect that, and MOV will be under codec VPX / AOM.

I don't think Apple has publicly announced anything about AOM, has it?

wiak

24th January 2017, 14:57

They'll most likely extend WebM (or they already did actually as aomenc already outputs WebM with AV1) . Probably they'll want to extend MP4 too (like they did it for VP9 (Netflix) and Opus).

this is how webm is
WebM v1 aka VP8/Vorbis
WebM v2 aka VP9/Opus

in the future it will probably look like this

WebM v3 aka AV1/Opus

the preferred container for av1 is webm as the encoder and decoders has a muxer and demuxer built in already

you can still put it in matroska, mov, and other containers, but webm has a much better compatibility guaranteed than other containers, its much closer to mp4 which only has AVC/HEVC with AAC audio etc
:stupid:

Jamaika

24th January 2017, 15:44

you can still put it in matroska, mov, and other containers, but webm has a much better compatibility guaranteed than other containers, its much closer to mp4 which only has AVC/HEVC with AAC audio etc
:stupid:
As regards the work codec webm it better preserves parameters of converter ffmpeg codec than the VPX / AOM. I don't know why it is like that.
As regards the codec HEVC. In the Magix Vegas 14 codec Intel HEVC is in MOV container.;)

PS Even half a year ago it was added to the VPX codec MOV. Now is blocked and the problem solved.
Sam codec AV1 IVF currently can't be added to the Matroska container.
I don't think Apple has publicly announced anything about AOM, has it?
VP9 only supported in MP4.:eek:
VP9 in MP4 support is experimental, add '-strict -2' if you want to use it. That may change in a month.;)

ffmpeg.exe -i input.mov -f mp4 -c:v libvpx-vp9 -vb 2000k -strict -2 output.mp4

At one time the user RBO wrote two articles about the construction of codecs in containers VP9 / AV1. Unfortunately I don't received information, will codecs vpx be implemented in MP4Box?

Nintendo Maniac 64

30th January 2017, 02:31

I don't think Apple has publicly announced anything about AOM, has it?

No, Apple has not seeing how Apple is not listed on here:

http://aomedia.org/about-us/

Jamaika

30th January 2017, 07:19

In the press from the previous year was just a suggestion:
While this collaboration falls far short of Apple joining the Alliance for Open Media, it does signal that the two companies can work together effectively. It also indicates that Apple, long and publicly intransigent on MPEG DASH, is willing to contribute to new standards that benefit the common good. Will Apple join the Alliance? “We’ve been talking to a lot of companies, and recruiting definitely isn’t our challenge," Gabe Frost said. "The hard part is the engineering effort, taking the next step, and driving contributions through the open source project.”

bstrobl

30th January 2017, 16:30

Google has stopped encoding 4k videos in h264, leaving Safari users on Mac OS without that option. VP9 is still impacting battery life though so my guess is Apple will start shipping AV1 decoders once bitstream is frozen. Implementing VP9 now would be a bit pointless and Apple has been sticking with h264/AAC for a rather long time, hence they will most likely want the same ROI on the next set of codecs.
Joining the AOM now might just completely break down support for HEVC as well since Apple is one of the final large holdouts not shipping consumer devices with VP9. Not sure if Apple wants to do that or if they are bound by agreements with the MPEG LA not to relicense their patents to others. At this stage they are probably just waiting for AV1 to be complete and then making a decision.

sneaker_ger

1st February 2017, 13:36

Google has stopped encoding 4k videos in h264
That is not true. (Example (https://www.youtube.com/watch?v=geZWqWfMcpM))

bstrobl

1st February 2017, 18:41

That is not true. (Example (https://www.youtube.com/watch?v=geZWqWfMcpM))

Nope, 1440p max on Safari.

sneaker_ger

1st February 2017, 19:38

It's still encoded and available (e.g. via youtube-dl) as 3840x2160 H.264. I don't know about Safari.

dapperdan

3rd February 2017, 13:51

https://www.twitch.tv/videos/94956965

An overview of AOM from last year. Mostly old news and a recap, though in response to a question they do mention that AV1 is not the final name for the codec.

Also justifies some of Youtube/Google's design decisions around sending video to people in countries where the CPU available is higher than the bandwith.

mandarinka

6th February 2017, 00:13

Slides from FOSSDEM (https://fosdem.org/2017/schedule/event/om_av1/attachments/slides/1704/export/events/attachments/om_av1/slides/1704/av1_update.pdf)

(from http://phoronix.com/scan.php?page=news_item&px=AV1-Codec-FOSDEM-2017 )

wiak

6th February 2017, 00:21

Clare

6th February 2017, 12:52

iwod

6th February 2017, 14:10

And the presentation from FOSDEM:

http://video.fosdem.org/2017/K.3.401/om_av1.mp4

Slides are gone, any backup link?

mandarinka

6th February 2017, 22:19

Slides are gone, any backup link?

https://fosdem.org/2017/schedule/event/om_av1/attachments/slides/1795/export/events/attachments/om_av1/slides/1795/av1_update.pdf

iwod

7th February 2017, 03:41

https://fosdem.org/2017/schedule/event/om_av1/attachments/slides/1795/export/events/attachments/om_av1/slides/1795/av1_update.pdf

That is literally no news in the slide. :(

And it is hasn't pass IP test, I can bet the bitstream wont be frozen until next year. It is good they didn't rush it. But another year for HEVC to gain.

Let's just hope Apple hold off HEVC for another year.

hajj_3

7th February 2017, 04:25

It is good they didn't rush it. But another year for HEVC to gain.

No-one is adopting h265. Only broadcast and ultra hd bluray are using it. Almost no digital cameras record in h265 even though there have been hardware encoders for years for mobile devices. AV1 shall be the king for many years on the web. We really could do with safari adding support for vp9 though in the meantime.

Jamaika

15th February 2017, 12:29

I post up to date links of development on github aomenc.c and aomanalyzer.c
https://github.com/mbebenita/aomanalyzer
https://github.com/brion/aomedia

Blue_MiSfit

15th February 2017, 19:19

No-one is adopting h265. Only broadcast and ultra hd bluray are using it. Almost no digital cameras record in h265 even though there have been hardware encoders for years for mobile devices. AV1 shall be the king for many years on the web. We really could do with safari adding support for vp9 though in the meantime.

Well... that's not really true. All the major OTT streaming providers are doing 4k using HEVC. It's a big deal to high end consumers because it enables HDR!

CruNcher

16th February 2017, 11:25

enabling HDR hasn't so heavy requirements at all most of the HDR requirements are rather on a higher level like when to enable HDR and when not if detected that it is HDR content, it's more the clean management of it inside the Device architecture.
Hollywood has higher requirements hence they want foremost artistic control of it to manipulate it to their liking to get certain emotional feedback from the viewer from it.

That's also why it was rather Simple for Samsung to adapt their Tizen Software/Hardware stack to support it fast for VP9, the most complex thing in HDR is how efficient it works together with the PQ and how clean it is percepted in the end from the output Device and the acquisition of it :)

MisterXDTV

18th February 2017, 13:56

No-one is adopting h265. Only broadcast and ultra hd bluray are using it. Almost no digital cameras record in h265 even though there have been hardware encoders for years for mobile devices. AV1 shall be the king for many years on the web. We really could do with safari adding support for vp9 though in the meantime.

??? broadcasts, discs and streaming services like Netflix and Vudu are using HEVC for UHD (HDR)

Actually I don't get why we need yet another codec, VP9 is brand new and it's just starting to be supported on hardware. VP9 Profile 2 (10/12 bit + HDR) is even newer

AV1 seems to be late to the party IMO

mandarinka

18th February 2017, 18:46

??? broadcasts, discs and streaming services like Netflix and Vudu are using HEVC for UHD (HDR)

Actually I don't get why we need yet another codec, VP9 is brand new and it's just starting to be supported on hardware. VP9 Profile 2 (10/12 bit + HDR) is even newer

AV1 seems to be late to the party IMO

VP9 is quite a bit worse than HEVC, so compression improvements are welcome.

beastbg8

18th February 2017, 18:59

Can somebody provide me 480p, 720p and 1080p AV1 video samples? I can't find any on the internet. Thanks in advance.

Quikee

19th February 2017, 00:06

Can somebody provide me 480p, 720p and 1080p AV1 video samples? I can't find any on the internet. Thanks in advance.

Well, currently AV1 bitstream changes daily and depends on the experiments you enable in the encoder. So what do you want to do with them?

beastbg8

19th February 2017, 01:27

Well, currently AV1 bitstream changes daily and depends on the experiments you enable in the encoder. So what do you want to do with them?

I just want to test how well it plays on my hardware.

Nintendo Maniac 64

20th February 2017, 01:33

VP9 is brand new

VP9 had its first release before HEVC.

HEVC started development before VP9 though.

benwaggoner

22nd February 2017, 00:06

I just want to test how well it plays on my hardware.
You aren't going to learn much that's useful yet about how a final version would work on your hardware, or would work on then-current hardware when it's released.

Jamaika

24th March 2017, 07:12

New current link to aom codecs. Authors every month change the location of the link on the github. I also see that this year the project was abandoned ffmpeg-Daala.
https://github.com/atomnuker/aom

New Java Web AV1 Bitstream Analyzer
https://medium.com/@mbebenita/av1-bitstream-analyzer-d25f1c27072b#.ug6h3g1rb

Trends to Watch at NAB 2017
http://www.studiodaily.com/2017/03/five-4kuhd-trends-to-watch-at-nab-2017/
AV1 is scheduled to be finalized in Q4 2017, meaning a solid preview of its capabilities should be on display at NAB.
Everything is cool, but at present I don't see the use of hevc or av1 codecs in the cameras. Nor do I know what is meant by new camera HDR. After all, there are cameras with S-log3 or other color matrix settings.

Quikee

24th March 2017, 10:00

New current link to aom codecs. Authors every month change the location of the link on the github.

Jesus F. Christ - the developers are making private clones on github to work on the code (and for other developers to see the changes). It is better to avoid any of this as developers update with main repository when they need to and who knows what experimental modification they performed. If you want to check AV1 you always need to get the code from the AV1 main repository (https://aomedia.googlesource.com/aom/). This code was reviewed and is always the most up-to-date.

I also see that this year the project was abandoned ffmpeg-Daala.

No wonder as all the work shifted to AV1 and daala won't be finished..

New Java Web AV1 Bitstream Analyzer
JavaScript Web AV1 Bitstream Analyzer

Jamaika

31st March 2017, 06:31

LAVvideo decoder doesn't play AOM codecs. Even after registration with Windows 10. I mean 10bit movies.
http://tmod.nmm-hd.org/LAVFilters/
Work only aomdec.

Quikee

31st March 2017, 18:40

LAVvideo decoder doesn't play AOM codecs. Even after registration with Windows 10. I mean 10bit movies.
http://tmod.nmm-hd.org/LAVFilters/
Work only aomdec.

In the other news: nobody has yet won a gold medal at 2018 Winter Olympics.

Jamaika

31st March 2017, 20:52

In the other news: nobody has yet won a gold medal at 2018 Winter Olympics.
Maybe crap, but someone reads and improves in the next version.
http://tmod.nmm-hd.org/LAVFilters/LAVFilters-0.69-16-av1_test21-git-r3822%28737da5f%29.7z

bstrobl

1st April 2017, 09:57

IETF 98 Meeting is up:

https://www.youtube.com/watch?v=-dQIEisqHtQ

GTPVHD

19th April 2017, 23:58

https://bitmovin.com/bitmovin-supports-av1-encoding-vod-live-joins-alliance-open-media/

Another company joins the Alliance.

wiak

25th April 2017, 07:37

https://bitmovin.com/bitmovin-supports-av1-encoding-vod-live-joins-alliance-open-media/

Another company joins the Rebel Alliance.
fixed it for you
:stupid:

blurred

29th April 2017, 06:45

Some optimistic benchmarks: https://www.linkedin.com/pulse/aom-av1-vs-hevc-marc-clement

blurred

29th April 2017, 06:49

Optimistic benchmarks from Elecard: https://www.linkedin.com/pulse/aom-av1-vs-hevc-marc-clement

Jamaika

30th April 2017, 14:05

Elecard provides support of AV1 implemented in our flagship product - StreamEye. (https://www.elecard.com/news/elecard-provides-support-of-AV1)
Difference between AOM AV1 and HEVC (https://www.elecard.com/page/aom_av1_vs_hevc)
Results of Elecard's latest benchmarks of AV1 compared to HEVC (https://www.elecard.com/news/results-of-elecards-latest-benchmarks-of-av1-compared-to-hevc)

https://www.elecard.com/products/video-analysis/streameye

bstrobl

5th May 2017, 19:10

NAB Show 2017:

http://www.nabshow.com/video/algorithms-power-web-video

dapperdan

7th May 2017, 22:21

Did the Netflix rep say they were supporting work on the Eve encoder and seeing an extra 5% improvement? That's pretty cool.

easyfab

8th May 2017, 09:06

http://www.streamingmediaglobal.com/Articles/ReadArticle.aspx?ArticleID=118062

OT @dappedan

"he mentioned that they weren't using the stock open-source VP9 encoder available from Google. Rather, they were encoding with technology from a company called Two Orioles, which was founded by Ronald Bultje, a lead VP9 developer. Ronca mentioned that in particular, Netflix had found that the open-source VP9's two-pass rate control mechanism was suboptimal, and that Bultje's encoder is currently about 8% more efficient than Google's."

/OT

"Google's Frost claimed that AV1 was currently 30-35% more efficient than VP9"

Is correct that's nice .

dapperdan

8th May 2017, 12:53

That does introduce ambiguity into their comments about e.g. AV1 is 20% better than VP9, do they mean libvpx or eve encoded VP9? Since that could mean a further 8% difference.

Gravitator

20th May 2017, 14:34

I do not get normal (smeared squares) AV1 playback through tmodLAV (http://tmod.nmm-hd.org/LAVFilters/).
Samples > https://www.elecard.com/videos

mzso

20th May 2017, 14:51

I do not get normal (smeared squares) AV1 playback through tmodLAV (http://tmod.nmm-hd.org/LAVFilters/).
Samples > https://www.elecard.com/videos

Which other options are there to play AV1 videos?

sneaker_ger

20th May 2017, 14:53

You are dealing with experimental software and the bitstream hasn't been frozen yet. A sample created with yesterday's encoder might not work with today's decoder. Such things are expected. If you think you found a "real" bug in either encoder or decoder report it to the developers.

Gravitator

20th May 2017, 15:10

Which other options are there to play AV1 videos?
Elecard MPEG Player (only my processor can not cope - it slows down).

mzso

20th May 2017, 15:13

sneaker_ger

20th May 2017, 15:17

I don't.

wiak

20th May 2017, 16:30

here is the thing "its not finished, so a newer or older decoder will not work, it has to be exact"
there is one way to do it, its to encode a file and use ./aomdec file.webm| mpv -

stax76

1st June 2017, 17:58

How does 2 pass work?

D:\Projekte\VS\VB\StaxRip\bin\Apps\ffmpeg\ffmpeg.exe -i D:\Temp\staxrip\Eli_temp\Eli.avs -f yuv4mpegpipe - | D:\Projekte\VS\VB\StaxRip\bin\Apps\aomenc\aomenc.exe - --passes=2 --pass=1 --target-bitrate=1167 -o D:\Temp\staxrip\Eli_temp\Eli_out.webm

av_interleaved_write_frame(): Broken pipe
Error writing trailer of pipe:: Broken pipe
frame= 1 fps=0.0 q=-0.0 Lsize= 191kB time=00:00:00.03 bitrate=46971.0kbits/s speed=0.0618x
video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 39397.984375%
Conversion failed!

wiak

1st June 2017, 18:06

stax76

1st June 2017, 18:17

Is there a avs/vs reader then?

sneaker_ger

1st June 2017, 18:19

I vaguely remember you having the same problem with the VP9 encoder. With auto-2pass piping doesn't work because it cannot rewind the pipe. But manual 2pass should be possible or is that feature not available in the AV1 encoder? Or does it really not support pipe input at all?

stax76

1st June 2017, 18:21

staxrip uses ffmpeg for VP9 but I don't remember how it works. I've tried with avs input:

C:\WINDOWS\system32>D:\Projekte\VS\VB\StaxRip\bin\Apps\aomenc\aomenc.exe D:\Temp\staxrip\Eli_temp\Eli.avs --target-bitrate=1167 -o D:\Temp\staxrip\Eli_temp\Eli_out.webm
Fatal: Specify stream dimensions with --width (-w) and --height (-h)

edit:

C:\WINDOWS\system32>D:\Projekte\VS\VB\StaxRip\bin\Apps\aomenc\aomenc.exe D:\Temp\staxrip\Eli_temp\Eli.avs --target-bitrate=1167 --width=1280 --height=720 -o D:\Temp\staxrip\Eli_temp\Eli_out.webm
Pass 1/2 frame 0/0 0B 0b/f 0b/s 0 us (0.00 fps)[K
Failed to initialize encoder: Invalid parameter
rc_twopass_stats_in requires at least two packets.

stax76

1st June 2017, 18:24

Is there a place to get support from the developers?

wiak

1st June 2017, 18:31

Is there a place to get support from the developers?

#aomedia @ irc.freenode.net probobly your best bet, or there is http://aomedia.org/contact/

btw aoem isnt even done yet sooo

sneaker_ger

1st June 2017, 18:38

Try with y4m input via pipe:
aomenc --pass=1 --passes=2 --fpf="statsfile.txt" -o "output" -
aomenc --pass=2 --passes=2 --fpf="statsfile.txt" -o "output" -

stax76

1st June 2017, 18:44

Thanks, got it working now as it seems.

https://postimg.org/image/vbjihxjml/

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Encoding video using aomenc May 2017
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

@echo off
D:\Projekte\VS\VB\StaxRip\bin\Apps\ffmpeg\ffmpeg.exe -i D:\Temp\staxrip\Eli_temp\Eli.avs -f yuv4mpegpipe - | D:\Projekte\VS\VB\StaxRip\bin\Apps\aomenc\aomenc.exe - --passes=2 --pass=1 --target-bitrate=1167 --fpf=D:\Temp\staxrip\Eli_temp\Eli.txt -o D:\Temp\staxrip\Eli_temp\Eli_out.webm

cmd.exe /C call D:\Temp\staxrip\Eli_temp\Eli_encode.bat

ffmpeg version 3.3.1 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 6.3.0 (GCC)

Input #0, avisynth, from 'D:\Temp\staxrip\Eli_temp\Eli.avs':
Duration: 00:00:43.41, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 480x272, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, yuv4mpegpipe, to 'pipe:':
Metadata:
encoder : Lavf57.71.100
Stream #0:0: Video: wrapped_avframe, yuv420p, 480x272, q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
Metadata:
encoder : Lavc57.89.100 wrapped_avframe
Pass 1/2 frame 1/0 0B 0 us 0.00 fpm [ETA unknown] [K
Pass 1/2 frame 2/1 176B 2963 us 674.99 fps [ETA unknown] [K
Pass 1/2 frame 3/2 352B 5649 us 531.07 fps [ETA unknown] [K
Pass 1/2 frame 4/3 528B 8217 us 486.80 fps [ETA unknown] [K
Pass 1/2 frame 5/4 704B 10686 us 467.90 fps [ETA unknown] [K
Pass 1/2 frame 6/5 880B 12733 us 471.22 fps [ETA unknown] [K
Pass 1/2 frame 7/6 1056B 14736 us 475.03 fps [ETA unknown] [K
Pass 1/2 frame 8/7 1232B 16749 us 477.64 fps [ETA unknown] [K
Pass 1/2 frame 9/8 1408B 18797 us 478.80 fps [ETA unknown] [K

Start: 19:32:48
End: 19:32:53
Duration: 00:00:04

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Encoding video second pass using aomenc May 2017
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

@echo off
D:\Projekte\VS\VB\StaxRip\bin\Apps\ffmpeg\ffmpeg.exe -i D:\Temp\staxrip\Eli_temp\Eli.avs -f yuv4mpegpipe - | D:\Projekte\VS\VB\StaxRip\bin\Apps\aomenc\aomenc.exe - --passes=2 --pass=2 --target-bitrate=1167 --fpf=D:\Temp\staxrip\Eli_temp\Eli.txt -o D:\Temp\staxrip\Eli_temp\Eli_out.webm

cmd.exe /C call D:\Temp\staxrip\Eli_temp\Eli_encode.bat

ffmpeg version 3.3.1 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 6.3.0 (GCC)

Input #0, avisynth, from 'D:\Temp\staxrip\Eli_temp\Eli.avs':
Duration: 00:00:43.41, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 480x272, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, yuv4mpegpipe, to 'pipe:':
Metadata:
encoder : Lavf57.71.100
Stream #0:0: Video: wrapped_avframe, yuv420p, 480x272, q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
Metadata:
encoder : Lavc57.89.100 wrapped_avframe
frame= 27 fps=1.4 q=-0.0 size= 5164kB time=00:00:00.90 bitrate=46956.7kbits/s speed=0.0458x
frame= 28 fps=1.3 q=-0.0 size= 5355kB time=00:00:00.93 bitrate=46956.6kbits/s speed=0.0429x
frame= 30 fps=1.3 q=-0.0 size= 5738kB time=00:00:01.00 bitrate=46956.6kbits/s speed=0.0433x
frame= 31 fps=0.9 q=-0.0 size= 5929kB time=00:00:01.03 bitrate=46956.6kbits/s speed=0.029x
frame= 32 fps=0.8 q=-0.0 size= 6120kB time=00:00:01.06 bitrate=46956.6kbits/s speed=0.0281x
frame= 34 fps=0.8 q=-0.0 size= 6503kB time=00:00:01.13 bitrate=46956.5kbits/s speed=0.0274x
frame= 35 fps=0.8 q=-0.0 size= 6694kB time=00:00:01.16 bitrate=46956.5kbits/s speed=0.0257x
frame= 36 fps=0.7 q=-0.0 size= 6885kB time=00:00:01.20 bitrate=46956.5kbits/s speed=0.0246x
frame= 38 fps=0.7 q=-0.0 size= 7268kB time=00:00:01.26 bitrate=46956.5kbits/s speed=0.0241x
frame= 39 fps=0.4 q=-0.0 size= 7459kB time=00:00:01.30 bitrate=46956.5kbits/s speed=0.013x
frame= 40 fps=0.3 q=-0.0 size= 7650kB time=00:00:01.33 bitrate=46956.5kbits/s speed=0.0107x
frame= 42 fps=0.3 q=-0.0 size= 8033kB time=00:00:01.40 bitrate=46956.4kbits/s speed=0.0103x

mzso

1st June 2017, 19:38

Too bad Montgomery stopped with the Dalaa blogs. Now there's no info (that mere mortals can comprehend) about what stuff they're experimenting with.

stax76

2nd June 2017, 18:34

There's a first staxrip test build with AV1 support, feedback for tab names and labels would be a really helpful.

https://postimg.org/image/hjhoy7qar

https://github.com/stax76/staxrip/blob/master/Encoding/AV1Encoder.vb#L144

https://forum.doom9.org/showthread.php?p=1808526#post1808526

nevcairiel

2nd June 2017, 18:36

I hope you have a huge warning somewhere that people should really not encode videos in AV1 if they care to be playable in the future? :) AV1 is not done yet, and files encoded with a certain encoder version will not be compatible with future decoders.

stax76

2nd June 2017, 19:21

I guess you are right, I've changed the title bar to: Under construction, AV1 isn't finished yet

TD-Linux

15th June 2017, 22:48

I found this comparison betwen beta of AV1, HEVC and AVC by the Fraunhofer Heinrich Hertz Institute:

http://iphome.hhi.de/marpe/download/Preprint-Performance-Comparison-AV1-HEVC-AVC-PCS2016.pdf

The result is somewat surprising but not much if we think who did it and the development status of AV1, after reading it I also find it of poor quality and with various possibilities for errors plus it's potentially in conflict with other studies.

This paper is old now, but I didn't see this documented anywhere else, so:

This paper made the same error as their previous VP9 comparison paper. They allow x265 to do fixed quantizer modulation, but lock AV1 to a single quantizer per frame. x265's --qp option still varies per-frame qp's via ipFactor and pbFactor.

Even if they had set both x265 factors to 1.0, there would still be the problem that H.265 itself maps the QP value to different "real" quantizers based on keyframe or not, as part of the bitstream. So you'd actually have to null that out with a "backwards" ipFactor, or adjust AV1 to have a similar boost.

blurred

16th June 2017, 22:10

Hot thread about Google ANS patent for AV1:
https://www.reddit.com/r/programming/comments/6h08z5/google_is_currently_trying_to_patent_video/?sort=confidence

ls1dreams

24th June 2017, 19:39

Anyone have a prediction on which intel series chip/igpu this will make it into?

- coffee lake
- cannonlake
- later?

Coffee Lake seems unlikely since timing is about the same time as they plan to freeze the AV1 bitstream, unless the alliance has been working VERY closely with intel. Cannonlake even shortly after seems like it's rather tight.

soresu

24th June 2017, 20:21

Seems likeliest that the first accelerated implementations will be GPGPU or DSP based prior to ASIC for at least a year after bitstream is frozen later this year (assuming they manage to freeze at all this year).

soresu

24th June 2017, 20:25

Beelzebubu

25th June 2017, 02:24

A more interesting question is whether AV1 will be more amenable to parallel implementations than VP9, or even HEVC - which was a key goal originally for Daala, given the slow progress in CPU single thread performance, GPGPU or some other massively parallel accelerator represents a far more efficient target, and OTOY's ORBX codec shows that it can be done, strange that they are completely absent from the Alliance to be honest.

Why do you believe VP9 was not parallelizable? I think FFmpeg's decoder showed that parallelism is not an issue. The fact that Google's decoder didn't use parallelism has nothing to do with the format.

soresu

25th June 2017, 02:43

Ah, when talking about parallelism, I meant the encoder rather than the decoder, which is usually more compute intensive and seems to increase in complexity sometimes an order of magnitude or more per generation, while the decoder seems to be only a modest increase albeit still enough to hurt in the current climate of slow single thread improvement.

It seems that the likes of Netflix and Google get around parallelisation limits (atleast limits that dont impact compression efficiency) of H264, HEVC and VP9 by employing chunked encoding over the gamut of a server farm/datacenter, but this is still limited to CPU compute.

It would be interesting to see if we could at least see GPGPU employed efficiently for chunked encoding, if not for full length videos.

Beelzebubu

25th June 2017, 02:50

Without wanting to get too much into detail, I would claim that the issue here is in the implementation, not the format. There are alternative VP9 encoder implementations that are far less limited in their parallelism.

nevcairiel

25th June 2017, 07:56

It would be interesting to see if we could at least see GPGPU employed efficiently for chunked encoding, if not for full length videos.

GPGPU for encoding has never really been any successfull. You would probably have to design a codec with that as a key basic design for it to work decently, and it would probably have drawbacks anywhere else - ie. not be very general purpose.
The thing about GPGPU is that it only works well if a simple task can be parallized a whole lot. Encoding thousands of chunks at the same time would not be very simple (in fact a single chunk would be rather complex), and likely not work very well.

I do think however that the codecs we currently have do scale well enough to keep multi-core CPUs busy just fine, encoder implementations not withstanding.

Nintendo Maniac 64

26th June 2017, 02:22

I would imagine that the first GPUs implementing hardware AV1 decoding would be the middle of 2018 at the earliest.

CPU-wise, that would line up well with Zen2 APUs (H2 2018 - H1 2019) but if you insist on Intel you'd have to wait for Icelake in 2019.

Przemek_Sperling

26th June 2017, 19:28

The thing about GPGPU is that it only works well if a simple task can be parallized a whole lot.

I can't believe it :devil:

;-)

Phanton_13

29th June 2017, 13:25

GPGPU for encoding has never really been any successfull. You would probably have to design a codec with that as a key basic design for it to work decently, and it would probably have drawbacks anywhere else - ie. not be very general purpose.
The thing about GPGPU is that it only works well if a simple task can be parallized a whole lot. Encoding thousands of chunks at the same time would not be very simple (in fact a single chunk would be rather complex), and likely not work very well..
Actually the bigest problem is that you have to throw to the sink the knowledge and commom sense in algorithms that you learned doing commom programing. I learned this the hard way when I helped in the parallezitaion of a problem, we made it faster doing it slower... basically our solution was around ten times slower than the clasical one runing only one thread, but the clasical one was mostly limited to 12 threads and our was able to scale to more than 1000 threads and that resulted in it being around 80 times faster that the clasical solution in the machine where it was run.

Sorry for my english, I'n not a native speaker.

easyfab

3rd July 2017, 15:01

And 2 new members : Hulu and Argon Design.

https://www.hulu.com/press/product_update/hulu-joins-the-alliance-for-open-media/
http://www.argondesign.com/news/2017/jun/28/argon-joins-aom/

Now I hope the bitstream freeze will come in 2017.

wiak

4th July 2017, 10:16

stax76

4th July 2017, 11:59

And I hope the command line interface design and documentation improves to the same excellence as x264 and x265.

wiak

4th July 2017, 12:01

And I hope the command line interface design and documentation improves to the same excellence as x264 and x265.
and multi-threading :sly:

stax76

4th July 2017, 12:11

And native AviSynth and VapourSynth support. :)

easyfab

4th July 2017, 15:37

And after bitstream freeze I dream of others encoders like ffav1 ( ffmpeg team ) or xav1 ( like x264 ) with multi-threading and a lot of asm optimizations to enable better competition .

bstrobl

4th July 2017, 16:04

I am hoping that they will not rush out a bitstream with flaws in it. If it takes a bit longer than 2017 I guess that would be fine, since these codecs have much longer lifespans than companies like Google would like (remember the whole "every year a new codec" thing).

MP3 is still being used and progress in codecs is slowing gradually. Only so much Information can be crammed into a small file size. Getting this codec right the first time would be great.

leandro

5th July 2017, 04:06

I really hope they freeze bitstream this year too.

nakTT

5th July 2017, 06:53

mzso

5th July 2017, 08:15

If it takes a bit longer than 2017 I guess that would be fine, since these codecs have much longer lifespans than companies like Google would like (remember the whole "every year a new codec" thing).

Another reason I don't understand why they're still handicapping it with historic baggage like chroma subsampling and YUV. (At least interlacing seems to be gone for good.)
(Are they still doing the limited range nonsense too?)

Quikee

5th July 2017, 08:51

Another reason I don't understand why they're still handicapping it with historic baggage like chroma subsampling and YUV. (At least interlacing seems to be gone for good.)
(Are they still doing the limited range nonsense too?)

What's the alternative? Chroma subsampling is a good way to shave of quite a bit of image data without most people noticing it or caring about it.

mzso

5th July 2017, 09:56

What's the alternative? Chroma subsampling is a good way to shave of quite a bit of image data without most people noticing it or caring about it.

It's not a good way, it's a very bad, primitive way.

The alternative: no subsampling. Let the encoder reduce color information in a more evolved way. An immediately obvious possibility is that you could change how color/luminosity is stored adaptively.

eg: when there's only the sky on the picture why dump half the color information for the blue range of the spectrum even before it reaches the encoder? Why "keep" anything for the red range? (The only color is blue, or white/grey aka no-color)

nevcairiel

5th July 2017, 10:00

Can we not repeat this discussion every couple months? You can't force content producers on a technical level, they'll just not use the codec then. Convince them that they want to use 4:4:4 or RGB, not that they have to.

Additionally, a lot of content already exists that is already subsampled. Being forced to upsample that before encoding isn't going to do anyone any good, and as such a codec that can't encode a vast amount of existing content is not going to see adoption. Its as simple as that.

Clare

5th July 2017, 16:55

Hey guys,

I've updated my image comparison website, now you can compare AV1 from oct 2016 to AV1 from now.

You can see the changes in metrics here: http://wyohknott.github.io/image-formats-comparison/comparison.html

wiak

6th July 2017, 14:11

Quikee

6th July 2017, 14:21

can you add VP9 and HEVC in that too?

BPG uses x265 so there is already HEVC representation

Clare

8th July 2017, 10:49

can you add VP9 and HEVC in that too?

I've updated all the codecs and added VP9. I also fixed some erroneous numbers. VP9 is doing pretty good, but I don't think we will see anyone making it an image codec. The guys doing WebP can't change codec because it would modify their bitstream and all efforts to be integrated in browsers would go to waste.

BPG is based on HEVC, although it's an older revision, I've tried a more recent git revision from x265 and there's no real gain.

Nice blog btw.

IgorC

12th July 2017, 02:17

Clare,

Interesting comparison. Thank You.

AV1 gets better. Ringing has disappeared. There are less artifacts and more details.

wiak

15th July 2017, 16:52

did anyone post these?

https://image.prntscr.com/image/GWXVFSD0RkGnvy_BlPfnig.png

https://parisvideotech.com/wp-content/uploads/2017/07/AOM-AV1-Video-Tech-meet-up.pdf (English Slides)
https://www.youtube.com/watch?v=PVUIBbb-WcE (French
https://www.youtube.com/watch?v=t0oVlYcDAxM (French)

Zebulon84

15th July 2017, 23:15

In the videos, the AV1 developer says he estimated the availability of AV1 hardware chips around 18 month after codec freeze (so*mid 2019 if codec is realy frozen end of this year).

easyfab

16th July 2017, 09:25

@Zebulon84

18 months is for the very first products if I understand correctly.
And not all HW devices are planned to have it in the next generation, Apple now support HEVC, Qualcomm is not ( yet?) in the alliance...
if AV1 succeed against HEVC, It will take a long time for the adoption
Like Jean-Yves Avenard from Mozzila said : H264 will still be used for a very long time.

I think like for VP9 the first usage will be for youtube on desktop, perhaps Netflix.
but I hope the decoding will make progress, for now it's 3 times slower than VP9 and they target 2 times slower in the 6 months after bitstream freezing.
What CPU will be needed to decode 4K ?

bstrobl

19th July 2017, 18:13

IETF 99: https://www.youtube.com/watch?v=LJzvkOvPF30

Clare

20th July 2017, 18:02

wiak

20th July 2017, 20:29

The coding complexity is going through the roof. It would be nice they keep it reasonnable otherwise only big companies like Netflix or Google will be able to encode on their server. I'm running an encode and the eta is 15-20 days.
well how many cores? it slow because they
1. not started optimzing for SIMD yet
2. no multi-threading yet

mzso

20th July 2017, 21:42

well how many cores? it slow because they
1. not started optimzing for SIMD yet
2. no multi-threading yet

Also there's a bunch of stuff they're experimenting with which they might take out or change.

benwaggoner

20th July 2017, 23:46

I've updated all the codecs and added VP9. I also fixed some erroneous numbers. VP9 is doing pretty good, but I don't think we will see anyone making it an image codec. The guys doing WebP can't change codec because it would modify their bitstream and all efforts to be integrated in browsers would go to waste.

BPG is based on HEVC, although it's an older revision, I've tried a more recent git revision from x265 and there's no real gain.

Nice blog btw.
HEIF is likely to leave BPG in the dust due to Apple's strong support. Same basic concept, but with a richer wrapper format.

mzso

21st July 2017, 07:12

HEIF is likely to leave BPG in the dust due to Apple's strong support. Same basic concept, but with a richer wrapper format.

Since it's not some fashion gunk Apple support means very little.

nevcairiel

21st July 2017, 07:15

bstrobl

27th July 2017, 14:37

New still image formats have just never taken off, and I doubt any will for quite a while. Most people are content with JPEG, especially due to it being supported by everything everywhere, and if you want quality you just go PNG.

I actually think HEIF is a well thought out container format. As long as there are no patent fees for the spec itself it would actually be neat if it replaced jpeg/png. The HEVC part can be thrown out for AV1 in the future and an additional lossless codec would make it pretty much the all-rounder image format.

The problem with a new image format is that if it can't do everything the previous ones do it won't succeed. HEIF seems extensible as well as containing pretty much every feature I can think of. WebP on the other hand was rushed and did not have too many benefits over jpeg/png (not to mention being stuck with VP8 as compression codec).

Blue_MiSfit

27th July 2017, 17:26

benwaggoner

27th July 2017, 17:41

Yeah, Apple support for HEIF is a big deal, honestly. Lots of iOS apps will start using it internally to save bandwidth I'm sure - especially bandwidth hogs like facebook, instagram, snapchat, reddit, etc...
Yeah, HEIF HEVC is a superior superset of JPEG, PNG, and Animated GIF. It spans all those use cases, and offers much improved encoding efficiency.

Also, Apple support means a LOT for an image format, given the overrepresentation of Macs in the creative and web design community.

HLS was a bad technology, and Apple's support made it extremely widely used. Apple's support of a really good format is going to be a big deal.

HEIF AV1 would be ballpark equivalent. However, the lack of HW decoders relative to HEVC could add friction for using AV1 instead of HEVC, particularly in mobile devices, Smart TVs, and other non-PC devices.

huhn

27th July 2017, 23:11

benwaggoner

27th July 2017, 23:27

looking at VP9 hardware decoder which are standard on nvidia cards, on intel iGPUs and at lest TVs have them too for some time now. i have no clue about mobile devices. i can see AV1 hardware decoder in late 2018.
VP9<>AV1 AV1 should be more competitive versus HEVC than VP9 is.

I found this interesting paper comparing HEVC HM and VP9 for intra-coded images, looking how different features impact efficiency. It's just PSNR based, but that is fair as HM and VP9 are both heavily tuned for optimizing PSNR.

http://www.m-hikari.com/ams/ams-2013/ams-137-140-2013/sharabaykoAMS137-140-2013.pdf

This looks interesting as well:
http://www.uta.edu/faculty/krrao/dip/Courses/EE5359/ShrutiSukumaranFinalReport_0508.pdf

I wouldn't want to extrapolate how AV1 would compare from these, of course.

huhn

27th July 2017, 23:41

my biggest problem with these papers is that they are pretty old and the encoder software made huge gains over the time up to this date.
only a new test can give a better idea how well they perform today.

ok this is about intra coding right now but i wouldn't be so sure anymore if VP9 can't beat HEVC.

Beelzebubu

30th July 2017, 15:30

VP9<>AV1 AV1 should be more competitive versus HEVC than VP9 is.

I found this interesting paper comparing HEVC HM and VP9 for intra-coded images, looking how different features impact efficiency. It's just PSNR based, but that is fair as HM and VP9 are both heavily tuned for optimizing PSNR.

http://www.m-hikari.com/ams/ams-2013/ams-137-140-2013/sharabaykoAMS137-140-2013.pdf

This looks interesting as well:
http://www.uta.edu/faculty/krrao/dip/Courses/EE5359/ShrutiSukumaranFinalReport_0508.pdf

I wouldn't want to extrapolate how AV1 would compare from these, of course.

If one paper claims 40-50% and another 10-15% BDRATE reduction, then you know - factually - at least one of them is bogus... A bigger issue is that neither of them offers actual parameters used, so it's impossible to reproduce.

That said, in my tests on intra-only cases, I have found that libvpx does indeed under-perform (in my tests by approximately 10%) versus HEVC encoders in any metric. I believe this makes sense, given per-symbol adaptivity in CABAC versus global fw/bw adaptivity in libvpx (which - for intra-only cases - accounts for 5-10%) and less intra prediction angles (which - according to 2nd paper - accounts for approximately 5%). The rectangular block sizes for intra, decomposed ADST/DCT combinations and ADST at larger transform sizes for VP9 gives a few % points back to VP9, but not enough to make up for this. Therefore, I'm willing to give the second paper the benefit of the doubt that it may be sensible (although results are still bigger than what I see in my tests). I think the first paper is bogus. Obviously these are time snapshots and since then, x265/libvpx would both have seen improvements.

Note again that this is intra-only. In inter coding, you will see AMVP (HEVC), filtered predictors (VP9) and entropy retention (VP9) making big differences. I believe entropy retention is by far the biggest one, and is the cause that as the keyframe interval increases, VP9 (libvpx) not only matches, but even overtakes HEVC in efficiency. This is obviously limited to VoD use-cases only, and cannot be used for RTC use-cases, so it also acts as an indication of particular cases where HEVC or VP9 would be more useful.

And I haven't talked about coefficient coding efficiency yet - the coefficient coding in HEVC is optimized for parallelization and hardware implementability, but the other side of the coin is that its compression performance is not so great. As a result, at higher bitrates, you tend to see HEVC suffering. I'm not sure anyone cares about this for internet VoD, though...

benwaggoner

31st July 2017, 17:57

If one paper claims 40-50% and another 10-15% BDRATE reduction, then you know - factually - at least one of them is bogus... A bigger issue is that neither of them offers actual parameters used, so it's impossible to reproduce.
I believe that the 10-15% is ballpark for IDR-only and 40-50% is ballpark for interframe encoded content. The problem with this kind of comparison is that it only compares what was specifically tests, and it is hard to generalize. And PSNR<>MOS!

That said, in my tests on intra-only cases, I have found that libvpx does indeed under-perform (in my tests by approximately 10%) versus HEVC encoders in any metric. I believe this makes sense, given per-symbol adaptivity in CABAC versus global fw/bw adaptivity in libvpx (which - for intra-only cases - accounts for 5-10%) and less intra prediction angles (which - according to 2nd paper - accounts for approximately 5%). The rectangular block sizes for intra, decomposed ADST/DCT combinations and ADST at larger transform sizes for VP9 gives a few % points back to VP9, but not enough to make up for this. Therefore, I'm willing to give the second paper the benefit of the doubt that it may be sensible (although results are still bigger than what I see in my tests). I think the first paper is bogus. Obviously these are time snapshots and since then, x265/libvpx would both have seen improvements.
I believe the first paper used HM, not x265, with both encoders using fixed QP to calibrate to the same equivalent file size. So, avoiding explicit psychovisual optimization, but including a fair amount of the implicit psychovisual optimization in any codec.

Note again that this is intra-only. In inter coding, you will see AMVP (HEVC), filtered predictors (VP9) and entropy retention (VP9) making big differences. I believe entropy retention is by far the biggest one, and is the cause that as the keyframe interval increases, VP9 (libvpx) not only matches, but even overtakes HEVC in efficiency. This is obviously limited to VoD use-cases only, and cannot be used for RTC use-cases, so it also acts as an indication of particular cases where HEVC or VP9 would be more useful.
Not just VOD - Live streaming can use B-frames and still get to competitive broadcast delay.

I haven't seen real-world cases where x265 doesn't have a bigger advantage over libvpx with interframe encoding. That is where psychovisual optimizations really start paying off, and encoder implementation>>bitstream syntax.

And I haven't talked about coefficient coding efficiency yet - the coefficient coding in HEVC is optimized for parallelization and hardware implementability, but the other side of the coin is that its compression performance is not so great. As a result, at higher bitrates, you tend to see HEVC suffering. I'm not sure anyone cares about this for internet VoD, though...
Ironically, parallelization is MORE important for internet VOD for VP9, since many more users are going to reply on SW decoders. VP9 is essentially single-threaded, without skipable b-frames and without Wavefront Parallel Processing; just horizontal slices, which are quite inefficient given the dominance of horizontal motion over vertical. VP9 is very much bound to peak single-thread performance when HW isn't available.

AV1 is more parallelizable than VP9 (loop filter can be its own thread, for example), although still less so than HEVC, where you basically get one potential decode thread per 64 pixels of height with WPP. And can parallelize P and B decoding if that isn't enough.

TD-Linux

3rd August 2017, 00:04

AV1 is more parallelizable than VP9 (loop filter can be its own thread, for example), although still less so than HEVC, where you basically get one potential decode thread per 64 pixels of height with WPP. And can parallelize P and B decoding if that isn't enough.

There are some other wins - there are now fully parallelizable 2D tiles. In addition, entropy adapts on the fly rather than per frame, which makes parallel encoding and decoding easier. There are no counts to keep track of and the bitstream can be written on the fly. Frames can still start out with the probabilities from a previous one, so you need the encoder to write an appropriate reference structure to decode frames in parallel (alternately, you can decode the symbols ahead of reconstruction, as you could in VP9). There is no WPP.

bstrobl

4th August 2017, 15:31

Any word on whether PVQ will make it into the final codec?

ls1dreams

9th August 2017, 03:18

looking at VP9 hardware decoder which are standard on nvidia cards, on intel iGPUs and at lest TVs have them too for some time now. i have no clue about mobile devices. i can see AV1 hardware decoder in late 2018.

Late 2018 would be awesome but it would be a bit of a stretch, IMO. HEVC took around 3 years to get hardware decoding, and VP9 around 4.5 years.

There's a ton of people behind the AV1 alliance, but assuming that we'll get hardware decoding 1 year after the target code freeze seems optimistic to me.

Maybe we'll luck out though if hardware manufacturers are preparing in advance. The other thing that might help is the large push to low power / mobile chips which would want to get the battery life advantage.

I'm personally trying to hold out for AV1 hardware decoding to upgrade my laptop and tv media player, but it's been a long stretch. (I originally was going to wait for HEVC decoding but then quickly saw the AV1 train happening).

A better optimistic guess is probably mid to late 2019, but lets all cross our fingers that we get it sooner.

huhn

9th August 2017, 05:31

HEVC is from april 2013 and the 960 is from January 2015

sneaker_ger

9th August 2017, 13:32

First TVs had HEVC decoders no later than spring 2014. Maybe even end of 2013.

Clare

10th August 2017, 13:09

Late 2018 would be awesome but it would be a bit of a stretch, IMO. HEVC took around 3 years to get hardware decoding, and VP9 around 4.5 years.

There's a ton of people behind the AV1 alliance, but assuming that we'll get hardware decoding 1 year after the target code freeze seems optimistic to me.

Maybe we'll luck out though if hardware manufacturers are preparing in advance. The other thing that might help is the large push to low power / mobile chips which would want to get the battery life advantage.

I'm personally trying to hold out for AV1 hardware decoding to upgrade my laptop and tv media player, but it's been a long stretch. (I originally was going to wait for HEVC decoding but then quickly saw the AV1 train happening).

A better optimistic guess is probably mid to late 2019, but lets all cross our fingers that we get it sooner.

I'll be waiting for AV1 hardware decoding too, I currently have a Skylake, it does hevc decoding but only 8bit. Same for VP9.
Being under Linux, I think I'll have to wait even longer.

However I haven't seen Qualcomm being a supporter of AOM, I don't know what's it's gonna be like on the Android market.

bstrobl

30th August 2017, 16:14

http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/AV1-A-Status-Update-120214.aspx

Hopefully they can squeeze out a bit more than the targeted 20%. 25 would be nice and 30 really great.

easyfab

30th August 2017, 18:57

https://forum.doom9.org/showpost.php?p=1812356&postcount=259

from the pdf page 4 and 5 : target 40-50% and currently ( july 2017 ) 25-35%

So the 20% should be here but for what complexity ? Last time I try it was < 1fps for 720p

Quikee

1st September 2017, 13:34

20% over HEVC is the wish of NetFlix, others can have different goals in mind.

So the 20% should be here but for what complexity ? Last time I try it was < 1fps for 720p

That's not complexity - it's just the state of optimizations of the current implementation. Considering that the codec is in pre-bitstream freeze state, speed is not the focus, complexity of a coding tool however is.

bstrobl

1st September 2017, 15:40

There are nearly 100 experiments that are in the code base(some presumably don't work with each other). If the signalling for a large combination of those is practically free it would make sense to integrate as many as possible if they can be of use to an encoder later down the line, as long as the decoder doesn't become too complex.

What does confuse me is how Netflix and Google seem to be coming up with rather different percentages of improvement(20% vs nearly 35%?). Probably a combination of differing builds and metrics.

IgorC

3rd September 2017, 18:02

As H.266 is already in development http://mpeg.chiariglione.org/standards/exploration/future-video-coding
it's very likely that development of a new format will be launched after AV1.

StephanD

18th September 2017, 11:59

Hello everybody,

I'm a media student of a university of applied sciences in germany and I have a lot of questions concerning the work of the new AV1-Codec of AOM. I know it is terrible when newbies are coming to a forum with a lot of real experts in it. So I won't ask my stupid questions here, but I'd like to know where I could ask them without spamming too much.

Have a nice day all togehter. :)

huhn

18th September 2017, 12:31

well this forum i guess.

but not sure if a real indeep AV1 codec profi is present/active on this forum.

so i recommend you to open a new thread in a matching sub forum or maybe even here and just post your question. so a person able to answer your question is present and willing to answer you may get your answer. if "not" you may not get it.

and like always :search: first.

CruNcher

19th September 2017, 00:33

https://groups.google.com/a/webmproject.org/forum/#!msg/codec-devel/idezdUoV1yY/ZfklwwhWDgAJ

could endup in a disaster growing up slowly now

stax76

19th September 2017, 10:12

staxrip's AV1 support is now completed, better early than late. :)

https://github.com/stax76/staxrip/blob/master/md/changelog.md

nevcairiel

19th September 2017, 10:17

Except it can't be complete as long as the codec isn't even finished. :p Should not encourage people to make files that eventually nothing will be able to play.

CruNcher

19th September 2017, 10:28

Yeah should be marked as "experimental not frozen" in the GUI on the other side Staxrip is not really a avg joe target GUI Methodology so rather unlikely that the target group of it isn't aware that AV1 isn't absolutely ready for Production.

stax76

19th September 2017, 10:35

@nev

Are you worried about future bug reports? :)

There is a warning I leave until it's finished.

MsgWarn("Please note that AV1 is unfinished!")

CruNcher

19th September 2017, 10:39

stax76

19th September 2017, 11:03

@CruNcher

I changed it to this:

Please note that AV1 is unfinished/experimental!
The bitstream format is not yet frozen.

Should be clear enough.

huhn

19th September 2017, 12:20

not sure if the AVG user understands this as "it is very unlikely that my file will work in the future".

you can not assume that an AVG user knows what a bitstream format is.

easyfab

19th September 2017, 15:45

please add in bold "and shouldn't be used for any serious Production purposes yet, risk be none of your files created now with it will ever work in the future and only cause headaches, this is highly experimental"

For this people warning in not necessary, the current encoding speed is enough . :p

AV2 or AV3 will be out until they finish encoding there first movie.

It take me 5 min to encode foreman clip (300 frames 352*288).

stax76

19th September 2017, 16:51

OK, now it's this:

MsgWarn(
"Please note that AV1 is experimental!",
"The bitstream format is not yet frozen. It's very
likely that files created with the current encoder
become unreadable in the future.")

CruNcher

19th September 2017, 17:14

Hehe

AVG Joe ( oh i can read them why should i read them i read books or whatsapp messages but not files i create, nonsense ) :D

unplayable would be much better everyone understands that this wouldn't be nice.

Or did you ever saw (File->Read) ?

stax76

19th September 2017, 17:56

Unplayable, fine I changed it, can't get much more foolproof!

wiak

21st September 2017, 20:46

For this people warning in not necessary, the current encoding speed is enough . :p

AV2 or AV3 will be out until they finish encoding there first movie.

It take me 5 min to encode foreman clip (300 frames 352*288).
tell me i tried encoding 500fps 4k frames ;P took a few days
:stupid:

easyfab

26th September 2017, 17:09

From Timothy B. Terriberry's VDD17 presentation :

see : https://bambuser.com/v/6908002#t=2416s

Planning soft bitstream freeze by Oct. 31st

● Definition of “soft” is soft
– Some think it means “only critical bugfixes”
– Some think it means “we can tweak anything”
– Reality likely a pragmatic mix
● IPR analysis is not complete

From Netflix VDD17 prsentation :

Teaser : codec comparaison :

see : https://bambuser.com/v/6909221#t=2465s

x265_Project

26th September 2017, 17:49

From Timothy B. Terriberry's VDD17 presentation :
see : https://bambuser.com/v/6908002#t=2416s

Very interesting... but please use the latest build (v2.5) of x265 in your comparisons. v1.9 was released in January. Also be sure to use --tune PSNR for your PSNR comparisons, and --tune SSIM for your SSIM comparisons. Ideally, use VMAF for your objective comparison.

Can't wait for the new Netflix codec comparison.

easyfab

26th September 2017, 18:44

@x265_Project, yes agreed with you, x265 version is pretty old in this comparaison.

from Netflix teaser ( https://bambuser.com/v/6909221#t=2465s ) I don't see the versions but it use vmaf that should be better.

Full Netflix codec comparison should give more details.

HS : x265_Project, is this someone from your team ? https://bambuser.com/v/6909221#t=205

x265_Project

26th September 2017, 19:41

HS : x265_Project, is this someone from your team ? https://bambuser.com/v/6909221#t=205
Yes, that's Pradeep Ramachandran, who runs the x265 development team (also known as pradeeprama (https://forum.doom9.org/member.php?u=223284))

Clare

29th September 2017, 08:44

Evolution of the AV1 codec between October 2016 and July 2017

http://wyohknott.github.io/image-formats-comparison/comparison.html

I'll add another data point after bitstream freeze.

Tommy Carrot

29th September 2017, 16:59

Clare, in your image comparison page, the old and the new AV1 images are completely identical. Other than that, it's a very useful page, much appreciated.

Clare

29th September 2017, 21:39

Clare, in your image comparison page, the old and the new AV1 images are completely identical. Other than that, it's a very useful page, much appreciated.

I don't know the files got mixed but it should work now.

mzso

29th September 2017, 21:43

I don't know the files got mixed but it should work now.

Wow. the new one is even worse than the old (which is pretty bad alread) on that factory image. Large almost flat areas.

easyfab

30th September 2017, 13:56

@clare

could you add PIK ( https://github.com/google/pik ) in a next comparison ?

Tommy Carrot

30th September 2017, 14:56

Thanks Clare.

Wow. the new one is even worse than the old (which is pretty bad alread) on that factory image. Large almost flat areas.

Unfortunately, i have to agree. AV1 still image encoding has improved in some regards (less ringing), but it smoothes a bit too much for my liking. In many cases the old AV1 looks better than the new in my opinion.

IgorC

5th October 2017, 00:27

I've watched some images from here http://wyohknott.github.io/image-formats-comparison/
And yes, AV1 and HEVC don't retain fine details as much as Daala but they have less blocking though.

Clare

8th October 2017, 12:59

@clare

could you add PIK ( https://github.com/google/pik ) in a next comparison ?

Yeah some guy from Mozilla asked for Pik too, but the thing seems to require a lot of CPU power and I just have a mobile CPU.

MoSal

9th October 2017, 19:11

Yeah some guy from Mozilla asked for Pik too, but the thing seems to require a lot of CPU power and I just have a mobile CPU.

@Clare Here you go:
subset1 (https://archive.org/download/unsorted_files/subset1-pik-2017.10.4-ab748ffe0fb62500baaee98be831bae6f4282d57.tar) | subset2 (https://archive.org/download/unsorted_files/subset2-pik-2017.10.4-ab748ffe0fb62500baaee98be831bae6f4282d57.tar)

Encoded with --distance 3 (maximum compression). Images are still larger than the ones used in your current comparison, especially the more compressible ones.

bstrobl

20th October 2017, 20:34

Demuxed 2017 videos are on their Youtube channel (https://www.youtube.com/channel/UCIc_DkRxo9UgUSTvWVNCmpA). Apparently the AV1 still image format will be called AVIF.

hajj_3

21st October 2017, 02:19

https://i.imgur.com/H5tly3v.png

This is a screenshot from the October 5th Demuxed video in the post above this. Its a shame the version of x265 is old that they are comparing this to and no x264 to compare to.

benwaggoner

22nd October 2017, 17:12

This is a screenshot from the October 5th Demuxed video in the post above this. Its a shame the version of x265 is old that they are comparing this to and no x264 to compare to.
Also, these aren't particularly great metrics for moving images; none of them include any temporal component to detect things like keyframe strobing.

DMOS is the gold standard of course, but is expensive and non-automatable. I would like to see at least VMAF scores, as VMAF looks to be the substantially best objective video metric available, at least for SDR <=1080p and >300 Kbps.

I am baffled by the use of such an old x265 build. Even in placebo it'll run a ton faster than the current AV1 reference implementation. So it'd be trivial to rerun the test at the same time the final tests for AV1 are done for a presentation like this.

Are the different command lines used for the different codecs listed somewhere?

dapperdan

24th October 2017, 14:15

In case anyone else was confused like I was, the still image format based on AV1 called AVIF is mentioned (briefly) in a video mostly on other topics, given by Netflix at the Demuxed conference, not in either of the two videos that mention AV1 in their titles:

https://www.youtube.com/watch?v=PSdhW-R9u6s

birdie

25th October 2017, 08:06

AV1 status report (Oct 20, 2017)

https://www.youtube.com/watch?v=yKEDf5-2sT4

mzso

25th October 2017, 09:26

dapperdan

25th October 2017, 13:20

It's at 1:30 through to about 4 minues though it pretty much only says "We expect to have a new image format based on [AV1] called AVIF" and about 3 minutes makes clear this is just a I-Frame of AV1 and aimed towards distribution rather than storage.

dapperdan

25th October 2017, 17:44

AV1 status update talk from Gstreamer conference, very similar content to the Demuxed talk.

https://gstconf.ubicast.tv/videos/av1-the-quest-is-nearly-complete/

dapperdan

25th October 2017, 17:47

A PhD-level internship for working on AV1 at Mozilla is open for applications:

https://careers.mozilla.org/position/gh/881961

bstrobl

25th October 2017, 21:34

Hope not too many issues crop up in the reference implementation due to the final rush to get things done.

TD-Linux

27th October 2017, 17:36

I am baffled by the use of such an old x265 build. Even in placebo it'll run a ton faster than the current AV1 reference implementation. So it'd be trivial to rerun the test at the same time the final tests for AV1 are done for a presentation like this.

Are the different command lines used for the different codecs listed somewhere?

Yeah using the old version is not great (which is why I was sure to list it) I want to provide better x265 numbers before presenting numbers with something closer to the "final" codec (the "AV1" here is missing features too). Note it's probably far from the only issue comparing x265 and AV1 - both use very different reference frames and keyframe boosts so doing a comparison with metrics is quite hazard frought. The VP9 numbers are much more comparable. The x265 parameters were:

--preset placebo --no-wpp --bframes 16 --merange 256--min-keyint 1000 --keyint 1000 --no-scenecut --crf=$x

The bframes and merange options were determined through trial and error to improve x265's metric score. I've run x265 since but haven't tried to re-optimize these on a newer build.

This is done on the AWCY infrastructure. Here are two more recent results, still with the old x265 runs:

https://arewecompressedyet.com/?job=x265-1.9-hl-placebo-nowpp-b16-me256-objective-1-fast-3&job=debargha-adopted-0928%402017-09-28T21%3A43%3A40.468Z

with --tune psnr

https://arewecompressedyet.com/?job=x265-1.9-hl-placebo-nowpp-psnr-objective-1-fast-4&job=debargha-adopted-0928%402017-09-28T21%3A43%3A40.468Z

benwaggoner

27th October 2017, 19:09

Yeah using the old version is not great (which is why I was sure to list it) I want to provide better x265 numbers before presenting numbers with something closer to the "final" codec (the "AV1" here is missing features too). Note it's probably far from the only issue comparing x265 and AV1 - both use very different reference frames and keyframe boosts so doing a comparison with metrics is quite hazard frought. The VP9 numbers are much more comparable. The x265 parameters were:
An apples-to-apples comparison of a bitstream is impossible. All that really is possible is to compare DMOS of an optimal encode from the best available encoders for each format targeting the same scenario.

--preset placebo --no-wpp --bframes 16 --merange 256--min-keyint 1000 --keyint 1000 --no-scenecut --crf=$x
No IDR frames and no rate control isn't a real-world scenario. But assuming these are short clips

Why a CRF encode? If you want a particular bitrate to compare quality, you should use 2-pass VBR. Iteratively selecting a CRF to get the target file size is just a very slow way to get an identical result.
If you stick with single pass, use --rc-lookahead 250
You should add --cu-lossless to fully exercise x265 and HEVC features. It can improve efficiency with synthetic elements and when visual lossless.
You should add --tskip, which can often improve x265 with fine details.
You should try --subme 7; placebo defaults to 5. I don't know if it'll offer practical improvements, but may well for objective metrics when using --tune for those metrics.
You should try --me sea or even full if you want Full Placebo. They likely would help a bit with PSNR and objective metrics, although it doesn't seem that useful in the real world.
For lower syntax overhead, try--opt-cu-delta-qp.
You should be testing with the current release version of x265 for when you are running the comparison. AV1 isn't going to compete against last year's x265! The competition is between the best available encoders at the time of a comparison.

The bframes and merange options were determined through trial and error to improve x265's metric score. I've run x265 since but haven't tried to re-optimize these on a newer build.
Those should be fine, albeit super slow. Even placebo only uses merange of 92. Tskip is going to offer a lot better quality @ speed improvement.

Also, none of the metrics I've seen published have particularly good correlation to DMOS. If you can't do a real subjective test, you should at least include VMAF, which is definitely the best available subjective metric today.

This is done on the AWCY infrastructure. Here are two more recent results, still with the old x265 runs:

https://arewecompressedyet.com/?job=x265-1.9-hl-placebo-nowpp-b16-me256-objective-1-fast-3&job=debargha-adopted-0928%402017-09-28T21%3A43%3A40.468Z

with --tune psnr

https://arewecompressedyet.com/?job=x265-1.9-hl-placebo-nowpp-psnr-objective-1-fast-4&job=debargha-adopted-0928%402017-09-28T21%3A43%3A40.468Z
If you are testing SSIM, you need to use --tune ssim and --rd-ssim. --tune PSNR generally gives worse results with SSIM than not using any --tune, as your results show.

But, really, these results don't matter with an old version. There has been a ton of tuning since that x265 build. Ones relevant to placebo 8-bit SDR testing include:

Support for non-IDR I-frames (very relevant with --no-keyint)
new lambda tables
A bunch of syntax simplification tools

There is a temptation to assume there exists a way to compare bitstreams outside of their encoders, but there simply isn't. Which is why I recommend picking a real world scenario and tuning each encoder as best as possible for that scenario. Ignoring rate control, keyframes, and subjective quality excludes critical features always used in real-world encoding, and results in a less relevant real-world test.

And bitrates need to be used where all streams to be tested show some degree of compression artifacting. If any stream is visually lossless for any significant period, we don't know if the bitrate is higher than is needed to be visually lossless. That tends to underestimate the advantage of the more efficient encoder.

Two tests I like are:

VBR:
2-pass VBR
peak bitrate 2x average bitrate
VBV set to the max of the lowest Profile @ Level for the content frame size and fps
Open GOP with adaptive duration of a maximum of 5 seconds

CBR:
1-pass CBR
VBV set to 2x bitrate
Fixed 2 second Closed GOP

The minimum viable objective metric is VMAF, in my opinion. All the ones currently used for this comparison don't include temporal comparisons(need to catch keyframe strobing and grain swirling!), and all have lots of known defects resulting in poor subjective comparisons. Plus the average of squared errors of individual frames does nothing to pick up on quality variation inside of a clip. A clip that is 3 second great and 3 seconds awful can have a better psnr and ssim as a clip that is consistently mediocre, but consistently mediocre is a much better subjective experience. I understand that is why rate control is deactivated in codec comparisons, but that itself assumes that QP==constant quality, when we know it isn't (which is why CRF was invented).

The better the metrics being used, the more relevant the comparison. And it is also helpful for designers of new bitstreams and encoders to get them focused on optimizing the stuff that really matters. The whole sum of squared PSNR and no rate control biases codec development for codecs where fixed QP optimizes for high mean PNSR per frame. And that just isn't something that matters in a real-world encoder with rate control, adaptive quantization, and watched by humans.

It is illustrative to encode with --tune psnr and see the ways that subjective quality degrades when optimizing for that metric. Or just using fixed QP.

TD-Linux

27th October 2017, 23:32

An apples-to-apples comparison of a bitstream is impossible. All that really is possible is to compare DMOS of an optimal encode from the best available encoders for each format targeting the same scenario.

Agreed. I've set up some infrastructure that makes it possible to crowdsource this as well, so I'd like to do so once AV1's done.

No IDR frames and no rate control isn't a real-world scenario. But assuming these are short clips
Yup, they are only 60 frames long and intentionally don't have scenecuts. This is done primarily for performance reasons (it also approximately matches the HEVC test conditions, though whether that should be a goal is questionable). Note that the primary use case of this platform is to quickly iterate small changes - it is a slight abuse to be doing cross codec comparisons...

Why a CRF encode?

We're calculating bd-rate, which plots several rate points on a curve and integrates the area difference between them to get an "average" change in rate. Precisely hitting a rate target isn't important. In fact, using VBR is counterproductive as it often adds noise to the results for small changes, and also x265 and libaom's VBR modes aren't really comparable. It might make more sense to use VBR modes for visual comparisons, though (with careful consideration of the buffer models). And possibly with some objective metrics as well, but I think libaom's rate controller will need to be rewritten to have a more x265-like mode before this really produces interpretable results.
You should add --cu-lossless to fully exercise x265 and HEVC features. It can improve efficiency with synthetic elements and when visual lossless.
Noted. There a couple of clips in the test set that might benefit.

You should add --tskip <snip>

Noted, I'll try iteratively adding them to the current release (previously I've found that that some of these options were less well tested and didn't always offer improvements)

Also, none of the metrics I've seen published have particularly good correlation to DMOS. If you can't do a real subjective test, you should at least include VMAF, which is definitely the best available subjective metric today.

I've actually added it already, the main issue I've ran into is that VMAF tends to saturate quickly at higher qualities and actually goes down slighty, this causes bd-rate to be come uncomputable. I need to come up with some sort of solution to this. Select VMAF and individual videos at this link to see the problem: https://arewecompressedyet.com/?job=x265-2.5-hl-placebo-nowpp-normal-tuning-objective-1-fast%402017-09-23T17%3A06%3A32.304Z

I also do want to warn that I've seen VMAF give rather unexpected results. For example, AV1's CDEF filter produced clearly superior results in a subjective test but VMAF shows it as several percent worse. In addition, VMAF hates x264 and x265's AQ modes. The greatest strength of VMAF is that it tends to offer an absolute quality measure across different types of video - but locally it's far from perfect.

iwod

30th October 2017, 08:25

Hope not too many issues crop up in the reference implementation due to the final rush to get things done.

Which is exactly the same I am feeling now.

But I dont think it matters, at least I hope that is the way Open Media Alliance sees it. If they are in it for the long run. AV1 shouldn't really be perfect. But it should be a statement to the world, that it is possible to do video codec this way.

Then I hope they will start drafting a AV2 spec along with a ecosystem around it.

But given the way google does thing, I am not holding my breath.

benwaggoner

30th October 2017, 17:46

Yup, they are only 60 frames long and intentionally don't have scenecuts. This is done primarily for performance reasons (it also approximately matches the HEVC test conditions, though whether that should be a goal is questionable). Note that the primary use case of this platform is to quickly iterate small changes - it is a slight abuse to be doing cross codec comparisons...
Only 60 frame clips? No scenecut makes perfect sense in that case, but I worry about the broad applicability of the results. The VBV is a huge percentage of the bitrate at those low sizes, which can yield a lot of variability of the size of a compliant stream. And a 2-sec GOP is on the low end of typical usage anyway.

We're calculating bd-rate, which plots several rate points on a curve and integrates the area difference between them to get an "average" change in rate. Precisely hitting a rate target isn't important. In fact, using VBR is counterproductive as it often adds noise to the results for small changes, and also x265 and libaom's VBR modes aren't really comparable.
Perhaps the implementations aren't comparable, but the problem to solve is the same: maximum quality given a maximum file size and a maximum VBV. So I would think the results are comparable, even if not comparable.

It might make more sense to use VBR modes for visual comparisons, though (with careful consideration of the buffer models). And possibly with some objective metrics as well, but I think libaom's rate controller will need to be rewritten to have a more x265-like mode before this really produces interpretable results.
That is a core point. Are we comparing the ability of the bitstream or of the best reference encoder? I'd argue that doing the former is impossible to do well with high precision. But I can see the value in getting a snapshot estimate.

I've actually added it already, the main issue I've ran into is that VMAF tends to saturate quickly at higher qualities and actually goes down slighty, this causes bd-rate to be come uncomputable. I need to come up with some sort of solution to this.
If perceptual quality is saturating, than VMAF is yielding appropriate results. From a DMOS perspective, the closer we are to visually lossless, the smaller the relative efficiency of different encoders becomes. We would expect meaningful distortion to flatten out at a certain point. It is kind of ridiculous that PSNR -10 to -30 has the same weight as PSNR -60 to -80, since the former is a huge visual quality difference and the latter is invisible.

I also do want to warn that I've seen VMAF give rather unexpected results. For example, AV1's CDEF filter produced clearly superior results in a subjective test but VMAF shows it as several percent worse. In addition, VMAF hates x264 and x265's AQ modes. The greatest strength of VMAF is that it tends to offer an absolute quality measure across different types of video - but locally it's far from perfect.
VMAF isn't perfect. Its test range was relatively limited (1080p down to ~300 Kbps IIRC) and was mainly done with x264. Since it was only trained on x264 style artifacts, types of artifacts only appearing in HEVC and/or AV1 might give weird results.

In theory, the VMAF framework can be used, but using new clips to retrain the ML. In practice, I think VMAF will need and enhanced temporal component to capture a broader range of codecs and scenarios. In particular, I think the current VMAF will underestimate the perceptual experience hit of keyframe strobing, and thus wouldn't capture Open versus Closed GOP differences.

Overall, I think you're making a very good effort here. This is really hard stuff to do well. Fundamentally, there are lots of real-world things we want to predict from metrics that we simply can't predict well. Even DMOS has its limitations, as it takes so long that the results generally don't reflect the abilities of encoder implementations by the time they are published.

And golden eyes have all kinds of biases. I know I am so trained to pick up and classic forms of encoding issues that I notice things real-world customers almost never will.

We continue to slouch towards mediocrity.

bstrobl

1st November 2017, 11:04

Which is exactly the same I am feeling now.

But I dont think it matters, at least I hope that is the way Open Media Alliance sees it. If they are in it for the long run. AV1 shouldn't really be perfect. But it should be a statement to the world, that it is possible to do video codec this way.

Then I hope they will start drafting a AV2 spec along with a ecosystem around it.

But given the way google does thing, I am not holding my breath.

Google seems to be cooperating well enough with the group(along with everyone else even if they are on opposing sides e.g. Intel/AMD). AV1 is unlikely to have the same major issues like VP9, but it is slowly looking to become more of a stopgap for AV2 due to time pressure. I am seeing a lot of experiments being moved to AV2, which will hopefully be done right once the pressure to rush things out clears after AV1 is released.

Can't complain about the current state that much however, AV1 is still a very good codec :)

As for the ecosystem, I am hoping for a family of related container formats, something like:
webm - video (AV1/Opus)
webp - picture (AV1 Intra) - throw out VP8
weba - audio (Opus)

It would definitely help to market these codecs and formats a bit more to the general populace. Not sure AVIF is that great to pronounce ;)

hajj_3

1st November 2017, 13:13

As for the ecosystem, I am hoping for a family of related container formats, something like:
webm - video (AV1/Opus)
webp - picture (AV1 Intra) - throw out VP8
weba - audio (Opus)

It would definitely help to market these codecs and formats a bit more to the general populace. Not sure AVIF is that great to pronounce ;)

using the extension .webp would be a bad idea. As people may try and view a vp8 .webp file in a view/browser that only supports av1 .webp. They should use the extension .avif. Avif will be good enough for a decade as image compression isn't going to improve that much. JPEG has been around for over 20yrs and avif is only going to be ~65% smaller. There isn't any point making a new image format every ~3yrs, there is a good benefit to making new aom video codecs every 3yrs though.

mzso

1st November 2017, 13:25

I am seeing a lot of experiments being moved to AV2, which will hopefully be done right once the pressure to rush things out clears after AV1 is released.

I will be thoroughly disappointed if AV2 turns out to be another tweakfest for old ideas. I don't think there's a point in creating yet another format to a similar concept. Development would will have ever diminishing returns anyway.

I think AV2 should be something fundamentally different (for the better) and they'll finish it whenever they do.

there is a good benefit to making new aom video codecs every 3yrs though.

I strongly disagree... In three years they can't even exploit the full potential of a codec format.
It's only good for HW manufacturers, who can resale the same crap, but with a newer HW decoder.

benwaggoner

1st November 2017, 18:51

As for the ecosystem, I am hoping for a family of related container formats, something like:
webm - video (AV1/Opus)
webp - picture (AV1 Intra) - throw out VP8
weba - audio (Opus)

Why not use MPEG-4 program streams for video, HEIF for picture, and MPEG-4 program streams for audio? Dropping in a new codec is a lot easier than full support for a new container format. And we have a LOT of mature muxing, distribution, and playback tech built around MPEG-4 PS.

benwaggoner

1st November 2017, 18:57

using the extension .webp would be a bad idea. As people may try and view a vp8 .webp file in a view/browser that only supports av1 .webp. They should use the extension .avif. Avif will be good enough for a decade as image compression isn't going to improve that much. JPEG has been around for over 20yrs and avif is only going to be ~65% smaller. There isn't any point making a new image format every ~3yrs, there is a good benefit to making new aom video codecs every 3yrs though.
Maybe a 65% size reduction for natural images, which are JPEG's sweet spot. But for sharp-edged and synthetic content like text, line art, screen shots, noise-free gradients, etcetera, JPEG is quite bad. I've been able to get 95% reductions for Manga-style art using HEIF HEVC versus JPEG. I imagine AV1 would be in the same rough ballpark.

The goal isn't just to replace JPEG, but also PNG and GIF. HEIF+HEVC is a superset of all of JPEG, PNG, and GIF, and offers better efficiency than any of them for all their scenarios, and adds a lot of additional scenarios as well (like real PQ Rec. 2020 style HDR). An HEIF+AV1 would likely have similar potential.

hajj_3

1st November 2017, 21:04

Maybe a 65% size reduction for natural images, which are JPEG's sweet spot. But for sharp-edged and synthetic content like text, line art, screen shots, noise-free gradients, etcetera, JPEG is quite bad. I've been able to get 95% reductions for Manga-style art using HEIF HEVC versus JPEG. I imagine AV1 would be in the same rough ballpark.

The goal isn't just to replace JPEG, but also PNG and GIF. HEIF+HEVC is a superset of all of JPEG, PNG, and GIF, and offers better efficiency than any of them for all their scenarios, and adds a lot of additional scenarios as well (like real PQ Rec. 2020 style HDR). An HEIF+AV1 would likely have similar potential.

heif requires licensing h265 patents though which can be expensive. Avif will be patent free, so much better to use that.

bstrobl

2nd November 2017, 10:28

Why not use MPEG-4 program streams for video, HEIF for picture, and MPEG-4 program streams for audio? Dropping in a new codec is a lot easier than full support for a new container format. And we have a LOT of mature muxing, distribution, and playback tech built around MPEG-4 PS.

I guess the point is to use simplified containers dedicated to few codecs to ensure a decent chance of compatibility, as dropping in newer codecs onto old containers may cause frustrations in the future. HEIF is also a very large spec from what I can tell, would make sense to use a heavily simplified version to ensure compatibility and reliability for standard web distribution. WebP is still at version 0.6 so something could still be fixed up for version 1.0 rather than ditching the name. Ingraining format names like JPEG can be quite useful sometimes.

heif requires licensing h265 patents though which can be expensive. Avif will be patent free, so much better to use that.

The HEIF container itself should not have any associated patent fees, only the HEVC Intra part. Not sure what AVIF brings to the table in this case actually.

MoSal

2nd November 2017, 21:48

Why not use MPEG-4 program streams for video, HEIF for picture, and MPEG-4 program streams for audio? Dropping in a new codec is a lot easier than full support for a new container format. And we have a LOT of mature muxing, distribution, and playback tech built around MPEG-4 PS.

I'm not sure who is the target of those suggestions.

* For a new image format to gain relevant success, browser vendors will have to reach a consensus. Google and Mozilla are not going to support anything HEVC or MPEG based.

* weba is already the unofficial extension of YouTube's Opus WebM DASH streams. weba/Opus/~160kbps is the highest quality 2ch audio format available (MP4/AAC/256kbps is discontinued).

* For local storage, Matroska works, and will work, just fine with any codec combination.

* Browsers will support AV1/Opus in WebM by default (muxed or separate, including live DASH/WebM streams).

TD-Linux

2nd November 2017, 23:59

LigH

8th November 2017, 10:22

Since MABS is able to build aomenc/aomdec as separate encoder/decoder application pair, I wanted to try it once with a small sample (Siemens "foreman", CIF PAL, 300 frames, Derf's Y4M fixed to 25 fps), running on an AMD Phenom-II X4 (other encoders want to use at most SSE2 here).

Basic batch:
aomenc -v --passes=2 --pass=1 --fpf=foreman_cif.basic.av1.fpf --target-bitrate=300 -o foreman_cif.basic.av1.webm foreman_cif_pal.y4m
aomenc -v --passes=2 --pass=2 --fpf=foreman_cif.basic.av1.fpf --target-bitrate=300 -o foreman_cif.basic.av1.webm foreman_cif_pal.y4m

Pass 1 finishes quickly, only few seconds. Pass 2, instead ... a previous run with a more explicit command line estimated several days to finish. So I reduced the parameter set and tried again. Still:

>aomenc -v --passes=2 --pass=1 --fpf=foreman_cif.basic.av1.fpf --target-bitrate=300 -o foreman_cif.basic.av1.webm foreman_cif_pal.y4m
Codec: AOMedia Project AV1 Encoder v0.1.0-6495-g63d190aea
Source file: foreman_cif_pal.y4m File Type: Y4M Format: I420
Destination file: foreman_cif.basic.av1.webm
Coding path: LBD
Encoder parameters:
g_usage = 0
g_threads = 8
g_profile = 0
g_w = 352
g_h = 288
g_bit_depth = 8
g_input_bit_depth = 8
g_timebase.num = 1
g_timebase.den = 25
g_error_resilient = 0
g_pass = 0
g_lag_in_frames = 19
rc_dropframe_thresh = 0
rc_resize_mode = 0
rc_resize_denominator = 8
rc_resize_kf_denominator = 8
rc_end_usage = 0
rc_target_bitrate = 300
rc_min_quantizer = 0
rc_max_quantizer = 63
rc_undershoot_pct = 25
rc_overshoot_pct = 25
rc_buf_sz = 6000
rc_buf_initial_sz = 4000
rc_buf_optimal_sz = 5000
rc_2pass_vbr_bias_pct = 50
rc_2pass_vbr_minsection_pct = 0
rc_2pass_vbr_maxsection_pct = 2000
kf_mode = 1
kf_min_dist = 0
kf_max_dist = 9999
Pass 1/2 frame 300/301 55384B 1476b/f 36922b/s 3788536 us (79.19 fps)

>aomenc -v --passes=2 --pass=2 --fpf=foreman_cif.basic.av1.fpf --target-bitrate=300 -o foreman_cif.basic.av1.webm foreman_cif_pal.y4m
Pass 2/2 frame 22/3 24753B 1018316 ms 1.30 fpm [ETA 6:55:11] 4F
Pass 2/2 frame 24/5 25314B 1435997 ms 1.00 fpm [ETA 8:18:27] 4F

The output seems to play with ANSI Escape sequences, which Windows 7 cmd may not support on its own...

The ETA will rise the longer I let it ... do whatever it does. Such a speed is ... "concerning", nicely said. And I wonder what the reason could be: Is there a minimum CPU requirement for assembly optimized routines way beyond SSE2? Or is there a possible mis-configuration in the build? Or are the computational efforts so extreme when not capped by a per-frame deadline?

Unfortunately, there is no support in ffmpeg yet (JEEB mentioned some shared variable names with libvpx in IRC), thus no playback in LAV Filters (e.g. in MPC-HC) yet, either. At most it is detected...

Codecs:
D..... = Decoding supported
.E.... = Encoding supported
..V... = Video codec
..A... = Audio codec
..S... = Subtitle codec
...I.. = Intra frame-only codec
....L. = Lossy compression
.....S = Lossless compression
-------
..V.L. av1 Alliance for Open Media AV1

BTW, the low target bitrate of 300 kbps is not the reason, it is just as slow for 3,000. And a deadline goal '--good' did not change the speed either.

Tommy Carrot

8th November 2017, 15:44

The ETA will rise the longer I let it ... do whatever it does. Such a speed is ... "concerning", nicely said. And I wonder what the reason could be: Is there a minimum CPU requirement for assembly optimized routines way beyond SSE2? Or is there a possible mis-configuration in the build? Or are the computational efforts so extreme when not capped by a per-frame deadline?

BTW, the low target bitrate of 300 kbps is not the reason, it is just as slow for 3,000. And a deadline goal '--good' did not change the speed either.
You need to play around with "--cpu-used" command. It's basically a speed/quality tradeoff, 8 is the fastest, 0 (the default) is the slowest but is supposed to have the best quality.

LigH

8th November 2017, 15:52

I do now ... for my hardware, 4 is still a challenge (~10 min for 300 frames CIF). And I guess to watch the result, I still need to decode it to Y4M again...

BTW, what's this hex code at the end of the progress line? A flag for developers, giving hints about the result type and efficiency?

benwaggoner

8th November 2017, 22:46

heif requires licensing h265 patents though which can be expensive. Avif will be patent free, so much better to use that.
HEIF is codec agnostic. It can use JPEG, H.264, HEVC, and it would be trivial to extend to AV1.

I don't have any specific thoughts about how HEVC and AV1 would compare technically as still image codecs.

Also, I would speculate that a lot of the HEVC IP wouldn't apply to still image encoding; so much is around interframe encoding.

LigH

9th November 2017, 20:58

Brief result: Tested --cpu-used 8..4 with rather low speed differences (every run around 10 minutes) and with quite good quality (no really annoying artefacts, except for floating textures). Will postpone further tests here, no immediate relevance for me, personally.

bstrobl

13th November 2017, 18:18

Facebook has joined as founding member. Guess they want to cut costs on streaming and storing video too.

cheerow

13th November 2017, 18:47

I just did some test encodes with the recent git version. All the now default enabled features (experiments) have massively increased the VMAF score compared to a few months ago. Just judging by VMAF, as flawed as it may be, AV1 is now way above x265.

Also tried some options to speed up encodes. Seems like --cpu-used has very limited effect. Encoder always ran on just one cpu until I supplied --tile-columns=X but that is bugged, only the leftmost columns comes out correctly, the others are basically broken. And even then it doesn't saturate any cpu completely.

mzso

13th November 2017, 21:57

Also tried some options to speed up encodes. Seems like --cpu-used has very limited effect. Encoder always ran on just one cpu until I supplied --tile-columns=X but that is bugged, only the leftmost columns comes out correctly, the others are basically broken. And even then it doesn't saturate any cpu completely.

Well, vpx also has crappy multi-processing which never saturates my cpu, so not really surprising.
Hopefully eventually it'll get decent multi-processing like x264.

Blue_MiSfit

13th November 2017, 22:01

I wouldn't hold your breath. The main use case for AV1 and VP9 is cloud scale distributed encoding which can very happily be single threaded because inputs are broken into small chunks and encoded in parallel across many many many small cloud VMs. Given the availability of a system to do this, it's a much better solution than trying to do per-encode-instance multithreading because it's way simpler and has zero downsides.

Multi-threading is more important for live, and for desktop encoding.

LigH

13th November 2017, 22:19

The more complex an algorithm, the more probable are dependencies between intermediate results, the less probable is optimal parallelizability...

bstrobl

18th November 2017, 10:22

IETF 100: https://www.youtube.com/watch?v=_wRLR8ypCg0

wiak

20th November 2017, 18:11

Well, vpx also has crappy multi-processing which never saturates my cpu, so not really surprising.
Hopefully eventually it'll get decent multi-processing like x264.
there is hope now that vp9 has row-mt

and on a related note streaming media C104 video with alot of AV1/HEVC talk
http://streamingmedia.brightcovegallery.com/detail/videos/streaming-media-west-2017/video/5643859282001/c104:-the-future-of-video-codecs:-vp9-hevc-av1?autoStart=true&page=1

Clare

21st November 2017, 18:44

http://demo.bitmovin.com/public/firefox/av1/

LigH

21st November 2017, 19:50

I love sloppily dropped URLs I have to visit to know what to expect...

MPEG-DASH Adaptive Streaming with AV1 by Mozilla and Bitmovin

Content encoded in AV1 by Bitmovin Encoding and played back with Bitmovin Player (7.3.0-b7) in Firefox (**.*)

Seems to require a nightly Firefox to be installed.

mzso

21st November 2017, 19:57

http://demo.bitmovin.com/public/firefox/av1/

To me video hangs every few seconds for several seconds in FF Nightly. Any better way to view it?

Can I download it somehow? It might be that something glitchy with networking.

LigH

21st November 2017, 20:00

Possibly if you somehow manage to record the MPEG DASH video stream locally and play it afterwards; but that's the opposite of the intended use: Video streaming. Who knows whether the streaming or the player is the bottleneck here (but it is hosted on Akamai network servers...).

mzso

21st November 2017, 20:21

IgorC

21st November 2017, 20:22

1080p streams have the issue. 720p and below play all fine.

Quality is less than impressive (even for highest bitrate, 1080p@3 Mbps). A lot of blur. :scared:
Probably lately AV1 will be tuned visually.

wiak

22nd November 2017, 17:07

To me video hangs every few seconds for several seconds in FF Nightly. Any better way to view it?

Can I download it somehow? It might be that something glitchy with networking.
well thats one of the long time quirks of that decoder, i suspect they use the same decoder firefox used in a another older demo, what hw do u got?
i suspect its very single core depenant on decoding just like the current encoder

wait for the bitstream to freeze to check it out, thats when all the encoders and decoders align to decode the same file, atm the decoder cant decode another version of the encoder

mzso

22nd November 2017, 17:41

well thats one of the long time quirks of that decoder, i suspect they use the same decoder firefox used in a another older demo, what hw do u got?
i suspect its very single core depenant on decoding just like the current encoder

wait for the bitstream to freeze to check it out, thats when all the encoders and decoders align to decode the same file, atm the decoder cant decode another version of the encoder

I have a Ryzen 1600 right now.

wiak

22nd November 2017, 18:39

I have a Ryzen 1600 right now.
hello there, your zenpai here! i got a 1700X :)

Clare

25th November 2017, 17:45

hello there, your zenpai here! i got a 1700X :)

I'm looking to buy one too (or maybe wat for the Zen+ in February), what kind of fps do you get for AV1 or x265?

bstrobl

27th November 2017, 17:36

hajj_3

27th November 2017, 22:37

Streaming Tech Sweden AV1/HEVC comparison by Jan Ozer: https://www.youtube.com/watch?v=KzqOIddTNPQ

Hopefully the AV1 update by Jai Krishna will be uploaded soon. For those who are impatient, the slides are here: https://speakerdeck.com/stswe/av1-update-by-jai-krishnan-from-google

only ~25% better compression than vp9 so far. They were claiming 30% by bitstream freeze, lets hope they make it.

They have delayed the bitstream freeze to January now instead of end of year, not a big deal.

VincAlastor

29th November 2017, 21:06

https://demo.bitmovin.com/public/firefox/av1/

how can i grab this demo stream? I wanna analyse and test this stream outside of firefox.

sneaker_ger

29th November 2017, 21:12

youtube-dl (https://rg3.github.io/youtube-dl/) https://bitmovin-demos.commondatastorage.googleapis.com/mozillaAV1_Oct2017/e87fb2378f01103d5d6e477a4ef6892dc714e614_v1/stream.mpd

bstrobl

30th November 2017, 14:32

Mozilla Blog: https://hacks.mozilla.org/2017/11/dash-playback-of-av1-video/

mzso

30th November 2017, 22:53

Hmmm. It looks like they removed the 1080 videos from the demo page.

benwaggoner

1st December 2017, 18:46

Hopefully the AV1 update by Jai Krishna will be uploaded soon. For those who are impatient, the slides are here: https://speakerdeck.com/stswe/av1-update-by-jai-krishnan-from-google
It makes me somewhat nervous that the percentage gains go down the more subjectively correlated the metric used is.

-26.51% for VOD PSNR-Y but only -23.57% for MS-SSIM. And no metrics that include any temporal component. I'd love to see at least VMAF scores, which is the metric most predictive of DMOS that we have today.

The VPx series was always heavily tuned to optimize for PSNR, so its theoretical PSNR always overstated the series' actual perceptual quality. At least since VP6, which had a lot of advanced postprocessing technology that did a good job of hiding artifacts in a lot of ways.

IgorC

1st December 2017, 20:35

https://demo.bitmovin.com/public/firefox/av1/

how can i grab this demo stream? I wanna analyse and test this stream outside of firefox.

Hmmm. It looks like they removed the 1080 videos from the demo page.
Yep.

Also audio is Opus @ 32 kbps. Opus is the best available audio codec right now though 32 kbps is low.

Opus @ 48 kbps has much better quality which makes more sense for 720p streams (and 64-96+ kbps for 1080p)

VincAlastor

4th December 2017, 23:04

Yep.

Also audio is Opus @ 32 kbps. Opus is the best available audio codec right now though 32 kbps is low.

Opus @ 48 kbps has much better quality which makes more sense for 720p streams (and 64-96+ kbps for 1080p)

But it's amazing what audio quality is possible with 32 kbit/s! Thank you IgorC and all other opus audio developers! :)

I can't wait for upcoming opus 1.3 alpha/beta release!

bstrobl

5th December 2017, 16:41

It makes me somewhat nervous that the percentage gains go down the more subjectively correlated the metric used is.

-26.51% for VOD PSNR-Y but only -23.57% for MS-SSIM. And no metrics that include any temporal component. I'd love to see at least VMAF scores, which is the metric most predictive of DMOS that we have today.

The VPx series was always heavily tuned to optimize for PSNR, so its theoretical PSNR always overstated the series' actual perceptual quality. At least since VP6, which had a lot of advanced postprocessing technology that did a good job of hiding artifacts in a lot of ways.

I suppose the good news here is that AV1 has had no form of optimisation beyond the basic stuff done to it yet. Might be able to squeeze out a couple percent more with improved encoders. Right now encoding time is the biggest problem, especially for RTC.

benwaggoner

7th December 2017, 00:15

I suppose the good news here is that AV1 has had no form of optimisation beyond the basic stuff done to it yet. Might be able to squeeze out a couple percent more with improved encoders. Right now encoding time is the biggest problem, especially for RTC.
I'm sure there are massive potential gains that can be squeezed out by real-world encoders. Something like x264 and x265 can run rings around the reference encoders with real-world long form content using real-world parameters, and still be orders of magnitude faster.

It just takes a whole lot of development that's out of scope of defining a bitstream to get those gains. Codec development focused on PSNR @ Constant QP also runs the risk of over optimizing for a design where QP correlates highly with PSNR.

bstrobl

7th December 2017, 11:51

I'm sure there are massive potential gains that can be squeezed out by real-world encoders. Something like x264 and x265 can run rings around the reference encoders with real-world long form content using real-world parameters, and still be orders of magnitude faster.

It just takes a whole lot of development that's out of scope of defining a bitstream to get those gains. Codec development focused on PSNR @ Constant QP also runs the risk of over optimizing for a design where QP correlates highly with PSNR.

Doesn't HEVC do the same thing to an extend? Besides, the VP9 base will still be prominent in AV1 due to limited development time and the desire for reusability of components by chipset manufacturers.

The fact that AV1 does well when compared to x265 with a five year head start is neat, but I won't deny the fact that this was a somewhat rushed development.

My guess is most desirable features and improvements will only come with AV2, when the Alliance have most of the development kinks worked out.

iwod

10th December 2017, 13:52

Doesn't HEVC do the same thing to an extend? Besides, the VP9 base will still be prominent in AV1 due to limited development time and the desire for reusability of components by chipset manufacturers.

The fact that AV1 does well when compared to x265 with a five year head start is neat, but I won't deny the fact that this was a somewhat rushed development.

My guess is most desirable features and improvements will only come with AV2, when the Alliance have most of the development kinks worked out.

I am hoping for the best on AV2. But given how they have communicate, and expecting to have AV2 and AV3 done in next 5 years just shows they have absolutely no idea how real world progress and works.

Then there is the law of diminishing return, a lot of the improvement and progress made in x264 and x265 took years to fine tune. It wasn't long ago x264 was still beating x265 at high bitrate encoding.

mzso

10th December 2017, 15:26

I am hoping for the best on AV2. But given how they have communicate, and expecting to have AV2 and AV3 done in next 5 years just shows they have absolutely no idea how real world progress and works.
I don't have high hopes. They'll just probably keep tweaking the same basic concept (dct on blocks) as it's done for decades now.
Then there is the law of diminishing return, a lot of the improvement and progress made in x264 and x265 took years to fine tune. It wasn't long ago x264 was still beating x265 at high bitrate encoding.
That's why it would make sense to head to a radical new direction. But they won't.
I doubt that there'll be any interest in adopting AV2 if it ever gets finished. By then AV1 will be pretty well optimized and AV2 won't offer any improvement of particular significance.

bstrobl

11th December 2017, 17:56

That's why it would make sense to head to a radical new direction. But they won't.
I doubt that there'll be any interest in adopting AV2 if it ever gets finished. By then AV1 will be pretty well optimized and AV2 won't offer any improvement of particular significance.

Nothing wrong with DCT on blocks, worked well for a long time and still does ;).
It's a bit like squeezing out everything from current microprocessors and other modern technology, eventually you simply reach what is actually possible without going off into ridiculous complexity/cost. Daala is a good codec with a different design, but doesn't have a huge benefit over HEVC/AV1. Same with wavelets.

I doubt the Alliance will release a new codec if they can't make it at least 30% better than AV1. If there is no AV2, we will at least have a solid codec that is royalty free to depend on. Nothing wrong with a long lasting standard when you don't have to replace hardware/software and re-encode everything.

mzso

11th December 2017, 18:36

Nothing wrong with DCT on blocks, worked well for a long time and still does ;).
It's a bit like squeezing out everything from current microprocessors and other modern technology, eventually you simply reach what is actually possible without going off into ridiculous complexity/cost.

Yeah, it feels like most of the complexity of present codecs is spent on catering to blocks and deblocking.

Daala is a good codec with a different design, but doesn't have a huge benefit over HEVC/AV1. Same with wavelets.

I think alternative approaches are sorely under-researched. Not much effort was put into wavelets, even less into Daala's overlapped transformation before it was dopped.

benwaggoner

15th December 2017, 18:30

Yeah, it feels like most of the complexity of present codecs is spent on catering to blocks and deblocking.
Well, they ARE block-based codecs! New codecs are adding LOTS of knobs around block sizes and deblocking modes.

I think alternative approaches are sorely under-researched. Not much effort was put into wavelets, even less into Daala's overlapped transformation before it was dopped.
That is one of the challenges with any radically new technology. We have decades and millions of engineer-hours of experience optimizing around DCT-like block-based encoding. Even if a fundamentally new transform had a lot more potential, its initial implementations would have to compete against all the refinement of the current architectures. And it's very hard to estimate how well a basic technology will pan out. Wavelet-based video codecs were "obviously" the future, until actual real-world implementations went splat.

If we started with J2K instead of JPEG, and had all the motion estimation work done based around wavelets, hundreds of PhDs and developers could have found the magic way. And then someone with a crazy block-based codec idea would have run out of funding at just full-pel motion search, and we'd say "yeah, blocks were kind of interesting, but just never proved to be competitive."

bstrobl

19th December 2017, 09:55

Took a while but here is the Google update on AV1:

https://www.youtube.com/watch?v=sBAHBZsh4AA&list=PLpv8XV4Px3qKVWXj3rzJHP8y8-Qaqcvb0&index=7

hajj_3

19th December 2017, 11:23

Took a while but here is the Google update on AV1:

https://www.youtube.com/watch?v=sBAHBZsh4AA&list=PLpv8XV4Px3qKVWXj3rzJHP8y8-Qaqcvb0&index=7

The video says that they are currently up to 29% improvement over VP9 and aim to be at ~35% by the bitfreeze in January. That is a welcomed improvement as they say a month or so ago that they were aiming for 30% improvement.

hajj_3

4th January 2018, 22:19

Hell has frozen over...... Apple has quietly joined AOM as a founding member: https://www.cnet.com/news/apple-online-video-compression-av1/

nevcairiel

4th January 2018, 22:30

How can you join as a "founding member" this late?

hajj_3

4th January 2018, 23:17

How can you join as a "founding member" this late?

I presume founding members pay more money and probably have more voting rights. AOM obviously wanted Apple to join badly as having a single codec for all future smartphones and tablets would be extremely beneficial for everyone.

GTPVHD

5th January 2018, 01:57

That's unexpected but welcome news, I'm guessing Apple will have Axx SoCs with fixed function AV1 hardware decoding in the future.

And yes, Hell has frozen over.

x265_Project

5th January 2018, 03:43

That's unexpected but welcome news, I'm guessing Apple will have Axx SoCs with fixed function AV1 hardware decoding in the future.

That's not a safe assumption. Supporting a standards organization and adopting the standard in your own products and services are two separate decisions. Companies may have many different motivations for the first decision. But it's low risk. They only make the second, much more expensive decision based on a careful cost/benefit analysis for each product line (or in Apple's case, for each platform). It took Apple 4 1/2 years from the time HEVC was standardized until it announced broad support for HEVC (and AV1 is not yet finalized, as far as I know). Apple joining the Alliance for Open Media may actually end up helping HEVC adoption, as AV1 (or the threat of a major platform owner like Apple actually adopting AV1) provides a strong counter-balancing force to convince HEVC patent holders to avoid unreasonable patent license demands. HEVC doesn't need to be free to all implementers to succeed, but it definitely needs to be reasonable, and the work of the Alliance for Open Media is very helpful to the overall cause of enabling advanced encoding standards at reasonable costs. Only time will tell how it all plays out.

iwod

5th January 2018, 11:48

There is NetVC, which aims to be a royalty free Video Codec for the Internet, and AV1 is the front runner ( or the only contender ) for it.

Apple may very well only support AV1 in Safari only, much like opus on their platform.

Since Apple already have cross licensing with all the HEVC patents holder, any video patents against AV1 is highly unlikely to be a threat to them. And like @x265_Project have said, this is a move to tell the HEVC patents holder, loosen up or get out of the way.

GTPVHD

6th January 2018, 16:27

http://www.streamingmedia.com/Articles/News/Online-Video-News/Apple-Joins-Alliance-for-Open-Media-What-Does-it-Mean-122476.aspx

iwod

7th January 2018, 13:08

http://www.streamingmedia.com/Articles/News/Online-Video-News/Apple-Joins-Alliance-for-Open-Media-What-Does-it-Mean-122476.aspx

Apart from Desktop Web, I dont see any devices that has or would only have AV1 hardware decode support and not HEVC decode support. So the argument for Apple needing AV1 because they are trying to compete with Netflix in the future is moot.

It could be Netflix and Youtube decided against HEVC, which means Apple will need to add AV1 out of necessity. I hardly doubt Apple will budge if it was only Youtube.

While the article said it was being doubtful, I actually think Apple wants its opinion and steering on AV2 a very possible reason.

My guess is that there will be more news leaking out in CES.

bstrobl

7th January 2018, 14:43

It took Apple 4 1/2 years from the time HEVC was standardized until it announced broad support for HEVC (and AV1 is not yet finalized, as far as I know). Apple joining the Alliance for Open Media may actually end up helping HEVC adoption, as AV1 (or the threat of a major platform owner like Apple actually adopting AV1) provides a strong counter-balancing force to convince HEVC patent holders to avoid unreasonable patent license demands. HEVC doesn't need to be free to all implementers to succeed, but it definitely needs to be reasonable, and the work of the Alliance for Open Media is very helpful to the overall cause of enabling advanced encoding standards at reasonable costs. Only time will tell how it all plays out.

Apple already had HEVC in the A8, only to rip it out a short time later. Even the threat of VP9 has only barely provoked licensors into giving slightly better terms.

I think Apple has noticed where the wind is blowing and is also fed up with the other patent groups, having adopted OPUS in High Sierra and iOS 11.

HEVC is done, hope you don't mind creating an xAV1 :)

Blue_MiSfit

8th January 2018, 20:00

hajj_3

8th January 2018, 21:42

HEVC is scarcely "done".

It's in production and working extremely well in UHD BluRay, UHD linear TV, and 4K OTT streaming services. It's also enabling great consumer experiences like HDR.

Even if AV1 was done today, there'd be years of runway for broad availability of hardware decoders, and performant, well tuned encoders.

I think we'll all be living with HEVC for several years, at least!

Hardware decoders will take 12-18 months to make and a small number of months for products to ship with the new chips. YouTube and Netflix will be encoding videos with AV1 within days of it being finalised. A large portion of youtube viewers use a pc which can software decode av1. Sure it will take a while for av1 to become mainstream but we will still be using it quickly. I hope that my new $40 android box that has a quad core 1.5ghz cortex a53 is powerful enough to software decode 1080p AV1.

mzso

9th January 2018, 13:11

sneaker_ger

9th January 2018, 13:27

It's often used for 4K. E.g. Netflix, Amazon, Blu-ray, DVB. Also some non-4K broadcasting, e.g. DVB-T2 in Germany is exclusively HEVC (1080p50 max).

And it seems no one is creating VP9. E.g. if you buy a camcorder it will record AVC or HEVC, not VP9. No live VP9 broadcasting. Could end up the same with AV1, i.e. we will consume it via Youtube and Netflix (non-live encoding in big server farms) but in other areas HEVC will be the leader.

We'll see ...

hajj_3

9th January 2018, 13:32

We're not even living with HEVC now. It's scarcely used. Websites use VP9 or AVC, home media is encoded in AVC.

I only came in contact with HEVC files via samples and files encoded for filesharing (and it's scarce even here).

yep, it has been a commercial flop so far. Apple's recent addition is the only major support they have had recently. A small number of tv broadcasters use it, uhd bluray and 4k streaming services but that is about it. hardly any torrents use it and those that do use a bitrate ridiculously low that it looks far worse. Unless a single patent group is formed with lower licensing costs and a cap for costs it is never going to become even vaguely as popular as h264.

And it seems no one is creating VP9. E.g. if you buy a camcorder it will record AVC or HEVC, not VP9.

hardly any camcorders, point and shoot cameras or dslr's support hevc. Those are areas that should have adopted it years ago but still haven't.

Motenai Yoda

9th January 2018, 14:15

yep, it has been a commercial flop so far. Apple's recent addition is the only major support they have had recently.
Yep, unless you count that almost all smartphones, smart tvs (especially those with uhd and hdr support), gpus, intel cpus, single board computers, tvboxes and uhd bluray players of those last 2 years can natively decode and/or encode hevc videos (apple is only a little last addiction on a large and consolidated panorama)
All streaming services as netflix, prime video, google film, itunes, youtube etc. uses hevc beside vp9 for 4k content.
All broadcasters need to use hevc on dvb-t2 trasmissions.
All UHD BD are encoded in hevc.

yep a very large "flop"

hajj_3

9th January 2018, 15:15

Yep, unless you count that almost all smartphones, smart tvs (especially those with uhd and hdr support), gpus, intel cpus, single board computers, tvboxes and uhd bluray players of those last 2 years can natively decode and/or encode hevc videos (apple is only a little last addiction on a large and consolidated panorama)
All streaming services as netflix, prime video, google film, itunes, youtube etc. uses hevc beside vp9 for 4k content.
All broadcasters need to use hevc on dvb-t2 trasmissions.
All UHD BD are encoded in hevc.

yep a very large "flop"

This post is filled with nonsense:

1. broadcasters are not require to use hevc with dvb-t2, the uk uses h264+he-aac audio on dvb-t2.
2. youtube does not encode any videos in hevc.
3. tv's and smartphones may have hevc decoders but hardly any phones record videos in hevc and hardly any tv's receive broadcasts in hevc. Saying that because there are hardware decoders in lots of devices doesn't make it a success. Lots of devices have vp8 hardware decoders but that isn't a successful codec either.

dapperdan

17th January 2018, 11:04

Apart from Desktop Web, I dont see any devices that has or would only have AV1 hardware decode support and not HEVC decode support. So the argument for Apple needing AV1 because they are trying to compete with Netflix in the future is moot.

I could imagine this applying to the next generation of Chromecast devices from Google.

I wonder if those video dongle's will lower hardware prices to the point where just shipping with free codec support would be a viable differentiation move for companies without a dog in the fight. Probably comes down to which content providers they consider essential and what those content providers in turn choose to do.

GTPVHD

22nd January 2018, 20:05

https://www.cnet.com/news/google-mozilla-av1-photo-format-could-outdo-aging-jpeg/

mzso

22nd January 2018, 21:58

https://www.cnet.com/news/google-mozilla-av1-photo-format-could-outdo-aging-jpeg/

Finally some promising news on this. I started to think that everyone in the alliance is too dumb to think of a brand new still image format.

LigH

22nd January 2018, 22:13

HerpaDerp

23rd January 2018, 08:38

Imagine, I once found a website which specialized in offering images in WebP format and was not just a format promoting site.

One.

User acceptance is hard to predict. If it doesn't offer more important advantages than just bandwidth saving (in times of VDSL and 4G), there may not be much incentive to use it. Just remember the overhead of external JavaScript modules required to keep your own source small.

http://frupic.frubar.net/thumbs/36347.png (http://frupic.frubar.net/shots/36347.jpg)

I've been improving a website for a customer off/on for the past year. One of the goals was to create product pages that showed high resolution, high quality images with alpha transparency overlayed on top of a fixed background image, so that it makes the product "pop" and look impressive when the user scrolls down the page.

I quickly ran into a roadblock where, JPEG wouldn't work because it doesn't support alpha transparency. GIF will get you close, but it's either fully opaque, or fully transparent. PNG in my instance resulted anywhere from 800KB to 1.5MB per image, and with some pages containing 20+ images, you can see how this would be a problem for mobile users.

So, my solution was to provide WebP to Chrome users on both Desktop and Android, and provide a fallback of Quantized (Lossy) PNG for Firefox, Edge, Internet Explorer, and basically any browser that doesn't support WebP.

This resulted in a massive bandwidth reduction for the user, which caused the page to load 10-15 seconds faster on 4G.

Now, you mentioned you once found a website that specialized in offering images in WebP, and I can name a big one right off the top of my head: Netflix. They in fact, provide WebP to Chrome users.

Facebook at one point dabbled with WebP, but due to the nature of users wanting to download pictures, I think they ended up upsetting people more than making them happy, since WebP is a bad format to serve to people wanting to make local backups of their files.

Now, WebP is really not the best format, but it solved a big problem for me on Chrome, especially since it captures more than 60% of the total browser marketshare. I'm not making that number up.

A big problem with WebP is that it suffers from generation loss, and for certain situations, it can produce a significantly worse looking image than JPEG, which is why it's paramount that you don't choose a quality lower than 80%.

I looked into FLIF image format, which as of right now, is supported by absolutely nobody. It's some new fangled format that shunts the most important bits to the the beginning of the image so that if you downloaded a mere 10KB of a 2MB image, you could still view a low resolution version of it, which quite frankly is awesome.

The see several immediate problems with FLIF.
1. Files take a horrendous amount of time to create if they're greater than 2048x2048px in dimensions because it's doing all sorts of color sorting and algorithms to achieve the best filesize. Time to create the file increases exponentially with dimension. We're talking 5+ minutes to create a 4096x4096 FLIF image. Also, I have been unsuccessful in creating 16bit FLIF files, but that could just be a limitation of XNViewMP. Not sure.

2. It doesn't actually solve filesize problem for mobile users. Hypothetically speaking, if you put 30 FLIF files on your web page, each of which amounts to 2MB in file size, then you're forcing the user to download 60MB of pictures. The only benefit they get is the ability to view the image before they've finished downloading, but this just simply inflates the filesize of the page enormously, and causes other files to queue during the page load time. At the end of the day, serving your users smaller images ( less than 1MB in filesize) is the absolute best way to achieve fast page load time.

3. Animated FLIF is fantastic if you have less than 30 second recordings, but if you go beyond that, it quickly becomes impractical because the user would still have to download a mega amount of data just to be able to begin displaying the image. So, at the end of the day, you're still far better off using a video codec for anything exceeding 30 seconds.... and we now have an absolute wealth of services that do exactly that (imgur, gfycat, etc). Animated FLIF is a neat proof of concept, but I see almost no practical use for it other than being able embed fast previewing short animated images into a product page... which tbh, I would probably be the one in 100,000 website developers taking advantage of that feature. lol... Right now, my current method of doing animated video is to overlay a VP9 WebM for Firefox and Chrome users, and then fallback to animated GIF for Edge / IE users. What a pain the neck, but hey it works.

4. A 30KB partial download of a FLIF looks SIGNIFICANTLY worse than WebP, Jpeg, BPG, or any new fangled image format that is saved at the exact same filesize. FLIF is fantastic looking once the full data has been received, but looks quite terrible for partial downloads if you're comparing them to already existing image formats saved at the exact same filesize.

5. If web browsers ever become intelligent enough to download "only" the bits needed for optimal viewing experience, what we will end up with, is a bunch of partial downloads sitting in our browser cache, which means if user resizes their web browser, or zooms the image, then the browser will have to request the additional data from the webserver, which means, you can end up having multiple requests for the same image... and web servers operators HATE multiple requests. They would rather you get the full file the first time, than to bog down their servers with multiple requests for the same file.

I could go on and on and on.

But what we need, is not FLIF. We need an alternative image format, that reduces file size, has features, does not suffer from generation loss, is fast to create files, and in every way shape or form, replaces JPEG and PNG. FLIF does not replace JPEG and PNG. It's great, but it doesn't resolve the 5 issues I mentioned above.

And unfortunately, AV1 probably has TERRIBLE generation loss because using similar tech as WebP, and I can almost guarantee, it will suffer from the same problems. Nevertheless, if an AV1 image format became available to use in Chrome, I would switch to it simply because I like better things.

Anyway, just thought I'd like to share. lol

Jamaika

23rd January 2018, 14:42

I quickly ran into a roadblock where, JPEG wouldn't work because it doesn't support alpha transparency.
We are talking about the JPEG standard. What about the other native JPEG development?
JPEG2000, JPEGLS or JPEGXT. Amateur production or codes will have any application.
Now, WebP is really not the best format, but it solved a big problem for me on Chrome, especially since it captures more than 60% of the total browser marketshare. I'm not making that number up.
A big problem with WebP is that it suffers from generation loss, and for certain situations, it can produce a significantly worse looking image than JPEG, which is why it's paramount that you don't choose a quality lower than 80%.
Google develops a WebP but without the VP9 codec. I don't know what creators have vision Lepton. Codec bases on WebP and JPEG. I think that you made a mistake codecs. WebP isn't 16bit, and 16bit is FIiF. Unfortunately, it works even more slowly.

HerpaDerp

23rd January 2018, 16:05

We are talking about the JPEG standard. What about the other native JPEG development?
JPEG2000, JPEGLS or JPEGXT. Amateur production or codes will have any application.

https://caniuse.com/#search=jpeg

Google develops a WebP but without the VP9 codec. I don't know what creators have vision Lepton. Codec bases on WebP and JPEG. I think that you made a mistake codecs. WebP isn't 16bit, and 16bit is FIiF. Unfortunately, it works even more slowly.

:confused:

benwaggoner

24th January 2018, 20:27

hajj_3

24th January 2018, 20:53

The only real viable replacement for GIF/PNG/JPEG I see now is HEIF, which is now the default picture format for iOS. The implementation today is HEVC, but extending it to AV1 appears reasonably straightforward.

I have no idea how HEVC and AV1 would compare for still image coding, but both are WAY better than JPEG or PNG for any kind of image type. And unbelievably better for mixed continuous/discreet tone images like graphics or comic books.

isn't heif patented though? I can't see mozilla adopting a patented format nor many phone manufacturers. AV1 is 15% better than hevc at still images according to recent statements. Google's PIK is another contender.

mzso

24th January 2018, 23:05

isn't heif patented though? I can't see mozilla adopting a patented format nor many phone manufacturers. AV1 is 15% better than hevc at still images according to recent statements. Google's PIK is another contender.

I don't think Pik can exist if they go for an AOM image format. If they decide to diverge from AV1 compatibility it's improvements will probably be merged, otherwise it'll likely get abandoned.

IgorC

25th January 2018, 20:09

The only real viable replacement for GIF/PNG/JPEG I see now is HEIF, which is now the default picture format for iOS. The implementation today is HEVC, but extending it to AV1 appears reasonably straightforward.
Can I ask why do You think that HEIF is the only viable alternative?

Not sure about HEIF but HEVC has zero chances to replace jpeg.
Enough to say that Google and Mozilla simply won't implement it. It's a big no-go. There is no even a minor doubt of that.

JPEG XL (https://jpeg.org/items/20171107_cfp_jpeg_xl.html) or intra-AV1 have all chances. Or some sort of collaboration between these two.

mzso

25th January 2018, 21:39

Can I ask why do You think that HEIF is the only viable alternative?

Not sure about HEIF but HEVC has zero chances to replace jpeg.
Enough to say that Google and Mozilla simply won't implement it. It's a big no-go. There is no even a minor doubt of that.

JPEG XL (https://jpeg.org/items/20171107_cfp_jpeg_xl.html) or intra-AV1 have all chances. Or some sort of collaboration between these two.

Well, HEIF is HEVC based, so I doubt there's any difference in the corporation's attitude toward it compared to HEVC.

dapperdan

26th January 2018, 13:35

JPEG XL (https://jpeg.org/items/20171107_cfp_jpeg_xl.html)

"To encourage widespread adoption, an important goal for this standard is to support a royalty free baseline."

Sounds like a non-starter with wishy-washy language like that. Pretty sure that's what was said about H.264 as well, but they had no real process in place to make it possible. HEVC even lacked a process to enable one-stop shopping for royalties. They all seem to be stuck in some trap of their own making.

IgorC

26th January 2018, 15:15

It's just a beginning.

"The JPEG Committee intends to publish a final Call for Proposals (CfP) following its 78th meeting (January 2018)"

There was already some collaboration(?) between Daala developers and JPEG
https://people.xiph.org/~jm/daala/revisiting/
The improvement in quality compared to the previous status update is quite obvious. Daala is now much better than both WebP and JPEG (libjpeg-turbo is the most commonly used JPEG encoder). As for Daala vs BPG/HEVC, the artifacts are obviously different and hard to judge from just four images. Opinions are likely to vary based on the viewer and the input image. At this point, what we'd really need is a full subjective test. Fortunately, this is exactly what is going to take place shortly, as Daala has been submitted as a candidate for the Image Compression Grand Challenge at ICIP 2016. The results should be available in September. In the mean time, you can read the paper we will be presenting.

I guess that now Daala is part of AV1 project there will be some feedback between AV1 and JPEG-XL.

mzso

28th January 2018, 12:54

new Libvpx released with improvements to VP9: https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1003857-libvpx-1-7-0-released-with-avx-optimizations-more

This is the AOM/AV1 thread. There's vp9 thread (http://forum.doom9.org/showthread.php?t=165839&goto=newpost) also.

That said, I hope there's some multi-process optimization. CPU utilization is abysmal when encoding VP9.

GTPVHD

30th January 2018, 01:09

http://blog.chiariglione.org/a-crisis-the-causes-and-a-solution/

At long last everybody realises that the old MPEG business model is broke, all the investments (collectively hundreds of millions USD) made by the industry for the new video codec will go up in smoke and AOM’s royalty free model will spread to other business segments as well.

Even the MPEG founder sees the beginning of the end of MPEG's terrible proprietary codecs situation & business model.

birdie

30th January 2018, 12:16

http://blog.chiariglione.org/a-crisis-the-causes-and-a-solution/

Even the MPEG founder sees the beginning of the end of MPEG's terrible proprietary codecs situation & business model.

Thanks for the link.

HEVC is 60% more efficient than AVC? I wonder what he's smoking. In my experience it's more like from 0 to 30% (for very specific use cases like anime).

LigH

30th January 2018, 20:01

In UHD resolutions it's more probable for HEVC to be ahead of AVC.

Mystery Keeper

30th January 2018, 23:15

I've only ever encoded one video with HEVC. A musical video with rather high motion. At the same bitrate HEVC did visibly much better than AVC. Also, took forever to encode.

TD-Linux

31st January 2018, 03:03

MSU's codec comparison is out: http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=122945

It uses a version of libaom from July 2017.

Selur

31st January 2018, 20:31

btw. is there any news regarding when to expect a bit stream freeze? Last I read was January 2018, which now is gone,.. :)

mzso

31st January 2018, 20:39

btw. is there any news regarding when to expect a bit stream freeze? Last I read was January 2018, which now is gone,.. :)

It's not midnight yet everywhere. :P

Rumbah

1st February 2018, 07:25

btw. is there any news regarding when to expect a bit stream freeze? Last I read was January 2018, which now is gone,.. :)

FOSDEM is this weekend so I guess that's when we get some news.

iwod

3rd February 2018, 14:44

3000x slower.

Also we need to stop focusing on PSNR and SSIM. These two should be used to add prospective.

Last time i heard Netflix were going to update VMAF. What happen to that?

IgorC

3rd February 2018, 15:20

3000x slower.

Duh, like reference H.265 encoder (HM) was any faster.

iwod

3rd February 2018, 20:04

Duh, like reference H.265 encoder (HM) was any faster.

It was, if I remember correctly only 50 - 100 times slower. Order of Magnitude less then AV1.

Anthonytex

5th February 2018, 08:33

So, not ready yet:
https://youtu.be/6UksCRCl_bI
"Almost"

bstrobl

5th February 2018, 12:24

Looks like they are cleaning up all the little niggles in the bitstream which is good :) A couple additional weeks for a potentially long lasting codec is fine.

iwod

6th February 2018, 13:59

Looks like they are cleaning up all the little niggles in the bitstream which is good :) A couple additional weeks for a potentially long lasting codec is fine.

How about months? At least Mozilla and Xiph are doing those works and many other member. If it was Google i dont know what mess it will end up with.

iwod

6th February 2018, 16:50

So, not ready yet:
https://youtu.be/6UksCRCl_bI
"Almost"

You just have to watch this video and wonder, even at this what is supposed to be late stage development, there are still LOTs of big changes.

mzso

6th February 2018, 18:44

You just have to watch this video and wonder, even at this what is supposed to be late stage development, there are still LOTs of big changes.

Better than having a format with huge bugs/issues.

bstrobl

7th February 2018, 12:03

How about months? At least Mozilla and Xiph are doing those works and many other member. If it was Google i dont know what mess it will end up with.

I'm afraid this is not going to be the perfect codec we are looking for. Lots of compromises (old tools kept due to hardware vendor demands and VP9 legacy etc.) due to the time frame and a lot of tools simply not being integrated. The AOM is still at a pretty young age right now, but it is better to ship an imperfect but very good codec rather than delaying another few years and miss overtaking HEVC and VP9.

AV2 is going to have far fewer compromises simply because there will be more time (10 years?), especially once the kinks in organisation within AOM have been worked out and at that stage any major gains will have to be gotten from better tools and architecture rather than stuffing more things into it. It may be possible that more radical ideas will be used including some sort of hybrid codec like OPUS (AV1 and Daala hybrid perhaps?).

Compromise is key here. As long as the bitstream is solid and no massive bugs are left it should do well.

Q3CPMA

7th February 2018, 16:52

After seeing the FOSDEM video, I mosty agree with the previous posts: too much and too big changes for an "almost" finished codec and hardware decoding dumbing down the codec. They could have simply made a profile for hardware decoding and one for software to solve all of this. Kind of like AAC.

nevcairiel

7th February 2018, 16:54

They could have simply made a profile for hardware decoding and one for software to solve all of this.

That solves nothing. Any consumer media would never use those features that don't work with hardware, so its wasted effort to even consider them.

mzso

7th February 2018, 17:36

and hardware decoding dumbing down the codec. They could have simply made a profile for hardware decoding and one for software to solve all of this. Kind of like AAC.

Well, we might be better off having a somewhat simpler and conventional format (with substantial improvements) now that can be adopted easily and quickly and then have a revolutionary one years later. A proper new format that throws away all baggage and conventions probably takes several years to produce anyway.

That solves nothing. Any consumer media would never use those features that don't work with hardware, so its wasted effort to even consider them.

That's kind of surprising. I'd expect even from smartphones of the past few years to decode FullHD content on CPU power alone.

nevcairiel

7th February 2018, 19:19

That's kind of surprising. I'd expect even from smartphones of the past few years to decode FullHD content on CPU power alone.

I'm not sure if they could, don't have final decode complexity figures yet, but even if they can it would burn much more battery then using a bitstream that can be hardware decoded, so its far from ideal.

Q3CPMA

7th February 2018, 20:49

That solves nothing. Any consumer media would never use those features that don't work with hardware, so its wasted effort to even consider them.
Yeah, the industry would probably only use the hardware profile. But a codec that's supposed to replace almost all other codecs might be used for archiving too. I'm not even talking about encoding done by individuals where something like h264's high10 got some use.

Djfe

9th February 2018, 10:52

I guess it comes to the point, that the companies involved want working hardware decoders rather sooner than later. So saving time on implementing hardware decoders is a huge deal. the question, I cannot answer, is: how much better could hardware decoders get, if they make them from scratch? (in other words. is it worth the effort?)

One actual question, I have, is, are Xiph/Mozilla still working on Daala? (will Daala ship on it's own one day?)
Not that I want that to happen. One codec is better than several. But it's interesting to know, whether they still consider doing it for some reason :)

About: http://blog.chiariglione.org/a-crisis-the-causes-and-a-solution/
Nice read, thx for sharing it :)
Moving away from profiles to tool-based encoders doesn't seem to be a good option(IMO), since it complicates the encoder/decoder situation a lot more
especially since all tools have to work together somehow.

it's kind of stupid though, that big parts of the industry only saw their own profits instead of the bigger picture.
well, it's their own pile of shards now.
AOM has chances to win.

I wonder what the broadcast industry will choose in 15-30 years. Or the movie making industry, in-case there is a new type of disc format. ^^

About his last paragraph:
Do we actually need a better, new codec after av1 and opus for media?
(at least on the web, the web needed an open codec for several reasons, even if the model of implementing such a codec isn't profitabel at first
this might not keep broadcasters and the media industry and so on from paying royalties for better codecs; they have the perfect business model to do so after all (unlike the web))

Quikee

9th February 2018, 11:06

But a codec that's supposed to replace almost all other codecs might be used for archiving too.

Look at the companies behind AOM and tell me which one of them cares about archiving? I don't even remember it being mentioned as a use case for netvc. And also when did they say that the coded is supposed to "replace almost all other codecs"? I thought that AV1 main focus was clear - internet streaming (including game content) and internet real-time communications.

mzso

9th February 2018, 13:18

Look at the companies behind AOM and tell me which one of them cares about archiving? I don't even remember it being mentioned as a use case for netvc. And also when did they say that the coded is supposed to "replace almost all other codecs"? I thought that AV1 main focus was clear - internet streaming (including game content) and internet real-time communications.

That doesn't mean it can't be used for everything else. Especially since it's free and supposedly superior to all contemporary lossy codecs.
Also, it seems to me that there's a shift towards the internet from discs and such and television broadcasts.

tfouto

12th February 2018, 12:27

Look at the companies behind AOM and tell me which one of them cares about archiving? I don't even remember it being mentioned as a use case for netvc. And also when did they say that the coded is supposed to "replace almost all other codecs"? I thought that AV1 main focus was clear - internet streaming (including game content) and internet real-time communications.

How can it be used for internet real-time communications, when the encoding is really expensive?

Quikee

12th February 2018, 13:44

How can it be used for internet real-time communications, when the encoding is really expensive?

Turning off expensive coding tools, limiting search, optimization, hardware encoders,...

AV1 didn't see much optimizations yet and they AFAIK always do full search for new coding tools, which is similar to having placebo mode all the time on.

LigH

17th February 2018, 20:22

AOM 0.1.0-8039-g01faff973

benwaggoner

19th February 2018, 01:55

Well, we might be better off having a somewhat simpler and conventional format (with substantial improvements) now that can be adopted easily and quickly and then have a revolutionary one years later. A proper new format that throws away all baggage and conventions probably takes several years to produce anyway.

That's kind of surprising. I'd expect even from smartphones of the past few years to decode FullHD content on CPU power alone.
Premium content requires HW DRM which means HW decode. A SW-only codec may get used by hobbyists, but won't be by the content industry.

Tommy Carrot

19th February 2018, 14:13

Barough

19th February 2018, 17:02

AOM AV1 v0.1.0-8127-gc7a5e8830 (http://www.mediafire.com/file/n1a3zl0t43tqbis/)
Built on February 19, 2018, GCC 7.3.0

https://aomedia.googlesource.com/aom

mzso

19th February 2018, 17:39

What's the basic way to pipe video with ffmpeg to aomenc? So far I'm failing miserably.

sneaker_ger

19th February 2018, 17:48

ffmpeg -i "input" -f yuv4mpegpipe - | aomenc --passes=1 -o "output.webm" -

mzso

19th February 2018, 18:25

ffmpeg -i "input" -f yuv4mpegpipe - | aomenc --passes=1 -o "output.webm" -

Result, as before:
[yuv4mpegpipe @ 0000000e84237700] ERROR: yuv4mpeg can only handle yuv444p, yuv422p, yuv420p, yuv411p and gray8 pixel formats. And using 'strict -1' also yuv444p9, yuv422p9, yuv420p9, yuv444p10, yuv422p10, yuv420p10, yuv444p12, yuv422p12, yuv420p12, yuv444p14, yuv422p14, yuv420p14, yuv444p16, yuv422p16, yuv420p16, gray9, gray10, gray12 and gray16 pixel formats. Use -pix_fmt to select one.
Could not write header for output file #0 (incorrect codec parameters ?): I/O error
Error initializing output stream 0:0 --

sneaker_ger

19th February 2018, 18:30

mzso

19th February 2018, 18:36

Like the error message said: Some formats require you to set -strict -1 for y4m output. (But of course aomenc still needs to support the format you choose.)
ffmpeg -i "input" -strict -1 -f yuv4mpegpipe - | aomenc --passes=1 -o "output.webm" -

It doesn't help with the file I'm trying. I'm actually trying with an RGB stream. (screencast)
So RGB can't be piped?

sneaker_ger

19th February 2018, 18:38

I don't see any rgb input option in aomenc (maybe it can be passed as i444?). Use -pix_fmt to convert to a compatible format in ffmpeg.

mzso

19th February 2018, 18:56

I don't see any rgb input option in aomenc (maybe it can be passed as i444?). Use -pix_fmt to convert to a compatible format in ffmpeg.

Okay. Thanks.

(Out of curiosity, what would I need to pass RGB if the encoder supported it? The original command line failed on ffmpeg's side. PS: there's a yuvj pixel format, what does that mean? I know I need to use this when encoding with libx264 to keep it full range.)

sneaker_ger

19th February 2018, 19:01

LigH

19th February 2018, 19:05

mzso

19th February 2018, 19:35

The formats with j mark full range content. RGB cannot be passed as y4m. You would have to pass as raw video (headerless) and specificy resolution, fps, colorspace, bitdepth manually if aomenc would support it (x264 does).

I see. So since yuvj isn't supported I guess I need to use "-scale=out_color_matrix=bt709:out_range=pc", right?

mzso

19th February 2018, 19:49

As the name (YUV for MPEG) already suggests, it was designed for YUV color space (luminance Y + chrominance differences U/V) with different chroma subsampling configurations, additionally also luminance-only (greyscale) formats. Most efficiently compressing modern video formats rely on this color space because it resembles the preference for luminance in the retina of the human eyes (a magnitude more brightness-sensitive rods than color-sensitive cones), a pre-requisite for making use of chroma subsampling to reduce data rate with hardly obvious loss of resolution.

Basic command-line encoders in test and development generation, like aomenc, may not even contain code to convert generally unsupported RGB color space into supported YUV color space on their own, they rely on the video source serving a supported format.

It might have converted to yuv automatically for all I knew.

I'm aware of what YUV is, but it's not your assesment of the retina is wrong, YUV doesn't resemble how the retina works. The retina has RGB cones which ar sensitive to their respective colors (sort of, they have an overlapping sensitivity curve) . And there's no suck thing as separation for brightness sensation, which is nonsensical. The rods are alternative sensors for low light circumstances, which (since there's only one kind) are monochromatic.

However human preception is more sensitive towards luminance that's why having it separate is advantageous. (The UV part has no relevance to human perception, it's just an artificial way to store color)

sneaker_ger

19th February 2018, 20:04

I see. So since yuvj isn't supported I guess I need to use "-scale=out_color_matrix=bt709:out_range=pc", right?
Yes. (If you want BT709 PC range output. Most people would use TV range.)

benwaggoner

19th February 2018, 22:50

Thanks for the new build. I thought after so many SIMD optimization, the encoding speed would've got a bit more tolerable, but on the default settings it's still slow as hell. With cpu-used=2 i could at least test it on some very short videos. The quality is decent, but i don't think it has improved much in the last few months.
Encoder optimization is a HUGE project, especially with the current generation of complex codecs. It's not just SIMD, but early exits, heuristics, frame-level parallelism. And there are SO MANY functions requiring assembly optimization. Just take a look at the x265 source code for a roughly equivalent example.

The VPx series has always had speed issues, particularly in multicore environments; most VPx encoding was done with split-and-stitch across multiple hosts, which isn't typical for premium content at feature length. A true production-efficient encoder might require a different basic architecture than what the reference encoder uses. Which is why we have bitstream specs, so people can build their own interoperable encoders and decoders.

But I'd expect it'd take a couple of years before we have AV1 encoders that would match performance @ quality of today's best HEVC encoders.

And that's not even getting into rate control and psychovisual optimization, which can also take several years to get to a reasonable baseline, and keep on getting refined for the usage life of the codec. We are still seeing significant improvements in MPEG-2 encoders 20+ years in.

mzso

20th February 2018, 00:10

But I'd expect it'd take a couple of years before we have AV1 encoders that would match performance @ quality of today's best HEVC encoders.

And that's not even getting into rate control and psychovisual optimization, which can also take several years to get to a reasonable baseline, and keep on getting refined for the usage life of the codec. We are still seeing significant improvements in MPEG-2 encoders 20+ years in.

I hope not. These many large corporations should have lots of bodies to throw at optimizing, improving the encoder.

benwaggoner

20th February 2018, 00:21

I hope not. These many large corporations should have lots of bodies to throw at optimizing, improving the encoder.

That was true of HEVC, H.264, and MPEG-2. It always takes a couple of years from an essentially complete bitstream design to commercial grade encoders.

Sent from my iPhone using Tapatalk

bstrobl

20th February 2018, 19:26

That was true of HEVC, H.264, and MPEG-2. It always takes a couple of years from an essentially complete bitstream design to commercial grade encoders.

Sent from my iPhone using Tapatalk

It gets worse once you factor the insane amount of coding tools that can be used in a myriad of combinations. Simply getting all of the heuristics to figure that out is insane work.

I do expect the default encoder and decoder to be pretty decent with good support however. OPUS is doing a decent job with its default tools.

benwaggoner

20th February 2018, 19:58

It gets worse once you factor the insane amount of coding tools that can be used in a myriad of combinations. Simply getting all of the heuristics to figure that out is insane work.
Yeah, exactly my point. The efficiency gains of new codecs largely comes from the variety of new tools available, so getting the quality gains requires

I do expect the default encoder and decoder to be pretty decent with good support however. OPUS is doing a decent job with its default tools.
Decoders are way easier than encoders, thankfully. They work, or they don’t. And unlike VP9, we actually have some Profile/Level specs so we know what a particular decoder is required to do and thus what our encoders can be allowed to do.

I’m not sure how you’d define “pretty decent” - I would think it wouldn’t before end of year that AV1 has solutions that clearly outperform even x264 for high-volume scenarios. But yeah, desktop file-to-file conversion will work, and will produce good looking video. Speed is far from practical yet, but getting it to the ballpark of x265 speed at x264 quality is a reasonable 2018 goal.

Also, Opus is an audio codec: only one dimension! Audio codec optimization is important, but we’re talking 1-2 orders of magnitude less effort to get to a production-grade encoder than with a video codec. And we actually have good audio quality perceptually correlated metrics, which makes automated tuning and testing much more feasible and useful.

mzso

20th February 2018, 20:19

benwaggoner

20th February 2018, 20:21

It seems like to me that HEVC and AVC mostly had patent trolls. Who were only interested in filling their pockets.

DEFINITELY not mostly. Companies that really wanted to contribute to it so they could use the technology most joined the reasonable MPEG-LA pool.

Sent from my iPhone using Tapatalk

IgorC

20th February 2018, 23:30

And we actually have good audio quality perceptually correlated metrics, which makes automated tuning and testing much more feasible and useful.
Audio metrics are no better than any video metrics.
Both have flaws.

Final quality verification tests of absolutely every meaningful audio standard were made by testing ... on humans.

Clare

23rd February 2018, 23:43

Experimental AV1 encoder in Rust: https://github.com/xiph/rav1e

I'll be adding new data to my comparator with a AV1 snapshot from 20180222, next week or so. I've changed the encoder parameters for more speed so I need to recalculate the old snapshots to have comparable data.

Also I added the PIK image format.

I also plan to do an actual video comparaison based on 30 short clips, VMAF metrics, AV1, X264, X265, and VP9. Gonna take a long while as I haven't written a single line of code yet and the encoding itself will be long.

Maybe AV1 will be bitstream freezed then. Latest estimate are: "AOM: Bitstream maybe March, maybe announce at NAB (early April)"
(https://www.nabshow.com/ from April 7th to April 12th)

hajj_3

24th February 2018, 00:33

I also plan to do an actual video comparaison based on 30 short clips, VMAF metrics, AV1, X264, X265, and VP9.

I hope you do comparisons at many resolutions e.g: 360p, 480p, 576p, 720p, 1080p, 1440p, uhd. A lot of the benchmarks shown so far comparing av1 to x264, x265 and vp9 either just show the overall difference or they show 360p, 720p and 1080p. I am more interested in the improvement of 360p-720p as x265 doesn't have that much improvement over x264 at those resolutions.

Clare

24th February 2018, 01:36

I hope you do comparisons at many resolutions e.g: 360p, 480p, 576p, 720p, 1080p, 1440p, uhd. A lot of the benchmarks shown so far comparing av1 to x264, x265 and vp9 either just show the overall difference or they show 360p, 720p and 1080p. I am more interested in the improvement of 360p-720p as x265 doesn't have that much improvement over x264 at those resolutions.

I plan to use objective1-fast https://people.xiph.org/~tdaede/sets/objective-1-fast/
It's a mix of 360p, 720p and 1080p. I don't have any 1440p or UHD content and I doubt my computer would be able to process it in a reasonable time. But I plan to release the Python scripts I use on Github so it will be usable on any dataset, like I did for images (https://github.com/WyohKnott/image-comparison-sources).

Or I need to buy a Threadripper… when I have lots of money and no taxes to pay.

Clare

24th February 2018, 01:40

objective2-slow https://people.xiph.org/~tdaede/sets/objective-2-slow/ has UHD content. Might be useful.

LigH

24th February 2018, 20:05

New upload: AOM v0.1.0-8231-gcb4622dee

Tommy Carrot

24th February 2018, 23:01

I'll be adding new data to my comparator with a AV1 snapshot from 20180222, next week or so. I've changed the encoder parameters for more speed so I need to recalculate the old snapshots to have comparable data.

Also I added the PIK image format.

Thanks for the comparisons.

The new AV1 blurs even more than the older ones. I know it's primarily a video encoder, so it's not really tuned for still images, but in its current form it's not really doing a good job as an image encoder.

However, PIK is really interesting. It basically behaves like a much more efficient JPEG. It has blocking and ringing artifacts, but preserves much more details than the other encoders. I sure prefer it over the artifactless, but sterile looking and blurry AV1 or HEVC images.

Clare

26th February 2018, 02:11

Thanks for the comparisons.

The new AV1 blurs even more than the older ones. I know it's primarily a video encoder, so it's not really tuned for still images, but in its current form it's not really doing a good job as an image encoder.

However, PIK is really interesting. It basically behaves like a much more efficient JPEG. It has blocking and ringing artifacts, but preserves much more details than the other encoders. I sure prefer it over the artifactless, but sterile looking and blurry AV1 or HEVC images.

I've just stumble onto that on Github: https://aomediacodec.github.io/av1-avif/

AV1 Still Image File Format (AVIF)

Overview

AVIF is a file format wrapping compressed images based on the Alliance for Open Media AV1 intra-frame encoding toolkit. AVIF supports High Dynamic Range (HDR) and wide color gamut (WCG) images as well as standard dynamic range (SDR). Only the intra-frame encoding toolkit is used in AVIF version 1.0. Using the intra-frame encoding mechanism from an existing video codec standard has a precedent in WebP: VP8, and HEIF: HEVC. This document describes at a high level a proposal on the structure of AVIF version 1.0.

The initial version of AVIF seeks to be simple, with just enough structure to allow the distribution of images based on the AV1 intra-frame coding toolset. At its core, AVIF 1.0 will allow for one or more images plus all supporting data needed to correctly reconstruct and display the images to be conveyed in a file. The ability to embed a thumbnail image will also be provided. An image sequence with suggested playback timing may be defined.

bstrobl

26th February 2018, 11:43

I've just stumble onto that on Github: https://aomediacodec.github.io/av1-avif/

The part where it says:

An AVIF file should be a simplified and conformant version of an [HEIF] file.

would imply this is basically HEIF with AV1 as still image codec, which is a sensible choice.

Not a big fan of the ringing artefacts in PIK, those bother me quite a lot more.

mzso

26th February 2018, 13:19

TD-Linux

28th February 2018, 02:28

The new AV1 blurs even more than the older ones. I know it's primarily a video encoder, so it's not really tuned for still images, but in its current form it's not really doing a good job as an image encoder.

If you want to experiment, you can build an encoder with -DCONFIG_DIST_8X8=1 and then specify --tune=cdef-dist or --tune=daala-dist. These will optimize away from blurring and towards ringing.

bstrobl

4th March 2018, 12:09

hajj_3

4th March 2018, 15:11

Here is the buglist for the bitstream:

https://bugs.chromium.org/p/aomedia/issues/list?can=2&q=Hotlist%3DAV1-Normative&colspec=ID+Type+Status+Priority+Milestone+Owner+Summary&cells=ids

Presumably once all of those have been fixed the bitstream can be frozen.

Looks like everyone is working on weekends to get this thing done.
not sure, I have been following this list: https://bugs.chromium.org/p/aomedia/issues/list?can=2&q=&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary&sort=priority&num=100&start=0

It is down to 75 bugs, 2.5 weeks ago it was at 215 bugs so probably another 1-2 weeks or so until it is ratified.

Clare

4th March 2018, 18:40

I also plan to do an actual video comparaison based on 30 short clips, VMAF metrics, AV1, X264, X265, and VP9. Gonna take a long while as I haven't written a single line of code yet and the encoding itself will be long

I plan to use objective1-fast https://people.xiph.org/~tdaede/sets/objective-1-fast/
It's a mix of 360p, 720p and 1080p. I don't have any 1440p or UHD content and I doubt my computer would be able to process it in a reasonable time. But I plan to release the Python scripts I use on Github so it will be usable on any dataset, like I did for images (https://github.com/WyohKnott/image-comparison-sources).

So it was easier to code than I thought, with few changes from the image comparison.

It's up there: https://wyohknott.github.io/video-formats-comparison/

I haven't added AV1 yet, I'm waiting for the bitstream freeze.

Let me know what you think would be good to add. I put most of the graph I thouqgt would be useful. I wish I could addsome examples videos to plày side by side but I don't know how to do that.

Jamaika

4th March 2018, 19:47

Each Y4M videos is exported to 4:2:0 10 bits Y4M with FFMPEG:

ffmpeg -y -i [input] -pix_fmt yuv420p10le -strict -1 [output]
Video compression
All videos are compressed over a range of qualities for each encoder:
•AV1:
◦between q=12 and q=60, with a step of 4:

aomenc --cpu-used=2 --tile-columns=4 --passes=2 --pass=1 --bit-depth=10 --input-bit-depth=10 --end-usage=q --cq-level=$q --fpf=[output].log -o [output] [input(Y4M_10bits)]

aomenc --cpu-used=2 --tile-columns=4 --passes=2 --pass=2 --bit-depth=10 --input-bit-depth=10 --end-usage=q --cq-level=$q --fpf=[output].log -o [output] [input(Y4M_10bits)]

•VP9:
◦between q=12 and q=60, with a step of 4:

vpxenc --tile-columns=4 --row-mt=1 --passes=2 --cpu-used=2 --bit-depth=10 --input-bit-depth=10 --profile=2 --end-usage=q --cq-level=$ -o [output] [input(Y4M_10bits)]

•x264:
◦between q=12 and q=40, with a step of 2:

x264 --profile high10 --preset slower --input-depth=10 --output-depth=10 --crf $q -o [output] [input(Y4M_10bits)]

•x265:
◦between q=12 and q=40, with a step of 2:

x265 --profile main10 --preset slower --input-depth=10 --output-depth=10 --crf $q -o [output] [input(Y4M_10bits)]
My ideas:
ffmpeg.exe -loglevel verbose -i "[input(your_colorspace).raw]" -an -f yuv4mpegpipe -vf scale=1920:1080:in_color_matrix=rgb:in_range=full:out_color_matrix=bt2020_ncl:out_range=full,format=yuv422p10le -strict -1 -
ffmpeg.exe -loglevel verbose -i "[input(your_colorspace).y4m]" -an -f yuv4mpegpipe -vf scale=1920:1080:in_color_matrix=S_gamut3:in_range=full:out_color_matrix=bt2020_ncl:out_range=full,format=yuv422p10le,lutyuv=val:val:val -strict -1 -
aomenc.exe --bit-depth=10 --input-bit-depth=10 --i4?? --codec=av1 --good --threads=? --cpu-used=? --profile=3 --drop-frame=(0 or 100 depends on fps) --end-usage=q --cq-level=48 --target-bitrate=0 --min-q=?(the problem bitrate of the first frame)
--kf-max-dist=GOP --auto-alt-ref=? --frame-boost=? --aq-mode=0 --color-space=bt2020 --verbose --debug --pass=? --passes=? --output="xxx.webm" - (where is range full?)

x264.exe --demuxer y4m --input-csp i4?? --input-depth 10 --input-range pc --output-csp i4?? --threads ? --preset slow --tune grain --crf 28 --fps ??.??? --keyint 60 --nal-hrd none --vbv-bufsize 40000 --vbv-maxrate 40000(use for web or don't use)
--colormatrix bt2020nc --colorprim bt2020 --transfer bt2020-10 --range pc --output "xxx.h264" -

o-l-a-v

5th March 2018, 08:07

It's up there: https://wyohknott.github.io/video-formats-comparison/
You are linking to PIKs github page for x265.

"x265: https://github.com/google/pik. The version used is built from GIT revision 3cf3839f82bb177c43449ab10792c184c4485d8b"

Tommy Carrot

5th March 2018, 13:26

So it was easier to code than I thought, with few changes from the image comparison.

It's up there: https://wyohknott.github.io/video-formats-comparison/

I haven't added AV1 yet, I'm waiting for the bitstream freeze.

Let me know what you think would be good to add. I put most of the graph I thouqgt would be useful. I wish I could addsome examples videos to plày side by side but I don't know how to do that.
Nice.

I think XVC encoder could be interesting to see. I know it's a proprietary codec, but quality-wise, in my experience, it competes quite well with x265 and AV1.

clsid

5th March 2018, 17:07

Does anyone have a link to a sample file that was encoded by a recent build?

LigH

5th March 2018, 23:33

Just for you :o ... I created a "samples" subdirectory in my AOM (https://www.mediafire.com/?21254ingvippg) MediaFire folder; it contains a WebM clip of "foreman" in PAL CIF resolution (https://www.mediafire.com/file/byqa843j4im70s4/foreman_cif_AV1_0.1.0-8300-g088217b2e.webm), encoded with AOM encoder v0.1.0-8300-g088217b2e (http://www.mediafire.com/file/3b7n762y852rxvh/aom_v0.1.0-8300-g088217b2e.7z) (built Feb. 27, I hope that's recent enough) with '--cpu-used 8' (supposed to be a faster preset). Encoding took 3/4 hour on this aged PC with AMD Phenom-II (max. SSE2).

Tomorrow I could try a newer one with faster hardware.

LigH

6th March 2018, 16:13

A few more uploads: AOM v0.1.0-8449-g6471e8bd7 and samples with "--cpu-used [8..4]" to compare speeds (encoded on an AMD FX-6300). Disillusioning... :(

Pass 2/2 frame 300/300 469809B 12528b/f 313206b/s 769973 ms (0.39 fps)
Pass 2/2 frame 300/300 460022B 12267b/f 306681b/s 841144 ms (0.36 fps)
Pass 2/2 frame 300/300 449454B 11985b/f 299636b/s 921242 ms (0.33 fps)
Pass 2/2 frame 300/300 448798B 11967b/f 299198b/s 1044732 ms (0.29 fps)
Pass 2/2 frame 300/300 448035B 11947b/f 298690b/s 1214326 ms (0.25 fps)

Reminding you, PAL CIF resolution (352×288). Due to the small video, only 1 thread was active.

hbbs

6th March 2018, 18:30

Sorry, I am fairly new to this.

But which player are you using to play this samples?

I have tried the latest vlc stable to no avail.

Couldn't play the codec "av01" (AOMedia's AV1 Video)

clsid

6th March 2018, 22:06

Thanks LigH.

The AV1 format has not been finalized yet. Once that is done, you can expect players to quickly adopt it.

LigH

6th March 2018, 22:06

There is probably no player available yet. You can only use aomdec to decode to Y4M and play this decoded raw video, AFAIK.

Tommy Carrot

6th March 2018, 23:03

Thanks for the new build.

Despite all the SIMD optimizations and other improvements, this build is actually even slower than build #8039. The quality seems visually very similar, the metrics as well. I was curious what AV1 is capable of with all the compression tools enabled, so i tried --cpu-used=0 on a 50 frames long, 720*288 video. It took almost 6 hours to encode. :)

clsid

6th March 2018, 23:45

I have a patch for MPC-HC/LAV/FFmpeg but it is not fully working yet. Libaom outputs YUV420P for your sample video, but using a 16 bit framebuffer, which is normally only used for higher bitdepths.

nevcairiel

7th March 2018, 00:27

Work on support for libaom in FFmpeg is already underway, but it won't really be made available until the bitstream freeze.

easyfab

7th March 2018, 08:29

Firefox and chrome should also have the decoder in quickly After final bitstream

Dope

7th March 2018, 12:56

50 frames long, 720*288 video. It took almost 6 hours to encode.

Bloody hell.. Can someone make a realistic prediction as to how long it will take an optimized AV1 to encode exactly that sequence?
Thank you.

2160p

7th March 2018, 13:27

Bloody hell.. Can someone make a realistic prediction as to how long it will take an optimized AV1 to encode exactly that sequence?
Thank you.

What is the multi-core CPU distribution/load?

dapperdan

7th March 2018, 13:32

I think they were aiming for it to take longer than HEVC/VP9 but I'm not sure they let themselves get pinned down to anything more specific than "reasonable increases" in encoding time. I think Netflix said they'd roll it out internally once it was less than 5x HEVC encoding time, so I guess that's an upper bound.

Dope

7th March 2018, 20:25

What is the multi-core CPU distribution/load?

I'm running an i5 3570K@ 4500Mhz. I run all of my 1080p x265 encodes at no less than 1 FPS. This is with my lil bit customized "placebo" preset.
I just can't comprehend how a processor like this would encode some 50 360p frames even during 1 hour, let alone 6. This is insane.

LigH

7th March 2018, 23:24

MoSal

8th March 2018, 03:24

There is a little cosmetical issue I reported (https://bugs.chromium.org/p/aomedia/issues/detail?id=1517) (aomenc displays ANSI escape sequences for cursor control, vpxenc does not).

:o I have never seen developers so speechless... :rolleyes:

lol. Wait until they discover there is no byte sequence they can use to get this functionality in Windows cmd.

clsid

9th March 2018, 03:20

A sneak peek of the future...

http://i68.tinypic.com/15eeb5s.png

Before anyone asks, this isn't available until the bitstream specification is finalized.

bstrobl

9th March 2018, 12:24

not sure, I have been following this list: https://bugs.chromium.org/p/aomedia/issues/list?can=2&q=&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary&sort=priority&num=100&start=0

It is down to 75 bugs, 2.5 weeks ago it was at 215 bugs so probably another 1-2 weeks or so until it is ratified.

That list contains all bugs for all parts including those not affecting the bitstream(stuff in the encoder/decoder themselves).

If you search in Monorail for "Hotlist=AV1-Normative", only bitstream bugs will be shown.

The codec is a bit rushed, hopefully no major or even minor bugs are left. Might have to use it for a very long time if it catches on and no major progress in codecs is being made :scared:

bstrobl

9th March 2018, 12:26

A sneak peek of the future...

http://i68.tinypic.com/15eeb5s.png

Before anyone asks, this isn't available until the bitstream specification is finalized.

320 x 240 ought to be enough for everyone :D. Although I am curious about low resolution performance. Countries with poor internet could massively benefit from receiving even tiny videos.

mzso

9th March 2018, 13:11

The codec is a bit rushed, hopefully no major or even minor bugs are left. Might have to use it for a very long time if it catches on and no major progress in codecs is being made :scared:

Let's hope they go down the deep end with novel and exotic ideas.

bstrobl

9th March 2018, 14:23

Let's hope they go down the deep end with novel and exotic ideas.

My guess is they will have to do that. Only so many gains can be made by increasing block sizes and motion direction etc. The next codec will probably be 10 years down the line so that should give enough time to rip out the old plumbing or simply start from scratch for a more radical new architecture. The Alliance will hopefully stay together for that period of time. A 50% efficiency gain on top of AV1 would be pretty nice, which would mean going from e.g. 800MB (MPEG2) -> 400MB (H264) -> 200MB (AV1) -> 100MB (AV2?) file sizes :)

LigH

9th March 2018, 14:52

@bstrobl:

PAL CIF = 352×288 (a common "Video CD" resolution). And ... I really don't understand how people still get so excited about miracolous bitrate reductions from one generation to the next, but for low resolution video; and even the subjective threshold how much loss of quality appears tolerable changed over the last decade (I doubt you would accept today what was acceptable in the VCD era, today you would complain about "retina cancer" with the same amount of artifacts).

Don't be afraid of available bandwidth. "Countries with poor internet" ... did you know that Estonia has better rural broadband coverage than Germany? UHD over the Web will be the future, globally – because its availability makes profit. Forget about CIF.

Selur

16th March 2018, 09:31

@all: Is there some documentation about the command line parametes of aomenc somewhere?
Looking at the output of 'aomenc --help' there a quite a few option without explanations about min/max values of the arguments or what the default argument is.
Usage: aomenc.exe <options> -o dst_filename src_filename

Options:
--help Show usage options and exit
-c <arg>, --cfg=<arg> Config file to use
-D, --debug Debug mode (makes output deterministic)
-o <arg>, --output=<arg> Output filename
--codec=<arg> Codec to use
-p <arg>, --passes=<arg> Number of passes (1/2)
--pass=<arg> Pass to execute (1/2)
--fpf=<arg> First pass statistics file name
--limit=<arg> Stop encoding after n input frames
--skip=<arg> Skip the first n input frames
--good Use Good Quality Deadline
-q, --quiet Do not print encode progress
-v, --verbose Show encoder parameters
--psnr Show PSNR in status line
--webm Output WebM (default when WebM IO is enabled)
--ivf Output IVF
--obu Output OBU
-P, --output-partitions Makes encoder output partitions. Requires IVF output!
--q-hist=<arg> Show quantizer histogram (n-buckets)
--rate-hist=<arg> Show rate histogram (n-buckets)
--disable-warnings Disable warnings about potentially incorrect encode settings.
-y, --disable-warning-prompt Display warnings, but do not prompt user to continue.
--test-decode=<arg> Test encode/decode mismatch
off, fatal, warn

Encoder Global Options:
--yv12 Input file is YV12
--i420 Input file is I420 (default)
--i422 Input file is I422
--i444 Input file is I444
--i440 Input file is I440
-u <arg>, --usage=<arg> Usage profile number to use
-t <arg>, --threads=<arg> Max number of threads to use
--profile=<arg> Bitstream profile number to use
-w <arg>, --width=<arg> Frame width
-h <arg>, --height=<arg> Frame height
--forced_max_frame_width Maximum frame width value to force
--forced_max_frame_height Maximum frame height value to force
--stereo-mode=<arg> Stereo 3D video format
mono, left-right, bottom-top, top-bottom, right-left
--timebase=<arg> Output timestamp precision (fractional seconds)
--fps=<arg> Stream frame rate (rate/scale)
--error-resilient=<arg> Enable error resiliency features
-b <arg>, --bit-depth=<arg> Bit depth for codec (8 for version <=1, 10 or 12 for version 2)
8, 10, 12
--lag-in-frames=<arg> Max number of frames to lag
--large-scale-tile=<arg> Large scale tile coding (0: off (default), 1: on)
--monochrome Monochrome video (no chroma planes)

Rate Control Options:
--drop-frame=<arg> Temporal resampling threshold (buf %)
--resize-mode=<arg> Frame resize mode
--resize-denominator=<arg> Frame resize denominator
--resize-kf-denominator=<ar Frame resize keyframe denominator
--superres-mode=<arg> Frame super-resolution mode
--superres-denominator=<arg Frame super-resolution denominator
--superres-kf-denominator=< Frame super-resolution keyframe denominator
--superres-qthresh=<arg> Frame super-resolution qindex threshold
--superres-kf-qthresh=<arg> Frame super-resolution keyframe qindex threshold
--end-usage=<arg> Rate control mode
vbr, cbr, cq, q
--target-bitrate=<arg> Bitrate (kbps)
--min-q=<arg> Minimum (best) quantizer
--max-q=<arg> Maximum (worst) quantizer
--undershoot-pct=<arg> Datarate undershoot (min) target (%)
--overshoot-pct=<arg> Datarate overshoot (max) target (%)
--buf-sz=<arg> Client buffer size (ms)
--buf-initial-sz=<arg> Client initial buffer size (ms)
--buf-optimal-sz=<arg> Client optimal buffer size (ms)

Twopass Rate Control Options:
--bias-pct=<arg> CBR/VBR bias (0=CBR, 100=VBR)
--minsection-pct=<arg> GOP min bitrate (% of target)
--maxsection-pct=<arg> GOP max bitrate (% of target)

Keyframe Placement Options:
--kf-min-dist=<arg> Minimum keyframe interval (frames)
--kf-max-dist=<arg> Maximum keyframe interval (frames)
--disable-kf Disable keyframe placement

AV1 Specific Options:
--cpu-used=<arg> CPU Used (0..8)
--dev-sf=<arg> Dev Speed (0..255)
--auto-alt-ref=<arg> Enable automatic alt reference frames
--sharpness=<arg> Loop filter sharpness (0..7)
--static-thresh=<arg> Motion detection threshold
--single-tile-decoding=<arg Single tile decoding (0: off (default), 1: on)
--tile-columns=<arg> Number of tile columns to use, log2
--tile-rows=<arg> Number of tile rows to use, log2 (set to 0 while threads > 1)
--tile-loopfilter-v=<arg> Enable loop filter across vertical tile boundary
--tile-loopfilter-h=<arg> Enable loop filter across horizontal tile boundary
--arnr-maxframes=<arg> AltRef max frames (0..15)
--arnr-strength=<arg> AltRef filter strength (0..6)
--tune=<arg> Distortion metric tuned with
psnr, ssim, cdef-dist, daala-dist
--cq-level=<arg> Constant/Constrained Quality level
--max-intra-rate=<arg> Max I-frame bitrate (pct)
--max-inter-rate=<arg> Max P-frame bitrate (pct)
--gf-cbr-boost=<arg> Boost for Golden Frame in CBR mode (pct)
--lossless=<arg> Lossless mode (0: false (default), 1: true)
--enable-cdef=<arg> Enable the constrained directional enhancement filter (0: false, 1: true (default))
--enable-restoration=<arg> Enable the loop restoration filter (0: false, 1: true (default))
--enable-qm=<arg> Enable quantisation matrices (0: false (default), 1: true)
--qm-min=<arg> Min quant matrix flatness (0..15), default is 8
--qm-max=<arg> Max quant matrix flatness (0..15), default is 15
--enable-dist-8x8=<arg> Enable dist-8x8 (0: false (default), 1: true)
--frame-parallel=<arg> Enable frame parallel decodability features (0: false (default), 1: true)
--aq-mode=<arg> Adaptive quantization mode (0: off (default), 1: variance 2: complexity, 3: cyclic refresh)
--deltaq-mode=<arg> Delta qindex mode (0: off (default), 1: deltaq 2: deltaq + deltalf)
--frame-boost=<arg> Enable frame periodic boost (0: off (default), 1: on)
--noise-sensitivity=<arg> Noise sensitivity (frames to blur)
--tune-content=<arg> Tune content type
default, screen
--cdf-update-mode=<arg> CDF update mode for entropy coding (0: no CDF update; 1: update CDF on all frames(default); 2: selectively update CDF on some frames
--color-primaries=<arg> Color primaries (CICP) of input content:
bt709, unspecified, bt601, bt470m, bt470bg, smpte240, film, bt2020, xyz, smpte431, smpte432, ebu3213
--transfer-characteristics= Transfer characteristics (CICP) of input content:
unspecified, bt709, bt470m, bt470bg, bt601, smpte240, lin, log100, log100sq10, iec61966, bt1361, srgb, bt2020-10bit, bt2020-12bit, smpte2084, hlg, smpte428
--matrix-coefficients=<arg> Matrix coefficients (CICP) of input content:
identity, bt709, unspecified, fcc73, bt470bg, bt601, smpte240, ycgco, bt2020ncl, bt2020cl, smpte2085, chromncl, chromcl, ictcp
--chroma-sample-position=<a The chroma sample position when chroma 4:2:0 is signaled:
unknown, vertical, colocated
--min-gf-interval=<arg> min gf/arf frame interval (default 0, indicating in-built behavior)
--max-gf-interval=<arg> max gf/arf frame interval (default 0, indicating in-built behavior)
--sb-size=<arg> Superblock size to use
dynamic, 64, 128
--num-tile-groups=<arg> Maximum number of tile groups, default is 1
--mtu-size=<arg> MTU size for a tile group, default is 0 (no MTU targeting), overrides maximum number of tile groups
--timing-info=<arg> Signal timing info in the bitstream:
unspecified, constant
--disable-tempmv=<arg> Disable temporal mv prediction (default is 0)
-b <arg>, --bit-depth=<arg> Bit depth for codec (8 for version <=1, 10 or 12 for version 2)
8, 10, 12
--input-bit-depth=<arg> Bit depth of input

Stream timebase (--timebase):
The desired precision of timestamps in the output, expressed
in fractional seconds. Default is 1/1000.

Included encoders:

av1 - AOMedia Project AV1 Encoder 0.1.0-8663-gaf35e318e (default)

Use --codec to switch to a non-default encoder.

So I'm wondering is there some documentation somewhere what all those parameters are for and what their values are?
Or is this simply still to early to expect a bit more detailed documentation?
Seeing that a few folks did some tests here I wonder how they chose the settings they used. (some parameters are kept from vpx, but quite a few are new)

Cu Selur

LigH

16th March 2018, 20:22

AOM v0.1.0-8698-gba7b8fe27

colinhunt

16th March 2018, 22:14

Thank you LigH for providing binaries. I did a little test yesterday, and noticed that it would take 4 hours to encode 1 second of 1080p60 footage. Am I guessing correctly there's no multithreading in the encoder yet? I noticed the -t parameter for number of threads, but setting it to 8-12 had no effect; aomenc kept running on a single core.

LigH

16th March 2018, 22:19

I only tested it with a tiny resolution so far, and blamed the low resolution for the lack of threading. If it doesn't use threading for larger resolutions either ... then it's not yet implemented, I guess. :o

colinhunt

16th March 2018, 22:38

^ Okay... might it be possible that -t parameter is referring to something else besides multithreading? Just trying to figure out if I messed something up.

LigH

16th March 2018, 23:29

No, I could only agree: I would expect multi-threaded processing of frames, possibly in a slices or wavefront partition technology. (AFAIR, AV1 still uses small macroblock-like windows, just more overlapping to neighborhoods...)

foxyshadis

17th March 2018, 03:41

I don't think anyone but the developers know what half the options mean or do, though some expected values are in the code. You might try --cpu-used=8, which is supposed to max out the processing power.

Actually don't bother, that argument does nothing, they nerfed it without removing the option. Hm. Maybe pthreads isn't detected correctly? OK, tracing the code, you have to have more than one tile-column to get more than one thread; threading is tile-based only. You'd think default would equal threads, but...?

Tommy Carrot

17th March 2018, 06:01

--cpu-used is actually the speed/quality slider, it has nothing to do with threading, they just named it stupidly. The lower it is, the more additional tools and searches are enabled, so 0 is the highest quality, but ridiculously slow, and 8 is the "fastest", but lowest quality.

colinhunt

17th March 2018, 12:58

This cmdline

ffmpeg -i moto--x264-8bit-420-1080p2400fps-468frames.mp4 -strict -1 -f yuv4mpegpipe - | aomenc -w 1920 -h 1080 -v --fps=24000/1000 --cpu-used=8 --dev-sf=255 --tile-columns=6 --limit=48 --i420 -t 24 -b 8 --input-bit-depth=8 --end-usage=cbr --target-bitrate=1024 -p 1 --webm --num-tile-groups=32 -o aomout.webm -

resulted in aomenc running 15 threads and cpu load bouncing around between 4 and 20 percent. Encoding 48 frames took approx. 10 minutes.

LigH

17th March 2018, 14:54

IMHO, aomenc (and vpxenc the same way) will need a lot of simplification regarding sane defaults and relations between parameters to become user friendly... balancing the presets (and "everything default" equals to the "medium" preset) for x264 and x265 took quite an important part of their development efforts.

colinhunt

17th March 2018, 17:05

Source: 1080p24 8bit 4:2:0 468 frames (19.5 seconds)

cmdline: ffmpeg -i moto--x264-8bit-420-1080p2400fps-468frames.mp4 -strict -1 -f yuv4mpegpipe - | aomenc -w 1920 -h 1080 -v --fps=24000/1000 --cpu-used=4 --tile-columns=6 --i420 -t 14 -b 8 --input-bit-depth=8 --end-usage=vbr --target-bitrate=1024 -p 1 --webm -o aomout.webm -

Encoding took 74 minutes, running on 14 threads. Output has a reported (mediainfo) bitrate of 1047 kbps. Oddly enough framerate is reported as 24.025 fps.

LigH

17th March 2018, 17:37

Maybe aomenc doesn't count the duration of the very last frame, only the gaps between all of them.

colinhunt

17th March 2018, 17:44

Maybe aomenc doesn't count the duration of the very last frame, only the gaps between all of them.
You mean that framerate? That number is from Mediainfo.

LigH

17th March 2018, 17:50

Hmm, yes, it looks a bit like "duration / (framecount-1)". So, maybe the opposite way, aomenc counted the duration of the last frame, MediaInfo instead assumes it does not count.

colinhunt

17th March 2018, 22:54

I encoded the same 1080p24 8bit 4:2:0 source on aomenc 0.1.0-8449-g6471e8bd7 twice, first with --cpu-used=4 and then with --cpu-used=2. Target bitrate was set for 1024 kbps. Below are the 3SSIM Metric graphs for both encodes.

https://saitti.kuvat.fi/kuvat/VQMetrics/3SSIM-av1cpu2-av1cpu4.png/_medium.jpg

--cpu-used=4 (green) took 4440 seconds to encode, while --cpu-used=2 (red) took 9060 seconds.

bstrobl

20th March 2018, 17:32

IETF 101: https://www.youtube.com/watch?v=qS7hfrFWeic

Spec is somewhat "frozen", so only bugfixes left.

iwod

20th March 2018, 19:15

IETF 101: https://www.youtube.com/watch?v=qS7hfrFWeic

Spec is somewhat "frozen", so only bugfixes left.

And for anyone that has not been following it, it has been somewhat "Frozen" for nearly 6 months.

As said in the video, there are still crap loads of things going on under the hood. That is not necessarily a bad thing, they are taking the time to properly finish it.

But I have slightly less confident given how they have handle it, I hope they release a preview or beta to the industry before going final.

nevcairiel

20th March 2018, 19:20

But I have slightly less confident given how they have handle it, I hope they release a preview or beta to the industry before going final.

The part of the industry that cares is involved in the development already, so whats left?

bstrobl

20th March 2018, 19:21

The interesting part about the xvc presentation is that this is basically the current state of JVET/JEM, along with its current bitrate performance that ISO/ITU and co. have managed to achieve.

Obviously there is no way in hell Divideon is getting away with basically a direct rip of JVET, so if xvc gains any commercial ground whatsoever it will simply get sued into oblivion or into updating and making a poor codec. Might as well use VP9/AV1 in that case, especially if no old files become incompatible. The best they can hope for is to basically become a replacement for MPEG LA, but I don't see any lists where they have gained any companies as licensors.

hajj_3

20th March 2018, 21:27

leonccyiu

23rd March 2018, 13:13

hajj_3

23rd March 2018, 15:35

https://www.golem.de/news/videocodec-av1-ist-eingefroren-und-30-prozent-besser-als-vp9-1803-133457.html

According to this German article, the bitstream has been frozen with just a few bugs to work out.

I hope that hardware decoders can come a lot sooner than we expect, and that nvidia and arm have already been working on them.

The article just talks about the conference video that was posted a few days ago. I am more bothered about intel and amd apus getting AV1 hardware decoders quickly than nvidia gpus.

easyfab

24th March 2018, 11:52

some tests with foreman clip @250kbit/s on my i7-2600k:

x264 - core 155 r2901 7d0ff22
preset : placebo
real bitrate 263 kb/s size 321 KiB
time : pass 1 : 1s pass 2 : 9s total time : 10 s
metrics :
SSIM All:0.948739 (12.902161)
PSNR average:36.585589
VMAF score = 93.379718

x265 - 2.7+3-9086c8a3e76d:[Windows][GCC 7.3.0][64 bit] 8bit+10bit+12bit
preset : veryslow
real bitrate 254 kb/s size 311 KiB
time : pass 1 : 39s pass 2 : 39s total time : 78 s
metrics :
SSIM All:0.952898 (13.269586)
PSNR average:37.447079
VMAF score = 95.024192

libvpx-vp9 v1.7.0-213-gf4b1eca53
preset : cpu-used 0
real bitrate 238 kb/s size 291 KiB
time : pass 1 : 2s pass 2 : 68s total time : 70 s
metrics :
SSIM All:0.952918 (13.271442)
PSNR average:37.275722
VMAF score = 94.977788

aomenc 0.1.0-8871-g7a3c26460
preset : cpu-used 2
real bitrate 252 kb/s size 307 KiB
time : pass 1 : 2s pass 2 : 1254s total time : 1256 s
metrics :
SSIM All:0.951930 (13.181228)
PSNR average:37.565993
VMAF score = 95.79106

aomenc is real slow for the moment and with cpu-used 2 . I won't try 1080p file for the moment =p

ChaosKing

24th March 2018, 12:04

The most important part: Which one of the encodes pleases your eyes the most?

easyfab

24th March 2018, 13:03

here you have the result files. I add a av1->x264 (crf 0) file .

https://www.sendspace.com/file/bm5el8

For me av1 is the most "clean"

bstrobl

24th March 2018, 13:24

aomenc is real slow for the moment and with cpu-used 2 . I won't try 1080p file for the moment =p

I was expecting a lot slower to be honest :). But as long as the devs can get slightly better quality at roughly the same cpu encode required as VP9 we will have a decent codec on our hands.

MasterNobody

24th March 2018, 14:56

How about adding disabling psy-rd for x264 to the mix i.e. `--psy-rd 0` and adding `--aq-mode 2`: https://www.sendspace.com/file/qdj71j
At such bitrates you SHOULD disable --psy-rd in its current form.

easyfab

24th March 2018, 17:06

Yes, you're right. I only set preset in previous encode and leave others settings to default. I never encode at so low bitrate, it was only for a small test.

for info, with --psy-rd 0 --aq-mode 2 :

x264 :
SSIM All:0.952115 (13.197976)
PSNR average:37.005003
VMAF score = 95.521538

x265 :
SSIM All:0.956373 (13.602420)
PSNR average:38.090090
VMAF score = 96.459293

JohnLai

25th March 2018, 18:05

Nobody post the news?

https://twitter.com/mattication/status/976774873316982784

https://aomediacodec.github.io/av1-spec/

nevcairiel

25th March 2018, 18:22

sneaker_ger

25th March 2018, 21:10

Are they still using "Golden Frames"? Shouldn't the bframe patents have expired by now?

bstrobl

25th March 2018, 21:42

Some random unknown person tweeting a claim that its finished doesn't seem overly convincing. The spec still has a huge draft warning on top, afterall, and the github repo behind it is still changing daily.

There are currently only 3 bugs pertaining to the bitstream itself that need to be finished: https://bugs.chromium.org/p/aomedia/issues/list?can=2&q=Hotlist%3DAV1-Normative+&colspec=ID+Type+Status+Priority+Milestone+Owner+Summary&cells=ids

So it should be close to being done.

hajj_3

26th March 2018, 00:09

https://bitmovin.com/av1-multi-codec-dash-dataset/
https://bitmovin.com/cool-new-video-tools-five-encoding-advancements-coming-av1/

mzso

26th March 2018, 09:51

https://bitmovin.com/av1-multi-codec-dash-dataset/
https://bitmovin.com/cool-new-video-tools-five-encoding-advancements-coming-av1/

The goal is to de-noise the initial content before encoding it and then re-adding the noise or grain effect before output during the decoding process. This way, the unnecessary information would not have to be transmitted at all and the overall load of data could be reduced substantially.

It would be even better if the second stupid step would be skipped.
I hope at least that decoders will have an option to disable artificial noise generation.

LigH

26th March 2018, 10:04

Without adding it back, the result may look strangely artifical ("plastic") and may not cover compression artifacts well, I guess ... so I'm curious to see that, whether confirming my guess or not.

nevcairiel

26th March 2018, 10:58

Grain/Noise-synthesis is not a new concept, H.264 supported it as well, but it never saw any use. This may be more advanced, but we'll see.

In any case, if you want to permanently denoise/degrain a movie, then just do so in pre-processing, but if its a codec feature then it should always be applied in decoding and the image reconstructed fully and properly. My decoders will certainly not offer any options to output a degraded image.

mzso

26th March 2018, 10:59

Without adding it back, the result may look strangely artifical ("plastic") and may not cover compression artifacts well, I guess ... so I'm curious to see that, whether confirming my guess or not.

I think, only if the grain filter sucks and removes a lot of actual detail/pattern.

nevcairiel

26th March 2018, 11:02

I think, only if the grain filter sucks and removes a lot of actual detail/pattern.

Such a grain filter is designed for coding efficiency, with the design in mind that the grain will be added back. It does not have to be designed to "look good" without the grain. So chances are that it won't.

sneaker_ger

26th March 2018, 13:35

Grain/Noise-synthesis is not a new concept, H.264 supported it as well, but it never saw any use. This may be more advanced, but we'll see.
But optional, IIRC. I think basically no decoder implemented it.

Will it be mandatory for AV1?

mzso

26th March 2018, 15:21

Such a grain filter is designed for coding efficiency, with the design in mind that the grain will be added back. It does not have to be designed to "look good" without the grain. So chances are that it won't.

Oh, well. As you said, we'll see. :)

foxyshadis

26th March 2018, 15:32

Are they still using "Golden Frames"? Shouldn't the bframe patents have expired by now?

Golden Frames are a technically elegant solution in their current form; there's no real reason to switch back to B-frames. There's a bit more bookkeeping overhead, which is largely squeezed out in the entropy coding, but the flip side is greater flexibility if the encoder chooses to use it. (VP9's implementation generally doesn't stray far from the classic P and B types, but AV1 supposedly uses them to greater effect by shuffling blocks around in more interesting ways.)

foxyshadis

26th March 2018, 15:41

But optional, IIRC. I think basically no decoder implemented it.

Will it be mandatory for AV1?

Absolutely, just like the in-loop filter.

LigH

27th March 2018, 08:12

New upload: AOM v0.1.0-8892-g10b745615

mzso

27th March 2018, 11:36

I wonder if aom will remain the only encoder/decoder, or whether third parties will develop something such as x264/x265 projects or maybe the ffmpeg people.

(Didn't there used to be an ffvp8 encoder (http://blog.webmproject.org/2010/08/ffmpeg-vp8-decoder-implementation.html)? I don't see it listed in ffmpeg as a decoder/codec.)

LigH

27th March 2018, 11:49

Of course, there will be several "Next Generation Video Codec" projects; e.g. there is a lively discussion about xvc (https://forum.doom9.org/showthread.php?t=175110) in this board. ... BTW, where is schweinsz (https://forum.doom9.org/showthread.php?t=168327)?

On2 VP8 / Google VP9 can be used in ffmpeg, no more need to develop an alternative decoder, I guess... a non-free "everything goes" ffmpeg build by the media-autobuild_suite contains:

DEV.L. vp8 On2 VP8 (decoders: vp8 libvpx vp8_cuvid vp8_qsv ) (encoders: libvpx )
DEV.L. vp9 Google VP9 (decoders: vp9 libvpx-vp9 vp9_cuvid ) (encoders: libvpx-vp9 )

I am quite confident that an ffmpeg with a more restricted license, which is allowed to be distributed (like zeranoe's selection (https://ffmpeg.zeranoe.com/builds/)), will contain them too.

But as long as the AV1 format is not "frozen", ffmpeg will at most "know about it" (maybe detect its presence in some containers with matching content type flags?); as codec it is not yet implemented.

..V.L. av1 Alliance for Open Media AV1

Quoted output is part of ffmpeg -codecs

nevcairiel

27th March 2018, 12:01

Once av1 takes off, I would expect someone to develop a decoder for ffmpeg eventually. Encoders, probably not. Thats more suited for stand-alone projects from the sheer complexity of it.

sneaker_ger

27th March 2018, 12:03

LigH

27th March 2018, 12:09

If ffmpeg developers disagree with some opinions of the original team about e.g. programming styles, I would not be surprised if they may be going to show how it can be made better; wasn't that a reason to develop VPx codecs in parallel to Google? I do not remember everything in detail, but I believe efficiency was one of the focus points.

mzso

27th March 2018, 12:42

I think mzso means other implementations of the AV1 specs. For example ffmpeg has two VP9 software decoders (as your quote from the help shows), the one coming from Google ("libvpx-vp9") and FFvp9 (https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/) ("vp9") developed in spite of already having the free Google one.

I don't see ffvp9 either in ffmpeg (zeranoe), which is strange if it's an ffmpeg internal decoder, as suggested the "ff" part.

sneaker_ger

27th March 2018, 12:52

Like I quoted:
-c:v "vp9" is ffvp9
-c:v "libvpx-vp9" is the one from Google

nevcairiel

27th March 2018, 13:38

They are not called "ffvp9" internally, its just "vp9", which is listed in the quoted output above.

Anyway distinct decoder implementations have several advantages. Often it helps to find bugs in the original decoder, and historically the ffmpeg decoders have also been faster - and they serve as a platform for hardware acceleration, which is not possible with an external decoder like using libaom.

mzso

27th March 2018, 14:11

@sneaker_ger @nevcairiel
Ah, okay. Thanks for clearing that up. It was also confusing that it's named google VP9:
VFS..D vp9 Google VP9
V....D libvpx-vp9 libvpx VP9 (codec vp9)

Once av1 takes off, I would expect someone to develop a decoder for ffmpeg eventually. Encoders, probably not. Thats more suited for stand-alone projects from the sheer complexity of it.

Yeah, a completely software encoder doesn't feel too likely to me. I guess if someone really wants a feature can just add it to aomenc, unless they're just morbidly resistant to external input. Maybe fork it at most.

LigH

27th March 2018, 19:00

it's named google VP9

because Google developed the specifications (theory) further from the base of the VP8 specifications originally developed by On2. But there can be different implementations (practice), not only from Google, but also from different authors, still based on the same specifications, but with different code. The listing is indeed not really unambiguous.

easyfab

27th March 2018, 19:53

aomedia.org new site :)

Coming Soon to a Screen Near You

hajj_3

28th March 2018, 00:54

aomedia.org new site :)

Coming Soon to a Screen Near You

Site looks nice :)

LigH

28th March 2018, 07:34

Bloated and partially insecure.

Quikee

28th March 2018, 12:39

I wonder if aom will remain the only encoder/decoder, or whether third parties will develop something such as x264/x265 projects or maybe the ffmpeg people.

There is "rav1e" - rust AV1 encoder from Mozilla/Xiph guys: https://github.com/xiph/rav1e

bstrobl

28th March 2018, 14:19

Mail just went out from AOMedia, looks like AV1 is now a codec :)

hajj_3

28th March 2018, 14:39

iwod

28th March 2018, 16:36

Yep, AV1 1.0 spec is official: https://aomedia.org/the-alliance-for-open-media-kickstarts-video-innovation-era-with-av1-release/

1.0 spec (619 pages) PDF: https://aomediacodec.github.io/av1-spec/av1-spec.pdf

Now, what plan / ideas do they have to speed it up by 10 to 50x?
And what sort of time frame could we expect that in?

birdie

28th March 2018, 16:42

Can we have a subforum dedicated to AV1?.

I wonder why there's no subforum for VP8/VP9 codecs but they all might be put together.

IgorC

28th March 2018, 16:47

bstrobl

28th March 2018, 16:53

Now, what plan / ideas do they have to speed it up by 10 to 50x?
And what sort of time frame could we expect that in?

They are most likely fixing all the bugs in the initial release in order to have a predictable foundation to work from before dropping in heuristics and optimisations as well as more SIMD instructions. A significant speed-up should be possible by simply reducing the search scope of the encoder at the expense of coding efficiency.

iwod

28th March 2018, 16:59

And I notice the membership page

https://aomedia.org/membership/members/

Apple is the only one not using its logo?

iwod

28th March 2018, 17:00

New era of video has begun. :)

Some big companies were already ready
https://aomedia.org/the-alliance-for-open-medias-av1-takes-center-stage-at-nab-2018/

ARM and Intel talk about fast adoption of AV1 into their hardware.

Ittiam will showcase its Content Adaptive Encoding (CAE) technology with a significantly speeded-up version of the AV1 encoder.

Cant wait to see what speed up that have.

iwod

28th March 2018, 18:07

Yep, AV1 1.0 spec is official: https://aomedia.org/the-alliance-for-open-media-kickstarts-video-innovation-era-with-av1-release/

1.0 spec (619 pages) PDF: https://aomediacodec.github.io/av1-spec/av1-spec.pdf

Christ...........

It's not even a bitstream freeze. This 'release' was put out by the marking folks, and wasn't even discussed with people on the AOM list (I'm part of AOM via VideoLAN). The bitstream remains under development.

Near as I can tell this is just a PR piece before NAB.

LigH

28th March 2018, 18:10

@iwod: Where is your quote from?

v0lt

28th March 2018, 19:01

Are there already video files that fully comply with the approved specification?

JEEB

28th March 2018, 19:12

@iwod: Where is your quote from?
Daemon404 posted (https://news.ycombinator.com/item?id=16699481) that on HN as people posted the "news" article there.

I love it how this wasn't co-ordinated at all with the technical folk in AOM.

Are there already video files that fully comply with the approved specification?
The bit stream hasn't yet been frozen. It is close to it, but there are still open issues on the issue tracker, and apparently there was going to be some final check-ups from now towards the first day or days of April.

hajj_3

29th March 2018, 09:44

https://aomedia-review.googlesource.com/q/status:open is this the same as the github tracker as there seems to be a lot more than 57 bugs on this one?

nevcairiel

29th March 2018, 10:55

Thats a code review platform, not a bug tracker. All those entries there are proposed changes going through review in some shape or form.

bstrobl

29th March 2018, 13:03

http://www.streamingmedia.com/Articles/News/Online-Video-News/AV1-Is-Finally-Here-but-Intellectual-Property-Questions-Remain-124134.aspx

Apparently the hope is for the encoder to be 5x and decoder 2x slower by EOY when compared to VP9.

LigH

29th March 2018, 21:33

Anyway ... enough reason for MABS to support libaom in ffmpeg now, in the "non-free" variant. (And Zeranoe probably soon as well? Read their notes.)

Just check if "--enable-libaom" is included in ffmpeg_options.txt if you used the option ffmpegChoice=1; I believe it is not yet added { P.S.: Now it should. }. Elseway, ffmpegChoice=4 builds the full (non-free) version. Do not distribute.

vidschlub

30th March 2018, 13:07

Why is there no av1 dedicated Forum?

I'm a newbie but I enjoy reading posts here from advanced enthusiasts who opinion I trust. Like to see you guys discuss this stuff so I can learn

vidschlub

30th March 2018, 13:20

I think, only if the grain filter sucks and removes a lot of actual detail/pattern.

This is a common issue with hevc files throughout the internet, the term is often referred to "clay face" and it's utterly appalling.

I would expect any film enthusiast to want to keep as close a quality to the original source as humanly possible in the lowest bit rate possible.

MANY hevc files have this and only the good encoders who know what to look for seem to be smart enough to disable the film grain filter which I believe is on by default.

Plenty of skin wrinkles get removed as a result of this filter.

wiak

31st March 2018, 04:12

Can we have a subforum dedicated to AV1?.

I wonder why there's no subforum for VP8/VP9 codecs but they all might be put together.
or simply "Alliance for Open Media" subforum for AV1, VP9, VP8, Daala, Thor, and meybe Opus and Vorbis as they are all under the same webm/aomedia banner

AV1 shares dna from VPx, daala, thor, will be apart of webm container together with vp9, vp8, opus and vorbis

colinhunt

31st March 2018, 16:00

MANY hevc files have this and only the good encoders who know what to look for seem to be smart enough to disable the film grain filter which I believe is on by default.
Could you tell me where I can find this filter on x265? I went through its documentation and found nothing applicable.

Shevach

31st March 2018, 17:26

Unlike to HEVC, there is a shortage of technical papers and detailed tutorials on AV1. i could not find even a dozen papers dedicated to AV1.
i use March 2018 'aomenc' version (AOMedia Project AV1 Encoder 0.1.0-8619-ge0018b5). There is one issue not clear to me:

To enable parallel encoding, it's necessary to use tiles. Apparently a sort of frame-level parallelization has not been implemented yet (i.e. when one core starts the first frame and upon completion of several MB-rows the second core starts the second frame by using already reconstructed samples of the first frame for motion estimation and so on).

The corresponding code is responsible for activating multi-threading:

if (AOMMIN(cpi->oxcf.max_threads, cm->tile_cols) > 1 && cm->tile_rows == 1)
av1_encode_tiles_mt(cpi);
else
encode_tiles(cpi);

So, in order to activate multi-threading you need set the following parameters: '--num-rows=0' and '--num-columns=N' and '--threads=log2(N)'
Actually in order to apply the parallel encoding i have to divide frames into column-wise tiles. For example, if i use 4x4 tile grid by setting '--num-rows=2 --num-columns=2 --threads=4' then no parallel encoding is performed.

What's a reason for such restriction?

foxyshadis

1st April 2018, 17:23

Can we have a subforum dedicated to AV1?.

I wonder why there's no subforum for VP8/VP9 codecs but they all might be put together.

HEVC and VapourSynth got their subforums when each was starting to get dozens of topics, you don't just magically hit 1.0 and get your sub. It took HEVC over a year after the final release and VapourSynth many months to get to that level of interest. Once that happens with AV1 (it started to with VP8 for a while, but never really hit for VP9) that would be a good idea.

I'm pretty loathe to lump a bunch of codecs together unless they're strongly related and all getting lots of topics. (There was a time when we had a VP3/VP6/Theora subforum.) But that's just my opinion, not necessarily D9's or the other mods'.

hajj_3

1st April 2018, 18:42

mkvtoolnix 22.0 has been released, here is 1 of the new features.

* mkvmerge: AV1: added support for reading AV1 video from IVF, WebM and
Matroska files.

paul97

2nd April 2018, 17:39

LigH

2nd April 2018, 19:20

Welcome.

How do you measure "more relevance"?

I suppose as soon as a more efficient format is announced already with a backing by major commercial companies, interest in the predecessor formats naturally subsides.

TomV

3rd April 2018, 00:14

Now that FFMPEG officially supports AV1, has anyone gotten FFMPEG to successfully encode an AV1 bitstream? What container are you using for output? FFMPEG rejects .av1, .bin, .webm and .mp4. It seems to run (SLOWLY) if you use .mkv or .ts

FFMPEG -f rawvideo -vcodec rawvideo -pix_fmt yuv420p -s 1920x1080 -r 60 -i Netflix_PierSeaside_1080p.yuv -c:v libaom-av1 -strict -2 Pier.mkv

I can't figure out how to pass parameters. -av1-params doesn't work, nor does any other syntax (-aom-params, etc.) I can guess.

If you've successfully encoded, have you been able to decode your AV1 bitstream back to YUV?

nevcairiel

3rd April 2018, 00:21

TomV

3rd April 2018, 01:54

Matroska is the only supported container for AV1 in ffmpeg so far. MPEG-TS will just result in an unplayable file, don't do that. AV1 will likely never fit into MPEG-TS, unless someone defines an additional wrapping with special bitstream startcodes to sync to.
Not sure about other containers, are the specs for those even finalized?

For the options, it doesn't work like x264 or the likes, you can't just pass arbitrary option strings to the library to parse.
Currently, the following options are available directly, plus the usual ffmpeg options for bitrate etc:
-cpu-used x
-auto-alt-ref x
-lag-in-frames x
-error-resilience {default|partitions}
-crf x
-static-thresh x
-drop-threshold x
-noise-sensitivity x

Thanks.

It would make sense for FFMPEG to be able pass AV1 specific encoder parameters to libaom just like you can with -x264-params or -x265-params.

nevcairiel

3rd April 2018, 08:35

It would make sense for FFMPEG to be able pass AV1 specific encoder parameters to libaom just like you can with -x264-params or -x265-params.

libaom would need to have an API to parse string parameters like that, I do not know if that is the case.

benwaggoner

3rd April 2018, 21:15

I have a question.
Why AV1 has more relevance than VP9? VP9 is on par with H265, but on youtube doesn't offer signfiicant bitrate improvements, video bitrate is about the same as Mp4.
Because it is better? For 4K videos ? Supported by many companies?
Practical HEVC encoders substantially outperform any VP9 encoder for pretty much any scenario I can think of. AV1 is a substantial upgrade versus VP9.

Blue_MiSfit

4th April 2018, 01:25

^^ Exactly

hajj_3

4th April 2018, 14:23

Practical HEVC encoders substantially outperform any VP9 encoder for pretty much any scenario I can think of. AV1 is a substantial upgrade versus VP9.

The EVE vp9 encoder claims to have better compression and offer faster encode times than x265.

LigH

4th April 2018, 14:56

AOM v0.1.0-9043-g6f49b5a21 (I noticed several CLI changes)

wiak

5th April 2018, 07:11

Matroska is the only supported container for AV1 in ffmpeg so far. MPEG-TS will just result in an unplayable file, don't do that. AV1 will likely never fit into MPEG-TS, unless someone defines an additional wrapping with special bitstream startcodes to sync to.
Not sure about other containers, are the specs for those even finalized?

For the options, it doesn't work like x264 or the likes, you can't just pass arbitrary option strings to the library to parse.
Currently, the following options are available directly, plus the usual ffmpeg options for bitrate etc:
-cpu-used x
-auto-alt-ref x
-lag-in-frames x
-error-resilience {default|partitions}
-crf x
-static-thresh x
-drop-threshold x
-noise-sensitivity x

the official container for av1 is webm i believe and it support ivf too per aomenc output

webm 1 (vp8/vorbis)
webm 2 (vp9/opus)
webm 3 (av1/opus)

when all browsers and players get support hehe you should be able to just play it fine

and the current av1 encoder is so slow that even vp9 with row-mt=1 runs circles around it

Mosu

5th April 2018, 07:40

The storage format for AV1-in-Matroska is the same as the one for AV1-in-WebM, it's even the same for AV1-in-IVF. No CodecPrivate, each Block starts with a TD OBU and contains all following OBUs up to but excluding the following TD OBU. Dead simple.

And yes, they're still changing the bitstream. Just yesterday an additional bit ("still_picture") was added to the sequence header OBU, and five days ago the profile indicator was changed from two to three bits. Luckily reading AV1 from IVF or WebM doesn't require parsing the sequence header OBU (and therefore mkvmerge already supports those two source containers for AV1), but it is required for reading raw OBU streams. I do have the code for that already, but I won't include it as long as the bitstream is in that much flux.

nevcairiel

5th April 2018, 08:10

I talked with a few people involved in AV1 the other day and they said that AV1 in WebM/MKV is not actually finally specified yet. For example, AV1 in ISOMBFF (MP4) is still under discussion, among other things about the bitstream format allowed in the container, since AV1 has two of those (Annex B and "normal"), and if both would be allowed you would need CodecPrivate to tell the difference. For consistencies sake, I would hope that WebM/MKV would follow the same logic that MP4 takes, so we don't have to deal with yet another difference.

I definitely didn't find a AV1-in-WebM/MKV spec written down anywhere, for that matter.

Mosu

5th April 2018, 08:21

I've read both the current AV1-in-MP4 spec draft as well as Annex B storage method. What I don't quite get is why there's the Annex B format when the OBUs themselves already contain a length field, albeit an optional one (the "obu_size" syntax element with "obu_has_size_field" set to 1). Wouldn't it have sufficed to make that mandatory in certain situations?

I definitely agree that storage-in-WebM/Matroska and storage-in-MP4 should work the same way as much as possible.

nevcairiel

5th April 2018, 08:50

Yeah I don't understand that part either. One reasoning I have stumbled upon seems to be that RTP transport tries to optimize transmission for every single byte, so they don't have the size field in the OBU, and instead of wanting to re-write the OBU header to add it on the RTP depacketizers side, they prefer to just add the Annex B size headers.

mzso

5th April 2018, 10:36

There is "rav1e" - rust AV1 encoder from Mozilla/Xiph guys: https://github.com/xiph/rav1e

Interesting. Is this completely written from scratch?

mzso

5th April 2018, 10:40

Yep, AV1 1.0 spec is official: https://aomedia.org/the-alliance-for-open-media-kickstarts-video-innovation-era-with-av1-release/

1.0 spec (619 pages) PDF: https://aomediacodec.github.io/av1-spec/av1-spec.pdf

I don't know about you guys, but the large notice and the watermark gives me a suspicious draft vibe.

nevcairiel

5th April 2018, 10:44

The spec is indeed not finished yet, people all fell victim to a PR marketing push for the upcoming tradeshow. But presumably its on a deadline to actually get finished soon.

bstrobl

5th April 2018, 11:07

The spec is indeed not finished yet, people all fell victim to a PR marketing push for the upcoming tradeshow. But presumably its on a deadline to actually get finished soon.

It is probable that HW manufacturers wanted something to work with as well, since most of the large tools need to be implemented at one point or another in silicon which takes time. A couple minor issues in the bitstream can be fixed later before tape-out.

nevcairiel

5th April 2018, 11:10

It is probable that HW manufacturers wanted something to work with as well, since most of the large tools need to be implemented at one point or another in silicon which takes time. A couple minor issues in the bitstream can be fixed later before tape-out.

You don't need to post a big PR thing that its finished (when its not) for the HW people to start working on it. The big HW companies are involved in the development of the codec anyway. Its pure marketing.

Clare

5th April 2018, 12:58

and the current av1 encoder is so slow that even vp9 with row-mt=1 runs circles around it

There's a bug talking about porting row-mt to AV1: https://bugs.chromium.org/p/aomedia/issues/detail?id=488&q=

mzso

5th April 2018, 14:17

There's a bug talking about porting row-mt to AV1: https://bugs.chromium.org/p/aomedia/issues/detail?id=488&q=

Since they have a performance gap, hopefully they'll at least improve upon multi-threading, where there's definitely room for improvement compared to VP9.

wiak

5th April 2018, 14:25

Since they have a performance gap, hopefully they'll at least improve upon multi-threading, where there's definitely room for improvement compared to VP9.
vp9 with row-mt improved it a hell of alot

mzso

5th April 2018, 15:15

vp9 with row-mt improved it a hell of alot

Indeed, though we're still only talking about 75% CPU utilization compared to <40%

wiak

5th April 2018, 15:31

Indeed, though we're still only talking about 75% CPU utilization compared to <40%
av1 is less than 1%
:stupid:

mzso

5th April 2018, 15:47

av1 is less than 1%
:stupid:

So row-mt would improve it to 2%? What relevance does that have? So far it had zero performance optimizations. (As far as I know)

wiak

5th April 2018, 16:15

So row-mt would improve it to 2%? What relevance does that have? So far it had zero performance optimizations. (As far as I know)

hehe its so slow even time would be waiting for it to end before the universe does :D

mandarinka

5th April 2018, 20:30

The EVE vp9 encoder claims to have better compression and offer faster encode times than x265.

Treat those claims like you would any marketing speak. It might be made by FFmpeg/open source guy, but it is still a vendor marketing pitch, he obviously only states things that make Eve look good.

After all, the thing is not publicly available, so nobody can really prove the claims.

hajj_3

5th April 2018, 23:25

Treat those claims like you would any marketing speak. It might be made by FFmpeg/open source guy, but it is still a vendor marketing pitch, he obviously only states things that make Eve look good.

After all, the thing is not publicly available, so nobody can really prove the claims.
They seem to imply that google and netflix use the eve encoder.

Djfe

6th April 2018, 15:49

might be, it's probably not that hard to improve vp9 for someone like him, and he worked at Google creating vp8 and vp9.

it certainly can be better, but that doesn't proof that it's always better (how he implies it), since the test samples can be constructed to get the statistics he wants.

"I only believe in statistics that I doctored myself"

I'm very certain, that it's better than libvpx in every way so it's likely that Google and especially Netflix (being big content providers) are interested in these gains.
but that doesn't make his statistics into a proof.

mandarinka

7th April 2018, 21:10

Yeah, it should definitely be better than libvpx, that's why Ronald Bultje (the author) wrote it after all! Not sure if Google uses it. At least for youtube they used to stick to libpvx and just didn't seem to care much about problems it has/had.

(Note that I didn't want to suggest the claims are outright dirty lies, just that thing the authors would claim tend to be one-sided, be it with On2, AV1, this case, x264/MCW...)

Mystery Keeper

8th April 2018, 11:51

libvps does have problems though.
I reported this critical bug a year ago, and they still haven't gotten to fixing it.
https://bugs.chromium.org/p/webm/issues/detail?id=1380&q=component%3Alibvpx&colspec=ID%20Pri%20mstone%20ReleaseBlock%20Type%20Component%20Status%20Owner%20Summary

mzso

10th April 2018, 09:28

By the way. Is AVIF getting finalized in parralel with AV1?
Or is that something that will happen later, if at all?

bstrobl

10th April 2018, 15:44

By the way. Is AVIF getting finalized in parralel with AV1?
Or is that something that will happen later, if at all?

I think they are standardising an AV1 still frame so that hardware decoders can be used to decode images in future. Container support in AVIF will come later since video is a priority.

bstrobl

10th April 2018, 15:45

New Xiph blog post:

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

mzso

10th April 2018, 16:14

I think they are standardising an AV1 still frame so that hardware decoders can be used to decode images in future. Container support in AVIF will come later since video is a priority.
The mention "animation" for AVIF. So they're going to do that with I frames?
This sounds remarkably counter-intuitive to me. Take only the I frames of a video codec, then make a half-assed video format ("animation") out of it.

bstrobl

10th April 2018, 16:58

The mention "animation" for AVIF. So they're going to do that with I frames?
This sounds remarkably counter-intuitive to me. Take only the I frames of a video codec, then make a half-assed video format ("animation") out of it.

From what I can tell the still image header is optional and mainly designed to save a few bytes: https://aomedia-review.googlesource.com/c/aom/+/54781

I am going to take an educated guess and say that they will include Inter-frame compression for timed image sequences, just like HEIF/HEIC does, as it would be silly to waste storage not including it while reclaiming a few bytes in the header. It is possible that the logic for those components will be shifted to the P frames themselves to allow very basic decoders to deal with single frame images, as each frame is stored separately.

Clare

11th April 2018, 01:55

AV1 beats x264 and libvpx-vp9 in practical use case

https://code.facebook.com/posts/253852078523394/av1-beats-x264-and-libvpx-vp9-in-practical-use-case/

foxyshadis

11th April 2018, 04:27

New Xiph blog post:

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

Whoa, awesome. Monty's posts are some of the best reading out there on the state of the art of AV compression, glad to see him back.

AV1 beats x264 and libvpx-vp9 in practical use case

https://code.facebook.com/posts/253852078523394/av1-beats-x264-and-libvpx-vp9-in-practical-use-case/

Interesting how they didn't even bother with x265. They've obviously rejected it for licensing reasons, even if they haven't ever said so. The encoding time increase for AV1 though... wow.

iwod

11th April 2018, 06:24

Interesting how they didn't even bother with x265. They've obviously rejected it for licensing reasons, even if they haven't ever said so. The encoding time increase for AV1 though... wow.

I think somewhere along the line of HEVC licensing, one or all of the HEVC guys ( MPEG / HEVC Advance or Valos ) must have seriously pissed off these companies. I can literally smell and taste their hatred on HEVC, and vowed not to use it in their life time sort of attitude.

Shevach

11th April 2018, 13:05

AV1 supports 1/8-pel motion precision (optional, specified by frame header parameter - allow_high_precision_mv). i wonder what's a gain in coding efficiency to exploit high MV precision? In HEVC and AVC the precision is 1/4-pel (for luma). In case of high-frequency video (HFR) or even for 60 fps 1/8-pel probably is redundant. Perhaps, 1/8-pel MV precision is beneficial for 4K resolution with 30 fps rate?
Unlike to HEVC development (where all was public and all discussions/contributions were located at jct-vc repository), some AV1's decisions are non-graspable to me. Who knows - under what circumstances 1/8-pel motion vector precision is beneficial vs. 1/4 pel one?

Shevach

11th April 2018, 13:12

Maybe for low-resolutions and low frequency sub-pixel movements achieve the 1/8 granularity?

ianken

11th April 2018, 23:43

Tommy Carrot

12th April 2018, 00:31

vidschlub

12th April 2018, 01:12

Could you tell me where I can find this filter on x265? I went through its documentation and found nothing applicable.

You might need to set a +film flag or disable 'nograin' I honestly can't recall, I'm really a newbie at best, others here can help.

I've done a lot of side by side comparisons and if you don't have the side by side, you can trick yourself into thinking it's better, but a lot of detail is lost and washed out.

Someone here will know for sure.

foxyshadis

12th April 2018, 03:45

nevcairiel

12th April 2018, 06:25

VP9 already had 1/8 pel MV precision, it was probably just inherited from there.

colinhunt

12th April 2018, 21:23

Harmonic showed a comparison demo at NAB, pitting AV1, AVC, HEVC and JVET against each other. At the equivalent bitrate of 1.9 Mbps they got the following results:

Codec -- PSNR -- VMAF

AVC -- 32.7 -- 58
HEVC -- 36.7 -- 80
AV1 -- 37.2 -- 83
JVET -- 38.5 -- 88

That's all the info I got.

LigH

12th April 2018, 22:52

They still use PSNR? :rolleyes: Don't we prefer SSIM/dB today? Well, VMAF is more like that.

What does it prove? ... More computational complexity is the solution? We need more supercomputers. :o

This statement might contain sarcasm.

iwod

14th April 2018, 12:39

LigH

14th April 2018, 13:14

For this one selected sample, maybe? Many show demos pick the one comparison with the results making the own preferred product look best. I do not even see any link to this show here (maybe colinhunt was there in person?).

colinhunt

15th April 2018, 19:35

^ No, I wasn't, just happened to bump into a short video of the demo (and the scores) on Twitter.

enctac

16th April 2018, 08:48

AV1 vs x265 / libvpx-vp9 / x264 / QSV(H.264,LA-ICQ)

Clip: Animation, 1920x1080, 335frames(13.972sec)
Metric: VMAF, SSIM

https://i.imgur.com/9l5xVZX.jpg

mzso

16th April 2018, 10:46

AV1 vs x265 / libvpx-vp9 / x264 / QSV(H.264,LA-ICQ)

Clip: Animation, 1920x1080, 335frames(13.972sec)
Metric: VMAF, SSIM

16311

The attachment will never get approved, you need to upload it somewhere else.

iwod

16th April 2018, 12:13

That is x265 doing surprisingly well.

Phanton_13

16th April 2018, 17:14

enctac for Vp9 in comparisons I recomend to disable frame-parallel as is at outdated feature and use row-mt because in my tests it don't hurt quality and inprove speed (in reality row-mt has highther metrics but the variation is so low that statistically is insignicant, it has a variance of 0.0002 for ssim scores and 0.04 for vmaf scores). Plus apart of CPU 0 is also interesting to use CPU 1 an least one time in the comparison.

dissory

16th April 2018, 23:29

LigH

16th April 2018, 23:35

As usual, it is impossible to give a guaranteed ratio of efficiency between two codecs, it always depends on the material processed with it, as well as how annoying a specific person rates the loss.

The development of both HEVC (x265) and AV1 is not yet done, and AV1 is in a much earlier stage (it has not even many speed-up techniques implemented yet). But it is already considerably more efficient than x265. Unfortunately, it also requires a lot more time to encode.

dissory

16th April 2018, 23:39

But it is already considerably more efficient than x265.

Any rough estimate % on how much more efficient on average?

LigH

17th April 2018, 09:05

At its current speed, I don't have the patience to run elaborate test sequences, they would probably take months without using a "render park".

And how much difference does it mean to you whether it is 10% or 15% or 20%? Where is your personal threshold for ... which action?

mzso

17th April 2018, 14:23

What are the odds that youtube won't use AV1's increased efficiency to decrease bandwidth further instead of increasing the crummy quality?
I expect they're not good.

LigH

17th April 2018, 14:38

Because AV1 software is not yet mature enough, neither as encoder nor as decoder. If you have a device which has a hard time playing FullHD HEVC and can't handle UHD HEVC in real time, then do not even consider trying to play AV1.

The AOM is just even in the process to release specifications. There was no time yet to speed-optimize any software implementation. And without specifications being officially finalized, no hardware producer would be a fool to already release accelerating decoder chips.

Blue_MiSfit

17th April 2018, 17:58

Clearly a very long way to go.

Development of psy is of course critical in getting good subjective quality. In the tests I've seen the encoder still favors blurring heavily which smells a lot like simple PSNR tuning ;)

Also, hopefully AV1 avoids the pitfall of VP9 - terrible rate control.

Provided these issues are handled, the encoding speed comes up and fast software decoders plus hardware decoders come out, I'd see AV1 being quite useful on the web - specifically in Chrome and Firefox, since these will likely never get HEVC support.

As a premium OTT service operator, I struggle to see the value in it, however, since DRM standards only allow for delivery of 480p (and in some cases 720p) on Chrome and Firefox due to the insecurity of Widevine on these platforms. One of the biggest value propositions for using a new codec is being able to deliver high resolution video. If my DRM requirements prevent this, there's less incentive to spend the cost to make yet another video format.

The way I see it, we'll have to keep making H.264 basically forever, we have to make HEVC today to deliver UHD + HDR video to all the 10 foot endpoints plus some mobile devices, and that is an increasingly mature ecosystem with high quality today. VP9 is an option, but it's moot for us since everything that supports VP9 also supports HEVC, and practical HEVC encoders are better than libvpx.

What does adding AV1 get me?

iwod

17th April 2018, 18:32

Can anyone please explain this for dummies?

How good is AV1 in comparison to HEVC in terms of quality and size right now (and will these get better over time or are they pretty much done with most major improvements)?

If you look at the graph, it is not too hard to tell, at 5Mbps or below, x265 is about the same ( or better ) as AV1 in terms of quality for this clip. ( Anime )

My Personal Opinion, judging from small amount of testing and limited information, AV1 is the same or ( 10 - 20% ) better. ( Bitrate Reduction ). That is at the expense of 500x to 1000x+ encoding time. And as said, AV1 encoder is not optimised for speed yet, expect the final to be around 6 - 10x encoding time.

MoSal

17th April 2018, 22:19

If you look at the graph, it is not too hard to tell, at 5Mbps or below, x265 is about the same ( or better ) as AV1 in terms of quality for this clip. ( Anime )

Look closer (--cpu-used=2 and --cpu-used=1).

user822

18th April 2018, 10:34

mzso

18th April 2018, 13:04

I would say that the film grain synthesis is something that no one has really looked at yet in tests, that will be a huge advantage over HEVC.
Screenshots below are from

Bluray Source (125MB H264)
aom-master 2pass cq-level=40 (cpu-used=2 film-grain-test=1 bit-depth=10) (8.3MB)
x265-master 2pass bitrate=2025 (preset=placebo output-depth=10) (8.0MB)

Frame 1:
Src (https://i.imgur.com/sGlSjgF.png), x265 (https://i.imgur.com/4dxUOZD.png), aom (https://i.imgur.com/619PaXz.png)
Frame 2:
Src (https://i.imgur.com/x4PWzw9.png), x265 (https://i.imgur.com/MJX4FPc.png), aom (https://i.imgur.com/8VeGM8t.png)

I still think it's the worst idea ever. Time would have been better spent creating an extraordinary grain filter that leaves useful detail intact. (as much as realistically possible)

Out of curiosity, can the synthesis part (but not the removal.) be disabled (or defeated) to see how it looks without it?

sneaker_ger

18th April 2018, 13:22

I still think it's the worst idea ever. Time would have been better spent creating an extraordinary grain filter that leaves useful detail intact.
That can be done purely as an encoder-side feature and it's not like degraining filters are something new. No need to have something done for the bitstream freeze.

MoSal

18th April 2018, 13:39

I would say that the film grain synthesis is something that no one has really looked at yet in tests, that will be a huge advantage over HEVC.

If content providers use it.

I definitely look for the day where I no longer need to use the sharpening filter shortcuts I added to my player configuration.

mzso

18th April 2018, 14:32

If content providers use it.

I definitely look for the day where I no longer need to use the sharpening filter shortcuts I added to my player configuration.

How is that? I only feel the need to disable sharpening if the video is atrociously grainy/noisy. This keep-grain feature doesn't help with this at all. It might make it worse though.

MoSal

18th April 2018, 16:21

How is that? I only feel the need to disable sharpening if the video is atrociously grainy/noisy. This keep-grain feature doesn't help with this at all. It might make it worse though.

I don't disable sharpening. I enable sharpening as I can't stand the smoothness of many videos.

I basically have this in ~/.mpv/input.conf:

k add sharpen +0.25
K add sharpen -0.25

Values between 0.75 and 1.25 look good for my eyes.

And I already use ewa_lanczossharp for scaling.

Barough

19th April 2018, 13:56

AOM AV1 v0.1.0-9264-gbce84eb0b (http://www.mediafire.com/file/zaq4vp3j7b9cf3n/)
Built on April 19, 2018, GCC 7.3.0

https://aomedia.googlesource.com/aom

foxyshadis

20th April 2018, 02:35

HM and JM both had a rudimentary implementation of FGM, and they never made it into any of the commercial or major free encoders or decoders. I hope AV1's makes it into the wild, because that's one of the features I most sorely miss for mid-to-low bitrate encoding. There wouldn't be such a thing as "too smooth" at normal bitrates anymore; HEVC has really suffered among video enthusiasts because of that.

mzso

20th April 2018, 13:32

With a current FFMPEG build I get 0.2 fps on 1080p content. And that's a single stream.

To use this for next-day TV VOD it needs to be...faster. Or, maybe the ffmpeg integration is not fully baked? The CPU certainly is not loaded in any appreciable way. It's not even clocking up.

Oh, cool, at least we won't need to wait for it to get into ffmpeg. I missed this comment before. Although I think I'll hold back on trying it until some performance improvements land.

(BTW, It's been mentioned a bunch of times that they didn't do any performance optimizations in libaom.)

LigH

20th April 2018, 18:08

AOM v0.1.0-9271-gd6499b0cd

mzso

20th April 2018, 18:32

The bitstream is not frozen, so you should use av1 only for testing... but currently it's too slow even for that. ;) Once it is frozen, i expect the speed optimizations will come fairly quickly. Their stated goal is around a hundred times faster encoding speed at the end of the year. Hopefully with not significant quality drop.

Well, at least it maximizes it's single-thread cpu utiliztation. I get constant 8.32-8.33 CPU utilization on my 12 (virtual) core system. :)

Blue_MiSfit

20th April 2018, 21:51

^^ Is it just me, or does that sound extremely optimistic?

The bitstream was supposed to be frozen about 18 months ago I think? Maybe they should be a bit more conservative with timelines.

WhatZit

22nd April 2018, 08:23

Maybe they should be a bit more conservative with timelines.

Remember that the fundamental purpose behind AV1's existence is to spit in the eye of HEVC.

Should the AoM have published credible timelines, HEVC would have had ample opportunity to dodge out of the way of any expectoration. Whether they'd have actually taken advantage of those opportunities is another matter.

As it currently stands, the decision facing the streaming industry is this: with the rapid uptake of UHD/HDR consumer displays (aka immediate demand), do you implement a UHD delivery system NOW using HEVC's absurd licensing, or in 3 years time using AV1's open license?

That decision should be a no-brainer... if it weren't for the likes of Velos being in the HEVC patent pool.

So, if the AoM were able to convince those decision makers that they need only wait 1 year (irrespective of the timeline's veracity), HEVC gets it in the eye again.

iwod

22nd April 2018, 20:45

^^ Is it just me, or does that sound extremely optimistic?

The bitstream was supposed to be frozen about 18 months ago I think? Maybe they should be a bit more conservative with timelines.

Also remember they are still pretty much the guys from On2, ( Or at least half of them ) anyone who has been in Doom9 long enough would know what they are like.

foxyshadis

24th April 2018, 15:59

Also remember they are still pretty much the guys from On2, ( Or at least half of them ) anyone who has been in Doom9 long enough would know what they are like.

I don't think there's that many On2 employees left; I think it's more a general quality of the AV industry to overpromise and underdeliver, and Google itself is well-known for unfounded enthusiasm for eternal betas. Kind of a match made in heaven, there.

Clare

24th April 2018, 20:20

Shevach

25th April 2018, 07:39

Doesn't seem to have ever been discussed in public. I bet it was a test an engineer inserted and it was just never removed; I wonder if it's ever been used in real life.

Rationales of many AV1 features seem me vague. Woo-Jin Han in LinkedIn forum "AV1 Learning" commented 1/8-pel precision:
" It was proven that high precision mc is only effective for low resolution. Beyond 1080p, even 1/4 pel seems not very effective to justify its complexity. I remember that 1/4 pel shows 30% coding gain for famous Mobile CIF sequence (low res, complex texture, slow motion, aliasing from inadequate down sampler) but average 5-8% over various test sequences. Very high frame rate with non hierarchical structure may change the situation but it seems clear that it is highly sequence dependent tool"

I remember a paper "Motion-Compensating Prediction with Fractional-Pel Accuracy", by B. Girod, 1993 . If we omit a mathematical part of the article and go to the conclusion part, it's written (in my wording): for blocks 16x16 of TV video resolution 1/4-pel motion accuracy appears to be sufficient.

Shevach

25th April 2018, 07:46

AV1 enables to omit transmission of skip flags. Indeed, there is the frame-header parameter 'skip_mode_present' and if this parameter equals to 1 then the skip flags are not signalled. The rationale is clear, if we know 'a priory' that encoding of a given frame will not produce skip blocks then it's redundant to transmit skip flags.
Let's look at the situation from another view, what's a penalty in transmission of skip flags provided that all blocks are non-skipped?
Because i am not completely familiar with AV1 entropy coding process i consider AVC/HEVC arithmetic engine instead.
In HEVC/AVC the maximal probability of a symbol is ~0.98 and hence the number of bits produced by encoding a symbol having the maximal probability is -log2(0.98) = ~0.02 bits.
Let's suppose that we know ahead that all MBs will be no-skipped (i.e. skip_flag = 0 for each MB) and consequently the skip_flag syntax element gets maximal probability 0.98. In such case the total number of bits consumed by all skip flags is ~0.02 x Number_Mbs.
For example, HD resolution frame has usually 8100 MBs (16x16 grid) and hence the total size of all skip_flag syntax elements is ~8100 x 0.02 = 162 bits. It's negligible in most cases.
Probably AV1 frame level parameter 'skip_mode_present' (to disable transmission of skip flags) has a minimal impact on coding efficiency, although it increases the decoding complexity (more 'if-else').

Shevach

25th April 2018, 15:42

Added AV1 to my comparison: https://wyohknott.github.io/video-formats-comparison/

I had to run it at cpu-used=4 to get a reasonable encode time so it's not representative of the max quality that could be obtained.

You can see that the encode speed is still infinitesimal.

What's sense to check codecs with PSNR values 45 dB and greater?
According to HVS research all video with PSNR above 45 dB look perceptual identical to the original.

Djfe

27th April 2018, 07:12

I still think it's the worst idea ever. Time would have been better spent creating an extraordinary grain filter that leaves useful detail intact. (as much as realistically possible)

Out of curiosity, can the synthesis part (but not the removal.) be disabled (or defeated) to see how it looks without it?

Use the NL-Means filter on Handbrake instead ;) (way too slow for an encoder but beautiful/very good IMO)

Another topic:
Good video to explain people what av1 is, why it was created and by whom etc. (the whole story):
https://youtu.be/lEdqN22vaWs

wiak

27th April 2018, 17:21

fresh build today
https://awesome.nwgat.ninja/av1/av1-3db7530-x64-nwgat.ninja.7z

LigH

29th April 2018, 09:03

AOM 0.1.0-9348-g589bae879

mzso

29th April 2018, 12:31

So, a month passed since the (not quite true) news about the bitstream being frozen. Are they closer at least?

iwod

29th April 2018, 13:54

So, a month passed since the (not quite true) news about the bitstream being frozen. Are they closer at least?

Yes, they are much closer now, as it was last month, and early this year, and late last year......

/s

Honestly, I think it is actually good they delay it. The one thing you don't want is a standard being rushed.

wiak

29th April 2018, 23:38

finally newer git builds decode older av1 encoded files, yey for progress
:stupid:

TD-Linux

8th May 2018, 21:38

In HEVC/AVC the maximal probability of a symbol is ~0.98 and hence the number of bits produced by encoding a symbol having the maximal probability is -log2(0.98) = ~0.02 bits.
Let's suppose that we know ahead that all MBs will be no-skipped (i.e. skip_flag = 0 for each MB) and consequently the skip_flag syntax element gets maximal probability 0.98. In such case the total number of bits consumed by all skip flags is ~0.02 x Number_Mbs.
For example, HD resolution frame has usually 8100 MBs (16x16 grid) and hence the total size of all skip_flag syntax elements is ~8100 x 0.02 = 162 bits. It's negligible in most cases.
Probably AV1 frame level parameter 'skip_mode_present' (to disable transmission of skip flags) has a minimal impact on coding efficiency, although it increases the decoding complexity (more 'if-else').

For AV1 it's even smaller, 1/65535 of a bit. However you'll need do adapt to that probability, so you'll burn more bits at the beginning of a frame. That said, the skip_mode_present doesn't control the skip flag but rather the skip_mode flag, which itself is a way to signal that you're going to use a "default" predictor. Still, the gains are pretty small, it's more of a speed savings to not have to code this flag if it's unused.

wiak

9th May 2018, 09:03

hey TD-Linux fancy meeting you here and in other news mpv windows builds finally has av1 decoding
https://sourceforge.net/projects/mpv-player-windows/files/64bit/

LigH

9th May 2018, 09:33

The media-autobuild_suite (https://github.com/jb-alvarado/media-autobuild_suite/) can help you building your up-to-date mpv as well, based on ffmpeg sources. So if mpv can play it, then ffmpeg may handle it as well? ... Yes:

DEV.L. av1 Alliance for Open Media AV1 (decoders: libaom-av1 ) (encoders: libaom-av1 )

nevcairiel

9th May 2018, 09:45

Until the bitstream is actually finally frozen, excitement about inclusion in software seems misplaced, since any current binary may not work anymore tomorrow. That should always be kept in mind. :)

mzso

9th May 2018, 11:17

Until the bitstream is actually finally frozen, excitement about inclusion in software seems misplaced, since any current binary may not work anymore tomorrow. That should always be kept in mind. :)

Well, it already can't play a few av1 encodes from a few weeks ago. :)

Mierastor

15th May 2018, 12:06

https://twitter.com/bitmovin/status/996084579952836608

Pushman

15th May 2018, 20:28

https://streaminglearningcenter.com/codecs/netflix-on-av1.html

Ronca: "We think that initial AV1 computational complexity of 4-10x vs. libvpx would be usable in production. There is a lot of work underway to improve the performance, and we are hopeful that the performance goals will be achieved."

vidschlub

16th May 2018, 22:54

Well, it already can't play a few av1 encodes from a few weeks ago. :)

Seriously? That sounds like it's really not ready for prime time.

nevcairiel

16th May 2018, 23:30

Seriously? That sounds like it's really not ready for prime time.

Its quite simply not done yet. We keep repeating that here regularly. :)
Until its finalized, noone should be using it outside of experimentation/testing.

vidschlub

17th May 2018, 07:35

Its quite simply not done yet. We keep repeating that here regularly. :)
Until its finalized, noone should be using it outside of experimentation/testing.

I got the impression from the news announcement that they'd frozen some element of the design, which was a big milestone?

I (wrongly?) assumed, it would just be optomisations and performance from here on out.

I look forward to it dominating, but maybe it's going to be several years?

Phanton_13

17th May 2018, 09:01

Actually from why I heard AV1 is frozen at the level of features, now they are working out implementations bugs and the only thing that is really work on is the bitstream.

Blue_MiSfit

17th May 2018, 19:32

^^ Where did you hear this?

Phanton_13

19th May 2018, 13:23

^^ Where did you hear this? More that heard is read as it was in a discusion on IRC but I'm not sure on the channel.

bstrobl

19th May 2018, 16:25

More that heard is read as it was in a discusion on IRC but I'm not sure on the channel.

https://freenode.logbot.info/aomedia/20180514

foxyshadis

19th May 2018, 18:26

I wish they'd taken a look at the eighth-pel issue before going into informal feature freeze, that's going to completely hamstring 4K adoption and probably hurt even at 1080p. Just performing the equivalent search as AVC or HEVC will take so much longer, just due to much higher memory pressure, even if you pretend it's q-pel and only look at every other pixel.

nevcairiel

20th May 2018, 00:06

Luckily encoders can choose to not use some feature if its deemed too slow, especially since 8-pel is optional anyway and has to be signaled in the frame header.

foxyshadis

20th May 2018, 07:49

Luckily encoders can choose to not use some feature if its deemed too slow, especially since 8-pel is optional anyway and has to be signaled in the frame header.

Ah, I'd been under the impression that it was a required feature. With a permissive spec, it doesn't matter.

LigH

21st May 2018, 14:54

AOM v0.1.0-9559-g59d2aa958

TD-Linux

22nd May 2018, 23:31

I remember a paper "Motion-Compensating Prediction with Fractional-Pel Accuracy", by B. Girod, 1993 . If we omit a mathematical part of the article and go to the conclusion part, it's written (in my wording): for blocks 16x16 of TV video resolution 1/4-pel motion accuracy appears to be sufficient.

Others are correct in that 1/8-pel is inherited from VP9. That said, there are many reasons why the results from that 1993 paper may no longer be valid - for example, VP9 operates on up to 64x64 blocks (and 128x128 for AV1), meaning that spending an extra bit for a more precise MV can potentially have a much bigger payoff than in a codec limited to 16x16 prediction blocks.

It's also a relatively cheap feature to add - the subpel filters are already pretty large, so it's just adding another set of taps.

Shevach

31st May 2018, 15:44

Others are correct in that 1/8-pel is inherited from VP9. That said, there are many reasons why the results from that 1993 paper may no longer be valid - for example, VP9 operates on up to 64x64 blocks (and 128x128 for AV1), meaning that spending an extra bit for a more precise MV can potentially have a much bigger payoff than in a codec limited to 16x16 prediction blocks.

It's also a relatively cheap feature to add - the subpel filters are already pretty large, so it's just adding another set of taps.

The problem is not spending additional 'bin' per vector component but how many comparisons are added for motion estimation in 1/8-pel MV precision?

LigH

1st June 2018, 15:40

AOM 0.1.0-9658-g265d15d46

New CLI option:

--enable-fwd-kf=<arg> Enable forward reference keyframes

mzso

1st June 2018, 16:36

AOM 0.1.0-9658-g265d15d46

New CLI option:

--enable-fwd-kf=<arg> Enable forward reference keyframes

What does it do?

benwaggoner

5th June 2018, 03:07

What does it do?
Something like Open GOP or RADL, I'd guess.

Mierastor

9th June 2018, 11:06

"The new V76 is essentially the successor to Arm’s previous high-end video block, the Mali-V61, which was announced back in 2016. Understandably the world of video encoding and decoding doesn’t evolve at quite as brisk a pace as GPUs, so Arm generally only revises their video blocks at about half the frequency. ... this processor will not include any support for the upcoming AV1 codec. While the bitstream specification for the eagerly anticipated codec was released a couple of months back, the timing was unfortunately after Arm had already completed the V76 RTL (never mind the fact that the specification isn’t closed yet). So it’s going to have to be the next video block after the V76 before Arm can include AV1 decode support. ... The very high encoding requirements of AV1 also mean that even after a decoder ships in a phone, we’re unlikely to see a full-featured encoder in a phone any time soon."

https://www.anandtech.com/show/12835/arm-announces-maliv76-video-processor-planning-for-the-8k-video-future

nevcairiel

9th June 2018, 11:11

Its fascinating how the PR stunt from AOM managed to mislead everyone into thinking the bitstream is actually done. And months later, its still not actually done!

Blue_MiSfit

10th June 2018, 23:02

Mr_Khyron

11th June 2018, 09:00

Socionext Implements AV1 Encoder on FPGA over Cloud Service
http://socionextus.com/pressreleases/socionext-implements-av1-encoder-over-cloud-service/

LigH

11th June 2018, 10:27

AOM v0.1.0-9742-g4e7b6f08f

Somewhat related to AV1: Google would like to patent (r)ANS, a speed optimized kind of Arithmetic Coding, specifically for its use in a video codec – despite Jarek Duda (its main inventor) having released this algorithm already to Public Domain in 2014...

iwod

11th June 2018, 19:35

Its fascinating how the PR stunt from AOM managed to mislead everyone into thinking the bitstream is actually done. And months later, its still not actually done!

May be I am Old? Does any one remember On2? I mean if anyone who has been on Doom9 long enough should know. On2's "marketing", has been the same for years, even after it has been acquired by Google, and even many of the On2 employees left ( May be only the engineering left and not their marketing? ), their marketing hasn't changed a bit. And now it is Open Media Alliance, which is still pretty much ( Google + Mozilla ) + many others, with Av1, google is taking the majority of responsibility.

I guess it's still "wait and see".

I'm still not sure why I'd use AV1 as an OTT operator delivering 4k content. I have to make HEVC for everything that exists today. Even if AV1 ends up being a bit more efficient (and this comes down to encoder implementation) it will still cost me a huge amount of money to encode my library in both formats, so why would I?

I guess it all depends on what clients end up supporting it.

One of the reason were HEVC Advance were changing OTT operator % per stream. Which was ridiculous. It wasn't until this march did they decide to stop this terms. And Youtube ( Google ) and Netflix has a huge incentive to stop using HEVC because of this. Not to mention HEVC listening is a bag of hurt. Google and Netflix want to provide uses AVC as base and use VP9 / AV1 for everything else. So as a consumer if you want Youtube or Netflix 4K content you will have to buy a STB that support Vp9 or Av1. They won't be doing ANY HEVC content. One of the interesting thing is both Youtube and Netflix cant be watched in China, and while many "new" or "info" likes to claim they are the biggest in the "world". That "world" does not include China. Similar to how Amazon or eBay likes to claim they are the biggest X in the world, when compared to China they are at least 4 - 5 times smaller in sales volume. Since China is in Region 2, they paid much less and most of the devices are already shipped with HEVC, in fact they are already streaming HEVC whenever they can.

Somewhat related to AV1: Google would like to patent (r)ANS, a speed optimized kind of Arithmetic Coding, specifically for its use in a video codec – despite Jarek Duda (its main inventor) having released this algorithm already to Public Domain in 2014..

This has been mentioned multiple times, not sure if they are really against patent codec or against codec that don't use their patents portfolio.

Anyway I really hate this licensing terms and price discovery period. It has happened with AVC, and it is happening again with HEVC. The group or their members want to extract maximum outrageous prices, and waited for years of failure in market before they relent. I sometimes wonder if there are any more thing we could do with AVC to further improve it as an baseline.

benwaggoner

12th June 2018, 22:30

I guess it's still "wait and see".

I'm still not sure why I'd use AV1 as an OTT operator delivering 4k content. I have to make HEVC for everything that exists today. Even if AV1 ends up being a bit more efficient (and this comes down to encoder implementation) it will still cost me a huge amount of money to encode my library in both formats, so why would I?

I guess it all depends on what clients end up supporting it.
Assuming the prior codec has full penetration,
codec_value=decoder_penetration * quality_@_perf advantage

So AV1's success is driven by decoder_penetration and quality_@_perf. The latter is important; 15% better at 10x encoding time doesn't really count unless encoding time was already more than fast enough. When live encoding is needed, or if encoding compute is a limit, MIPS/pixel is the limiting factor, and so AV1 implementations will compete with H.264, VP9, and HEVC at the same MIPS/pixel.

If devices wind up providing just H.264 and AV1, than the decision driver is whether the added compute, storage cost, and cache dilution is worth it. Even if compute was free, at a large scale supporting another codec is a huge operational expense and system complexity increase.

benwaggoner

12th June 2018, 22:58

So as a consumer if you want Youtube or Netflix 4K content you will have to buy a STB that support Vp9 or Av1. They won't be doing ANY HEVC content.
Netflix is certainly delivering UHD on devices that don't have VP9 hardware decoder support. And VP9 is a particularly challenging bitstream format for software decoding without high single-core CPU performance (this is much improved in AV1).

Tons of SmartTV and STB-like devices have way less CPU than a typical phone, so software decoding at 2160p is a non-starter. And replacement cycles are way slower for TVs and STBs than for phones and tablets.

Even if AV1 is an incredible success, companies would still have to deliver HEVC for legacy living room devices in 2025+. Heck, they will still have to deliver H.264 in 2025 for a number of device categories.

Personal computers and phones/tablets are by far the easiest markets for fast integration of new codec support. And lots of enterprises were still doing corporate content in WMV/VC-1 until they'd deprecated XP and Vista.

Massively improved technologies get the market moving, but even the best improvements can take a long time to become universally available in many markets.

amichaelt

13th June 2018, 00:58

So as a consumer if you want Youtube or Netflix 4K content you will have to buy a STB that support Vp9 or Av1. They won't be doing ANY HEVC content.

So your claim is that Netflix will cut off the 10s of millions (though probably actually more) of devices that are already streaming 4K HEVC from their service? Yeah, right... :rolleyes: People are not going to buy a new TV or STB because of some silly codec war.

IgorC

13th June 2018, 02:49

Blue_MiSfit

13th June 2018, 07:03

Even if AV1 is an incredible success, companies would still have to deliver HEVC for legacy living room devices in 2025+. Heck, they will still have to deliver H.264 in 2025 for a number of device categories.

Exactly, and this is why (unless CDN delivery costs are the vast majority of your opex) I don't see why a premium OTT VOD service would use AV1 anytime soon.

iwod

13th June 2018, 07:08

So your claim is that Netflix will cut off the 10s of millions (though probably actually more) of devices that are already streaming 4K HEVC from their service? Yeah, right... :rolleyes: People are not going to buy a new TV or STB because of some silly codec war.

Well I should have removed Netflix from that sentence, I am not sure if all of their Catalog are in HEVC already. But Youtube certainly aren't doing any HEVC at all. ( At least for now )

Yes, The point is, HEVC is already included in most TV or STB.

Exactly, and this is why (unless CDN delivery costs are the vast majority of your opex) I don't see why a premium OTT VOD service would use AV1 anytime soon.

I wish we don't have the same problem with VVC.

MoSal

13th June 2018, 21:16

I have bought 1,5 years ago LG smartTV. This year after upgrading the Youtube aplication it starts to support VP9 (stats for nerds reports it) and plays Youtube 4K without single drop.

I tested a cheap locally-assembled TV with Chinese parts the other day. VP9 4K@60fps is supported out of the box. Opus was the codec that's not supported.

No one will forget AV1, not even the no name chip manufacturers. Here is hope, from now on, they will not forget Opus either.

amichaelt

14th June 2018, 03:13

It's not like VP9 isn't supported by any smart TVs.

I have bought 1,5 years ago LG smartTV. This year after upgrading the Youtube aplication it starts to support VP9 (stats for nerds reports it) and plays Youtube 4K without single drop.

But it’s not supported by everything whereas anything that can do 4K with a Netflix app has to have HEVC support.

Blue_MiSfit

15th June 2018, 09:46

anything that can do 4K with a Netflix app has to have HEVC support.

Exactly

blurred

22nd June 2018, 10:24

Interesting discussion regarding the choice of entropy coder for AV1: https://encode.ru/threads/1890-Benchmarking-Entropy-Coders?p=56945&viewfull=1#post56945

Daala range coder using 16 multiplications per symbol has won with rANS using 1 multiplication per symbol, and ~7x faster implementations: https://sites.google.com/site/powturbo/entropy-coder

Do anybody know why the slower and more costly one was chosen?

ps. This nibble adaptive rANS is e.g. used in recent open source Dropbox DivANS: https://blogs.dropbox.com/tech/2018/06/building-better-compression-together-with-divans/

nevcairiel

22nd June 2018, 11:43

Phanton_13

22nd June 2018, 12:13

If I don't remenber incorrectly the rANS does some things in a reverse way and othes things that complicated the cost of implimentation in hardware, in other works of implementing in silicon the 16 multipliers in Daala range coder is cheapier than implementing the memory need to implement the rANS. Also it apears that rANS can increase the latency specially at low rates due to the buffers. Most of this problems are being tackled in a new generation of ANS coders, but they are not going to be ready for a possible implementation in AV1.

Also remenber: Faster/cheapier in software is not the same as faster/cheapier in hardware.

blurred

22nd June 2018, 17:03

But doesn't 16 multiplications cost more energy than one - paid in energy consumption and battery life of our devices?

Phanton_13

23rd June 2018, 00:55

That only aplies to software implementations, in hardware you dont think in number of instructions but in number of gates/transistors, and the maping is not that simple as sometimes you can implement a function with 9 multiplications into the same number of gates that takes to implent 2 multiplications (this in an example of a real case). Memory also have cost in gates and power and you ned to evaluate If it's more eficient to expend the gates on memory or in procesing, the result of this evaluation is what determined the use of the Daala range coder as av1 have been designed with the hardware implementation in mind because it is critical for mobile phones.

blurred

24th June 2018, 12:32

(...)you can implement a function with 9 multiplications into the same number of gates that takes to implent 2 multiplications(...)
Looks like you are referring to serial execution, which might require 16x frequency increase here (?)
And hardware decoding requires replacing current hardware - meanwhile (~5 years) it will be made software, where being 7x slower seems a huge sacrifice.
Additionally, Google is still fighting for this ANS patent over dead bodies ( https://arstechnica.com/tech-policy/2018/06/inventor-says-google-is-patenting-work-he-put-in-the-public-domain/ ) - if it is not intended for AV1, will it prevent others using ANS in video compression?

Phanton_13

24th June 2018, 15:21

Looks like you are referring to serial execution, which might require 16x frequency increase here (?)
No, I refering to reimplemt the function, in that case a 50Mhz FPGA implementation of the full ASIC was able to match a Core2duo at 2Ghz runing its functionality in software, and in silicon the asic was runing at 1Ghz.

Hardware design is very diferent that software development, for example in the range coder of daala most multiplication are constant*value, in this case in hardware you don't need to do multiplication always, for example in the case that the constant is "2" there are various variants as for example in unsigned is only a bit shift but in harware is even cheaper as you only resoute the data and for signed you use and adder or a modified shifter. And for other values most of the time there is an alternative and faster way to implement it instead of doing a full multiplier. Also most of the time you don't need to implement a full multiplication unit as you only implement it what you need, for example you can do a 12 bit multiplier instad of a 16bit one if you values always fit in 12 bits, or you only implement the lower bits of a 16 bits multiplication and ignore any value over 16bits...

In hardware design the frecuency is a derived value of data propagation (delay, timing) and what you whant is results, even if some implementation have slower frecuency but produces the result faster you go for it.

And hardware decoding requires replacing current hardware - meanwhile (~5 years) it will be made software, where being 7x slower seems a huge sacrifice.

That is true, bus is more like 2-3 years for hardware to start apearing, and in this case it can be reduced to 1 year due to the varios hardware designers and manufactures in AOM.

Additionally, Google is still fighting for this ANS patent over dead bodies ( https://arstechnica.com/tech-policy/2018/06/inventor-says-google-is-patenting-work-he-put-in-the-public-domain/ ) - if it is not intended for AV1, will it prevent others using ANS in video compression? No, actually having it refused can actually be good as it's detimentral if its aproved at posteriori for other entity because it can be used to put the patent office and the posteriori aproval in question and invalidate it. More this also demostrated the disfuntionality in both the patent system and the legal teams in companies.

blurred

24th June 2018, 16:17

(...)in the range coder of daala most multiplication are constant*value(...)
If I properly understand, there are 16 multiplications due to "maximal alphabet size" = 16 - it needs to multiply "range size" by CDF value for all 16 symbols.
In contrast, rANS needs to multiply by only one value (p[s] = CDF[s+1]-CDF[s]), where s is the currently decoded symbol.

CDF changes with data type (context), and can be adapted - these are definitely not constant values.
In hardware you can build 16 parallel multipliers not to increase frequency, but it would need 16x more gates, and most importantly: consume 16x more energy.

Phanton_13

24th June 2018, 19:45

In part you are rigth but at the same time you are forgeting one thing, those 16 pararell multipliers consume more energy than the extra memory needed in rANS? the hardware is inerent pararell, then is theupdate posible to do in pararel with another task during the decoding process? Also there is the posibility of optimization for those 16 pararell multiplications as one operand is comon to all. On thing that help with hardware is not to think of it like a computer program but as a data flow between operands.

blurred

24th June 2018, 21:24

Such additional (for rANS) buffer is only needed in encoder, which for video compression is usually an order of magnitude more costly, and for example for youtube, netflix video used only once per thousands or millions of views (decodings).
And video compressor seems to require huge flexible buffers for various modellings/predictions - is it a non-negligible cost to share a few kilobytes with entropy coder?

Also there is the posibility of optimization for those 16 pararell multiplications as one operand is comon to all.
Interesting, indeed the range is varying, but the same for all 16 multiplications.
Thinking about multiplication as shifts and additions, the cheap shifting part can be indeed shared, but it doesn't seem simple to get systematic optimization for separate additions - do you maybe know some paper showing how to optimize it?

Quikee

25th June 2018, 21:13

AV1 1.0.0 code tag (https://aomedia.googlesource.com/aom/+/v1.0.0)

Also specs (https://aomedia.org/av1-bitstream-and-decoding-process-specification/) don't have draft status anymore.

No official announcement yet..

GTPVHD

26th June 2018, 00:12

https://aomediacodec.github.io/av1-spec/

Still says Draft Document here.

TD-Linux

26th June 2018, 02:03

Daala range coder using 16 multiplications per symbol has won with rANS using 1 multiplication per symbol, and ~7x faster implementations: https://sites.google.com/site/powturbo/entropy-coder

Do anybody know why the slower and more costly one was chosen?

Firstly, the AV1 range coder only uses 1 multiplication per CDF entry, the 16 is the "worst case" (keep in mind that they can be done in parallel, e.g. with SIMD, so it's actually better to use more than less as the multiply is the cheapest part in software). Secondly, the difference is nowhere near 7x when we benchnmarked the two - rANS was faster, but by a factor of about 2. However, the requirement to buffer and reverse the symbols was unfortunately insurmountable.

Also keep in mind that AV1 adjusts the probabilities on a per-symbol basis. The entropy coder CDFs are designed to make adapting the probabilities very fast (with only adds and shifts). This puts some constraints on the design that don't exist in the linked benchmark (which uses fixed probabilities as far as I can tell).

benwaggoner

26th June 2018, 04:50

Often the choice is for simpler hardware implementations, since thats really the future, not software. I'm also not convinced a generic benchmark can fully represent the performance characteristics of an actual codec.
I think you can remain happily convinced that a generic benchmark will NOT "represent the performance characteristics of an actual codec"

There is so much clever that gets done, even in decoders. And there are so many different kinds of parallelization, SIMD, ASIC, etcetera available. And surprising numbers of decoders don't implement basic stuff like skipping non-reference frames when doing seeking, due to the system layer and the decoder layers not being tightly coupled enough.

AV1 is way better designed for parallelized HW decoders than VP9 was, which was pretty painfully serialized compared to HEVC, with software decoders pretty dependent on fast single-core performance.

LigH

26th June 2018, 07:37

@ GTPVHD: Then the github site may have outdated content?

MABS also retrieves sources from GoogleSource. And had to disable a TESTS flag to continue compiling, 2 days ago.
__

P.S.: New upload:

AOM v1.0.0-6-gce8f4811b (https://www.mediafire.com/file/chl6dyq78ej8lt9/aom_v1.0.0-6-gce8f4811b.7z) (yes, v1.0.0+)

Phanton_13

26th June 2018, 11:17

do you maybe know some paper showing how to optimize it? Lamentably no for the general case, also searching for it I found a paper:"DAALA_EC in AV1" that have some data for hadware implementations:

Daala_ec decoder 54k gates,performance 1 symbol per clock, decoding time 1 clock.
Daala_ec encoder 9k gates,performance 1 symbol per clock, encoding time 1 clock.
ANS decoder 49k gates,performance 1 symbol per clock, decoding time 1 clock.
ANS encoder 25k gates,performance 1 symbol every 2 clocks, encoding time 2 clocks.

As for reference VP9 G2 hardware codec has 2.60M gates (2160p@30fps content playback: ~250Mz)

Basically ANS has not faster decoding speed that Daala range coder once implemented in hardware, an even is slower in encoding. The thing that the speed diference in software implementation don't correlate to it in hardware implementation is enougth common as to call it a norm. Other thing is that it appears that in the decission of using the Daala range coder the hardware guys at ARM/AMD/Itel/Nvidia had a good hand in it.

Also rANS is quite recent and higthly optimised, plus it uses 32/64bit aritmetic and SIMD instructions while daala range coder uses only 16bit aritmethic. And you can do betwen 2 and 4 1 clock 16bit multipliers in the same number of gates that of a 32bit 1clock multiplier.

Blue_MiSfit

27th June 2018, 08:11

Congrats to the AOM team for hitting 1.0! It's only a few months late ;)

Good stuff tho, looking forward to the encoder maturing. It's always great to see more options.

wiak

27th June 2018, 11:26

I tested a cheap locally-assembled TV with Chinese parts the other day. VP9 4K@60fps is supported out of the box. Opus was the codec that's not supported.

No one will forget AV1, not even the no name chip manufacturers. Here is hope, from now on, they will not forget Opus either.
LG OLED telly dont support opus either sooo heh

LigH

27th June 2018, 11:34

Due to general interest:

My AOM builds are a result of jb-alvarado's media-autobuild_suite (https://github.com/jb-alvarado/media-autobuild_suite/), which has building ffmpeg as main purpose, but also offers several more features.

During the configuration, among several other options, I enabled building of separate executables (not only libraries used in ffmpeg), and building of AOM.

Tommy Carrot

27th June 2018, 17:18

I've done a few tests with the 1.0 build (thanks Ligh!). I've compared it to the 0.1.0-9043 build from april, i mainly tested --cpu-used 0 to 2, because above that the quality isn't really better than current gen codecs, while it's still horrendously slow. :D Overally the encoding speed is improved to around twice as fast in each speed settings, while the quality is very similar (both filesize and metrics). In some cases there are definite visual improvements, but in most cases it has more or less the same quality.

This encoder still needs a lot of work, it's still too slow even for short tests, not to mention everyday use. The quality is fairly impressive, definitely better than x265 or VP9, but IMO it falls short to XVC and VVC.

iwod

27th June 2018, 18:51

Tommy Carrot

27th June 2018, 18:55

Are there VVC encoder already? Or are you implying XVC?
Well, the jvet encoder posted in the vvc thread. It should be more or less the same, just an earlier version.

blurred

27th June 2018, 20:41

Response by author of the benchmark from https://encode.ru/threads/1890-Benchmarking-Entropy-Coders?p=57093&viewfull=1#post57093
Firstly, the AV1 range coder only uses 1 multiplication per CDF entry, the 16 is the "worst case" (keep in mind that they can be done in parallel, e.g. with SIMD, so it's actually better to use more than less as the multiply is the cheapest part in software).
For SSE2 decoding in AV1 you need 4 SIMD multiplications (_mm_mullo_epi32) + 4 comparisons (_mm_cmpgt_epi32) + combining (after _mm_movemask_ps) 4 SSE2 registers
It is unlikely that this will be faster than scalar decoding.
For AV1 hardware implementations, you need 16 32x32 multipliers, otherwise parallel multiplications are not possible.
Also 16 comparisons + other operations are additionaly required.
Secondly, the difference is nowhere near 7x when we benchnmarked the two - rANS was faster, but by a factor of about 2.
For this benchmark and current implementations, rANS decoding is SEVEN times faster than AV1.
On ARM the scalar version is 5 times faster.
The AV1 nibble entropy coder is even slower than a bitwise range coder.
However, the requirement to buffer and reverse the symbols was unfortunately insurmountable.
This is only required in encoding which is usually done in software.
This irrelevant argument is always used in their discussions.
The benchmark shows that TurboANXN, even with reverse encoding is more than 4 times faster than the current AOMedia AV1 encoder.
Also keep in mind that AV1 adjusts the probabilities on a per-symbol basis.
The entropy coder CDFs are designed to make adapting the probabilities very fast (with only adds and shifts).
This puts some constraints on the design that don't exist in the linked benchmark (which uses fixed probabilities as far as I can tell).
The benchmark is using adaptive probabilities.
There is so much clever that gets done, even in decoders.
And there are so many different kinds of parallelization, SIMD, ASIC, etcetera available.
And surprising numbers of decoders don't implement basic stuff like skipping non-reference frames when doing seeking, due to the system layer and the decoder layers not being tightly coupled enough.
This is indepedant from entropy coding. Here we are comparing the AV1 entropy coder against rANS and they are interchangeable.
Also rANS is quite recent and higthly optimised, plus it uses 32/64bit aritmetic and SIMD instructions while daala range coder uses only 16bit aritmethic.
And you can do betwen 2 and 4 1 clock 16bit multipliers in the same number of gates that of a 32bit 1 clock multiplier.
According to the AV1 source code, 32 bits operations are used. rANS is 32 bits only.

I think the decision against rANS is politically motivated (Not-invented-here-Syndrom (https://de.wikipedia.org/wiki/Not-invented-here-Syndrom)).
Otherwise, why not simply let the (now removed) rANS version in the repository for comparisons.
Hardware comparisons (complexity,energie consumption,costs,...) are only possible after implementing both optimized versions.

Note, we are considering here only adapative rANS. Do not confuse this with block based ANS as used in zstd,lzfse, lzturbo...

Phanton_13

28th June 2018, 18:22

Response by author of the benchmark...
According to the AV1 source code, 32 bits operations are used. rANS is 32 bits only.

They are actually doing 16 arithmetic using 32 bit operations due that modern processor are faster unsing 32 bits operations that using 16bit operations, also varios presentations and documents indicates that dala range coder uses 15x16-> 31bit multiplications.

I think the decision against rANS is politically motivated (Not-invented-here-Syndrom).
Otherwise, why not simply let the (now removed) rANS version in the repository for comparisons.

The political motivation can also be viewed in the reverse and if it was included tell that it was for political reasons... An inventor of something can always and most of the time tell that the reason that other don't use it is political motivated. Other times something cam be included to make someone happy (this have hapened in hevc and x264).

Also the patent situation, not only by google but also by others that do the same dirts it's posibility of inclusion.

For me instead of whine for it not being included the correct is to continue perfecting for it to be included in AV2.

foxyshadis

29th June 2018, 06:06

Response by author of the benchmark from https://encode.ru/threads/1890-Benchmarking-Entropy-Coders?p=57093&viewfull=1#post57093

For SSE2 decoding in AV1 you need ....

I'm sorry, tell us again about how this codec isn't designed for your 20-year-old Pentium 4. That has nothing to do with optimizability under AVX/AVX2 or Altivec, which are the only instruction sets that matter today.

mzso

29th June 2018, 08:40

AV1 development is becoming disappointing. With the promise of a February delivery for the final bitstream format I expected youtube providing AV1 streams by now. (At least for new/popular videos)

wiak

29th June 2018, 14:05

AV1 development is becoming disappointing. With the promise of a February delivery for the final bitstream format I expected youtube providing AV1 streams by now. (At least for new/popular videos)

they shot them self in the foot during NAB, when they so called released the codec

but currently most tools with not encode, case in point ffmpeg has strict mode on and dont even do webm, aomenc does webm, the encoding and decoding parts are to slow to be ustable even on a modern ryzen 8-core

atleast with 1.0.x series we can finally decode stuff encoded in older builds

still useless for anything other than thinkering

and this is from a user perspective

a proper roadmap with set dates on when stuff is getting implemented like faster encoding, multi-threading, browser support?

am convinced that aomedia runs on valve time https://developer.valvesoftware.com/wiki/Valve_Time

anyway, will check back in 3 months time, pace out (but i guess they are still more than a year off)

nevcairiel

29th June 2018, 14:59

but currently most tools with not encode, case in point ffmpeg has strict mode on and dont even do webm, aomenc does webm

The container bindings are not finalized yet, which is why tools don't really create those yet. But both MP4 and MKV/WebM bindings are being worked on right now, and once those are final, expect at least FFmpeg to pick them up too.

MoSal

30th June 2018, 01:30

the encoding and decoding parts are too slow to be usable even on a modern ryzen 8-core

No kidding. I tested with --cpu-used=8 --tile-columns=4 expecting acceptable speed and awful quality.

The opposite turned out to be true. The speed is still slow. And the quality wasn't bad. It wasn't very good either, but still beets a tuned x265-slower profile with the specific sample I tested (1Mbps / 1080p / 30fps).

aomenc -o t.webm t.y4m -t 4 --target-bitrate=256 --enable-qm=1 \
--aq-mode=1 --film-grain-test=1 --cpu-used=8 --tile-columns=4

ffmpeg -i t.y4m -c hevc -crf 38 -preset slower -x265-params \
sao=0:deblock=-2,-2:psy-rdoq=5:qcomp=.75:ipratio=1.25:pbratio=1.18 t.mkv

The quality of --film-grain-test=1 is impressive. Better than no test, but --film-grain-test=2 adds too much grain.

On the decoding side. ffav1 should be available soon-ish.

paul97

5th July 2018, 15:38

Has AOMedia already started optimizing AV1 (especially its speed) after the bitstream freezed on the 25th of June?

iwod

5th July 2018, 18:06

Has AOMedia already started optimizing AV1 (especially its speed) after the bitstream freezed on the 25th of June?

Well you can be assured they have plans. But it will take time, counted in months, not days or weeks.

Mjpeg

5th July 2018, 22:07

Great Chris Montgomery article on CDEF

https://hacks.mozilla.org/2018/06/av1-next-generation-video-the-constrained-directional-enhancement-filter/

I'm thrilled to see a royalty-free option here, so I'll try to be patient as they speed up the encoder.

TD-Linux

6th July 2018, 00:04

They are actually doing 16 arithmetic using 32 bit operations due that modern processor are faster unsing 32 bits operations that using 16bit operations, also varios presentations and documents indicates that dala range coder uses 15x16-> 31bit multiplications.

Since those slides were made, they shrank even further - they are only 7x9 multiplications. Lower latency for this multiply was critical for hardware throughput, so we shrank it as much as we could without significant compression losses. See https://aomedia.googlesource.com/aom/+/master/aom_dsp/entdec.c#199

Has AOMedia already started optimizing AV1 (especially its speed) after the bitstream freezed on the 25th of June?

Yup! You can always follow the latest development of libaom on Gerrit. Here's the most recent merged changes: https://aomedia-review.googlesource.com/q/status:merged

MoSal

6th July 2018, 00:19

Had some time to do some tests with --cpu-used=4 and no tiles.

As the bitrate goes up, libaom continues to be superior compared to tuned x265 when it comes to I frames. For non-I frames, the story is different. Tuned x265 (see my previous comment) non-I frames look superior to libaom P frames which look terrible. Even when I give more bitrate to P frames (--max-intra-rate=700), they continue to look terrible.

The flexibility in the API and CLI options is quite lacking. The documentation is not great either (I had to check the source code to know what to pass to some options).

Again, this is with --cpu-used=4 which is probably analogous to veryfast in x264/x265. And it is needless to say that none of this is due to inherent limitations in the codec itself.

dapperdan

7th July 2018, 08:08

Great Chris Montgomery article on CDEF

https://hacks.mozilla.org/2018/06/av1-next-generation-video-the-constrained-directional-enhancement-filter/

Interesting tidbit from Monty in the comments, sounds like Mozilla is working on its own AV1 encoder.

"That’s much more to do with the way the encoder is tuned, and you’re seeing VPx’s traditional tuning biases here. The VP encoders have always been rather merciless to mid-frequency content, and I think the current AOM encoder isn’t yet using any sort of activity masking.

Compare AV1 to Daala on those images; the substantial difference there is difference in encoder tuning philosophy. We’ll be bringing that to the encoder we’re working on here at Moz."

Quikee

7th July 2018, 08:45

Interesting tidbit from Monty in the comments, sounds like Mozilla is working on its own AV1 encoder.

Yup - rav1e - https://github.com/xiph/rav1e

hajj_3

7th July 2018, 22:15

https://www.bbc.co.uk/rd/blog/2018-06-comparison-of-recent-video-coding-technologies-in-mpeg-and-aomedia

foxyshadis

9th July 2018, 06:28

Yup - rav1e - https://github.com/xiph/rav1e

Wow, I'm suddenly excited about AV1 again. Why is it that anything Monty does is like a kiss of gold to me?

Barough

9th July 2018, 15:47

AOM AV1 v1.0.0-82-gf77d93175 (http://www.mediafire.com/file/ad4l6rcz8iszznp/)
Built on July 09, 2018, GCC 7.3.0

https://aomedia.googlesource.com/aom

Zebulon84

9th July 2018, 16:19

AOM AV1 v1.0.0-82-gf77d93175 (http://www.mediafire.com/file/ad4l6rcz8iszznp/)
Built on April 19, 2018, GCC 7.3.0

I guess the "April 19, 2018" is just a copy-paste fromthat previous message (https://forum.doom9.org/showthread.php?p=1839762#post1839762). Files in the archive are from today, July 9, 2018.

Barough

9th July 2018, 17:50

I guess the "April 19, 2018" is just a copy-paste fromthat previous message (https://forum.doom9.org/showthread.php?p=1839762#post1839762). Files in the archive are from today, July 9, 2018.

Thnx for the heads up. As u said...... it's copy/paste from the old post. Fixed now. ;)

benwaggoner

9th July 2018, 19:27

Yup - rav1e - https://github.com/xiph/rav1e
The VPx series was quite unusual in that the bitstream proponent also made the primary encoder. For all the MPEG codecs, MPEG didn't worry much about the speed of the reference encoder because only 3rd party implementations are used in the market.

It's a good sign of the health of AV1 that we are seeing a variety of different encoders, both open-source and proprietary, being worked on. VPx never had enough interest to get that effort.

Competition drives tons of implementation innovations in encoding. That's why we're still seeing significant improvements in MPEG-2 after all these years.

utack

9th July 2018, 22:04

VPx never had enough interest to get that effort.

That is not entirely true, there is Eve (https://www.twoorioles.com/eve-for-vp9/), which Netflix used for a while

soresu

10th July 2018, 02:04

I was under the impression that Ronald Bultje from the libvpx team built Eve, so while technically separate its practically incestuous in creation :p

iwod

10th July 2018, 07:21

Competition drives tons of implementation innovations in encoding. That's why we're still seeing significant improvements in MPEG-2 after all these years.

I think I have read this statement sometime ago and may have asked a similar question before. What are the use case of MPEG-2 today? From high end bitrate to low end I cant think of a single use case where it would be valuable.

Blue_MiSfit

10th July 2018, 08:29

I think I have read this statement sometime ago and may have asked a similar question before. What are the use case of MPEG-2 today? From high end bitrate to low end I cant think of a single use case where it would be valuable.

So many.

- Terrestrial broadcast in the US using ATSC is 100% MPEG-2 for now.
- Legacy cable / satellite networks with tons of existing decoders / professional IRDs in the field
- Legacy broadcast contribution, especially at high bitrates for backup.
- Legacy cable VOD (still pushing 15 Mbps 1080i MPEG-2 in most cases)
- Broadcast playout - quite heavily using 50 Mbps XDCAM HD422, sometimes even lower quality.

TBH, for anything new that's for distribution, yeah you wouldn't use MPEG-2 most likely.

However, legacy stuff has a habit of staying around forever.

Plenty of current premium satellite TV networks use MPEG-2 as their house format because surrounding standards like XDCAM HD422 in MXF have robust support for in-band metadata like captioning, timecode, AFD, etc, and also have broad support from playout server vendors, NLE / post production tools, and pro transcoder tools. The other benefit is that MPEG-2 is quite lightweight to decode these days, so a video server can be dense and cost effective and still perform perfect frame accurate seeking and smooth playback, saving CPU cycles for graphics etc.

Quality is definitely "good enough" (especially considering transmission encoding typically being 6-12 Mbps real-time encoded CBR H.264 with small GOPs and tight buffers).

More modern alternatives like J2K (a-la AS-02 style MXF) and AVC Intra do have benefits in certain cases, especially where very high quality is desired, but they typically come with additional cost in terms of processing power, software licensing, and storage capacity. Higher quality formats tend to live in acquisition and post production. When you deliver to playout, 1080i XDCAM HD422 is probably the most common standard - at least in the US.

The broadcast industry as a whole tends to cling to the melting icebergs of trust for as long as possible, and TBH this is for good reason. Any change that introduces potential risk is an extremely tough sell when you have 4 or 5 nines of uptime required in your SLA. It only takes a few minutes of downtime per year to start feeling the pain.

I've heard of some improvements in MPEG-2 especially for H.264 -> MPEG-2 transcoders to glue new channels into legacy infrastructure, but TBH this was years ago. I haven't heard of anything major recently. Ben, care to share?

benwaggoner

10th July 2018, 21:49

I've heard of some improvements in MPEG-2 especially for H.264 -> MPEG-2 transcoders to glue new channels into legacy infrastructure, but TBH this was years ago. I haven't heard of anything major recently. Ben, care to share?
Elemental's encoder has delivered >20% bitrate reduction for statmuxed MPEG-2 over the last couple of years.

Granted statmuxed MPEG-2 is kind of a special case, except that it probably accounts for the majority of MPEG-2 eyeball hours these days.

(for those blissfully ignorant of channel-based broadcast world, statmuxing is when multiple video streams are encoded in parallel to fit within a given amount of total bandwidth. Basically inter-stream VBR).

hajj_3

12th July 2018, 08:20

https://medium.com/@luc.trudeau/av1-opportunity-or-threat-for-power-and-arm-servers-6871007ad99e

paul97

12th July 2018, 11:21

When there''ll be a good and official encoder for AV1. (for example in Handbrake or Youtube. We need to wait for Mozilla''s Rust Encoder or they immediately will release AOMedia encoder?

LigH

12th July 2018, 20:05

Official? Well, aomenc is already available as codec for ffmpeg; and HandBrake uses an ffmpeg core, you just need to build a recent version or hope for one to be released.

Whether it is "good" ... your demands, you opinion.

benwaggoner

12th July 2018, 20:06

When there''ll be a good and official encoder for AV1. (for example in Handbrake or Youtube. We need to wait for Mozilla''s Rust Encoder or they immediately will release AOMedia encoder?
What do you consider a "good official" encoder for H.264 and HEVC? Generally for the MPEG codecs there is a reference encoder which is way too slow for production use, and then a variety of vendors making their own implementations, some open-source, some proprietary.

I wouldn't expect to have everyone using one "official" encoder like libvpx with AV1 if AV1 gets significantly broad market adoption. VPx had mainly a very small number of very large companies using it.

olduser217

13th July 2018, 03:11

Yup - rav1e - https://github.com/xiph/rav1e

From encoding strategy or algorithm point of view, are these AV1 encoders developed by Mozilla or EVE have any difference compare to the one from AOM? Or just mainly encoding speed up?

mzso

13th July 2018, 10:48

benwaggoner

13th July 2018, 19:16

I don't think that any of the encoders are in a usable state yet.
Certainly not for large scale content publishing.

Given historical encoder development, I wouldn't expect AV1 encoders to be able to practically compete with HEVC encoders for large commercial mission-critical live/VOD applications before Q4 2019.

There's a long path from "look, I can encode a little clip in two days that'll play in this pre-release web browser" to "this is good enough to replace the stuff I bet my business on already."

And 1080p and UHD are things, and the current AV1 are too slow to do enough encoding at those resolutions for tuning, and optimal tuning can be quite different at higher resolutions, particularly 2160p. So no one really even knows how suitable AV1 is as a technology, let alone how applicable current encoders are for it.

Beyond quality @ perf, there's tons of integration effort along many end-to-end pipelines. And some of those pipelines will require a decent quality 2160p60 low latency live encoder. In theory it's obvious how it works, but in practice SO many little things will and do go wrong.

Even with mature codecs, you try to raise the reference frame count of a low bitrate stream (still staying under profile @ level minimum), and you realize that some mobile chipset's DRM implementation requires a boot-time memory carveout of max ref frames * max frame size. So if you use 6 refs at 320x240, and your max frame size is 1920x1080, you still need to carve out 6 1920x1080 frames.

So many little implementation details like that need to get discovered and ironed out with every new codec. One advantage of AV1 is that supporting chipsets will all be newer, so the backwards compatibility won't be as fraught. But in many cases, fraught backwards compatibility is vastly better than none at all.

That's why tons of broadcast/cable is still MPEG-2.

Blue_MiSfit

13th July 2018, 23:34

Super well put, per usual, Ben.

I'm stoked to dive head-first into AV1 testing once I have some more time. I'm neck deep in HEVC right now :)

uneedme

14th July 2018, 08:16

i typed --help ......

too much parameters

I tried to read the references...... tried to get the meanings of abbreviations

alot arguments with no range indications......

............

any good guide texts？Thanks indeed

TD-Linux

19th July 2018, 21:08

From encoding strategy or algorithm point of view, are these AV1 encoders developed by Mozilla or EVE have any difference compare to the one from AOM? Or just mainly encoding speed up?

Both have methods to improve quality, as well. EVE gives a large improvement over libvpx quality via a number of methods. rav1e is not nearly as far along, but does already have psy optimization, unlike libaom. You can try it out with the --tune psychovisual flag if you like.

mzso

20th July 2018, 09:25

Both have methods to improve quality, as well. EVE gives a large improvement over libvpx quality via a number of methods. rav1e is not nearly as far along, but does already have psy optimization, unlike libaom. You can try it out with the --tune psychovisual flag if you like.

Is rav1e forked from libaom, or was it written from nothing?

LigH

20th July 2018, 14:35

New upload:

AOM v1.0.0-181-g3bffe09a5 (https://www.mediafire.com/file/by73glqlyag4ya7/aom_v1.0.0-181-g3bffe09a5.7z)

v0lt

20th July 2018, 20:01

Almost a month has passed since the freezing of the bitstream (2018-06-26). Official samples posted somewhere?

TD-Linux

20th July 2018, 23:17

Is rav1e forked from libaom, or was it written from nothing?

It's written from nothing, however it does link in some CDF tables and the transform SIMD code from libaom as we haven't written our own yet.

Almost a month has passed since the freezing of the bitstream (2018-06-26). Official samples posted somewhere?

If you run "make testdata" in libaom you'll get a ton of test ivf files that are used to verify the decoder. They are as close to "official samples" as exist right now.

Tommy Carrot

20th July 2018, 23:47

New upload:

AOM v1.0.0-181-g3bffe09a5 (https://www.mediafire.com/file/by73glqlyag4ya7/aom_v1.0.0-181-g3bffe09a5.7z)
:thanks:

vidschlub

23rd July 2018, 01:33

How long do people think till we start seeing files encoded with this on the web, even from the hardcore crazy people (anime)

I'm going to assume at least 12 months?

Tommy Carrot

23rd July 2018, 12:45

Well, the encoder has gotten 2-3 times faster in the last 4 months. It still needs to be at least 50-100 times faster to be anywhere near being usable as an encoder. Maybe they pick up the pace now that the bitstream is finalized, but i'd say it will probably take more than 12 months.

v0lt

23rd July 2018, 13:46

It still needs to be at least 50-100 times faster to be anywhere near being usable as an encoder.
You are an optimist. According to my calculations, the codec needs to be accelerated 1000 times.

Tommy Carrot

23rd July 2018, 14:31

excellentswordfight

23rd July 2018, 17:07

Lol, i try to be realist. ;) AV1 is a much more complex codec than VP9 or h.265, so i can accept that it will be slower. 1 fps at 720p for the veryslow preset equivalent would be acceptable to me (assuming no serious quality degradation of course). Although you're right, that'd need probably more than 100x improvement.
This got me curious, is that for private use? If so what is the use case for a encoder that slow? Cant be for storage space, even if bitrates were noticeably lower in 720p than x265, it would be so slow that it would take you an lifetime to fill an 3TB drive at that speed :)

Tommy Carrot

23rd July 2018, 17:45

This got me curious, is that for private use? If so what is the use case for a encoder that slow? Cant be for storage space, bitrates were AV1 would be noticeably better in 720p than x265 would be so low that it would take you an lifetime to fill an 3TB drive at that speed :)

Yes, for private use. To be honest i'm still using x264, because at the crf 18-22 range it's still performing very well, while being lightning fast compared to the newer codecs. Neither x265 nor VP9 are noticeably better (if at all) at that bitrate range. If AV1 can deliver similar quality at a significantly lower bitrate, i might switch to that, because i like to have the best possible quality at the lowest possible bitrate. X265 is simply not better enough to worth the hassle to switch to that (and VP9 is IMO worse than x264 at that bitrate range). I have more than enough storage space, but still, i dont want to have bloated videos if there are better alternatives, and i dont encode that much that i couldn't wait a couple of hours for an encode.

But more importantly, a usable encoder would mean youtube could finally improve the video quality, assuming of course that they dont use the improved efficiency to lower the video bitrates.

user1085

24th July 2018, 01:53

Yes, for private use. To be honest i'm still using x264, because at the crf 18-22 range it's still performing very well, while being lightning fast compared to the newer codecs. Neither x265 nor VP9 are noticeably better (if at all) at that bitrate range. If AV1 can deliver similar quality at a significantly lower bitrate, i might switch to that, because i like to have the best possible quality at the lowest possible bitrate. X265 is simply not better enough to worth the hassle to switch to that (and VP9 is IMO worse than x264 at that bitrate range). I have more than enough storage space, but still, i dont want to have bloated videos if there are better alternatives, and i dont encode that much that i couldn't wait a couple of hours for an encode.

But more importantly, a usable encoder would mean youtube could finally improve the video quality, assuming of course that they dont use the improved efficiency to lower the video bitrates.If you have to encode 4K HDR10 content, then your only option is x265 right?

Blue_MiSfit

24th July 2018, 04:40

Nope, not by a long shot. There's lots of rather good commercial encoding solutions for 4K HDR10 encoding today.

See Beamr, Ittiam, Ateme, etc...

user1085

24th July 2018, 08:14

Nope, not by a long shot. There's lots of rather good commercial encoding solutions for 4K HDR10 encoding today.

See Beamr, Ittiam, Ateme, etc...I meant for my personal collection

Blue_MiSfit

25th July 2018, 00:54

In that case, yeah x265 is likely your best option. There's always the Intel / nVidia encoders, and whatever Adobe has in Adobe Media Encoder (Mainconcept maybe?)

Blue_MiSfit

25th July 2018, 01:05

hbbs

25th July 2018, 03:05

Holy crap guys, the latest Chrome Canary has a significantly improved AV1 decoder. You can play this http://video.1ko.ch/codec-comparison/videos/av1-2018-06_550.webm 1080p test stream using very little CPU.

It didn't work for me on today's canary anyway.

But this sample played on the latest mpv.

Do you have more samples?

hbbs

25th July 2018, 03:52

Firefox Nightly also is playing this demo above.

That's a lot of improvement from the time of that bitmovin demo.

On Firefox Nightly remember to toggle "media.av1.enabled" to true.

Blue_MiSfit

25th July 2018, 18:39

Yeah you need to enable AV1 decoding in the options.

https://www.reddit.com/r/AV1/comments/91gchg/psa_firefox_nightly_and_chrome_canary_can_now/

excellentswordfight

26th July 2018, 08:17

Yeah you need to enable AV1 decoding in the options.

https://www.reddit.com/r/AV1/comments/91gchg/psa_firefox_nightly_and_chrome_canary_can_now/
Is it lag free for you? I'm getting quite a lot of dropped frames. 20% ish usage on all cores, i7-7500U.

clsid

26th July 2018, 14:05

The video itself is just laggy and poor quality. I have it working in MPC-HC (private test build). No drops.

Benchmark in GraphStudioNext gives 32fps. It seems to be single threaded by default. Need to check compile options later.

soresu

26th July 2018, 14:29

iwod

26th July 2018, 16:15

I wonder how conducive AV1 is to decoding by GPU OpenCL, certainly seems like the ideal way to go prior to ASIC decoders being integrated into SoC's and GPU's. Presumably some of the hardware input from companies like AMD, nVidia and Intel covered this?

OpenCL isn't silver bullet, copying data between GPU and CPU will likely be expensive for decoding operation.

Gravitator

26th July 2018, 17:26

The video itself is just laggy and poor quality. I have it working in MPC-HC (private test build). No drops.

Timing to the open version?
Park_Joy will bring to the clean water all the PR of the next-gen video format. :)

Blue_MiSfit

26th July 2018, 19:42

I see only about 5% CPU usage on my i7 6700k. Upon reviewing a bit more there are some frame drops happening, so there's still work to do here for sure.

The quality is rough, but it's 500 Kbps, so quite impressive TBH.

Nintendo Maniac 64

26th July 2018, 23:52

OpenCL isn't silver bullet, copying data between GPU and CPU will likely be expensive for decoding operation.

Weren't those expensive memory copying operations exactly what AMD's HSA and hUMA were supposed to solve?

I realize that, back when HSA and hUMA were introduced, AMD only had APUs using the sub-par "Bulldozer" architecture and its evolutions - this meant there wasn't exactly much interest in tailoring software towards AMD CPUs at the time, but Ryzen is definitely a completely different beast.

Now obviously this would only work on Ryzen APUs, but that's not exactly an issue on laptops when all mobile Ryzen chips are APUs anyway (not counting those uber-performance laptops that use a full-fat AM4 desktop Ryzen CPU). Besides, I would imagine that most non-APU Ryzen processors could at least "brute-force" their way via the abundance of CPU cores and threads to decode the video stream (assuming that AV1 decoding could be made to take advantage of that many threads).

...of course, this assumes that Ryzen APUs even support HSA and hUMA. I mean, AMD hasn't mentioned anything about them for a while now, so who knows?

EDIT: I was reading through some of the older posts in this thread and I just had to respond to this:
I'm sorry, tell us again about how this codec isn't designed for your 20-year-old Pentium 4. That has nothing to do with optimizability under AVX/AVX2 or Altivec, which are the only instruction sets that matter today.

The first Pentium 4 was released in late 2000, but those were the lame Willamette models that needed RDRAM. Much more popular were the Northwood models that supported DDR memory, but those didn't come out until early 2002.

So no, not 20 years ago.

And AVX isn't supported on even the newest Sky/Kaby/Coffee Lake-based Pentium and Celeron CPUs either (and no, I don't mean the low-power Atom-based Celerons & Pentiums), including the ever-popular 2c/4t Pentium CPUs like the G4560 and G5400.

mzso

27th July 2018, 12:13

Weren't those expensive memory copying operations exactly what AMD's HSA and hUMA were supposed to solve?

It did solve it. It's just that no-one bothered using it.

Too bad. If things wen the other way around it could have opened up a bunch of algorithms to use together. Intel (ARM) would have been forced to follow and we might have some pretty cool stuff by now. Maybe we'd be at a brink of two layer CPU+GPU APUs.

IgorC

27th July 2018, 18:35

Holy crap guys, the latest Chrome Canary has a significantly improved AV1 decoder. You can play this http://video.1ko.ch/codec-comparison/videos/av1-2018-06_550.webm 1080p test stream using very little CPU.
Thank you for the video.

Slow motion parts have very good quality (considering it's 1080p@550k). However high motion moment is looking ugly. :mad:
Rate-control isn't well tuned, I guess.

Nintendo Maniac 64

27th July 2018, 20:20

It did solve it. It's just that no-one bothered using it.

That's why I mentioned the whole "Bulldozer was a bit sub-par", because as Itanium proved, devs aren't really going to develop for something that's fast at new things if it's also a complete dog at old things.

And that's also why I mentioned Ryzen, because it's totally not a dog at all, and those Ryzen APUs are arguably even more competitive in mobile (at least if you ignore those 6core Intel parts, but I would be very surprised if mobile Zen2-based APUs weren't also sporting at least 6 cores).

But again, I have literally no idea if Ryzen APUs support HSA and hUMA, and I've even tried researching the subject.

If there's any consolation, I imagine that any future AMD-powered console would support this functionality, and heck even Intel's renewed focus on graphics may result in something similar in the future.

Barough

28th July 2018, 12:02

AOM AV1 v1.0.0-245-ge4d148435 (http://www.mediafire.com/file/vblp969d4whc5p0/)
Built on July 28, 2018, GCC 7.3.0

https://aomedia.googlesource.com/aom

utack

29th July 2018, 00:47

Is it just me, or is the tuning of libaom stil way off?
It completely murders some darker and "flat" areas, where x265 retains a lot of detail
Example (especially bottom right, from a 30s clip, same bitrate):
http://screenshotcomparison.com/comparison/117597

Is there some optimization coming, that takes human perception into consideration and distributes bitrate accordingly?

Tommy Carrot

29th July 2018, 01:18

foxyshadis

29th July 2018, 06:35

Any codec that smooths that much is obviously PSNR-tuned.

It was funny waking up this morning and seeing Monty log on to the IRC channel with, "'mornin. How close are we to 1.0?" Crackin' the whip.

mandarinka

29th July 2018, 13:50

And AVX isn't supported on even the newest Sky/Kaby/Coffee Lake-based Pentium and Celeron CPUs either (and no, I don't mean the low-power Atom-based Celerons & Pentiums), including the ever-popular 2c/4t Pentium CPUs like the G4560 and G5400.

Very important point. I actually found that some multimedia devs weren't aware of this in the past, thinking they only need to write AVX2 now. It's rather unfortunate that Intel insists on this.

The Atom cores matter too though, IMHO. There is a huge number of devices with them and they actually improve a lot currently (Goldmont, Goldmont+), much more than Intel big cores. Yet they still keep only 128bit SIMD (SSE-SSE4) so it would really be good if the devs of important format's decoders took time to implement SSE* functions and not just AVX2 ones. After all, there is also a huge number of fast CPUs that don't have AVX2, like Sandy/Ivy Bridge CPUs a la i5-2500/2400 or i7-2600K.

---------------------------
Hmm, BTW. Are there some good estimates as to what CPU will be needed for comfortable decoding of 4K content (24 - 30 fps) in AV1 with all bells and whistles of the format used? (10bit etc, all the compression tools on, high bitrates including spikes in motion, VBR with no streaming-style constraints...). With some sane headroom.

Jamaika

29th July 2018, 15:30

Yet they still keep only 128bit SIMD (SSE-SSE4) so it would really be good if the devs of important format's decoders took time to implement SSE* functions and not just AVX2 ones. After all, there is also a huge number of fast CPUs that don't have AVX2, like Sandy/Ivy Bridge CPUs a la i5-2500/2400 or i7-2600K.
Little real. The creators of the new JPEG codecs google or dropbox aren't interested in prehistory. :(

Nintendo Maniac 64

29th July 2018, 20:43

prehistory

This is why I focused on the newest Pentiums like the G5400 - one can't use the "old" argument if they're literally the newest generation of Pentiums available.

Jamaika

29th July 2018, 21:34

mzso

29th July 2018, 21:45

I don't think it has any visual tuning yet, it's only being tuned for a variety of metrics. Also, AV1 uses golden frames (imho a bad legacy from vp9), so the frame quality varies quite considerably, so judging individual frames are not necessarily an accurate way to compare quality.

I believe someone explained before that the golden frame was kept consciously, and that it's no is not only not a disadvantage, but on the contrary it allows to do some stuff that otherwise wouldn't be possible.

Tommy Carrot

30th July 2018, 12:08

I believe someone explained before that the golden frame was kept consciously, and that it's no is not only not a disadvantage, but on the contrary it allows to do some stuff that otherwise wouldn't be possible.
Maybe so, but it definitely has some disadvantages too. Golden frames are very noticeably higher quality than the rest of the frames, so they can cause uneven, fluctuating quality (the finer details are vanishing and coming back periodically). This can be rather distracting if you start noticing this tendency.

Granted, AV1 is much better in this regard than VP9, but this issue is still there.

LigH

30th July 2018, 13:27

Well, "B-frame pumping" already existed in MPEG-2 times. Very noticeable in the "Animatrix" DVD. May just be a matter of tuning?

iwod

30th July 2018, 13:51

Off top:
For me, a poor man and an enthusiast, let's say novelties, in Central Europe the computer ages after five years. Then the computer for free throws into the bucket and begins the path of cost-effective recycling to Asia. For me, an inconceivable fact.
I remember the times when Intel's new processors debuted on the market every two weeks. It was a market. The world is changing and for sure it isn't an era of Intel.
https://pclab.pl/zdjecia/artykuly/blind/2015/03/skylake/intel2.PNGhttps://www.fudzilla.com/images/stories/2016/April/intel-avx-512.jpg
https://linustechtips.com/main/topic/379471-intels-skylake-cpus-for-pcs-wont-support-avx-512-aka-avx3/

Or you mean every two years?

And as said before Skylake or whatever lake Intel has, has little to do with AVX support. All the Pentium / Celeron CPU don't support AVX, even thought they are Skylake +.

We only have to wait a few more years. We finally have a decent alternative to Intel x86.

Tommy Carrot

30th July 2018, 13:53

Well, "B-frame pumping" already existed in MPEG-2 times.
The effect is similar, but with a bigger gap. The b-frame thing occured in every 3rd frame or so, the golden frame boost happens in every 16th or so frame, and with a way higher quality boost. These factors make the ""pumping" effect more apparent. It could be tuned to be less noticeable, but that would worsen the metrics, so i doubt they would consider it.

mzso

30th July 2018, 15:11

Maybe so, but it definitely has some disadvantages too. Golden frames are very noticeably higher quality than the rest of the frames, so they can cause uneven, fluctuating quality (the finer details are vanishing and coming back periodically). This can be rather distracting if you start noticing this tendency.

Granted, AV1 is much better in this regard than VP9, but this issue is still there.

Actually I noticed this phenomenon with (rather poor) AVC videos before, from twitch I think. Don't remember noticing it with VP9 stuff.

mzso

30th July 2018, 15:13

We finally have a decent alternative to Intel x86.

Oh? What is that?

RussianNeuroMancer

30th July 2018, 15:21

But again, I have literally no idea if Ryzen APUs support HSA and hUMA, and I've even tried researching the subject.Not supported (http://rocm-documentation.readthedocs.io/en/latest/Installation_Guide/Installation-Guide.html)AMD Raven Ridge APU are currently not supported

A little bit of history on HSA topic: post 1 (https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/amd-linux/1025112-amd-will-continue-maintaining-multiple-compute-stacks-for-linux?p=1025309#post1025309), post 2 (https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/amd-linux/1034534-amdkfd-looking-to-be-merged-into-amdgpu-linux-drm-kernel-driver?p=1034729#post1034729), post 3 (https://github.com/RadeonOpenCompute/ROCm/issues/132#issuecomment-312926987) (John Bridgman is AMD HSA Linux architect).

In conclusion, I believe what industry possibly need in the future is AV1 decoder implementation on Vulkan compute, that will work on ARM and Intel-based devices too (in contrary to HSA implementation). However, I think that GPU hybrid implementations will quickly sunset such efforts (attempts to implement AV1 decoder on OpenCL, Vulkan, CUDA, etc.) and make them obsolete. Eventually hybrid implementations will be replaced by more complete hardware solutions, while legacy devices will continue to decode either AV1 on CPU or recieve VP9 or H264 stream for decoding on GPU, exactly as they do now. We seen how this play out with H264->VP9 transition and I don't think this time may be different.

LigH

30th July 2018, 21:45

The b-frame thing occured in every 3rd frame or so...

Then I used the wrong term; let's call it "GOP pumping" instead. DVD GOPs usually have a duration of half a second. And some MPEG-2 (hardware?) encoders prefer the I frame over all the following P and B frames with finer quantization. This effect was quite similar to your Golden Frame issue.

Tommy Carrot

30th July 2018, 22:17

Then I used the wrong term; let's call it "GOP pumping" instead. DVD GOPs usually have a duration of half a second. And some MPEG-2 (hardware?) encoders prefer the I frame over all the following P and B frames with finer quantization. This effect was quite similar to your Golden Frame issue.
Ah, gotcha. Indeed, it's very similar, especially in VP9 (mzso, watch something hard to compress on youtube, like fast moving gameplay footage, or something with a lot of foliage, you'll see). It's much more subtle in AV1, but still noticeable in some cases.

foxyshadis

31st July 2018, 04:33

Oh? What is that?

ARM64 is a darling in some circles, but it's hardly perfect, and it's even more segmented than the x64 market. You can't get AVC on some x64, but you can't be guaranteed NEON at all (which is like saying you can't get MMX/SSE) on some ARM64. That market is weird. It's also having serious scale-up issues, like everyone else who tries to make silicon go fast.

Xeon Phi has its diehards, but the SPARC route of lots of intermediate-powered chips hasn't set the world on fire. Intel appears to be abandoning the Knights platform, and moving toward doing things with superfast flash (Optane) mixed into a mesh of micro-CPUs. We'll see if that pans out any better.

And then, of course, there's GPU. There are people out there who want to ditch the CPU entirely for the GPU, or at least give it an even larger role than it already grabs in today's computing. There's a metric buttload of research on this, everything from new languages to on-the-fly recompiling x86 code into shaders that can run massively parallel, but the current hybrid solution is the current solution for a reason. It works, it's cheap, and it's accessible. Vulcan, OpenCL, and CUDA have proven to be powerful glue languages that specialize in what they can do very well, and fall over when asked to compute loops with side effects. Toss in a chip to do that processing faster, and hey, you have an underpowered CPU in the middle of your GPU! Like fixed-function video decoders, though, the case may be that such a thing could evolve and slowly push out the overkill system CPU, absorbing the CPU into the GPU instead of vice versa (or most likely, both in parallel). It doesn't take a genius to understand that if SIMD width keeps doubling, you're basically starting to process textures. As long as gamers and coin miners keep buying wildly overpowered GPUs for overspecced monitors, though, the state of the art will keep being advanced.

Oh, and quantum computing. Google's Bristlecone set a fire in the breasts of many a nerd, but we're probably almost a decade off from getting any derivative in an average joe's hand, even by cloud computing. Researchers are going to be grappling with what the hell to do with these for decades. Some brilliant folks are going to have their name immortalized in the coming years, but quantum has only just graduated from "nuclear fusion" territory.

foxyshadis

31st July 2018, 04:47

I believe someone explained before that the golden frame was kept consciously, and that it's no is not only not a disadvantage, but on the contrary it allows to do some stuff that otherwise wouldn't be possible.

Golden frames are technically superior to ref-frames in every way. It's just that no one's actually taken advantage of that superiority, just like as far as I know no one has taken advantage of long-refs in HEVC to minimize the impact of scenecuts, especially repeated scenecuts. The reduced refs HEVC gives you does take some of that flexibility away though.

LigH

31st July 2018, 15:44

New upload:

AOM v1.0.0-262-gbc484c485 (https://www.mediafire.com/file/miotmxp7csnsfav/aom_v1.0.0-262-gbc484c485.7z)

IgorC

1st August 2018, 01:01

rav1e is just on early stage of development
https://twitter.com/fg118942/status/1022425990276952064
https://pbs.twimg.com/media/DjBi2mdU8AEq8wv.png

MoSal

1st August 2018, 01:50

rav1e is just on early stage of development

It is. It's not even compatible with the final AV1 spec yet (getting close). And some encoding tools are not implemented or optimized for quality yet.

The encoder will be immediately interesting for its speed. The quality will (hopefully) come later. And by quality, I mean subjective quality.

marcomsousa

1st August 2018, 10:02

I'm trill by this new video codec (AV1), but also with the image (av1-avif (https://aomediacodec.github.io/av1-avif/)) brought by the same Alliance.
This AVIF image codec it's better that WebP.

You can compare the image AV1-AVIF with other formats here (http://wyohknott.github.io/image-formats-comparison/#abandonned-factory). (Select the AV1-2018 version)
You can also compare the video AV1 with other formats here (https://wyohknott.github.io/video-formats-comparison/).

It's very good that it begins new implementation of AV1, but how an encoder (rav1e) can make this statement?
The fastest and safest AV1 encoder.
If it's on early stage, is experimental, and not caught up with the release version.

About the AV1 roadmap
We just complete phase 1.
In 1 year we complete phase 2.
In 2 to 3 years we complete phase 3.
In 4 to 5 years we complete phase 4.

https://forum.doom9.org/attachment.php?attachmentid=16445&stc=1&d=1533115434

nevcairiel

1st August 2018, 10:16

Its safe because its written in Rust, which has fundamental type and memory safety built-in.

Nintendo Maniac 64

1st August 2018, 21:18

Not supported (http://rocm-documentation.readthedocs.io/en/latest/Installation_Guide/Installation-Guide.html)

ROCm is actually something different from HSA/hUMA as you can see that it also lists "Carrizo" APUs as 'Not Supported' even though Carrizo was in fact the first APU with full HSA/hUMA support (AMD would advertise Kaveri, the gen before, as only having "HSA features").

The additional transistor budget also allows Carrizo to become the first processor in the industry designed to be compliant with the HSA 1.0 specification developed by the HSA Foundation.

----------------------------------------------------------------

We finally have a decent alternative to Intel x86.
Oh? What is that?
ARM64 is a darling in some circles...And then, of course, there's GPU.

I'd just like to point out that all Ryzen processors support AVX2, and this even includes the lowly Ryzen 3 2200U and Ryzen Embedded V1000 (both of which are 2core/4thread parts much like their Pentium equivalents). I'm not sure how much Doom9-ers keep up with PC hardware news, but Intel has made a major fumble with their 10nm node which has left the door wide open for AMD's Zen2 + 7nm architecture to quite possibly clean house next year.

And of course, most of the lower core-count Ryzen parts (4c/8t and less) also have a relatively powerful iGPU as well (there's only a few 4core Ryzen parts that lack an iGPU, and they're all on desktop anyway).

Also, technically this isn't a "finally" as AMD was very competitive with Intel in the first half of the 2000s (Athlon XP to Athlon 64 x2) as well as with the late 2000's Phenom II parts (particularly the Phenom II x6). It's only been since 2011 with Intel's release of Sandy Bridge and AMD's "Faildozer" that Intel became so absolutely dominant in the CPU space.

...unless you were talking about the ISA of x86, in which case you can largely ignore everything I just said. :P It is worth pointing out though that 64bit x86 (that is, "x86-64") is actually an AMD creation and therefore both Intel and AMD cross-license with each-other.

But in other non-x86 related news, both AMD and Nvidia not only make ARM CPUs but are also part of the RISC-V Foundation.

benwaggoner

2nd August 2018, 19:04

It is. It's not even compatible with the final AV1 spec yet (getting close). And some encoding tools are not implemented or optimized for quality yet.
No encoding tools are well optimized for quality yet! HEVC is several years older and is still seeing substantial year-on-year perceptual quality improvements. I'm estimating we're 1+ year away from a "reasonably good" AV1 encoder, based on past encoder development.

For example, all the strobing concerns mentioned above. That's not an issue in the bitstream format at all, just about encoder implementation. It'll get addressed with better psychovisual tuning via adaptive quantization.

FWIW, my read on Golden Frames is that it started as an alternative way to get some of the advantages of b-frames and multiple reference frames while staying clear of IP around those technologies.

MoSal

2nd August 2018, 19:57

No encoding tools are well optimized for quality yet!

What I meant was, they are not finished with rudimentary implementations of the basic tools necessary to produce a compatible bitstream yet. There are a lot of things to do before they can even start caring about competitive quality.

Quikee

2nd August 2018, 22:42

No encoding tools are well optimized for quality yet!

Right, but there is --tune=psychovisual option already, which enables optimizations that improve visual and hurt metrics (using cdef-dist for RDO), but this was already implemented for libaom.

OTOH it doesn't even have inter prediction yet, which is the reason it performs so badly.

hajj_3

3rd August 2018, 12:15

Chrome 69 Beta has been released with support for decoding AV1.

birdie

4th August 2018, 10:06

Chrome 69 Beta has been released with support for decoding AV1.

Firefox 63 as well.

mandarinka

4th August 2018, 20:34

I believe someone explained before that the golden frame was kept consciously, and that it's no is not only not a disadvantage, but on the contrary it allows to do some stuff that otherwise wouldn't be possible.

Golden frame was the goto thing they could point at when they wanted to pretend VP8/9/... is a result of an extensive independent research and novel ideas of On2's and not just a crippled H.264/HEVC copy with some arbitrary changes and mangling made so that it is harder to sue. :devil: When your competitor makes everything in the open and drafts are available years in advance...

dapperdan

5th August 2018, 07:55

Golden frame was the goto thing they could point at when they wanted to pretend VP8/9/... is a result of an extensive independent research and novel ideas of On2's and not just a crippled H.264/HEVC copy with some arbitrary changes and mangling made so that it is harder to sue. :devil: When your competitor makes everything in the open and drafts are available years in advance...

Live by the patent, die by the patent.

If your entire business model is based on the public granting you property rights over a specific bit of mathematics in return for publishing the exact limits of your property, it's a little bit churlish to complain that the public makes use of that information. If that deal didn't suit then they shouldn't have taken it.

mandarinka

7th August 2018, 02:04

I don't buy the "it's only math" as an argument that video compression technology is simple and should not be patentable.

Everything is obvious in hindsight/to laymen, but to get to that hindsight situation is the hard part. MPEG/VCEG circles brought amazing video technology forward, if you recall how bad the codecs were say in 2004 (and those were already things brought forward by them and those were already great progress above truly stone age tech).

As in many fields and situations, people take all good things for granted, ignore their value and endlessly bitch about some trifling small details they find on them to complain about. (Yes, the neverending rants about licensing and royalty-free/encumberedness broken record, I consider that unimportant in the overall scope of video compression progress - to be clear.)

mzso

7th August 2018, 07:44

Blue_MiSfit

8th August 2018, 00:53

Let's not go down this rabbit hole, please :) Let's keep discussion on AV1.

IgorC

8th August 2018, 23:34

I apologize for an offtopic.
if you recall how bad the codecs were say in 2004
Ateme H.264 encoder was already state of the art with an excelent physocvisual model in 2004. It took x264 some long time to reach that quality.

LigH

9th August 2018, 15:03

New upload:

AOM v1.0.0-359-g1bc580401 (https://www.mediafire.com/file/f1b2sm00ydtglcx/aom_v1.0.0-359-g1bc580401.7z) (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0)

Tommy Carrot

9th August 2018, 16:56

:thanks:

The latest build crashes at the third frame in each attempt, no matter what settings i try. Anyone else have this happening? The 32 bit version works fine, so i dont know if it's because some bug in the code, or because of the new GCC.

LigH

10th August 2018, 07:36

Confirming on an AMD FX-6300. First pass passes; second pass gives an APPCRASH: Exception at 0x00000000004D3B68 in aomenc.exe: 0xC0000005: Access violation while reading at address 0x0000000000000000

A kind of "over-optimization" bug in GCC 8.2.0 is quite probable, IMHO. I wonder where to discuss it best. Will use the good old IRC for a while.
_

P.S.: There is a channel #aomedia on Freenode; I wonder why it is missing in the server's channel list, though... — Probably to avoid spam bots.
_

P.P.S.: It's probably an issue with the auto-vectorization (https://bugs.chromium.org/p/aomedia/issues/detail?id=2055). Let's see whether Alexpux can downgrade or upgrade GCC in MSYS2...

LigH

12th August 2018, 19:35

The issue has been analyzed down to a disassembly proving that Tree SLP Vectorization may produce undesired unaligned memory access, causing a segmentation fault.

There is a temporary patch proposed which rearranges some code to avoid this misalignment. Furthermore, I tried to notify the GCC developers of this issue. So until GCC 8 got fixed, aomedia may try to circumvent it sooner.

LigH

17th August 2018, 14:46

New upload:

AOM v1.0.0-399-g427b0382d (https://www.mediafire.com/file/bf4jtrfep9gc9k3/aom_v1.0.0-399-g427b0382d_noVO.7z) (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0; -fno-tree-slp-vectorize)
_

I have no experience creating a real .diff file; but if you want to do the same in MABS, a snippet for build/media-suite_compile.sh would look like:

if { [[ $aom = y ]] || { [[ $ffmpeg != "no" ]] && enabled libaom; }; } &&
do_vcs https://aomedia.googlesource.com/aom; then
- extracommands=()
+ extracommands=(-DAOM_EXTRA_C_FLAGS="-fno-tree-slp-vectorize" -DAOM_EXTRA_CXX_FLAGS="-fno-tree-slp-vectorize")
[[ -n $_aom_bins ]] && _check+=(bin-video/aomdec.exe) ||
extracommands+=(-DENABLE_EXAMPLES=off)

It could possibly be optimized to include these extra flags only in the 64 bit branch.

Tommy Carrot

17th August 2018, 18:23

Thanks for the new build, and for finding out what went wrong with the previous. No crashes so far, and while it's still very slow, the encoding speed is getting a bit better (though the quality has regressed a bit in some cases compared to the earlier builds).

I tinkered around with rav1e (the other av1 encoder) a bit too. It's definitely in a much earlier stage of development, it's still missing way too many features to have acceptable quality. But at least it produces valid bitstream.

TD-Linux

18th August 2018, 04:01

rav1e now has automatic Windows builds via Appveyor. To get the latest build, go to this page:

https://ci.appveyor.com/project/tdaede/rav1e/history

Click the latest build labeled with "master", then click Artifacts to download the executable. I'll wire up a better interface for some at this point.

Keep in mind that rav1e is still incomplete, lacking features such as motion compensation, so you should not expect good compression performance. However, it is much faster than libaom and is useful for generating long AV1 test sequences.

Selur

18th August 2018, 15:20

@TD-Linux: does rav1e support y4m input via pipe?

TD-Linux

18th August 2018, 20:40

Yes it does - just use a "-" to indicate pipe. You can also output ivf via a pipe. For example:

ffmpeg -i file.webm -f yuv4mpegpipe - | rav1e - -o file.ivf

olduser217

21st August 2018, 13:17

Hi guys, does the bit distribution of AV1 similar to VP9?

For VP9 4k bitstream in Youtube, according to requirement from Youtube, the decoder needs to support up to 65-frame decoding frame rate for 60-frame display frame rate, where there are up to 5-frame decoded without display.
These non-display frames are normally acting as ALTREF frame for the decoding of frames decoded after it, and they are normally being allocated with lot of bits compare to other inter frames (more than 10 times) which will be displayed.

Netflix VP9 bitstreams seem like having such bit distribution too.

Does the same happen to AV1?

v0lt

21st August 2018, 16:50

TD-Linux

22nd August 2018, 01:28

For VP9 4k bitstream in Youtube, according to requirement from Youtube, the decoder needs to support up to 65-frame decoding frame rate for 60-frame display frame rate, where there are up to 5-frame decoded without display.
These non-display frames are normally acting as ALTREF frame for the decoding of frames decoded after it, and they are normally being allocated with lot of bits compare to other inter frames (more than 10 times) which will be displayed.

Netflix VP9 bitstreams seem like having such bit distribution too.

Does the same happen to AV1?

Yes, see section A.3 of the spec. MaxDisplayRate and MaxDecodeRate are different, with MaxDecodeRate being higher. Note that this is more flexible than VP9 - if you are at a lower resolution or frame rate, you can use more non-shown frames. There is also a maximum header rate defined separately.

olduser217

22nd August 2018, 01:32

Where did you get this very questionable information?

https://sites.google.com/a/google.com/youtube-leanback-partners/evaluation/2019-technical-requirements?pli=1

You probably need to join the group to access it.

You can simply download a 4k 60fps VP9 bitstream from Youtube to check the existence of such non-display frames (show_frame == 0), which are added around or close to the frequency mentioned.

olduser217

22nd August 2018, 01:46

Yes, see section A.3 of the spec. MaxDisplayRate and MaxDecodeRate are different, with MaxDecodeRate being higher. Note that this is more flexible than VP9 - if you are at a lower resolution or frame rate, you can use more non-shown frames. There is also a maximum header rate defined separately.

Yes, noticed about this too.
So, for Level 5.1 of AV1 (seems like suitable for 4k60), the maximum decode frame rate for 3840x2160 equals to:
= MaxDecodeRate/3840x2160
= 547,430,400 / 3840x2160
= 66fps

So, the frame rate for decoding is quite similar to VP9 (at least for Youtube case).

Just curious whether the bit distribution of AV1 is similar as VP9 too, i.e. the non-display inter frames are being allocated with much higher bits (more than 10 times) compared to the displayed inter frames.
This seems like not mentioned in the AV1 specification.

Blue_MiSfit

22nd August 2018, 21:02

Just curious whether the bit distribution of AV1 is similar as VP9 too, i.e. the non-display inter frames are being allocated with much higher bits (more than 10 times) compared to the displayed inter frames.
This seems like not mentioned in the AV1 specification.

Wouldn't this behavior be a result of encoder implementation, and not have anything to do with the bitstream specs?

benwaggoner

22nd August 2018, 22:01

Wouldn't this behavior be a result of encoder implementation, and not have anything to do with the bitstream specs?

Yeah, that would be my assumption as well.

Using WAY more bits on non-visible Intra frames than intra frames seems pathological. Unless there’s some reason why the displayed frame is just one big skip block of the golden frame or something. It would be interesting to look at the per-frame allocation with/without non-display frames on. I’d guess that having only visible intra frames would result in having a lot larger intra frames.

Is there any good data on the efficiency improvements from golden & non-visible intra frames?

Sent from my iPad using Tapatalk

olduser217

23rd August 2018, 10:29

Wouldn't this behavior be a result of encoder implementation, and not have anything to do with the bitstream specs?

Yes, this definitely about the encoder implementation rather than specification/standard.
However, since both Youtube and Neflix VP9 bitstreams show similar bit distribution pattern, just wondering whether the same will happen to AV1.

olduser217

23rd August 2018, 11:03

Yeah, that would be my assumption as well.

Using WAY more bits on non-visible Intra frames than intra frames seems pathological. Unless thereÂ’s some reason why the displayed frame is just one big skip block of the golden frame or something. It would be interesting to look at the per-frame allocation with/without non-display frames on. IÂ’d guess that having only visible intra frames would result in having a lot larger intra frames.

Is there any good data on the efficiency improvements from golden & non-visible intra frames?

Sent from my iPad using Tapatalk

The non-display frames (invisible frames) are actually inter frames. The bit allocated for each of these non-display inter frames are still less than the Key frame (but much higher than other displayed inter frame).

Take the example decoding order of VP9 bitstream below:
I0 NP0 P0 P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12

I0 is the Key frame, NP0 is the non-display inter frame and Pn are the displayed inter frames.

The display order is:
I0 P0 P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12

NP0 is actually encoded using the same input frame to encode P12.
In the sequence above, I0 is always used as the GOLDEN frame, NP0 always the ALTREF frame and the last decoded frame as the LAST FRAME.

This NP0 is actually encoded mainly for backward prediction in bi-directional prediction.

marcomsousa

23rd August 2018, 13:25

AV1 will be disable in Chome 69.

AV1 is not ready. Disable it on the M69 branch.

https://chromium.googlesource.com/chromium/src.git/+/3416497c874e5f121ade527e6796192818654436

v0lt

25th August 2018, 13:57

NP0 is actually encoded using the same input frame to encode P12.
In the sequence above, I0 is always used as the GOLDEN frame, NP0 always the ALTREF frame and the last decoded frame as the LAST FRAME.

This NP0 is actually encoded mainly for backward prediction in bi-directional prediction.
It's wrong to call the frame. This is additional information for the GOP sequence. It could simply be added to the first frame and you would not have to invent the unseen frames.

IgorC

26th August 2018, 17:22

rav1e improves quite fast
https://twitter.com/fg118942/status/1033280738869706752

https://pbs.twimg.com/media/DlbzTq4U0AEWcuB.png

mzso

26th August 2018, 18:48

rav1e improves quite fast
https://twitter.com/fg118942/status/1033280738869706752

https://pbs.twimg.com/media/DlbzTq4U0AEWcuB.png

So now it has motion compensation. It's still a fair bit worse than x264, what other basic features might be missing?

I suppose you don't happen to have a graph on speed improvement?

Rumbah

26th August 2018, 21:04

It's still a fair worse than x264, what other basic features might be missing?I think it's still intra only.

fg118942

26th August 2018, 22:28

I use google translation.

I created not only the graph but also uploaded the encoded image to imgur.
https://imgur.com/a/ifs2bn3

Also rav1e is still late, it takes over an hour to convert 1080p 375 frames of movies.

Tommy Carrot

26th August 2018, 22:31

I think it's still intra only.
Nah, it definitely has inter frames, and some basic motion compensation. It doesnt have deblocking filter, b-frames and many other features yet, and the quality is not very good, but it has improved a lot in the last few days. The encoding speed is getting slower though, in the slower speed settings it's getting close to aomenc level, and they still need to keep adding a lot of new features to the encoder.

olduser217

27th August 2018, 04:14

It's wrong to call the frame. This is additional information for the GOP sequence. It could simply be added to the first frame and you would not have to invent the unseen frames.

Hi, what do you mean by "It's wrong to call the frame"?
This is NOT just simply an "additional information for the GOP sequence". The data of the non-display frame is there and the decoder has to spend time to decode that like a normal frame, except it doesn't display it.

And what do you mean by "It could simply be added to the first frame"?
I didn't invent the frame, it was encoded by VP9 encoder of libvpx.

v0lt

27th August 2018, 04:20

This is NOT just simply an "additional information for the GOP sequence". The data of the non-display frame is there and the decoder has to spend time to decode that like a normal frame, except it doesn't display it.
This is additional information for the GOP sequence that needs to be decoded. Calling it frames is wrong.

v0lt

27th August 2018, 04:31

I have a problem with the rav1e encoder. The resulting IVF files play poorly in ffplay and mpv. I can not convert these frames to MKV using ffmpeg or mkvtoolnix.
My IVF AV1 files (https://cloud.mail.ru/home/AV1/).

Mosu

27th August 2018, 06:47

The mapping for AV1 in Matroska hasn't been finalized yet. Therefore you cannot convert IVF to Matroska, and even if you could, the resulting files would be invalid.

LigH

27th August 2018, 07:42

Hi, what do you mean by "It's wrong to call the frame"?

I believe v0lt dropped an 'm': "It's wrong to call them frame".

And as we are just discussing little details:

Besides WebM and IVF (funny to discover it is based on a legacy container known as "Indeo Video Format"), aomenc also can create "OBU" (Open Bitstream Units); am I right that this format is more similar to the one of raw AVC?

olduser217

27th August 2018, 08:02

This is additional information for the GOP sequence that needs to be decoded. Calling it frames is wrong.

I do not agree about this.
Even though these frames are not going to be displayed, they definitely need to be decoded as a frame, stored and take up memory space of a frame in the decoded picture buffer as a reference frame for future frame decoding.

Even the requirement of Youtube mentions that the decoding frame rate can be higher than displaying frame rate, which implying that these "additional information" are exact frame(s).

Anyway, there is no point arguing about this, if your implementation can ignore the performance required to encode/decode these "additional information".

nevcairiel

27th August 2018, 10:02

Besides WebM and IVF (funny to discover it is based on a legacy container known as "Indeo Video Format"), aomenc also can create "OBU" (Open Bitstream Units); am I right that this format is more similar to the one of raw AVC?

OBU is the AV1 name for "NALU" (ie. the generic name for every high level element of a bitstream), it does not indicate a specific storage format. You cannot really store AV1 without a container, much like VP9. Thats why IVF exists, an extremely no-frills container serving as a "raw" format, since pure "raw" is not something you should do.

Mosu

27th August 2018, 10:18

Besides WebM and IVF (funny to discover it is based on a legacy container known as "Indeo Video Format"), aomenc also can create…

Just to make this very clear: the WebM aomenc produces is not valid. As I said before, the mapping for AV1 in Matroska & WebM hasn't been finalized yet, and what aomenc produces is definitely not going to be what the specs will say how it should be.

Aleksoid1978

27th August 2018, 11:26

Hello all. Can somebody build static .lib(for me need only AV1 decoder) x86/x64 version.
I want try add to MPC-BE/ffmpeg library.

clsid

27th August 2018, 13:06

I previously used this for mingw build of decoder lib:
rm -rf CmakeCache.txt CMakeFiles
cmake.exe ..\aom -G "MSYS Makefiles" -DCMAKE_AR="C:\msys64\mingw64\bin\x86_64-w64-mingw32-gcc-ar.exe" -DCMAKE_TOOLCHAIN_FILE="..\aom\build\cmake\toolchains\x86_64-mingw-gcc.cmake" -DCONFIG_LOWBITDEPTH=1 -DCONFIG_AV1_ENCODER=0 -DCONFIG_LIBYUV=0 -DCONFIG_WEBM_IO=0 -DENABLE_DOCS=0 -DENABLE_EXAMPLES=0 -DENABLE_TOOLS=0 -DENABLE_TESTS=0 -DENABLE_TESTDATA=0
make
But imho it is too early to include in the player. There is not even (demo) content available yet.

Aleksoid1978

27th August 2018, 13:43

I try - but cmake show me error about avx2 and exit. Maybe it's because my CPU don't support AVX2.

clsid

27th August 2018, 13:52

Mine doesn't either. Works here with CMake 3.10.2. Haven't tried newer versions.

MoSal

27th August 2018, 15:55

I have a problem with the rav1e encoder. The resulting IVF files play poorly in ffplay and mpv.

rav1e still uses a libaom snapshot from February. That is, the output is not yet compatible with the final AV1 specification.

Edit: this is outdated info.

v0lt

27th August 2018, 16:30

rav1e still uses a libaom snapshot from February. That is, the output is not yet compatible with the final AV1 specification.
This is unexpected for me. I spent a lot of time using it. :(

magistral

27th August 2018, 16:40

rav1e still uses a libaom snapshot from February. That is, the output is not yet compatible with the final AV1 specification.

rav1e has been compliant for almost a month now. See https://github.com/xiph/rav1e/pull/404

MoSal

27th August 2018, 18:13

rav1e has been compliant for almost a month now. See https://github.com/xiph/rav1e/pull/404

Ouch. I was looking at the wrong branch.

IgorC

27th August 2018, 20:08

I suppose you don't happen to have a graph on speed improvement?
No, I don't have it.

See here https://forum.doom9.org/showpost.php?p=1849845&postcount=855

TD-Linux

28th August 2018, 02:31

We have a very experimental option called "--tune psychovisual" that uses a different distortion metric. I'd be interested if anyone wants to compare. It's still relatively untested at the moment.

benwaggoner

28th August 2018, 18:57

rav1e improves quite fast
https://twitter.com/fg118942/status/1033280738869706752
It's interesting the comparison is just versus x264/4 using --preset slower. Even at --preset placebo they'd still be way faster than current AV1 implementations. A fairer comparison versus x265 would look more like:

--preset placebo --subme 7 --cu-lossless --tskip --bframes 16 --no-wpp

Which would still be faster than libaom, and would make more exhaustive use of HEVC's features. At very low bitrates, maybe another 10-15% reduction in bits @ quality versus slower.

Quality @ Speed is the name of the game here, and comparisons at orders of magnitude different speed aren't that applicable to estimating real-world advantages of different bitstream formats.

(not a diss at the OP; that data might have been useful for an internal comparison for just posting to Twitter. I just want to warn against premature optimism based on Excel RD plots).

mandarinka

1st September 2018, 12:40

We have a very experimental option called "--tune psychovisual" that uses a different distortion metric. I'd be interested if anyone wants to compare. It's still relatively untested at the moment.

Most users probably aren't routinely compiling stuff, are there (Windows) builds of Rav1e available from somebody to test with ?

Tommy Carrot

1st September 2018, 15:17

Most users probably aren't routinely compiling stuff, are there (Windows) builds of Rav1e available from somebody to test with ?
Here:
rav1e now has automatic Windows builds via Appveyor. To get the latest build, go to this page:

https://ci.appveyor.com/project/tdaede/rav1e/history

Click the latest build labeled with "master", then click Artifacts to download the executable. I'll wire up a better interface for some at this point.

hajj_3

5th September 2018, 02:26

chrome 69 was supposed to add av1 decoding support (which could be enabled using about:flags) however they removed it a week or so ago. If you were wondering why the newly released v69 didn't have it now you know why. I'm pretty sure it will be in v70, though probably disabled by default.

marcomsousa

5th September 2018, 05:01

chrome 63 was supposed to add av1 decoding support (which could be enabled using about:flags) however they removed it a week or so ago. If you were wondering why the newly released v63 didn't have it now you know why. I'm pretty sure it will be in v64, though probably disabled by default.

Google release today Chrome 69.

Chrome 69 adds an AV1 decoder to Chrome Desktop stable (Windows, Mac, Linux, ChromeOS) based on the official bitstream specification. At this time, support is limited to "Main" profile 0 and does not include encoding capabilities. The supported container is ISO-BMFF (MP4). To enable this feature use the chrome://flags/#enable-av1-decoder flag.
source (https://developers.google.com/web/updates/2018/08/chrome-69-media-updates)

At this moment it's planing be enabled by default in Chrome v70 (https://www.chromestatus.com/features/5729898442260480).

sneaker_ger

5th September 2018, 10:40

I don't have that setting in Chrome 69.0.3497.81 (stable).

mzso

5th September 2018, 10:53

chrome 63 was supposed to add av1 decoding support (which could be enabled using about:flags) however they removed it a week or so ago. If you were wondering why the newly released v63 didn't have it now you know why. I'm pretty sure it will be in v64, though probably disabled by default.

Chrome 63 was released last year. And 64 in January.
Google release today Chrome 69.

Chrome 69 adds an AV1 decoder to Chrome Desktop stable (Windows, Mac, Linux, ChromeOS) based on the official bitstream specification. At this time, support is limited to "Main" profile 0 and does not include encoding capabilities. The supported container is ISO-BMFF (MP4). To enable this feature use the chrome://flags/#enable-av1-decoder flag.

At this moment it's planing be enabled by default in Chrome v70. https://www.chromestatus.com/features/5729898442260480

So I guess the encoder will be usable enough in six weeks for youtube beta testing at least.

mandarinka

5th September 2018, 14:49

We have a very experimental option called "--tune psychovisual" that uses a different distortion metric. I'd be interested if anyone wants to compare. It's still relatively untested at the moment.

Hmm, only a short test because I ran into time issues but it seems psychovisual tune doesn't on its own prevent the blocking/banding (and texture/noise smoothing/blurring) in areas like sky or other flat regions. But it does seem to help on some noisier/dirtier textures though I can't say it would make the whole picture strictly better. Sometimes it keeps some grain where psnr drops it all, but only sometimes, elsewhere it removes everything just as "well" as psnr. Since it does do something though, I guess it might be useful down the road?

I did not get those "super weird lines" shown in the github issue thread, but I think some similar stripe artifacts do appear in smaller degree too (some transform basis function showing?).

Here are some example images: http://imgbox.com/g/l1gKciGNMk I tested it on a bluray sample I had for other purposes, 1985 animation (remaster with some noise reduction. Chroma noise has been temporally filtered by me earlier). I don't normally deal with live action footage so I have to leave that to others. The sample is a mashup of dunno, 15 scenes, 910 frames total. Lossless encode is about 500 megabytes in case anybody wants to take a look.

I noticed that rav1e at the default speed setting had about the same performance/thread as x265 settings I used for testing before (though that was at much higher bitrate than what I received now), so I decided to use the exact same CLI except for 2-pass to make a comparison clip. So these are not x265 default settings, note.

x265_2.6+2.exe - --input-depth 8 --input-res 1440x1080 --fps 24000/1001 --preset slower --output-depth 10 --ctu 32 --max-tu-size 16 --bitrate 4200 --pass 1 --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me 3 --subme 5 --merange 92 --amp --rect --ref 6 --weightb --weightp --keyint 300 --min-keyint 1 --bframes 8 --aq-mode 1 --aq-strength 1.0 --rd 5 --psy-rd 1.6 --psy-rdoq 8.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --max-merge 5 --qcomp 0.70 --no-strong-intra-smoothing --no-limit-modes --limit-refs 0 --limit-tu 0 --frame-threads 1 --no-wpp --deblock -2:-2 --qg-size 8 --pbratio 1.2 --no-cutree --cu-lossless --lookahead-slices 1 --sar 1:1 --range limited --chromaloc 0 --colormatrix bt709 --no-rskip --rd-refine --cbqpoffs -2 --crqpoffs -2 -o hevc-test.hevc
(this got 4146 kbps on second pass)

Rav1e commandlines:
rav1e.exe --speed 3 --quantizer 70 --tune Psnr dump.y4m -o psnr.ivf (got ~4200 kbps)
rav1e.exe --speed 3 --quantizer 75 --tune Psychovisual dump.y4m -o psy.ivf (got ~4270 kbps)

binary used: https://ci.appveyor.com/project/tdaede/rav1e/build/1.0.195/artifacts

mandarinka

5th September 2018, 14:50

Also, may I have some suggestions? I realize that Rav1e is very early in development (I guess no more can be expected from encoders under the age of 2 years and/or supporting adaptive quantization and such important features).
However, there are some changes that I think could be useful to do even at this early stage.

1) there is a general lack of configurable settings and I heard some rumor that this might actually be somewhat a policy (like the nonexistent user-facing configurabiltiy in Theora?) and not just effect of being early in development.
This is an unfortunate position IMHO. x264/x265 have shown that configurability actually adds to both performance and quality because people can tweak settings. No defaults can be good for everybody.
In addition, the it's the configurability that allows testers to actually test the encoder. You can't even get feedback about your default internal tuning if random people can't test it against different set of parameters.
For example, with things like the psychovisual tuning you requested testing off, it would be useful to be able to test what changing the strength does (whether more is better or less is better, where's an apparent sweetspot, whether it is different depending on content etc...)

Things like aq-strenth, psychovisual bias settings, ratecontrol parameters like qcompress, these things absolutely have to be user-configurable in a serious encoder. Anything that has some quality-compression balance effect too, or just about any compression tool that is a bonus for compression but not always - or when there are cases where it hurts and people will want to disable it. All encoders/formats have tools like that (hello there SAO) and I don't think there are reasons for AV1 (rav1e) to be completely different. If you bar access to these parameters, you handicap the encoder by leaving compression performance potential locked away. You should strive to sell what you got, like x264/x265 does, not keep it in the vault.

Even if you disagree with all of the above, you should think about it form the PR point of view. I'm not the only person feeling like this, so exposing the parameters to users will make your encoder more attractive to users even if you think it's useless...

2) a smaller thing: there is very little feedback given by the commandline encoder. A FPS counter probably isn't completely important, but there is one thing that really would help with testing, and that is a achieved bitrate being reported at the end. I was rather suprised Rav1e didn't report this, because I wanted to encode a comparison clip with 2pass with another encoder and this is rather complicating. I have to figure it out based on filesize but the output's already in a container that has some unknown overhead... I used bitrate calculator like in 2006 but note that those generally only have 1 second precision, which is not very exact for short testing samples.

MoSal

5th September 2018, 16:11

I don't have that setting in Chrome 69.0.3497.81 (stable).

Is it Chrome? or a Chromium distribution package?

marcomsousa

5th September 2018, 16:44

It seems that AV1 has disable in M69 by Google in last minute (https://bugs.chromium.org/p/chromium/issues/detail?id=866522)

But in official docs it's still there Source (https://developers.google.com/web/updates/2018/08/chrome-69-media-updates)

sneaker_ger

5th September 2018, 22:00

Is it Chrome? or a Chromium distribution package?
Chrome from Google on Windows 7 x64, not Chromium.

marcomsousa

5th September 2018, 22:32

I ask information to Google and they said that the AV1 note in the media update (https://developers.google.com/web/updates/2018/08/chrome-69-media-updates) is an error.

They pulled AV1 support in M69 as there were late changes made to the MP4 specification (https://aomediacodec.github.io/av1-isobmff/).
The spec has been finalized by AOM (http://aomedia.org/), so they have moved launch scheduling to M70 (https://www.chromestatus.com/features/5729898442260480).

This pull request (https://github.com/AOMediaCodec/av1-isobmff/pull/99) in MP4 specification repository suggests that will be finalized soon.

birdie

7th September 2018, 21:59

AV1 support is to be reenabled in Chrome 70.

marcomsousa

8th September 2018, 07:08

The AV1 MP4 specification (https://aomediacodec.github.io/av1-isobmff/) was finalized yesterday.

Mr_Khyron

10th September 2018, 02:20

ChaosKing

10th September 2018, 08:06

And you can download it like this youtube-dl.exe -f 396 https://www.youtube.com/watch?v=F1B9Fk_SgI0

marcomsousa

10th September 2018, 08:22

And you can download it like this youtube-dl.exe -f 396 https://www.youtube.com/watch?v=F1B9Fk_SgI0

1080p
Interesting to compare this 3 formats

AV1 - 33.37MiB
youtube-dl.exe -f 399 https://www.youtube.com/watch?v=F1B9Fk_SgI0
VP9 - 42.30MiB
youtube-dl.exe -f 248 https://www.youtube.com/watch?v=F1B9Fk_SgI0
AVC1/H.264 - 41.34MiB
youtube-dl.exe -f 137 https://www.youtube.com/watch?v=F1B9Fk_SgI0

sneaker_ger

10th September 2018, 11:23

Thx. ffmpeg can decode/play it already. Interesting that it's not webm. (I know it was said mkv/webm binding isn't final yet.)

mzso

10th September 2018, 12:02

Youtube has started to encode videos to AV1 :cool:
https://www.youtube.com/watch?v=F1B9Fk_SgI0
https://i.imgur.com/nBcUsqa.png
You must have youtube-dl (2018-09-10) (https://github.com/rg3/youtube-dl/commit/25d110be30b92f785617140b0617a73d8eec5f7b)

Why is the format identifier so messed up? "av01.0.05M.08" and such. On second look AVC is messed up also.

And it only goes up to 480p?

MoSal

10th September 2018, 13:10

And it only goes up to 480p?

Higher resolutions are probably still encoding ;)

nevcairiel

10th September 2018, 13:23

Why is the format identifier so messed up? "av01.0.05M.08" and such. On second look AVC is messed up also.

Thats not messed up, thats the codec parameters string as the MP4 specification, its used for immediate profile/level recognition without having to parse the file.

https://aomediacodec.github.io/av1-isobmff/#codecsparam

av1, Main Profile (0), Level 3.1 (05), Main Tier (M), 8 bit (08)

marcomsousa

10th September 2018, 13:23

Thx. ffmpeg can decode/play it already. Interesting that it's not webm. (I know it was said mkv/webm binding isn't final yet.)
You can also decode/play with Chrome 70 DEV (via chrome://flags/)
Chrome/Firefox don't add any features that can be incompatible in the future.

Why is the format identifier so messed up? "av01.0.05M.08" and such.
mp4 codecs param (https://aomediacodec.github.io/av1-isobmff/#codecsparam)

And it only goes up to 480p?
It's beginning encoding videos with AV1 as a testing or to push the standard.
It's too expensive encoding all videos at this moment, maybe it's better waiting 1 year (with custom capable encoding hardware).

mzso

10th September 2018, 20:36

Thats not messed up, thats the codec parameters string as the MP4 specification, its used for immediate profile/level recognition without having to parse the file.

https://aomediacodec.github.io/av1-isobmff/#codecsparam

av1, Main Profile (0), Level 3.1 (05), Main Tier (M), 8 bit (08)

Ah, okay.

So, is LAV holding back support until some sort of wider adoption of AV1 is accomplished?

It's beginning encoding videos with AV1 as a testing or to push the standard.
It's too expensive encoding all videos at this moment, maybe it's better waiting 1 year (with custom capable encoding hardware).

I didn't suggest that YT should start converting all videos. But converting all resolutions makes sense, for the few that are encoded.

benwaggoner

11th September 2018, 05:14

(with custom capable encoding hardware).
The era of HW encoders is behind us. HEVC was too complex to do with ASIC or even with GPU pixel shaders. Encoding with modern complex codecs like AV1 is going to be CPU, and maybe FPGA.

olduser217

11th September 2018, 05:50

foxyshadis

11th September 2018, 07:33

Youtube has started to encode videos to AV1 :cool:
https://www.youtube.com/watch?v=F1B9Fk_SgI0
https://i.imgur.com/nBcUsqa.png
You must have youtube-dl (2018-09-10) (https://github.com/rg3/youtube-dl/commit/25d110be30b92f785617140b0617a73d8eec5f7b)

Holy cow, as soon as the extensions get support I'm going to be downloading everything both ways and testing. Hopefully AV1 broad release lives up to its promise.

SmilingWolf

11th September 2018, 07:56

Hi y'all!

So, since I keep finding more (https://bugs.chromium.org/p/aomedia/issues/detail?id=2055) and more (https://bugs.chromium.org/p/aomedia/issues/detail?id=2145) alignment-related bugs that only show up on GCC 8.2, but not on 7.3 (compiler's fault? aomedia's fault? Who knows <rant>they have barely gotten any attention despite the community's effort and the fact they involve common configurations and major compiler releases</rant>) I decided to just go for it and build a GCC 7.3 cross compilation VM

Builds specs:
GCC 7.3, 64bits only, statically linked, secure api enabled, so no Win XP support
lbd binaries have been compiled with -DCONFIG_LOWBITDEPTH=1
hbd binaries have been compiled with -DCONFIG_LOWBITDEPTH=0
Use the former for all your 8bits needs since they are considerably faster (https://bugs.chromium.org/p/aomedia/issues/detail?id=2062), the latter for 10-12bits

av1-1.0.0-541-g7d447f5b0: https://mega.nz/#!0wxmgCqS!vBuViCEA7xiLQwl9X1bjVCa9MXoMKv1MubYI0lJnluI

Pushman

11th September 2018, 09:58

It is in HD now:

https://i.imgur.com/0oDgonL.png

LigH

11th September 2018, 11:08

SmilingWolf

11th September 2018, 11:46

@SmilingWolf: I'll keep an eye on it, as soon as MABS passes in both branches again. But for now, there is a greater evil (https://github.com/jb-alvarado/media-autobuild_suite/issues/914) breaking the building of ffmpeg. If the API for AV1 was ever "frozen", it seems to melt already.

Well TBF they froze the bitstream and released a "stable" version 1.0, such issues are to be expected when using an old and moving codebase that needs some cleaning up after many different iterations.
Shouldn't take much more than removing lines 741-744 from libavcodec/libaomenc.c (https://ffmpeg.org/doxygen/trunk/libaomenc_8c_source.html)
This one's on FFMPEG, and will probably be fixed in a day or so

What bothers me much more is the same as the second part of your post, the inertia over months-long periods of time in the AOM tracker

And yes, I shared one of the issues of GCC 8.2.0 creating unaligned RAM access when vector optimization is enabled, several weeks ago, and apart from adding more CC's, not much happened about it.
Regarding this, they are evaluating (https://bugs.chromium.org/p/aomedia/issues/detail?id=2055#c14) using the patch I suggested in comment 8 as a short term fix. BUT now it can't be tested with GCC 8.2 on master, because there is another couple of access violations of various nature happening at different optimization levels because of (as far as I've been able to test) some unholy interaction between GCC 8.2 and AVX code

Side note: unaligned memory access is fine AS LONG AS the ASM instructions emitted take into account memory could be unaligned. In this instance GCC 8.2 -O3 emits instructions that expect memory to be aligned to a 16-byte boundary (movdqa and movaps), while GCC 8.2 -O3 -fno-tree-slp-vectorize emits instructions fit for unaligned memory access (movdqu and movups)

My advice is to stay on GCC 7.3 for AV1 for the time being. I found the laptop I was using back in june to build A/V stuff with an old toolchain, if you want I can zip it up and upload

LigH

11th September 2018, 18:13

And I believe MABS even only selects -O2.

MSYS2 can't include GCC 8.2.0 in the 32-bit branch because it doesn't build itself without errors. I like how MABS keeps MSYS2 up-to-date before updating and compiling the projects. I don't want to miss this feature completely due to very rare compiler issues limiting the speed of the generated code; ultimately it has to be fixed in GCC, and when this happens, MABS will update MSYS2 to it.

I could dig in my archives and find an older MSYS with GCC 7.x too, but I don't want to stuff my drive for a rather little reason. I hope I am not the only provider of binaries...

SmilingWolf

11th September 2018, 18:32

Nope, the only custom GCC flags MABS uses are the ones that won't cause UMA (because typing unaligned memory access all the time is tiring): https://github.com/jb-alvarado/media-autobuild_suite/blob/ccd2fd49bc9fbccec428f02e1b895e219c3cc02b/build/media-suite_compile.sh#L837
Every other compiler flag is left to the default, which implies -O3

Anyway, I think I have almost worked out what's wrong with issue 2145 (https://bugs.chromium.org/p/aomedia/issues/detail?id=2145) and might be able to propose a temporay fix and an explanation shortly. So that would be one out of everybody's hair

As for binaries, as I said I can compile 64bit stuff on my VM now (the first ones are right above, in my first post (http://forum.doom9.org/showpost.php?p=1851277&postcount=902)), if there's need for something particular I guess I can tweak my setup. E.g. I might be able to stuff an extra 32bit toolchain on the VM. Just, no WinXP support, please

easyfab

11th September 2018, 18:54

with MABS, personnaly I create a custom_build_options file ( see L. 63-66 media-suite_compile.sh) with

export CFLAGS="-march=native -O3 -pipe"
export CXXFLAGS="${CFLAGS}"

TD-Linux

12th September 2018, 03:50

1) there is a general lack of configurable settings and I heard some rumor that this might actually be somewhat a policy (like the nonexistent user-facing configurabiltiy in Theora?) and not just effect of being early in development.

I plan to add debugging options exactly for the purpose of getting feedback from users - the first obvious thing to add is the internal cdef-dist parameters to tune them. That said, they will remain debug options - for example, we may change how cdef-dist works internally when we find a better way to do it, and that will break the options. If you find a combination of debug options that looks better, I'd rather you report it as a bug and we use that information to change the defaults.

BTW we are getting segmentation soon - once we get it I'll let you know, it'll make the effect of cdef-dist far stronger.

2) a smaller thing: there is very little feedback given by the commandline encoder. A FPS counter probably isn't completely important, but there is one thing that really would help with testing, and that is a achieved bitrate being reported at the end. I was rather suprised Rav1e didn't report this, because I wanted to encode a comparison clip with 2pass with another encoder and this is rather complicating. I have to figure it out based on filesize but the output's already in a container that has some unknown overhead... I used bitrate calculator like in 2006 but note that those generally only have 1 second precision, which is not very exact for short testing samples.

I would happily take patches for this. That said, the top priority is actually to get it integrated with ffmpeg, which will give you a printout of the framerate and bitrate, plus allow muxing and many more input formats.

SmilingWolf

12th September 2018, 09:19

nevcairiel

12th September 2018, 09:40

If a register is being used has to be flagged by the ASM function in question (in its cglobal line), x86inc.asm cannot detect that automatically, the code has to tell it. If its not pushing regs that are in fact being used, then the cglobal line may be wrong. From the code it looks like the macro is being passed a "7" for numbers of register used, while RSI would be the 9th in their counting (ie. r8). I don't see it directly being used in quantize_b, but it maybe used behind a symbolic name to load a parameter.

SmilingWolf

12th September 2018, 09:47

Cr*p and I just sent a mail to Henrik.

Yes, RSI is used here (https://aomedia.googlesource.com/aom/+/f36be56b39c1125264a6c4b9a7e835855e5d50c8/aom_dsp/x86/quantize_avx_x86_64.asm#182) for dequantq

Ok let me test that real quick.
Thanks for the input!

nevcairiel

12th September 2018, 09:58

If dequant is the highest parameter being used, changing the 7 to a 9 at the end of the file might be all that is needed.

SmilingWolf

12th September 2018, 10:03

YES! Fix confirmed!

EDIT: and patch sent: https://bugs.chromium.org/p/aomedia/issues/detail?id=2145#c7

Aleksoid1978

12th September 2018, 12:29

av1-1.0.0-552-gbb82e05fb: https://mega.nz/#!99ASgKAJ!l7Lc4n9KEs2eHeaebwnmLyHDVUrRf9FgrYxXAEaoByw

As promised, the explanation for BUG=aomedia:2145 has dropped (https://bugs.chromium.org/p/aomedia/issues/detail?id=2145#c6). Does anybody know if one of x264/x86inc.asm maintainers could take a look?
There are some contacts in the header of the file, I suppose my best bet is e-mailing Henrik Gramner, who seems responsible for most of the recent commits, yes?

Hello. Can you compile static lib for use with any project, like ffmpeg ?? I need x86/x64 AV1 decoder only.

I don't know why - but on my home/work PC i can't compile, cmake error on AVX2(my PC don't support AVX2).

marcomsousa

12th September 2018, 13:11

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

I like more the second round testing at lower data rates and this comment:

You should focus your tests on the data rates at which your video will most likely be deployed. At this point, H.264 and any newer codec should produce near perfect quality at 6 Mbps, making that data rate irrelevant for forward-looking testing. HEVC and VP9 take the near perfect quality level down to between 3.5Mbps to 4Mbps, and AV1 and future codecs should bring this down into the 2Mbps to 3.5Mbps range.

SmilingWolf

12th September 2018, 13:50

Hello. Can you compile static lib for use with any project, like ffmpeg ?? I need x86/x64 AV1 decoder only.

I don't know why - but on my home/work PC i can't compile, cmake error on AVX2(my PC don't support AVX2).

You should post a log and some infos on your building env. Missing AVX2 at compile or even configure time looks like an outdated version of GCC rather than an issue with your CPU.
Maybe there is an older version/toolchain in your $PATH that's interfering?
GCC 7/8 can emit AVX2 instructions even when running on an old Pentium 4.

Aleksoid1978

12th September 2018, 14:06

Use VS 2017 or GCC 8.2.0 - there is no difference.

SmilingWolf

12th September 2018, 14:18

Blue_MiSfit

12th September 2018, 18:35

Decoding using vlc nightly on the above ~1 Mbps 1080p encode from YouTube is working very well - takes about 10% CPU on my i7-6700k

mzso

12th September 2018, 19:05

The era of HW encoders is behind us. HEVC was too complex to do with ASIC or even with GPU pixel shaders. Encoding with modern complex codecs like AV1 is going to be CPU, and maybe FPGA.

How can something be too complex for ASIC? (And not for FPGA, which is essentially an ASIC you can program)

Holy cow, as soon as the extensions get support I'm going to be downloading everything both ways and testing. Hopefully AV1 broad release lives up to its promise.

Why not just download with youtube-dl?

mzso

12th September 2018, 19:22

Is there some hidden way on youtube to find AV1 encoded videos? (I vaguely remember that they used to have something for VP9 when it was deployed)

Anyways, did anyone find more videos on Youtube than the one posted before?

Aleksoid1978

13th September 2018, 00:31

Can you post the full cmake -G "MSYS Makefiles" etc. etc. log on pastebin as it appears on screen?
Or, better/more complete, the contents of <yourBuildDir>/CMakeFiles/CMakeError.log and CMakeOutput.log?

cmake output - https://pastebin.com/spXmNAJS

CMakeError.log - https://pastebin.com/aPnpqnGF

CMakeOutput.log - https://pastebin.com/JpnNx4Xm

P.S. i think some message test on russian and we can't see it in CMake logs :)

Blue_MiSfit

13th September 2018, 02:10

Why not just download with youtube-dl?

I think foxyshadis was referring to the availability of MSE decoders in the browsers.

marcomsousa

13th September 2018, 04:29

YES! Fix confirmed!

EDIT: and patch sent: https://bugs.chromium.org/p/aomedia/issues/detail?id=2145#c7

Yours two patch requests was merge in master (https://aomedia.googlesource.com/aom/+log/master), congrats.

SmilingWolf

13th September 2018, 07:32

cmake output - https://pastebin.com/spXmNAJS

CMakeError.log - https://pastebin.com/aPnpqnGF

CMakeOutput.log - https://pastebin.com/JpnNx4Xm

P.S. i think some message test on russian and we can't see it in CMake logs :)

It's the path :D

The "++" in "D:/Aleksoid/C++/Source/aom/" create an invalid regular expression that makes some of the cmake tests fail. The AVX2 one just happens to be the first file tested that triggers the problem.
Just rename the path to something like CPP and all the problems should go away

Yours two patch requests was merge in master (https://aomedia.googlesource.com/aom/+log/master), congrats.

Confirming that with these additions the master branch, as of commit 67645b8, compiles and works again with GCC 8.2 without adding any extra C/CXX option on the CMake command line.
Ping @LigH :)

EDIT:
New build, GCC 8.2 based, no extra C/CXX flags, 32/64bits, HBD/LDB, static libraries included (decoder+encoder, sorry Aleksoid1978 but this solution was simply faster than having 8 different build configs)
av1-1.0.0-566-g67645b8f5: https://mega.nz/#!BsxmTYyJ!dnoSK66ucCz8DciOrhbgJtgW6Mebh7QnZnFkEzEop08

Following the comments on issue 2147 (https://bugs.chromium.org/p/aomedia/issues/detail?id=2147) I think I'll drop the CONFIG_LOWBITDEPTH=0 builds from now on
The CONFIG_LOWBITDEPTH=1 ones should work perfectly for 8/10/12 bits video and work faster for 8 bits on top, so no reason to keep the HBD-only builds around

LigH

13th September 2018, 08:26

Thanks, I noticed via aomedia mail notification. I assume wiiaboo will revert the MABS patch soon.

GTPVHD

13th September 2018, 08:48

https://www.youtube.com/playlist?list=PLyqf6gJt7KuHBmeVzZteZUlNUQAVLwrZS

AV1 beta testing on Youtube.

Pushman

13th September 2018, 10:43

It has very high bitrate now.
At time of writing, these transcodes are encoded at a very high bitrate for decoder performance testing.

ChaosKing

13th September 2018, 11:16

I can't play the "halo infinite trailer" video (720p) lagfree with mpv. It seems that is uses gpu decoding? bcs cpu is only at max 5%

nevcairiel

13th September 2018, 11:42

There is no GPU decoding for AV1 anywhere yet. But maybe the decoder has a bottleneck somewhere.

sneaker_ger

13th September 2018, 11:43

ChaosKing

13th September 2018, 11:45

Ryzen 1700 @3.6ghz. gpu Rx480 8GB. I testet it in Chrome 70 now and it is very smooth.
I thought of gpu decoding bcs in the task manager you can see a "GPU 3d" if you show the gpu modules column when playing in mpv.

mzso

13th September 2018, 13:43

It has very high bitrate now.

AKA, decent bitrate. :)

Sadly, they play nowhere near smoothly on my R5 1600, even though 6/12 cores are utilized to around 30-40%.

Gravitator

13th September 2018, 14:52

AKA, decent bitrate. :)

Sadly, they play nowhere near smoothly on my R5 1600, even though 6/12 cores are utilized to around 30-40%.

Check how it will be with the disabled SMT/HT?

clsid

13th September 2018, 15:01

It seems to already use only the physical cores by default. So that won't have any effect.

TD-Linux

13th September 2018, 22:36

With mpv 2018-09-02 the 720p version of the halo trailer stutters here as well. I'm not sure it is related to shere AV1 decoding performance as LAV nightly (via MPC-HC) decodes completely smooth on i5-2500K with maybe 15% - 30% CPU. (Not that you have told us anything about your hardware ...)

ffmpeg bug, should be fixed in newer builds of mpv:+ffmpeg: https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/309c3a0e81be553626711912e90015c26f4b09ba

Clare

14th September 2018, 05:12

ffmpeg bug, should be fixed in newer builds of mpv:+ffmpeg: https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/309c3a0e81be553626711912e90015c26f4b09ba

Still dropping many frames in 1080p with this commit.
CPU usage is around 10-13%.

Nintendo Maniac 64

14th September 2018, 08:23

I just did some performance testing with the 1080p 30fps AV1 encode of the Gus Kenworthy & Tom Wallisch X Games Slopestyle GoPro Preview (https://www.youtube.com/watch?v=_fAOe8oz8qM) video in MPC-HC v1.8.1 x64 with its built-in LAVfilters; I originally tried the Halo video but I found the X Games video to be much more demanding (but also much more motion-sick inducing, especially when playing at slower than real-time).

With my 4c/8t Nehalem Xeon x3470 I was only seeing ~25% CPU utilization at maximum even though I was unable to play back the video in real-time (it was somewhere between 16fps and 20fps). Mathematically that should mean that it's only using 2 threads, but disabling SMT and setting my BIOS to only enable 2 cores resulted in noticably worse performance, yet setting the BIOS to enable 3 cores without SMT resulted in the same 16-20fps performance I was originally seeing yet at only ~67% CPU utilization.

At least with the LAVfilters bundled with MPC-HC v1.8.1 x64, it would seem that the AV1 decoder can only utilize 3 cores and no SMT, yet even then the 2 less loaded cores are only hitting around half of their according core's available utilization.

And for reference, the 720p 30fps AV1 encode of that same video played back without a hitch on my Xeon - heck it left enough headroom that I could turn on a bunch of motion interpolation which greatly helped alleviate the motion sickness I got from watching the 1080p AV1 encode playback at sub-20fps frame rates (it's times like this that I thank the devs over at Nintendo for making F-Zero X and F-Zero GX native 60fps games).

Now I'm a bit out-of-the-loop, but I couldn't help but notice that YouTube-DL was using the .MP4 extension for AV1 downloads - is that in fact correct behavior? (and no, I don't mean AVC1, otherwise my PC would have been playing back the videos easy-peasy).

SmilingWolf

14th September 2018, 09:07

Now I'm a bit out-of-the-loop, but I couldn't help but notice that YouTube-DL was using the .MP4 extension for AV1 downloads - is that in fact correct behavior? (and no, I don't mean AVC1, otherwise my Xeon would have been playing back the videos easy-peasy).

I can only answer to this part: the ISO-BMFF bindings for AV1 have been finalized first (just a few days ago in fact), while the Matroska/WebM ones are still WIP

So MP4-only for the time being

Also:
GCC 8.2, static builds, 32/64bits, CONFIG_LOWBITDEPTH=1
av1-1.0.0-577-g8ae39302e: https://mega.nz/#!14REmAwB!AO8Sta2C3ok4LZYyH9N7QKeZHfdcaKVcSKPnnuyEOeI

marcomsousa

14th September 2018, 09:11

I just did some performance testing with the 1080p 30fps AV1 encode of the Gus Kenworthy & Tom Wallisch X Games Slopestyle GoPro Preview (https://www.youtube.com/watch?v=_fAOe8oz8qM) video in MPC-HC v1.8.1 x64 with its built-in LAVfilters

I was able to play 1080p with MPC-HC v1.8.1 x64 in real time, with some hitches in middle part of the video.
CPU at 62%
Intel Core i7-8550U (Kaby Lake-R U4+2)

With ffplay.exe 20180912 I play this 1080p video, realy realy slow, but play well the 720p video.

Now I'm a bit out-of-the-loop, but I couldn't help but notice that YouTube-DL was using the .MP4 extension for AV1 downloads - is that in fact correct behavior?
It's correct, since webm support for av1 isn't finalized. Also youtube-dl download what youtube give, and Youtube have av1 in mp4 container with mp4 schema (av01.0.05M.08).

SmilingWolf

14th September 2018, 10:59

With ffplay.exe 20180912 I play this 1080p video, realy realy slow, but play well the 720p video.

ffplay 20180912 is, for whatever reason, a very poor version to test with. Don't know if it depends on the aom library revision used, on the ffmpeg revision, or something in the middle, but on my system it performs at half the perf on my own minimal ffmpeg+aom build

CPU: Intel i7-4770 @ 3.4 GHz

Zeranoe build:
# ffmpeg -threads 4 -i "Gus Kenworthy & Tom Wallisch X Games Slopestyle GoPro Preview.1080.mp4" -benchmark -f null -
ffmpeg version N-91931-gb69ea742ab Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 8.2.1 (GCC) 20180813
[libaom-av1 @ 0000000000485ac0] 1.0.0-507-g5d963cb57
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Gus Kenworthy & Tom Wallisch X Games Slopestyle GoPro Preview.1080.mp4':
frame= 1736 fps= 18 q=-0.0 Lsize=N/A time=00:00:57.92 bitrate=N/A speed=0.602x
video:909kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=95.473s stime=0.187s rtime=96.195s
bench: maxrss=234036kB

My own:
# ./ffmpeg -threads 4 -i "Gus Kenworthy & Tom Wallisch X Games Slopestyle GoPro Preview.1080.mp4" -benchmark -f null -
ffmpeg version N-91943-g1b98bfb932 Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 8.2.1 (GCC) 20180913
[libaom-av1 @ 0000000000338500] 1.0.0-577-g8ae39302e
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Gus Kenworthy & Tom Wallisch X Games Slopestyle GoPro Preview.1080.mp4':
frame= 1736 fps= 37 q=-0.0 Lsize=N/A time=00:00:57.92 bitrate=N/A speed=1.24x
video:909kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=98.234s stime=1.076s rtime=46.544s
bench: maxrss=272452kB

Mr_Khyron

14th September 2018, 12:09

http://download.opencontent.netflix.com/?prefix=AV1/
************** Netflix AV1 Encodes Readme **************************************

This is the readme for the Netflix AV1 Encodes.

The assets covered in this readme can be browsed on the Netflix OpenContent
bucket here:
http://download.opencontent.netflix.com/?prefix=AV1/

Each asset has its license posted to its main directory in the file license.txt.

********** Downloading with AWS CLI ********************************************

You can download single files directly through your web browser on the
OpenContent page, but for large files and long frame sequence, you may wish to
use command line tools such as aws cli.
Detailled instructions are posted here:
http://download.opencontent.netflix.com.s3.amazonaws.com/TechblogAssets/README.txt

********** Encoding and Packaging **********************************************

The IVF files were produced using AOM aomenc (Libaom v1.0) using 2-pass, CQP,
tiles on higher resolutions, and Film Grain. Additionally, the following
parameters were used for all encodes:
--passes=2 --fpf=twopassStats --i420 --profile=0 --arnr-maxframes=7
--arnr-strength=5 --lag-in-frames=25 --aq-mode=0 --bias-pct=100
--minsection-pct=1 --maxsection-pct=10000 --end-usage=q --min-q=0 --max-q=63
--input-bit-depth=[8|10] --cpu-used=1 --auto-alt-ref=1 --max-gf-interval=12
--min-gf-interval=[4|5|6] --frame-parallel=0 --threads=8
--tile-columns=[1|2|4] --ivf

The IVF files were then packaged into (non-fragmented and non-encrypted) MP4
files conforming to https://aomediacodec.github.io/av1-isobmff/using
GPAC's MP4Box (GPAC version 0.7.2-DEV-rev654-gb6f7409ce-master) as follows:

MP4Box -add input.ivf output.mp4

********************************************************************************

Last updated: 2018 Sept 4
Copyright NETFLIX INC.
100 Winchester Circle, Los Gatos, CA 95032, USA
:)

sneaker_ger

14th September 2018, 12:34

Screenshots 8 vs 10 bit (8 bit has 40% more bitrate):
Netflix Chimera 8 bit (https://abload.de/img/chimera-av1-8bitipemd.png)
Netflix Chimera 10 bit (https://abload.de/img/chimera-av1-10bitreea9.png)

Is this an inherent problem of AV1 8 bit or just because it isn't very tuned yet (bitrate allocation, aq, psy)? Though 10 bit encode also has some problems, those "boxes" on the power lines between the two skyscrapers on the left go missing. Then again 10 bit was given much lower bitrate here ..

MoSal

14th September 2018, 12:43

ffmpeg bug, should be fixed in newer builds of mpv:+ffmpeg: https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/309c3a0e81be553626711912e90015c26f4b09ba

That's not the (only) issue. Note the decoding bottleneck in this sample (https://archive.org/download/unsorted_files/halo_av1.mkv) five seconds in, at the scene change.

marcomsousa

14th September 2018, 12:48

Zeranoe build:
libaom-av1 @ 0000000000485ac0] 1.0.0-507-g5d963cb57
My own:
[libaom-av1 @ 0000000000338500] 1.0.0-577-g8ae39302e
ffmpeg/Zeranoe build don't have the 70 optimization commits that you have in libaom-av1.

ffmpeg-20180913-1b98bfb-win64

ffmpeg -threads 4 -i 1080.mp4 -benchmark -f null -
ffmpeg version N-91943-g1b98bfb932 Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 8.2.1 (GCC) 20180813
configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth
libavutil 56. 19.101 / 56. 19.101
libavcodec 58. 30.100 / 58. 30.100
libavformat 58. 18.100 / 58. 18.100
libavdevice 58. 4.103 / 58. 4.103
libavfilter 7. 31.100 / 7. 31.100
libswscale 5. 2.100 / 5. 2.100
libswresample 3. 2.100 / 3. 2.100
libpostproc 55. 2.100 / 55. 2.100
[libaom-av1 @ 000001e19c898940] 1.0.0-507-g5d963cb57
Stream mapping:
Stream #0:0 -> #0:0 (av1 (libaom-av1) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, null, to 'pipe:':
Metadata:
major_brand : dash
minor_version : 0
compatible_brands: iso6av01mp41
encoder : Lavf58.18.100
Stream #0:0(und): Video: wrapped_avframe, yuv420p, 1920x1080, q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc (default)
Metadata:
creation_time : 2018-09-12T19:11:12.000000Z
handler_name : ISO Media file produced by Google Inc. Created on: 09/12/2018.
encoder : Lavc58.30.100 wrapped_avframe
frame= 1736 fps= 19 q=-0.0 Lsize=N/A time=00:00:57.92 bitrate=N/A speed=0.637x
video:909kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=88.703s stime=0.938s rtime=90.919s
bench: maxrss=233580kB

SmilingWolf

14th September 2018, 13:51

Sure, which was one of the options considered in my post. The 20180913 build with the current ffmpeg HEAD (91943-g1b98bfb932) wasn't out when I tested, so I couldn't be sure.
Still, to double performance in just about 8 days (Zeranoe aom revision: 20180906-5d963cb) is really a LOT, especially considering a lot of the commits are either bugfixes or encoding-related.

Turns out the commit that really made the difference is f820da0 - Turn on the row-based multi-thread decoder by default (https://aomedia.googlesource.com/aom/+/f820da02be8caa59c3e1c372cca048ac296ca5fb).

# time ./aomdec.850e126ac.exe --threads=4 -o /dev/null "Gus Kenworthy & Tom Wallisch X Games Slopestyle GoPro Preview.1080.ivf"

real 1m0,929s
user 0m0,000s
sys 0m0,000s

# time ./aomdec.f820da02b.exe --threads=4 -o /dev/null "Gus Kenworthy & Tom Wallisch X Games Slopestyle GoPro Preview.1080.ivf"

real 0m37,947s
user 0m0,000s
sys 0m0,000s

LigH

14th September 2018, 14:59

New uploads:

AOM v1.0.0-577-g8ae39302e noVO (https://www.mediafire.com/file/odgwmafp1dp6n4i/aom_v1.0.0-577-g8ae39302e_noVO.7z) (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0 with -fno-tree-slp-vectorize)
AOM v1.0.0-577-g8ae39302e (https://www.mediafire.com/file/i8lcorwl2c5x7oq/aom_v1.0.0-577-g8ae39302e.7z) (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0) – no crash in 2-pass for me

rav1e 0.1.0 (1fa32bb / 2018-09-14) (https://www.mediafire.com/file/944vj5j3j495329/rav1e_0.1.0_2018-09-14_1fa32bb.7z) (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0)

birdie

14th September 2018, 16:12

AV1 in MP4 has been standardized: https://cdn.rawgit.com/AOMediaCodec/av1-isobmff/v1.0.0/index.html

Tommy Carrot

14th September 2018, 16:49

Thanks Ligh and Smilingwolf for the builds. For some reason, Smilingwolf's build is considerably faster (finished the same encode in 40 minutes vs 67). I used your unpatched build, Ligh, and 64 bit versions. I don't know if this happens because of difference in the compiler settings, or because Smilingwolf sets CONFIG_LOWBITDEPTH=1. The outputs are identical.

Nintendo Maniac 64

14th September 2018, 20:42

It's correct, since webm support for av1 isn't finalized. Also youtube-dl download what youtube give, and Youtube have av1 in mp4 container with mp4 schema (av01.0.05M.08).

Again, kind of out-of-the-loop, but since AV1 will support MP4 and WebM unlike VP8/9, one has to wonder which container would be "better?"

(I would imagine that AV1 in MP4 would have better compatibility on Apple devices in the future, but I wasn't really concerned about the difference in support as so much if either of the MP4 or WebM containers are objectively "better" on a technological level than the other).

mzso

14th September 2018, 20:52

Again, kind of out-of-the-loop, but since AV1 will support MP4 and WebM unlike VP8/9, one has to wonder which container would be "better?"

(I would imagine that AV1 in MP4 would have better compatibility on Apple devices in the future, but I wasn't really concerned about the difference in support as so much if either of the MP4 or WebM containers are objectively "better" on a technological level than the other).

I don't think that mp4 store opus/vorbis for one. Probably the most efficient lossy audio codecs.

Nintendo Maniac 64

14th September 2018, 20:58

CPU at 62%
Intel Core i7-8550U

Interesting how both of our CPUs have the exact same 4c/8t configuration, yet you're seeing more than 2x the CPU utilization than I am...

Mathmatically that would mean that you're utilizing at least 5 threads, which would equal out to being something like 4 cores and 1 SMT thread.

I do know that that my Nehalem predates AVX and that newer CPUs also have stronger SMT (this is particularly true with Zen cores), so I've got to wonder if something between those two variables is resulting in AV1 utilizing multiple threads much better on your Kabylake i7 than it does on my Nehalem Xeon.

I mean, I know that Sky/Kaby/Coffee lake will have anywhere from 30% to 50% higher single core IPC than Nehalem, but I wouldn't think that would account for any difference in how many cores are being utilized at any given time (outside of SMT threads being used, but I'm not even seeing any utilization on my fourth hardware core let alone SMT).

sneaker_ger

14th September 2018, 21:54

I don't think that mp4 store opus/vorbis for one.
http://opus-codec.org/docs/opus_in_isobmff.html

mzso

14th September 2018, 22:55

http://opus-codec.org/docs/opus_in_isobmff.html

Version 0.6.8 (incomplete)

last updated: April 28, 2016

So, not done yet. If it'll ever be.

Nintendo Maniac 64

15th September 2018, 04:31

Blue_MiSfit

15th September 2018, 07:38

Well then, as someone with much more expertise in audio than video, Opus not being compatible with MP4 is a big win for WebM in my book.

...unless you do streaming in the same manner that YouTube does whereby you just deliver completely independent streams for audio and video, therefore allowing you to use MP4 and WebM streams concurrently (sometimes a recently-uploaded video will have VP9 video encodes but only AAC audio encodes for whatever reason; here's an example video of such (https://www.youtube.com/watch?v=miE1nrkjmUA) that has VP9 video yet only AAC audio as of this comment).

So - speaking from the perspective of an OTT operator, having separate audio and video files is quite common for both HLS and DASH. This is basically mandatory the second you want to offer more than one audio track (e.g. multiple languages or 2.0 vs 5.1 etc).

I believe YouTube uses DASH by default on modern browsers. I know you can do fMP4 and webm via DASH but I didn't realize you could mix both in a DASH manifest, but YouTube is clearly doing this with their AV1 + Opus streams.

I do imagine that YouTube's JavaScript player is quite specialized though. I wouldn't expect this to work OOTB on other DASH clients like a Roku or something like dash.js (even if the underlying audio / video decoders supported AV1 and Opus) - but then again I've never tried :)

benwaggoner

15th September 2018, 12:59

I don't think that mp4 store opus/vorbis for one. Probably the most efficient lossy audio codecs.
xHE-AAC is really very good and going to be widely adopted in the mobile ecosystem. Similar mixed voice/other encoding like Opus. significantly better quality <24 Kbps in my limited testing.

As for container, WebM and MKV just aren't used for mainstream commercial content or streaming outside of YouTube. MP4 has a huge and mature ecosystem that is already deployed, and there's nothing about WebM that would justify the cost of switching ALL those components to ones that support WebM. There are so many components for transport, muxing, demuxing, encryption, decryption, fragmentation, ALL of which would have to be updated for WebM to be viable. All it takes is a few legacy-but-supported devices that can't use WebM to keep an organization from even contemplating switching. And even if all the components were updated, what would switching from MP4 improve?

I can't imagine any container format replacing MPEG-4 for at least a decade. If new container features are needed, they'll most likely be done as an official extension of MP4 by MPEG.

mzso

15th September 2018, 15:10

@benwaggoner
Well, I for one don't care at all about <100kbps crappines whatever the codec may be.

Zebulon84

15th September 2018, 15:27

From what I understand, the main point of AV1 is to have a good royalty free codec. Why associate it with an audio codec that require licensing like xHE-AAC, when an equivalent royalty free codec like opus exist ?
Compatibility is not an issue, as nothing is compatible with AV1 today, so you can just add both together.

IgorC

15th September 2018, 17:50

xHE-AAC is really very good and going to be widely adopted in the mobile ecosystem.
???

xHE-AAC, Opus, HEVC and VP9 were all standarized at the same time.

VP9, HEVC and Opus were adopted in many applications.

xHE-AAC? Name me one functional encoder. 6 years and counting.
No market for its licensing (Opus did it), awfully late and too little.
xHE-AAC is dead.

benwaggoner

15th September 2018, 19:40

@benwaggoner
Well, I for one don't care at all about <100kbps crappines whatever the codec may be.
You may not. But if you are in rural India on a 2G network, you would care a LOT. And have a lot of company.

Or, if you are in a subway, or on airport WiFi.

Nintendo Maniac 64

15th September 2018, 21:33

Hey, has anyone tried decoding AV1 on a CPU that lacks AVX and seeing what the resulting CPU utilization is? (for reference, even the newest 2c/4t Coffee lake Pentiums lack AVX) I'm starting to wonder if my Xeon's under-utilization is due to the fact that my CPU completely predates AVX...

I know that a similar thing happened in the past where VP9 had some heavy optimizations for SSSE3 (I don't believe this is the case anymore) which resulted in something like a 2.5x performance gain simply by having SSSE3 support (which wasn't present on AMD CPUs until 2011).

MoSal

15th September 2018, 22:25

Hey, has anyone tried decoding AV1 on a CPU that lacks AVX and seeing what the resulting CPU utilization is? (for reference, even the newest 2c/4t Coffee lake Pentiums lack AVX) I'm starting to wonder if my Xeon's under-utilization is due to the fact that my CPU completely predates AVX...

I know this doesn't exactly answer your question, but I profiled the decoder with an AVX2-capable CPU, and while there are hot AVX2 optimized functions (namely the ones called by av1_make_inter_predictor), a lot of (currently) hot functions are still implemented in C (e.g. av1_read_coeffs_txb and od_ec_decode_cdf_q15). So the decoder is still not well-optimized SIMD-wise, regardless of the instruction set.

Everyone will probably end up using ffav1 anyway, so this shouldn't really matter.

lvqcl

15th September 2018, 22:46

Everyone will probably end up using ffav1 anyway

From Video Dev Days 2018 (September 22) (https://www.videolan.org/videolan/events/vdd18/):
Dav1d: a fast new AV1 decoder

Dav1d is Dav1d.

LigH

15th September 2018, 23:31

Nice ... another alternative to aomenc, similar to rav1e (by team Xiph), here by team VideoLAN.
_

:o Oops: decoder.

mandarinka

16th September 2018, 00:10

I plan to add debugging options exactly for the purpose of getting feedback from users - the first obvious thing to add is the internal cdef-dist parameters to tune them. That said, they will remain debug options - for example, we may change how cdef-dist works internally when we find a better way to do it, and that will break the options. If you find a combination of debug options that looks better, I'd rather you report it as a bug and we use that information to change the defaults.

I don't think that's going to be viable. The point of tweakability is that the changes taht improve one source don't improve all sources. I would be surprised if one set of magic numbers were ideal for all content. And likewise, even beyond that objective factor, people have different ideas about how should the video look and that requires ability to change settings too and again precludes one specific setting from being ideal for everything.

Hmmm, makes me think... Doom9 has this in its forum rules: "There is no best".
It's not a straightforward "video truth" (heh), but the reason behind it most likely has a connection exactly with this case. In video processing/compression, you usually don't have an absolute correct and final answer that is true always, regardless of context. Personally I agree with it that there is not one best aq-strength, psy-rdo, crf and so on. IMHO it's going to happen with Rav1e options too.

Selur

16th September 2018, 07:17

Since when feeding 10bit yv12 with profile I get:
Profile 2 bit-depth < 10 requires 4:2:2 color format
I got a small question:
What color sampling and bit depth combinations are supported in which profile when using aomenc?

Cu Selur

nevcairiel

16th September 2018, 07:39

You should be using Profile 0 (Main) for 10-bit 4:2:0 for maximum compatibility.

The general AV1 rules are pretty simple:
Main Profile (0) is 8/10-bit 4:2:0 or Monochrome (4:0:0)
High Profile (1) is 8/10-bit 4:2:0, 4:4:4, Monochrome
Professional Profile (2) is 8/10/12-bit, 4:2:0, 4:2:2, 4:4:4, Monochrome

I would assume that the encoder follows the same rules - and judging by that message it even enforces the "use the lowest profile possible" suggestion?
I don't know right off the top of my head if the profiles actually influence anything else beyond the bitdepth/chroma, but I don't think so, which gives you little to no reason to use a higher profile when you don't need its chroma/bitdepth extensions.

foxyshadis

16th September 2018, 08:54

I like more the second round testing at lower data rates and this comment:

You should focus your tests on the data rates at which your video will most likely be deployed. At this point, H.264 and any newer codec should produce near perfect quality at 6 Mbps, making that data rate irrelevant for forward-looking testing. HEVC and VP9 take the near perfect quality level down to between 3.5Mbps to 4Mbps, and AV1 and future codecs should bring this down into the 2Mbps to 3.5Mbps range.

The bias of this comment is obvious: This is targeting the little-to-no-grain FHD segment. Grain is basically an uncompressible random number generator, the only only way out is tons of bitrate or FGM. People are going to hate on AV1 the same way they hate on HEVC because it won't store film grain efficiently, since neither codec is even remotely targeting that.

foxyshadis

16th September 2018, 09:07

@benwaggoner
Well, I for one don't care at all about <100kbps crappines whatever the codec may be.

It has nothing to do with only being good at crap bitrates, and everything to do with having one codec that can go from 8kbps to 500kbps without compromise, the one codec to replace them all. That is the siren call of Opus, and that is the promise of xHE-AAC, although it hasn't exactly been realized yet. IMHO it's still better to have two heavyweights that are better than everything else out there, because it keeps the pressure on to keep improving.

???

xHE-AAC, Opus, HEVC and VP9 were all standarized at the same time.

VP9, HEVC and Opus were adopted in many applications.

xHE-AAC? Name me one functional encoder. 6 years and counting.
No market for its licensing (Opus did it), awfully late and too little.
xHE-AAC is dead.

Spotify has been using it all year at the 24kbps point, and they're working on moving it up the stack. Android 9 has made it mandatory. (Android 5 made Opus mandatory.)

Mr_Khyron

16th September 2018, 14:32

From Video Dev Days 2018 (September 22) (https://www.videolan.org/videolan/events/vdd18/):
Dav1d: a fast new AV1 decoder
Ronald Bultje is making the decoder?!!

So we will have the worlds fastest AV1 decoder soon ;)
https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/

:)

IgorC

16th September 2018, 15:23

Spotify has been using it all year at the 24kbps point, and they're working on moving it up the stack. Android 9 has made it mandatory. (Android 5 made Opus mandatory.)
Spotify uses HE-AAC for lowest bitrate mode, not xHE-AAC.
As for the rest of bitrates they use Vorbis and LC-AAC. There is no quality benefit from xHE/HE-AAC codec at higher rates. Add to it that Vorbis is free and LC-AAC patents will expire in 2 years.
https://support.spotify.com/us/using_spotify/system_settings/high-quality-streaming/

Android 9 has made it mandatory.
That's a decoder. There is still no any encoder (and it won't be)
Remember MPEG surround format? It's 11 years old ... with zero adoption. xHE-AAC goes a same road with its 6 years of 'unadoption'. After MP3 and (HE)AAC none of a new mpeg audio format has seen any meaningful adoption.

marcomsousa

17th September 2018, 09:48

ffmpeg 2018-09-13 zeranoe build
ffmpeg -threads 4 -i 1080.mp4 -benchmark -f null -
ffmpeg version N-91943-g1b98bfb932
[libaom-av1 @ 000001e19c898940] 1.0.0-507-g5d963cb57

frame= 1736 fps= 19 q=-0.0 Lsize=N/A time=00:00:57.92 bitrate=N/A speed=0.637x
bench: utime=88.703s stime=0.938s rtime=90.919s
bench: maxrss=233580kB

ffmpeg 2018-09-16 zeranoe build
ffmpeg -threads 4 -i 1080.mp4 -benchmark -f null -
ffmpeg version N-91961-g5109c38162
[libaom-av1 @ 000001b015cfd8c0] 1.0.0-590-g6fa400604

frame= 1736 fps= 34 q=-0.0 Lsize=N/A time=00:00:57.92 bitrate=N/A speed=1.15x
bench: utime=100.594s stime=2.812s rtime=50.395s
bench: maxrss=274472kB

The new ffmpeg builds with a newer libaom-av1 improves performance a lot (like SmilingWolf said)

iwod

17th September 2018, 14:24

Add to it that Vorbis is free and LC-AAC patents will expire in 2 years.

Any links? The only thing I got was from Wikimedia

https://phabricator.wikimedia.org/T166025

Which state LC-AAC to be patents free in 2018! This is big news.

mzso

17th September 2018, 19:37

Any links? The only thing I got was from Wikimedia

https://phabricator.wikimedia.org/T166025

Which state LC-AAC to be patents free in 2018! This is big news.

Why? Because around no-one cares about it by now?

LigH

17th September 2018, 19:51

In general, generalizations are wrong... "no-one" is a strong assumption without proof over the whole population of earth using technology compatible to LC-AAC already (e.g. iTunes).

If you don't care about AAC, it's your choice. But don't assume about anyone else.

Blue_MiSfit

18th September 2018, 08:23

Let's try to keep discussion focused on AV1, guys ;)

marcomsousa

18th September 2018, 08:53

Let's try to keep discussion focused on AV1, guys ;)

Can doom9 promote AV1 and give an sub-forum like for HEVC?

So we can have more specialized threads:

AV1

Software adoptions
HW compatible
libaom
Rav1e
Dav1d
Tune with parametres
10bit and 12bit
Quality compare
Performance compare
Custom Builds
Containers
Etc...

hajj_3

18th September 2018, 08:57

???

xHE-AAC, Opus, HEVC and VP9 were all standarized at the same time.

VP9, HEVC and Opus were adopted in many applications.

xHE-AAC? Name me one functional encoder. 6 years and counting.
No market for its licensing (Opus did it), awfully late and too little.
xHE-AAC is dead.

xHE-AAC was added to the DRM+ digital radio standard which india is rolling out. It may still become popular in the future if DRM+ becomes popular.

I can't see it becoming popular online due to the patent costs especially as Opus 1.3 has improved lower bitrates recently and will continue to improve.

foxyshadis

18th September 2018, 11:14

Can doom9 promote AV1 and give an sub-forum like for HEVC?

So we can have more specialized posts:

News
Software adoptions
HW decode compatible
HW encode compatible
Tune with parametres (libaom-av1)
Tune with parametres (ffmpeg)
Tune with parametres (others)
10bit and 12bit
Quality compare
Performance compare
Custom Builds
Containers
Etc...

As much as I'm hoping AV1 sets the world on fire, especially once it's released from Google's "performance? who needs optimization when you have the world's largest server farm?" attitude, Doom9 is about interest more than promotion. So far there just aren't that many posts about AV1; compare the HEVC forum. Some of those threads are obvious duplicates or way too niche, but if you want to go ahead and found a dedicated AV1 tuning or comparison thread, go ahead.

News goes in the news forum, naturally.

hydra3333

18th September 2018, 13:59

So far there just aren't that many posts about AV1; compare the HEVC forum.
OK. Possibly only for now, though ? A novice like me and perhaps most punters may have reasonably inferred that with google and so many (almost all ?) large industry players signed up and behind it that it is likely to receive growing attention. Just a thought.

IgorC

18th September 2018, 18:09

Sorry for offtopic. Last one and probably will get it somewhere else.
Any links? The only thing I got was from Wikimedia

https://phabricator.wikimedia.org/T166025

Which state LC-AAC to be patents free in 2018! This is big news.
It's difficult to say. I'm not a lawyer. I just saw some patent related estimations here http://www.ecodis.de/audio.htm
Especially when laws change per country. Also there are decoding and encoding related patents. MP3 decoding related patents have expried in 2015 but encoder patents in 2017. https://www.cs.helsinki.fi/group/pakkaamo/docs/legal.pdf

It might be the case that patents of LC-AAC have already expired.
Will investigate.

Nintendo Maniac 64

18th September 2018, 23:49

The new ffmpeg builds with a newer libaom-av1 improves performance a lot (like SmilingWolf said)

MPC-HC v1.8.2 also got released - could you perhaps confirm/deny whether its built-in LAVfilters also contain these performance improvements?

Thing is, I saw no performance gains when using 1.8.2 vs 1.8.1, so I need to confirm/deny whether my performance issue is persisting or whatnot.

I did however notice that, out of the three cores being utilized on my Xeon x3470, one of them is pretty much fully pegged and the other two are about half utilization - this would then equal the ~25% utilization I'm seeing.

Now normally I would let this all go as simply a case of "not having fast enough single-threaded performance" and be done with it, but the fact that you and others were seeing over 60% utilization on your own 4c/8t CPUs (which implies it was balancing the load across more than 4 threads) makes me thing something still isn't quite right here - I mean, weaker single-threaded performance shouldn't result in fewer threads being utilized, and if anything you'd want it to be the opposite, no?

lvqcl

19th September 2018, 11:58

I downloaded aom-master.tar.gz (that is, the latest sources), recompiled libaom amd ffmpeg libs myself, and I cannot see speed increase over vanilla LAVFilters-0.72.0-13.

Also: according to LAVFilters sources, it uses AV1 library v1.0.0-552-gbb82e05fb which does have that "row-based multi-thread decoding" patch.

Selur

19th September 2018, 16:21

Got a few additional questions about aomenc, since I couldn't find any doc about it.

Does anyone know where I can lookup the default values for all the options where the help doesn't provide a default value?
What are the allowed values for '--usage' and '--profile'?
What is the difference between 'Usage' and 'Bitstream' profile?
What are the 'forced_max_frame_width' and 'forced_max_frame_height' values for? Does the force to encoder to internally not downscale width/height?
What is the recommend value for '--timebase' and when should one change this value?
What is the 'resize-mode'-option for and what are valid values for it?
What are the 'superres' options for?
What are S-frames and what are the sframe-modes?
What does the 'input-chroma-subsampling' options for and what are valid values for them?

Thanks for anyone who help with some answers. :)

Cu Selur

SmilingWolf

19th September 2018, 17:19

Got a few additional questions about aomenc, since I couldn't find any doc about it.

Does anyone know where I can lookup the default values for all the options where the help doesn't provide a default value?

You can check some defaults here: https://aomedia.googlesource.com/aom/+/master/av1/encoder/speed_features.c
Not the most user friendly way but that's all there is for now unfortunately

As for the other questions, my best guess is that they are described one way or the other in the spec.
Or in the sources... somewhere. Yeah not quite the best for end users.

easyfab

19th September 2018, 17:30

encoding default :
https://aomedia.googlesource.com/aom/+/master/av1/av1_cx_iface.c#107

Selur

19th September 2018, 17:31

Thanks! :)
about s-frames (switching frames): https://www.youtube.com/watch?v=o5sJX6VA34o seems to be only interesting for abr low latency live streaming, so not interesting when you don't have multiple streams of different bitrates available.

Blue_MiSfit

19th September 2018, 22:51

Very cool. I should go to Demuxed this year!

lvqcl

20th September 2018, 01:19

Found this comment (https://aomedia.googlesource.com/aom/+/master/av1/decoder/dthread.c#44) in libaom code:
// TODO(hkuang): Fix the pthread_cond_broadcast in windows wrapper.
Apparently it was made in this commit for vp9 (https://chromium.googlesource.com/webm/libvpx/+/d5fa786b4f881bc50663a0c1333a053e99406dfa%5E%21/vp9/decoder/vp9_dthread.c). I wonder is it still true?

(Also, libaom phtreads wrapper (https://aomedia.googlesource.com/aom/+/master/aom_util/aom_thread.h) has a lot of code for pre-Vista Windows. Why? Nobody bothered to clean it up? ;))

LigH

20th September 2018, 07:34

The last issue (unaligned memory access in GCC 8.2.0) was marginally related to cleaning up VP9 remains... :o

marcomsousa

21st September 2018, 08:03

I have diferent Coding path when encoding with differents aom builds with the same y4m.

Coding path: LBD
Coding path: HBD

Can't you explain why and how to change this?

SmilingWolf

21st September 2018, 08:47

My builds come with the CONFIG_LOWBITDEPTH build option enabled.
It enables 8bit content optimized codepaths, which work roughly 2x (in theory) - 1.75x (in practice) faster than the high (10-12) bit depth codepaths because you can stuff 8 bits in just 8 bits of memory, while to use 10-12bits you need to use 16 bits of memory, halving the throughput.
The default of that build options is 0, which means the 8bits codepaths are never used, and a lot of builds out there just use default settings (MABS ones in primis).

Lotsa yadda yadda on my part, issues 2062 (https://bugs.chromium.org/p/aomedia/issues/detail?id=2062) and 2147 (https://bugs.chromium.org/p/aomedia/issues/detail?id=2147) probably explain better what this means for end users

Side note: today's build are complete, few minutes they'll be up on MEGA.
There's a little feature I've been keen to try for a long time now: loop filter bitmask (https://aomedia.googlesource.com/aom/+/84b09935284d56def49cca7d7f79aa8265566c0b) for decoding, which promises a 6% decoding performance increase in single thread (https://aomedia.googlesource.com/aom/+/c75fb08f653b7614cdbe8e840140cb6617022ce3)

LigH

21st September 2018, 08:51

I will mention this in the MABS project, maybe wiiaboo agrees to enable it (or even make a choice to build either or both, like for x264 and x265, unless that are able to provide a multilib solution as well).

SmilingWolf

21st September 2018, 09:09

I think there's no need for CONFIG_LOWBITDEPTH=0 builds, with CONFIG_LOWBITDEPTH=1 the appropriate codepaths are selected automatically based on input and output bit depths.

Today's build:
av1-1.0.0-629-g7b9ddd4bf: https://mega.nz/#!cg5njRjA!WZkuEg2g7qDdAjq19nAhd3dlGnQa-vEcCgQL5_vRMY8

Cautionary note: the issues tracker has been populating quite fast the last couple of days, so there's a chance this is not the most stable build to work with.
I have just finished a series of encodes that took all week , so I'll be able to try it and report back if anything nasty happens.
Also, some coding features have been temporarily disabled for row-mt (https://aomedia.googlesource.com/aom/+/2fc59df195a7579bb8d5e6223da26e883d0f7a02) to accomodate some corner cases

Silver lining: the code is being modified to enable easier debugging of threading related issues, so maybe we'll see some newfound stability on that front in the coming days/weeks

marcomsousa

21st September 2018, 13:14

I'm building (yet another version) AOM with Visual Studio 2017 from sources.

They are automatically builds

AV1 executable builds: here (https://ci.appveyor.com/project/marcomsousa/build-aom/build/artifacts)
I also open source the build scripts at Github: here (https://github.com/marcomsousa/build_aom)

I note that with VS2017 generates a lot of *.exe compare with gcc

aomdec.exe
decode_with_drops.exe
decode_to_md5.exe
twopass_encoder.exe
dump_obu.exe
lightfield_decoder.exe
lightfield_bitstream_parsing.exe
lightfield_encoder.exe
aom_cx_set_ref.exe
lightfield_tile_list_decoder.exe
aomenc.exe
lossless_encoder.exe
noise_model.exe
scalable_decoder.exe
resize_util.exe
scalable_encoder.exe
set_maps.exe
simple_encoder.exe
simple_decoder.exe

At this moment I'm only saving aomenc.exe and aomdec.exe.
You can do pull requests to improve this script.

SmilingWolf

21st September 2018, 13:31

All of that EXEs are generated under MSYS2 too, they are simply not installed by "make install" because they are examples or test tools, not meant for the end user.
# find . -name \*.exe -type f
./aomdec.exe
./aomenc.exe
./CMakeFiles/3.12.1/CompilerIdC/a.exe
./CMakeFiles/3.12.1/CompilerIdCXX/a.exe
./examples/aom_cx_set_ref.exe
./examples/decode_to_md5.exe
./examples/decode_with_drops.exe
./examples/lightfield_bitstream_parsing.exe
./examples/lightfield_decoder.exe
./examples/lightfield_encoder.exe
./examples/lightfield_tile_list_decoder.exe
./examples/lossless_encoder.exe
./examples/noise_model.exe
./examples/scalable_decoder.exe
./examples/scalable_encoder.exe
./examples/set_maps.exe
./examples/simple_decoder.exe
./examples/simple_encoder.exe
./examples/twopass_encoder.exe
./resize_util.exe
./tools/dump_obu.exe
Love the AppVeyor integration! Thanks!

LigH

21st September 2018, 13:54

marcomsousa

21st September 2018, 14:04

Just chatted a bit in IRC ... gnafu believes that CONFIG_LOWBITDEPTH=1 is a) still necessary to be set at compile time, b) in general useful, because it enables an optimized code path for 8 bit precision only, but does not alter the behaviour of higher bit depths.

I hope he is right.

I tested with CONFIG_LOWBITDEPTH=1 and it's faster. But it was disable because something...

Turn off CONFIG_LOWBITDEPTH by default

CodecWG agreed to have this off for default "C" model.
Commit (https://aomedia.googlesource.com/aom/+/155120f44aad2fce30f5a8a4ba2a15653e0e2f8f%5E%21/)

alex1399

21st September 2018, 16:50

Who is gnafu?

SmilingWolf

21st September 2018, 16:59

Who is gnafu?

https://freenode.logbot.info/aomedia/20180921

If your question is "who's him in the project", I think he's just an enthusiast like most of the people here on doom9

SmilingWolf

21st September 2018, 17:48

Graphs time! Click to enlarge
Y axis: chosen metric
X axis: bits per pixel

720p:
https://thumb.ibb.co/fj5BWe/msssim_720.png (https://ibb.co/fj5BWe)https://thumb.ibb.co/dnZS4z/psnrhvsm_720.png (https://ibb.co/dnZS4z)

1080p:
https://thumb.ibb.co/fW9GxK/msssim_1080.png (https://ibb.co/fW9GxK)https://thumb.ibb.co/irpujz/psnrhvsm_1080.png (https://ibb.co/irpujz)

BD rates for 720p:
rav1e -> x264
RATE (%) DSNR (dB)
MSSSIM -18.3758 0.910887
PSNRHVS -17.3064 1.14428

x264 -> x265
RATE (%) DSNR (dB)
MSSSIM -25.6195 1.21115
PSNRHVS -29.8289 1.83058

x265 -> av1
RATE (%) DSNR (dB)
MSSSIM -16.6292 0.680221
PSNRHVS -13.0642 0.641722

BD rates for 1080p:
rav1e -> x264
RATE (%) DSNR (dB)
MSSSIM -19.4204 0.869977
PSNRHVS -16.9114 0.949348

x264 -> x265
RATE (%) DSNR (dB)
MSSSIM -28.9956 1.18206
PSNRHVS -31.474 1.63676

x265 -> av1
RATE (%) DSNR (dB)
MSSSIM -24.1474 0.840846
PSNRHVS -19.4281 0.796909

Clips used for 720p: F.Y.C, KimiNoNa720, PresageFlowerFight720, PresageFlowerWalk720, TearsOfSteel720, TheFifthElement, ThisIsHalloween
Clips used for 1080p: KimiNoNa, PresageFlowerFight, PresageFlowerWalk, TearsOfSteel

Encoders:
x264 157-2932-303c484
x265 2.8-68-fa57fa584898
rav1e 0.1.0-315-1fa32bbd
av1 1.0.0-577-g8ae39302e

VQM Tools:
dump_msssim and dump_psnrhvs from the daala git repo: https://github.com/xiph/daala
Everything glued together with some bash and python2 scripts
The metrics used are from the Total field of the tools' output, so they take into account both luma and chroma. In dump_msssim this just looks like an arithmetic mean between the three measurements, while dump_psnrhvs applies some weighting.
The final metrics-per-resolution have been obtained taking the measurement for each clip and weighting it with the number of pixels.

Cmdlines:
x264 --preset veryslow --tune ssim --crf 16 -o test.x264.crf16.264 orig.i420.y4m
x265 --preset veryslow --tune ssim --crf 16 -o test.x265.crf16.hevc orig.i420.y4m
rav1e -o test.rav1e.cq80.webm --quantizer 80 -s 3 --tune psnr orig.i420.y4m
aomenc --frame-parallel=0 --tile-columns=6 --auto-alt-ref=1 --cpu-used=4 --tune=psnr --passes=2 --threads=4 --end-usage=q --cq-level=20 --test-decode=fatal -o test.av1.cq20.webm orig.i420.y4m

Quality settings:
x264: CRF 16-24 step 1, and 24-34 step 2
x265: CRF 16-24 step 1, and 24-34 step 2
rav1e: CQ 80-160 step 16
aomenc: CQ 20-40 step 4

Clips used:
F.Y.C: https://amvnews.ru/index.php?go=Files&in=view&id=6801, second link, the 250.78Mb one. Clip cut with ffmpeg -ss 00:00:10 -t 20, 1280x720, 480 frames
KimiNoNa and KimiNoNa720: scene from the Kimi no Namae Wa, BD source. Clip cut with ffmpeg -ss 00:01:13 -t 17, 1920x1080, 410 frames
PresageFlowerFight and PresageFlowerFight720: scene from Fate/stay night: Heaven's Feel - Presage Flower, BD source. Clip cut with ffmpeg -ss 00:43:50 -t 15, 1920x1080, 360 frames
PresageFlowerWalk and PresageFlowerWalk720: scene from Fate/stay night: Heaven's Feel - Presage Flower, BD source. Clip cut with ffmpeg -ss 00:15:14 -t 13, 1920x1080, 312 frames
TearsOfSteel and TearsOfSteel720: https://media.xiph.org/tearsofsteel/tearsofsteel-1080bis-png/ frames 13500 to 13900, 1920x800, 400 frames
TheFifthElement: clip found on the #aomedia channel: https://freenode.logbot.info/aomedia/20180726 -> themayhaks.com/~gideon/tfe.mkv, 1280x534, 240 frames
ThisIsHalloween: https://www.animemusicvideos.org/members/members_videoinfo.php?v=196998, second link, the LOCAL/123 MiB one. Clip cut with ffmpeg -ss 00:01:50 -t 15, 1280x720, 450 frames

Clips notes/misc details:
All of them have been losslessly cut and stored in FFv1 in an MKV container to serve as master files, decoded to y4m for encoding. All the master files use 8bits 4:2:0 subsampling, and so do the encodes.
The *720 clips actually have been resized to a 1280 width and the heigth has been adjusted accordingly, so either 720 or 534 as required to keep the aspect ratio.
Resizing done with ffmpeg using the z.img library/zscale video filter, using a 4 taps lanczos kernel.
F.Y.C: mixed and superimposed anime/real life content, lots of effects, rain in a couple of scenes, fast motion, flashes, many scenecuts. AMV encoder unknown, final bitrate around 9.4Mb/s
KimiNoNa and KimiNoNa720: anime, detailed backgrounds, brief scene with moving croud, cut to moving trains, cut to moving background with static foreground, few scenecuts
PresageFlowerFight and PresageFlowerFight720: anime, fight between Rider and Saber for whoever knows what I'm talking about, lots of particles at some point, reasonably fast motion, few scenecuts
PresageFlowerWalk and PresageFlowerWalk720: anime, MC just walking around in the school, no really detailed backgrounds, mostly static and slow, very few scenecuts
TearsOfSteel and TearsOfSteel720: real life with synthetic/rendered elements, smoke, rapid camera movement and motion, very few scenecuts
TheFifthElement: real life, lots of film grain, static, very few scenecuts. The original uploader sourced the clip from the BD and resized it himself
ThisIsHalloween: anime, no effects, some flames in a scene, mostly static but brief scenes, many scenecuts. Scenes used come from the BD box of the anime (Soul Eater), the final encode of the AMV has been made with x264, CRF 15 and --preset veryslow --tune animation, final bitrate around 4.3Mb/s

As you have already noticed, my testbed mostly covers my personal interests: AMVs (F.Y.C and ThisIsHalloween) and anime in general, with some real life content thrown in the mix
Natural consequence, since I tailored this to my needs, is that I used only encoding settings I felt confortable with, especially with aomenc:
- maximum number of tiles allowed per clip for smooth playback and (whenever it didn't bug out) multithreaded encoding
- cpu-used no lower than 4 or I would have never seen the end of it

Alright, wall of text over, I'm open to any kind of feedback since I'm posting this to get corrections or suggestions