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?page=news_item&px=SVT-AV1-Speed-Progress


Reading this :
https://01.org/sites/default/files/documentation/scalable_video_technology_for_the_visual_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]

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 ?

[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 ?

[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.

[Jamaika]

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*/

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]

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

[poisondeathray]

Wolfberry has 1.3.0 compiled and in his public share folder
https://drive.google.com/drive/folders/1xZQABtoaSFgGu11YstmHKYLzO3elemlC

[Jamaika]

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

[filler56789]

Wolfberry has 1.3.0 compiled and in his public share folder
https://drive.google.com/drive/folders/1xZQABtoaSFgGu11YstmHKYLzO3elemlC

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

[Forteen88]

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]

Wolfberry has 1.3.0 compiled and in his public share folder
https://drive.google.com/drive/folders/1xZQABtoaSFgGu11YstmHKYLzO3elemlC



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]

SvtHevcEnc-20190302-19344bd-win64.7z (https://www.mediafire.com/file/l3zvs7q34su9405/SvtHevcEnc-20190302-19344bd-win64.7z/file)

Built by GCC 8.3.0 both with and without PGO.
Almost good but there are mistakes.:D
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]

Where is color format in SvtHevcEncApp.exe?
TOKEN DESCRIPTION INPUT TYPE

-nch NumberOfChannels Single input
-i InputFile Single input
-b StreamFile Single input
-errlog ErrorFile Single input
-o ReconFile Single input
-qp-file QpFile Single input
-interlaced-video InterlacedVideo Single input
-separate-fields SeperateFields Single input
-w SourceWidth Single input
-h SourceHeight Single input
-n FrameToBeEncoded Single input
-nb BufferedInput Single input
-base-layer-switch-mode BaseLayerSwitchMode Single input
-encMode EncoderMode Single input
-intra-period IntraPeriod Single input
-irefresh-type IntraRefreshType Single input
-fps FrameRate Single input
-fps-num FrameRateNumerator Single input
-fps-denom FrameRateDenominator Single input
-bit-depth EncoderBitDepth Single input
-compressed-ten-bit-format CompressedTenBitFormat Single input
-hierarchical-levels HierarchicalLevels Single input
-pred-struct PredStructure Single input
-scd SceneChangeDetection Single input
-q QP Single input
-use-q-file UseQpFile Single input
-rc RateControlMode Single input
-lad LookAheadDistance Single input
-tbr TargetBitRate Single input
-max-qp MaxQpAllowed Single input
-min-qp MinQpAllowed Single input
-dlf LoopFilterDisable Single input
-sao SAO Single input
-use-default-me-hme UseDefaultMeHme Single input
-hme HME Single input
-search-w SearchAreaWidth Single input
-search-h SearchAreaHeight Single input
-constrd-intra ConstrainedIntra Single input
-tune Tune Single input
-lp LogicalProcessors Single input
-ss TargetSocket Single input
-rt SwitchThreadsToRtPriority Single input
-brr BitRateReduction Single input
-sharp ImproveSharpness Single input
-vid-info VideoUsabilityInfo Single input
-hdr HighDynamicRangeInput Single input
-ua-delm AccessUnitDelimiter Single input
-pbuff BufferingPeriod Single input
-tpic PictureTiming Single input
-reg-user-data RegisteredUserData Single input
-unreg-user-data UnregisteredUserData Single input
-recovery-point RecoveryPoint Single input
-max-cll MaxCLL Single input
-max-fall MaxFALL Single input
-use-master-display UseMasterDisplay Single input
-master-display MasterDisplay Single input
-dolby-vision-profile DolbyVisionProfile Single input
-dolby-vision-rpu DolbyVisionRpuFile Single input
-nalu-file NaluFile Single input
-temporal-id TemporalId Single input
-fpsinvps FPSInVPS Single input
-inj Injector Single input
-inj-frm-rt InjectorFrameRate Single input
-speed-ctrl SpeedControlFlag Single input
-profile Profile Single input
-tier Tier Single input
-level Level Single input
-latency-mode LatencyMode Single input
-asm AsmType Single input

