Alliance for Open Media codecs

[dapperdan]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

I wonder where Apple is in all of this?

[BadFrame]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[dapperdan]

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]

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]

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]

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]

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]

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]

AMD, ARM, and Nvidia have joined,

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

[mandarinka]

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]

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]

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]

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

[mandarinka]

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]

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]

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]

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]

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]

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]

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]

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]

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.

[benwaggoner]

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]

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]

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]

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]

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.
And how did they look? With such close values, PSNR and SSIM aren't going to be that informative.

[Jamaika]

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]

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]

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.