Alliance for Open Media codecs

[LigH]

Bloated and partially insecure.

[Quikee]

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]

Mail just went out from AOMedia, looks like AV1 is now a codec :)

[hajj_3]

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

[iwod]

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]

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]

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.

[bstrobl]

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]

And I notice the membership page

https://aomedia.org/membership/members/

Apple is the only one not using its logo?

[iwod]

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]

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]

@iwod: Where is your quote from?

[v0lt]

Are there already video files that fully comply with the approved specification?

[JEEB]

@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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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?

[LigH]

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]

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]

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

[TomV]

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]

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]

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]

^^ Exactly

[hajj_3]

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]

AOM v0.1.0-9043-g6f49b5a21 (I noticed several CLI changes)

[wiak]

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]

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]

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]

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]

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]

There is "rav1e" - rust AV1 encoder from Mozilla/Xiph guys: https://github.com/xiph/rav1e

Interesting. Is this completely written from scratch?

[mzso]

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]

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]

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]

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]

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]

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]

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]

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]

Indeed, though we're still only talking about 75% CPU utilization compared to <40%
av1 is less than 1%
:stupid: