StaxRip

[stax76]

When I select a .mkv file as source and then go to Tools -> Launch -> mkvinfo GUI then StaxRip tries to open mkvinfo GUI but closes instantly, it crashes.

fixed

Is it a problem for Intel encoder only or Nvidia/ AMD has the same problem too, using ffmpeg dxva2 as a decoder ?

command line was wrong :o, fixed

According to Intel, Quick Sync is one word QuickSync

most google hits are two words

[NikosD]

fixed



command line was wrong :o, fixed



Have you uploaded the new test build ? :)

[stax76]

it's online now

[dejong12]

it's online now
You're on a roll today Stax, it's really nice to see you active.

[stax76]

It's many little only improvements but it's the little things that make a difference so it's important when Nikos or other people point it out.

I've sent a message to rigaya suggesting to support y4m output for all encoders.

[NikosD]

Hello.

I've done a few tests this morning regarding Intel HW H.264 encoding and the results are not so good.

So, on my system Win 10 x64 - Core i7-4790 - iGPU HD 4600@1.5GHz - Drivers v.4380, I find out these:


1) The main disappointment is the instability of Intel's HW encoder, probably due to drivers on Haswell and Windows 10

For almost all clips I tried, it starts very good with a performance of more than 200+ fps for 1080p to 1080p H.264 transcoding, but it has sudden drops of GPU load and performance to even less than half of it, around 80fps (!) and the average speed is about 120fps - very slow.

I remember the times that I had a steady 300+ fps for the same conversion.

I have discussed the same issue here and with rigaya, he told me that there were some MediaSDK releases that dropped performance a lot introducing new API versions, but it seems more of a problem of the driver, the GPU architecture and the OS version.

So, I wonder how Skylake performs on typical 1080p to 1080p H.264 conversion on yours platform and I mean the Skylake owners.


2) The ffmpeg (DXVA2) decoder is using a copy-back mode from GPU to system memory and the performance is worst than DSS2/LAV QSV and DSS2/LAV DXVA-Copy-back

So the performance of the decoders goes like this:

QSVEncC (Quick Sync) > LAV DXVA copy-back > LAV QSV > ffmpeg (DXVA2)

So, I would suggest to rename ffmpeg (DXVA2) to ffmpeg (DXVA2-CB) in case anyone wonders why is it so slow.

One more detail is that using ffmpeg (DXVA2) decoder, QSVEncC doesn't show the progress in percentage as with all the other decoders. Strange.

3) Frank, after the release of FFMpeg 2.8 last year supporting officially QSV transcoding (HW decoding + HW encoding), Intel has started supporting that implementation a lot.

We have spent a lot of time (YOU a LOT more) to build, test, debug GUIs for HW encoding based on rigaya's CLI HW encoders, but if I were you, I would investigate the ffmpeg QSV and NVENC implementations for HW transcoding on Intel and Nvidia HW, not only decoding.

[stax76]

@Nikos

It runs around ~200fps, my driver is probably outdated though.

I'll take a look at ffmpeg QSV/NVENC, there is an ffmpeg encoder which I can expand, it's a while back it was added so needs some modernization but it's based on the same new framework all recent encoders are based on.


------------------------------------------------------------
Encoding using QSVEncC
------------------------------------------------------------

D:\Projekte\GitHub\staxrip\bin\Apps\QSVEncC\QSVEncC64.exe --fallback-rc
--icq 25 -i D:\Temp\test.mkv -o D:\Temp\test_temp\test_new_out.h264

QSVEncC (x64) 2.39 (r951) by rigaya, Mar 13 2016 10:24:15 (VC 1900/Win/avx2)
OS Windows 10 (x64)
CPU Info Intel Core i5-6600K @ 3.50GHz [TB: 3.80GHz] (4C/4T) <Skylake>
GPU Info Intel HD Graphics 530 (24EU) 1150MHz (20.19.15.4331)
Media SDK QuickSyncVideo (hardware encoder) PG, 2nd GPU, API v1.17
Async Depth 6 frames
Buffer Memory d3d11, 1 input buffer, 18 work buffer
Input Info avcodec video: H.264/AVC, 1920x1080, 25/1 fps
Output H.264/AVC High @ Level 4
1920x1080p 1:1 25.000fps (25/1fps)
Target usage 4 - balanced
Encode Mode ICQ (Intelligent Const. Quality)
ICQ Quality 25
QP Limit min: none, max: none
Trellis Auto
Ref frames 3 frames
Bframes 3 frames, B-pyramid: on
Max GOP Length 250 frames
Scene Change off
Ext. Features PerMBRC
encoded 146824 frames, 203.56 fps, 1789.47 kbps, 1252.83 MB
encode time 0:12:01, CPULoad: 11.48
frame type IDR 588
frame type I 588, total size 36.25 MB
frame type P 37000, total size 733.73 MB
frame type B 109236, total size 482.85 MB

