Intel SVT-HEVC encoder

[TEB]

hi, anyone tested this one? and benchmarked it with speed vs. quality (VMAF 95ish) ?

https://github.com/intel/SVT-HEVC


https://www.phoronix.com/scan.php?pa...Speed-Progress


Reading this :
https://01.org/sites/default/files/d...sual_cloud.pdf

SVT-HEVC achieves similar quality levels to those of HM16, while being 70:1 faster, and similar quality
levels to those of x265 very slow, while being 176:1 faster.

Quite the statement

[benwaggoner]

It doesn't have as deep tuning parameters as x265, but offers subjective quality optimization and deeper reference frame hierarchy. And they even have subjective DMOS scores!

I don't see at what bitrates the comparisons are made, though. If at really high bitrates, it's not that exciting to say "subjective quality is similar to other encoders." Testing should be done in the range so that the very best encode has at least a Just Noticeable Difference from the source. Thus the codecs are demonstrating at bitrates where "perfect" isn't obtainable, and we can see the tradeoffs and blind spots of each.

Also, I am reminded that x265 still doesn't include --tskip in veryslow or placebo. Stock "veryslow" still has more juice to squeeze out (although at further cost of speed). I'm guessing this test used pre 3.0 x265, so the performance difference compared to 3.0's veryslow would be even bigger.

[utack]

x265 can now also use SVT
http://x265.org/x265-svt-hevc-house/

[dipje]

I've done a very short (and wrong ) test with 1.3 compiled into ffmpeg 4.1.

I've re-encoded a 5 second clip Sony 1920x1080 25fps h264 +/- 50mbit slog2 that had a small object moving fast.
As a baseline tried starving the codecs a bit.
X264 preset slow, two pass 500k bitrate, yielded a VMAF +/- 76.
X265 preset medium two pass 500k bitrate, yielded a VMAF +/- 86 (but was slower to encode )
Libsvt_hevc vbr to actually hit around 600k (single pass always ) , yielded a VMAF of +/- 75.

Tried again in cqp mode , changing the qp to hit a bitrate of about twice that. Than tried x264 in preset slow with CRF mode, adjusting the CRF value to get a final filesize that is just under the libsvt one. Svt hit VMAF of 80, x264 VMAF of 86.

So, this isn't a serious test at all. Just a little start for me. The clip is too short, it's ungraded, VMAF doesn't tell you all there is, etc...
But svt seems fast but sacrifices Soo much in the quality that x264 can match it for not that much slower.

It's a software only solution that encodes real-time easily on my 8-series i5 ultrabook...but does not offer Soo much value for 1920x1080 for me it seems.

Again, wrong test so don't take it for granted . Files with proper contrast and 4k would be a much more interesting case.

[benwaggoner]

Originally Posted by dipje

I've done a very short (and wrong ) test with 1.3 compiled into ffmpeg 4.1.

I've re-encoded a 5 second clip Sony 1920x1080 25fps h264 +/- 50mbit slog2 that had a small object moving fast.
As a baseline tried starving the codecs a bit.
X264 preset slow, two pass 500k bitrate, yielded a VMAF +/- 76.
X265 preset medium two pass 500k bitrate, yielded a VMAF +/- 86 (but was slower to encode )
Libsvt_hevc vbr to actually hit around 600k (single pass always ) , yielded a VMAF of +/- 75.

Tried again in cqp mode , changing the qp to hit a bitrate of about twice that. Than tried x264 in preset slow with CRF mode, adjusting the CRF value to get a final filesize that is just under the libsvt one. Svt hit VMAF of 80, x264 VMAF of 86.

So, this isn't a serious test at all. Just a little start for me. The clip is too short, it's ungraded, VMAF doesn't tell you all there is, etc...
But svt seems fast but sacrifices Soo much in the quality that x264 can match it for not that much slower.

It's a software only solution that encodes real-time easily on my 8-series i5 ultrabook...but does not offer Soo much value for 1920x1080 for me it seems.

Again, wrong test so don't take it for granted . Files with proper contrast and 4k would be a much more interesting case.

Hmm. Maybe try --tune VMAF or whatever they call that mode. I would hope that would improve VMAF scores at least . It'd be interesting to see how well the encoder does when given a specific target metric.

