SVT-AV1 announced as the official AV1 encoder of AOMedia

[foxyshadis]

https://www.businesswire.com/news/ho...roup-Bring-AV1

The Alliance for Open Media (AOMedia) today announced the formation of the AOMedia Software Implementation Working Group (SIWG), a member-driven initiative to aid the development of AOMedia AV1 products and services. The SIWG will use the Scalable Video Technology for AV1 (SVT-AV1) encoder developed by Intel in collaboration with AOMedia member Netflix. The goal is to create AV1 encoder implementations that deliver excellent video compression across applications in ways that remove computational complexity trade-offs for an ever-growing video delivery marketplace. Open to all AOMedia members, which include leading internet and media technology companies, the SIWG Co-Chairs will be Facebook’s Ioannis Katsavounidis and Tencent’s Xiang Li and Intel’s Hassene Tmar will serve as the Software Coordinator.

The GIT repository will move from https://github.com/OpenVisualCloud/SVT-AV1 to https://github.com/AOMediaCodec/SVT-AV1 when the next release is tagged (or shortly after), and for the time being the name will remain SVT-AV1.

aomenc will continue as a research codec for AV2 development.

[Blue_MiSfit]

Interesting! I'm actually quite surprised by this. aomenc and SVT-AV1 currently do well at very different operating points AFAIK, so it will be awhile before SVT-AV1 can cover all those cases.

[foxyshadis]

Originally Posted by Blue_MiSfit

Interesting! I'm actually quite surprised by this. aomenc and SVT-AV1 currently do well at very different operating points AFAIK, so it will be awhile before SVT-AV1 can cover all those cases.

For sure, SVT-AV1 is still heavily oriented toward VOD right now, as you'd expect with Netflix bankrolling it. It's also, to put it mildly, a substantially messier codebase than libaom's right now, but at least there's a dead code removal branch being worked on now.

[dapperdan]

Originally Posted by foxyshadis

aomenc will continue as a research codec for AV2 development.

Is that specifically "a research codec" not "the research codec"?


They dont state it explicitly but I thought they were heavily hinting that SVT would be the main codebase for work on AV2.

[benwaggoner]

Intel's SVT codecs were built from the ground up to support wide parallelization, efficient use of SIMD, and other performance enhancements. For example, clever byte-packing mechanisms that reduce memory bandwidth compared to "standard" practices. Aomenc is fundamentally derived from the old On2 VPx series of encoders which were infamous for poor multithreading more than a decade ago. And the YouTube scenario didn't leverage multiple cores significantly, which was the primary libvpx use case. Getting really wide parallelization out of it was an ongoing struggle, and the number of cores available for encoding keeps going up up up.

Because a faster encoder allows for more rapid iteration on quality tuning, it can be easier to make a fast encoder look good than to make a good-looking encoder fast.

VPx/AOM was always a little unusual in that the reference encoder was also meant to function as a production encoder. The MPEG codecs never had a goal of reference encoders being useful for real-world encoding, which simplified development of them.

[foxyshadis]

Originally Posted by dapperdan

Is that specifically "a research codec" not "the research codec"?


They dont state it explicitly but I thought they were heavily hinting that SVT would be the main codebase for work on AV2.

It may be; I'm not privy to that level of discussion! aomenc is still getting daily commits, both in the mainline maintenance branch and the experimental branches, so where things end up for AV2 is probably still up in the air.

I just realized, so this is why they hunted down all their contributors to relicense the library over the last few months.

[benwaggoner]

Originally Posted by foxyshadis

It may be; I'm not privy to that level of discussion! aomenc is still getting daily commits, both in the mainline maintenance branch and the experimental branches, so where things end up for AV2 is probably still up in the air.

I just realized, so this is why they hunted down all their contributors to relicense the library over the last few months.

The parallelization of SVT-AV1 might cause design overhead that makes it a difficult sandbox for developing blue sky features early in codec development. It'd be hard to quickly implement novel frame types and reference structures on the SVT design. And rate control is complexified by having to figure out target QP for so many frames simultaneously. A more linear waterfall style prototype is likely a lot simpler.

