AOMedia Announces Public Release Of AV1 Video Format

[shmerl]

Notable missing from The AOMedia Alliance is Qualcomm (who makes the Snapdragon series SoC), Samsung (who makes the Exynos series SoC), HiSilicon (who makes the Kirin series SoC), and MindGeek (who owns PornHub, XVideos, Redtube, Porntube, etc).

Expected regarding Qualcomm. They are a notorious patent troll when it comes to media codecs. Not sure about others.

[stalkerg]

ok, what about image format? JPEG is very annoying and the situation with WebP too.

[Gusar]

Why apply DRM on the container level when EME exists in the HTML5 spec. Which explains Apple and Netflix participation in all of this (in the case of Apple, they join AOM so late that there wasn't any development from them over AV1), since they (as well as YouTube) have a rather vested intent in how content is distributed.

EME is just a framework through which you load a CDM (content decryption module) like Google Widevine. Said decryption module then decrypts... the container.

Besides, while internet streaming (where EME comes into play) is where AV1 will be used the most, video is not limited to just internet streaming.

[starshipeleven]

Notable missing from The AOMedia Alliance is Qualcomm (who makes the Snapdragon series SoC), Samsung (who makes the Exynos series SoC), HiSilicon (who makes the Kirin series SoC),

Google will probably require hardware acceleration for AV1 in Android devices, the same as they did with VP9.
Qualcomm and others don't have much choice, if they want to sell their SoCs to Android device manufacturers they will comply.

[starshipeleven]

ok, what about image format? JPEG is very annoying and the situation with WebP too.

Also gif. (animated images)

Still, there does not seem to be much pushing on that, probably because there is far far far less money in play.

[Brisse]

Downloaded aomenc source, compiled and started testing a bit on my Ryzen 1700X. Trying to encode a 30 second sample with '-w 1912 -h 800 --tile-columns=2 --frame-parallel=1 --threads=16' and the first pass finished quickly enough, but the second pass is currently doing 2.4 frames per MINUTE with an ETA of almost three days.

SLOOOOOOOOW

[Brisse]

With --tile-columns=4 it saturates all my 16 CPU-theads which I think is a bit interesting because VP9 never did that which made it a bit slower than x265 on my system. VP9 would only saturate 4-6 threads no matter what settings I used.

Still really slow though. With 100% CPU-usage I'm getting 6.42fpm which is just insanity.

[Mrkellog]

Downloaded aomenc source, compiled and started testing a bit on my Ryzen 1700X. Trying to encode a 30 second sample with '-w 1912 -h 800 --tile-columns=2 --frame-parallel=1 --threads=16' and the first pass finished quickly enough, but the second pass is currently doing 2.4 frames per MINUTE with an ETA of almost three days.

SLOOOOOOOOW

Try

https://github.com/xiph/rav1e

Overview

rav1e is an experimental AV1 video encoder. It is designed to eventually cover all use cases, though in its current form it is most suitable for cases where libaom (the reference encoder) is too slow.

Because AV1 is not yet frozen, it relies on an exact decoder version and configuration that is periodically updated.
Features

Intra frames
64x64 superblocks
H, V, and DC prediction modes
4x4 DCT and ADST transforms
~5 fps encoding @ 480p (see issue #124)

[M@yeulC]

I just had a videoconference with some outdated hardware. I now find myself eager to discover the new and improved compression artifacts that this new codec will undoubtedly bring with it

With --tile-columns=4 it saturates all my 16 CPU-theads which I think is a bit interesting because VP9 never did that which made it a bit slower than x265 on my system. VP9 would only saturate 4-6 threads no matter what settings I used.

Still really slow though. With 100% CPU-usage I'm getting 6.42fpm which is just insanity.

That's just a bit better than 4 times slower than realtime, which sounds quite reasonable for a new codec. There's no hardware acceleration yet, and the software is not necessarily optimized. You can bet that decoders will improve faster than encoders, though.
One nice thing about the website is a statement from Xilinx that they would use their FPGAs to bring HW-accelerated encoders to datacenters quickly. That makes a lot of sense IMO, and as a nice bonus, you can easily update the hardware with the latest performance improvements -- you can bet it won't be cheap, also.

One thing I've been wondering is whether this codec supports additive multiple quality streams or not (not sure how to call them, or even if that's really a thing, for that matter). But take Fourier transforms, for example: the more harmonics you include, the more faithful your output is. So you can send a few harmonics if the connection is slow, and scale this number up as needed. Of course, modern compression techniques don't work exactly like this, but as a general principle, I would be surprised if that couldn't apply here (more tiles, displacement information, higher precision, higher bitrates as supplementary channels), and was wondering if this is something that was optimized for. That would be a killer for peertube-style video streaming (or even simple multicast streaming), where everyone receives the lowest quality channel, and add the others as needed. The way it's usually done is to transmit a whole new video file, yay! (and you have to transcode N times when uploading, with N the number of settings you are interested in).

[Brisse]

That's just a bit better than 4 times slower than realtime, which sounds quite reasonable for a new codec.

Nope. Note that it says frames per minute, not second, so that's actually ~224 times slower than realtime. Also, the framerate eventually dropped down to about one frame per minute before I terminated the process.