What are we framerate by -fps-denom 1001 -fps-num 30000?
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L3.1@Main
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Duration : 2 s 880 ms
Bit rate : 1 909 kb/s
Maximum bit rate : 2 543 kb/s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.083
Stream size : 671 KiB (100%)
Title : h265@GPAC0.7.2-DEV-rev991-gac74c900-master
Encoded date : UTC 2019-03-04 16:16:40
Tagged date : UTC 2019-03-04 16:16:40
Codec configuration box : hvcC

The color format doesn't work. After removing the command, I have it.
http://i65.tinypic.com/2h5ionm.jpg

[filler56789]

.........

The color format doesn't work. After removing the command, I have it.
http://i65.tinypic.com/2h5ionm.jpg

I can be wrong, but it seems this type of problem is "inevitable" when the current source-code is compiled for Windows with GCC:

https://github.com/intel/SVT-HEVC/issues/118#issuecomment-468867836

[Jamaika]

I can be wrong, but it seems this type of problem is "inevitable" when the current source-code is compiled for Windows with GCC:

https://github.com/intel/SVT-HEVC/issues/118#issuecomment-468867836

It isn't true that GCC is guilty.
I've compiled svt encoder myself. Strange, for BPG libsvt works, in encoder svt doesn't want to.

[filler56789]

It isn't true that GCC is guilty.
I've compiled svt encoder myself. Strange, for BPG libsvt works, in encoder svt doesn't want to.

I DIDN'T say it's GCC's fault, I said and meant the current source-code is messy :-/

[Jamaika]

I will not clutter up the topic. I'll wait for the corrections. In general, I have a hard time compiling the App with GCC. GCC enforces static headers in the APP otherwise the information is duplicated with libsvt.

[dipje]

AFAIK the svt encoder only supports a few specific input formats :

https://github.com/intel/SVT-HEVC/blob/master/Docs/svt-hevc_encoder_user_guide.md#input-video-format

Svt encodes to raw hevc streams on my system, so I have to mux it and set framerate there.
The fps parameters on the cli are (I guess ) only to specify framerate of the input for things like calculating bits per second (so it needs to know how many frames in a second ).

I don't know, but do raw elementary hevc streams even have a fps field somewhere ?

[sneaker_ger]

AVC and HEVC have vui_num_units_in_tick and vui_time_scale.

[Jamaika]

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]

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.

[Jamaika]

For grumpy here they are:
https://www.sendspace.com/filegroup/1jMGWRtQ2DhuBIEFDAGMHiESUyp2aEtw

[Atak_Snajpera]

For grumpy here they are:
https://www.sendspace.com/filegroup/1jMGWRtQ2DhuBIEFDAGMHiESUyp2aEtw

Pathetic quality! x264 destroys this HEVC encoder easily!
https://www.mediafire.com/file/dmbhg3v8ztux09k/normal.mkv/file

[Jamaika]

I don't comment on it. I am proud that I could compile myself and show off my waste of time. I will leave the rest to the professionals.

[Jamaika]

- new fixes for codec SVT HEVC 2019.06.01

Despite few amendments. Generally codec is a bit neglected in relation to SV1 AV1. The codec still has visible errors. There are pink spots of pixels.
svt_hevc.exe -i 111.yuv -b auto_svt.h265 -tile_row_cnt 1 -tile_col_cnt 1 -w 1280 -h 720 -n 0 -bit-depth 8 -umv 1 -fpsinvps 1 -level 0 -tier 0 -fps-num 30000 -fps-denom 1001 -temporal-id 0 -asm 0 -rc 0 -tbr 3000000 -qp-file 32 -max-qp 48 -min-qp 10 -search-w 16 -search-h 7 -hme 1 -use-default-me-hme 1 -sao 0 -dlf 1 -tune 2 -interlaced-video 0 -compressed-ten-bit-format 0 -color-format 1 -encMode 0 -vid-info 1 -sharp 0 -irefresh-type 1 -hierarchical-levels 0 -base-layer-switch-mode 0 -intra-period 31 -pred-struct 2 -constrd-intra 1 -profile 1 -hdr 0