I could easily see delaying core work on SVT-AV2 until there is a clearer design of what AV2 actually looks like as a codec and requires in an encoder.

[foxyshadis]

Originally Posted by benwaggoner

The parallelization of SVT-AV1 might cause design overhead that makes it a difficult sandbox for developing blue sky features early in codec development. It'd be hard to quickly implement novel frame types and reference structures on the SVT design. And rate control is complexified by having to figure out target QP for so many frames simultaneously. A more linear waterfall style prototype is likely a lot simpler.

I could easily see delaying core work on SVT-AV2 until there is a clearer design of what AV2 actually looks like as a codec and requires in an encoder.

Probably a matter of commercial priorities as well. SVT-AV1 still uses fixed frametype hierarchies, since VOD is still its core service, even though they could just steal x264's lookahead decisions; likewise, @hassount just said that only 4:2:0 will be supported at least until next year.

The fact that x265 was created out of the jct-vc reference software is a testament to the sheer will and tenacity of Steve Borho and Min Chen, but it's usually not the most solid of foundations. AV2 needs plenty of room to experiment and avoid early pre-optimized needs.

[soresu]

Originally Posted by foxyshadis

The fact that x265 was created out of the jct-vc reference software is a testament to the sheer will and tenacity of Steve Borho and Min Chen, but it's usually not the most solid of foundations. AV2 needs plenty of room to experiment and avoid early pre-optimized needs.

Eh?

I was under the impression that they heavily borrowed from the x264 code base to speed up early development?

[foxyshadis]

Originally Posted by soresu

Eh?

I was under the impression that they heavily borrowed from the x264 code base to speed up early development?

That came later. The first versions were the reference software + intrinsics to speed up core operations; the very first commit to the x265 repo is "commit JCT-VC HM source with cmake based build scripts". As time went on pretty much the entire codebase was replaced, intrinsics replaced by assembly (some from x264), and also integrated some of x264's rate control and frame decision as a start for their new one in 2014.

[MythCreator]

So there is --enable-hdr, but no reference to set Mastering display color pri, luminance, CLL, FAL, etc.? It's weird

[zambelli]

Has anyone had luck getting SVT-AV1 encoder to work in FFmpeg? I'm using 2020-10-21 gyan.dev build of FFmpeg with libsvtav1 v0.8.5-62, and whenever I run the following command line, libsvtav1 encoder gets initialized properly, all parameters look correctly parsed, encoding process starts - and when the encoder gets past the first 170 frames - it hangs for 1-2 minutes and then FFmpeg terminates without explanation.

ffmpeg -i 720p30_yuv420p10le_source.avs -strict experimental -vcodec libsvtav1 -b:v 2400k -maxrate 9600k -bufsize 9600k -keyint_min 120 -g 120 -la_depth -1 -rc cvbr -preset 6 -colorspace bt709 -color_trc bt709 -color_primaries bt709 -color_range tv output.mkv

Here is what the libsvtav1 console output looks like:

-------------------------------------------
SVT [version]:  SVT-AV1 Encoder Lib v0.8.5-62-g80ec5ae75
SVT [build]  :  GCC 10.2.0       64 bit
LIB Build date: Oct 21 2020 17:05:32
-------------------------------------------
Svt[warn]: The VBR and CVBR rate control modes are a work-in-progress projects, and are only available for demos, experimental and further development uses and should not be used for benchmarking until fully implemented.
Number of logical cores available: 4
Number of PPCS 174
[asm level on system : up to avx2]
[asm level selected : up to avx2]
-------------------------------------------
SVT [config]: Main Profile      Tier (auto)     Level (auto)
SVT [config]: Preset                                                    : 6
SVT [config]: EncoderBitDepth / EncoderColorFormat / CompressedTenBitFormat     : 10 / 1 / 0
SVT [config]: SourceWidth / SourceHeight                                        : 1280 / 720
SVT [config]: Fps_Numerator / Fps_Denominator / Gop Size / IntraRefreshType     : 30 / 1 / 120 / 2
SVT [config]: HierarchicalLevels  / PredStructure                               : 4 / 2
SVT [config]: RCMode / TargetBitrate (kbps)/ LookaheadDistance / SceneChange   : Constraint VBR / 2400 / 119 / 0
-------------------------------------------