For example, one could use --tune psnr in x264, x265, and SVT-HEVC. That would give some insight into how many tools and modes the encoder tries. Although it would look worse than your tests, so it would be more interesting than applicable.

It'd be good to try some longer clips to get a sense of the speed delta. I note that per the updated x265 docs for svt, that it has two modes SLOWER than the placebo equivalent.

[dipje]

so people are actually getting respectable quality out of SVT-HEVC? And then I don't mean that it must match or best x265, but I at least expected it yield better quality than x264-software encoder running at comparable speeds.

I tried again with a slog2->rec709 lut on there and preparing the file to be 25fps and a bit longer (30 seconds), and _visually_ the SVT file isn't that bad actually. It just has a bunch more smoothing on it it seems. So x265 with --no-sao can show small amounts of blocking, while the SVT encode has the blocking smoothed out but otherwise just as enjoyable to watch and the same amount of detail from what I can tell..

Will do my tests with a proper free source and the good old fashioned way of using realistic bitrates and visually inspecting the file to make up my mind

[Atak_Snajpera]

Can somebody test how this SVT-HEVC survives famous park_joy_1080p50.y4m ?

[Jamaika]

Originally Posted by Atak_Snajpera

Can somebody test how this SVT-HEVC survives famous park_joy_1080p50.y4m ?

My test codec by encoder BPG SVT.
At the moment the only way I could use.
yuv420p->RGB24->yuv420p
SvtHevcEncApp1.exe -i park_joy_1080p50.y4m -w 1920 -h 1080 -vid-info 1 -fpsinvps 1 -rt 0 -lp 0 -ss -1 -dolby-vision-rpu 0 -tune 2 -profile 1 -tier 0 -hme 1 -sao 0 -dlf 1 -brr 1 -bit-depth 8 -fps 50 -asm 0 -encMode 9 -tbr 70000 -compressed-ten-bit-format 0 -max-qp 48 -min-qp 10 -use-default-me-hme 1 -search-w 16 -search-h 7 -n 0 -q 30 -dolby-vision-profile 0 -max-cll 0 -max-fall 0 -use-master-display 0 -inj-frm-rt 60 -temporal-id 1 -sharp 1 -lad 17 -scd 1 -interlaced-video 0 -color-format 1 -base-layer-switch-mode 0 -pred-struct 0 -irefresh-type 2 -intra-period -2 -hierarchical-levels 3 -b park_joy_1080p50_QP30_tune2_hier3_base0_pred0.h265

https://www.sendspace.com/file/yf2ht7
Conclusion:
We don't use option PredStructure greater than zero. Tune 2 it's VMAF.

[Atak_Snajpera]

Originally Posted by Jamaika

My test codec by encoder BPG SVT.
At the moment the only way I could use.
yuv420p->RGB24->yuv420p
SvtHevcEncApp1.exe -i park_joy_1080p50.y4m -w 1920 -h 1080 -vid-info 1 -fpsinvps 1 -rt 0 -lp 0 -ss -1 -dolby-vision-rpu 0 -tune 2 -profile 1 -tier 0 -hme 1 -sao 0 -dlf 1 -brr 1 -bit-depth 8 -fps 50 -asm 0 -encMode 9 -tbr 70000 -compressed-ten-bit-format 0 -max-qp 48 -min-qp 10 -use-default-me-hme 1 -search-w 16 -search-h 7 -n 0 -q 30 -dolby-vision-profile 0 -max-cll 0 -max-fall 0 -use-master-display 0 -inj-frm-rt 60 -temporal-id 1 -sharp 1 -lad 17 -scd 1 -interlaced-video 0 -color-format 1 -base-layer-switch-mode 0 -pred-struct 0 -irefresh-type 2 -intra-period -2 -hierarchical-levels 3 -b park_joy_1080p50_QP30_tune2_hier3_base0_pred0.h265

https://www.sendspace.com/file/yf2ht7
Conclusion:
We don't use option PredStructure greater than zero. Tune 2 it's VMAF.

Well I was expecting something around 5Mbps not those insane 30Mbps. At such high bitrate even x264 shines.