[NikosD]

My performance starts even better than that, but can't keep up and stalls for few moments completely unpredictably with all decoders I have tried -SW avs, LAV SW/HW, ffmpeg (DXVA2) or QSVEncC (Quick Sync)

If you have time, try various clips and see if that kind of performance ~200 fps is consistent across various clips for all transcoding time.

The older ffmpeg based encoders are useless.
They are based on SandyBridge and have very few options.

Last ffmpeg 3.0 is the minimum for anything based on ffmpeg.

What you could easily add right now, I think, is the ffmpeg (Quick Sync) decoder which has added HEVC decoding besides the other HW accelerated codecs of ffmpeg (DXVA2) and probably better performance than ffmpeg (DXVA2)

[stax76]

All three sources I tried give around 200 fps.

[JohnLai]

Note:
FFMPEG DXVA2 has problem with Intel IGPU (tested using haswell i3-4330 hd4600). If one has ONLY Intel IGPU alone, he must use ffmpeg QSV decoder instead of DXVA2, other conditions being the igpu must be active and primary display.

ffmpeg DXVA2 works well with dedicated NVIDIA and AMD gpus.

[NikosD]

As I wrote before, my instability problems happen with ALL decoders, even SW.

It would be useful if Frank could add in the GUI the ffmpeg Quick Sync decoder, though :)

BTW, rigaya replied that when the input comes from piping like ffmpeg dxva2, then QSVEncC can't display the percentage of progress.

P.S1

Maybe Intel want us all to buy Skylake, who knows ;)

P.S2

Haswell 4770K with Win 8.1 x64 and 4332 drivers - no dGPU - has no such issues.

The problem is probably v4380 drivers and/or Win 10

[stax76]

Has anybody a qsv and nvenc enabled ffmpeg build?

[NikosD]

The ffmpeg build included with StaxRip has qsv enabled.

You can check it by running -hwaccels and -codecs.

There a few *_qsv codecs available.

[NikosD]

Has anybody a qsv and nvenc enabled ffmpeg build?
Here is an interesting thread that looks like it was opened yesterday just for you !

http://forum.doom9.org/showthread.php?t=173304

[stax76]

it seems but I cannot get it working