https://www.sendspace.com/file/z9xqvl

[benwaggoner]

Pathetic quality! x264 destroys this HEVC encoder easily!
https://www.mediafire.com/file/dmbhg3v8ztux09k/normal.mkv/file
How did you tune it? There's approaching x265-like configurability in SVT-HEVC. Lots of psychovisual options, lots of quality/speed tradeoffs.

[GrandAdmiralThrawn]

I compiled x265_svt with my own way:
i.e. I delete AVX and leave only SSE2.
Could you elaborate on how you did that? I tried the same thing, but all I managed to do was to disable assembly optimizations altogether, making --asm 0 the default and running it on non-AVX, non-NUMA machines after a bit of patching. But that appears to be pure C code now.

Even the NONAVX2 codepath (--asm 1) seems to depend on AVX in some way. Or maybe it depends on YMM/ZMM registers or the OS XSAVE instruction being present, I don't know. Can't speak C or x86 assembly properly.

Edit: Or maybe it's Visual Studio 2017 at fault here?

What I would like to do is to create a build that runs with SSE2 or SSSE3 or SSE4.2 selectively, so I can do non-NUMA specific builds for older CPUs, while retaining as many optimizations as possible.

Thank you!

[Jamaika]

I have changed some implementations a bit. I had to turn off the SIMD (SSE3, SSE41, AVX, AVX2, AVX512)
I could not use assembler in GCC. So some of the functions do not work, i.e. SAO.
It should be added that x265_svt is only 8bit 420yuv.
I also changed the functions of svt in param.cpp

Added opensource for GNU and codec video with file .bat
https://www.sendspace.com/filegroup/AUEmucarzcfwx7MXSw%2B6nA

How do you think that you will do better? You have other ideas. Share your knowledge.;)

[Shevach]

How to configure SVT-HEVC to generate closed GOPs with SPS/PPS?

i tried the following command line to generate closed GOP (= 30 frames):

./SvtHevcEncApp -i container_384x320.yuv -w 384 -h 320 -encMode 6 -intra-period 29 -fps 30 -rc 1 -tbr 500000 -umv 0 -irefresh-type 2 -lad 2 -pred-struct 2 -hierarchical-levels 0 -ua-delm 1 -b test.h265

However, upon inspection of the generated stream i found that all IDRs (excepting the very first one) are not accompanied with SPS/PPS and hence can't serve as a random access point.

[Jamaika]

Use the function:
-irefresh-type 2 -hierarchical-levels 0 -base-layer-switch-mode 0 -intra-period 29 -pred-struct 2
// GOP Structure

/* The intra period defines the interval of frames after which you insert an
* Intra refresh. It is strongly recommended to set the value to multiple of
* 8 minus 1 the closest to 1 second (e.g. 55, 47, 31, 23 should be used for
* 60, 50, 30, (24 or 25) respectively.
*
* -1 = no intra update.
* -2 = auto.
*
* Deault is -2. */
int32_t intraPeriodLength;

/* Random access.
*
* 1 = CRA, open GOP.
* 2 = IDR, closed GOP.
*
* Default is 1. */
uint32_t intraRefreshType;

/* Flag to code VPS / SPS / PPS.
*
* Default is 1. */
uint8_t codeVpsSpsPps;

[Shevach]

@Jamaika

i actually use same command line 'excepting -base-layer-switch-mode 0'. This does not work.
i dived into the source code and found in the main loop (the procedure PacketizationKernel ) the following condition:

if(pictureControlSetPtr->pictureNumber == 0 && sequenceControlSetPtr->staticConfig.codeVpsSpsPps == 1)

According to the above condition VPS/SPS/PPS are generated for the very first frame only.
i replaced the condition with 'if(outputStreamPtr->sliceType==EB_IDR_PICTURE)' and the modified SVT encoder does inserts VPS/SPS/PPS before each IDR. Thus, each IDR is a random access point.

[Jamaika]

@Jamaika

