StaxRip

[Yups]

Originally Posted by Yups

http://www.station-drivers.com/index...d=1901&lang=en


Media SDK 1.17 has been released with this driver. No documentation or changelog available yet. Intel says soon, whatever it means.

New documentation has been released for API 1.17.

https://software.intel.com/sites/def...ease_notes.pdf
https://software.intel.com/sites/def...diasdk-man.pdf

[NikosD]

The release notes are for API v1.16, but the reference manual is for v1.17.

Stax76 and StaxRip has nothing to do with this, because he doesn't write code for MediaSDK.

The developer of QSVEncC which is based on MediaSDK is rigaya, you could send him an email.

Here in Doom9 there is no thread for MediaSDK.

A few years ago, the thread of QSV decoder (a decoder based on MediaSDK) by egur (Eric Gur) - an Intel employee - was very active, but now he doesn't seem interested in development any more.

[Yups]

Release notes should be for 1.17 because there wasn't Skylake support in 1.16, now it is. And there are specific 1.17 notes. Rigaya told this might be interesting for QSVEncC.

[NikosD]

API v1.17 added for the first time rotation of 90,180 and 270 degrees.

I've already asked rigaya for implementing it.

Hope he adds it and Stax76 too in StaxRip's GUI.

[NikosD]

QSVEncC v2.22 is out adding support of API v1.17 using latest unofficial drivers v4312.

It adds vpp-rotation <angle>.

[stax76]

I'll catch up on missed posts in the next days.

Regarding test builds I made a separate wiki page, changes not yet uploaded will be stated in the future.

https://github.com/stax76/staxrip/wi...ment-Changelog

[dejong12]

Originally Posted by stax76

I'll catch up on missed posts in the next days.

Regarding test builds I made a separate wiki page, changes not yet uploaded will be stated in the future.

https://github.com/stax76/staxrip/wi...ment-Changelog

Thanks! NVEncC 1.13 is out by the way.

[JohnLai]

Indeed.....VBR2pass and adaptive quantization option gui for staxrip?

[stax76]

Originally Posted by JohnLai

Indeed.....VBR2pass and adaptive quantization option gui for staxrip?

please let me know if it works

https://github.com/stax76/staxrip/wi...ment-Changelog

[JohnLai]

Originally Posted by stax76

please let me know if it works

https://github.com/stax76/staxrip/wi...ment-Changelog

Will test it later.

Stax76, I got few questions.....

1)Why is your ffmpeg version has dxva decode support, but lack of ffmpeg QSV Decode + VPP? Oh,plus NVENC support as well?

2)On 9 November 2015 or so....nvidia include GPU Resize and GPU Zero-copy for ffmpeg. https://developer.nvidia.com/ffmpeg . Scroll down the site and click the green "Download" to get nvidia pdf reference.

Reason = rigaya qsv decode + vpp resize often crash for my win10 hd4000 intel igpu. I wonder if ffmpeg is more error resilience at it?

*I actually need hardware based resizer......T_T...Although your ffmpeg has DXVA support (it actually faster in decoding than DSS2 LAVfilter copyback), the cpu based resizing really take a hit on transcoding fps.

*One ffmpeg to rule them all?

[stax76]

@JohnLai

sounds promising, I'll investigate it.

[Magik Mark]

@JohnLai

vbr2 is awesome! Good Quality & small file size. It can encode in 10 minutes for a typical 1 hour tv show

[NikosD]

Originally Posted by JohnLai

1)Why is your ffmpeg version has dxva decode support, but lack of ffmpeg QSV Decode + VPP? Oh,plus NVENC support as well?

Reason = rigaya qsv decode + vpp resize often crash for my win10 hd4000 intel igpu. I wonder if ffmpeg is more error resilience at it?

...Although your ffmpeg has DXVA support (it actually faster in decoding than DSS2 LAVfilter copyback), the cpu based resizing really take a hit on transcoding fps.

I remember checking FFMpeg a while ago and for Intel, it had all HW features supported - decoding, encoding and VPP.

BUT IIRC, encoding and VPP were loosely supported, meaning very low API version support, capable for SandyBridge.

SandyBridge can support up to API v1.4 only (I think), so all the advanced rate controls and VPP functions shouldn't be supported by FFMPEG QSV encoding and VPP.