-----------------------------------------------------------
_________ __ __________.__
/ _____// |______ ___ __\______ \__|_____
\_____ \\ __\__ \ \ \/ /| _/ \____ \
/ \| | / __ \_> < | | \ | |_> >
/_______ /|__| (____ /__/\_ \|____|_ /__| __/
\/ \/ \/ \/ |__|

------------------------------------------------------------
Environment
------------------------------------------------------------

StaxRip x64 : 1.3.3.1
OS : Windows 10 Pro
Language : German (Germany)
CPU : Intel(R) Core(TM) i5-6600K CPU @ 3.50GHz
GPU : NVIDIA GeForce GTX 960, Intel(R) HD Graphics 530

------------------------------------------------------------
Encoding H.264 Intel Quick Sync using ffmpeg
------------------------------------------------------------

D:\Projekte\GitHub\staxrip\bin\Apps\ffmpeg\ffmpeg.exe -threads 1
-hwaccel dxva2 -i D:\Video\Samples\Misc\eli.mp4 -c:v h264_qsv
-q:v 25 -y -hide_banner D:\Video\Samples\Misc\eli_temp\eli_out.mkv

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'D:\Video\Samples\Misc\eli.mp4':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: isommp42
creation_time : 2015-05-20 08:55:10
Duration: 00:00:43.42, start: 0.000000, bitrate: 2367 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p,
1280x720 [SAR 1:1 DAR 16:9], 2173 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc (default)
Metadata:
handler_name : VideoHandler
Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 192 kb/s (default)
Metadata:
creation_time : 2015-05-20 08:55:10
handler_name : IsoMedia File Produced by Google, 5-11-2011
[h264_qsv @ 0000018b333038c0] More than one of: { constant qscale, lookahead, VCM } requested,
only one of them can be used at a time.
Output #0, matroska, to 'D:\Video\Samples\Misc\eli_temp\eli_out.mkv':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: isommp42
Stream #0:0(und): Video: h264, none, q=2-31, 128 kb/s, SAR 1:1 DAR 0:0, 29.97 fps (default)
Metadata:
handler_name : VideoHandler
encoder : Lavc57.28.100 h264_qsv
Stream #0:1(eng): Audio: vorbis, 0 channels, 128 kb/s (default)
Metadata:
creation_time : 2015-05-20 08:55:10
handler_name : IsoMedia File Produced by Google, 5-11-2011
encoder : Lavc57.28.100 libvorbis
Stream mapping:
Stream #0:0 -> #0:0 (h264 (native) -> h264 (h264_qsv))
Stream #0:1 -> #0:1 (aac (native) -> vorbis (libvorbis))
Error while opening encoder for output stream #0:0 - maybe incorrect parameters
such as bit_rate, rate, width or height

------------------------------------------------------------
Error Encoding H.264 Intel Quick Sync using ffmpeg
------------------------------------------------------------

Encoding H.264 Intel Quick Sync using ffmpeg failed with exit code: 1 (0x1)

The exit code might be a system error code: STATUS_WAIT_1

The exit code might be a system error code: Unzulässige Funktion.

[NikosD]

I'm not 100% certain, but I think you don't need -hwaccels dxva2, try -hwaccels qsv or nothing and you have to use -vcodec h264_qsv and try without specifying encoding mode at all.

[stax76]

I think it's a config issue

https://www.ffmpeg.org/ffmpeg-all.html#QSV-encoders

edit:

this encodes now:

D:\Projekte\GitHub\staxrip\bin\Apps\ffmpeg\ffmpeg.exe -threads 1 -hwaccel dxva2 -i D:\Video\Samples\Misc\eli.mp4 -c:v h264_qsv -b:v 1000k -an -y -hide_banner D:\Video\Samples\Misc\eli_temp\eli_out.mkv

edit2:

about 20 fps faster then QSVEncC

[NikosD]

I've just read in ffmpeg Zeranoe forum a comment from him


Re: Intel QSV Codecs
PostTue Mar 01, 2016 5:16 am

Intel QSV is now included in the daily builds, and Windows XP support has been dropped.


So, it seems that from March 1st the daily builds include QSV.

Probably ffmpeg NVENC is not so mature yet to include it.

[stax76]

I almost gave up until I found out some has to type: ffmpeg -h full

then 8000 lines print including this:


h264_qsv encoder AVOptions:
-async_depth <int> E..V.... Maximum processing parallelism (from 0 to INT_MAX) (default 4)
-avbr_accuracy <int> E..V.... Accuracy of the AVBR ratecontrol (from 0 to INT_MAX) (default 0)
-avbr_convergence <int> E..V.... Convergence of the AVBR ratecontrol (from 0 to INT_MAX) (default 0)
-preset <int> E..V.... (from 1 to 7) (default medium)
veryfast E..V....
faster E..V....
fast E..V....
medium E..V....
slow E..V....
slower E..V....
veryslow E..V....
-vcm <int> E..V.... Use the video conferencing mode ratecontrol (from 0 to 1) (default 0)
-rdo <int> E..V.... Enable rate distortion optimization (from -1 to 1) (default -1)
-max_frame_size <int> E..V.... Maximum encoded frame size in bytes (from -1 to 65535) (default -1)
-max_slice_size <int> E..V.... Maximum encoded slice size in bytes (from -1 to 65535) (default -1)
-bitrate_limit <int> E..V.... Toggle bitrate limitations (from -1 to 1) (default -1)
-mbbrc <int> E..V.... MB level bitrate control (from -1 to 1) (default -1)
-extbrc <int> E..V.... Extended bitrate control (from -1 to 1) (default -1)
-adaptive_i <int> E..V.... Adaptive I-frame placement (from -1 to 1) (default -1)
-adaptive_b <int> E..V.... Adaptive B-frame placement (from -1 to 1) (default -1)
-b_strategy <int> E..V.... Strategy to choose between I/P/B-frames (from -1 to 1) (default -1)
-cavlc <int> E..V.... Enable CAVLC (from 0 to 1) (default 0)
-idr_interval <int> E..V.... Distance (in I-frames) between IDR frames (from 0 to INT_MAX) (default 0)
-pic_timing_sei <int> E..V.... Insert picture timing SEI with pic_struct_syntax element (from 0 to 1) (default 1)
-single_sei_nal_unit <int> E..V.... Put all the SEI messages into one NALU (from -1 to 1) (default -1)
-max_dec_frame_buffering <int> E..V.... Maximum number of frames buffered in the DPB (from 0 to 65535) (default 0)
-look_ahead <int> E..V.... Use VBR algorithm with look ahead (from 0 to 1) (default 1)
-look_ahead_depth <int> E..V.... Depth of look ahead in number frames (from 0 to 100) (default 0)
-look_ahead_downsampling <int> E..V.... (from 0 to 2) (default unknown)
unknown E..V....
off E..V....
2x E..V....
-int_ref_type <int> E..V.... Intra refresh type (from -1 to 65535) (default -1)
none E..V....
vertical E..V....
-int_ref_cycle_size <int> E..V.... Number of frames in the intra refresh cycle (from -1 to 65535) (default -1)
-int_ref_qp_delta <int> E..V.... QP difference for the refresh MBs (from -32768 to 32767) (default -32768)
-recovery_point_sei <int> E..V.... Insert recovery point SEI messages (from -1 to 1) (default -1)
-trellis <flags> E..V.... Trellis quantization (default 0)
off E..V....
I E..V....
P E..V....
B E..V....
-profile <int> E..V.... (from 0 to INT_MAX) (default unknown)
unknown E..V....
baseline E..V....
main E..V....
high E..V....
-a53cc <int> E..V.... Use A53 Closed Captions (if available) (from 0 to 1) (default 0)

hevc_qsv encoder AVOptions:
-async_depth <int> E..V.... Maximum processing parallelism (from 0 to INT_MAX) (default 4)
-avbr_accuracy <int> E..V.... Accuracy of the AVBR ratecontrol (from 0 to INT_MAX) (default 0)
-avbr_convergence <int> E..V.... Convergence of the AVBR ratecontrol (from 0 to INT_MAX) (default 0)
-preset <int> E..V.... (from 1 to 7) (default medium)
veryfast E..V....
faster E..V....
fast E..V....
medium E..V....
slow E..V....
slower E..V....
veryslow E..V....
-vcm <int> E..V.... Use the video conferencing mode ratecontrol (from 0 to 1) (default 0)
-rdo <int> E..V.... Enable rate distortion optimization (from -1 to 1) (default -1)
-max_frame_size <int> E..V.... Maximum encoded frame size in bytes (from -1 to 65535) (default -1)
-max_slice_size <int> E..V.... Maximum encoded slice size in bytes (from -1 to 65535) (default -1)
-bitrate_limit <int> E..V.... Toggle bitrate limitations (from -1 to 1) (default -1)
-mbbrc <int> E..V.... MB level bitrate control (from -1 to 1) (default -1)
-extbrc <int> E..V.... Extended bitrate control (from -1 to 1) (default -1)
-adaptive_i <int> E..V.... Adaptive I-frame placement (from -1 to 1) (default -1)
-adaptive_b <int> E..V.... Adaptive B-frame placement (from -1 to 1) (default -1)
-b_strategy <int> E..V.... Strategy to choose between I/P/B-frames (from -1 to 1) (default -1)
-cavlc <int> E..V.... Enable CAVLC (from 0 to 1) (default 0)
-load_plugin <int> E..V.... A user plugin to load in an internal session (from 0 to 2) (default hevc_sw)
none E..V....
hevc_sw E..V....
hevc_hw E..V....
-load_plugins <string> E..V.... A :-separate list of hexadecimal plugin UIDs to load in an internal session (default "")
-profile <int> E..V.... (from 0 to INT_MAX) (default unknown)
unknown E..V....
main E..V....
main10 E..V....
mainsp E..V....

[NikosD]

From what I have tested and what I have read so far:

If you don't use the -hwaccel switch, then SW decoding is used.

In order to have HW accelerated decoding you have to use -hwaccel which takes two arguments: dxva2 or qsv

You can find the hwaccels available by running ffmpeg -hwaccels. You have to include the last "s" (plural)

By using -hwaccel dxva2, you can get HW decoding for H.264, MPEG2, VC-1/WMV3 but no H.265.

By using -hwaccel qsv, you can get HW decoding for H.265, H.264, MPEG2, VC-1/WMV3

The problem is that in the help file, the term "h264_qsv" and every "*_qsv" item, is used to describe decoding and encoding.

qsv decoding is used only in -hwaccel switch, writing just -hwaccel qsv and the app knows what codec to HW accelerate, just like -hwaccel dxva2.

So, do you see any performance difference by using -hwaccel dxva2 vs - hwaccel qsv ?

[stax76]

-hwaccel qsv -threads 1 : 108 fps
-hwaccel qsv : 240 fps

-hwaccel dxva2 -threads 1 : 220 fps
-hwaccel dxva2 : warning

problem is ffmpeg freezes all the time by printing:

Press [q] to stop, [?] for help

and doing nothing otherwise, after installing the new beta driver and rebooting it started to work again but not for long

[NikosD]

-hwaccel qsv -threads 1 : 108 fps
-hwaccel qsv : 240 fps

-hwaccel dxva2 -threads 1 : 220 fps
-hwaccel dxva2 : warning


Thanks.


problem is ffmpeg freezes all the time by printing:

Press [q] to stop, [?] for help

and doing nothing otherwise



I have exactly the same problem and thought it was my system again (Haswell - Win 10 - v4380)


Edit:
Try SW decoding without -hwaccel switch

[stax76]

SW decoding and QSVEncC works, looks like somebody has to visit ffmpeg bug tracker :)

