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.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 17th February 2019, 00:06   #1  |  Link
TEB
Registered User
 
Join Date: Feb 2003
Location: Palmcoast of Norway
Posts: 306
Intel SVT-HEVC encoder

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

Last edited by TEB; 17th February 2019 at 00:59.
TEB is offline   Reply With Quote
Old 18th February 2019, 21:18   #2  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,793
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 19th February 2019, 16:06   #3  |  Link
utack
Registered User
 
Join Date: Apr 2018
Posts: 35
x265 can now also use SVT
http://x265.org/x265-svt-hevc-house/
utack is offline   Reply With Quote
Old 20th February 2019, 08:42   #4  |  Link
dipje
Registered User
 
Join Date: Oct 2014
Posts: 267
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.
dipje is offline   Reply With Quote
Old 22nd February 2019, 21:35   #5  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,793
Quote:
Originally Posted by dipje View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 23rd February 2019, 22:17   #6  |  Link
dipje
Registered User
 
Join Date: Oct 2014
Posts: 267
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
dipje is offline   Reply With Quote
Old 25th February 2019, 16:03   #7  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 6,773
Can somebody test how this SVT-HEVC survives famous park_joy_1080p50.y4m ?
Atak_Snajpera is offline   Reply With Quote
Old 25th February 2019, 20:21   #8  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,793
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 25th February 2019, 23:56   #9  |  Link
TEB
Registered User
 
Join Date: Feb 2003
Location: Palmcoast of Norway
Posts: 306
Anyone know of a windows or linux build with FFmpeg and SVT compiled together ?
TEB is offline   Reply With Quote
Old 27th February 2019, 23:04   #10  |  Link
dipje
Registered User
 
Join Date: Oct 2014
Posts: 267
@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).
dipje is offline   Reply With Quote
Old 27th February 2019, 23:20   #11  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 830
Has anyone already built a Windows binary through Visual Studio?

It's impossible to compile the d@mn thing with MinGW-w64.
filler56789 is offline   Reply With Quote
Old 28th February 2019, 08:49   #12  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 532
Quote:
Originally Posted by benwaggoner View Post
  • 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*/

Quote:
Originally Posted by filler56789 View Post
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:
Code:
    if (encoder->m_param->bEnableSvtHevc)
    {
        EB_H265_ENC_CONFIGURATION* svtParam = (EB_H265_ENC_CONFIGURATION*)encoder->m_svtAppData->svtHevcParams;
        if (pic_in)

Last edited by Jamaika; 28th February 2019 at 09:15.
Jamaika is offline   Reply With Quote
Old 28th February 2019, 12:47   #13  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 830
Quote:
Originally Posted by Jamaika View Post
The line isn't here:
Code:
    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:

Code:
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
filler56789 is offline   Reply With Quote
Old 28th February 2019, 16:42   #14  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,701
Wolfberry has 1.3.0 compiled and in his public share folder
https://drive.google.com/drive/folde...mHKYLzO3elemlC
poisondeathray is offline   Reply With Quote
Old 28th February 2019, 18:16   #15  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 532
I compiled x265_svt with my own way:
i.e. I delete AVX and leave only SSE2.
What conclusions: doesn't tolerate colormatrix 2020, high-tier and lacks parameters.
Don't add LIBVMAF.

Why is main10? How I added 8bit.

y4m [info]: 1920x1080 fps 29/1 i420p8 sar 1:1 unknown frame count
raw [info]: output file: x265_hightier_crf28_tunegrain.h265
x265 [info]: HEVC encoder version 3.0_Au+8
x265 [info]: build info [Windows][GCC 9.0.1][64 bit][noasm] 8bit
SVT [version]: SVT-HEVC Encoder Lib v1.3.0
SVT [build] : GCC 9.0.1 64 bit
LIB Build date: Feb 28 2019 16:55:02
-------------------------------------------
SVT [Warning]: Color format EB_YUV400 not supported, set to EB_YUV420
Number of logical cores available: 4
Number of PPCS 107
-------------------------------------------
SVT [config]: Main10 Profile Tier (auto) Level (auto)
SVT [config]: EncoderMode / LatencyMode / Tune : 4 / 0 / 0
SVT [config]: EncoderBitDepth / CompressedTenBitFormat / EncoderColorFormat : 8 / 0 / 1
SVT [config]: SourceWidth / SourceHeight : 1920 / 1080
SVT [config]: Fps_Numerator / Fps_Denominator / Gop Size / IntraRefreshType : 29 / 1 / 61 / 2
SVT [config]: HierarchicalLevels / BaseLayerSwitchMode / PredStructure : 3 / 0 / 2
SVT [config]: BRC Mode / QP / LookaheadDistance / SceneChange : CQP / 32 / 17 / 1
SVT [config]: BitRateReduction / ImproveSharpness : 1 / 1
-------------------------------------------


My file only for 8bit. Enjoy.
https://www.sendspace.com/file/ki9z14

Last edited by Jamaika; 28th February 2019 at 18:25.
Jamaika is offline   Reply With Quote
Old 2nd March 2019, 23:51   #16  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 830
Quote:
Originally Posted by poisondeathray View Post
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😒
filler56789 is offline   Reply With Quote
Old 3rd March 2019, 20:14   #17  |  Link
Forteen88
Herr
 
Join Date: Apr 2009
Location: North Europe
Posts: 324
Quote:
Originally Posted by filler56789 View Post
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!
Forteen88 is offline   Reply With Quote
Old 3rd March 2019, 21:00   #18  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,793
Quote:
Originally Posted by poisondeathray View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 4th March 2019, 10:02   #19  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 532
Quote:
Originally Posted by HolyWu View Post
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
Jamaika is offline   Reply With Quote
Old 4th March 2019, 16:04   #20  |  Link
HolyWu
Registered User
 
HolyWu's Avatar
 
Join Date: Aug 2006
Location: Taiwan
Posts: 535
Quote:
Originally Posted by Jamaika View Post
How to add framerate 29.972?
How to add color subsample yuv420? encoderColorFormat = EB_YUV420
Not quite understand your latter question. From the -help:
Code:
-fps-num                        FrameRateNumerator
-fps-denom                      FrameRateDenominator
-color-format                   420:1, 422:2, 444:3
HolyWu is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 21:16.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.