Do you know if the latest version of FFMPEG QSV has changed that ?
Is it updated ?

Now, regarding FFMpeg QSV decoding haven't seen or tested yet.

Have you done any tests regarding speed and video stream compatibility of FFMPEG QSV decoding compared to DXVA LAV and MediaSDK QSVEncC by Rigaya ?

Would be interesting to know...

P.S

I forgot to say that your problems with qsvencc decode + vpp could probably occur due to your Ivybridge setup.
I don't think Haswell or better have such problems.

What is the latest API version support of Ivy ?

[JohnLai]

Originally Posted by stax76

@JohnLai

sounds promising, I'll investigate it.

Thanks for your hardwork. ^.^b
Oh ya, the VBR2 and AQ GUI option works without issue.

Originally Posted by Magik Mark

@JohnLai

vbr2 is awesome! Good Quality & small file size. It can encode in 10 minutes for a typical 1 hour tv show

Remember to use adaptive quantization too.

Originally Posted by NikosD

I remember checking FFMpeg a while ago and for Intel, it had all HW features supported - decoding, encoding and VPP.

BUT IIRC, encoding and VPP were loosely supported, meaning very low API version support, capable for SandyBridge.

SandyBridge can support up to API v1.4 only (I think), so all the advanced rate controls and VPP functions shouldn't be supported by FFMPEG QSV encoding and VPP.

Do you know if the latest version of FFMPEG QSV has changed that ?
Is it updated ?

Now, regarding FFMpeg QSV decoding haven't seen or tested yet.

Have you done any tests regarding speed and video stream compatibility of FFMPEG QSV decoding compared to DXVA LAV and MediaSDK QSVEncC by Rigaya ?

Would be interesting to know...

P.S

I forgot to say that your problems with qsvencc decode + vpp could probably occur due to your Ivybridge setup.
I don't think Haswell or better have such problems.

What is the latest API version support of Ivy ?

Even without VPP usage, rigaya QSVencC decode still crash for my system.
From rigaya qsvencc, the API version 1.11 is reported for HD4000.


FFMPEG QSV 2.8 supposes to change that......but so far....I cant find any ffmpeg cli that has full QSV decode + vpp + encode around the internet. Compiling one is too troublesome. Headache.
There is one ffmpeg with qsv_h264 decoder. ffmpeg-20150610-git-913685f-win64-static from zeronoa. The problem, it doesnt work. You will encounter exactly error as mentioned here http://ffmpeg.org/pipermail/ffmpeg-d...st/176843.html
Based on the mailing list, seems like the latest ffmpeg fixed it, but there isnt anyone compiling and making it available online.


EDIT: -.-......I just found one binary.....https://github.com/illuspas/ffmpeg-hw-win32 .........click 'Download Zip'.....

Extract out anywhere..... Benchmark time? Start command prompt.......

ffmpeg -vcodec h264_qsv -i test_track1_und.h264 -f null -

Should work? GPUZ report the HD4000 has utilization of 70 - 76% for bitrate 3072Kbps 1080p test file.

The log:

ffmpeg version 2.8 Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 5.2.0 (GCC)
configuration: --prefix=/home/aliang/Library/mingw --cross-prefix=i686-w64-mingw32- --cc='ccache i686-w64-mingw32-gcc' --enable-cross-compile --target-os=mingw32 --arch=i686 --enable-small --disable-doc --disable-debug --enable-nvenc --enable-libmfx --enable-libfdk-aac --enable-libspeex --enable-libx264 --enable-libx265 --enable-libopenh264 --enable-libopus --enable-libmp3lame --enable-nonfree --enable-gpl
libavutil 54. 31.100 / 54. 31.100
libavcodec 56. 60.100 / 56. 60.100
libavformat 56. 40.101 / 56. 40.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 40.101 / 5. 40.101
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.101 / 1. 2.101
libpostproc 53. 3.100 / 53. 3.100
Input #0, h264, from 'test_track1_und.h264':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: h264, nv12, 1920x1080, 12.50 fps, 25 tbr, 1200k tbn, 25 tbc
Output #0, null, to 'pipe:':
Metadata:
encoder : Lavf56.40.101
Stream #0:0: Video: rawvideo (NV12 / 0x3231564E), nv12, 1920x1080, q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
Metadata:
encoder : Lavc56.60.100 rawvideo
Stream mapping:
Stream #0:0 -> #0:0 (h264 (h264_qsv) -> rawvideo (native))
Press [q] to stop, [?] for help
[h264_qsv @ 027bebe0] A decode call did not consume any data=N/A
Last message repeated 10 times
frame=34410 fps=179 q=-0.0 Lsize=N/A time=00:45:53.12 bitrate=N/A
video:2151kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown


