Alliance for Open Media codecs

[mzso]

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]

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]

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]

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]

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]

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]

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]

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]

In UHD resolutions it's more probable for HEVC to be ahead of AVC.

[Mystery Keeper]

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]

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]

btw. is there any news regarding when to expect a bit stream freeze? Last I read was January 2018, which now is gone,.. :)

[mzso]

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]

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]

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]

3000x slower.

Duh, like reference H.265 encoder (HM) was any faster.

[iwod]

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]

So, not ready yet:
https://youtu.be/6UksCRCl_bI
"Almost"

[bstrobl]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

AOM 0.1.0-8039-g01faff973

[benwaggoner]

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]

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.

[Barough]

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]

What's the basic way to pipe video with ffmpeg to aomenc? So far I'm failing miserably.

[sneaker_ger]

ffmpeg -i "input" -f yuv4mpegpipe - | aomenc --passes=1 -o "output.webm" -

[mzso]

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]

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" -

[mzso]

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]

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]

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]

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).

[LigH]

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.

[mzso]

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]

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]

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]

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.