[NikosD]

You mean ffmpeg SW decoding + ffmpeg gsv encoding works ?

[stax76]

ffmpeg qsv decoding does not work

[NikosD]

If you omit -hwaccel switch, then ffmpeg SW decoding is used.

[stax76]

ffmpeg SW decoding works

[nevcairiel]

The -hwaccel qsv switch is special, its not meant to use qsv decoding, you need to manually tell it to do that.
Using something like "ffmpeg -hwaccel qsv -c:v h264_qsv -i file.mp4 -c:v h264_qsv out.mkv" would use qsv decoding, qsv encoding, with no copying back to system memory (thats what the -hwaccel qsv does). Note that this mode is somewhat unstable because qsv sucks.

[NikosD]

OK. .But if the implementation of -hwaccel qsv doesn't use copy - back like ffmpeg dxva2, then CPU usage should be lower.

My tests show a CPU usage close to a copy - back mechanism and not to native mode.

Some copy - back to memory should be happening, but I'll test it again - when it's not freezing - to be sure.

QSV transcoding (decoding+encoding) doesn't suck and the proof is the native QSV transcoding of QSVEncC with lowest CPU usage and fast performance.

Latest MediaSDK and drivers seem to need some more work on Win 10 and Haswell.

[JohnLai]

-hwaccel qsv = this one was mentioned by ffmpeg contributor to be 'zero copy' mode. No idea why this mode has higher cpu usage than command below;