Note:someone is adding qsv vpp as ffmpeg -vf support to ffmpeg on 12 Nov 16:46 2015......
http://search.gmane.org/?author=Sven+Dueking&sort=date
*deleted*

Hmm...just noticed ffmpeg -benchmark argument, might as well as testing using the command below;

ffmpeg -an -benchmark -vcodec h264_qsv -i test.mkv -f null -


Update:
-.- Darn it.....seem like ffmpeg QSV above is really slow in decoding. When I use "ffmpeg -an -benchmark -hwaccel dxva2 -i test.mkv -f null -" in order to benchmark the same video using my discrete gpu gtx 970....i got this result :

Input stream #0:0 frame changed from size:1920x1080 fmt:yuv420p to size:1920x1080 fmt:nv12
[null @ 04707300] Encoder did not produce proper pts, making some up.
frame=34410 fps=402 q=-0.0 Lsize=N/A time=00:23:55.31 bitrate=N/A
video:2151kB audio:247256kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=32.672s
bench: maxrss=236900kB

179fps ffmpeg QSV decoder vs 402fps ffmpeg DXVA2 gtx 970 decoder.
I guess this ffmpeg slow qsv decode is the same issue encountered by rigaya not too long ago. Before any conclusion is done......NikosD~~, can you post your ffmpeg QSV decode fps here?

ffmpeg -vcodec h264_qsv -i test.mkv -an -vcodec h264_qsv -q 20 test.h264
frame= 4795 fps=130 q=-0.0 Lsize= 141545kB time=00:03:19.78 bitrate=5804.0kbits/s

Hmm.....i wonder if one must use "-hwaccel qsv" instead of using h264_qsv decoder?
From ffmpeg documentation;
-hwaccel[:stream_specifier] hwaccel (input,per-stream)
Use hardware acceleration to decode the matching stream(s). The allowed values of hwaccel are:
qsv
Use the Intel QuickSync Video acceleration for video transcoding.
Unlike most other values, this option does not enable accelerated decoding (that is used automatically whenever a qsv decoder is selected), but accelerated transcoding, without copying the frames into the system memory.
For it to work, both the decoder and the encoder must support QSV acceleration and no filters must be used.

-.- too bad when i run "ffmpeg -hwaccels" to list out any hardware acceleration, only "dxva2" is shown.

Update2: On the bright side of the news....
http://lists.ffmpeg.org/pipermail/ff...er/181843.html
Thu Oct 22 17:56:10 CEST 2015

He said 2.5 times faster? Maybe like 179fps X 2.5 = 358fps? (This figure seems to be realistic)
Oh well...let see how ffmpeg developers re-design session control and internal allocation.......(copy pasted)

[NikosD]

Originally Posted by JohnLai

179fps ffmpeg QSV decoder vs 402fps ffmpeg DXVA2 gtx 970 decoder.
I guess this ffmpeg slow qsv decode is the same issue encountered by rigaya not too long ago. Before any conclusion is done......NikosD~~, can you post your ffmpeg QSV decode fps here?

ffmpeg -vcodec h264_qsv -i test.mkv -an -vcodec h264_qsv -q 20 test.h264
frame= 4795 fps=130 q=-0.0 Lsize= 141545kB time=00:03:19.78 bitrate=5804.0kbits/s

Hmm.....i wonder if one must use "-hwaccel qsv" instead of using h264_qsv decoder?
From ffmpeg documentation;
-hwaccel[:stream_specifier] hwaccel (input,per-stream)
Use hardware acceleration to decode the matching stream(s). The allowed values of hwaccel are:
qsv
Use the Intel QuickSync Video acceleration for video transcoding.
Unlike most other values, this option does not enable accelerated decoding (that is used automatically whenever a qsv decoder is selected), but accelerated transcoding, without copying the frames into the system memory.
For it to work, both the decoder and the encoder must support QSV acceleration and no filters must be used.

