Eagerly awaited across the tech industry, this week the Alliance for Open Media (AOMedia) has published the first complete version of the bitstream and decoding process specification for their royalty-free AV1 video codec. The release of the AV1 1.0 spec will enable backers of AOMedia to add support for the technology to their products or services, including taking the all-important step of finalizing the designs for the low-power hardware decoders critical for driving the codec's adoption. At least initially, AV1 will be used primarily for streaming video and user-generated content as an alternative to HEVC and its ongoing royalty disputes, but eventually adoption of AV1 may expand to other applications.

The AV1 open-source video codec was developed with 4K+ ultra-high-def resolutions, HDR, and wide color gamut in mind. Among the key features the new codec, AOMedia mentions a 30% more efficient compression algorithm compared to existing methods, predictable requirements for computational capabilities of hardware, and maximum flexibility and scalability. The backers of the AV1 want the codec to be ubiquitous across devices and platforms, therefore expect it to be supported not only by major chipmakers, software designers, and service providers, but also by leading makers of consumer electronics.

AOMedia does not disclose key technological peculiarities of the AV1 video codec in a short whitepaper form, meanwhile parsing through a 600-page bitstream and decoding spec for developers does not necessarily help to explain all the peculiarities of the tech in general. Therefore, I am going to limit technical details about the AV1 to a necessary minimum here.

On a high level, the AV1 is conceptually similar to existing codecs, such as H.264 or H.265. AV1 uses the same basic elements as various codecs have used for well over a decade: block-based coding, variable block sizes (up to 128x128 pixels), block motion compensation, intra-frame compression, forward-integer transform and so on. Meanwhile, since we are talking about compression algorithms more efficient than existing ones, it is natural that the AV1 has a number of advantages over contemporary codecs.

The AV1 performs internal processing in 8, 10 or 12 bits per sample precision, it also supports all three widespread types of chroma subsampling (4:2:0, 4:2:2, 4:4:4), and virtually all major color gamuts and formats (sRGB, BT.2020 (both 10-bit and 12-bit), BT.2100, etc.). The BT.2020 and the BT.2100 recommendations include support not only for 3840×2160, but also for 7680×4320 (8K) resolution, so the AV1 is technically ready for the next-gen monitors and TVs.

AV1 Profiles
seq_profile Bit Depth sRGB Gamut Support Chroma Subsampling
0 8 or 10 No YUV 4:2:0
1 8 or 10 Yes YUV 4:4:4
2 8 or 10 No YUV 4:2:2
2 12 Yes YUV 4:2:0
YUV 4:2:2
YUV 4:4:4

Speaking of displays, it is necessary to note that the AV1 was designed to be compatible with existing interconnections, such as DisplayPort, eDP, HDMI and so on. That said, the technology should also be compatible with contemporary content protection technologies.

The publication of the AV1 spec 1.0 is merely the first step towards adoption of the technology by the market. AOMedia expects content creation tools and desktop browsers to begin to roll out support for AV1 later this year. To ensure this, AOMedia released an unoptimized/experimental AV1 software decoder and encoder for use in software applications. Then, sometimes in 2019, the consortium anticipates select chips and programs to support the tech. More widespread support of the AV1 along with adoption by software is projected for 2020.

Speaking of adoption, the list of AOMedia members includes a variety of influential companies, including Apple, Amazon, AMD, Arm, Broadcom, Facebook, Google, Hulu, Intel, IBM, Microsoft, Netflix, NVIDIA, Realtek, Sigma and many others. These companies either control huge ecosystems themselves, or develop chips that are used by hundreds of millions of customers worldwide. Their support will ensure widespread adoption of the AV1 in the next decade. In the meantime, AOMedia has already started R&D for the AV2, which is to succeed the AV1 codec.

Related Reading:

Source: AOMedia