The command below is 'copy-back' mode;
ffmpeg -vcodec h264_qsv -i "INPUT.mkv" -vcodec h264_qsv -b:v 1000k "OUTPUT.mkv"

Then again, one could COMBINE;
ffmpeg -hwaccel qsv -vcodec h264_qsv -i "INPUT.mkv" -vcodec h264_qsv -b:v 1000k "OUTPUT.mkv"
to get even lower cpu usage.


Note: Remember, Intel IGPU has to be the primary. NO dedicated GPU.

EDIT: I just realize nevcairiel had mentioned it....darn, I just make a fool outta myself.

Fine, next lesson;

Note: To get ffmpeg help, use "ffmpeg -h encoders=nvenc" . To get list of encoder, use "ffmpeg -encoders"


FFMPEG WITH NVRESIZE (g3862200 64bit only, one that compiled with a script from RDP few months ago);
https://www.solidfiles.com/v/zyxWGRgGx53Yn
(Install ublock/adblock and noscript, don't click the wrong 'download')

Command;
ffmpeg -threads 1 -hwaccel dxva2 -i "INPUT.mkv" -pix_fmt nv12 -filter_complex nvresize=1:s=1280x720:readback=0 -vcodec nvenc_hevc -tier high -level 4.1 -preset slow -async 1 -maxrate 10M -bufsize:v 10M -bf 0 -refs 9 -g 240 -i_qfactor 0.71 -b_qfactor 1.25 -qmin 1 -qmax 25 -enableaq true -2pass true -an -sn "OUTPUT.mkv"

Explanation (some copy-pasted from nvidia documentation);
Option available for "s" : hd1080\|hd720\|hd480\|wvga\|cif or one could use 1280x720 (resolution) directly.
Option available for "g" : GOP basic formula "A" seconds x "B" fps = GOP length, in example above, i put 8seconds x 30fps=240, maybe?

Nvresize filter has a -readback parameter, if it's set as 0, resized
result won't be copied back to CPU, mostly in case it's connected to an
NVENC encoder。 If it's set as 1, resized result will still be copied
back to AVFrame so that it could be compatible with other components.

Advanced usage for multiple video resizing at once;
ffmpeg -y -i INPUT -filter_complex
nvresize=5:s=hd1080|hd720|hd480|wvga|cif:readback=0[out0][out1][out2][out3][out4]
-map [out0] -an -vcodec nvenc -b:v 6M -bufsize 6M -maxrate 6.8M -bf 2 out0nv.mp4
-map [out1] -an -vcodec nvenc -b:v 3M -bufsize 3M -maxrate 3.4M -bf 2 out1nv.mp4
-map [out2] -an -vcodec nvenc -b:v 2M -bufsize 2M -maxrate 2.1M -bf 2 out2nv.mp4
-map [out3] -an -vcodec nvenc -b:v 1M -bufsize 1M -maxrate 1.1M -bf 2 out3nv.mp4
-map [out4] -an -vcodec nvenc -b:v 0.5M -bufsize 0.5M -maxrate 0.5M -bf 2 out4nv.mp4
Note: "- y" means overwrite existing files without confirmation.

Example:
ffmpeg -y -i $1 $2 $3 -filter_complex \nvresize=5:s=hd1080\|hd720\|hd480\|wvga\|cif:readback=0[out0][out1][out2][out3][out4]\ -map [out0] -an -vcodec nvenc_h264 -preset slow -profile:v main -async 1 -b:v 200M -bufsize 200M -maxrate 200M -refs 1 -bf 2 $1_1080p.mp4 \ -map [out1] -an -vcodec nvenc_h264 -preset slow -profile:v main -async 1 -b:v 100M -bufsize 100M -maxrate 100M -refs 1 -bf 2 $1_720p.mp4 \ -map [out2] -an -vcodec nvenc_h264 -preset slow -profile:v main -async 1 -b:v 50M -bufsize 50M -maxrate 50M -refs 1 -bf 2 $1_480p.mp4 \ -map [out3] -an -vcodec nvenc_h264 -preset slow -profile:v main
-async 1 -b:v 25M -bufsize 25M -maxrate 25M -refs 1 -bf 2 $1_wvga.mp4 \ -map [out4] -an -vcodec nvenc_h264 -preset slow -profile:v main -async 1 -b:v 10M -bufsize 10M -maxrate 10M -refs 1 -bf 2 $1_cif.mp4

[NikosD]

I did some further tests regarding the stability of the QSVEncC and unfortunately it seems that it is StaxRip's fault.

Running the command via CLI directly without using StaxRip's GUI, i get a stable performance of ~250fps (!)

The exact same clip, with the exact same options drops the performance from 250fps to 99fps (!) using StaxRip.

In all cases I used QSVEncC HW decoding, the switch --avqsv.

So, the only parameter different is the demux/mux of the two apps and maybe some hidden (?) or non-hidden switches.

I can't think of something else, but definitely QSVEncC as a standalone app has no problem at all (!!) on my system.

[NikosD]

Hello Frank.

I used latest QSVEncC v2.40 with a custom switch suggested by rigaya in order to find out what is going on.

So, I put in "Custom Switches:" field these switches --input-thread 1 --output-thread 1 --perf-monitor --log log.txt running at the same time the GPU-Z app in the background and I sent rigaya the log.txt and the .csv file produced in the temp directory of StaxRip.

He replied that he can see QSVEncC waiting doing nothing for a while and start running again in a period of about 5 sec.

Weird behavior which is the cause of my sudden drops of GPU load and performance.

I don't know how could I help more in order to find out the cause of the problem.

[stax76]

Are you sure there is a difference between windows shell and StaxRip? I get around 200 fps in and outside of StaxRip, when I wake up from Standby though it's only 70 fps again in and outside of StaxRip the same.

[Havokdan]

Wow, I manually changed the version of QuickSync to version 2.40, the encodes who were in the average speed of 70/90 fps was for over 400 fps.

[Pulp Catalyst]

bug in StaxRip x64 1.3.2.0 pre-release

Python exception: knlm.KNLMeansCL: a must be greater then or equel to 1!

this happens with temporal light/medium/strong profile

[NikosD]

Are you sure there is a difference between windows shell and StaxRip? I get around 200 fps in and outside of StaxRip, when I wake up from Standby though it's only 70 fps again in and outside of StaxRip the same.
Yes. I did the tests a few times.

The problem is there, even when I run "Execute command" from inside StaxRip running QSVEncC.

Only when I run QSVEncC from pure Shell environment I get stable performance.

[stax76]

Did you try to reboot? It has helped here.

[Magik Mark]

bug in StaxRip x64 1.3.2.0 pre-release



this happens with temporal light/medium/strong profile


Are you using nvidia gtx 900 series Gpu?


Sent from my iPhone using Tapatalk

[NikosD]

Did you try to reboot? It has helped here.
If it was for me, I always shut down and restart my PC.

I don't leave it open for no reason.

[Pulp Catalyst]

i'm using gtx 760, i changed to another profile, i'm now using the temporal + spacial one instead, as it's only "dvd" material, the speed is ok, the GPU can decode fast enough to keep the pipe fed to x265.

[stax76]

If it was for me, I always shut down and restart my PC.

I don't leave it open for no reason.

My PC boots ridiculous slow, like a minute and there is nothing left I could try to make it faster. I shut it down every night but at daytime I often just put it in energy saving mode.

I made some more test with same results as before, I never saw a fps difference between running in StaxRip or the command shell. Normally I get about 220 fps but when I but the PC shortly to energy saving mode it drops to pitiful 70 fps until I either reboot or shortly deactivate the device in the device manager. My specs are:

Windows 10 Pro - 10586.164
i5-6600K - Skylake - 20.19.15.4404 - GPU set to always on in Bios, no need for fake monitor
GTX 960 - Maxwell 2 - 10.18.13.6451
GA-Z170X-UD3 - F6

[burfadel]

Just a reminder Yadifmod2 has been updated :)