-.- too bad when i run "ffmpeg -hwaccels" to list out any hardware acceleration, only "dxva2" is shown.

Maybe I could try that version , although I have to say that I'm very pleased of QSVEncC by Rigaya in terms of both speed and features (+stream compatibility)

It uses ffmpeg for demuxing and muxing only and the transcoding (decoding/encoding) is processed by MediaSDK code of Rigaya and not ffmpeg's.

He has added mpeg2/vc1/hevc HW decoding and mpeg2 HW encoding that ffmpeg qsv doesn't support (I think)

Also, rigaya has implemented his transcoding pipeline without using system memory (memory copy) and that is the reason that is very fast with very low CPU utilisation.

Originally Posted by JohnLai

Update2: On the bright side of the news....
http://lists.ffmpeg.org/pipermail/ff...er/181843.html
Thu Oct 22 17:56:10 CEST 2015

He said 2.5 times faster? Maybe like 179fps X 2.5 = 358fps? (This figure seems to be realistic)
Oh well...let see how ffmpeg developers re-design session control and internal allocation.......(copy pasted)

Hendrik Leppkes is nevcairiel, here in Doom9 the developer of LAV filters.
You could ask him directly here without using ffmpeg forum.

[NikosD]

According to rigaya his app has a lot of differences with ffmpeg version.
I asked him and this is his reply:

ffmpeg and QSVEncC is rather different program, although it uses libavformat for demuxing and muxing.

ffmpeg does not have many encoding options for QSV which is there in QSVEncC.
They only have options below API 1.10, and they don’t have options for bluray, and many other options.

ffmpeg don’t have ability to check QSV features on runtime like QSVEncC has.

Frame rate detection algorithm is completely different, I don’t know which is better.

Also, it does not have vpp feature or full GPU transcoding currently.
But I think ffmpeg will have it soon, because I’ve heard that libav has that feature now.

Currently ffmpeg cannot decode HEVC in QSV.

On the other hand, when using QSV in ffmpeg, you can use many features which ffmpeg has,
such as various audio & video filters which are not there in QSVEncC.

I also said to him to open a thread here in doom9, supporting all his apps for hardware transcoding using AMD/Intel/Nvidia GPUs, in order to help us users and to help him too.

I think it's a good idea.

[JohnLai]

Originally Posted by NikosD

Maybe I could try that version , although I have to say that I'm very pleased of QSVEncC by Rigaya in terms of both speed and features (+stream compatibility)

He has added mpeg2/vc1/hevc HW decoding and mpeg2 HW encoding that ffmpeg qsv doesn't support (I think)

Also, rigaya has implemented his transcoding pipeline without using system memory (memory copy) and that is the reason that is very fast with very low CPU utilisation.

Hendrik Leppkes is nevcairiel, here in Doom9 the developer of LAV filters.
You could ask him directly here without using ffmpeg forum.

Oh? I never know that H.L. is nevcairiel......Maybe I will ask him later.

Latest ffmpeg from github supports qsv hardware decode; (using ffmpeg -decoders>decoder.txt to list out)

V....D h264_qsv H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel Quick Sync Video acceleration) (codec h264)
V....D hevc_qsv HEVC (Intel Quick Sync Video acceleration) (codec hevc)
V....D mpeg2_qsv MPEG-2 video (Intel Quick Sync Video acceleration) (codec mpeg2video)
V..... vc1_qsv VC-1 video (Intel Quick Sync Video acceleration) (codec vc1)


Meanwhile, the ffmpeg hardware based encoders support ; (using ffmpeg -encoders>encoders.txt to list out)

V..... h264_qsv H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (Intel Quick Sync Video acceleration) (codec h264)
V..... hevc_qsv HEVC (Intel Quick Sync Video acceleration) (codec hevc)
V..... mpeg2_qsv MPEG-2 video (Intel Quick Sync Video acceleration) (codec mpeg2video)