View All Comments

  • ZolaIII - Friday, March 30, 2018 - link

    VLC for video and Foobar2000 for audio (among others) & you are done with what ever when ever you will need with Opus. Naturally both are cross platform enough to get 90+% coverage on desktop and mobile. It's neither Opus fault nor it's developers why app developers & device vendors are lazy to implement something which is both open source & well documented. Reply
  • npz - Friday, March 30, 2018 - link

    I had stated native OS support and hw acceleration support not app support for OPUS. Youtube will choose that over sw accell only and thus for anything other than linux and the like you wont get the VP9 stream Reply
  • ZolaIII - Saturday, March 31, 2018 - link

    Opus has a FP support so it's possible to make; SIMD, DSP and ASIC for it. But why would anyone really bother with it? It's still rather light on it's encode/decode requirements so that it can be done even on tiny weak ARM cores in the real time. Actually full band Opus is almost not at all charged Ogg in new container of course. In narrow band it's a magic with the hybrid two codec combo. Do you use or ever used the OS integrated MP3 codec or Ogg codec? Did you stay on their as in OS integrated implementation? Finally ware they really hardware decoded? Also for a sake of argument of how much Opus is wide spread in current real usage Skype also use it in mentioned narrow band hybrid mode. Vp9 hardware decoding is for instance supported on Android from Nugget if their is a vendor provided solution for such use & again if OEM implemented it. At the end it's all about lazy OEM's and vendors especially when it comes to superior solutions that doesn't cost them a 10¢. Reply
  • ZolaIII - Saturday, March 31, 2018 - link

    Also Google doesn't care what you think or feel about it, Vp9 helped them to reduce bandwidth requirements on their servers on FHD videos compared to H264 one's used before for some 25% & that alone while not really costing them much (as they in this case developed it on their on which cost's R&D money). For them single sole savings on electricity ware work wile enough. Now when all together companies can share & save on development and research for a future generations by splitting the expenses and working together or simply not spend nothing at all with an cost to gain info about it later using the Open source solution when & as published just guess how it will prevail. Reply
  • ZeDestructor - Monday, April 2, 2018 - link

    Google has HEVC streams too. It's mostly used by Safari and iOS and occasionally Android Reply
  • ViRGE - Friday, March 30, 2018 - link

    Unfortunately neither of your major technical points are entirely correct. But I see why you think as you do.

    VP9 Usage: Google prefers to use VP9 on any system where hardware decode support is available (annoyingly, even if it's not full fixed-function support). Besides recent PCs, this also covers most recent Android phones (that is, with an SoC released after 2015 or so).

    Audio Codec: You are correct that Opus is paired with VP9 when available. But it's not exclusive. On my Shield ATV for example, it's VP9 video + AAC audio. On the PC you generally find Opus because the decode overhead is so low. On mobile it's less common since the name of the game is energy efficiency (and you can't necessarily count on having much CPU time for these things).
  • ZolaIII - Saturday, March 31, 2018 - link

    Their simple isn't any argument not to use Opus that will stand. It simply can better represent fidelity of original source with it's 20mn release which helps especially on lo and high tonal spectrum. This are advantages it has over AAC. Over the MP3 it has more from less compression specific artifacts to the more wide band (16KHz on MP3 and 24 (20 real) KHz with Opus per channel) to on flight precision encoding and supported sampling rates of Opus (8,16,24,32 vs 16 on MP3).
    What most people don't & never will understand correctly that when you convert from one to another lossy format (or even more times in the same one) you can only lose on quality as parents inherited compression artifacts are passed & new ones added with compressing it again. The 320KB MP3 converted to 256KB Opus will sound worse but 48KHz 24 bit Flac will sound much better when converted to 320KB Opus than same bitrate MP3 as it will retain both 24 bit & 48KHz in Opus...
  • ZolaIII - Saturday, March 31, 2018 - link

    20ns* Reply
  • bcronce - Saturday, March 31, 2018 - link

    I remember playing around with Opus back when it was in beta. 48kb Opus sounded better than 256kb MP3. Reply
  • ZolaIII - Saturday, March 31, 2018 - link

    Well Opus scales best for wide band & in hybrid mode so 48 & 64kb does sound as 96 & & 128kb MP3 but as you go up Opus advantage shrink to the point that CBR mp3 is better at 256kb but still as Opus has better capabilities native source in 48KHz or more done in 24 or 32 bit will still sound better in Opus as 48KHz 24/32 bit at 320kb VBR than MP3 44KHz 16 bit CBR/VBR... Reply

Log in

Don't have an account? Sign up now