[NikosD]

I made some more test with same results as before, I never saw a fps difference between running in StaxRip or the command shell.


OK...Here we are.

Rigaya managed to reproduce my issue with his Haswell Win 8.1 Pro system and he found out a workaround.

In order to reproduce the issue with your systems, you have to transcode a clip with high bitrate output, more than 20 Mbps.

Probably you must have a large bitrate input source clip and use the default -cqp or -icq encoding modes with low values for cqp and icq, in order to output large bitrates.

My sample is a source clip with 53Mbps and the output is 25Mbps using default -cqp value of QSVEncC.

The workaround is to add a custom switch --output-buf with values 4 or 8 or 16.

With that switch --output-buf 16 my average speed is ~235 fps.

The default value of --output-buf is 64 and it drops my performance to ~95 fps (!)

That switch defines the internal buffer size in MBytes for output and its purpose is not to mix up disk input & output in fine grain for further performance.

According to rigaya, output buffer size and Staxrip should have no interaction to each other.

As a workaround he will probably put a lower than 64 value to that switch in the next QSVEncC release, BUT Frank I think you could probably send an email to rigaya to find the cause of the issue and fix it, if possible.

I don't know if Skylake has the same issue, using large bitrate (> 20 Mbps) output.

I have to write once more, that using the CLI version of QSVEncC outside of StaxRip, I have no problem at all using the default values, but the CLI version of QSVEncC inside StaxRip, drops the transcoding speed more than 60% for high bitrate outputs.

