Intel SVT-HEVC encoder

[filler56789]

Originally Posted by Jamaika

.........

The color format doesn't work. After removing the command, I have it.

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/is...ment-468867836

[Jamaika]

Originally Posted by filler56789

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/is...ment-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]

Originally Posted by Jamaika

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/bl...t-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]

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.

[Jamaika]

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

[Atak_Snajpera]

Originally Posted by Jamaika

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

Pathetic quality! x264 destroys this HEVC encoder easily!
https://www.mediafire.com/file/dmbhg...ormal.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]

Originally Posted by Atak_Snajpera

Pathetic quality! x264 destroys this HEVC encoder easily!
https://www.mediafire.com/file/dmbhg...ormal.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]

Originally Posted by Jamaika

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/...fwx7MXSw%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]

Originally Posted by Shevach

@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]

Originally Posted by Jamaika

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.