Trying to use SvtHevcEncApp.exe (https://github.com/OpenVisualCloud/SVT-HEVC) and running
I get:Code:SvtHevcEncApp.exe -help
nice lots of options,..Code:SVT-HEVC Encoder TOKEN DESCRIPTION INPUT TYPE -nch NumberOfChannels Single input -i InputFile Single input -b StreamFile Single input -errlog ErrorFile Single input -o ReconFile Single input -use-q-file UseQpFile Single input -qp-file QpFile Single input -interlaced-video InterlacedVideo Single input -separate-fields SeperateFields Single input -tile_row_cnt TileRowCount Single input -tile_col_cnt TileColumnCount Single input -tile_slice_mode TileSliceMode Single input -encMode EncoderMode Single input -speed-ctrl SpeedControlFlag Single input -bit-depth EncoderBitDepth Single input -compressed-ten-bit-format CompressedTenBitFormat Single input -color-format EncoderColorFormat Single input -w SourceWidth Single input -h SourceHeight Single input -n FrameToBeEncoded Single input -nb BufferedInput Single input -profile Profile Single input -tier Tier Single input -level Level Single input -fps FrameRate Single input -fps-num FrameRateNumerator Single input -fps-denom FrameRateDenominator Single input -hierarchical-levels HierarchicalLevels Single input -base-layer-switch-mode BaseLayerSwitchMode Single input -pred-struct PredStructure Single input -intra-period IntraPeriod Single input -irefresh-type IntraRefreshType Single input -q QP Single input -vbv-maxrate vbvMaxRate Single input -vbv-bufsize vbvBufsize Single input -hrd hrd Single input -vbv-init vbvBufInit 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 -rc RateControlMode Single input -tbr TargetBitRate Single input -max-qp MaxQpAllowed Single input -min-qp MinQpAllowed Single input -lad LookAheadDistance Single input -scd SceneChangeDetection Single input -tune Tune 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 -temporal-id TemporalId Single input -rt SwitchThreadsToRtPriority Single input -fpsinvps FPSInVPS 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 -umv UnrestrictedMotionVector 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 -asm AsmType Single input -ss TargetSocket Single input -lp LogicalProcessors Single input -thread-count ThreadCount Single input
Problem none of these options show what their default value is and what are valid parameters for these options.
-> Is there some documentation somewhere?
Here are my initial (un-verified) thoughts/guesses (range guesses are in brackets):
- -thread-count: the number of threads the encoder uses; [1+]
- -lp: the number of numa nodes to use [1+]
- -ss: target socket on multi cpu systems? [1+]
- -asm: whether to use assembly optimized code or not ? [when used assembly will be used otherwise non optimized C code only]
- -level: HEVC level probably; [range: 1, 2, 2.1, 3, 3.1, 4, 4.1, 5, 5.1, 5.2, 6, 6.1, 6.2]
- -tier: HEVC tier [range: 0/1 or main/high, depending on whether integers or strings are used]
- -profile: hevc profile [1/0 or main/main10 depending on whether integers or strings are used]
- -speed-ctrl: to whatever it takes to archive X fps encoding speed; only useful for streaming [1+]
- -inj-frm-rt: 'injector frame rate', may be the may speed the input is provided in fps ? [1+]
- -inj: whether the input is provided via a pipe with speed limits? [0 / 1]
- -umv: whether motion vectors should be restricted or not? (does hevc allow 'unrestriced' motion vectors? ) [0 / 1]
- -fpsinvps: whether timing infos should indicated in the vps meta data
- -nalu-file: no clue some file specifing somehow which nal units should be set/used?
- -dolby-vision-rpu: a DolbyVision rpu file [some file path]
- -dolby-vision-profile: the dolby vision profile which the rpu file abides to [8.1]
- -master-display: the master display string; no clue about the syntax, may be the same as with x265 'G(8500,39850)B(6550,2300)R(35399,14599)WP(15634,1 6450)L(10000000,20)'? [file path]
- -use-master-display: whether to add the master display information provided by '-master-display' or not? [0 / 1]
- -max-fall: the maximum frame average light level [0-65535]
- -max-cll: the maximum content light level [0-65535]
- -rt: 'SwitchThreadsToRtPriority' no clue
- -temporal-id: 'TemporalId' no clue
- -recovery-point: 'RecoveryPoint', no clue may be open vs closed gop related?
- -unreg-user-data: 'UnregisteredUserData' some private data added to the SEI ?
- -reg-user-data: adding some data to the SEI?
- -tpic: 'PictureTiming', may be something related to live streamining and how long to wait for a new frame?
- -pbuff: 'BufferingPeriod', same as above
- -ua-delm: add an access unit delimiter NAL at the start of each slice access unit when set
- -hdr: whether hdr encoding should be used and the input is hdr
- -vid-info: VideoUsabilityInfo like matrix etc. [no clue how to specify these here]
- -sharp: apply some additional sharpening [no clue about the range]
- -brr: I guess this is something like x264s ratetol [0.00-1.00 or 0-100]
- -tune: tune for quality metric [0: Visually optimized mode, 1: PSNR / SSIM optimized mode, 2: VMAF optimized mode]
- -scd: the SceneChangeDetection threshold [0.00-1.00 or 0-100]
- -min-qp: minimal allowed quantizer [0 - 51]
- -max-qp: maximum allowed quantizer [0 - 51]
- -tbr: target bitrate when using 1pass vbr encoding [no clue whether the bitrate is in kBit/s or Bit/s or ...]
- -rc: RateControlMode [0: 1pass cqp, 1: 1pass vbr]
- -constrd-intra: use Constrained intra prediction when specified.
- -search-h: SearchAreaHeight during motion estimation [1 - 256]
- -search-w: SearchAreaWidth during motion estimation [1 - 256]
- -hme: use Hierarchical Motion Estimation
- -use-default-me-hme: no clue how this differs from '-hme'
- -sao: use Sample Adaptive Offset loop filter
- -dlf: disable loop filtering
- -vbv-init: Initial buffer occupancy. [0-1]
- -hrd: signalling of HRD parameters to the decoder.
- -vbv-bufsize: the size of the VBV buffer (kBit?). [0+]
- -vbv-maxrate: maximum local bitrate (kBits/sec ?). [0+]
- -q: quantizer to use in cqp mode
- -irefresh-type: related to using Periodic Intra Refresh(PIR) instead of keyframes [no clue whyt types are available]
- -pred-struct: gop structure basis; usually 2 should be used unless streaming [0 - Low Delay P 1 - Low Delay B 2 - Random Acces]
- -base-layer-switch-mode: Choose type of slices to be in base layer. Accepts values [0 - Use B-frames in the base layer 1 - Use P-frames in the base layer]
- -hierarchical-levels: no clue
- -fps/-fps-num/-fps-denom: specify frame rate of output
- -nb: lookahead buffer? [1+]
- -n: encode max X frames of input [1+]
- -bit-depth: specify input&output bit depth (needed since only raw video is allowed as input afaik)
- -compressed-ten-bit-format: not totally sure what qualifies as compressed 10bit format (needed since only raw video is allowed as input afaik)
- -color-format: no clue how to specific [yuv420p yuv420p10le yuv422p yuv422p10le yuv444p yuv444p10le to 420, 422, 444 ?] (needed since only raw video is allowed as input afaik)
- -w/-h: resolution of input (needed since only raw video is allowed as input afaik)
- -encMode: no clue since rc is already covered by -rc
- -tile_row_cnt: TileRowCount for threading [1-height/16]
- -tile_col_cnt: TileColumnCount [1-width/16]
- -tile_slice_mode: no clue what modes are available
- -interlaced-video / -separate-fields: related to interlaced encoding my guess is these are used to set the field order and specify that the output should be interlaced
- -qp-file: path to qp file that gets used when '-use-q-file' is used, no clue about the syntax of the file.
- -o: 'ReconFile' no clue, normally I would expect '-o' to be the output file indicator,..
- -errlog: write errors to a specific file instead of writing them to std::err
- -b: 'StreamFile' no clue
- -i: path to the input file
- -nch: 'NumberOfChannels' no clue
-> does anyone use the svt hevc encoder and can shed some light on the parameters/options or knows a decent documentation of the encoder?
Like you can see I'm mainly lost with all these options.
Cu Selur
+ Reply to Thread
Results 1 to 20 of 20
-
users currently on my ignore list: deadrats, Stears555, marcorocchini
-
Default values and short description.
https://github.com/OpenVisualCloud/SVT-HEVC/blob/master/Docs/svt-hevc_encoder_user_guide.md
I tested it a while back. Lots of blurring ( like early x265 development), but quite fast even on a desktop. But there have been some commits since then, maybe some quality improvements
SVT-VP9 got a massive speed bump recently for hardware with AVX2, I'm wondering if SVT-HEVC will get similar code -
Thanks a lot, that's what I needed.
Resolution Minimum Footprint in GB
8k 64
Cu Selur
Ps.: VP9 and AV1 really need a speed upusers currently on my ignore list: deadrats, Stears555, marcorocchini -
Nobody uses the SVT-HEVC encoder, so if you use it, then you are nobody
x265's source-code includes it as an option only because MCW received some money from Intel themselves.
After I complained a lot the SVT-HEVC team managed to make the code compilable with MinGW-w64...
but there is no way to make the stupid .EXE encode anything from the stdin -_-"Programmers are human-shaped machines that transform alcohol into bugs." -
building x265 with SVT fails atm. afaik. at least MBAS fails building it,..
users currently on my ignore list: deadrats, Stears555, marcorocchini -
-
If you guys will recall I tested and posted samples of SVT HEVC in these forums, I don't know what the claims about poor quality are about, I thought it was quite good.
I didn't bother with all the options too much, I think if Selur includes just the Tune, Preset, QP, Bit-rate, rate control, frame rate and look ahead depth options, it would be fine.
I think people should get used to using SVT, I believe it is a precursor to Intel's hardware encoder that will be included with the discrete gpu they will be releasing. -
What do you think about handing interlaced video:
InterlacedVideo -interlaced-video [0,1] 0
1 : encoder will signal interlaced signal in the stream
0 : assumes progressive signal
SeparateFields -separate-fields [0,1] 0
1: Interlaced input, application will separate top and bottom fields and encode it as progressive.
0 : Treat video as progressive video
Cu Selurusers currently on my ignore list: deadrats, Stears555, marcorocchini -
I think the issue of interlaced sources is a non-issue, I don't think anyone is going to want to encode interlaced HEVC, VP9 or AV1; I would put logic in your app that detects when someone attempts to encode interlaced content to SVT-HEVC/VP9/AV1 without deinterlacing first and pop up a warning that this is not supported.
In other words, make the end user do things the proper way and deinterlace prior to encoding to HEVC, VP9 or AV1, and apply that to any encoder, not just the SVT family. -
I agree that I don't like interlaced encoding, but restricting users to not be able to encode interlaced in a format that supports it seems wrong.
(iirc. neither VP9 nor AV1 supports interlaced encoding, only HEVC does)
Cu Selurusers currently on my ignore list: deadrats, Stears555, marcorocchini -
"Programmers are human-shaped machines that transform alcohol into bugs."
-
yup.
see: https://github.com/m-ab-s/media-autobuild_suite/issues/1405, https://bitbucket.org/multicoreware/x265/issues/509/x265-fails-to-build-with-current-svt-hevc, https://github.com/OpenVisualCloud/SVT-HEVC/issues/322
Looking at:
IntraPeriod -intra-period [-2 - 255] -2
Distance Between Intra Frame inserted.
-1 denotes no intra update.
-2 denotes auto.
IntraRefreshType -irefresh-type [-1,N] -1
-1: CRA (Open GOP)
>=0: IDR (Closed GOP, N is headers insertion interval, 0 supported if CQP, >=0 supported if VBR)
Atm. I interpret the above as:
1. to have a open gop I set -irefresh-type -1,
then I can use '-intra-period X' to specify when I want the encoder to add I frames
2. to have a closed gop I with a max key int of 250 I set '-irefresh-type 250', but what does ''-intra-period X' do then?
-> I guess I missunderstand the meaning of '-intra-period' and '-irefresh-type'. Can someone explain how these two interact?
Cu Selurusers currently on my ignore list: deadrats, Stears555, marcorocchini -
The way I read it:
-intra-period 250 -irefresh-type 0 for closed GOP with max keyint 250
When -irefresh-type >0 that is the period interval of header insertion . If you put it to 100 it would insert headers every 100
But I haven't confirmed if this is what actually happens in the ES -
About the pipe issue, have you tried using a y4m pipe instead of a raw video pipe? Since they added y4m support, may be they broke raw input at the same time.
users currently on my ignore list: deadrats, Stears555, marcorocchini -
Yes, tried both. Both encode, but garbage/garbled output. Fresh 1.4.1 today and all new commits same issue
Someone reported it . Mine was 10bit , his was probably 8bit and he said 1.4.0 - but both had problems with output
https://github.com/OpenVisualCloud/SVT-HEVC/issues/373 -
Argh, so one can't compile it into x265 and piping doesn't work either atm.
-> just out of curiosity: Does it work with y4m files as input? (or it the project totally broken atm.)
Cu Selurusers currently on my ignore list: deadrats, Stears555, marcorocchini -
Holywu compiled x265 version + SVT-HEVC , not sure if it works
https://forum.doom9.org/showthread.php?p=1885945#post1885945
For SvtHevcEncApp -
I only tested piping(raw/y4m) ,and YUV direct in the current version (YUV works ok). Didn't test y4m physical files -
Some questions about "quality". I posted similar comments in the other SVT thread. This version is slightly improved
The quality is good, encodes are clean, pleasant to watch. But it's immature and lacking features/control . It tends to blur and overdenoise fine frequency details, similar what has been posted of Turing NVEnc HEVC. For some types of videos that might be ok. If you're doing a decent quality encode, not bitrate starved - where the goal it to keep details, not blur them away... not so much. If you have a shot of a detailed face , wrinkels, stubble, you'd lose things like hair strands and stubble, smooth over the wrinkles
Because of this, you are prone to banding even with 10bit (!), problems with fades, fine detail and texture loss.
The interesting options are ImproveSharpness, BitRateReduction. But the 1st only works with UHD/8K resolutions, it's supposed to be like AQ ("This is a visual quality knob that allows the use of adaptive quantization within the picture and enables visual quality algorithms that improve the sharpness of the background. This feature is only available for 4k and 8k resolutions"). The 2nd helps only very slightly with detail retention in my testing. Also -sao 0 , but this has little effect here. As x265 users know, SAO with x265 has a massive effect.
Also the ability to adjust and modulate parameters more would be useful. Such as ImproveSharpness +/- varying degrees like 1,2,3, etc... Or control deblock offsets,etc. That's what I mean by immature and lacking features
x265 has the ability to blur too if you wanted too (in fact, it tends to with default settings)
If you test VMAF, or MS-SSIM, or PSNR-HVS against x265/detail retention goal encode in a quality with details scenario , x265 wins by a fair margin by those "subjective" weighted metrics. Also just looking at it you can tell right away which is better assuming you're using x265 correctly .
If you're just doing quick tests with default settings, then I wouldn't blame someone for arriving at the wrong conclusions. In real life, people use different settings for different types of content. You wouldn't use same settings for say, a simple cartoon, vs. a grainy movie. People make the same assumptions with x265 - that it blurs too much (and it really did especially early on), encodes are too clean. It doesn't have to. In many ways, it's more difficult to tweak /tune than x264 .
But SVT-HEVC looks very promising. The "faster" encmode settings are quite fast without major issues (besides detail loss, blurring) . I bet it scales like a beast on servers -
File encoding still works, I used:
Code:ffmpeg -y -loglevel fatal -noautorotate -threads 8 -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p10le -strict -1 -vsync 0 -f yuv4mpegpipe e:\test.y4m SvtHevcEncApp -rc 0 -encMode 8 -i e:\test.y4m -profile 2 -tier 0 -b "E:\Temp\test_18_08_02_4910_01.265"
Cu SelurLast edited by Selur; 28th Sep 2019 at 12:26.
users currently on my ignore list: deadrats, Stears555, marcorocchini
Similar Threads
-
ffmpeg how to interpret parameters, documentation?
By BabaG in forum Newbie / General discussionsReplies: 2Last Post: 17th Aug 2019, 17:58