[NikosD]

According to rigaya, Skylake has a drop in performance around 10% when the encoding exceeds 20Mbps and QSVEncC is used inside StaxRip.

That reminds me the increase in performance of ffmpeg qsv encoding that Frank noticed, when using ffmpeg CLI app outside StaxRip, compared to QSVEncC inside StaxRip.

Frank, it would be useful to try ffmpeg qsv encoding inside StaxRip, if you are interested in implementing that GUI, or try QSVEncC inside/ outside StaxRip with large bitrate output.

[stax76]

@Nikos

I'm still not able to reproduce it, please mail a full StaxRip log file and one log from the command shell (Ctrl+A and Enter), if possible tell me where to download the source video.

[NikosD]

Frank, I have sent you an email with everything you asked.

Now, for everyone wanted to test my source sample you can download it from here:
http://www.filedropper.com/megascansjungle

[jsquare]

Been using and testing Quick Sync with Staxrip (QSVEncC) these past few days, QS encodes are very flat and kills a lot of detail unlike x264 that can be fine tuned, but the speed of QS is 4 times faster than x264 on my rig. I tried to solve this issue with one of the custom switches: The --vpp-detail-enhance <int> option, but it gives the same results no matter the value of the strength, tried from 1 to 100.
Anyone knows the values or range for this variable?