I've tried reducing GOP and lookahead durations, switching to VBR RC, using an yuv420p source instead of yuv420p10le... The encoder always hangs after 170-180 frames.

[benwaggoner]

Have you tried running in debug mode to get more granular output from ffmpeg?

[Selur]

tried your command line:

ffmpeg -i "f:\TestClips&Co\files\10bit Test.mkv" -strict experimental -vcodec libsvtav1 -b:v 2400k -maxrate 9600k -bufsize 9600k -keyint_min 120 -g 120 -la_depth -1 -rc cvbr -preset 6 -colorspace bt709 -color_trc bt709 -color_primaries bt709 -color_range tv e:\output.mkv

and finished after 2 frames.
then I removed the '-g 120'

ffmpeg -i "f:\TestClips&Co\files\10bit Test.mkv" -strict experimental -vcodec libsvtav1 -b:v 2400k -maxrate 9600k -bufsize 9600k -keyint_min 120 -la_depth -1 -rc cvbr -preset 6 -colorspace bt709 -color_trc bt709 -color_primaries bt709 -color_range tv e:\output.mkv

and a valid output was produced.
then I tried without the '-keyint_min 120'

ffmpeg -i "f:\TestClips&Co\files\10bit Test.mkv" -strict experimental -vcodec libsvtav1 -b:v 2400k -maxrate 9600k -bufsize 9600k -g 120 -la_depth -1 -rc cvbr -preset 6 -colorspace bt709 -color_trc bt709 -color_primaries bt709 -color_range tv e:\output.mkv

encoding ended again after 2 frames and a zero byte output file.
-> seems like an issue with the '-g 120'-parameter

Cu Selur

[zambelli]

Originally Posted by Selur

-> seems like an issue with the '-g 120'-parameter

Thanks for debugging that! I wonder if 120 is too long of a GOP for the encoder to handle, or if something else is going on. The encoder defaults to GOP = 33 frames, which is a strange GOP duration, so perhaps 120 is violating some obscure rule.

[quietvoid]

Possibly related: https://github.com/AOMediaCodec/SVT-...ment-697933656
The default has `enable_tpl_la` enabled, and your lookahead is at 119, as well as rate control enabled.

[benwaggoner]

Originally Posted by zambelli

Thanks for debugging that! I wonder if 120 is too long of a GOP for the encoder to handle, or if something else is going on. The encoder defaults to GOP = 33 frames, which is a strange GOP duration, so perhaps 120 is violating some obscure rule.

33 is the default in Main Concept's H.264 and HEVC encoders, and thus what the Adobe encoder defaults to. It's odd that such an odd number would show up in multiple places. I bet there's a common origin.

With a modern codec, 33 is a really SHORT GOP. Something that short made since with MPEG-2, since the floating point DCT meant that different FP calculation methods could result in drift over a GOP. The default DVD of 0.6 maximum meant that, at 30p and 2 B-frames, there would only be at most 9 reference frames away from the IDR to accumulate error. But in the iDCT era, that became a non-issue. Even VC-1 did totally fine with >100 frame GOPs. The much more efficient prediction in modern codecs also mean that an IDR is larger relative to P or B on average, so the total compression efficiency hit of frequent GOPs is larger. I can't think of anything other than Blu-ray which used less than a 2-sec GOP with H.264 (and even Blu-ray supported 2-sec GOPs at 15 Mbps or below).

AV1 is certainly in the same boat, and I'd think 48 frames is about the smallest GOP we'd ever see in practice, and larger would be generally preferable with a mature encoder.

[Overdrive80]

They are in https://gitlab.com/AOMediaCodec/SVT-AV1 now