Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
21st August 2020, 08:11 | #1 | Link | |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
SVT-AV1 announced as the official AV1 encoder of AOMedia
https://www.businesswire.com/news/ho...roup-Bring-AV1
Quote:
aomenc will continue as a research codec for AV2 development. |
|
21st August 2020, 22:03 | #2 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,989
|
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.
|
22nd August 2020, 03:59 | #3 | Link |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
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.
|
24th August 2020, 02:01 | #5 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
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. |
26th August 2020, 22:23 | #6 | Link | |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
Quote:
I just realized, so this is why they hunted down all their contributors to relicense the library over the last few months. |
|
27th August 2020, 18:36 | #7 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
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. |
|
28th August 2020, 12:49 | #8 | Link | |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
Quote:
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. |
|
28th August 2020, 19:11 | #9 | Link | |
Registered User
Join Date: May 2005
Location: Swansea, Wales, UK
Posts: 196
|
Quote:
I was under the impression that they heavily borrowed from the x264 code base to speed up early development? |
|
29th August 2020, 08:22 | #10 | Link |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
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.
|
29th October 2020, 18:48 | #12 | Link |
Doom9ing since 2001
Join Date: Oct 2001
Location: Seattle, WA, USA
Posts: 2,002
|
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.
Code:
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 Code:
------------------------------------------- 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 ------------------------------------------- Last edited by zambelli; 29th October 2020 at 18:50. |
30th October 2020, 11:58 | #14 | Link |
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,277
|
tried your command line:
Code:
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 then I removed the '-g 120' Code:
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 then I tried without the '-keyint_min 120' Code:
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 -> seems like an issue with the '-g 120'-parameter Cu Selur |
30th October 2020, 18:02 | #15 | Link |
Doom9ing since 2001
Join Date: Oct 2001
Location: Seattle, WA, USA
Posts: 2,002
|
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.
|
30th October 2020, 20:53 | #16 | Link |
Registered User
Join Date: Jan 2019
Location: Canada
Posts: 574
|
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. |
30th October 2020, 21:12 | #17 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
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. Last edited by benwaggoner; 6th March 2021 at 00:31. Reason: Fixed "long GOP" when I meant "short GOP." |
|
5th March 2021, 09:40 | #18 | Link |
Anime addict
Join Date: Feb 2009
Location: Spain
Posts: 673
|
They are in https://gitlab.com/AOMediaCodec/SVT-AV1 now
__________________
Intel i7-6700K + Noctua NH-D15 + Z170A XPower G. Titanium + Kingston HyperX Savage DDR4 2x8GB + Radeon RX580 8GB DDR5 + ADATA SX8200 Pro 1 TB + Antec EDG750 80 Plus Gold Mod + Corsair 780T Graphite |
|
|