[stax76]

@Nikos

with your sample and settings I get this numbers:

StaxRip: 244-245 fps
Shell: 244-245 fps
--output-buf 16: 252 fps

I see a drop to 86 fps after wake up from power saving mode. Looks like a problem of the Intel driver.

If a programmer has a problem like yours chances to find the reason are already not good but if it happens not on his machine and only on one machine chances are near zero.

You can try to change the process priority in the settings and change your target drive because --output-buf might affect disk IO. I can add support for --output-buf of course.

I have done some work on the ffmpeg GUI and will do some more but due to the freezes it's not really useful, I hope most issues can be fixed some time.

[JohnLai]

Been using and testing Quick Sync with Staxrip (QSVEncC) these past few days, QS encodes are very flat and kills a lot of detail unlike x264 that can be fine tuned, but the speed of QS is 4 times faster than x264 on my rig. I tried to solve this issue with one of the custom switches: The --vpp-detail-enhance <int> option, but it gives the same results no matter the value of the strength, tried from 1 to 100.
Anyone knows the values or range for this variable?

{Detail Enhancement}: is the process of enhancing the edge contrast to improve its sharpness. VPP uses an adaptive detail enhancement algorithm to increase the edge sharpness.

Value of 0-100 (inclusive) indicates the level of details to be enhanced. Default value is 0 (disabled).

Sorry to break the party, but that option is not what you need.
There is not much you can do with QSV about finer detail retainment. Maybe LA-ICQ mode, higher value for la-depth scenechange, trellis for all, --quality sets to best, --b-pyramid on,--weightp, --weightb, --la-quality sets to slow .....etc?

[NikosD]

@Nikos

with your sample and settings I get this numbers:

StaxRip: 244-245 fps
Shell: 244-245 fps
--output-buf 16: 252 fps

I see a drop to 86 fps after wake up from power saving mode. Looks like a problem of the Intel driver.

If a programmer has a problem like yours chances to find the reason are already not good but if it happens not on his machine and only on one machine chances are near zero.

You can try to change the process priority in the settings and change your target drive because --output-buf might affect disk IO. I can add support for --output-buf of course.



Rigaya released QSVEncC v2.41 with a default --output-buf 8, so no worries of using QSVEncC inside or outside StaxRip.

It's only that we really didn't find out the reason of dropping performance on Haswell so much inside StaxRip.



I have done some work on the ffmpeg GUI and will do some more but due to the freezes it's not really useful, I hope most issues can be fixed some time.


Nice.
It's a work on development from ffmpeg team, so maybe sometime they will reach the stability of QSVEncC.

You could also add the ffmpeg QSV option as a decoder in all three HW encoding GUIs of rigaya's encoders inside StaxRip (Intel, Nvidia, AMD) without changing the encoder.

It could be better/ more compatible than ffmpeg DXVA2 for Intel.


Been using and testing Quick Sync with Staxrip (QSVEncC) these past few days, QS encodes are very flat and kills a lot of detail unlike x264 that can be fine tuned, but the speed of QS is 4 times faster than x264 on my rig. I tried to solve this issue with one of the custom switches: The --vpp-detail-enhance option, but it gives the same results no matter the value of the strength, tried from 1 to 100.
Anyone knows the values or range for this variable?


QSVEncC is based on a mixed/hybrid fixed function/GPU encoder with a lot more flexibility and options than NVEncC (Nvidia) or VCEEncC (AMD), but still is no match for a SW encoder like x264 in terms of encoding options.

The main advantages of every HW encoder is the speed, low power and efficiency.

The main drawbacks are quality, size and flexibility.

Try --icq encoding mode with lower values and maybe the lookahead switches.

Read the help file, it has a lot of options and if some of them don't work, email directly to the developer (rigaya) pointing out the issue.

He usually fixes bugs in the next release.