V..... nvenc NVIDIA NVENC h264 encoder (codec h264)
V..... nvenc_h264 NVIDIA NVENC h264 encoder (codec h264)
V..... nvenc_hevc NVIDIA NVENC hevc encoder (codec hevc)

Impressively, ffmpeg latest git even has nvenc hevc encode support. I dont understand what is the difference between "nvenc" and "nvenc_h264", should be the same?

Originally Posted by NikosD

According to rigaya his app has a lot of differences with ffmpeg version.
I asked him and this is his reply:


I also said to him to open a thread here in doom9, supporting all his apps for hardware transcoding using AMD/Intel/Nvidia GPUs, in order to help us users and to help him too.

I think it's a good idea.

True, ffmpeg still doesnt support QSV VPP yet......I am hopeful it can be added to official ffmpeg trunk, same with nvidia zero copy and gpu resize.

-.-.....the only thing missing....where is AMD VCE?

*Took me some time to compile full actual working ffmpeg using ffmpeg-windows-build-helpers.
*Will benchmark later. Right now, I just make sure everything works......

[NikosD]

Originally Posted by JohnLai

*Took me some time to compile full actual working ffmpeg using ffmpeg-windows-build-helpers.
*Will benchmark later. Right now, I just make sure everything works......

Thank you for the link of the compiled version of full ffmpeg.exe.

Originally Posted by JohnLai

ffmpeg -an -benchmark -vcodec h264_qsv -i test.mkv -f null -

Update:
-.- Darn it.....seem like ffmpeg QSV above is really slow in decoding. When I use "ffmpeg -an -benchmark -hwaccel dxva2 -i test.mkv -f null -" in order to benchmark the same video using my discrete gpu gtx 970....i got this result :

179fps ffmpeg QSV decoder vs 402fps ffmpeg DXVA2 gtx 970 decoder.
I guess this ffmpeg slow qsv decode is the same issue encountered by rigaya not too long ago. Before any conclusion is done......NikosD~~, can you post your ffmpeg QSV decode fps here?

Using your command line:
ffmpeg -an -benchmark -vcodec h264_qsv -i test.mkv -f null -

...it is clear to me, that the h264_qsv acceleration is using a copy-back mode for decoding and I also get slow results, with very low GPU clock and a CPU usage that demonstrates a copy-back method.

ffmpeg h264_qsv is faster than Eric's Gur Intel QSV decoder (which also uses copy-back mode) but slower than LAV DXVA copy-back.

I think that -hwaccel dxva2 could use a dxva2 native mode, but unfortunately it gives me the following error with my iGPU and falls back to software mode:

[h264 @ 000001ae43867f00] Hardware accelerated decoding with frame threading is not supported.

I'm afraid we are using a wrong thread for all these, because they have nothing or little to do with StaxRip.

Make another thread regarding ffmpeg HW acceleration (decoding/encoding) to go on there...

[JohnLai]

Originally Posted by NikosD

Thank you for the link of the compiled version of full ffmpeg.exe.

Using your command line:
ffmpeg -an -benchmark -vcodec h264_qsv -i test.mkv -f null -

...it is clear to me, that the h264_qsv acceleration is using a copy-back mode for decoding and I also get slow results, with very low GPU clock and a CPU usage that demonstrates a copy-back method.

ffmpeg h264_qsv is faster than Eric's Gur Intel QSV decoder (which also uses copy-back mode) but slower than LAV DXVA copy-back.

I think that -hwaccel dxva2 could use a dxva2 native mode, but unfortunately it gives me the following error with my iGPU and falls back to software mode:

[h264 @ 000001ae43867f00] Hardware accelerated decoding with frame threading is not supported.

I'm afraid we are using a wrong thread for all these, because they have nothing or little to do with StaxRip.

Make another thread regarding ffmpeg HW acceleration (decoding/encoding) to go on there...

Yeah, maybe I should create a new thread, btw, something isn't right with the build I compile.

When either -vcodec h264_qsv or -hwaccel qsv is used, seem like it doesnt make use of the IGPU at all. Darn it.....the compile seems to be successful without any issue....I wonder what went wrong. The h264_qsv also fall back to software.

*Hope stax76 can compile one that actually work without any issue.

[NikosD]

For me h264_qsv works fine, but hevc_qsv doesn't seem to work.