[benwaggoner]

It would be great if people would share the command lines they're using with SVT-HEVC. There's a ton of configurability in there (not as much as x265, but that's a high bar). Some ones where changing from default is likely to have a significant impact on output quality and performance include:

• EncoderMode - quality versus speed; 0 is highest quality and 12 highest speed. x265 maps 2 as placebo, with 0 and 1 below that. Default is 9 which I guess is the rough equivalent of "faster."
• Tune - optimization mode. 0 is visually optimized, which is what we should be testing. 1 is the default (grr) and SSIM/PSNR tuned. 2 is VMAF tuned.
• RateControlMode - default is 0, 1 is VBR where VBR gets applied (and is what matters for real-world scenarios).
• BitRateReduction - only applies to EncoderMode=0, and defaults to on there. Attempts to reduce bitrate without reducing quality (Ala CRF?)
• TargetBitrate - specify target bitrate. Only applies in EncoderMode=1.
• ImproveSharpness - Improves sharpness in EncoderMode=0 for 4K and 8K content. Defaults to on

I am kind of confused about how rate control/quality works here. It seems like optimal quality would be

-encMode 0
-tune 0
-rc 1
-bitrate <bitrate>

No idea how practical -encMode 0 is for speed; that may need to be adjusted. But the above should give a perceptually optimized capped VBR style encode at or below the bitrate value.

[TEB]

Anyone know of a windows or linux build with FFmpeg and SVT compiled together ?

[Jamaika]

Originally Posted by benwaggoner

• EncoderMode - quality versus speed; 0 is highest quality and 12 highest speed. x265 maps 2 as placebo, with 0 and 1 below that. Default is 9 which I guess is the rough equivalent of "faster."
• Tune - optimization mode. 0 is visually optimized, which is what we should be testing. 1 is the default (grr) and SSIM/PSNR tuned. 2 is VMAF tuned.
• RateControlMode - default is 0, 1 is VBR where VBR gets applied (and is what matters for real-world scenarios).
• BitRateReduction - only applies to EncoderMode=0, and defaults to on there. Attempts to reduce bitrate without reducing quality (Ala CRF?)
• TargetBitrate - specify target bitrate. Only applies in EncoderMode=1.
• ImproveSharpness - Improves sharpness in EncoderMode=0 for 4K and 8K content. Defaults to on

I am kind of confused about how rate control/quality works here. It seems like optimal quality would be

-encMode 0
-tune 0
-rc 1
-bitrate <bitrate>

No idea how practical -encMode 0 is for speed; that may need to be adjusted. But the above should give a perceptually optimized capped VBR style encode at or below the bitrate value.

void svt_param_default(x265_param* param)
{
EB_H265_ENC_CONFIGURATION* svtHevcParam = (EB_H265_ENC_CONFIGURATION*)param->svtHevcParam;

//Preset & Tune default
svtHevcParam->encMode = 9; // if (!strcmp(preset, "faster")) svtHevcParam->encMode = 9;
svtHevcParam->tune = 0; // if (!strcmp(tune, "grain")) svtHevcParam->tune = 0; else if (!strcmp(tune, "animation")) svtHevcParam->tune = 0; ???

// Rate Control default
svtHevcParam->frameRate = 60;
svtHevcParam->frameRateNumerator = 0;
svtHevcParam->frameRateDenominator = 0;
svtHevcParam->encoderBitDepth = 8;
svtHevcParam->compressedTenBitFormat = 0;
svtHevcParam->rateControlMode = 0;
svtHevcParam->sceneChangeDetection = 1;
svtHevcParam->lookAheadDistance = (uint32_t)~0;
svtHevcParam->framesToBeEncoded = 0;
svtHevcParam->targetBitRate = 7000000;
svtHevcParam->maxQpAllowed = 48;
svtHevcParam->minQpAllowed = 10;
svtHevcParam->bitRateReduction = 1;

/*vmaf is under development, currently x265 won't support vmaf*/

Originally Posted by filler56789

Has anyone already built a Windows binary through Visual Studio?

It's impossible to compile the d@mn thing with MinGW-w64.

The line isn't here:

    if (encoder->m_param->bEnableSvtHevc)
    {
        EB_H265_ENC_CONFIGURATION* svtParam = (EB_H265_ENC_CONFIGURATION*)encoder->m_svtAppData->svtHevcParams;
        if (pic_in)

[filler56789]

Originally Posted by Jamaika

The line isn't here:

    if (encoder->m_param->bEnableSvtHevc)
    {
        EB_H265_ENC_CONFIGURATION* svtParam = (EB_H265_ENC_CONFIGURATION*)encoder->m_svtAppData->svtHevcParams;
        if (pic_in)

Actually I was talking about something like this:

r:\make6t4\gccs64\830\bin\../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ranlib.exe:
unable to rename '../../../lib/libASM_AVX2.a'; reason: File exists
make[2]: *** [Source/Lib/ASM_AVX2/CMakeFiles/ASM_AVX2.dir/build.make:230: lib/libASM_AVX2.a] Error 1
make[2]: *** Deleting file 'lib/libASM_AVX2.a'
make[1]: *** [CMakeFiles/Makefile2:403: Source/Lib/ASM_AVX2/CMakeFiles/ASM_AVX2.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

[dipje]

@TEB: I just grabbed the ffmpeg from git (github, not official but real enough) and did a checkout on the 4.1 release. I picked the last release from the IntelSVTHevc from github and it gave directions to apply a patch to the ffmpeg tree. This patch is made for 4.1 and applied cleanly on my build and compiled fine (Windows 10 but WSL Ubuntu 18.04 install). So I don't really have a build to be shared but it compiles cleanly on Ubuntu 18.04 so I guess it shouldn't be that hard to build it yourself if you're asking for Linux binaries.

@Benwaggoner: Played around a bit with piping yuv420p from ffmpeg into the SvcHevcEncApp utility (specifying number of frames, fps, width and height) and that produced way different results than my earlier ffmpeg tests. I don't know if I just gave wrong parameters in ffmpeg, or the ffmpeg-svthevc wrapper is not passing all parameters correctly but these results were WAAAY more usable on the quality side of things, but also took longer to encode.

I can slow SvcHevc right down to 0.5fps on my laptop or up to 88 fps... and it produces results which are more in line with what I expect with those speeds :P. So I'm testing again, my previous results were apparently only on the 'very fast' settings. This makes the encoder way more usable and a 'real encoder' for common use.
(it seems it's been made with the idea to run 'always realtime, adjusting itself as it goes to stay realtime' on recent Xeon cores).

[filler56789]

Has anyone already built a Windows binary through Visual Studio?

It's impossible to compile the d@mn thing with MinGW-w64.

[poisondeathray]

Wolfberry has 1.3.0 compiled and in his public share folder
https://drive.google.com/drive/folde...mHKYLzO3elemlC

[filler56789]

Originally Posted by poisondeathray

Wolfberry has 1.3.0 compiled and in his public share folder
https://drive.google.com/drive/folde...mHKYLzO3elemlC

Thanks for the information. Sadly all that the .EXE can do is crash😒

[Forteen88]

Originally Posted by filler56789

Thanks for the information. Sadly all that the .EXE can do is crash��

It's because you need to install Intel-compiler file "ww_icl_redist_msi_2019.2.190.zip" too!

[benwaggoner]

Originally Posted by poisondeathray

Wolfberry has 1.3.0 compiled and in his public share folder
https://drive.google.com/drive/folde...mHKYLzO3elemlC

How specific are these to a particular Xeon version? I would think they would get tuned and targeted pretty specifically. I wonder how much benefit profiler-guided optimization would provide.

[Jamaika]

Originally Posted by HolyWu

SvtHevcEnc-20190302-19344bd-win64.7z

Built by GCC 8.3.0 both with and without PGO.

Almost good but there are mistakes.
SvtHevcEncApp.exe -i 111.yuv -w 1920 -h 1080 -tune 0 -profile 1 -bit-depth 8 -fps 30000/1001 -asm 0 -encMode 9 -tbr 70000 -compressed-ten-bit-format 0 -b 112.h265
How to add framerate 29.972?
How to add color subsample yuv420? encoderColorFormat = EB_YUV420