i actually use same command line 'excepting -base-layer-switch-mode 0'. This does not work.
This is true, but they have improved something for frames B with SAO frames. Still bad work compressed-ten-bit-format and hierarchical-levels.
In general the problem frames B and SPS/VPS were reported. The answer was we don't have time for HEVC.

It adds holiday corrections, added new features, but old problems remain.

PS To check the new codecs HEVC, analyzer is useful. Unfortunately the programs are paid.

[Shevach]

This is true, but they have improved something for frames B with SAO frames. Still bad work compressed-ten-bit-format and hierarchical-levels.
In general the problem frames B and SPS/VPS were reported. The answer was we don't have time for HEVC.

It adds holiday corrections, added new features, but old problems remain.

PS To check the new codecs HEVC, analyzer is useful. Unfortunately the programs are paid.

i observe a problem in encoding time. Despite i compiled SVT-HEVC with all SSEx and AVX2, for encMode=8 (fast preset) on CIF yuv sequence the encoding speed is around 12fps. The same setting of x265 provides ~50fps.

As per B-frames, there are a wide class of low-latency applications (e.g. cloud gaming) where B-frames are irrelevant and not used.

My main concern is low encoding time of SVT-HEVC comaring to that of x265.

[Jamaika]

Add VPS/SPS/PPS insertion for IDR frames option (https://github.com/OpenVisualCloud/SVT-HEVC/commit/e69c96544c2142ba03cea80de097a91caecd7b67)

Maybe it work, but also instructions only for AVX. I don't know what to change _xgetbv(0) for SSE2

[LigH]

New upload (no really new features, but anyway...):

SVT-HEVC 1.5.1-78bcaa7 (https://www.mediafire.com/file/dbmgu8ozfuq4v2h/SVT-HEVC_1.5.1-78bcaa7.7z/file) (Win64, GCC 13.2)

[LigH]

New upload:

SVT-HEVC 1.5.1-ed80959 (https://www.mediafire.com/file/msvzlg5uk2nvti7/SVT-HEVC_1.5.1-ed80959.7z/file) (Win64, GCC 14.1)

[Spyros]

SVT-HEVC has been discontinued. FWIW, the announcement was made at the end of July, a few days before Intel released its Q2 2024 financial results and a more than 15% headcount reduction (https://www.intc.com/news-events/press-releases/detail/1704/intel-reports-second-quarter-2024-financial-results).

This repository has been archived by the owner on Jul 29, 2024. It is now read-only.

DISCONTINUATION OF PROJECT

This project will no longer be maintained by Intel.
Intel has ceased development and contributions including, but not limited to, maintenance, bug fixes, new releases, or updates, to this project.
Intel no longer accepts patches to this project.
If you have an ongoing need to use this project, are interested in independently developing it, or would like to maintain patches for the open source software community, please create your own fork of this project.

[benwaggoner]

SVT-HEVC has been discontinued. FWIW, the announcement was made at the end of July, a few days before Intel released its Q2 2024 financial results and a more than 15% headcount reduction (https://www.intc.com/news-events/press-releases/detail/1704/intel-reports-second-quarter-2024-financial-results).
Unsurprising. I don't know that anyone has been using it in production for anything.

Anyone know of use cases?

[LigH]

New upload: (final build)

SVT-HEVC 1.5.1-4181c9e (https://www.mediafire.com/file/6zahx60tmwauiow/SVT-HEVC_1.5.1-4181c9e.7z/file) (Win64, GCC 14.2.0)

[rwill]

So... I did not keep track of development but does x265 still support integrating SVT-HEVC as a fast alternative to itself? If so, what now?

[LigH]

Reading the source, it is still mentioned. But I will not know if it still works. No supported hardware here.

[benwaggoner]

So... I did not keep track of development but does x265 still support integrating SVT-HEVC as a fast alternative to itself? If so, what now?
I never found a great scenario for that. SVT-HEVC had a much lower quality ceiling than x265, and x265 is already really fast for encoding at those quality levels. SVT-HEVC mainly standard out for being able to apply huge parallelism, but I'm not convinced that we couldn't get in the same ballpark with proper use of --threads --frame-threads, --pmode, and --pme.