Intel QuickSync Decoder - HW accelerated FFDShow decoder with video processing [Archive] - Page 3

egur

19th May 2013, 22:34

Version 0.42 is out with the following changes:
* Direct3D11 playback (decode + video processing) on Windows 8. Windows 8 allows D3D11 to play video without a display connected to the accelerating GPU.
* Fixed a minor bug in the deinterlacer.
* Fixed an issue with H264 handling of fragmented streams (TV streams with some splitters)
* Updated MSDK headers and dispatch library to Intel Media SDK 2013.
* FFDShow: r4508

Downloads
* For the latest cutting edge FFDShow builds download my builds Intel QuickSync Decoder SourceForge home page (http://sourceforge.net/projects/qsdecoder/)
* FFDShow-tryout site (http://ffdshow-tryout.sourceforge.net/download.php)
* LAV Splitter builds (http://forum.doom9.org/showthread.php?t=156191)

Superb

20th May 2013, 00:24

Great work Eric! :D

betaking

20th May 2013, 14:16

last ffdshow svn can not compile
vista sp2 msvc 2010sp1
生成启动时间为 13/05/20 PM 07:30:11。
1>项目“C:\ffdshow\src\codecs\IntelQuickSyncDecoder\IntelQuickSyncDecoder.vcxproj”在节点 2 上(build 个目标)。
1>InitializeBuildStatus:
正在创建“C:\ffdshow\obj\Release_Win32_VC2010\IntelQuickSyncDecoder\IntelQuickSyncDecoder.unsuccessfulbuild”，因为已指定“AlwaysCreate”。
ClCompile:
C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\CL.exe /c /I\Include /I\Include\um /I\Include\shared /Isrc\MSDK\include /Zi /nologo /W4 /WX /MP /Ox /Oi /Ot /Oy /D WIN32 /D NDEBUG /D _WINDOWS /D _USRDLL /D QUICKSYNC_EXPORTS /D _CRT_SECURE_NO_WARNINGS /D _WINDLL /D _UNICODE /D UNICODE /Gm- /EHsc /MT /GS- /Gy /fprecise /Zc:wchar_t /Zc:forScope /Yc"StdAfx.h" /Fp"C:\ffdshow\obj\Release_Win32_VC2010\IntelQuickSyncDecoder\IntelQuickSyncDecoder.pch" /Fo"C:\ffdshow\obj\Release_Win32_VC2010\IntelQuickSyncDecoder\\" /Fd"C:\ffdshow\obj\Release_Win32_VC2010\IntelQuickSyncDecoder\vc100.pdb" /Gd /TP /wd4996 /wd4995 /analyze- /errorReportrompt src\stdafx.cpp
stdafx.cpp
1>c:\ffdshow\src\codecs\intelquicksyncdecoder\src\stdafx.h(23): fatal error C1083: 无法打开包括文件:“dxgi1_2.h”: No such file or directory
1>已完成生成项目“C:\ffdshow\src\codecs\IntelQuickSyncDecoder\IntelQuickSyncDecoder.vcxproj”(build 个目标)的操作 - 失败。

生成失败。

已用时间 00:00:03.97

egur

20th May 2013, 14:45

hopefully fixed :sly:

betaking

20th May 2013, 15:28

hopefully fixed :sly:

YES it fix! Thanks!:)

itsonlyjustincase

20th May 2013, 23:41

I read the white paper on Optimus (Nvidia's switchable graphics solution). It's not 100% clear whether they disable the iGPU calls when the dGPU is active. The notion of the white paper is that it does. So it may NOT expose the existence of the iGPU to your application.
The proper behavior would be (for your app):
- Adapter #1 (main) NV620m
- Adapter #2 (secondary) HD 4000

If it exposes only the first adapter in D3D11, then there's nothing to do.

I don't have an Optimus system available for testing.

To check this, I'll prepare a version that will open a message box with this information. Wait a day or two, I'm in the middle of something else.

That is exactly what i tested but it doesn't work. For information i use a soft called Mirillis Action! to record my mix. It can use the igpu to record the video window on the secondary display although the soft is using the dGPU (and Cuvid with Lav)

I gonna test the new version to see what happens

itsonlyjustincase

20th May 2013, 23:56

I have just tested. My soft doesn't work if i don't force the nvidia to be used. But then i guess i won't use igpu as the dgpu has been forced. The QS works fine with others

Thanks for your work tough :)

egur

21st May 2013, 06:57

hoborg

21st May 2013, 07:06

BTW, i tryed to run Intel HD 2000 + AMD 7750 (primary) together on my desktop few weeks ago on Win7 x64 and they fight each other. This mean internet browser was crashing (flash module), Direct show was crashing (while adding video renderer to graph), games was crashing while D3D init, etc... All was randomized. It is possible to make it working ?

nevcairiel

21st May 2013, 07:15

I have been running NVIDIA + Intel for a long time, and its working just fine.
AMD is kinda known to be unfriendly to other GPUs in the system, although i thought that was changed in more recent drivers. I've briefly used a 7750 and a Intel HD 3000 in my HTPC together, and didn't notice any issues, but it was only for a few days for some testing.

egur

21st May 2013, 07:22

My main home PC has HD 2000 + Radeon HD 6950. I'm not aware of any issues. When I did have issues, the motherboard was causing them.

hoborg

21st May 2013, 07:23

My main home PC has HD 2000 + Radeon HD 6950. I'm not aware of any issues. When I did have issues, the motherboard was causing them.

Can i ask what motherboard do you have?
I have is Gigabyte GA-B75M-D3H 1.1.

wanezhiling

21st May 2013, 07:31

Its your win7s problem, install a clean win7 again.

hoborg

21st May 2013, 07:36

Its your win7s problem, install a clean win7 again.

Well, i still hoping in GBA motherboard with Haswell GT3e to replace my current setup. :)

egur

21st May 2013, 07:41

You should try updating your BIOS, might solve the problem.
I have an Asus Z77 chipset, don't remember the model. Gigabyte are considered very good too but sometimes these boards (all manufacturers) have BIOS bugs that get resolved in updates.

itsonlyjustincase

21st May 2013, 10:06

I've confirmed that several dGPU drivers in switchable graphics will block the secondary (Intel/iGPU) device.
This means no hybrid/headless support is possible.
Maybe new versions of the Nvidia/AMD drivers will provide this option.
Desktops don't have these issues.

I'm french so perhaps i expressed in a wrong way. What i wanted to say is that using the dGPU doesn't disable the iGPU here. In fact when i plug my HDMI TV, i can use my dGPU to mix my videos and use the iGPU through Mirillis Action to record in mp4 the video window (without a single fps drops). It does work well and we can see both GPU working thanks to GPU-Z.

My trouble is just coming from the software that doesn't support intel GPU......i thought i could kind of fool it thanks to DX11 QS and Lav Video but it doesn't work. So i'll stick to CUVID

itsonlyjustincase

21st May 2013, 10:18

Nev has just confirmed to me that the last lav update doesn't contains the QS 0.42. Perhaps i still have a chance. I'll try it tonight

egur

21st May 2013, 12:11

you can the ffdshow build I've prepared. You can copy the QS DLL from it (backup the old one first). Their interfaces are compatible.

itsonlyjustincase

21st May 2013, 12:56

you can the ffdshow build I've prepared. You can copy the QS DLL from it (backup the old one first). Their interfaces are compatible.

Thanks i'll do that and get back to you

itsonlyjustincase

21st May 2013, 23:10

tried but doesn't work. At the moment the software is forced to use dGPU, when using quickync it says not available (through LAV) and uses avcodec instead (libav in ffdshow)

itsonlyjustincase

21st May 2013, 23:34

i find it weird as it shouldn't tell me the quick sync is not available cause the goal is to have it even if the dGPU is the GPU in use.

This workaround works well with Mirillis Action and permit to record with iGPU even if the dGPU is used :

http://mirillis.com/en/products/tutorials/action-tutorial-intel-quick-sync-setup_for_desktops.html#top

I tried it here but it didn't change anything

egur

22nd May 2013, 07:22

On my system (SandyBridge desktop), if only the dGPU is connected and LAV used the new (0.42) IntelQuicksyncDecoder.dll it will report either Available or Active. LAV video decoder queries my DLL for ability to work.
If you replaced the right DLL and still doesn't get it to work, it means that the Nvidia's Optimus may block the iGPU enumaration, thus disabling QuickSync.

Update
Here's the media SDK system analyzer (http://www.mediafire.com/?yi5mpdd4djeg3u1).
Unzip the file and create an Optimus profile for it, the same profile for your app (dGPU profile).
Execute it (command line) and see if it supports any HW:
Version Target Supported Dec Enc
1.0 HW Yes X X
1.0 SW No
1.1 HW Yes X X
1.1 SW No
1.3 HW Yes X X
1.3 SW No
1.4 HW Yes X X

itsonlyjustincase

22nd May 2013, 10:52

On my system (SandyBridge desktop), if only the dGPU is connected and LAV used the new (0.42) IntelQuicksyncDecoder.dll it will report either Available or Active. LAV video decoder queries my DLL for ability to work.
If you replaced the right DLL and still doesn't get it to work, it means that the Nvidia's Optimus may block the iGPU enumaration, thus disabling QuickSync.

Update
Here's the media SDK system analyzer (http://www.mediafire.com/?yi5mpdd4djeg3u1).
Unzip the file and create an Optimus profile for it, the same profile for your app.
Execute it (command line) and see if it supports any HW:

Thanks again for your help. Will try this out tonight

itsonlyjustincase

22nd May 2013, 11:03

But i have thought again about it and yes in fact i think the way optimus works, when you set a profile for an app to force a GPU, this app won't get access to another GPU. That is why Action! works with iGPU while my app is using dGPU. It is just because it's not the same profile. So unless nvidia would change the way optimus works (i won't even take time to write to them for that cause i think i will never have any answer) i won't be able to use the quick sync while the app has a profile which forces it to use dGPU.

Thank you very much for your work any way

itsonlyjustincase

22nd May 2013, 23:19

Here is the result :

C:\Users\Admin1\Desktop\MediaSDK_sys_analyzer>sys_analyzer.exe
Intel Media SDK System Analyzer (32 bit)

The following versions of Media SDK API are supported by platform/driver:

Version Target Supported Dec Enc
1.0 HW Yes X
1.0 SW No
1.1 HW Yes X
1.1 SW No
1.3 HW Yes X
1.3 SW No
1.4 HW Yes X
1.4 SW No
1.5 HW Yes X
1.5 SW No
1.6 HW Yes X
1.6 SW No

Graphics Devices:
Name Version State
NVIDIA GeForce GT 620M 9.18.13.2000 08

System info:
CPU: Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz
OS: Microsoft Windows 8 Professionnel
Arch: 64 bits

Installed Media SDK packages (be patient...processing takes some time):

Installed Media SDK DirectShow filters:

Installed Intel Media Foundation Transforms:
Intel« Hardware M-JPEG Decoder MFT : {00C69F81-0524-48C0-A353-4DD9D54F9A6E}
Intel« Quick Sync Video H.264 Encoder MFT : {4BE8D3C0-0515-4A37-AD55-E4BAE19AF
471}

Tips:
- SW target does not work: make sure Media SDK DLL (e.g. libmfxsw64.dll)
is located in your executable path or in system path

Analysis complete... [press ENTER]

C:\Users\Admin1\Desktop\MediaSDK_sys_analyzer>

itsonlyjustincase

22nd May 2013, 23:21

I dit the test by forcing the dGPU then forcing the iGPU then forcing autoselect which is by default the iGPU. Result is the same in each case

itsonlyjustincase

22nd May 2013, 23:26

Something weird. Instead of launching through command line I tried doing a right click then use iGPU :

Graphics Devices:
Name Version State
NVIDIA GeForce GT 620M 9.18.13.2000 08
Intel(R) HD Graphics 4000 9.18.10.3071 Active

It is weird i don't get the same result when i force the use of iGPU through the nvidia panel

egur

23rd May 2013, 06:56

itsonlyjustincase

23rd May 2013, 13:53

D3D11 initial performance results:
I've found that the performance under d3d11 is significantly worse, about 2-3.5x slower than d3d9. The lower the bitrate the higher the performance drop due to extra copying done by the driver in D3D11. The D3D11 API has a built in copy-back mechanism which is slower than mine.
I couldn't find a way to get direct access to the VRAM as in D3D9.

I've already fixed some of the problem so expect a new version soon.

Egur could you make me a feedback regarding my results ? I don't really know how to interpret it or not sure i interpreted it well.

Regarding the poorer performance with DX11 it doesn't shock me. When i was trying to fix some old problems of GPU frequency drops i could see tons of post where people were saying that they had better performance with their game in DX9 than DX11 when they had the possibility to go back to DX9 (cause some time they just couldn't). I don't understand why Microsoft do shit like that........

egur

23rd May 2013, 14:02

The results say that your system is fine. SW implementation comes with the media SDK installation which you don't need.
I'm not sure whether the results are accurate, I'll try to write a simple program that does the check myself to be 100% sure. I'll get back to you in a day or 2.

itsonlyjustincase

23rd May 2013, 14:26

egur

25th May 2013, 14:21

Version 0.43 is out with the following changes:
* Direct3D11 playback (decode + video processing) on Windows 8. Due to performance degradation in D3D11, it will be used only when needed.
* Optimized D3D11 decode - 50% faster than before.
* FFDShow: r4512

Downloads
* For the latest cutting edge FFDShow builds download my builds Intel QuickSync Decoder SourceForge home page (http://sourceforge.net/projects/qsdecoder/)
* FFDShow-tryout site (http://ffdshow-tryout.sourceforge.net/download.php)
* LAV Splitter builds (http://forum.doom9.org/showthread.php?t=156191)

betaking

25th May 2013, 15:25

last ffdshow svn can not compile
vista sp2 msvc 2010sp1
生成启动时间为 13/05/25 PM 09:29:17。
1>项目“C:\ffdshow\src\codecs\IntelQuickSyncDecoder\IntelQuickSyncDecoder.vcxproj”在节点 2 上(build 个目标)。
1>InitializeBuildStatus:
正在创建“C:\ffdshow\obj\Release_Win32_VC2010\IntelQuickSyncDecoder\IntelQuickSyncDecoder.unsuccessfulbuild”，因为已指定“AlwaysCreate”。
ClCompile:
C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\CL.exe /c /I\Include /I\Include\um /I\Include\shared /Isrc\MSDK\include /Zi /nologo /W4 /WX /MP /Ox /Oi /Ot /Oy /D WIN32 /D NDEBUG /D _WINDOWS /D _USRDLL /D QUICKSYNC_EXPORTS /D _CRT_SECURE_NO_WARNINGS /D _WINDLL /D _UNICODE /D UNICODE /Gm- /EHsc /MT /GS- /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Yc"StdAfx.h" /Fp"C:\ffdshow\obj\Release_Win32_VC2010\IntelQuickSyncDecoder\IntelQuickSyncDecoder.pch" /Fo"C:\ffdshow\obj\Release_Win32_VC2010\IntelQuickSyncDecoder\\" /Fd"C:\ffdshow\obj\Release_Win32_VC2010\IntelQuickSyncDecoder\vc100.pdb" /Gd /TP /analyze- /errorReport:prompt src\stdafx.cpp
stdafx.cpp

Note: Intel QuickSync Decoder is built without D3D11 support!
Must have Windows SDK 8.0 installed and environment variable INTELMEDIASDK_WINSDK_PATH
should point to it.
e.g. "C:\Program Files (x86)\Windows Kits\8.0"
1>C:\Program Files\Microsoft Visual Studio 10.0\VC\atlmfc\include\atlconv.h(757): error C2220: 警告被视为错误 - 没有生成“object”文件
1>C:\Program Files\Microsoft Visual Studio 10.0\VC\atlmfc\include\atlconv.h(757): warning C4995: “wcscpy”: 名称被标记为 #pragma deprecated
1>C:\Program Files\Microsoft Visual Studio 10.0\VC\atlmfc\include\atlconv.h(768): warning C4995: “wcscat”: 名称被标记为 #pragma deprecated
1>C:\Program Files\Microsoft Visual Studio 10.0\VC\include\cstdio(48): warning C4995: “gets”: 名称被标记为 #pragma deprecated
1>C:\Program Files\Microsoft Visual Studio 10.0\VC\include\cstdio(52): warning C4995: “sprintf”: 名称被标记为 #pragma deprecated
1>C:\Program Files\Microsoft Visual Studio 10.0\VC\include\cstdio(55): warning C4995: “vsprintf”: 名称被标记为 #pragma deprecated
1>C:\Program Files\Microsoft Visual Studio 10.0\VC\include\cstring(21): warning C4995: “strcat”: 名称被标记为 #pragma deprecated
1>C:\Program Files\Microsoft Visual Studio 10.0\VC\include\cstring(22): warning C4995: “strcpy”: 名称被标记为 #pragma deprecated
1>C:\Program Files\Microsoft Visual Studio 10.0\VC\include\cwchar(30): warning C4995: “swprintf”: 名称被标记为 #pragma deprecated
1>C:\Program Files\Microsoft Visual Studio 10.0\VC\include\cwchar(31): warning C4995: “vswprintf”: 名称被标记为 #pragma deprecated
1>C:\Program Files\Microsoft Visual Studio 10.0\VC\include\cwchar(33): warning C4995: “wcscat”: 名称被标记为 #pragma deprecated
1>C:\Program Files\Microsoft Visual Studio 10.0\VC\include\cwchar(35): warning C4995: “wcscpy”: 名称被标记为 #pragma deprecated
1>C:\Program Files\Microsoft Visual Studio 10.0\VC\include\intrin.h(1092): warning C4995: “wcscat”: 名称被标记为 #pragma deprecated
1>C:\Program Files\Microsoft Visual Studio 10.0\VC\include\intrin.h(1094): warning C4995: “wcscpy”: 名称被标记为 #pragma deprecated
1>已完成生成项目“C:\ffdshow\src\codecs\IntelQuickSyncDecoder\IntelQuickSyncDecoder.vcxproj”(build 个目标)的操作 - 失败。

生成失败。

已用时间 00:00:04.86

egur

25th May 2013, 15:58

Very odd. Doesn't happen on my system. I'll fix it anyway in a few minutes

Update
Fixed

betaking

25th May 2013, 16:10

Very odd. Doesn't happen on my system. I'll fix it anyway in a few minutes

Update
Fixed

Thanks! it fix!

ajp_anton

26th May 2013, 17:11

* Direct3D11 playback (decode + video processing) on Windows 8. Due to performance degradation in D3D11, it will be used only when needed.Does this mean only when the GPU is not connected to a display?

egur

26th May 2013, 18:51

Does this mean only when the GPU is not connected to a display?
Correct, when the iGPU is disconnected. If performance would be the same I'd opt for d3d11 as default.

Plutotype

31st May 2013, 20:40

huhn

31st May 2013, 23:30

No issues with RGB Full HDMI output?

tthis can make problems is a know issue for over 1 year know

see here: http://communities.intel.com/thread/29420?start=0&tstart=0

this does not affected all tvs out there of course. i got this problem with my pc monitor too...

No issues with different fps/hz and resolutions?

at the moment sandybridge can't display 24000/1001 and ivy is at ~23.9720 this is not perfect but not that bad a repeat frame all ~4 min

this is an hardware issue. but most likely fixed with haswell.

No issues with HD audio?
never heard of problems with audio and intel

but this has nothing to do with quicksync

egur

1st June 2013, 07:37

Sorry for asking this maybe again, but does Intel iGPU makes no difference in terms of video playback using LAVfilters and madVR in comparison to AMD/NVidia?
No issues with RGB Full HDMI output? No issues with HD audio?
No issues with dropped frames, colors or scaling? No issues with different fps/hz and resolutions?

Planning to buy a Haswell ultrabook with i7-4558U (HD5100 GPU ).
Thanks

The full range RGB issue didn't affect most TVs, I have full range on my TV on using SandyBridge.

Very close to launch there will be several press reviews that will answer all the questions.

I personally recommend waiting for Haswell since Intel supplies driver updates ~2 years after launch so IvyBridge driver will probably stop updating in mid 2014. This policy may change, but that's the current state.
Haswell also provides better performance and power and the iGPU is much stronger too.

NikosD

1st June 2013, 11:29

I want to check your newest DLL with my Win 8 Pro x64 system.

I have a Sandy HD2000 with 9.17.10.3062 drivers and my monitor is connected to dGPU (Radeon 5750 - Catalyst 13.4).

I don't want to install FFDShow and nevcairiel is not helping us by not installing Win 8 on his system. :scared:

If you upload somewhere the DLL, is it possible to test it with LAV video 0.57 by just replacing quicksync DLL ?

I tried latest PotPlayer v1.5.38118 and it doesn't seem capable of using QS decoding (it uses DXVA of AMD card even if I select QS).

Of course if I make a fake display following one of the best guides with pictures here : http://imouto.my/headless-quicksync/ I can use PotPlayer with QS acceleration without connecting a monitor on iGPU.

But the same functionality already exists with Win 7.

Win 8 can use QS acceleration, without even creating a fake display, right ?

My BIOS settings are:
Primary display: Auto
iGPU multi-monitor: Enable

P.S

My MSDK analysis

Intel Media SDK System Analyzer (32 bit)

The following versions of Media SDK API are supported by platform/driver:

Version Target Supported Dec Enc
1.0 HW Yes X X [Adapter 1]
1.0 SW No
1.1 HW Yes X X [Adapter 1]
1.1 SW No
1.3 HW Yes X X [Adapter 1]
1.3 SW No
1.4 HW Yes X X [Adapter 1]
1.4 SW No
1.5 HW No
1.5 SW No
1.6 HW No
1.6 SW No

Graphics Devices:
Name Version State
Intel(R) HD Graphics 9.17.10.3062 Active
AMD Radeon HD 6700 Series 12.104.0.0 Active

System info:
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
OS: Microsoft Windows 8 Pro
Arch: 64-bit

Installed Media SDK packages (be patient...processing takes some time):

Installed Media SDK DirectShow filters:

Installed Intel Media Foundation Transforms:
Intelχ Quick Sync Video H.264 Encoder MFT : {4BE8D3C0-0515-4A37-AD55-E4BAE19AF
471}

Tips:
- SW target does not work: make sure Media SDK DLL (e.g. libmfxsw64.dll)
is located in your executable path or in system path

Analysis complete... [press ENTER]

andyvt

1st June 2013, 15:25

The full range RGB issue didn't affect most TVs, I have full range on my TV on using SandyBridge.

Did you do anything special to make that work? I am not able to make any Intel GPU use RGB-Full over HDMI either of my Panasonic TVs.

huhn

1st June 2013, 16:03

there is no way to force it but intel can detect it right.

you can try to change the desktop color to 16 bit some people say this force full rgb didn't work for me. it still uses 24 bit after that change.

GTPVHD

1st June 2013, 16:39

http://www.anandtech.com/show/7003/the-haswell-review-intel-core-i74770k-i54560k-tested

http://www.anandtech.com/show/6993/intel-iris-pro-5200-graphics-review-core-i74950hq-tested

Haswell reviews are up, Iris Pro 5200 is really impressive, it trounces the 100W desktop Trinity real good.

egur

1st June 2013, 16:44

I have a Sandy HD2000 with 9.17.10.3062 drivers and my monitor is connected to dGPU (Radeon 5750 - Catalyst 13.4).
That should work, very similar to my setup.

I don't want to install FFDShow ...
That's the easiest option, you can later uninstall it. Once installed, copy the QS DLL.

If you upload somewhere the DLL, is it possible to test it with LAV video 0.57 by just replacing quicksync DLL ?
Yes, works for me.

Win 8 can use QS acceleration, without even creating a fake display, right ?
Correct, via D3D11 instead of D3D9. This feature doesn't work on Windows 7.

My MSDK analysis

Intel Media SDK System Analyzer (32 bit)
...
Your setup looks great :)
SW decoding is missing but you don't need that anyway.

egur

1st June 2013, 16:51

Did you do anything special to make that work? I am not able to make any Intel GPU use RGB-Full over HDMI either of my Panasonic TVs.

Not really. My Panasonic TV was set to full range.
What wrong is that the iGPU reports partial range but using test patterns it shows that it was sending full range.
The TV reported full range and the blacks (which are great in Panasonic plasma TVs) were excellent.
Setting the iGPU to full range did the opposite, it set the actual range to limited (16-235). So the bug is there last time I checked (6 months ago), but the end result is that the output is fine.
So for my TV its all about wrong labels.
I've reported this issue to the graphics team but that's about all I can do.

andyvt

1st June 2013, 17:08

Not really. My Panasonic TV was set to full range.
What wrong is that the iGPU reports partial range but using test patterns it shows that it was sending full range.
The TV reported full range and the blacks (which are great in Panasonic plasma TVs) were excellent.
Setting the iGPU to full range did the opposite, it set the actual range to limited (16-235). So the bug is there last time I checked (6 months ago), but the end result is that the output is fine.
So for my TV its all about wrong labels.
I've reported this issue to the graphics team but that's about all I can do.

So if I understand correctly. You leave the limited/full toggle in the iGPU settings tool alone and configure the TV to use Nonstandard" (RGB-Full) for the HDMI port you have it connected to?

egur

1st June 2013, 17:33

Correct. Should be better quality anyway since the desktop displays at full range. The display pipeline within the GPU can change it limited range later on but data will be lost.
So to minimize range conversions, I output at full range.

The optimal would be to output YCbCr at standard levels (16-235 for Y) but Windows doesn't support that as far as I know.
Maybe one day Windows will support 30bpp output but till then, my setup is probably optimal.

nevcairiel

1st June 2013, 18:04

You only run into problems if your TV doesn't tell your GPU that it accepts full-range (even if you tell your TV to expect full range), and the Intel option doesn't let you override (which probably was never fixed)

NVIDIA kinda has the same issue, as they don't even have a visible option to override the HDMI range detection, but at least they have sneaky ways to override it.

hajj_3

2nd June 2013, 07:19

Quick Sync Performance

With more graphics EUs under the hood of all desktop Haswells (at least those launching today), Quick Sync performance improves a bit over Ivy Bridge. Intel claims to have focused heavily on improving the quality of Quick Sync transcodes however in my testing I saw a slight regression in quality. I didn’t have a ton of time to dig further to find out what’s going on but I plan on doing so post-Computex.

The other big news is Handbrake now officially supports Quick Sync, something Ganesh will be testing with his HTPC look at Haswell.

Needless to say, Quick Sync performance is better on Haswell than on Ivy Bridge. And it’s even better if you happen to have a Haswell with a 128MB L4 cache.

http://images.anandtech.com/graphs/graph6993/55316.png

Source: http://www.anandtech.com/show/7003/the-haswell-review-intel-core-i74770k-i54560k-tested/8

Egur: are you able to paste us the settings that the new higher quality profile that quicksync uses in haswell as the anandtech article doesn't say what they are?

egur

2nd June 2013, 12:12

Egur: are you able to paste us the settings that the new higher quality profile that quicksync uses in haswell as the anandtech article doesn't say what they are?

No, I don't have them.

NikosD

2nd June 2013, 13:23

That's the easiest option, you can later uninstall it. Once installed, copy the QS DLL.

The easiest option would be if I can get it as a single file, without all the trouble of installing/ uninstalling.
PM works I think in doom9, if you can't post it in public :)

Your setup looks great :)
SW decoding is missing but you don't need that anyway.

The problem is that the above MSDK configuration is visible only if I make a fake display.
But that is the Windows 7 way.
In Windows 8 we shouldn't make any fake displays.

So if I connect my monitor to dGPU in Win 8 without making a fake display I get this - state is 08, not active:

Intel Media SDK System Analyzer (32 bit)

The following versions of Media SDK API are supported by platform/driver:

Version Target Supported Dec Enc
1.0 HW No
1.0 SW No
1.1 HW No
1.1 SW No
1.3 HW No
1.3 SW No
1.4 HW No
1.4 SW No
1.5 HW No
1.5 SW No
1.6 HW No
1.6 SW No

Graphics Devices:
Name Version State
Intel(R) HD Graphics 9.17.10.3062 08
AMD Radeon HD 6700 Series 12.104.0.0 Active

System info:
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
OS: Microsoft Windows 8 Pro
Arch: 64-bit

Installed Media SDK packages (be patient...processing takes some time):

Installed Media SDK DirectShow filters:

Installed Intel Media Foundation Transforms:
Intelχ Quick Sync Video H.264 Encoder MFT : {4BE8D3C0-0515-4A37-AD55-E4BAE19AF
471}

Tips:
- SW target does not work: make sure Media SDK DLL (e.g. libmfxsw64.dll)
is located in your executable path or in system path

Analysis complete... [press ENTER]

NikosD

2nd June 2013, 16:52

http://www.anandtech.com/show/7003/the-haswell-review-intel-core-i74770k-i54560k-tested

Haswell CPU is all but desktop. Desktop view of Haswell CPU is at least boring.

About 8% faster than Ivy on average (AVX and AVX2 are faster and a lot faster)
The rival that Haswell is going to compete is not an AMD processor or a previous generation Intel.

The enemy is ARM

The new PCs are not desktop PCs. They are smartphones and tablets.

http://www.anandtech.com/show/6993/intel-iris-pro-5200-graphics-review-core-i74950hq-tested

Haswell reviews are up, Iris Pro 5200 is really impressive, it trounces the 100W desktop Trinity real good.

Haswell GPU is far more interesting than Haswell CPU.

Iris Pro 5200 (55W) didn't catch the target that Intel put, Nvidia 650M.
Actually it didn't catch even 640.

It's slower in almost every game, but it's very close or even faster in synthetic benchmarks.

Is it hardware limitation or driver's optimizations ?
Will see...

I was amazed by OpenCL numbers though.
In LuxMark 2.0, GT3e is even faster than my 5750 :eek:

VT-d and the other extensions are absent not only in K models, but in R (GT3e) models, too.
SAD

I think I'm gonna stick to my signature system again - with my new VP5.

If 4770R is reachable to a non-OEM product - maybe a M/B with a soldered CPU - I could think of an upgrade.

egur

2nd June 2013, 17:59

NikosD,
I just re-ran the analyzer and it didn't find HW acceleration (iGPU is headless in Win8). But QS works. In my setup the status of "08" was also there.

Your setup is fine.

Here's the QS DLL (32 bit) (http://www.multiupload.nl/NWVLRXI93D).

Here's a test DLL with debug colors (http://www.multiupload.nl/V911D3P4QY). Look at the top left corner, if QS is working you'll see a color rectangle:
* Blue - D3D9 HW
* Magenta (pink) - D3D11 HW
* Red - SW.
* No color - another decoder is active :)

NikosD

2nd June 2013, 19:20

Well done, Eric!
It works like a charm...

It works with a simple copy-paste in LAV folder, but PotPlayer has a different dll and it's not compatible with your structure.

So PotPlayer doesn't work, they have to do it by their own, as always.

Some benchmark results with DXVA Checker: (GPU clock is default max 1100MHz)

D3D11
Every 1080p H.264 clip I tried is always above 110 - 130 fps with an average CPU of 7% with the lowest CPU clock of 1600MHz. Unbelievable!

Even 1080p60 clips go below 2000MHz CPU and towards the end of the clips go down to 1600MHz CPU clock with an average CPU of 8%!

It was like testing DXVA native, but with a lot lower performance.

Samsung demo is the only one that goes below 100fps - even if it's not the most difficult of my test suite.

D3D9
It's a lot, lot faster than D3D11 from 100% to more than 250%, but CPU goes up to 3100MHz and more and the average utilization goes up to 40%!

Conclusion:
For laptops and power consumption aware desktop users, I would definitely suggest D3D11 use instead of D3D9 use of QuickSync decoder.

It can play every 1080p clip with ease and with minimum power consumption out of the box, with no "fake display" or other tricks.

andyvt

2nd June 2013, 19:47

Egur: are you able to paste us the settings that the new higher quality profile that quicksync uses in haswell as the anandtech article doesn't say what they are?

Do you mean the expanded target usage values?

GTPVHD

3rd June 2013, 08:32

http://www.anandtech.com/show/7007/intels-haswell-an-htpc-perspective

Unfortunately there's trouble in Haswell Quicksync's encoding quality.

In our opinion, the QuickSync results on HD4600 appear to be worse than what is obtained on the HD4000. With Haswell, Intel introduced seven levels of quality/performance settings that application developers can choose from. According to Intel, even the lowest quality Haswell QSV settings should be better than what we had with Ivy Bridge. In practice, this simply isn't the case. There's a widespread regression in image quality ranging from appreciably worse to equal at best with Haswell compared to Ivy Bridge. I'm not sure what's going on here but QuickSync remains one of the biggest missed opportunities for Intel over the past few years. The fact that it has taken this long to get Handbrake support going is a shame. Now that we have it, the fact that Intel seems to have broken image quality is the icing on a really terrible cake.

nevcairiel

3rd June 2013, 08:50

Its very well possible that Handbrakes settings are not optimized for the new presets in Haswell yet, i wouldn't jump to conclusions too early.

wanezhiling

3rd June 2013, 09:14

The few who care about advanced madVR scaling algorithms (such as Jinc and the anti-ringing filters for Lanczos) may need to fork out for a discrete GPU
http://i.imgur.com/egBCTtS.gif

But this refers to 4600, we know 5200 is double stronger than 4600.:)

ryrynz

3rd June 2013, 09:28

Yup, the 4600 will be adequate for lanczos as even the HD 3000 has no issues there, Jinc will probably be still a bit too demanding for some content though. But yeah the Iris Pro (HD 5200) is what I'm interested in too.

wanezhiling

3rd June 2013, 09:57

the Iris Pro (HD 5200) is what I'm interested in too.
http://en.wikipedia.org/wiki/Haswell_(microarchitecture)#Mobile_processors
4750HQ 4850HQ 4950HQ :)

nevcairiel

3rd June 2013, 10:06

http://en.wikipedia.org/wiki/Haswell_(microarchitecture)#Mobile_processors
4750HQ 4850HQ 4950HQ :)

Can't really put a mobile CPU into your HTPC. :p
The 4770R would be interesting, if they sell it soldered on a ITX board without a whole PC around it.

egur

3rd June 2013, 11:31

Conclusion:
For laptops and power consumption aware desktop users, I would definitely suggest D3D11 use instead of D3D9 use of QuickSync decoder.

If you've reached your conclusion based upon DXVA checker benchmarks, then let me correct you if I may.
You should check power and CPU utilization/speed at normal playback speeds. DXVA checker tries running at full speed which doesn't matter for playback.
Even for transcoding, your conclusion is a little hasty. You need to sum up the power used for the entire clip in both cases and see which one is better. Looking the power draw alone is not enough as D3D9 will finish much sooner.

CiNcH

3rd June 2013, 15:32

I read that with Haswell, the Display Controller also moved to the CPU. This could mean that we now have a common clock for audio (HDMI) and video!? It is quite an improvement that the video clock can now achieve an accurate 23.976Hz. This does not help a bit though if the audio resp. the DirectShow graph clock is off. Because the real problem has never been the inaccurate video clock but the deviation between audio/graph and video clock...

egur

3rd June 2013, 15:42

The digital display interfaces moved to the system agent (north bridge) within the processor instead of being transferred to via the DMI bus to the PCH. This is more efficient but as for the audio clock, I don't know.

jkauff

3rd June 2013, 15:57

Its very well possible that Handbrakes settings are not optimized for the new presets in Haswell yet, i wouldn't jump to conclusions too early.

QS quality in Handbrake beta is not as good on an HD4000 as other implementations (Nero Recode, Arcsoft Media Converter, Media Coder). These implementations vary in quality, too, so I think there's probably a lot of tweaking that needs to happen to get the best results out of QS. Intel is reportedly working closely with the Handbrake team, so I'd expect improvements in future betas.

Yups

4th June 2013, 16:44

Iris Pro 5200 (55W) didn't catch the target that Intel put, Nvidia 650M.
Actually it didn't catch even 640.

According to anandtech they matched this target. Anand tested a 900/2500 GDDR5 650M. So they should match a 800 Mhz 650M with DDR3 memory. GT640 on the desktop side is difficult to say because its competitor will be a 65W BGA GT3e.

Yups

4th June 2013, 16:47

QS quality in Handbrake beta is not as good on an HD4000 as other implementations (Nero Recode, Arcsoft Media Converter, Media Coder). These implementations vary in quality, too, so I think there's probably a lot of tweaking that needs to happen to get the best results out of QS. Intel is reportedly working closely with the Handbrake team, so I'd expect improvements in future betas.

This is absolutely wrong. Handbrake QS quality is top notch for Ivy Bridge. I did lots of tests. As for Haswell there might be some issues with the new presets.

jkauff

5th June 2013, 01:55

This is absolutely wrong. Handbrake QS quality is top notch for Ivy Bridge. I did lots of tests. As for Haswell there might be some issues with the new presets.
I guess I'll have to do additional testing with different source files. The three files I transcoded in the various apps had many more visible artifacts with Handbrake QS.

wanezhiling

5th June 2013, 11:05

Haswell family (http://ark.intel.com/products/codename/42174/Haswell)

Why separately name Iris Pro 5200 family Crystal Well (http://ark.intel.com/products/codename/51802/Crystal-Well) o.O

NikosD

5th June 2013, 12:13

If you've reached your conclusion based upon DXVA checker benchmarks, then let me correct you if I may.
You should check power and CPU utilization/speed at normal playback speeds. DXVA checker tries running at full speed which doesn't matter for playback.
Even for transcoding, your conclusion is a little hasty. You need to sum up the power used for the entire clip in both cases and see which one is better. Looking the power draw alone is not enough as D3D9 will finish much sooner.

Sorry for the late response. I was really busy the last few days...

For me benchmarking with DXVA Checker exposes the potential of the hardware and has only one real use, transcoding, because it uses hardware at its limits - like benchmarking.

The other real use is normal playback of course - more important to me.

Well, during normal playback DXVA native and DXVA copy-back are by far the most power-efficient solutions.

QS decoder power efficiency during playback is almost the same for various clips I tried under both situations - D3D11 and D3D9.

So, it seems that the real advantage of D3D11 is the headless, no fake display use of QS decoder.

According to anandtech they matched this target. Anand tested a 900/2500 GDDR5 650M. So they should match a 800 Mhz 650M with DDR3 memory. GT640 on the desktop side is difficult to say because its competitor will be a 65W BGA GT3e.

It is true that Anand tested the best variant of 650M, but the difference in games is big enough to not be covered by GT3e using a little lower clocked 650M with DDR3 memory - we have to see real numbers of course.

Iris Pro 5200 tested by Anand is inside a mobile CPU with lower TDP than desktop, but I think that the special version used in benchmarks of 55W is the top-performer GT3e that anyone could use regardless of Desktop-Mobile CPU package.

Eric could tell us more about that...

itsonlyjustincase

5th June 2013, 14:32

I have a question to all ? Do people with a laptop with win8 and sandy or ivy bridge coupled with discrete GPU has tested it ?

Cause the last version of the intel drivers was supposed to permit to use intel quick sync technology even if the iGPU isn't used. But in my case when the dGPU is used the possibility to use quicksync through lav filters disappears

egur

5th June 2013, 15:39

Haswell family (http://ark.intel.com/products/codename/42174/Haswell)

Why separately name Iris Pro 5200 family Crystal Well (http://ark.intel.com/products/codename/51802/Crystal-Well) o.O
CrystalWell is the code name for the EDRAM chip itself.
The combined name for GT3+EDRAM is Iris Pro.

I have a question to all ? Do people with a laptop with win8 and sandy or ivy bridge coupled with discrete GPU has tested it ?

Cause the last version of the intel drivers was supposed to permit to use intel quick sync technology even if the iGPU isn't used. But in my case when the dGPU is used the possibility to use quicksync through lav filters disappears
I didn't get any feedback except yours. No problems with Win8 on desktop.

wanezhiling

5th June 2013, 16:08

Thanks Eric.

http://ark.intel.com/compare/76087,76086,76085
I noticed that Max Memory Bandwidth of these three models is 76.8GB/s, and all other Haswell models(even 4770R) are 25.6GB/s. Is it true?

Yups

5th June 2013, 16:22

I guess I'll have to do additional testing with different source files. The three files I transcoded in the various apps had many more visible artifacts with Handbrake QS.

Arcsoft is crap to be honest. High profile isn't possible and I can't even choose the preset. It must be the balanced or speed preset. Quality preset not possible.

It is true that Anand tested the best variant of 650M, but the difference in games is big enough to not be covered by GT3e using a little lower clocked 650M with DDR3 memory - we have to see real numbers of course.

Iris Pro 5200 tested by Anand is inside a mobile CPU with lower TDP than desktop, but I think that the special version used in benchmarks of 55W is the top-performer GT3e that anyone could use regardless of Desktop-Mobile CPU package.

Eric could tell us more about that...

GDDR5 makes quite a big difference. See how the GT640 performs.

GT650M 900/2500 GDDR5
GT 640 925/1700 DDR3

Despite having the slightly faster GPU GT640 loses by a good margin. Except BF3 Iris Pro isn't much slower than a GT640 925/1700. On this basis I would say Iris Pro should match a 800 Mhz 650M with DDR3. As for the 65W model Iris Pro is clearly TDP limited in a 47W power envelope, 55W Iris Pro runs 10% or so faster. 65W Iris Pro for desktop could be even faster slightly.

itsonlyjustincase

5th June 2013, 16:43

CrystalWell is the code name for the EDRAM chip itself.
The combined name for GT3+EDRAM is Iris Pro.

I didn't get any feedback except yours. No problems with Win8 on desktop.

That's what i was doubting. Okay so i think that as you may have previously pointed out, Optimus disables entirely iGPU when dGPU is forced. So as for sure Nvidia won't do anything about it, i won't be able to use it in that way

nevcairiel

5th June 2013, 16:51

http://ark.intel.com/compare/76087,76086,76085
I noticed that Max Memory Bandwidth of these three models is 76.8GB/s, and all other Haswell models(even 4770R) are 25.6GB/s. Is it true?

The EDRAM is a L4 Cache, which means it can boost memory bandwidth.

wanezhiling

6th June 2013, 01:11

But 4770R is still 25.6GB/s

egur

6th June 2013, 07:35

The math is:
1.6GHz*8*2 = 25.6GB/s
- 8 bytes per channel bus width (64 bit)
- 2 memory channels.

Anyway, I agree that the various Iris Pro SKUs should have the same memory bandwidth. Will be fixed.

wanezhiling

6th June 2013, 13:49

9.18.10.3186 ;)

32bit (http://file2.mydrivers.com/display/intel_hd_graphics_9.18.10.3186_Win32.zip)

64bit (http://file2.mydrivers.com/display/intel_hd_graphics_9.18.10.3186_Win64.zip)

Tacio

8th June 2013, 17:38

Any news about NVIDIA Optimus support? Because on my system (Asus U36 with GT520M) QuickSync doesn't work with latest ffdshow. Just shows that libavcodec in use.

egur

8th June 2013, 19:20

I didn't get a clear answer on the Nvidia forum. Sadly no progress on this front.
I'll try to ask within Intel.

itsonlyjustincase

9th June 2013, 12:18

I also tried to ask the question on the nvidia forum but no answer

https://forums.geforce.com/default/topic/546217/geforce-mobile-gpus/intel-quicksync-when-dgpu-is-forced/

I also tried to mail through the driver support but i think i'll never get an answer

egur

9th June 2013, 12:22

FYI, here's my post (https://forums.geforce.com/default/topic/544766/geforce-drivers/optimus-behavior-with-secondary-gpu-win8-dx11-1-/) in the Nvidia forums. If enough people interact, Nvidia will answer :)

NikosD

9th June 2013, 15:38

Very nice integration of Media Performance in System Analyzer of latest GPA 2013 R2.

Performance metrics of CPU & GPU & QuickSync & Power all-in-one and each one separately.

Just one thing.
It would be nice if there was an option "Always on top", for better monitoring of system resources.

Superb

11th June 2013, 12:57

Just wanted to post that I've installed Windows 7 on a friend's laptop yesterday with the Intel driver from Windows Update... and QuickSync worked. (tested w/ LAV Filters; ran an actual video and checked the status)

egur

11th June 2013, 13:15

I got a report that this issue was fixed with Microsoft.
Personally, I still strongly advise against it.

egur

11th June 2013, 19:38

An issue was found with D3D11 playback using 15.31 drivers (IVB/HSW). The issue is a green playback screen.
A fix will be released shortly.

madchicken265

13th June 2013, 00:25

Hey Egur, any love for Sandybridge (new drivers)?

egur

13th June 2013, 07:25

Hey Egur, any love for Sandybridge (new drivers)?

Maybe (don't know). New drivers for SNB will have bug fixes not new features. Driver support has been always for current + (1) previous generation.

theoneofgod

13th June 2013, 18:44

I find when I use FFDShow for Audio and Video, audio seems slightly out of sync. Without the video decoder it seems fine, not sure which is the culprit. I use optical to my receiver. I've tried both an Asus Xonar DG and my Realtek ALC898 soundcards, both have the same results.

NikosD

14th June 2013, 11:20

Maybe (don't know). New drivers for SNB will have bug fixes not new features. Driver support has been always for current + (1) previous generation.

AMD (ATI) and Nvidia support many previous generations from current (at least 3)

theoneofgod

15th June 2013, 06:44

Does this work fine with a Crossfire setup? Other things are detecting QSV but this won't.

egur

15th June 2013, 07:27

Does this work fine with a Crossfire setup? Other things are detecting QSV but this won't.

Works with up to 3 discrete GPUs in theory. As far as I know, systems with more than 2 dGPUs don't have QuickSync (they have extreme edition processor models w/o QuickSync).
Note that using QuickSync when the display is not connected to the processor graphics (iGPU) is only supported in Windows 8. In Windows 7 you need to extend the desktop to the disconnected iGPU.

nevcairiel

15th June 2013, 08:25

With the correct motherboard with a PCIe switch, you can have 4 dGPUs with a "normal" CPU

egur

15th June 2013, 09:06

May be possible but not likely. In any case no support for systems where the iGPU is adapter number 4 (zero based) as enumerated by d3d.

nevcairiel

15th June 2013, 09:25

theoneofgod

15th June 2013, 09:43

Works with up to 3 discrete GPUs in theory. As far as I know, systems with more than 2 dGPUs don't have QuickSync (they have extreme edition processor models w/o QuickSync).
Note that using QuickSync when the display is not connected to the processor graphics (iGPU) is only supported in Windows 8. In Windows 7 you need to extend the desktop to the disconnected iGPU.

I run a 3770K and crossfire with Windows 8. FFDShow won't detect QSV but Arcsoft Media Converter does.

egur

18th June 2013, 00:00

Isnt the adapter number based on the number of connected screens as well? I can have one dGPU with 4 connected screens, and the iGPU would only come after that. Extreme setup i suppose, but possible :)
That's how it works with D3D9. With D3D10/11 every adapter is enumerated, even if disconnected. I'm not sure how multiple screens connected to multiple adapters are enumerated.

I run a 3770K and crossfire with Windows 8. FFDShow won't detect QSV but Arcsoft Media Converter does.
That's very strange, are you sure Media Converter actually manages to work with QS?
Maybe more than 4 devices get enumerated... Shouldn't happen.

theoneofgod

18th June 2013, 00:45

That's how it works with D3D9. With D3D10/11 every adapter is enumerated, even if disconnected. I'm not sure how multiple screens connected to multiple adapters are enumerated.

That's very strange, are you sure Media Converter actually manages to work with QS?
Maybe more than 4 devices get enumerated... Shouldn't happen.

Im pretty sure. Low CPU converting.

Please check the attached images.

itsonlyjustincase

18th June 2013, 11:39

I'm really impressed to see how QuickSync is powerful.

Egur did you have answer from nvidia ?

egur

18th June 2013, 17:40

theoneofgod

19th June 2013, 03:18

@theoneofgod
I'm currently on a business trip and can't test my desktop setup.
Please try to specify your setup in detail so I can reproduce as closely as possible (upon my return).
-- Intel GPU Driver version
-- How the display(s) are connected (which GPU).
-- Any other special drivers installed (e.g. Virtu)?
-- Player used (name + 32/64 bit).
-- Version of ffdshow
-- Does ffdshow use libavcodec or does it use QS but displays a bad image?

1) 9.17.10.2932 - 12/12/2012
2) 1 display, connected to DVI from the dGPU.
3) Yes, using Virtu MVP (otherwise nothing works, including Media Conveter) Virtu MVP Desktop Edition: 2.1.221.24927
4) GOM Player x86 2.1.50
5) ffdshow tryouts rev4512 may 25 2013 (the lastest you released) ffdshow_rev4512_20130525_egur
6) ffdshow shows libavcodec, no Intel QSV is displayed.

Thank you.

egur

19th June 2013, 05:07

1) 9.17.10.2932 - 12/12/2012
2) 1 display, connected to DVI from the dGPU.
3) Yes, using Virtu MVP (otherwise nothing works, including Media Conveter) Virtu MVP Desktop Edition: 2.1.221.24927
4) GOM Player x86 2.1.50
5) ffdshow tryouts rev4512 may 25 2013 (the lastest you released) ffdshow_rev4512_20130525_egur
6) ffdshow shows libavcodec, no Intel QSV is displayed.

Thank you.
Since you use Virtu MVP, you should set up your player to use the iGPU. Virtu may block using the iGPU when set to use the dGPU.
I currently don't have Virtu MVP, but I'll try to get a copy when I return home.
In any case, I don't believe that crossfire has anything to do with this.

theoneofgod

19th June 2013, 06:53

Since you use Virtu MVP, you should set up your player to use the iGPU. Virtu may block using the iGPU when set to use the dGPU.
I currently don't have Virtu MVP, but I'll try to get a copy when I return home.
In any case, I don't believe that crossfire has anything to do with this.

I forgot to mention that I tried that already, still the same results, QSV not shown in ffdshow codec setup.
Even when opening the ffdshow config menu directly, still doesn't show it.

NikosD

19th June 2013, 10:04

A performance preview of Snapdragon 800 at Anandtech:

Along with the x2 performance of Adreno 330 vs Adreno 320 we have the first mobile SoC capable of 4K H.264 Hardware Encoding / Decoding (playback).

It is capable of Hardware encoding/decoding of H.264 3840x2160@25fps with 120Mbps bitrate available to smartphones and tablets

4K samples here 3840x2160@25fps-120Mbpshttp://images.anandtech.com/reviews/gadgets/qualcomm/MDP8974/VID_20130618_161251.renametomp4.zip (]http://anandtech.com/show/7082/snapdragon-800-msm8974-performance-preview-qualcomm-mobile-development-tablet[/URL)

and YouTube here 3840x2160@25fps-56Mbps[URL=]http://youtu.be/H2eoSEPIQPQ

I'm sure that Ivy and Haswell can play both of them easily, but I have to say that my tiny VP5 can play both of them too - with an almost zero CPU utilization of my poor Core2Duo ;)

theoneofgod

19th June 2013, 11:07

screamz

20th June 2013, 12:53

4K samples here 3840x2160@25fps-120Mbpshttp://images.anandtech.com/reviews/gadgets/qualcomm/MDP8974/VID_20130618_161251.renametomp4.zip

I downloaded the file but can't extract it. Do you have similar problems?

NikosD

20th June 2013, 13:45

Playing that sample in VLC uses a whole 25% CPU. Crazy.

The crazy thing is that you can play it with ONLY 25% CPU.

This is impossible, unless you have a secret Chinese CPU :eek:

In order to view it in realtime@25fps you must use a decent video player like PotPlayer and in software mode you will need ~55% of a Core i5(quad core)@3.1GHz CPU (Sandy) or in hardware mode (DXVA/QS) you need Ivy or Haswell or an Nvidia VP5 card.

I downloaded the file but can't extract it. Do you have similar problems?

You can't extract it.
The name of the file says "rename me to mp4"
So, change the extension of the file from .zip to .mp4

vivan

20th June 2013, 14:42

The crazy thing is that you can play it with ONLY 25% CPU.

This is impossible, unless you have a secret Chinese CPU :eek:On my i7 970 I get ~20% CPU load.
Also note that my CPU (and his too, probably) does have HT and every second core have zero load (at least when I'm using LAV Decoder). Let's assume that HT efficiency is about 15%, then this 20% become 20*2/1,15 = 35% of "real" CPU load.

NikosD

20th June 2013, 15:02

On my i7 970 I get ~20% CPU load.

This is a false statement of the CPU monitor software, which counts the logical cores as physical cores.

Also note that my CPU (and his too, probably) does have HT and every second core have zero load (at least when I'm using LAV Decoder). Let's assume that HT efficiency is about 15%, then this 20% become 20*2/1,15 = 35% of "real" CPU load.

A more accurate way to measure the real load is to disable the HT - if it's possible - and run a CPU video benchmark with DXVA Checker or GraphEdit and then repeat the same benchmark with HT on.
The difference will show you the real benefit of HT for video decoding - I think 15% is too much for HT regarding video decoding and Core i7 970.

Then disable HT again and measure CPU utilization during normal playback.

You can subtract the real benefit of HT from the above utilization with HT off to find a more accurate CPU utilization of your hyperthreaded CPU.

nevcairiel

20th June 2013, 15:09

I did such tests before on my SNB 2600k. Enabling HT gives a 30% performance advantage when benchmarking decoding.

screamz

20th June 2013, 15:15

You can't extract it.
The name of the file says "rename me to mp4"
So, change the extension of the file from .zip to .mp4

Omg thank you! I didn't read that ;-)

NikosD

20th June 2013, 15:22

Intel didn't manage to have the best HT from the beginning - Pentium 4 had HT too :scared:

SNB's HT is surely better than HT of Core i7 970.

I didn't ever have a hyperthreaded CPU and I haven't done the tests I describe above myself - still 30% seems too much although video decoding could be a fully parallel procedure.

I won't insist on numbers since I don't have them, nevertheless, I think I made my point of what real CPU utilization means, clear.

egur

20th June 2013, 17:07

Hyper Threading like any other performance feature doesn't improve performance across the board. It improves performance for most flows and may lower performance for few.
It's worse than doubling the core count but it uses significantly less die area than double core count.
For flows that have lots of I/O, CPU execution resources are utilized better with HT. A good example is compilation (e.g. build a C++ project using Visual Studio).
Also if one thread is hammering the SSE units and another is scalar integer based, they'll use different execution resources and the overall performance would increase.
Compared to the die increase of HT, a 30% performance boost is very good (can be more sometimes).

theoneofgod

20th June 2013, 17:42

I have a 3770k at 4.2ghz and I assure you, with VLC 25% CPU was used.

Pat357

22nd June 2013, 13:45

nevcairiel

22nd June 2013, 13:54

Here is the link:
http://forum.doom9.org/showpost.php?p=1532786&postcount=186

sheppaul

22nd June 2013, 14:30

I have a 3770k at 4.2ghz and I assure you, with VLC 25% CPU was used.

I've tried it with 3570K not overclocked and the CPU usage of VLC was roughly 43% in task manager of windows 8.

cf. 41% in potplayer (with type 1 decoder)

theoneofgod

22nd June 2013, 16:20

I'm looking for a way to access my HD4600 (quickync) with my monitor connected to my NVidia GTX-680.
I remember that Egur posted a trick to accomplish this by setting up a "fake" monitor, but now that I have the proper HW, I can't fnd this post anymore.

Has anyone a pointer to the post from Egur ?

If your Motherboard supports Virtu MVP, it's possible.

I've tried it with 3570K not overclocked and the CPU usage of VLC was roughly 43% in task manager of windows 8.

cf. 41% in potplayer (with type 1 decoder)

Even with HT disabled, still clocked at 4.2ghz, VLC/GOM Player still take around 23/25%

jkauff

22nd June 2013, 17:31

If your Motherboard supports Virtu MVP, it's possible.
Motherboard needs to support iGPU and dGPU enabled at the same time. Eric's "fake monitor" trick works fine for decoding (like with LAV), but for encoding you do need Virtu MVP, and only certain apps work with that.

For example, Arcsoft Media Converter has explicit support in Virtu, but you can make Nero Recode and Handbrake QuickSync beta work by adding them to the Virtu iMode apps list. Media Coder, however, does not work.

theoneofgod

22nd June 2013, 17:45

Motherboard needs to support iGPU and dGPU enabled at the same time. Eric's "fake monitor" trick works fine for decoding (like with LAV), but for encoding you do need Virtu MVP, and only certain apps work with that.

For example, Arcsoft Media Converter has explicit support in Virtu, but you can make Nero Recode and Handbrake QuickSync beta work by adding them to the Virtu iMode apps list. Media Coder, however, does not work.

Eric's ffdshow didn't work for me (QSV), even with Virtu.

Pat357

22nd June 2013, 18:12

Here is the link:
http://forum.doom9.org/showpost.php?p=1532786&postcount=186

Thanks Nev !
I have it working, but with one very anoying issue : I often loose my mouse cursus (probably locked in the area of the not-existing fake screen).
Does this mean I did something wrong or is this a known issue ?
Is there a way to quickly recover from this situation besides rebooting the system ?

Pat357

22nd June 2013, 20:48

Eric's ffdshow didn't work for me (QSV), even with Virtu.

At first, it didn't work for me neither :)
I did have my monitor connected to the intel HD Graphics (DVI), but no quicksync for me.

I noticed that there was no file called "IntelQuickSyncDecoder.dll" in my fresh installed FFDShow folder, while AFAIR it should be there.
What I did was copy the "IntelQuickSyncDecoder.dll" from my LAV-filters installation to the FFDSHow directory and .. indeed.. quicksync was available in FFDshow !!

This could be a bug in the FFDshow installation : maybe it didn't detect my HD4600 and therefore it didn't install this needed file ?
I took the FFDshow installation file "ffdshow_rev4512_20130525_egur.exe" directly from this thread....

egur

23rd June 2013, 01:58

I'll check ffdshow's installer.
Anyway, Nev has found a graphics driver bug that causes QS to display green images when D3D11 is used on IvyBridge/Haswell drivers.
I hope to release a new version today.

egur

23rd June 2013, 03:12

Version 0.44 is out with the following changes:
* Improved D3D11 compatibility with 15.31 Intel drivers.
* H264 playback now properly supports fragmented packets (some live TV splitters), better error handling. Code was rewritten and now it's BSD licensed all the rest of IQSD code.
* FFDShow: r4519

Downloads
* For the latest cutting edge FFDShow builds download my builds Intel QuickSync Decoder SourceForge home page (http://sourceforge.net/projects/qsdecoder/)
* FFDShow-tryout site (http://ffdshow-tryout.sourceforge.net/download.php)
* LAV Splitter builds (http://forum.doom9.org/showthread.php?t=156191)

itsonlyjustincase

23rd June 2013, 13:29

any news from nvidia ?

egur

23rd June 2013, 17:25

Sorry, no.
Nev, has found an issue with live TV playback (I can't test this flow), so a fix will be made shortly.

itsonlyjustincase

24th June 2013, 21:58

Sorry, no.
Nev, has found an issue with live TV playback (I can't test this flow), so a fix will be made shortly.

I doubt we will have any answer or fix to that

egur

24th June 2013, 22:04

Just to be clear, the Nvidia issue is separate from the live TV issue.
The Nvidia issue is under investigation, it takes time to reach the right people.

itsonlyjustincase

25th June 2013, 00:37

Just to be clear, the Nvidia issue is separate from the live TV issue.
The Nvidia issue is under investigation, it takes time to reach the right people.

Sorry i should have precised i was talking about nvidia not nev.

I truely believe we won't have any interesting feedback from nvidia.

theoneofgod

26th June 2013, 12:39

egur

26th June 2013, 17:21

Issues with the latest version, watching Spartacus, I see the picture freezing (not audio) and then catching up on itself. Happens a lot during action scenes? It's not part of the show as it works fine with GOM Players internal filter.

Previous versions were OK?
What's your full setup (player, OS, splitter, driver, etc)?
Can you share a clip (<100MB) or specify the release name?

CharlieCL

26th June 2013, 18:10

My CPU Usage testing with 4K samples 3840x2160@25fps-120Mbp listed by NikosD on Ivy Bridge 2.0GHz HD 4000 Windows 8 Pro Intel Graphics Driver 9.18.10.3165

Windows Metro UI 6%
Windows Desktop 11% with LAV and Quick Sync enabled

Intel's new driver 10% ~ 20% better than Microsoft's default driver in Windows 8 pro.

I guess Quick Sync hardware acceleration unit may not be shared between tasks.
This may be a disadvantage of hardware acceleration codec vs software codec in
current using of hardware acceleration unit.

egur

26th June 2013, 18:23

Metro UI (all metro apps) use the MFT infrastructure. The graphics driver ships with Hardware MFTs to enable decode/vpp/encode (this is not not new BTW).

On Windows 7, WMP and WMC could use those MFTs. Windows (Metro) UI drops support for DirectShow in favor of MFT.
The MFT flow is very similar to DXVA as far as system resources are concerned. So it will always be my decoder.
Historically, Intel MFTs and Microsoft's DXVA2 video decoder (DTV-DVD video decoder) were not stable enough for general purpose use and lacked several features. That's why I started the Intel QuickSync Decoder project.

With 4K, the copy back scheme still works, but at a greater cost.

Each user should decide what's best for him/her.

theoneofgod

26th June 2013, 18:58

Previous versions were OK?
What's your full setup (player, OS, splitter, driver, etc)?
Can you share a clip (<100MB) or specify the release name?

The video was Spartacus.S02E06.720p.HDTV.x264-IMMERSE around 47th minute during the fight. It doesn't happen all the time. (this is just an example as it happened a few times)

I've not seen this before so I think it's just the new version.

GOM Player 2.1.50, Windows 8 x64 (fully updated), 9.18.10.3165, 3770k. No dGPU right now, using iGPU. I use ffdshow for both audio and video, spdif to my receiver.

egur

26th June 2013, 19:08

I can check this only on Monday (I'm on a business trip). Please fill in the blanks for the other details.

theoneofgod

26th June 2013, 22:08

Not sure, I don't use a specific splitter, just GOM Player and ffdshow.

GTPVHD

26th June 2013, 23:05

http://msdn.microsoft.com/en-us/library/windows/apps/bg182880.aspx

Windows 8.1 Preview introduces DirectX 11.2, which brings a host of new features to improve performance in your games and graphics apps.

Eric, does anything in DirectX 11.2 improve QS decoder when using D3D11?

CharlieCL

27th June 2013, 14:37

...

With 4K, the copy back scheme still works, but at a greater cost.

Each user should decide what's best for him/her.

The advantage of Quick Sync decoder is its renderer independent. Since Haswell's CPU and GPU share the same memory space, is it possible to remove the copy-back and keep renderer independent?

nevcairiel

27th June 2013, 15:17

The advantage of Quick Sync decoder is its renderer independent. Since Haswell's CPU and GPU share the same memory space, is it possible to remove the copy-back and keep renderer independent?

No, thats not possible.
Even if you could transfer the memory address, the GPU stores the image differently than your CPU needs it.

egur

27th June 2013, 16:49

There's an option for me to expose DXVA2 (D3D9 only) interface, in which the output will be an IMediaSample interface. This requires that D3D9 will be active, the DirectShow decoder (LAV) will add support for this. For DXVA2, the decoder is in charge of memory allocation, not the renderer. This option blocks adding a filter between the decoder and renderer as well as using only EVR style renderers.

Very complex (requires massive cooperation between me and Nev) and not worth the effort ATM. LAV already has DXVA2 in place.

I don't know how this is done with D3D11 or even which renderers support D3D11 (the surfaces are different)

Just exposing the address of the D3D9 surface data is something I already support (move the copy back to LAV). For D3D11, it's impossible to get the address.

The memory allocated for GPU surfaces is always WC (write combine) memory, which is uncached memory. It the same memory as WB (write back) memory with the same memory controller.

GPU drivers use WC memory and not WB because:
1) WC has excellent write performance - which is 99% of GPU memory traffic. WC used dedicated write back buffers to combine writes to DDR.
2) When writing to WC memory, the CPU caches are not modified (since it's uncached) hence CPU performance is not affected. Otherwise, every time you write a frame buffer to memory, many cache lines used by the application (code, data) will get evicted to higher caches or even main memory.

That's the theory anyway, I didn't test this on modern architectures where the memory controller is shared between GPU and CPU and the L3 cache is large. To test if this theory is still correct (my guess, it is), I'd need to rewrite the graphics driver.

theoneofgod

28th June 2013, 11:48

Eric, have you looked at the issue when Virtu MVP is in use, even with a single card, ffdshow won't use QSV.

edit: Strangely enough, after saying this, it seems to work now. I removed GOM Player from Virtu MVP. I had ffdshow installed and the codecs were selected before installing the graphics card this time.
edit2: Added GOM Player to Virtu MVP, now ffdshow won't use QSV.

Thanks Eric.

jkauff

30th June 2013, 03:45

theoneofgod

30th June 2013, 13:06

In my experience with Virtu MVP, adding unsupported applications is a real crap shoot. Are you using Eric's "phantom display" trick for the iGPU? That seems to work with the video filters that can use QS like ffdshow and LAV.

No, I haven't done anything. First I installed my system with the iGPU, including Eric's ffdshow. Set it up to allow QSV (all working)
Installed my HD 7950, and that was that, ffdshow works with QSV (D3D11)

jkauff

30th June 2013, 13:40

No, I haven't done anything. First I installed my system with the iGPU, including Eric's ffdshow. Set it up to allow QSV (all working)
Installed my HD 7950, and that was that, ffdshow works with QSV (D3D11)
Win 8 is supposed to support a headless iGPU and a dGPU setup, but this is the first report I've seen of it actually working. Maybe installing the dGPU last is the key.

theoneofgod

30th June 2013, 13:43

Win 8 is supposed to support a headless iGPU and a dGPU setup, but this is the first report I've seen of it actually working. Maybe installing the dGPU last is the key.

Me too. I do have Virtu MVP installed if that makes any difference.

Yups

1st July 2013, 20:50

Media SDK 2013 R2:

Intel® Media SDK 2013 R2 also introduces changes to the static dispatcher library which improve dynamic libraries loading algorithm in multi-GPU cases and headless mode via Microsoft* DirectX* 11.1.

Better headless support with the new SDK release?

egur

1st July 2013, 21:22

Better headless support with the new SDK release?
They fixed an issue I ran into while testing D3D11. It's mostly important for backwards compatibility. Shouldn't change anything with this decoder.

egur

1st July 2013, 22:28

It turns out my Asus board has a license for Virtu MVP so I did a few tests.
My setup:
* Windows 8 x64 fully patched.
* LAV splitter and EVR.
* Latest released ffdshow
* SandyBridge i7-2600
* Latest Intel drivers (15.28).
* AMD Radeon 6950 + Catalyst 13.4
* Single display connected to AMD dGPU.
* Virtu MVP from Asus site (2.1.221.24927)

32 bit - ZoomPlayer or mpc-hc
* iGPU profile: crashed when calling Direct3DCreate9 or Direct3DCreate9Ex. When not running under a debugger, the image is just black.
* dGPU profile: works fine in D3D11 mode.
* No profile or disabled profile - works fine in D3D11 mode.

64 bit - mpc-hc x64
* iGPU profile: works fine in D3D11 mode. This should be D3D9! Will dig deeper later on.
* dGPU profile: works fine in D3D11 mode.
* No profile or disabled profile - works fine in D3D11 mode.

I tried to contact LucidLogix (the company that makes Virtu), maybe they have a newer version that works better.

Update:
Same setup but screen is connected to the iGPU.
32 bit
* All modes (i/d/disabled) - all work in D3D9. dGPU profile should have been D3D11.
64 bit
* iGPU mode - works in D3D9.
* dGPU mode - doesn't work (fallback to libavcodec)
* No profile or disabled profile - works fine in D3D9 mode.

Update2
I updated to the latest version from Lucid's website. The results didn't change much.
Now I watched more than 2 seconds and saw that there's massive A/V sync and the CPU jumps from 2% to 27% utilization! Disabling Virtu for the player solved the problem.
Something is horribly wrong here :(
So until I get support from Lucid, nothing I can do with it. The version from the LucidLogix website doesn't accept the Asus license so in 30 days it will expire.
Conclusion (for now) - don't mix QS (only this decoder) and Virtu MVP.

jkauff

2nd July 2013, 00:07

Also, madVR doesn't work in Virtu's iMode. I don't put any of my players in Virtu.

Your "fake display" hack works fine for ffdshow and LAV. I have yet to play around with Win 8 without the fake display to see if it will use the iGPU. I'll give it a try tomorrow.

theoneofgod

2nd July 2013, 00:23

QSV in GOM Player using the latest ffdshow works fine with Virtu and a dGPU. The dGPU is the primary output, using DVI. I don't add the media player to Virtu's applications list. No manual tricks or anything.
I install the iGPU before the dGPU to insure ffdshow installs the correct dll, after doing this, I setup ffdshow codecs to use QSV for the relevant sources. Running AMD Radeon 13.4 drivers without Catalyst, I use Radeon Pro and MSI Afterburner, not that it matters.
When playing an mkv, ffdshow states Intel QSV D3D11.

egur

2nd July 2013, 09:31

Yes, it works fine with Virtu when Virtu is not active for the player/app.
Please check if the new ffdshow version installs correctly on your system, I've fixed the installation issue (for windows 8). In Windows 7, when connecting the screen to the dGPU, a system check will not see the iGPU and will not install QS. This is done because ffdshow admin (clsid) doesn't want this DLL to always install. As far as I'm concerned, I'd remove the check.

itsonlyjustincase

2nd July 2013, 10:55

Any update regarding the Optimus issue ?

theoneofgod

2nd July 2013, 10:56

I just reinstalled ffdshow, it installed fine, QSV shown for Windows 8, can't say for Windows 7.

egur

2nd July 2013, 11:22

Any update regarding the Optimus issue ?
Not yet, I have identified a few contacts and waiting for an answer.

I just reinstalled ffdshow, it installed fine, QSV shown for Windows 8, can't say for Windows 7.
For window 7, a screen (or fake screen) must connected to the iGPU during both installation and runtime.

jkauff

3rd July 2013, 01:13

For window 7, a screen (or fake screen) must connected to the iGPU during both installation and runtime.
I played around with Win 8 without the fake screen today, and LAV seems to have trouble with it. Config dialog shows QS as available, but doesn't use it during runtime. I'll try re-installing the Intel drivers tomorrow and see if that makes a difference.

itsonlyjustincase

3rd July 2013, 13:10

I played around with Win 8 without the fake screen today, and LAV seems to have trouble with it. Config dialog shows QS as available, but doesn't use it during runtime. I'll try re-installing the Intel drivers tomorrow and see if that makes a difference.

Same here it uses avcodec

wanezhiling

12th July 2013, 12:02

9.18.10.3214 (http://drivers.softpedia.com/get/GRAPHICS-BOARD/INTEL/Intel-Iris-HD-Graphics-Driver-15333214-Beta-for-Windows-8-Windows-81.shtml)

theoneofgod

14th July 2013, 06:56

9.18.10.3214 (http://drivers.softpedia.com/get/GRAPHICS-BOARD/INTEL/Intel-Iris-HD-Graphics-Driver-15333214-Beta-for-Windows-8-Windows-81.shtml)

Those drivers make my QSV slow with Media Converter.

ryrynz

14th July 2013, 07:12

9.18.10.3214 (http://turbobit.net/download/free/2kd5wdg67xqu#) Windows 7/8/8.1 32/64 bit for HD graphics 4000+
Turbobit.net (217MB)

wanezhiling's link is for Windows 8/8.1 only.

egur

14th July 2013, 08:00

Beta drivers...
They are meant mostly for developers to test Win 8.1 new features.

theoneofgod

14th July 2013, 08:19

Beta drivers...
They are meant mostly for developers to test Win 8.1 new features.

Thought so, didn't expect them to break existing functionality though.

diizzy

19th July 2013, 11:12

First of all, great work Eric! :-)

I reported this to nevcairiel who directed it to you so I'll just quote it.
I just updated to the newest version (0.58.1) and there seems to be a regression using QuickSync. From what I can tell it pretty much affects all types of MPEG-2 irregardless of container (.ts, .mpg, .vob). If you're lucky you'll get a few frames correctly but it'll then play roughly one frame per second making it a slideshow. Turning off QuickSync fixes the issues, H.264 works fine.

Windows 7 SP1 64-bit
LAV Filters 0.58.1 (32-bit)
MPC-HC 1.7.0.7634 (32-bit)
madVR 0.86.9 (32-bit)
Intel Graphics HD4000 (i7-3770) - v9.18.10.3165
https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProdId=3442&DwnldID=22873&ProductFamily=Desktop+Boards&ProductLine=Intel%C2%AE+7+Series+Chipset+Boards&ProductProduct=Intel%C2%AE+Desktop+Board+DZ77GA-70K&lang=eng

Best regards,
Daniel

egur

19th July 2013, 16:08

I couldn't reproduce on an i7-2600 with Windows 8.
Plays great with the LAV + MadVR (ZoomPlayer and MPC-HC).
I'm using LAV as splitter (splitter source) in my tests. What do you use?
Also, try changing settings in MadVR and see if things change (like queue lengths, etc.). My MadVR settings is default + DXVA scaling.

diizzy

19th July 2013, 16:39

I did a few more tests, something breaks when you enable hardware deinterlacing in LAV Filters (QS). I confirmed on both MPEG2 and H.264. QS and YADIF works fine though...
My settings are default in MadVR including scaling. Didn't notice it on H.264 earlier because I just a few files that are interlaced.
Best regards,
Daniel

nevcairiel

19th July 2013, 17:36

Yeah i'm personally not really convinced that the QS hardware deinterlacing works all that great, or it fails when i disable timestamp correction in QS, or something, but i've heard numerous problem reports from it.

Generally, you should just turn it off, and turn YADIF off as well, and just let your renderer do the deinterlacing.

egur

20th July 2013, 14:56

I also checked with and without HW deinterlacing. Still works on all my 18 MPEG2 test clips.
In one clip, when HW DI is off, MadVR had issues. This clip is a pathological case where the stream switches between soft and hard telecine (evil_trees.ts clip).
Normal clips had no issues.
The reason I asked about the splitter is that some splitters may produce very bad time stamps affecting playback, nothing I can do about this...

Please share a representative clip (<100mb).

diizzy

20th July 2013, 18:20

I can cut a few regular TS files too but here a MTS file.
http://projects.pyret.net/dump/sample.mts
I use LAV Filter as splitter, missed to mention it earlier.
//Daniel

theoneofgod

23rd July 2013, 11:42

What a dick move to Windows 8.1 to find Lucid doesn't work! ffdshow works fine though with QSV, if not better on Windows 8.1

VFR maniac

23rd July 2013, 15:53

Hi.
I'm using Marumo ISDB Splitter, which supports PID change in a service of ISDB stream.
http://www.marumo.ne.jp/junk/isdbsplitter-0.2.19.lzh

I can't use Intel Quick Sync Decoder with this splitter.
egur's ffdshow won't start playback of any ISDB stream.
LAV Video Decoder can't select as an active decoder for any ISDB stream.

Is this an issue of Intel Quick Sync Decoder?
Or of Marumo ISDB Splitter?

Here is my playback environment.
OS: Windows 7 Professional SP1 64bit
CPU: Core i5-3570 Intel HD Graphics 2500 (9.18.10.3165)
Player: MPC-HC rev7646 (x86)
Video Renderer: madVR 0.86.9

egur

23rd July 2013, 21:12

I don't know whose fault it is...
Could be a different (unsupported) fourCC code or an unsupported profile.
If there for me a way to test this?

VFR maniac

23rd July 2013, 21:46

What is needed for you to test and confirm this issue?

At least, I can use Quick Sync Decoder of your ffdshow and LAV Video when LAV Splitter is used to split from ISDB stream.

egur

23rd July 2013, 22:09

For testing I need a sample file and how to setup this splitter. If this splitter require connection to a live TV broadcasts (not via the Internet) then I can't test this.
What is this splitter used for?

VFR maniac

23rd July 2013, 22:23

What is this splitter used for?
For local file playback.

For testing I need a sample file and how to setup this splitter.
OK, here is a sample: http://vfrmaniac.fushizen.eu/TX_noise_sample.ts
And the setup is just doing "regsvr32 isdbsplitter.ax".

egur

24th July 2013, 15:25

@VFR maniac
I reproduced the failure with this splitter but I don't know what the exact cause is. It's sending a different stream than LAV splitter.
This splitter doesn't work at all with some of my TS files (H264 and MPEG2) - simply doesn't connect to the File Reader (Async) filter needed for playback.

My suggestions is to use LAV splitter.
Unless you're the developer of this splitter, why would you use it?

VFR maniac

24th July 2013, 15:59

@VFR maniac
My suggestions is to use LAV splitter.
Unless you're the developer of this splitter, why would you use it?

LAV Splitter (libavformat) doesn't support PID change in a service.
A certain TV channel I frequently recode changes PID when a SD TV program is changed into another HD, and vice versa.
So LAV Splitter is useless unless splitting TS file at points of PID change.

In addition, this splitter supports decryption of Japanese ISDB stream through smart card reader with B-CAS card.
For people who legally watch encrypted ISDB stream in Japan, LAV Splitter is absolutely useless.

diizzy

24th July 2013, 21:47

@ egur

Did you manage to replicate the issue?

Best regards,
Daniel

egur

25th July 2013, 16:05

@VFR maniac
I'll take a deeper look when I have the time.

@Diizzy
The clip plays perfectly fine on my machine.
Looks like a setup issue on your side. Try reinstalling the driver.
Another option is to change scaling in MadVR to 'DXVA'. Let me know if this changed anything.
How does it work with EVR?

Sparktank

4th August 2013, 05:22

Hi,

I don't know where to go for help.

1)
My laptop is preconfigured and discontinued. The price you pay for growing up poor.
I have an HP Pavilion G6 with Intel HD Graphics 3000 which HP has stopped providing driver updates for since 2011.
So I can't really update to latest drivers without worrying if the generic drivers are missing anything custom that HP did to them.

2)
I use primarily K-Lite Mega Codec Pack to install everything and never had a problem before.
Latest stable version is 9.9.5 (+9.9.6 update).

I don't know if they modify anything but but the 9.9.6 update uses LAV Filters 0.57-17-g1cc21b3.
I'm able to use QuickSynch for decoding AVC/H264 in LAV Video without problems.

But since I tried one of their BETA packages (9.9.9 BETA 2), they've upgraded their LAV Filters to 0.58.1-5-gcb4e2dc.
And QuickSynch was lost.

I also tried copying the portable version of LAV 58.2 into the K-Lite directory (never had a problem doing that before).
I even copied the little "dependencies" file and un/registered the three filters in the LAV folder.
All three un/registered successfully.

3)
For any version that's >58.x, QuickSynch is shown as "Not Available" when just in 57.1 it was available.
I prefer using LAV Video for decoding H264 streams because there is an incredible amount of performance efficiency compared to using FFDShow.

I use SVP (Smooth Video Project) a lot now and watch the performance graphs to see how much I can get out of my machine.
For some reason FFDShow takes nearly 90% of the CPU usage while LAV Video only peaks around 35% most of the time.

There's four places I could go to get help:

Here
LAV Filters
HP
KLCP

The KLCP forums are very dead.
I've asked in the HP forums "how safe is it to update to generic drivers?"
And I'm unsure who to bring this to and don't want to spam the forum with the same post so I figured it's mostly relevant to QuickSynch than LAV?

I'm so tired right now and wasted a good 3 hours doing nothing but googling and setting up an account with HP to post in their forum.

I could uninstall KLCP entirely and download the last 3 versions of LAV/FFDShow and find out which ones exactly lost QuickSynch, if that helps.

Superb

4th August 2013, 05:28

I could uninstall KLCP entirely and download the last 3 versions of LAV/FFDShow and find out which ones exactly lost QuickSynch, if that helps.Do that. Install the latest official LAV Filters (currently 0.58.2) w/ the official installer and then test.

Sparktank

4th August 2013, 05:59

Do that. Install the latest official LAV Filters (currently 0.58.2) w/ the official installer and then test.

Done.

LAV Video 58.0 and above lose QSV functionality. (Official builds)

Reverted back to KLCP 9.9.6 that uses LAV Video 57.0.

NikosD

4th August 2013, 06:29

You have old Intel drivers.

If you can't update them, you have to stick with old LAV filters.

If you want to use latest LAV filters, you have to update Intel driver too.

Think it as a pair.

egur

4th August 2013, 07:20

You should be quite safe installing the latest Intel drivers. Worst case, reinstall the old drivers and tell me the exact driver version.

nevcairiel

4th August 2013, 07:44

I heard from other people that the latest version of the decoder doesn't work with older drivers anymore, what caused this, and can you fix it?

Sparktank

4th August 2013, 08:23

You should be quite safe installing the latest Intel drivers. Worst case, reinstall the old drivers and tell me the exact driver version.

I'll give the newest drivers a try tomorrow and see if >58.0 works properly for me.

EDIT: Updating to latest Intel HD Graphics drivers from Intel website (not HP website) was a success (so far).

With current drivers, LAV 58.2 shows QSV as available.
And it does work.

I was using an old Intel driver from 2011 (the last driver HP pushed for Pavilion G6).
Intel High-Definition (HD) Graphics Driver
2011-11-10 , Version:8.15.10.2476
The only information it provided for this update was...
Fix/Enhancement

- Provides the updated driver.

So far I'm not seeing any difference in using the generic build from Intel. But video plays back, QSV is back in LAV >58.0 and SVP is liking it. A lot.

Latest driver (using auto-detect on Intel)...
* Package: 191470
*
* Graphics: 9.17.10.3062
* Display Audio Driver: 6.14.0.3097
*
*
* March 20, 2013

Since I haven't been updating the drivers since 2011, I can't really say which version actually prevented QSV functionality.

If any more information is needed, please let me know.
Thanks for all the help (so far). :)

egur

4th August 2013, 20:16

As a rule of thumb, it's usually a good idea to update drivers.
I've updated all my drivers (network graphics, sound, etc.) directly from the manufacturer sites. OEMs sometimes create bloated drivers w/o any apparent functionality and on my HW, the OEM drivers were also very old.

I'll check why old drivers fail tomorrow. Thanks for the report. My home system is Win8 now so drivers are relatively new.

jkauff

7th August 2013, 06:23

NikosD

7th August 2013, 13:37

Using latest Intel drivers of SNB for Windows 8 x64 and latest flash version, I get crashes of IE 10 when trying to play ANY YouTube 4K video.

For example:
http://www.youtube.com/watch?v=Cx6eaVeYXOs

I remind you in order to reproduce the crash, you have to select "Original" resolution in order to activate the UHD resolution - It's above the 1080p option.

Of course I'm talking for streaming playback and only above 1080p.

nevcairiel

7th August 2013, 13:57

Keep in mind that this thread is about the QuickSync Decoder that Eric wrote, not about generic driver bug reports.

egur

7th August 2013, 13:59

Eric, now that you've been using Win 8, have you found any software that takes advantage of the headless iGPU support? Everything I use still needs the fake display. Do we have to wait for new drivers from Intel for headless to work?
The drivers are there for a long while. The issue is that applications need to change in order to enable this feature - they must work in D3D11. The previous behavior was to use D3D9.

Using latest Intel drivers of SNB for Windows 8 x64 and latest flash version, I get crashes of IE 10 when trying to play ANY YouTube 4K video.

For example:
http://www.youtube.com/watch?v=Cx6eaVeYXOs

I remind you in order to reproduce the crash, you have to select "Original" resolution in order to activate the UHD resolution - It's above the 1080p option.

Of course I'm talking for streaming playback and only above 1080p.
Looks like a bug in the flash player component. SNB doesn't support 4K...

NikosD

7th August 2013, 14:07

Maybe it's flash problem or Win 8 drivers problem.
Particularly in the software fallback mode, exactly because SNB doesn't support 4K.

Win 7 x64 plays fine in software mode - same driver, same flash version.

Is it flash or Win 8 driver ?

Update:
Same behavior with a discrete card (Radeon 5750) inside the SNB system.
IE doesn't crash, but shows a green screen because 5750 is forced to use DXVA and not CPU even for 4K, which doesn't support.
So it's rather a flash problem than the immaturity of Win 8 drivers from both Intel/AMD.

NikosD

10th August 2013, 08:35

For those interested I did some tests regarding multiple streams decoding on various video hardware and various video formats

The test platform was:

Win 8 x64
MPC-HC v1.6.8 (with internal codecs using DXVA native)

Video Processors (with latest drivers and default clocks)

UVD2.2 (Radeon 5750)
VP4 (Geforce 440GT)
VP5 (Geforce 610GT) and
QuickSync 1 (HD 2000 - SandyBridge)

The video formats were all 1080p (full HD 1920x1080 progressive):

WMV HD (a 1080p24fps@10Mbps clip - the toughest WMV3 clip I have)
VC-1 (a 1080p24fps@18Mbps clip - a medium to hard VC-1 clip)
MPEG-2 (a 1080p24fps@45Mbps clip - a hard MPEG-2 (.ts) clip)
H.264 (a 1080p24fps@11Mbps clip - a Main@L4.1 "normal" clip)

The results are below - very interesting in my opinion.

WMV3

UVD2.2 - 2 streams
VP4 - 3 streams ~89% VPU utilization
VP5 - 4 streams ~89~ VPU utilization
QuickSync - Not supported

VC-1

UVD2.2 - 2 streams
VP4 - 3 streams ~95% VPU utilization
VP5 - 4 streams ~95~ VPU utilization
QuickSync - Not supported

MPEG-2

UVD2.2 - Not supported
VP4 - 3 streams ~80% VPU utilization
VP5 - 5 streams ~92~ VPU utilization
QuickSync - >9 streams

H.264

UVD2.2 - 2 streams
VP4 - 3 streams ~88% VPU utilization
VP5 - 4 streams ~99~ VPU utilization
QuickSync - >9 streams

Comments:

1)
UVD2.2 supports only 2 streams for all formats - odd behavior (driver?).
VP4, VP5 are the only video processors supporting all of 4 formats
I stopped QuickSync multiple streams at 9, not because of frame dropping or performance reasons, but because of limited space in my one and only screen (21.5" - 1920x1080). I think that maybe 10 or 11 streams were doable.

2) It's a pity that so fast hardware like QuickSync supports only 2 formats (MPEG-2, H.264) in DXVA native mode even AFTER 3 GENERATIONS/ VERSIONS of QuickSync.
UVD3.0 supports 5 formats (MPEG-2, MPEG-4 ASP, H.264, VC-1, WMV3) and VP4, VP5 support 4 and a half - because MPEG-4 ASP is supported only in CUVID mode.

3)When trying to measure QuickSync VPU utilisation with Intel GPA monitor, I had major frame dropping with the window open in front. Only in minimized mode it worked well - strange.
From what I've seen, the major bottleneck was EU utilisation and not MFX utilisation.
Faster QuickSync versions with more EUs and faster clocks can go up to a lot more streams I believe.

theoneofgod

11th August 2013, 06:11

Out of sync audio is common while using the iGPU in another process, like watching a movie + converting with both QSV?

egur

11th August 2013, 09:20

NikosD,
The HW supports WMV3 and VC-1 but use a different GUID for this task for some unknown reason.
The HW and driver also support H264 MVC profile as well as SVC in Haswell (encode + decode).

NikosD

11th August 2013, 10:23

H.264 MVC is supported by all video processors in HW.
I didn't mention it because it's the least common of all.

CharlieCL

14th August 2013, 15:52

For those interested I did some tests regarding multiple streams decoding on various video hardware and various video formats

Are you decoding multi-stream video by multi-thread or multi-tasking (multi-player)?

I found an interesting CPU usage change for multi-player testing. One player CPU usage maybe 5%, two maybe 10%, three maybe 20%, four maybe 40%. It is non-linear.

Usually there are at most two hardware decoders in a GPU, when they are not available, software decoder has to be used. So there is non-linear CPU usage curve.

NikosD

14th August 2013, 16:20

Are you decoding multi-stream video by multi-thread or multi-tasking (multi-player)?

I found an interesting CPU usage change for multi-player testing. One player CPU usage maybe 5%, two maybe 10%, three maybe 20%, four maybe 40%. It is non-linear.

I think you didn't read carefully my post.
I wrote :

The test platform was:

Win 8 x64
MPC-HC v1.6.8 (with internal codecs using DXVA native)

So when I say that I used DXVA native there is no such thing as CPU multi-threading or CPU usage.

DXVA native means HW decoding using a special ASIC and the EU of GPU, leaving to CPU as little as possible.

We are not interested in CPU usage - as long as it's not a bottleneck - and with DXVA native, never is.

Usually there are at most two hardware decoders in a GPU, when they are not available, software decoder has to be used. So there is non-linear CPU usage curve.

This is as false as possible.
There are no one, two or three HW decoders in there.
I'll write again that there is an ASIC and EUs (different number of EUs for each generation of iGPU and for different model in the same generation) that they do the job.

The decoding alone is done almost 100% by the ASIC, especially in newer generations of ASIC (QuickSync)

Software decoder was never used during my tests, it was always in pure HW DXVA mode.

Software decoding cannot be used during DXVA native decoding.

If the hardware is not powerful enough to decode the stream, it will start drop frames and framerate during playback.

It cannot fall-back to software mode.

egur

15th August 2013, 08:38

CharlieCL

15th August 2013, 16:18

Non linear behavior is common in many scenarios where a resource is a bottleneck.
In this case it's probably the memory bus and maybe CPU/GPU caches.
try writing to a disk (HDD/SSD/DOK) in parallel and see that the performance drop per job is non linear too.

HW decode/encode involves multiple stages, some can have multiple copies of HW resources in order to achieve higher throughput. These details are always "under the hood" and change without notice. There's no practical limit on the number of parallel HW decodes. The limiting factor is memory availability, HW decoder speed, memory speed, etc.

Memory bus and caches may be a bottleneck.

The use of HW decoder is a magic. For dGPU the HW decoder is on GPU, I am not sure whether the graphic driver or DirectShow filters may lock HW decoder resource to first request task. So later tasks have to use software decoder.

egur

17th August 2013, 18:40

It's the same principle like other HW. Only the driver (or OS kernel) can access the device and send tasks to it. When multiple requests are sent from various sources, the driver schedules them and run them at some arbitrary order.
The driver may need to acquire system resources per task, such as memory and these resources can run out eventually.

With HDD, it's exactly the same. Two apps can ask to write to disk at the same time, but the driver will schedule the writes sequentially.

theoneofgod

18th August 2013, 00:17

jkauff

21st August 2013, 02:17

So this explains the out of sync audio while converting with QSV?
I have three apps that use QS encoding, including the Handbrake beta, and I've never experienced out of sync audio.

This thread is only for QS decoding, as Eric has nothing to do with the SDK team, so I don't want to get into an encoding discussion, but I think something in your settings must be creating the problem.

theoneofgod

21st August 2013, 09:35

I have three apps that use QS encoding, including the Handbrake beta, and I've never experienced out of sync audio.

This thread is only for QS decoding, as Eric has nothing to do with the SDK team, so I don't want to get into an encoding discussion, but I think something in your settings must be creating the problem.

Sorry you misunderstood me.
While converting mkv->mp4, playing a movie in GOMPlayer using QSV decoder is out of sync.

andyvt

21st August 2013, 09:41

Sorry you misunderstood me.
While converting mkv->mp4, playing a movie in GOMPlayer using QSV decoder is out of sync.

Your system might not have the resources to handle both tasks when run at the same time. I'd looks at I/O first, but it's possible that another subsystem is causing, or taking part in, this issue.

It's also possible that GOMPlayer is doing something to mess up the clock in the graph when multiple processes are contending for resources.

theoneofgod

21st August 2013, 10:51

Your system might not have the resources to handle both tasks when run at the same time. I'd looks at I/O first, but it's possible that another subsystem is causing, or taking part in, this issue.

It's also possible that GOMPlayer is doing something to mess up the clock in the graph when multiple processes are contending for resources.

My resources are fine, my I/O is 10% usage while converting.

It's also possible that GOMPlayer is causing it, but what you said about contending processes, it's hard to make that part out.
ffdshow is contending with the converter, not GOMPlayer.

andyvt

21st August 2013, 12:04

My resources are fine, my I/O is 10% usage while converting.

What are you using to measure disk I/O?

It's also possible that GOMPlayer is causing it, but what you said about contending processes, it's hard to make that part out.
ffdshow is contending with the converter, not GOMPlayer.

Ffdshow is a DirectShow filter. DirectShow filters are COM components that load into a graph, which is hosted in a process - in this case GOMPlayer. Filters shouldn't have to worry about things like priority, that's the process's job. Unless ffdshow is producing different timestamps in this condition, it is not to blame.

theoneofgod

21st August 2013, 12:23

What are you using to measure disk I/O?

Ffdshow is a DirectShow filter. DirectShow filters are COM components that load into a graph, which is hosted in a process - in this case GOMPlayer. Filters shouldn't have to worry about things like priority, that's the process's job. Unless ffdshow is producing different timestamps in this condition, it is not to blame.

Windows Resource Monitor.
Analysing it while converting shows nothing of concern.

andyvt

21st August 2013, 12:37

Windows Resource Monitor.
Analysing it while converting shows nothing of concern.

If the PC is not resource constrained, then it gets back to analyzing the player.

- Does it reproduce when using a different player
- Does it reproduce when using a different filter
- Does it reproduce when using a different QS dll wrapper (lav video)

theoneofgod

21st August 2013, 13:20

If the PC is not resource constrained, then it gets back to analyzing the player.

- Does it reproduce when using a different player
- Does it reproduce when using a different filter
- Does it reproduce when using a different QS dll wrapper (lav video)

I'm not talking about process resources but the entire system. Not a single piece of hardware is struggling during the conversion. CPU 20%, I/O is low 10-15%, RAM at 17% used.
I haven't tested any of the above, yet.

andyvt

21st August 2013, 13:29

I'm not talking about process resources but the entire system. Not a single piece of hardware is struggling during the conversion. CPU 20%, I/O is low 10-15%, RAM at 17% used.

What's the queue length on the disk where the files are located? Is anything being pulled over the network?

I haven't tested any of the above, yet.

Troubleshooting is like algebra: can't solve the problem until the X stands alone. You need to isolate the variables to make any useful conclusions.

jkauff

21st August 2013, 13:54

I'm not talking about process resources but the entire system. Not a single piece of hardware is struggling during the conversion. CPU 20%, I/O is low 10-15%, RAM at 17% used.
I haven't tested any of the above, yet.
Do you get the same results using LAV audio and video decoders with QS support turned on?

egur

21st August 2013, 22:08

Most likely when you're transcoding using Handbrake (uses QS), then the QS engine is working at 100%, giving your player bad results.

theoneofgod

22nd August 2013, 18:16

What's the queue length on the disk where the files are located? Is anything being pulled over the network?

Troubleshooting is like algebra: can't solve the problem until the X stands alone. You need to isolate the variables to make any useful conclusions.
No, I know that. I just haven't had time to try different players, filters, etc. Nothing over network and queue length is low.

Do you get the same results using LAV audio and video decoders with QS support turned on?
Haven't tried yet. I was comfortable using GOMPlayer and Eric's decoder.

Most likely when you're transcoding using Handbrake (uses QS), then the QS engine is working at 100%, giving your player bad results.
Yeah, probably, that's what I was thinking. I don't use Handbrake though, but looking at GPU-Z during conversion, the iGPU is near maxed out (approx 93%).

Sparktank

22nd August 2013, 21:08

No, I know that. I just haven't had time to try different players, filters, etc. Nothing over network and queue length is low.

What is the source of the MKV? Is it converting framerate or anything?

Have you tried remuxing the MKV or modding the header file (in MMG; assuming the video elementary stream is h264) to have a valid FPS?

It's not Variable Frame Rate is it?

You should probably open a new thread, seems to be getting largely off topic with all the troubleshooting.

Perhaps create a small sample too.

andyvt

23rd August 2013, 09:39

... the iGPU is near maxed out (approx 93%).

If the GPU is maxed, that could easily be your resource constraint. I'm not sure how you would prioritize the player app over the transcoder. Windows has methods for giving priority (process priority and multimedia class scheduler), but that might not take GPU utilization into account.

NikosD

2nd September 2013, 18:34

Intel released new 9.17.10.3223 drivers for Sandy Bridge, will only install on Sandy Bridge HD2000/3000.

64bit
https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProdId=3319&DwnldID=23102

Using the above 64bit driver, I still have problems with at least two OpenGL programs, as with all previous ones.

I tried both Win 7 x64 and Win 8 x64 with Core i5 - SandyBridge (HD 2000)

The programs are:

GluxMark2
http://www.enduroriders.sk/juro/gluxmark2/app/gluxMark2.2_win32.zip

and

gpudip
http://www.skenegroup.net/fornvidiots/gpudip/gpudip.zip

If anyone has a SandyBridge or another iGPU from Intel (Ivy/ Haswell) could try and tell me if those programs are crashing or not.

With my AMD and Nvidia cards, both programs run OK.

XinHong

2nd September 2013, 20:40

@NikosD :
- gpudip show me "WGL_ARB_render_texture not supported", display the GPU ID and stop
- GluxMark2 : Error message "can not parse system info" but I can run the bench with my iGPU. It crashed with my nVidia GT525M

System : Sandy Bridge with HD3000, 9.17.10.3223 drivers on windows 7 x64

NikosD

2nd September 2013, 21:58

If you get the error message with GluxMark2, how come you can bench it with iGPU ?

When I press bench, I get an error message after a while and stops there.
Never completes the benchmark with iGPU (HD 2000)

egur

4th September 2013, 08:41

NikosD,
This is not the right thread for your discussion.

NikosD

4th September 2013, 12:30

I saw the new drivers posted and I took the chance to ask for some OpenGL help regarding those drivers.

There is no right thread in this forum to ask for correction of OpenGL bugs, but because you are an Intel employee and a lot of Intel officials take a look at this thread, it's a right thread - if you see it from this view.

Thanks.

ryrynz

4th September 2013, 14:33

It's his thread and he called it :) I wouldn't worry about justifying yourself, I think everyone posts OT at some point or another and we all have pretty much the same reason for doing so.

jkauff

5th September 2013, 02:59

IIRC, Eric's job at Intel has nothing to do with graphics (as his signature would indicate). He does the QS Decoder in his off-hours.

avih

5th September 2013, 14:50

There's no "proper" thread for this question, and using this thread is not such a bad idea for the reasons stated. Please let it be, and if someone has an answer - help, otherwise, no need to make a fuss about it. Thanks.

egur

5th September 2013, 20:57

No fuss :)
People are free to discuss whatever they want.

Raylan Givens

8th October 2013, 21:41

*Support headless iGPU (Intel GPU disconnected from display) on Windows 8 and newer.

Can please someone elaborate? I'm using i5 3570k & AMD7950 on an ASUS P8Z77-V Plus motherboard. The dvi connection is on the discrete GPU of course, mainly for gaming reasons, but it would be very interesting to have everything else or simply the video HWA on my HD4000. That's why I'd really like to know whether is it possible or not...

What can I do? Can I simply install the latest Intel drivers and keep both GPUs enabled or something? Will the IntelQS become 'avalaible' here:

http://i7.minus.com/i4soqiyx7DgDO.png

I'm not familiar at all with the integrated GPU...

andyvt

8th October 2013, 22:26

Can I simply install the latest Intel drivers and keep both GPUs enabled or something? Will the IntelQS become 'avalaible' here:

Yes. It should.

jkauff

10th October 2013, 00:49

*Support headless iGPU (Intel GPU disconnected from display) on Windows 8 and newer.

Can please someone elaborate?
You have to do two things. The iGPU is disabled by default when you install a discrete GPU, but there's a setting in the BIOS for your motherboard that enables multiple GPUs. You have to set that first.

Then install the Intel drivers. Both GPUs should now show up in Device Manager.

Finally, you need to create a "fake" display for the iGPU. Although Win 8 supports a headless GPU, programs must be coded specifically to use Direct3D 11.1. I'm not aware of any video software that currently supports it.

Follow the instructions on the following page to create the fake display, and after than QuickSync will be available.

http://mirillis.com/en/products/tutorials/action-tutorial-intel-quick-sync-setup_for_desktops.html

theoneofgod

10th October 2013, 09:20

You have to do two things. The iGPU is disabled by default when you install a discrete GPU, but there's a setting in the BIOS for your motherboard that enables multiple GPUs. You have to set that first.

Then install the Intel drivers. Both GPUs should now show up in Device Manager.

Finally, you need to create a "fake" display for the iGPU. Although Win 8 supports a headless GPU, programs must be coded specifically to use Direct3D 11.1. I'm not aware of any video software that currently supports it.

Follow the instructions on the following page to create the fake display, and after than QuickSync will be available.

http://mirillis.com/en/products/tutorials/action-tutorial-intel-quick-sync-setup_for_desktops.html

I tried that last night but couldn't get any software that doesn't already support headless to work. Windows 8 x64.

jkauff

10th October 2013, 15:35

I tried that last night but couldn't get any software that doesn't already support headless to work. Windows 8 x64.
I think you must have done something wrong in the setup. On my Win 8 64 bit, LAV video decoder uses QuickSync, as does ffdshow and the latest Handbrake nightlies that support QS encoding.

What software are you using that supports headless without the fake display? I haven't found any yet.

theoneofgod

11th October 2013, 12:44

I think you must have done something wrong in the setup. On my Win 8 64 bit, LAV video decoder uses QuickSync, as does ffdshow and the latest Handbrake nightlies that support QS encoding.

What software are you using that supports headless without the fake display? I haven't found any yet.

MSI Afterburner can encode your gaming using Quick Sync. ffdshow, LAV all work fine without a fake display. Of course you need your iGPU drivers installed. I needed this for Quick Sync and ArcSoft's Media Converter so I could convert MKV to MP4 for a Blu-ray player. Virtu MVP doesn't currently work on Windows 8.1 so spent time researching. Found XMedia Recode that takes about 90 seconds to do this stream copy.

corporalgator

18th October 2013, 22:42

theoneofgod

19th October 2013, 02:29

This really sucks. I updated to Windows 8.1 and it blew up my graphics drivers. When I reinstalled them, my dummy monitor was gone and LAV filters no longer detected quicksync. I reenabled it but no go. It was working fine under windows 8. Guess it's time to rollback. Stupid windows.

I was on Windows 8.1 RTM last night, had issues with my HD 4000 too. It kept re-installing the drivers and then failing on reboot. Back to Windows 8 I went.

corporalgator

19th October 2013, 16:27

It's absurd that 8.1 requires new drivers. I could understand going from one version to another, but .1 is supposed to be an incremental upgrade.

nevcairiel

19th October 2013, 16:38

Just because its named 8.1 doesn't make it any more incremental. The frontend may look quite similar, but in the backend many things changed, especially regarding graphics - which is why 8.1 introduces WDDM 1.3, which needs new drivers to support it, obviously. Using new features needs new drivers.
You don't need "special" 8.1 drivers, thats just something Intel does in this case, NVIDIA for example has one driver for all. However, older WDDM 1.2 drivers from Windows 8 will also work on 8.1, just not make use of the new features. I've been running the test versions of 8.1 on my Intel GPU just fine for a while, before there where dedicated 8.1 drivers.

jkauff

19th October 2013, 18:48

Welcome back, nev. Hope you had a great vacation.

egur

20th October 2013, 12:53

Does anyone else have issues with Windows 8.1?
I personally didn't try it yet.

hoborg

20th October 2013, 18:29

Hi.
I tryed 8.1 x64 RTM and after 3 days my instalation died after restart - only blackscreen with cursor.

Now back to Win 7 x64.

jkauff

21st October 2013, 07:22

Does anyone else have issues with Windows 8.1?
I personally didn't try it yet.
Works in LAV without the "fake" display trick, which is nice. No problems so far.

corporalgator

22nd October 2013, 03:48

The driver posted on the last page for 8.1 says I don't meet the minimum requirements even though I'm running a 2500k.

Edit: nevermind, Intel only released the WDDM 1.3 drivers for HD2500 and 4000+. Anyone know if/when they're going to release it for 3000?

egur

22nd October 2013, 10:07

The SandyBridge drivers (latest are 15.28) do not and probably will never support WDDM 1.3. They will work in Windows 8.1 like they did in windows 8, but not enjoy all the new features of WDDM 1.3.
Note that the bulk of the WDDM 1.3 features are not relevant to media.

CharlieCL

22nd October 2013, 15:13

Quick Sync worked fine with Windows 8.0, the latest LAV and Intel Graphics Driver. When I upgraded to 8.1, the true fullscreen displayed only green screen. In windows mode 8.1 display video fine.

Yups

23rd October 2013, 12:25

It's absurd that 8.1 requires new drivers. I could understand going from one version to another, but .1 is supposed to be an incremental upgrade.

The driver itself supports Windows 7 and Windows 8. Intel restricted it to Windows 8.1 in their official release. It could be that Intel officially stopped supporting Windows 7 and Windows 8 in new drivers series (starting with 15.33). That would be a political decision and typical for Intel. Given that so many users are still on Windows 7 it's inacceptable.

egur

23rd October 2013, 13:00

I've just installed the latest 15.33 on an IvyBridge with Win7 x64.
Didn't run everything, but the few clips I tried played fine.

uncola

11th November 2013, 05:29

quick sync seems broken with intel hd4000 and windows 8.1 using the 3316 drivers the encoding anyway. the decoding may work

egur

11th November 2013, 10:07

Encoding doesn't work at all or works badly?
Did you install the drivers from Intel's website or from another source?

jkauff

12th November 2013, 02:29

quick sync seems broken with intel hd4000 and windows 8.1 using the 3316 drivers the encoding anyway. the decoding may work
Encoding and decoding both work for me with the HD4000 and the 3316 drivers on 8.1. Maybe you need to re-install.

Are you using the HD4000 as your only GPU, or do you also have a discrete GPU? If the latter, you still have to do the "fake display" to get the iGPU to work (at least for encoding; LAV seems to be able to do decoding without it).

uncola

12th November 2013, 05:50

It's an nvidia optimus laptop with an external screen. I use the intel gpu 100% of the time. I installed the drivers direct from intel. I think that fake screen is only for people on desktops who use the discrete gpu as primary. I've tried everything I can think of, installed older win 8 drivers on win 8.1.. I've seen a bunch of other people mention they can't get it working either on 8.1. Is there a good freeware encoder I could try? I've only been using cyberlink power director 12
edit: NEVERMIND figured it out haha. Man, this entire time I Thought I was using the intel gpu for cyberlink powerdirector but it turns out it was running on the nvidia gpu automatically. This is the first time that function actually worked other than for games so I was totally surprised. I just had to right click powerdirector and choose run with gpu - integrated default.

NikosD

13th November 2013, 20:36

Eric,

I tried latest Intel GPA 2013 R3, in order to measure Media performance of QuickSync during playback on my Core i5 Sandy.

I really disappointed once more to find out that nothing has changed from 2013 R2, regarding interference with results.

When you open System Analyzer to measure media performance, the fps drop a lot compared to clean decoding (with GPA closed)

The old GPA with Media Performance as a separate selection (not integrated in System Analyzer) had no such problems.

The performance of QuickSync decoding was the same, with or without GPA monitoring.

Any workarounds ?

wanezhiling

14th November 2013, 16:22

Hi Eric, QS decoding doesn't support MPEG1?

egur

14th November 2013, 17:38

Any workarounds ?
I'm not a power user of this tool. Sorry.

Hi Eric, QS decoding doesn't support MPEG1?
MPEG1 is not supported. Since this legacy format is limited to very low resolutions and bitrate, using HW acceleration wouldn't help much anyway. My guess is that it would work slower than SW if copy back was used (e.g. like QS decoder).

NikosD

15th November 2013, 12:04

I'm not a power user of this tool. Sorry.

OK.
I think the best suitable workaround is to downgrade to the last previous version of Intel GPA, before the integration of Media Performance to System Analyzer.

Is it possible to provide me a download link for that version ?

TIA

egur

16th November 2013, 23:19

I can try, which version are you looking for (version number)?

NikosD

16th November 2013, 23:23

I don't remember exactly.

It's the last version before the integration of Media Performance with System Analyzer.

itsonlyjustincase

20th November 2013, 12:34

If you want to use quick sync try to encode a file with handbrake quick sync version. Try it with or without QS.

egur

20th November 2013, 13:10

The latest Handbrake has QS, you need to enable it from the video tab. You'll need the screen connected to the Intel GPU.

NikosD

21st November 2013, 14:43

egur

21st November 2013, 15:29

Eric,

I'm about to try a new Pentium Haswell dual core processor with QuickSync inside and I'm wondering if it's capable to play in HW 4K H.264 with your QS decoder, or I need to use DXVA native for 4K H.264.

QS Decoder should work, let me know anyway how it performs.
Also works on Atom (Bay Trail) with Window 8.1 (LAV filters+QS).

For YouTube video, flash video and other streaming technologies like Vimeo, DXVA native is the only way.
Right ?
I don't know what they use inside. Could be DXVA2, could be hardware MFTs.

itsonlyjustincase

21st November 2013, 17:00

Can't wait for the result :) but i'm sure it will work flawlessly cause this quick sync is really powerful. I was so impressed by handbrake. I'm also using a soft that permits to record screen while playing games for examples which use quick sync and permit to record without loosing a single fps.

Haswell + Quicksync should definately do it

NikosD

25th November 2013, 23:18

Eric, can you provide me a link for Intel GPA 2013 R1 (13.1) ?

It's the last version of separated Media Performance module.

Thanks.

NikosD

3rd December 2013, 20:04

Well,

today I got my new HTPC (signature system).

It has 8GB of DDR3-1600MHz memory.

I had a few surprises too!

Using latest drivers 3345 under Win 8.1 Pro x64, I have OpenGL 4.2/OpenCL 1.2 and of course QS decoding.

But the performance of QS hardware in both DXVA native and QS decoding is below my expectations.

With H.264 1080p clips, it's close to SNB HD2000 (6 EUs -1100MHz), just a little faster.

It shouldn't, because GT1 of Haswell has a 3rd generation QS hardware capable of 4K H.264 and 10 EUs@1100MHz.

The 4K performance is a lot worst than Ivy 3770K GPU (16 EUs)

In Ducks-3840x2160@50fps I get only 43fps with QS decoding and 80fps with DXVA native.

Those 2 figures (~45fps for QS and ~80fps for DXVAn) seem to be the limit for 4K H.264 clips.

So I can play every 4K@60fps clip but only in native mode, in QS mode I can't even play 4K@50fps.

And some rare 4K@120fps clips are of course unreachable, even in native mode.

Need further investigations and maybe some iGPU overclocking too ;)

egur

4th December 2013, 15:22

The numbers don't look so good.

I played DucksTakeOff (2160p@50) using ZoomPlayer + ffdshow QS and it played rock solid at 50fps. CPU utilization was 55-60%.
This was on my aging IvyBridge Laptop (2.3GHz) with DDR3 1600MHz. This is a 35W mobile CPU.

I'l try later on my Haswell i5 at home.

NikosD

4th December 2013, 18:59

Using MPC-HC v1.7.1.142 (Dec 2) with LAV filters 0.59.1.35 I got 40fps with QS decoding and 60-65% CPU utilization going full@3.2GHz for Ducks-2160p@50fps

The only way to really understand what is going on, is to use Intel GPA Monitor.

So, I installed latest version 2013 R3 and tried to catch GPU, EU and MFX utilization, during playback of MPC - HC but it was zero all the time!

For both DXVA native and QS decoding.

Probably some incompatibility with drivers/ Pentium or something is really weird here.

egur

5th December 2013, 14:25

@NikosD, Are you testing with EVR, EVR-CP, MadVR?
My numbers are with EVR.

Also use CPU-Z to check if your memory is actually working at 1600MHz.

NikosD

5th December 2013, 14:32

EVR always.
Yes memory is working@1600Mhz

I did some new test with DXVA native of LAV Video 0.59.1

For every 4096x2304 clip I get an upper limit of 75fps to 80fps, even for 10Mbps clips or 100Mbps clips

For every 3840x2160 clip I get an upper limit of 85fps to 90fps from low bandwidth to higher bandwidth clips.

QuickSync decoding should be better for Haswell than Ivy, even for my GT1 Haswell, because EUs should not play a significant role in decoding.

What are your figures of Haswell Core i5?

egur

5th December 2013, 15:09

I didn't have time yesterday to check.

NikosD

5th December 2013, 19:09

OK.

In order to have the same reference about decoding performance, I tested under signature system with LAV Video 0.59.1 in DXVA native the famous Ducks 2160p@50fps 370Mbps H.264 file with DXVA Checker v3.0

My results with fps and CPU utilization are in the picture

13900

zcream

8th December 2013, 13:31

I am trying to use QuickSync to encode 2x RAW video streams from USB3 cameras. Project here -
http://www.personal-view.com/talks/discussion/8944/3d-3k-12-bit-raw-camera-project

I don't need P or B- frames. Just need i-frame compression at lossless or near lossless quality. With this requirement, I think a dual 3K stream would be possible onto a fast dedicated SSD.

The best option is to use ffdshow/ffmpeg or an encoder that accepts input from stdin (for virtualdub).

So far, the encoders I have seen only accept a complete input file. Would you consider enabling RAW input from stdin - usage with Virtualdub ? Or alternatively an input using a RAW stream from a DirectShow driver that comes with most Vision cameras ?

egur

8th December 2013, 14:37

zcream

9th December 2013, 07:34

egur

9th December 2013, 08:22

Is this the status with ffdshow (ffmpeg) and Quicksync ATM ?
i.e. 8-bit 4:2:0 decoding only ?
I am not looking for 12-bit, only 8-bit 4:2:2 to begin with, and possibly 10-bit 4:2:2.
There are other encoders, however only virtualdub and ffmpeg support encoding from live USB vision streams. Hence, I was hoping for an encoder that can be offloaded from the CPU.
Cheers!

No support for anything other 4:2:0 8bit.
ATM, the HW supports NV12 surfaces output only.
Sadly, I don't see this change soon, as changing the HW to support more than 8 bit is very expensive and 10/12 is not mainstream.

NikosD

9th December 2013, 09:52

Eric,

any news about HW decoding performance of Haswell vs Ivybridge ?

andyvt

9th December 2013, 10:15

Is this the status with ffdshow (ffmpeg) and Quicksync ATM ?
i.e. 8-bit 4:2:0 decoding only ?
I am not looking for 12-bit, only 8-bit 4:2:2 to begin with, and possibly 10-bit 4:2:2.
There are other encoders, however only virtualdub and ffmpeg support encoding from live USB vision streams. Hence, I was hoping for an encoder that can be offloaded from the CPU.
Cheers!

QSTranscode uses ffmpeg for I/O so it should be possible to support this scenario with some customization. Does your desire to offload outweigh the desire for 4:2:2?

zcream

10th December 2013, 05:40

andyvt

10th December 2013, 10:59

Hi Andy.
I was hoping to capture USB3 vision 4:2:2 Raw video streams in realtime using a DirectShow driver. Hence 4:2:2 is preferred.

Is there a lossless i-frame only mode in QSTranscode that will allow for lower compression but hopefully realtime compression in 4:2:0 ?
I have a core i7 with HD4000 - a mid-2012 Macbook Pro for this project.

Any encoding will be lossy, how lossy will depend on the encoding parameters. I expect that you should be able to do the encoding in real time even at high settings (full transcoding is faster than real time for everything I've tried), but it is something you'd need to test out.

The goppicsize and goprefdist arguments can be used to control the mix of I/P/B-frames. IIRC setting goppicsize = 1 sets the encoder to only create I-frames.

If it is something that you'd like to pursue, LMK and I'll have a look at what it would take to signal to ffmpeg that a device should be the input source.

NikosD

10th December 2013, 18:02

Eric,

a lot of new things about my new Pentium Haswell.

First of all I managed to find Intel GPA 2013 R1 for Sandy, so that link is not necessary.

By reading 2013 R3 help, I realized that the HUD (head-up display metrics proposed by Intel) is using a lot less resources than System Analyzer, but I preferred the old Media Performance tool so I installed again 2013 R1.

2013 R3 has a lot of problems with my Pentium Haswell system because of Win 8.1 (not officially supported - only 8.1 preview) and/ or Haswell GT1 GPU - (4th generation core HD 4200 and above officially supported).

I guess I have to wait for 2013 R4 or 2014 R1 for proper Win 8.1 and/ or Haswell GT1 support.

I did some tests regarding 1080p decoding performance between QS1 (Sandy - GT1) vs QS3 (Haswell - GT1).

In normal bandwidth clips and easier codecs, like H.264<30Mbps or MPEG-2 1080p clips, QS3(Haswell) is a little slower!! than QS1(Sandy)

But H.264 1080p clips around 100Mbps are decoded a lot faster on QS3 than QS1, about 2x or even 2.4x times faster.

I found out one major difference that Intel silently has changed between QS generations.

Haswell QS3 supports a new VC-1 mode called (VC1_VLD2010) which is used by both LAV Video and WMVideo MFT decoders

LAV has some problems, but on progressive video WMVideo is perfect for VC-1/WMV3 clips.
PotPlayer supports VC-1/WMV3 in DXVA native too (no problems)

Still, interlaced video can't be decoded properly.

I'm really looking forward for an answer about IvyBridge vs Haswell performance comparison especially in 4K H.264 clips.

I have to know if it's my Pentium Haswell QS slower than Ivy or every Haswell QS is slower than any Ivy.

thanks.

zcream

10th December 2013, 23:39

I am going to test this as soon as I get my laptop.
ATM, ffmpeg can record from USB cameras.
https://trac.ffmpeg.org/wiki/DirectShow

If I can use the ffmpeg cli and pass the ffmpeg raw stream to QSTranscode it should be fine.

I am very curious to see if there are any noticeable differences in Cineform 4:2:2 vs h.264 4:2:0 at a high enough bitrate.

Any encoding will be lossy, how lossy will depend on the encoding parameters. I expect that you should be able to do the encoding in real time even at high settings (full transcoding is faster than real time for everything I've tried), but it is something you'd need to test out.

The goppicsize and goprefdist arguments can be used to control the mix of I/P/B-frames. IIRC setting goppicsize = 1 sets the encoder to only create I-frames.

If it is something that you'd like to pursue, LMK and I'll have a look at what it would take to signal to ffmpeg that a device should be the input source.

CharlieCL

12th December 2013, 03:03

a lot of new things about my new Pentium Haswell.
......

Pentium Haswell hardware may be a crapped Haswell vs Core i in graphics.

wanezhiling

12th December 2013, 07:02

Apparently GT1 (HD Graphics) is not on the same level with GT2 (HD Graphics 4200/4400/4600), the worse is that it may worse than IVB GT2 (HD Graphics 2500/4000).

NikosD

12th December 2013, 10:09

Pentium Haswell hardware may be a crapped Haswell vs Core i in graphics.

I couldn't disagree more with that statement.
Read below.

Apparently GT1 (HD Graphics) is not on the same level with GT2 (HD Graphics 4200/4400/4600), the worse is that it may worse than IVB GT2 (HD Graphics 2500/4000).

First of all we are talking here about media performance, not graphics performance.

Media performance is based on QuickSync hardware (ASIC) which is inside GPU and the number of EUs (graphics performance) doesn't play a significant role in hardware decoding.

Anandtech here http://www.anandtech.com/show/5871/intel-core-i5-3470-review-hd-2500-graphics-tested/2 has exactly the opposite opinion than me, saying that transcoding is based a lot on number of EUs, but never mind, Anandtech is wrong and I'm right! ;)

The number of EUs play a significant role for scaling and other post processing video features, but in decoding the role of EUs is not significant. Sure they assist, but main decoding is done by MFX engine.

So QS decoding should be on par between same generation QS hardware (HD 2000 vs HD 3000), (HD 2500 vs HD 4000), Haswell GT1, GT2 etc and not influenced by the number of EUs which shows us mainly graphics and not media performance.

But, talking about Pentium Haswell GPU in general, we have to say that even graphics performance has raised significantly compared to previous generations.

For example GT1 of SandyBridge (HD 2000) and GT1 of IvyBridge (HD 2500) have both 6 EUs, where GT1 of Haswell has 10 EUs.

In real world apps and benchmarks I saw a 2.5x increase in DX10 and OpenGL performance between GT1 -HD 2000 (sandy) and my Haswell GT1, for example Cinebench OpenGL mark and a DX10 benchmark.

So Haswell GT1 is certainly faster than GT1 - HD 2500 (Ivy) and probably faster even than GT2 -HD 3000 (Sandy) and close to GT2- HD 4000 (Ivy).

The equation goes like this regarding graphics performance:

HD 2000 < HD 2500 < HD 3000 < Haswell GT1 < HD 4000

But our talk here is about HW H.264 decoding performance of GT1 Haswell compared to GT2, GT3 Haswell and GT1, GT2 performance of Ivy.

nevcairiel

12th December 2013, 11:00

Anandtech here http://www.anandtech.com/show/5871/intel-core-i5-3470-review-hd-2500-graphics-tested/2 has exactly the opposite opinion than me, saying that transcoding is based a lot on number of EUs, but never mind, Anandtech is wrong and I'm right! ;)

Transcoding is a lot more then plain decoding. EUs play a role in encoding and the processing required for that.

Anyhow, the Pentium "Intel HD Graphics" is also limited in media features. It doesn't have QuickSync for example (the encoder), which could also be a sign that its a completely different media block, and does not share the same decoder as the other Haswell GPUs. Its very well possible that it behaves differently in decoding performance then the Core i3/i5/i7 would, and until someone does a clear 1:1 comparison, noone can know for sure.

Fact is, you are just assuming its the same hardware. What if its not?

NikosD

12th December 2013, 11:09

kypec

12th December 2013, 11:51

The best to way to find out is to run with your system (I know you have a Core i7 4770K ;) ) some H.264 benchmarks (1080p & 4K) to compare them with mine.

It would be a straight comparison between GT1 vs GT2 Haswell media decoding performance.
Please do that comparison test, I'm about to buy Pentium G3420 soon and need to be sure that H.264 decoding capabilities for 1080p (and possibly 4K as well) material are not crippled in this Haswell CPU. :thanks:

egur

12th December 2013, 19:52

Transcoding is a lot more then plain decoding. EUs play a role in encoding and the processing required for that.
Yes, a minor role.

Fact is, you are just assuming its the same hardware. What if its not?
It's the same HW (design wise). Same media block. Lowest binned silicon (leakage & frequency, but still reliable), much smaller L3 cache, 2 cores, no HT, no turbo and some other features turned off compared to i3/i5/i7.

NikosD

12th December 2013, 20:23

Please do that comparison test, I'm about to buy Pentium G3420 soon and need to be sure that H.264 decoding capabilities for 1080p (and possibly 4K as well) material are not crippled in this Haswell CPU. :thanks:

The decoding capabilities of Pentium G3420 are amazing.

With signature system and clips from my thread I got these results with LAV Video 0.59.1 DXVA native:

2. 298/303/313
6. 288/295/299
7. 264/265/265
10. -/240/-

For 4K H.264 I got:

Ducks 2160p30fps-243Mbps 72/75/77
Park Joy 2160p50fps - 136Mbps 77/79/79
Duck 2160p50fps - 370Mbps 73/78/80

CharlieCL

12th December 2013, 21:54

Your testing is not a pure decoding testing. There are render and fps. The bandwidth and memory performance as well as EU are factors. In Intel's official specification Pentium G3420 does not support Quick Sync Video. In word meaning that included both encoder and decoder.

egur

13th December 2013, 17:33

That's correct, rendering and video processing uses the EUs at some level.

NikosD

13th December 2013, 18:01

kypec

13th December 2013, 22:33

The decoding capabilities of Pentium G3420 are amazing.
Thank you very much for your input, NikosD, much appreciated!
Now, I can't wait to get that new rig in my room. This is gonna be one nice Christmas after all...:D

NikosD

14th December 2013, 20:24

Eric,

I found out that QS decoder suffers from the same limitations that DXVA copy-back suffers too.

It can't go up to 4K x 4K resolution for H.264 without blurring (artifacts).
I tried even some 3K x 3K and had problems too.

They aren't the most common resolutions of the planet, but it surprised me that only DXVA native can play such resolutions perfect.

DXVA copy-back doesn't even initialize - it falls back to software mode with LAV Video.

egur

15th December 2013, 08:38

@NikosD, Interesting, please share the clips.

NikosD

15th December 2013, 08:45

The clips have been downloaded from your collection of DXVA limited clips with various resolutions of square, macroblocks, height or width limitations.
There are many of them.

If you don't have them anymore, tell me to upload one or two.

egur

15th December 2013, 08:57

I don't have those. Just share 1 of each resolution.

NikosD

15th December 2013, 09:02

OK.

But because you have both an IvyBridge and a Haswell processor, I want from you a comparison of H.264 decoding performance in DXVA native for selected clips of 1080p and 4K resolutions :)

Do we have a deal ? :D

egur

15th December 2013, 09:10

I'm not committing to anything these days. A lot of work issues. But I'll give it a try.
BTW, Intel® Graphics Performance Analyzers 2013 R4 is out.

NikosD

15th December 2013, 09:17

I tried Intel GPA 2013 R4 on my system but nothing changed.

Still, media performance metrics (which have raised from only 3 to 11!) show me null values during playback.

Also I have a lot of hang-ups of OS while using 2013 R4.

Maybe Pentium G3000 series is still not compatible with that program.

Anyway a typical sample of a square sample with image distortion using QS decoder is here:
http://speedy.sh/Tm7BR/4080x4080-VP5.mkv

BTW, do you know why SandyBridge latest driver for HD2000 ver 3347 doesn't have VC1_VLD2010 support like Haswell ?

Are they going to add it in future driver releases ?

egur

15th December 2013, 09:22

SandyBridge drivers are feature-frozen, only serious bug fixes from now on.

NikosD

15th December 2013, 09:26

In only 2 years support ?

That's a pity...

They should have put it along with Haswell drivers or Ivy.

I don't know when exactly they added VC1_VLD2010 support.

zcream

16th December 2013, 14:10

Is 10-bit 4:2:2 YUY2 still unsupported within Quicksync ?

From the Intel Media SDK forums -
http://software.intel.com/en-us/forums/topic/328273

Media SDK supports YUV format NV12 (this is 4:2:0) natively. The SDK also supports 2 additional YUV formats: YV12 (this is 4:2:0) and YUY2 (this is 4:2:2). To use format YV12 or YUY2 a developer must first use VPP to convert format to NV12 before feeding the input frames to encoder.

- It supports the same formats as DXVA, so only 8-bit 4:2:0 (MPEG2, H264 and VC1)
- H264 High profile, no 10-bit or 4:2:2/4:4:4
- See above, only 8-bit. Output is always NV12.

egur

16th December 2013, 14:27

VPP can be used to convert from YUY2/YV12 to NV12, but that's it. No 10 bit support no 4:2:2 encoding or decoding and my guess, is that VPP operations occur after conversion to NV12.

andyvt

17th December 2013, 21:43

zcream

18th December 2013, 08:32

Cool. I'm going to buy a laptop with hd4000 or higher and then test it.

In Haswell, there is a MJPEG decoder but no encoder. Is your MJPEG encoding then done in software ?

andyvt

18th December 2013, 11:13

Cool. I'm going to buy a laptop with hd4000 or higher and then test it.

In Haswell, there is a MJPEG decoder but no encoder. Is your MJPEG encoding then done in software ?

All video encoding is done by the MSDK, IIRC MJPEG encoding is SW based with HSW.

NikosD

22nd December 2013, 23:34

Eric,

is it possible to accelerate in QS3 HW this clip ?
bbb_sunflower_2160p (http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_2160p_30fps_stereo_abl.mp4)

It is a 3D clip (top-bottom) 3840x2160x2=4320

egur

23rd December 2013, 08:29

ryrynz

2nd January 2014, 02:53

I have visual corruption at the bottom of the screen 9 seconds in with this sample (http://www.sendspace.com/file/h20f5q), happens on my 2600K with 15.28.20.64.3347 drivers on Windows 8.1 x64, but not with my 3570K using 15.33.8.64.3345.
I had this video freeze after this occured a few times (audio playback was uninterrupted with no response from MadVR using Ctrl-J) yet MPC-BE was fully operational.

Not sure if that's related but I hope so as I usually have no issues.

egur

3rd January 2014, 20:01

ryrynz

4th January 2014, 05:58

Glad to see it duplicated.

The freeze occured about an hour or so into the video this sample was taken from, if the error gets fixed I can retest the video, thanks.

egur

5th January 2014, 22:34

Here's a nice article in Anandtech (http://www.anandtech.com/show/7566/intels-haswell-nuc-d54250wyk-ucff-pc-review) on the new Haswell NUC.

Racer

7th January 2014, 20:08

Did anybody try to use this FFDShow decoder supporting QuickSync for frame-serving to x264. Is this actually possible? Because then decoding could be done by hardware and encoding by software.

egur

8th January 2014, 08:22

QuickSync can be used in FFDShow everywhere. If not, let me know.

The benefits are visible when high bitrate source clips are used or if you want to enable QS's video processing (e.g. deinterlacing, noise reduction).

TEB

19th January 2014, 11:04

Ho. This question has prolly been asked before, but does anyone know if Broadwell's Quicksync implementation will support H.265?

br TE

wanezhiling

19th January 2014, 14:47

I hope that Broadwell supports H.264 SVC, H.265, VP9. :D

btw Broadwell will not be used on desktop?

GTPVHD

19th January 2014, 22:45

http://www.cpu-world.com/news_2013/2013112001_Broadwell-K_socket_1150_CPUs_to_feature_GT3_graphics.html

There will be Socket 1150 Broadwell desktop chips.

skryabin

24th January 2014, 02:07

Does the fake monitor trick work anymore in 8.1?
When I click detect nothing happens, no vga monitors detection, so I can't extend the desktop and use quicksync.
It worked fine on windows 8.

EDIT: maybe I got it working again, reinstalled the drivers.

egur

25th January 2014, 22:00

The fake screen trick still works for me.

Deihmos

26th January 2014, 05:01

Is there any difference between ffdshow supplied by the developer and the tryouts version?

ryrynz

26th January 2014, 05:21

Is there any difference between ffdshow supplied by the developer and the tryouts version?

No, grab which ever version is the latest or suits your needs.

egur

26th January 2014, 08:10

My builds are taken from ffdshow-tryouts source code so they are the same. Since my last build, there wasn't anything new to add so I didn't release anything...

Near Broadwell launch I'll add some new stuff or before if I can find a workaround for broken clips.

Stereodude

1st February 2014, 14:04

Eric, can you take a look why the Intel QuickSync HW decoder gives choppy video playback with this sample .vob file (http://www.sendspace.com/file/b1pxf5)? FWIW, this is not some odd corner case I found. I've found that the QuickSync HW decoder can't smoothly decode a lot of MPEG-2 DVD content (played directly from the disc with the MS DVD navigator or from an extraced .vob file using the LAV splitter).

Here are the relevant details:
madVR tells me the renderer isn't dropping any frames so the stutter has to be in the decoder.
I'm using a i7-4770k with the latest 10.18.10.3345 drivers
An i5-4300U with slightly older 9.18.10.3324 drivers does the same thing
Windows 7 x64 on both systems
MPC-HC 1.7.1 or 1.7.2 w/ internal LAV filters
DXVA2 (native), DXVA2 (copy-back), CUVID, and SW decoding in LAV work fine
Extracting the audio and video streams from the .vob and putting them in a .mkv will play back fine decoded with QuickSync
nevcairiel says the decoder is misbehaving, not LAV

egur

1st February 2014, 20:00

I've managed to reproduce the bug. It didn't happen in my 3:2 soft telecine content...

As a quick fix, use either LAV video decoder or disable the time stamp correction within fddshow config->Intel QuickSync

I'll create a version after some more testing.

nevcairiel

1st February 2014, 20:09

It doesn't work properly in LAV either when the QS decoder is used, although it has a different bug.

Stereodude

1st February 2014, 20:22

egur

2nd February 2014, 11:41

I'll test with LAV too before posting a fix.

Deihmos

2nd February 2014, 22:26

Is it possible to disable auto loading of external subtitles in ffdshow? The ffdshow development is now dead and no one responds.

egur

3rd February 2014, 12:59

Is it possible to disable auto loading of external subtitles in ffdshow? The ffdshow development is now dead and no one responds.

Not using ffdshow for subs, but there's an option in config->subtitles: "Subtitle files". Doesn't unchecking this remove auto loading? Also, the player may force ffdshow to load the subs.

RealSnoopyDog

3rd February 2014, 13:09

Since i updated my PCs from Windows 7 to Windows 8.1, i get blurred and choppy playback of VC1 encoded full hd content with the quicksync decoder in the LAV filters. When i use software decoding or DXVA2, the playback is good again.

I tested several Intel drivers already, the "newest" one that windows 8.1 installs automatically (newer than the last offical release on the Intel homepage), the latest official from Intel and some olders.

I have CPUs with HD4000 graphics atm.

Is this a known issue with the windows 8.1 drivers or am i the only one getting this?

wanezhiling

3rd February 2014, 13:35

Post sample file which explains everything.

RealSnoopyDog

3rd February 2014, 15:08

Happens with every full HD VC1 encoded material that i have.

egur

4th February 2014, 09:16

@Stereodude - can you upload the file again? The link is not working.

Stereodude

4th February 2014, 13:31

@Stereodude - can you upload the file again? The link is not working.I deleted the file because I figured you had saved it and I didn't need it online any longer. Here it is again (http://www.sendspace.com/file/jquzwx).

Edit: Let me know when you've downloaded it because I plan to delete it again.

egur

4th February 2014, 16:02

My fix seems to work for ffdshow but not well for LAV. I'll do this offline with nevcairiel.

Using SW deinterlacing, everything is blurry and jumpy - looks like the DI is not handling 3:2 well or maybe the odd/even flags are wrong. When using HW DI (in my decoder), the frames are sharp but playback has tons of jitter - non smooth motion. The latter suggests time stamp issues.

Why this is happening:
In ffdshow, when QS decoder reports a film sequence, it will override the time stamps and use 1/23.976 second difference between frames and also clear the frame flags for the renderer. The original stamps of 3:2 clips is always for 29.97fps.

Also in ffdshow, the default behavior of QS decoder is to modify the time stamps.

Stereodude

4th February 2014, 19:29

I assume the sample I provided is soft telecined. Doesn't that mean the QS decoder should apply a telecine to the content instead of passing progressive frames? Is it valid for a decoder to ignore the flagging and pass progressive frames?

Personally, I'd rather get progressive 24p output instead of telecined output that then gets IVTC'd by either the video card drivers or madVR's routines as the latter is just a waste of GPU/CPU resources to pointlessly telecine and then IVTC it. However, I don't have a clue if that's a valid action for a mpeg-2 decoder to take, or QS has a way to negotiate skipping the soft telecine that with the application / filter using it.

egur

4th February 2014, 19:36

QS decoder has 2 modes:
1) Time stamp manipulation on (default for ffdshow, configurable): soft 3:2 are used and output is progressive frames at 23.975 (3:2).
2) TS manipulation is off (hardcoded in LAV), decoder outputs frames as interlaced but they are marked to have repeated fields. LAV decoder should do the soft telecine and change the timestamps to the new frame rate.

This behavior is something I fixed in ffdshow itself more than a year ago.

Stereodude

4th February 2014, 20:02

Mode 1 sounds more desirable to me. I wonder why does LAV not allow it...

nevcairiel

4th February 2014, 20:22

No, 1) is not more desirable. It may sound like that, but its really not. You lose information, which the video renderer can use to make better decisions how to handle the video.

Besides, the goal is to have all decoders in LAV behave similar, so QuickSync doesn't get any special modes that mock with data. LAV is not ffdshow.

The problem LAV has is that the QS decoder does not behave sanely on this stream, it does not pass-through the timestamps 1:1 like it should. The input stream barely has any timestamps, and the QS decoder "invents" new 30 fps timestamps, which are clearly wrong - despite me telling it not to do anything with the time!

Stereodude

4th February 2014, 21:04

Oh... Well, I'll let you two fight it out. :)

egur

4th February 2014, 21:08

No fighting, we're all on the same page :).
Could be my bug. Need more checks.

nevcairiel

4th February 2014, 21:50

Might also be in Intels code, who knows. All i know is that i give it certain timestamps, and get others back out. :)

CharlieCL

5th February 2014, 00:40

Deihmos

5th February 2014, 05:03

Not using ffdshow for subs, but there's an option in config->subtitles: "Subtitle files". Doesn't unchecking this remove auto loading? Also, the player may force ffdshow to load the subs.

That disables it completely. I was hoping for an option to not load them if the audio language is english.

egur

5th February 2014, 08:19

When the hardware of Quick Sync Decoder was called I guess many driver instructions need to be executed along with memory bandwidth, this will slow down the QS decoder. In software decoder if SSE4 or AVX was implemented right, is it possible faster than hardware QS decoder in high end Core i processors?

The HW decoder is significantly faster than all SW decoders. When copying frames back to system memory performance is lost. In low bitrate clips SW will end up being faster but on medium-high, HW will be faster. FYI, SSE4 isn't an improvement to SSE1/2/3, it's an additional set of instructions that use the same SSE registers.

That disables it completely. I was hoping for an option to not load them if the audio language is english.
I think this sort of logic should be part of the player, not the decoder. Just my 2 cents. You can always delete/rename the subtitle file before seeing the video. That's what I do.

egur

5th February 2014, 16:04

@Stereodude:
I've found a very low level bug that caused this. Very strange it didn't surface before. A few more tests and I'll release ffdshow.
LAV filters got the update too, so the next LAV release should be good.

If you have more issues, don't be shy. My test material is finite...

Stereodude

6th February 2014, 00:43

CharlieCL

6th February 2014, 04:55

The HW decoder is significantly faster than all SW decoders. When copying frames back to system memory performance is lost. In low bitrate clips SW will end up being faster but on medium-high, HW will be faster. FYI, SSE4 isn't an improvement to SSE1/2/3, it's an additional set of instructions that use the same SSE registers.

SSE/AVX is like DSP in 256/512bit with 3GHz in CPU. The ASIC decoder may have run only in 1GHz. I can not see why SW decoder can not be faster. Maybe SSE/AVX is poor in architecture or maybe software implementation is poor.

Anyway I am disappoint on the performance of SSE/AVX.

egur

6th February 2014, 10:31

SSE/AVX is like DSP in 256/512bit with 3GHz in CPU. The ASIC decoder may have run only in 1GHz. I can not see why SW decoder can not be faster. Maybe SSE/AVX is poor in architecture or maybe software implementation is poor.

Anyway I am disappoint on the performance of SSE/AVX.

I'll give you a high level example how things work. Let's say the HW needs to perform inverse DCT of 8x8 blocks on many blocks. Blocks are located sequentially in memory (for simplicity of example).

ASIC (dedicated HW circuit a.k.a fixed function):
* Entire IDCT algorithm is implemented as a circuit. Input is a matrix/vector, and so is the output.
* Every adder, multiplier and other logic in the circuit is not shared. e.g. if the algorithm has 64 multiplications, 64 different multipliers will exist in the circuit.
* The circuit can read new inputs at every clock.
* The circuit can output new data at every clock.
* The circuit has a fixed delay D (clock ticks between input and output). D is usually very small. For IDCT it's <10.
* Work time for performing IDCT on N DCT blocks is N+D, not N*D.
* If higher performance is needed, the circuit can be duplicated. This will give 2 IDCTs per clock. The cost is silicon area ($$$).
* The circuit can do just one algorithm/function.

SSE/AVX/DSP:
* CPU decodes instructions and/or fetches input data every clock.
* Logic resources are shared between stages of the algorithm. e.g. if the algorithm has 64 multiplications, there will be a small number of (vector) multipliers.
* Blocks are processed one at a time. With a delay of D2. Usually larger than the delay of the ASIC implementation.
* Time for performing N tasks is N*D2. Much larger than N+D.
* HW is much more generic, can performs millions of functions.

I hope this is clearer.

Why use ASIC? high performance for known and unchanging algorithms.
Why use DSP? Flexibility, ability to fix bugs or optimize after production, sometimes cheaper HW.

NikosD

6th February 2014, 13:59

Nice post Eric.

Very clear, short and accurate.

I could only add the efficiency/power as an added reason for implementing and using something in HW (ASIC) than SW (CPU)

Stereodude

6th February 2014, 17:00

CharlieCL

6th February 2014, 20:50

CharlieCL

6th February 2014, 20:55

I'll give you a high level example how things work. Let's say the HW needs to perform inverse DCT of 8x8 blocks on many blocks. Blocks are located sequentially in memory (for simplicity of example).

....

An IDCT can be done in one clock? At least I see the performance limitation of ASIC codec on discrete GPU card because of the data transfer through PCIe.

NikosD

7th February 2014, 09:11

I can't believe you just asked why specialized hardware is faster than general purpose hardware doing things in software. :scared:

Good question. In a mobile phone case (ARM) a software codec of JPEG by using DSP is faster than hardware codec.

In principle, in theory, in general, ASIC (HW) should and could be faster than DSP or CPU (SW).

But in reality, in real world implementations, if we see HW performance from the first fixed-function HW in 2006 like UVD from ATI and VP2 from Nvidia up to 2011, before QuickSync from Intel, then HW was not faster than SW.

Almost every Quad-core CPU SW decoder, is faster than any AMD UVDx or Nvidia VPx fixed-function HW.

So in real world, we can say the opposite is truth for HW vs SW performance.

SW is faster than HW.

Except QuickSync ASIC of course, which is faster than any Quad core CPU.

You can check my signature for further performance details in the Excel spreadsheet, between SW and HW generations.

egur

7th February 2014, 09:16

An IDCT can be done in one clock? At least I see the performance limitation of ASIC codec on discrete GPU card because of the data transfer through PCIe.

Think of the HW as a pipeline with several stages. Stage 1 is the input and stage K is the output. On every clock, new data is fed to the inputs. after K clocks, the first output is ready. After K+1 clocks, the 2nd data is ready, etc.
So after N+K clocks, N+K clock ticks, N tasks are ready.

If you have a GPU with massive parallelism and a high clock frequency, it might be possible to do the same task faster but take much more power.

Power difference can be >1000x, depending on how the ASIC and surrounding HW blocks are implemented.

A hybrid ASIC + GPU-cores style implementation as done in the iGPU is a compromised approach.

A full ASIC video pipeline as done in TVs is much more efficient (power) but also can't be upgraded so it's not used in the PC world.

Stereodude

7th February 2014, 14:06

In principle, in theory, in general, ASIC (HW) should and could be faster than DSP or CPU (SW).

But in reality, in real world implementations, if we see HW performance from the first fixed-function HW in 2006 like UVD from ATI and VP2 from Nvidia up to 2011, before QuickSync from Intel, then HW was not faster than SW.

Almost every Quad-core CPU SW decoder, is faster than any AMD UVDx or Nvidia VPx fixed-function HW.

So in real world, we can say the opposite is truth for HW vs SW performance.

SW is faster than HW.

Except QuickSync ASIC of course, which is faster than any Quad core CPU.

You can check my signature for further performance details in the Excel spreadsheet, between SW and HW generations.It seems like you're intentionally missing the point. The HW decoders you're complaining about being slower than SW only need to run real time for playback. So they weren't designed to run at 10x real time or faster as that would be a waste of silicon and or power. Further, even though SW decoders might be faster in terms of raw frame rate (if you're only decoding) you saturate the CPU. I still get faster x264 encoding using veryslow when I use DGDecNV for decoding than if I were to use FFMpegSource with software decoding because I'm not wasting CPU resources decoding the video. QuickSync is a very different animal because it wasn't designed only to provide HW decode for playback, but to do rapid decode/encode.

NikosD

7th February 2014, 14:39

It seems like you're intentionally missing the point.

It seems you're unintentionally missing the point.

UVD, UVD+, UVD2.0, UVD2.2, UVD3 etc are not fast enough to decode 1080p60fps H.264 files, like for example AVCHD files from camcorders.

It is a very well known limitation.

And of course they can't decode 4K H.264 at all.

VPx except VP5 can't decode huge bitrate 1080p H.264 files, they can't even reach 24fps.

Of course they can't decode 4K H.264 too.

Finally VP5 can go up to 27-29 fps max at 4K H.264 files, not enough for flawless 4K@30 fps and of course it is far away from 4K@60 fps or 4K@120 fps that QuickSync can do.

I hope it is clearer now that ALL HW mentioned before, have trouble decoding in realtime this or that file.

CharlieCL

7th February 2014, 15:51

Think of the HW as a pipeline with several stages. Stage 1 is the input and stage K is the output. On every clock, new data is fed to the inputs. after K clocks, the first output is ready. After K+1 clocks, the 2nd data is ready, etc.
So after N+K clocks, N+K clock ticks, N tasks are ready.

If you have a GPU with massive parallelism and a high clock frequency, it might be possible to do the same task faster but take much more power.

Power difference can be >1000x, depending on how the ASIC and surrounding HW blocks are implemented.

A hybrid ASIC + GPU-cores style implementation as done in the iGPU is a compromised approach.

A full ASIC video pipeline as done in TVs is much more efficient (power) but also can't be upgraded so it's not used in the PC world.

So in average the pipeline is one clock output. SW codec can be constructed in this kind of pipeline by threads in multi-core but performance may be poor. When CPU is running in 100% usage everything will be slow. And power usage will be high.

Stereodude

7th February 2014, 17:02

It seems you're unintentionally missing the point.

UVD, UVD+, UVD2.0, UVD2.2, UVD3 etc are not fast enough to decode 1080p60fps H.264 files, like for example AVCHD files from camcorders.

It is a very well known limitation.

And of course they can't decode 4K H.264 at all.

VPx except VP5 can't decode huge bitrate 1080p H.264 files, they can't even reach 24fps.

Of course they can't decode 4K H.264 too.

Finally VP5 can go up to 27-29 fps max at 4K H.264 files, not enough for flawless 4K@30 fps and of course it is far away from 4K@60 fps or 4K@120 fps that QuickSync can do.

I hope it is clearer now that ALL HW mentioned before, have trouble decoding in realtime this or that file.So you're complaining that HW decoders don't work outside the use cases they were designed to handle. No surprise there... I'm well aware that the QuickSync engine is quite a bit more capable and faster than the hardware decode engines found on video cards. It was designed with a different objective in mind and the performance bears that out. It shouldn't be surprising that a well designed hardware decoding engine that's intended to accelerate decoding & encoding is much faster than software routines, or older hardware that's strictly targeted for real time playback of certain content.

NikosD

7th February 2014, 18:14

So you're complaining that HW decoders don't work outside the use cases they were designed to handle.

I'm not complaining for anything.

I just gave you the proofs that SW decoders are faster than HW decoders in all cases besides QuickSync and that HW decoders can't keep up for sure with anything but clips inside BluRay specs.

egur

8th February 2014, 00:06

Stereodude

8th February 2014, 00:55

NikosD

8th February 2014, 07:52

Most (all?) of Nvidia's and AMD's decoding HW solutions were based on heavily using their GPU cores and less on fixed function HW. Those GPUs had much faster (and wider) memory using much more power and still couldn't compete in speed.

It all depends on the implementation details. How much is fixed function and how much is programmable.

Actually no.

I didn't choose accidentally the year 2006.

It was then, the year of Blu Ray that most CPUs couldn't keep up with the resolution, H.264 complexity and huge bitrate of BluRay movies and Nvidia first with VP2 and then ATI with UVD, decided to use fixed-function HW for the whole H.264 pipeline (VLD decoding) - the VP2 case - and H.264 & VC-1 VLD decoding for UVD.

Before VP2 and UVD at 2006, it is true that both companies were using programmable GPU resources to accelerate MPEG-2, WMV and H.264 for partial acceleration - no VLD decoding.

Actually even UVD and UVD+ were using shaders for MPEG-2 codec, but not for H.264 and VC-1 - they used fixed-function HW for both of them.

Blu-Ray brought us fixed-function HW and VLD decoding for H.264&VC-1.

egur

10th February 2014, 04:04

Stereodude

10th February 2014, 05:15

wanezhiling

10th February 2014, 05:21

Because fast decoding speed can make a fast seeking speed.

NikosD

10th February 2014, 08:28

As far as I know they didn't use ASIC for all the decoding components, otherwise why they are slower? They ran at about the same clock frequency, have much faster dedicated memory, they don't share the L3 cache with the CPU and have tons of thermal headroom.
Copying the compressed bitstream over PCIe isn't slow so I don't see any reason except:
1) They don't have ASIC for everything.
2) The drivers are highly inefficient (less likely).

Nvidia and especially ATI, preferred to stick to the BluRay specs and they decided to go up to realtime performance.
So the maximum performance was a dual stream of 1080p30 fps H.264 for PIP.

Only for VP5 Nvidia decided to build something out of BluRay specs and support 4K@24 fps, the maximum HDMI v1.4 output

About clocks and die area.
The clock of UVD2.2 is 400 MHz, when Intel GT1 goes up to 1100MHz.

The die area of first UVD fixed-function decoder was so big, that ATI was forced to remove it from the fastest card HD 2900, because 2900 had the largest number of GPU cores and it didn't have room for UVD!

The same thing happened with Nvidia and VP5, which appeared for the first time in Fermi architecture (Series 500), but only GT520 got it because it had the minimum number of GPU cores from all 500 series cards.

About Intel.
Intel didn't make a video decoder, but a video transcoder.
The purpose was not just "play movies", but build the fastest transcoder, which means faster decoder and encoder at the same time.

Intel decided to go far away from real time performance, because they wanted to decode as fast as possible and to encode as fast as possible at the same time, in order to minimize the transcoding time.

If you see the renderless speed of QuickSync in my Excel, you will be astonished by the performance advantage over the other HW and SW decoders.

That's why they didn't stick to Bluray specs and "accidentally" built the fastest video decoder of all, QuickSync, which is good for us who just decode movies and various other clips.

Stereodude

10th February 2014, 14:53

About Intel.
Intel didn't make a video decoder, but a video transcoder.
The purpose was not just "play movies", but build the fastest transcoder, which means faster decoder and encoder at the same time.

Intel decided to go far away from real time performance, because they wanted to decode as fast as possible and to encode as fast as possible at the same time, in order to minimize the transcoding time.

If you see the renderless speed of QuickSync in my Excel, you will be astonished by the performance advantage over the other HW and SW decoders.

That's why they didn't stick to Bluray specs and "accidentally" built the fastest video decoder of all, QuickSync, which is good for us who just decode movies and various other clips.The irony of you "explaining" QuickSync to an Intel employee who has been busy working with it firsthand isn't lost on me, nor is your use of the exact same argument I used on why CharlieCL shouldn't be surprised that the QS HW "decoder" is so much faster than software (that you criticized me for).

NikosD

10th February 2014, 15:12

The irony of you "explaining" QuickSync to an Intel employee who has been busy working with it firsthand isn't lost on me, nor is your use of the exact same argument I used on why CharlieCL shouldn't be surprised that the QS HW "decoder" is so much faster than software (that you criticized me for).

I don't explain explicitly things to anyone.
I take the opportunity to explain issues in general and with my perspective.

Eric is an Intel employee but he is not obliged to know everything about HW decoding of ATI and Nvidia.

So you are misleading with your post by putting my post with the Intel explanation only, when it is more than obvious that the explanation about Intel was not written alone but in contrast with ATI and Nvidia practice on this specific matter.

About CharlieCL and QS HW, I explained in details why he should be surprised by the performance of QS decoder judging by the previous approaches on the issue from ATi and Nvidia and the performance of HW decoders like UVDx and VPx that were common practice for years and Eric wrote in short but accurately why he shouldn't be surprised when the approach is different.

I can't understand what is your problem with me, besides some points I commented on your posts to enlighten the issues, which obviously made you nervous and aggressive.

Take it easy...

CharlieCL

10th February 2014, 20:26

Both NVIDIA and AMD used hardware codec in their graphics chips and APU now. They have found that GPU was not suitable for codecs.

Current hardware codec is put in wrong position - in the side of GPU with driver. It should be put in the side of CPU like FPU. Codec is executed in CPU not in GPU.

AVX2 is 512-bit so it can execute 16 32-bit multiplexer. Some DSP has 1024-bit. The improvement of SW algorithm should not be far away from HW.

At present SW codec can not play 4K video but HW codec can do it easily in X86. There may have something wrong in software implementation.

nevcairiel

10th February 2014, 20:36

AVX2 is 512-bit

Wrong, AVX2 is 256-bit.
You also need data which is suited for such processing. Not every algorithm can be made magically faster with AVX, some processing just doesn't benefit from SIMD operations.

At present SW codec can not play 4K video but HW codec can do it easily in X86. There may have something wrong in software implementation.

There is nothing wrong in the software, thats just how it is. The decoding complexity increases quite a lot from 1080p to 4K.
There is 4 times the pixels to handle, and a higher bitrate to process. Higher bitrates cause the bitstream parsers to need much more time, especially the entropy decoding (CABAC) in H264 is rather slow and cannot be implemented with SIMD instructions (SSE/AVX), but only "normal" instructions. Bitrate plays a huge role in the speed of a software decoder (unlike hardware decoders, where the impact from bitrate is much smaller).

H264 was primarily designed for HD, not UHD. You notice this in the UHD decoding performance, it doesn't scale properly. Its not a software problem as such, but a limitation of the format.

Even a HEVC decoder in its early stages (meaning not very optimized yet) can be as fast or even faster than a highly optimized H264 decoder on UHD content, just because the format is more suited for it. Bitrate is lower, processing algorithms are better suited and more efficient at higher resolutions.

PS:
All of this applies to software decoders, HW implementations scale quite differently.

NikosD

11th February 2014, 12:28

H264 was primarily designed for HD, not UHD. You notice this in the UHD decoding performance, it doesn't scale properly. Its not a software problem as such, but a limitation of the format.

The various levels of H.264 allow the format to be as flexible as you want.

You can encode in various resolutions from very low to very high and the same goes for bitrate.

Regarding scaling to multi-core/ multi-thread decoding, I disagree with you based on my SW decoding tests.

Most of the times the performance from single core to dual core is almost double and from dual core to quad core, is double again.

You can check it out in my Excel.

I would say that H.264 SW decoding is one of the most suitable process to show off multi-core/ multi-thread/ hyperthreading efficiency.

H.265 is just a small evolution of H.264 and not a revolution as it was H.264.

H.265 can achieve same picture quality with half-bitrate of H.264 and go up to 8K, but this is something that H.264 could possibly handle in the future with an appropriate extension -the resolution, not the bitrate.

Even MPEG1 managed to go to HD!

So, the "problem" is not in the algorithm or the implementation, the "problem" is the efficiency and speed of an ASIC vs CPU.

The order of magnitude that Eric wrote in his post between the complexity of the ASIC implementation and the programmable HW can't be beaten by faster clock or SIMD architecture unless you push it in unrealistic values, speaking theoretically.

nevcairiel

11th February 2014, 12:33

You don't understand. I never said H.264 doesn't scale properly to multi-cores. I said H.264 decoding performance does not scale properly for UHD content, because the format is not optimized for such image sizes and high bitrates. It just gets extremely slow!
Of course you can create such files, but they will just decode very slow in software decoders. HEVC on the other hand is optimized for UHD content and above, and its much easier to write a decoder for HEVC which can decode 4K movies faster than a H264 decoder could.

H264 was designed at a time when HD was the major target. You CAN create files in 4K and maybe even 8K in H.264, but decoding those files is just going to be extra slow.

NikosD

11th February 2014, 12:43

I understood what you wrote, but I think you didn't understand me.

During my SW decoding tests, there was no difference between H.264 HD decoding and H.264 UHD decoding.

The algorithm and the ffmpeg SW decoder, scale almost linearly, almost perfectly!

The algorithm and the decoder don't have strange preferences to check if the content is HD or UHD and to behave accordingly!

If it scales to HD it scales to UHD too.

It's just the extra information, pixels, bandwidth due to higher resolution that make things harder for decoders (SW or HW) to keep up with UHD.

HEVC on the other hand is optimized for UHD content and above, and its much easier to write a decoder for HEVC which can decode 4K movies faster than a H264 decoder could.

H264 was designed at a time when HD was the major target. You CAN create files in 4K and maybe even 8K in H.264, but decoding those files is just going to be extra slow.

You are DEFINITELY WRONG about that.

H.265 decoding is much more difficult than H.264 decoding and you need a quad core CPU to decode 1080p content.

For 4K H.265 you can forget any CPU that is released today, if you increase a little the bitrate or fps.

Again, check the SW performance of H.265 decoder in my Excel to see the figures of 1080p H.265 decoding

nevcairiel

11th February 2014, 13:22

There is no H.265 decoder out there today which is already properly optimized like the H.264 decoders are. Once they are optimized, they'll likely be double as fast as today, or even more.
I am a developer and I deal with software decoders every day. I know what I'm talking about.

For 1080p, H.264 will remain faster. For 4K, HEVC will be faster.

In any case, I've learned a long time ago that you are unwilling to accept any other truth then what you believe it to be, so I won't bother to try to argue.

hajj_3

11th February 2014, 13:32

NikosD

11th February 2014, 13:32

@nev

I don't doubt your programming skills, I just see the facts.

I did some testing a few weeks ago and I posted my results to an Excel.

I change my mind often, when I see real numbers, but I have this bad habit to test myself things and not just believe others with no testing.

You know that too.

And I have to say that most of the times - not always of course - I'm right and this is not selfish.

About 4K H.265, we' ll see...

I just haven't seen anywhere something that tells me H.265 is easier to decode than H.264, even for 4K.

nevcairiel

11th February 2014, 13:35

egur, do you know whether intel's current apu's will be able to hardware decode h265 and vp9 using programmable portions of the hardware as i'd rather not drain the battery on laptops playing h265/vp9 with cpu decoding.

Thats unlikely to be useful.
You'll have to wait for a new generation of CPUs/GPUs to get hardware H265 decoders.

Luckily, there isn't any real content using it yet either. Not to mention that all encoders for it still suck and don't even manage to beat H.264 videos. :)

CharlieCL

11th February 2014, 15:57

...

Higher bitrates cause the bitstream parsers to need much more time, especially the entropy decoding (CABAC) in H264 is rather slow and cannot be implemented with SIMD instructions (SSE/AVX), but only "normal" instructions. Bitrate plays a huge role in the speed of a software decoder (unlike hardware decoders, where the impact from bitrate is much smaller).

H264 was primarily designed for HD, not UHD. You notice this in the UHD decoding performance, it doesn't scale properly. Its not a software problem as such, but a limitation of the format.

Even a HEVC decoder in its early stages (meaning not very optimized yet) can be as fast or even faster than a highly optimized H264 decoder on UHD content, just because the format is more suited for it. Bitrate is lower, processing algorithms are better suited and more efficient at higher resolutions.

PS:
All of this applies to software decoders, HW implementations scale quite differently.

The entropy decoding (CABAC) in H264 may be need to be optimized by "Assembly".

HEVC with half bitrate of H264 has the same video quality?That will be good for SW decoder.

When CPU usage raise the performance of CPU may be decreased. That may be another problem of SW decoder.

nevcairiel

11th February 2014, 16:09

The entropy decoding (CABAC) in H264 may be need to be optimized by "Assembly".

It already is.
But you're welcome to contribute improvements!

CharlieCL

11th February 2014, 16:12

Most of the times the performance from single core to dual core is almost double and from dual core to quad core, is double again.

You can check it out in my Excel.

I would say that H.264 SW decoding is one of the most suitable process to show off multi-core/ multi-thread/ hyperthreading efficiency.

What software decoder can double the performance from dual core to quad core?

NikosD

11th February 2014, 16:25

I always use LAV Video in my tests, aka ffmpeg.

NikosD

13th February 2014, 12:16

GTPVHD

13th February 2014, 12:53

Maxwell introduces even faster H.264 encoding and decoding with improved NVENC (which is used, for instance, in ShadowPlay).

Looks like Nvidia Maxwell has a new generation VP6(?) decoder, maybe fast & powerful enough to decode 4K60P(?)/120P(?) now instead of just 4K24P in Kepler VP5.

NikosD

13th February 2014, 13:08

We 'll find out later this month, but while it says improved NVENC, it doesn't say anything about new decoding engine.
Probably they don't like the unofficial name "VPx".

Faster H.264 decoding could be a new engine like "VP6" or an improved VP5.x

VP5 is faster than 4K@24fps.
It's closer to ~30fps, like 27-29fps.

And what about other features regarding codecs, resolution or VPP functions ?

I don't think Maxwell supports H.265 (surely they would say so in bold letters), but I think that Intel's Broadwell will not support H.265 too.

I bet Nvidia with Maxwell will catch 4K@60 fps, but no more.

It's not that easy to catch 4K@120fps like Intel did.

We 'll see...

NikosD

24th February 2014, 22:43

Intel surely listens users and makes progress in driver's quality but:

1) They don't change their mind about pre-configured VPP functions in drivers - they activate a lot of them by default

2) They new drivers crash DXVA Checker v3.0

3) They disabled DXVA VC-1 above 1080p - fortunately QS decoder still use 4K VC-1

4) In the release notes say that my Pentium G3420 has Intel QuickSync enabled but not Intel Clear Video HD!

5) Still has OpenGL problems with MadShaders v.0.3.0

6) Still GPA can't be used for media metrics under Win 8.1 and it crashes OS

mhourousha

26th February 2014, 06:38

HDMI don't output sound after I Installed 10.18.10.3412,I have to uninstall the audio driver :( My cpu is i3-3225

Procrastinating

27th February 2014, 13:16

egur

27th February 2014, 14:41

Would anyone know what the lowest-end Haswell CPU is, which can take advantage of Quicksync Encoding features? It would be interesting to see how cheap of a recording-ready processor could be found nowadays.

That would be the i3-4130 (http://ark.intel.com/products/77480/Intel-Core-i3-4130-Processor-3M-Cache-3_40-GHz) according to ark.intel.com

kalehrl

27th February 2014, 14:52

wanezhiling

27th February 2014, 15:33

That would be the i3-4130 (http://ark.intel.com/products/77480/Intel-Core-i3-4130-Processor-3M-Cache-3_40-GHz) according to ark.intel.com

http://forum.doom9.org/showthread.php?p=1670539#post1670539

GTPVHD

27th February 2014, 22:04

http://www.phoronix.com/scan.php?page=news_item&px=MTYxNzE

http://anzwix.com/a/VA-API/AddTheSeparatedMediaEncodingdecodingFilesForBDW

"On the video acceleration side, there's lots of changes between Haswell and Broadwell."

Interesting, wished Intel would release Broadwell instead of constantly delaying it, the need for more efficient 14nm CPU is great.

NikosD

28th February 2014, 12:16

Would anyone know what the lowest-end Haswell CPU is, which can take advantage of Quicksync Encoding features? It would be interesting to see how cheap of a recording-ready processor could be found nowadays.

You have to look for the cheapest, among these:

•Intel Pentium Processor 3558U/3561Y/G3220/G3220T/G3320TE/G3420/G3420T/G3430 with Intel HD Graphics
•Intel Celeron Processor 2957U/2961Y/2981U/G1820/G1820T/G1820TE/G1830 with Intel HD Graphics

kalehrl

8th March 2014, 20:58

Is there an encoding tool which makes use of Intel Quick Sync hardware deinterlacing?

andyvt

8th March 2014, 21:23

Is there an encoding tool which makes use of Intel Quick Sync hardware deinterlacing?

QSTranscode (http://sourceforge.net/projects/qstranscode/) does. By default it will use MSDK VPP to DI and output the rendered frame rate.

kalehrl

9th March 2014, 09:53

NikosD

9th March 2014, 10:01

Have you tried HandBrake with QuickSync support (https://trac.handbrake.fr/milestone/QuickSync%20Beta) ?

egur

9th March 2014, 10:11

You can try using LAV/ffdshow in your AVS script via directshow source. I didn't try it but I've heard it works. Both DS filters have HW deinterlacing and film mode detection (HW IVTC).

kalehrl

9th March 2014, 11:05

Have you tried HandBrake with QuickSync support (https://trac.handbrake.fr/milestone/QuickSync%20Beta) ?
I've just tried it and I can encode my video with qsv but the problem is, the video is sped up and it is half the length of the original. I followed this advice:
Simply select the "H.264 (Intel QSV)" encoder option from the "Video Encoder" dropdown menu on the "Video" tab.
For hardware-accelerated deinterlacing, use deinterlace custom with "qsv" (without quotes). This will only work when QSV is also used for video encoding.
The problem seems to be not being able to select field order in handbrake and also not dumping half the fields. The encoded video is 50fps progressive.
@egur
Could you please tell me how to transform this script into the one using LAV/ffdshow decoder with HW deinterlacing?
LoadPlugin("D:\Programs\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("D:\Dreambox\movie\test.mkv", fpsnum=25, fpsden=1, threads=1)
Load_Stdcall_Plugin("D:\Programs\MeGUI\tools\avisynth_plugin\yadif.dll")
Yadif(order=0)
crop(2, 74, -2, -74)
LoadPlugin("D:\Programs\MeGUI\tools\avisynth_plugin\UnDot.dll")
Undot() # Minimal Noise
Spline36Resize(704,394) # Spline36 (Neutral)
I tried this way:
DirectShowSource("D:\Dreambox\movie\test.mkv")
crop(2, 74, -2, -74)
LoadPlugin("D:\Programs\MeGUI\tools\avisynth_plugin\UnDot.dll")
Undot() # Minimal Noise
Spline36Resize(704,394) # Spline36 (Neutral)
And it seems to work and LAV filter icon appears in the tray so I guess LAV is used now instead of FFVideoSource but the question is how to use Intel HW deinterlacing instead of Yadif?

NikosD

9th March 2014, 11:40

Sorry I can't help you with that, I'm extremely new to QuickSync encoding, since last 3412 driver update :)

I'm sure that you can set your questions to their user support pages/ forum or directly to the developers of HandBrake.

kalehrl

9th March 2014, 12:01

Thank you NikosD but I don't intend to use handbrake because it doesn't use avisynth and I'm much more familiar with MeGUI.
It was never my intention to use hardware Quick Sync encoding because the quality leaves a lot to be desired when compared to software x264.
All I want is to get rid of QTGMC and have HW deinterlacing which is of great quality, at least I've read so.
@egur
I can share my source file if you need it.

NikosD

9th March 2014, 12:06

It was never my intention to use hardware Quick Sync encoding because the quality leaves a lot to be desired when compared to software x264.

True, but the gap especially with Haswell is getting smaller.
And the speed of QS encoding is amazing.

All I want is to get rid of QTGMC and have HW deinterlacing which is of great quality, at least I've read so.

Definitely true.

andyvt

9th March 2014, 12:27

I tried it and it really works on my cheap Celeron g1820 processor.
The encoding is extremely fast but the quality is bad even with the highest quality preset.
I wound prefer to use MeGUI and software x264 encoder but just do deinterlacing with a tool which supports hardware Quick Sync deinterlacing.
I currently use QTGMC but it is very slow.

What arguments are you using? QSTranscode was originally intended for creating files suitable for mobile devices so many of the defaults target that use case.

I tested (http://missingremote.com/review/intel-quick-sync-examining-haswell-performance) QS quality against Handbrake x264 a while back and it was comparable at the same bitrate.

kalehrl

9th March 2014, 15:57

I used the GUI version with Mobile480p and Quality presets but I was comparing the quality with a software x264 encoder, not handbrake qsv encoder.
Here is the sample file:
https://mega.co.nz/#!4tpyWYrZ!kpQ130vf8FQsjPmBhEnNWA5LHrq7yjkkhUdOm6P49yY
It is decoded and deinterlaced fine during playback.
However, when I encode it using this script:
DirectShowSource("D:\Dreambox\movie\test.mkv")
crop(2, 74, -2, -74)
LoadPlugin("D:\Programs\MeGUI\tools\avisynth_plugin\UnDot.dll")
Undot() # Minimal Noise
Spline36Resize(704,394) # Spline36 (Neutral)
I get a lot of combing as if the deinterlacing was botched:
http://i61.tinypic.com/ic45fb.jpg

egur

15th March 2014, 10:03

@kalehrl, you can select HW deinterlacing in LAV Video Decoder settings (from start menu->LAV). You can also choose 25/30fps or 50/60fps output.

If this doesn't go well, you try using ffdshow. You can it's priority (merit) with GraphStudioNext.

MeteorRain

16th March 2014, 10:14

Hi egur

I'm new to this thread. Although I had a brief search I couldn't find the reason why decoding using QS doesn't work here.

I'm on i7 4770 + GT640, both graphics core works in standalone. I have 3 monitors, 2 on dGPU, 1 on iGPU. Windows 8.1.

When playing proper h.264 contents, LAV displays QS as available, but not using it, falling back to avcodec.

Tried ffdshow (the qsdecoder version) but it's same problem, falling back to libavcodec.

Tried both 32bit and 64bit player, tried initialize player on different monitors, no luck.

Player: MPC-HC + EVR CP

I was able to use DGDecodeIM to decode the video files properly, however.

Did I miss something?

NikosD

16th March 2014, 10:22

Why don't you try the 3rd option, PotPlayer, too ?

Are you sure that those H.264 clips are HW decoding compliant ?

Did you try to decode them in DXVA mode ?

MeteorRain

16th March 2014, 11:28

Why don't you try the 3rd option, PotPlayer, too ?

Are you sure that those H.264 clips are HW decoding compliant ?

Did you try to decode them in DXVA mode ?

Well, with potplayer it seems uses QS decoder. (I'm new to pot but I can see the different decoder used when playing 8-bit file and 10-bit file)

And yes these h.264 clips are 8-bit and HW decoding compliant and can be decoded in DXVA properly.

So my question is why LAV and FFD doesn't work here? Any clue?

wanezhiling

16th March 2014, 12:35

It really indicated QuickSync Decoder in PotPlayer's OSD(Press Tab during playback)?

MeteorRain

16th March 2014, 13:00

It really indicated QuickSync Decoder in PotPlayer's OSD(Press Tab during playback)?

Yes it did. It clearly shows QS Decoder on 8-bit files and FF Decoder on 10-bit files.

egur

17th March 2014, 12:55

MeteorRain

17th March 2014, 19:56

Could be that PotPlayer is using QS decoder in SW mode. Check performance of very high bitrate clips. If ffmpeg has better performance, than QS is in SW mode.

As a simple fix, try connecting one of your monitors to the Intel GPU ans see if that works.

If it fails, you need to install your driver.

3-4% when playing original blu-ray content.

I do have one monitor connecting to the iGPU, and with proper drivers installed (10.18.10.3412).

GTPVHD

18th March 2014, 10:53

http://www.phoronix.com/scan.php?page=news_item&px=MTYzNDA

Looks like Intel Broadwell supports VP8 hardware decoding.

egur

18th March 2014, 12:33

When this feature is available in the Media SDK, I'll add it to the IQS decoder.

Maybe I should start building a VP8 video clip collection...
Please share your files. High bitrate is preferred :)

NikosD

18th March 2014, 16:01

Eric hi.

I had posted to another forum the files below and it's been two months since then!

Have you done any progress on resolving the issues below ?

It's been a long time since your latest update and I had some time to test again QuickSync decoder with both Sandy and Haswell processors using latest Intel drivers for Win 8.1
I tested the implementation of QuickSync decoder inside LAV Video (external filter) and MPC-HC (internal filter), both latest versions.

I found out a lot of problems using Haswell and less or equal problems with Sandy.
The problems mainly are a lot of artifacts after seeking in progressive or interlaced H.264 and VC-1 files, especially AVCHD files

Examples:

Heavy artifacts after seeking

http://www.sendspace.com/file/9t7s3d

http://www.sendspace.com/file/kpy0a0

ftp://helpedia.com/pub/multimedia/x264/testvideos/2011%20-%2002%20-%20H.264%20CPU%20DXVA%20codec%20comparison%20-%20Core2Duo%20vs%20UVD%202.2/6.Cat-1080p60fpsRef4-25Mbps.m2ts

http://www.techpowerup.com/downloads/530/hd-dvd-demo-1080p-vc-1-ddplus-5-1/mirrors

http://www.sendspace.com/file/72ype8

http://www.sendspace.com/file/9p8xa0

Green images- image distortion

http://www.sendspace.com/file/p5f4j3

Looses video sync (stops decoding for a few seconds) after seeking

http://www.sendspace.com/file/xbzbp4

I have more than 50 files with similar problems.

Guest

18th March 2014, 16:39

Some of your links are dead. Please check them all.

EDIT: I tried the third one (cat) and seeking works just fine with DGDecodeIM(), so if you are transcoding that is an option. If you need the DirectShow filter for playing in a media player, then disregard this.

EDIT2: That cat stream is awesome 59.94 progressive HD! May I know where it comes from? Not for rule 6 purposes but because such streams are great for testing. Thank you.

NikosD

18th March 2014, 17:52

Most of the sendspace links are indeed dead because I uploaded them two months ago for the original post in another forum.

I haven't tested them since then, because I saw no update from Eric during the last two months.

If he doesn't have them from the first time and wants to get involved in resolving those many issues that unfortunately still exist with QS decoder, I would upload them again.

The cat sample is an AVCHD sample and it's one of many of my collection of such clips.

A few years ago (!) I have posted a link with a huge collection of AVCHD samples :)

NikosD

18th March 2014, 20:26

http://www.phoronix.com/scan.php?page=news_item&px=MTYzNDA

Looks like Intel Broadwell supports VP8 hardware decoding.

Bay Trail already has VP8 HW decoding support.

Look at the picture here:
http://www.anandtech.com/show/7314/intel-baytrail-preview-intel-atom-z3770-tested

Maybe I should start building a VP8 video clip collection...
Please share your files. High bitrate is preferred :)

VP8 is not a popular video format.
It has clearly lost the war with H.264 in terms of popularity, although is close in quality with H.264 (most of the people find H.264 a little better in PQ)

VP9 vs H.265 will be a more interesting battle because both these codecs are available at the same time and some companies like Imagination have already announced OpenCL assisted GPU decoding support.

http://www.imgtec.com/news/Release/index.asp?NewsID=844

UPDATE:
HW acceleration of VP8 in Bay Trail processors, comes from an Imagination processor VXD392.

egur

18th March 2014, 22:12

@NikosD,
I've looked at the clips 2 months ago and probably forgot to reply, busy times for me lately. Hence no updates on the decoder.

These seeking issues are not new. It is related to the splitter somehow, giving packets that break the HW decoder somehow.

Using the Matroska splitter removes most or all of seek issues (also faster TS seeking). I've asked for this smoother seeking via LAV splitter (a much better product all around) but I guess it's not so simple to implement.

I don't have a quick solution for this and I don't plan to parse the various stream for analysis as it will lower performance.

If I'd know what the problem was, I'd fix it.

GTPVHD

18th March 2014, 23:03

http://vr-zone.com/articles/first-look-new-features-cherry-trails-gpu/64068.html

Broadwell and Cherry Trail doesn't use Imagination IP, it's built into the Intel hardware decoder in their Gen8 GPUs.

NikosD

19th March 2014, 07:16

@NikosD,
These seeking issues are not new. It is related to the splitter somehow, giving packets that break the HW decoder somehow.

Using the Matroska splitter removes most or all of seek issues (also faster TS seeking). I've asked for this smoother seeking via LAV splitter (a much better product all around) but I guess it's not so simple to implement.

If I'd know what the problem was, I'd fix it.

I tried PotPlayer's internal splitter and all of the problems with seeking disappeared.

So it's LAV splitter's problem.

BTW, this (http://www.sendspace.com/file/pa59zq) clip has a small artifact just after the initial black screen (without seeking, in normal playback)

The artifacts are around the sun.

egur

19th March 2014, 08:48

Broadwell and Cherry Trail doesn't use Imagination IP, it's built into the Intel hardware decoder in their Gen8 GPUs.

You probably meant BayTrail not Broadwell. Broadwell is Haswell's successor and has new version of the GEN iGPU (faster of course :) ). Broadwell isn't sold yet.
The Atom family has a smaller version of the GEN processor if I remember correctly.

The video capabilities (not performance) of BayTrail and Haswell (or Broadwell, don't remember) are the same since they share a lot of logic. The drivers are not 100% compatible though. They are separate for these 2 products.

@NikosD - I checked the clip. I have like 5 clips with the same behavior, which I've reported. All of them are TS. Somehow they start corrupt. I'm open for ideas as to how to fix these. FFMPEG is very resilient to these cases, but not always.

NikosD

19th March 2014, 14:06

Cherry Trail is the successor of Bay Trail just as Broadwell is the successor of Haswell.

Bay Trail uses Imagination's decoder - VXD392 - for HW acceleration of VP8, while Cherry Trail and Broadwell will have Intel's Gen8 engine for HW accelerated VP8 codec.

Bay Trail has an IvyBridge GPU with only 4 EUs and lower clocks + VXD392 video decoder.

As for those clips with artifacts, I don't know if this helps, but SandyBridge has exactly the same artifact when using Intel's DXVA.

In Haswell, this has been fixed for DXVA.

Maybe if you could look what Intel did to fix this for DXVA between those GPU generations , you could fix it for QS too.

GTPVHD

20th March 2014, 02:18

http://www.anandtech.com/show/7875/new-unlocked-iris-pro-cpu-broadwell

Broadwell will have Iris Pro graphics and 128MB eDRAM for socketed chips, probably the -K SKUs.

ryrynz

20th March 2014, 02:20

Broadwell will have Iris Pro graphics and 128MB eDRAM for socketed chips, probably the -K SKUs.

That news has been about for awhile and this really isn't the place to be posting about it.

NikosD

20th March 2014, 12:15

@egur

I have gathered together all of my samples that don't look OK with QS decoder in PotPlayer's implementation (probably the best)

Please download and test them before expiration.

No decoding
H.264 timestamp issues (http://www.sendspace.com/file/w77xgs)

Image distortion
H.264 4096x4096 (http://www.sendspace.com/file/yzk97i)

Artifacts after seeking or during playback
VC-1 file (1st) (http://www.sendspace.com/file/znvf1r)

VC-1 file (2nd) (http://www.techpowerup.com/downloads/530/hd-dvd-demo-1080p-vc-1-ddplus-5-1/mirrors)

Artifacts after 1st second (same as previous post)
H.264 interlaced (http://www.sendspace.com/file/pa59zq)

nevcairiel

20th March 2014, 12:34

I have gathered together all of my samples that don't look OK with QS decoder in PotPlayer's implementation (probably the best)

You do realize that this thread is about Erics implementation of the QS decoder, as used in ffdshow and LAV, so why would he be interested in results of some other (closed) implementation?

Even if he did care, he can't debug someone elses closed-source implementation to see whats going on or to fix it.

NikosD

20th March 2014, 13:11

The issues reported by me at the above post, are not issues of QS implementation like PotPlayer's or yours, but issues of the QS decoder itself.

If some other implementation can play those files using QS decoder, I'm ready to test it.

On the other hand, I have dozens of files playing fine with QS decoder in PotPlayer that have problem with MPC-HC(LAV video+splitter).

So, I think he is interested in those files and you should also.

Can you decode with MPC-HC those files without problems ?

Yups

22nd March 2014, 22:22

The drivers are not 100% compatible though. They are separate for these 2 products.

This is not correct. Latest drivers support IVB, HSW and Bay Trail Pentium/Celeron in one driver.

kalehrl

23rd March 2014, 08:49

I installed that driver just fine on my Windows 7 64bit.
It reads that it supports Windows 7.

STaRGaZeR

26th March 2014, 00:29

Do you guys know any solution to the top left cursor issue with Intel drivers? Since I upgraded from Sandy Bridge to Haswell and did the fake screen trick, I have this freaking issue. Using lastest drivers.

http://thumbnails109.imagebam.com/31668/1f30ad316679194.jpg (http://www.imagebam.com/image/1f30ad316679194)

egur

26th March 2014, 08:48

Do you guys know any solution to the top left cursor issue with Intel drivers? Since I upgraded from Sandy Bridge to Haswell and did the fake screen trick, I have this freaking issue. Using lastest drivers.

Not really the place to discuss driver issues, but what is the problem here? The snapshot looks fine. Note the player isn't fullscreen so it's upper left corner is round not rectangular.

STaRGaZeR

26th March 2014, 12:36

There are two cursors: the one at the top left corner of the monitor and the one inside LAV, which is the correct one. The top left one is always there, regardless of where the real one is. At all times, not only playing video. I remember reading about other people suffering this too. I'd go to the Intel forums, but this kind of issue with fake screens would get zero attention.

egur

26th March 2014, 13:42

I'll try to reproduce this and also use newer (than released) drivers.
It will take a few days. Very busy lately.

STaRGaZeR

27th March 2014, 17:58

Thanks! Ask if you need any details. Screen res is 2560x1440, fake screen doesn't let me select anything other than 1280x720. The discrete GPU is an HD7870 (now called R9 270X).

egur

4th April 2014, 18:34

I don't have the exact same HW as you but I couldn't reproduce. Since the screen is on AMD, try asking for support with them or try a different AMD driver.
Not much I can do.

jkauff

6th April 2014, 01:35

Eric, I ran into a couple of interlaced SD files that I ran through LAV with QS HW deinterlace enabled, and the playback audio was 3-4 seconds behind the video playback. The video actually seemed to be getting ahead of the audio, instead of the audio lagging.

Not a big problem, since I can play them using software deinterlace, but I wondered if you've seen this before.

egur

6th April 2014, 07:38

jkauff

9th April 2014, 02:19

Please share a clip that demonstrate the issue. Without this I can't test/fix.
More info. Deinterlacing is not involved. The problem with providing samples is that the movie will play for 20 minutes or more before getting out of sync. The madVR OSD shows dropping frames once the problem starts, but not before.

Environment is latest versions of nightly MPC-HC, external LAV filters, and madVR. Problem instantly goes away if I switch to software decoding, and also goes away temporarily if I exit and restart.

I'm not asking you to fix anything, just making you aware that I'm having an issue. I'll keep experimenting to see if I can get some more information about the circumstances.

BTW, this is with Win 8.1, the HD4000 set as primary in the BIOS, but secondary in Windows. Both GPUs are connected to a display, but not the same display. This allows me to use QuickSync without a fake screen.

theoneofgod

9th April 2014, 06:49

More info. Deinterlacing is not involved. The problem with providing samples is that the movie will play for 20 minutes or more before getting out of sync. The madVR OSD shows dropping frames once the problem starts, but not before.

Environment is latest versions of nightly MPC-HC, external LAV filters, and madVR. Problem instantly goes away if I switch to software decoding, and also goes away temporarily if I exit and restart.

I'm not asking you to fix anything, just making you aware that I'm having an issue. I'll keep experimenting to see if I can get some more information about the circumstances.

BTW, this is with Win 8.1, the HD4000 set as primary in the BIOS, but secondary in Windows. Both GPUs are connected to a display, but not the same display. This allows me to use QuickSync without a fake screen.

Give him the file that suffers the issue.
You don't need a fake screen on Windows 8+.

NikosD

11th April 2014, 11:12

Intel updated their SandyBridge drivers to 15.28.22.3517

32 bit (https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProdId=3319&DwnldID=23763&ProductFamily=Graphics&ProductLine=Desktop+graphics+drivers&ProductProduct=2nd+Generation+Intel%c2%ae+Core%e2%84%a2+Processors+with+Intel%c2%ae+HD+Graphics+3000%2f2000&DownloadType=Drivers&lang=eng) & 64 bit (https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProdId=3319&DwnldID=23764&ProductFamily=Graphics&ProductLine=Desktop+graphics+drivers&ProductProduct=2nd+Generation+Intel%c2%ae+Core%e2%84%a2+Processors+with+Intel%c2%ae+HD+Graphics+3000%2f2000&DownloadType=Drivers&lang=eng)

I don't have access right now to my SandyBridge system, but I would like to know if someone has such system, if Intel finally added the VC1_VLD2010 device driver for Sandybridge and if they added/ fixed OpenGL driver

GTPVHD

16th April 2014, 06:38

http://www.phoronix.com/scan.php?page=news_item&px=MTY2NTQ

Going back to Intel G45 and newer graphics has been a "BSD ring buffer" for H.264 and VC1 VLD decoding. All hardware up to now has had one "Bit Stream Decoder" ring for video decoding, but with the high-end "GT3" graphics of Intel's upcoming Broadwell hardware will be two rings. Broadwell GT3 (the highest-end graphics) will have two independent decoder rings for processing video commands. For the upcoming CPUs featuring GT3 graphics, this should mean a faster and more pleasant video experience, particularly when dealing with multiple video decoding streams.

http://lists.freedesktop.org/archives/intel-gfx/2014-April/043797.html

This is the patch set that tries to add the support of dual BSD rings on BDW
GT3. Based on hardware spec, the BDW GT3 has two independent BSD rings, which
can be used to process the video commands. To be simpler, it is transparent
to user-space driver/middleware. In such case the kernel driver will decide
which ring is to dispatch the BSD video command.

As every BSD ring is powerful, it is enough to dispatch the BSD video command
based on the drm fd. In such case the different BSD ring is used for video playing
back and encoding.

QuickSync gonna get even more obscenely fast at least on Broadwell GT3.

ionutm80

29th April 2014, 07:48

Hello Egur,

I have encountered lately a strange problem. I have been using LAV filters with QS activated on SB Pentium G620 and lately on a IB Core I3 3320t w/o a problem, h/w decoding drives CPU usage at merely 5-10%. However I have decided to buy a satelite HTPC and opted for something very small, not so powerfull but I considered sufficient enough to run any Full HD movie with H/W decoding. The PC I have opted for is an Intel NUC Kit DN2820FYKH (CPU: Intel® Celeron® processor N2820, GPU: Intel® HD Graphics, 756 MHz), 4GB RAM and a 60 GB SSD Agility 3. I have installed Windows 8.1 Pro + Media Center Pack. Then I connected a 2TB WD MyPassport with my collection of movies to this PC and I have reached the following results for both 1080p or 720p movies played with MPC-HC with LAV Filters:
- with QS activated as H/W decoding the CPU usage was insane for the little baby Atom (I understood that the Celeron 2820 is jus a rebranded Atom), around 70-80%. With WMP + Shark007 codecs with LAV Filters it even peaked all the time at 90-95%
- with DXVA native as H/W decoding the CPU usage was in average between 11-20% and only for very high bitrate movies it went to 30% (not too much to worry though).
I know that the graphics inside this Bay Trail NUC are in fact based on IB not Haswell, but with the Core I3 3220t (almost same graphic) with QS I never went above 5% CPU usage.

Is there a problem between your QS decoder and the graphic drivers for this NUC?
I think you have done an excellent job with this decoder and I would really like to use it since with native DXVA on SB I had some jerky playback on some movies in the past. Did not check it with the NUC.

Thanks for your help.

egur

29th April 2014, 08:03

The BayTrail processor has a single memory channel if I remember correctly. If you have slow memory + a slow CPU that may lead to a high CPU utilization (CPU is bottlenecked by memory).

There might be something I can do - have the driver copy the images back instead of my code doing it.

I'll try to find a similar system and check it out.

ionutm80

29th April 2014, 08:45

There might be something I can do - have the driver copy the images back instead of my code doing it.

I'll try to find a similar system and check it out.

Thanks a lot! If you need me to do something just let me know.

Kind Regards.

NikosD

29th April 2014, 09:41

Using LAV DXVA native with Haswell, the decoding is perfect in all formats supported (H. 264, VC-1/WMV3, MPEG2)

The drivers for Ivy are the same as Haswell, so I think you won't have any problems using DXVA with NUC.

About Sandy's jerky playback, have you tried latest drivers posted above ?

ionutm80

29th April 2014, 13:40

Using LAV DXVA native with Haswell, the decoding is perfect in all formats supported (H. 264, VC-1/WMV3, MPEG2)

Thanks for confirming that. However if I remember well on G620 with native DXVA the CPU was also at 20-30% while with QS never went above 5%. But 30% load on the baby Atom is bearable since I do not plan multi-tasking. :)

About Sandy's jerky playback, have you tried latest drivers posted above ?

Already replaced it with an I3 3220t (35w vs. 65w, QS for transcoding, 1080p even in S/W) so no more SB Pentium for me.

NikosD

29th April 2014, 14:24

Thanks for confirming that. However if I remember well on G620 with native DXVA the CPU was also at 20-30% while with QS never went above 5%.

That's impossible!

DXVA always uses as low CPU as possible, in every configuration.

Try it again.

theoneofgod

29th April 2014, 15:43

That's impossible!

DXVA always uses as low CPU as possible, in every configuration.

Try it again.

DXVA 1.50%
QS 2.00%

Not much difference but you're right. 1080p mkv.

ionutm80

29th April 2014, 16:19

That's impossible!

DXVA always uses as low CPU as possible, in every configuration.

Try it again.

I usually check it in Task Manager, Performance tab. Maybe the drivers were old but QS was țhe champ for me with SB in terms of CPU load and headless playback. Otherwise what would be its advantage from a user perspèctive vs native DXVA?

NikosD

29th April 2014, 17:15

For SandyBridge there was no DXVA HW VC-1/WMV3 decoder, at least before latest driver release.

If it happened to play such file on Sandy, then CPU was used for sure when using DIVA (fallback to CPU decoding)

But QS for HW VC-1/WMV3 on Sandy works fine.

For Sandy and all the other iGPUs the main use of QS is along with a discrete GPU, when dGPU handles 2D, 3D and iGPU handles video decoding.

andyvt

29th April 2014, 19:12

That's impossible!

DXVA always uses as low CPU as possible, in every configuration.

Try it again.

Depending on the CPU it's quite possible for DXVA decoding to take 20% of CPU. The trick however is that CPU throttling could be in effect.

For e.g.
https://lh4.googleusercontent.com/-0ANXVarEDpE/Uzl6i_4fm6I/AAAAAAAAOp8/BfSvuKWxZOM/s640/dxva2.jpg

NikosD

29th April 2014, 19:32

That's different.

The way it was written by iontutm80, it was like DXVAn needs more CPU power/ usage than QS.

Nice catch though, he should check CPU frequency too.

andyvt

29th April 2014, 19:50

...it was like DXVAn needs more CPU power/ usage than QS.

Yes, that's simply not possible because QS = DXVA + copying frames around in memory. On the N2820 this is crippling, probably because it only has one channel of DDR-1066 exposed (Bay Trail supports two, but the board only has one slot). QS and DXVA-CB are both unusable (although QS is worse than DXVA-CB).

My point was that it's quite possible for the facts as they were represented to be correct, it's just the interpretation that could be inaccurate.

ionutm80

30th April 2014, 07:01

That's different.

The way it was written by iontutm80, it was like DXVAn needs more CPU power/ usage than QS.

Nice catch though, he should check CPU frequency too.

Mea culpa. I do not have the SB anymore so unfortunately I cannot check again. But could have been my mistake...

Anyway I have tested the majority of your samples that you use for tests (except those 2160p which none played) with my Celeron NUC + DXVA native in LAV and I can say that everything went very smooth (15% load on CPU in average, peaking to between 23-30% sometimes on some high bitrate movies). Even the "bad ass" Samsung clip went very smooth. I still have some m2ts files taken with a Sony camera (CX-115e), 1080i 50fps that I have not test it yet and which prooved to be very cumbersome in the past. In LAV filters I have noticed that H/W deinterlacing is only possible with QS and not with DXVA native...

Thanks again for your helpfull clarifications and apologize if I said something stupid / not accurate.

NikosD

30th April 2014, 10:27

Anyway I have tested the majority of your samples that you use for tests (except those 2160p which none played) with my Celeron NUC + DXVA native in LAV and I can say that everything went very smooth (15% load on CPU in average, peaking to between 23-30% sometimes on some high bitrate movies).

Your NUC should be play those 4K clips using your iGPU (Ivy)

In order to do that, you should tick the UHD (4K) box in resolutions tab of LAV Video properties.

If you do it, give me a feedback.

In LAV filters I have noticed that H/W deinterlacing is only possible with QS and not with DXVA native...

By using DXVAn and EVR/EVR-CP renderer, HW deinterlacing is automatically used without selecting it anywhere.

ionutm80

30th April 2014, 10:52

Your NUC should be play those 4K clips using your iGPU (Ivy)

In order to do that, you should tick the UHD (4K) box in resolutions tab of LAV Video properties.

If you do it, give me a feedback.

Done that, ticked the UHD box in LAV, tested CrowdRun and OldTownCross, only the OldTownCross played very choppy (however with decent CPU load, ... I don't remember the figure exactly). For CrowdRun I received an error mesage about not possible to render the file. I will download all your 2160p and revert with results.

By using DXVAn and EVR/EVR-CP renderer, HW deinterlacing is automatically used without selecting it anywhere.

Thanks for info, I will test tonight the 1080i 50fps files and revert.

NikosD

30th April 2014, 11:54

Maybe run the DXVAchecker first, in order to be sure that 4K is enabled in drivers for your HW.

andyvt

30th April 2014, 12:11

Your NUC should be play those 4K clips using your iGPU (Ivy)

I wasn't able to get 4K DXVA2 decoding to work properly on the N2820 on a 1080p display (don't have a 4K display to test it). It can decode it, but the results weren't acceptable. My guess is that it's bandwidth limited or that it runs out of go downscaling 4k->1080p.

ionutm80

30th April 2014, 12:33

I wasn't able to get 4K DXVA2 decoding to work properly on the N2820 on a 1080p display.

Did you ran by chance DXVA Checker as Nikos suggested?

NikosD

30th April 2014, 12:35

andyvt

30th April 2014, 12:40

I think it's the second.

The number of EUs is extremely limited (only 4 I think), so the GPU load should be the main restriction factor of 4K decoding and downscaling to 1080p.

Can you check GPU load during 4K decoding on a 1080p display ?

My understanding is that decoding is mostly ASIC, with limited VPP taking place in EU. Has Intel documented where scaling occurs?

IIRC, I was having trouble getting GPU-Z to work on the N2820. Do you know of another tool? That's why I'm hesitant to only blame the GPU (I don't have a way to prove it :)).

NikosD

30th April 2014, 13:15

I use HWiNFO it's very good and detailed and actually I use the HWiNFO monitor, which is a Win 7 gadget in order to see realtime some sensors (including clocks and GPU load of iGPU)

andyvt

30th April 2014, 13:19

I use HWiNFO it's very good and detailed and actually I use the HWiNFO monitor, which is a Win 7 gadget in order to see realtime some sensors (including clocks and GPU load of iGPU)

Thanks. I'll give that a try.

andyvt

30th April 2014, 13:41

can you check gpu load during 4k decoding on a 1080p display ?

93.42%

NikosD

30th April 2014, 14:48

Thanks.

The number of EUs is the limiting factor for proper 4K decoding and downscaling to 1080p, I'm pretty sure after your result.

ionutm80

30th April 2014, 15:42

Thanks.

The number of EUs is the limiting factor for proper 4K decoding and downscaling to 1080p, I'm pretty sure after your result.

Tried CrowdRun on a Intel Core I5 3320M @ 2.60 GHz, HD Graphics 4000, 16 EUs. See attached (UHD checkbox ticked in LAV, QS activated, DXVA similiar at CPU load). Are sure it's related to the number of EUs?

NikosD

30th April 2014, 16:23

I can't see your attachment, but if you have problems decoding 4K with your Core i5 try to put everything in Intel's driver menu from here:
VIDEO - > color enhancement, VIDEO -> Image enhancement, VIDEO -> Image scaling
to "Application settings" and "OFF"

Be sure to do that in your NUC too

theoneofgod

1st May 2014, 16:06

Tried CrowdRun on a Intel Core I5 3220M @ 2.60 GHz. See attached (UHD checkbox ticked in LAV, QS activated, DXVA similiar at CPU load). Are sure it's related to the number of EUs?

QS or DXVA doesn't seem to work for me with MPC and 4k movies. It always uses avcodec and lags like crazy...

ionutm80

5th May 2014, 07:06

Went home and tried the same CrowdRun this time on a desktop Core I3 3220T with HD Graphics 2500. Lags like hell and all 4 virtual cores were at 100%. But the strange thing was that MPC-HC was not displaying "Playing H/W" like in the case of the Core I5 3320M which has HD Graphics 4000!!! Anyway my bet is that downscalling from 2160p to 1080p (I don't have a 4k capable monitor nor a display port available on the MB to test if only video decoding works smooth) is too much for my IVBs not to mention also NUC Atom.

NikosD

5th May 2014, 10:24

The 4 virtual cores running at 100% and MPC-HC not displaying "Playing H/W" as you can easily imagine means bad configuration.

If you use MPC-HC, you must tick 4K box inside MPC-HC and LAV internal filters, which have separate configuration from LAV external filters.

ionutm80

5th May 2014, 10:36

NikosD

5th May 2014, 11:15

Try this http://www.codecguide.com/download_other.htm

It's called Codec Tweak Tool and has an option to fix registry codec problems.

Have you tried any other 4K H. 264 sample ?

ionutm80

5th May 2014, 11:41

Try this http://www.codecguide.com/download_other.htm

It's called Codec Tweak Tool and has an option to fix registry codec problems.

MPC-HC has all the codecs embedded (LAV Filters) so should be no interraction with other codecs packs, no? I have only shark007 installed but the light version with only LAV Filters w/o FFDShow and other.

Have you tried any other 4K H. 264 sample ?

Tried also OldTownCross, same issues. By the way I've left DXVA native and not QS and of-course I have ticked 4k.

P.J

9th May 2014, 10:32

Still no HEVC H.265 support through QuickSync? :(

I had no problem with Intel (HD4400,DxVA/QS), 4K 125Mbps:

http://t.imgbox.com/bKJiuiHr.jpg (http://imgbox.com/bKJiuiHr)

theoneofgod

12th May 2014, 02:46

3770k. Intel 10.18.10.3574. LAV Filters 0.61.2. 4K LG UHDTV Garden Demo.mp4
Distortion at the bottom around 48 seconds. The latest beta drivers helped as it happened at the start.
Not only at 48 seconds by the way.

mp4 can be grabbed here: http://btdigg.org/search?info_hash=afb550e11dd70fab79399f6f430fc8af2c9cfc84&q=4k

NikosD

12th May 2014, 13:14

That 3min clip is huge, 2.69GB, due to 125Mbps rate!

Using latest nightly build of MPC-HC and LAV internal filters, I got a lot more problems using DXVAn than QS.

In both modes though, there is no constant image distortion.

Only in specific points and mainly after seeking.

theoneofgod

12th May 2014, 18:26

Here, setting DXVA reverts to avcodec. Distortion at 3:04 too. The 0:38 distortion happens without seeking, everytime.
Exact same issues with MPC-HC nightly.

nevcairiel

12th May 2014, 19:47

If it also happens with the software decoder (ie. avcodec), then the stream is most likely damaged.

theoneofgod

12th May 2014, 20:53

I can't see any distortion with avcodec.

NikosD

12th May 2014, 20:55

S/W decoding seems fine.

nevcairiel

13th May 2014, 00:25

You are posting confusing things then.

Here, setting DXVA reverts to avcodec. Distortion at 3:04 too. The 0:38 distortion happens without seeking, everytime.

You said DXVA reverts to avcodec, and it shows distortion too? or not? or what now?

theoneofgod

13th May 2014, 10:13

You are posting confusing things then.

You said DXVA reverts to avcodec, and it shows distortion too? or not? or what now?

I was adding to the QS distortion. With QS, distortion also occurs at 3:04, as well as 0:38. I'm still unable to have DXVA function with 4k streams.

M@xim

17th May 2014, 12:19

Where is better picture quality now, DXVA or QS?

kypec

17th May 2014, 12:29

Where is better picture quality now, DXVA or QS?
Picture quality must not be dependent on used decoder. If you experience any visual difference between decoders used then there must be some post-processing going on between decoder output -> renderer input.

Yups

4th June 2014, 13:25

Intel 10.18.10.3621 drivers for Haswell, Ivy Bridge & Bay Trail. Eventhough the page says only for NUC, it does install on all supported hardware.

https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23886

https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProdId=3720&DwnldID=23885&ProductFamily=Grafik&ProductLine=Desktop-Grafikcontroller&ProductProduct=Intel%C2%AE+Core%E2%84%A2+Prozessoren+der+vierten+Generation+mit+Intel%C2%AE+HD-Grafik+4600&lang=eng

Interesting is this change:

HEVC decode now supported by the driver and video players can now take advantage of the GPU accelerated decode support offered by Intel

theoneofgod

4th June 2014, 15:03

https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProdId=3720&DwnldID=23885&ProductFamily=Grafik&ProductLine=Desktop-Grafikcontroller&ProductProduct=Intel%C2%AE+Core%E2%84%A2+Prozessoren+der+vierten+Generation+mit+Intel%C2%AE+HD-Grafik+4600&lang=eng

Interesting is this change:

If they mean via QS, I see no difference. Same old distortion.

CiNcH

5th June 2014, 11:36

HEVC decode now supported by the driver and video players can now take advantage of the GPU accelerated decode support offered by Intel
Indeed interesting. I wonder how it is done. Since H.265/HEVC QS ASIC support does not even appear on the list of Broadwell, it can only be some acceleration via shaders. It will be interesting to see which parts actually are accelerated and how well it scales with HD2000/HD4000/HD5000 series GPUs.

andyvt

5th June 2014, 11:38

Yups

5th June 2014, 13:34

Indeed interesting. I wonder how it is done. Since H.265/HEVC QS ASIC support does not even appear on the list of Broadwell, it can only be some acceleration via shaders. It will be interesting to see which parts actually are accelerated and how well it scales with HD2000/HD4000/HD5000 series GPUs.

Via Shader is more or less confirmed from Intel.

On that note, there are plans to release a "hybrid" (utilizing EUs of the Core Processor graphics unit) HEVC decoder later this year.
https://software.intel.com/en-us/forums/topic/499189

M@xim

9th June 2014, 02:58

Hi, i used g3420, 10.18.10.3621 video driver, WMP and LAV. When play "Japan 1080p59.94" and use QuickSync in LAV, video play normal, but if i click remote for any position video begins to freeze any ~5 seconds, cpu load in this moments has down to 0. If change QuickSync on DXVA Native video play good.

egur

9th June 2014, 07:11

I'm not familiar with this clip. Can you upload it or part of it?
Which splitter do you use?

M@xim

9th June 2014, 08:13

Splitter is LAV too. Link on download video https://drive.google.com/open?id=0B7zcTvSa9boAUlEyOFluTEdhWGc

egur

9th June 2014, 08:40

Please in a method that doesn't require me to install any SW.

M@xim

9th June 2014, 09:30

Dropbox https://www.dropbox.com/s/aslys4va3ssrsbk/Japan%201080p59.94.m2ts

NikosD

9th June 2014, 09:55

I can confirm the above behavior described by M@xim

Using PotPlayer with QS decoder, seeking becomes almost instant like DXVA native.

theoneofgod

9th June 2014, 11:33

egur

9th June 2014, 12:43

I reproduced also on ffdshow on SandyBridge. I'll look into this.

cybersans

14th June 2014, 12:21

the 15.33.19.64.3540 driver caused out-of-sync while playing mkv/mp4 videos using ffdshow_rev4519_20130622_egur.exe
need to release a new version, maybe since last version is 2013.

fyi, i am using .3412 driver since it is the "latest" driver that did not give any problem with ffdshow. other version later than that until .3540 caused audio and video not sync, where i can see that video comes faster than audio.

thats all for the information.

CharlieCL

19th June 2014, 19:50

Weird true full screen bug. I tested with windows 8.1, LAV 0.61.2 on Dell XPS12 Haswell. The first time installation I can switch to true full screen and run videos fines. But when I switch back to normal windows mode then back to true full screen, the full screen stayed in dead, no any reaction except close it. I am not sure if Quick Sync or driver not release all the resources in full screen switching.

CharlieCL

19th June 2014, 19:57

Quick Sync Copyback may cause lot of performance down especially in high data rate. Without copyback the CPU usage may be in 7% but with copyback the CPU usage may be 20%. Any solution? A buffer pointer to video render?

nevcairiel

19th June 2014, 20:03

Use DXVA2-Native, then you don't get any copy-back, and its fully compatible with recent Intel GPUs.

theoneofgod

20th June 2014, 01:55

Use DXVA2-Native, then you don't get any copy-back, and its fully compatible with recent Intel GPUs.

Is there a way to use the iGPU for DXVA while running a dGPU?

CharlieCL

20th June 2014, 01:58

Use DXVA2-Native, then you don't get any copy-back, and its fully compatible with recent Intel GPUs.

My render is embedded and not is compatible to EVR. So when I enabled DXVA-2 native the hardware acceleration was disabled. Quick Sync copyback can enable hardware acceleration in my case.

It is an architecture mistake for all the CPU and GPU designers that put video hardware acceleration in GPU memory space.

nevcairiel

20th June 2014, 02:08

It is an architecture mistake for all the CPU and GPU designers that put video hardware acceleration in GPU memory space.

For playback, which is the major use case, its the most efficient way to do it, since in an ideal case you'll never have to copy the image anywhere, which is how DXVA2 works.
From decoding right to the display, the image doesn't have to be copied once. If you put the decoder anywhere else, you would always have to copy the image at least once.

In any case, you can implement DXVA2 support in your own renderer if you really wanted do. Otherwise, you'll just have to use the copy-back decoders.

CharlieCL

20th June 2014, 03:52

For playback, which is the major use case, its the most efficient way to do it, since in an ideal case you'll never have to copy the image anywhere, which is how DXVA2 works.
From decoding right to the display, the image doesn't have to be copied once. If you put the decoder anywhere else, you would always have to copy the image at least once.

In any case, you can implement DXVA2 support in your own renderer if you really wanted do. Otherwise, you'll just have to use the copy-back decoders.

My case is to output decoded frame as a texture buffer input.
So shared decoding output buffer and texture buffer will remove an image buffer. Can I have a DXVA2 compatible render embedded in my program? I just know EVR render to generate a .DLL filter. I do not need a .DLL.

Whether it is DXVA2 Native or Quick Sync, I can allocate a image buffer and present a pointer to codec, however I do not know the protocol to do so.

I expect that HSA can solve this kind of hardware acceleration problem. Unfortunately HSA today is only a paper in software.

andyvt

20th June 2014, 09:41

Can I have a DXVA2 compatible render embedded in my program? I just know EVR render to generate a .DLL filter. I do not need a .DLL.

Are you asking if it's possible to load an unregistered COM object embedded in your exe as a DirectShow renderer (filter)? If so, the answer is yes (http://www.gdcl.co.uk/2011/June/UnregisteredFilters.htm).

To support DXVA2 you just need to follow the rules.

Out of curiosity, why are you writing a custom renderer? In most cases you should be able to use the EVR w/ a custom presenter or mixer (depending on what your use case is).

CharlieCL

20th June 2014, 14:50

Are you asking if it's possible to load an unregistered COM object embedded in your exe as a DirectShow renderer (filter)? If so, the answer is yes (http://www.gdcl.co.uk/2011/June/UnregisteredFilters.htm).

To support DXVA2 you just need to follow the rules.

Out of curiosity, why are you writing a custom renderer? In most cases you should be able to use the EVR w/ a custom presenter or mixer (depending on what your use case is).

No. I just included entire source code of a render in my exe. EVR + Custom Presenter is limited for post-processing.

andyvt

20th June 2014, 15:22

No. I just included entire source code of a render in my exe. EVR + Custom Presenter is limited for post-processing.

If you need to do something pre-post processing (e.g. before DI) that's where you could implement a custom mixer.

NikosD

27th June 2014, 17:27

Eric hi.

How hard would be for you to implement HW acceleration for MJPEG codec inside your QS decoder ?

egur

28th June 2014, 12:38

Eric hi.

How hard would be for you to implement HW acceleration for MJPEG codec inside your QS decoder ?

Hard to tell. If everything is simple (never is) it's pretty quick - a day or two. If things get complicated it can take a week or two.

There's very little appeal to MJPEG, this format is dying and not used much by HD content. For SD support, better to use the SW codecs.

Since I'm working 130% on my current tasks, I'm really in no way to experiment in low priority features.
Other codecs are coming soon. When/if MSDK supports them, I'll try to find time to add those.

My hope is that both DXVA2 and DX11 video API will be that good and QS decoder will have no need to exist. It was meant as an intermediate solution.

Anyway, all of my time is dedicated to Overclocking of next gen CPUs (fun :) )and a few new security features (less fun).
Media OC is on my TODO list as well.

egur

28th June 2014, 12:40

Japan clip analysis:
It seems the decoder isn't doing anything wrong. In ffdshow, the stalls occur when ffdshow asks the renderer for a surface.
I don't have a clue as to why this happens, I thought maybe the timestamps caused this, but I stopped handling those and no change.

So I'm out of ideas about this specific clip.

egur

28th June 2014, 14:15

Version 0.45 is out with the following changes:
* Bugfix - frames were sometime treated as interlaced.
* Bugfix - time stamps are passed 'as is' when TS manipulation is off.
* Bugfix - time stamps handling was causing A/V delay.
* Changed: AnnexB type packets (AVC in TS files) is not pre-processed and sent to the HW decoder directly. May break a broken clip or two but save many others.
* Sync with MSDK 2014 files.
* FFDShow: r4531

Downloads
* For the latest cutting edge FFDShow builds download my builds Intel QuickSync Decoder SourceForge home page (http://sourceforge.net/projects/qsdecoder/)
* FFDShow-tryout site (http://ffdshow-tryout.sourceforge.net/download.php)
* LAV Splitter builds (http://forum.doom9.org/showthread.php?t=156191)

NikosD

28th June 2014, 15:13

Nice!

It's been a long time since your last update.
I'm sure that will see the new version in both PotPlayer and LAV Video.

Do the changes in .ts container mean, that QS decoder will finally work together with LAV splitter without artifacts after seeking ?

UPDATE
I forgot to ask:
Are you going to support HEVC_VLD_Main mode in QS decoder ?

clsid

28th June 2014, 15:54

New stable ffdshow releases are now available on SourceForge as well.

egur

28th June 2014, 21:21

TS containers have long standing issues with the HW decoder but also with libavcodec.
The fix is related to timestamps which have nothing to do with image corruption that shows up in first few frames after a seek.
I hope the timestamp issue is solved.

Changing the splitter to produce the same bitstream as the old Matsroska splitter is probably hard.
Fixing this in my decoder is not simple. If someone has the knowledge to do it, I can give it a try.

HEVC, when supported properly by the MSDK will be added. I'm not sure what kind of HW acceleration is supported in Haswell/Broadwell if at all.

NikosD

28th June 2014, 21:35

So fixed timestamps will improve seeking and frame rate.

Is there anything more ?

I'm not sure if I had any problems with .ts besides image corruption.

About HEVC, it's officially supported by latest driver using a hybrid mode of HW acceleration, leveraging EU's and CPU of course.

Full fixed-function HW accelerated HEVC decoding will not be possible even by Broadwell.

We have to wait two generations from Haswell.

NikosD

29th June 2014, 09:57

New beta ver. 3651, mainly for GRID Autosport* game:

https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProdId=3719&DwnldID=23985&ProductFamily=Graphics&ProductLine=Desktop+graphics+drivers&ProductProduct=4th+Generation+Intel%c2%ae+Core%e2%84%a2+Processors+with+Intel%c2%ae+HD+Graphics+4400&lang=eng

ryrynz

29th June 2014, 11:11

Just set up a fake display, is there a way to actually hide the now invisible second screen I have to the right?

theoneofgod

29th June 2014, 15:07

Just set up a fake display, is there a way to actually hide the now invisible second screen I have to the right?

With Windows 8+ you don't need a fake display to use QuickSync.

Tacio

29th June 2014, 16:28

With Windows 8+ you don't need a fake display to use QuickSync.
I have windows 8.1 Pro x64 and Core i5-2410M (Sandy Bridge) but don't have available QuickSync decoding in LAV filters while my MPC-BE uses dGPU NVIDIA 520M in nVIDIA control panel settings.
LAV filters version: 0.62.0
Intel HD Graphics dirver ver. 3517
What's wrong with my setup?

wanezhiling

29th June 2014, 17:12

Because it doesn't support NVIDIA Optimus.
On desktop it works.

egur

29th June 2014, 20:38

Because it doesn't support NVIDIA Optimus.
On desktop it works.

Sad but true. Optimus hides the iGPU. Nothing I can do about it.

cybersans

30th June 2014, 04:19

http://i1116.photobucket.com/albums/k565/cybersans/ffdshow_rev4531_20140628_egur_x64-quicksync.jpg (http://s1116.photobucket.com/user/cybersans/media/ffdshow_rev4531_20140628_egur_x64-quicksync.jpg.html)

i don't know what to call this but the video's become like this when using the latest ffdshow. fyi, i am using windows media player 64 bit with ffdshow x64.
before this using ffdshow_rev4519_20130622_egur_x64.exe but audio and video not sync, where sometime audio is faster than video or vice versa.

fyi i also test the video using 32bit version and same result.

theoneofgod

30th June 2014, 08:49

Intel 10.18.10.3652 beta drivers for Haswell. This beta driver will only install on Haswell, Ivy Bridge & Bay Trail is not supported in this beta driver.

https://communities.intel.com/thread/52705

https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23985

Ivy is 2 generations behind now, I didn't realize. Oh well...

NikosD

30th June 2014, 09:52

Ivy is just the previous generation.
Not two generations, just one.

SandyBridge is two generations back.

theoneofgod

30th June 2014, 18:07

I thought z97 was the 5th generation.

nevcairiel

30th June 2014, 18:11

Z97 is not a new CPU generation, its just a new chipset with a refresh of Haswell, not a new graphics generation by itself.

theoneofgod

30th June 2014, 18:49

It's shamefully marketed as the 5th generation. Thanks for clearing that up for me.

andyvt

30th June 2014, 19:10

Z97 is not a new CPU generation, its just a new chipset with a refresh of Haswell, not a new graphics generation by itself.

9x was intended as the chipset for Broadwell (socket compatible w/ Haswell), but when Broadwell missed it's target date (now expected pre-holidays) they shipped the chipset anyway.

Deihmos

30th June 2014, 23:29

I have an i3 processor and during mkv video playback in WMC my CPU usage is about 10-15 with software decoding. Is there any benefit if I use intel quick sync? The gpu is intel HD 4400.

theoneofgod

1st July 2014, 13:51

I have an i3 processor and during mkv video playback in WMC my CPU usage is about 10-15 with software decoding. Is there any benefit if I use intel quick sync? The gpu is intel HD 4400.

QuickSync does use very little CPU, but there are issues with it too.

cybersans

20th July 2014, 15:55

hello, anyone?
can someone help me with my #2526 post?
when "enable time stamp correction" it will disappear but video and audio not sync.
disable that, video and audio sync but the image crash when dragging the seek bar.

egur

20th July 2014, 21:06

I released a new version recently, try it out. If it still fails, share the clip.

cybersans

27th July 2014, 10:38

fyi i already install your current version per my #2526 post. it happen to all my mp4/mkv clips. already try different version of intel hd graphics driver too

egur

27th July 2014, 13:10

fyi i already install your current version per my #2526 post. it happen to all my mp4/mkv clips. already try different version of intel hd graphics driver too

the latest version is newer than what you used. The version you specified is from last year.
Go to the downloads (http://sourceforge.net/projects/qsdecoder/) section and try the new version:

cybersans

2nd August 2014, 09:39

sorry, that was 2013 but the codec used for that video is rev4512. i try rev4519, also same. today i try latest one rev4531. also same. fyi my intel hd graphics is 15.33.22.64.3621

CiNcH

7th August 2014, 21:02

While reading the Media SDK 2014 documentation, I stumbled over the following thing...

Many implementations of Intel® Iris™ Pro Graphics, Intel® Iris™ Graphics and Intel® HD Graphics (4200+ Series) allow support the creation of interpolated frame content by using the MFX_FRCALGM_FRAME_INTERPOLATION algorithm if the ratio of input-to-output frame rate is not supported, the VPP operation will report MFX_WRN_FILTER_SKIPPED. Commonly supported conversion ratios are 1:2 and 2:5 (useful for creating 60Hz content from 30Hz and 24Hz, respectfully).

Could this be integrated into the QuickSync Decoder for easy usage in LAV? I also checked out the Direct3D11 Video APIs where there is als FRC support. But this seems to require a Media Foundation / Direct3D 11 pipeline. I don't know of a hardware that supports those Video APIs and no MFT that uses it. And the only more modern renderer supporting an up-to-date Direct3D might be madVR (which has its own FRC already). So I don't see any Direct3D11 FRC on the horizon. An easy to use Intel solution for existing infrastructures would be a cool thing.

Do you by chance know whether this is done by an ASIC inside the Haswell/4th Gen Core i processors? Or is it done by the EUs?

fvisagie

8th August 2014, 09:49

GTPVHD

11th August 2014, 17:16

http://images.anandtech.com/doci/8355/GPUMedia_575px.png

http://www.anandtech.com/show/8355/intel-broadwell-architecture-preview/3

Moving on, last but not least in our GPU discussion, Intel is also upgrading their GPU’s media capabilities for Broadwell. The aforementioned increase in sub-slices and the resulting increase in samplers will have a direct impact on the GPU’s video processing capabilities – the Video Quality Engine and QuickSync – further increasing the throughput of each of them, up to 2x in the case of the video engine. Intel is also promising quality improvements in QuickSync, though they haven’t specified whether this is from technical improvements to the encoder or having more GPU resources to work with.

Broadwell’s video decode capabilities will also be increasing compared to Haswell. On top of Intel’s existing codec support, Broadwell will be implementing a hybrid H.265 decoder, allowing Broadwell to decode the next-generation video codec in hardware, but not with the same degree of power efficiency as H.264 today. In this hybrid setup Intel will be utilizing both portions of their fixed function video decoder and executing decoding steps on their shaders in order to offer complete H.265 decoding. The use of the shaders for part of the decoding process is less power efficient than doing everything in fixed function hardware but it’s better than the even less optimal CPU.

The use of a hybrid approach is essentially a stop-gap solution to the problem – the lead time on the finalization of H.265 would leave little time to develop a fixed function encoder for anyone with a long product cycle like Intel – and we expect that future generation products will have a full fixed function decoder. In the meantime Intel will be in the company of other GPU manufacturers such as NVIDIA, who is using a similar hybrid approach for H.265 on their Maxwell architecture.

Zachs

16th August 2014, 12:57

egur

16th August 2014, 14:22

Dear Intellier (used to be one myself), I found a resource leak issue with the decoder. I reported it to LAVFilter's author but was asked to report here instead.

Bug report here: https://code.google.com/p/lavfilters/issues/detail?id=473

Cheers.

Well, this doesn't provide a lot of details...
I opened a media file 10 times in a row and memory stayed the about same (went up and down again and again).

Maybe one of the small memory footprint interfaces is leaked.

Do you know which resource type/interface is being leaked?
This could be a driver or Media SDK issue as well (my code is not the only allocator).

In any case this is a minor issue that shouldn't concern end users.

egur

16th August 2014, 14:28

I want to correctly target my system's GPU when encoding to ensure it can use DXVA for playback. At the moment I'm specifically concerned with H.264 encoding, but learning about the other available formats like MPEG-2 will also be useful. So far I've come up empty-handied and will welcome any suggestions.

Searching on the Internet indicates a lot of confusion around levels and reference frame settings, although it seems certain different GPUs have different capabilities. Scouring the Intel site for almost a day hasn't yielded anything either, beyond the statement that Clear Video is supported on my Core i5-2540M with HD Graphics 3000 GPU (http://ark.intel.com/products/50072/Intel-Core-i5-2540M-Processor-3M-Cache-up-to-3_30-GHz). From what I can tell, DXVA Checker doesn't provide this level of information (no pun intended) about the system.

Thanks,
Francois

QuickSync HW supports (at least) Level 5.1. High profile (8bit 4:2:0).
Some tablets only support up to level 4.0.
My suggestion is to use H264 (a.k.a MPEG4 part 10 AVC) High profile with Level 4.0 or 4.1. This is a trade off between the most optimized high bitrate encoding and having lots of devices be able to play it.
MPEG2 is old and should already be dead. H264 is superior in every aspect so use that.
H265 is too new for now but within a year or two it should start eating market share from H264.

Zachs

16th August 2014, 15:24

Hi egur,

You should use D3D9 debug runtimes with max validations and break on all errors and memory leaks, rather than looking at memory usage. In fact, it is not a memory leak but a GPU resource leak. Outstanding Alloc Counts when the app terminates can refer to either GPU or sys mem resource leak depending on where the resource was allocated.

Thanks,
Zach

egur

16th August 2014, 21:15

I didn't see how I can do this on Win8.1. I'll give it a look at work where i still use Win7.

Zachs

17th August 2014, 02:18

Yeah Win8.1 isn't ideal for D3D9 development.

fvisagie

19th August 2014, 07:57

I want to correctly target my system's GPU when encoding to ensure it can use DXVA for playback ... Clear Video is supported on my Core i5-2540M with HD Graphics 3000 GPU (http://ark.intel.com/products/50072/Intel-Core-i5-2540M-Processor-3M-Cache-up-to-3_30-GHz).

QuickSync HW supports (at least) Level 5.1. High profile (8bit 4:2:0).
Some tablets only support up to level 4.0.

Thanks for your response. Is a given Intel GPU supposed to support Clear Video and QuickSync to the same H.264 levels? Initial testing on HD Graphics 3000 seems to suggest that on playback (Clear Video) it only supports up to level 4.1 High profile, and playback is what I'm mostly concerned with at this point.

Your suggestion of targeting Level 4.0/1 during encoding would be even more appropriate if it turns out Intel GPUs are not guaranteed to support Clear Video to the same level as the 5.1 on QuickSync you mention. Just to be clear, I'm using non-HW-accelerated encoding.

nevcairiel

19th August 2014, 08:05

All Intel GPUs since the Sandy Bridge generation support decoding of H.264 up to level 5.1, however with resolution constraints. SNB only supports 1080p, not 4K (even though 4K is technically allowed in level 5.1).
That means 1080p with 16 refs or very high bitrate would decode just fine (which needs L5.1), but 4K would of course not.

In short, the support doesn't fit into any levels. If you needed to be very strict, then yes, only L4.1 is supported completely on Sandy Bridge, L5.1 only on later GPUs with 4K decoding capability.
But if you encode at 1080p, then L5.1 works just fine on those GPUs as well.

egur

19th August 2014, 08:32

Every generation has a limit on the decoder's resolution handling.
Latest generation (Haswell and Broadwell) supports up to 4K. 8K is still a dream.

NikosD

19th August 2014, 11:28

Seems like 15.36 drivers drop support for Ivybridge.

I'll give them a try.

Zachs

19th August 2014, 14:14

Any luck with debug runtime?

NikosD

20th August 2014, 06:02

http://forums.laptopvideo2go.com/topic/24340-intel-gma-drivers/page-30#entry148086

New 10.18.10.3907 drivers leaked, not official download from Intel's server if anyone wants to try. Only supports Haswell & Broadwell.

Added for the first time (?) - I don't remember if latest official beta 3651 had them - MediaFoundation VP8 Hardware decoder (& VP8 sync), although like MJPEG HW MFT decoder, I think there are no video decoders available leveraging them.

You have to use MSDK to leverage them.

NikosD

20th August 2014, 08:02

I want to correctly target my system's GPU when encoding to ensure it can use DXVA for playback. At the moment I'm specifically concerned with H.264 encoding, but learning about the other available formats like MPEG-2 will also be useful.

Scouring the Intel site for almost a day hasn't yielded anything either, beyond the statement that Clear Video is supported on my Core i5-2540M with HD Graphics 3000 GPU (http://ark.intel.com/products/50072/Intel-Core-i5-2540M-Processor-3M-Cache-up-to-3_30-GHz).

AMD cards, Nvidia cards and Intel's internal GPUs have different capabilities regarding H.264 Level and Ref frames support.

Almost all of the above - even 5 yo cards - support Bluray specs of 1080p H.264 L4.1 and Ref 4 clips.

For 1080p, Intel's iGPU from Sandy and better, they all support DXVA HW acceleration of L5.2 ReF 16 and bandwidths of more than 500Mbps.

egur

20th August 2014, 13:06

Any luck with debug runtime?

On Windows 7 I got the same report as you did but no way to know where it's coming from and what resource is leaked.
I don't see any "next steps" I can make here.

egur

20th August 2014, 13:11

Added for the first time (?) - I don't remember if latest official beta 3651 had them - MediaFoundation VP8 Hardware decoder (& VP8 sync), although like MJPEG HW MFT decoder, I think there are no video decoders available leveraging them.

You have to use MSDK to leverage them.

When I'll get a Broadwell system, I'll try to add VP8 support.

Please point me to VP8 clips or share some of your own.

Also which source/splitter is used with this format? LAV?

Zachs

21st August 2014, 02:13

On Windows 7 I got the same report as you did but no way to know where it's coming from and what resource is leaked.
I don't see any "next steps" I can make here.

I know from personal experience debugging D3D resource leak is no easy task. Typically anything that you 'get' from the D3D device needs to be released. This link contains useful info -- http://gamedev.stackexchange.com/questions/49614/how-to-debug-direct3d-resource-leak

jkauff

21st August 2014, 16:45

egur

21st August 2014, 22:45

Eric, I have a problem you might be able to help with. Ever since upgrading to Win 8.1, when I select QS decoding in LAV the video gets way ahead of the audio on playback--about 10-15 seconds. It never used to do this, and it happens no matter which player I use. I don't use Reclock, so that's not the culprit. I'm on Haswell now, although it started when I was still on Ivy Bridge. Latest Intel drivers.

Any idea what's going on?

I'm using Win8.1 on a regular basis and didn't encounter any problems like you described.
Do all containers (mkv, tc, mp4) do it?
All media files?
Which splitter and renderer are used?

This doesn't sound like a driver issue since there's a problem with the timestamps.

jkauff

22nd August 2014, 00:30

I'm using Win8.1 on a regular basis and didn't encounter any problems like you described.
Do all containers (mkv, tc, mp4) do it?
All media files?
Which splitter and renderer are used?

This doesn't sound like a driver issue since there's a problem with the timestamps.
After doing some testing, it's only MKV files that have the problem. I'm using LAV and madVR. I normally use MakeMKV, but I'll run a file through mkvmerge and see if that makes a difference.

jkauff

22nd August 2014, 00:53

The remux didn't help. The problem's still there, so apparently it's not a MakeMKV timestamp bug. I'll try creating an MP4 from the same source.

jkauff

22nd August 2014, 02:12

I did some further testing. It seems the problem only occurs on some MKV files, not all of them. All decode correctly using software decoding.

Since I don't use QS very often, I'm not sure it's worth your time to look into this if no one else is having a problem.

NikosD

22nd August 2014, 06:58

When I'll get a Broadwell system, I'll try to add VP8 support.

Please point me to VP8 clips or share some of your own.

Also which source/splitter is used with this format? LAV?

Based on my previous post, you don't need Broadwell to add VP8 support.

Latest unofficial beta drivers have added that option for Haswell too.

I don't have VP8 samples, but you can find some for sure by googling "VP8 samples" or "WebM samples" which is the same.

Although, besides video servers, I don't see where that could be useful.

egur

23rd August 2014, 13:41

I did some further testing. It seems the problem only occurs on some MKV files, not all of them. All decode correctly using software decoding.

I view MKV files every day w/o issues although I don't use MadVR too often. Can you share a problematic file (~50MB)?

jkauff

24th August 2014, 01:29

I view MKV files every day w/o issues although I don't use MadVR too often. Can you share a problematic file (~50MB)?
Here's a clip:
https://dl.dropboxusercontent.com/u/29526622/preview.mkv

This is beginning to look like a Handbrake or x264 problem. I'm going to play around with my settings.

jkauff

24th August 2014, 01:37

Found it. The source file needed deinterlacing. Once I set that, QS played the resulting clip just fine.

itsonlyjustincase

1st September 2014, 14:43

Hi Eric,

Is there an equivalent of ffdshow with QuickSync for OSX ?

egur

1st September 2014, 18:39

Hi Eric,

Is there an equivalent of ffdshow with QuickSync for OSX ?

I'm not a big Mac OS X expert. I know MAC OS X supports HW acceleration for some format but I don't know which player actually uses it.

kalehrl

3rd September 2014, 20:11

These drivers are bad, at least for windows 7 ultimate 64bit.
I have a Celeron G1820 processor.
I ended up with no Aero after reboot.
I didn't have such problems with previous releases.

hoborg

3rd September 2014, 20:45

Working just fine for my HTPC. Win7 x64, Intel® Core™ i5-4590T (HD 4600).

Zachs

5th September 2014, 15:54

Just wondering. Any progress with the resource leak?

egur

9th September 2014, 12:48

Just wondering. Any progress with the resource leak?

No, very busy lately...

NikosD

12th September 2014, 12:26

Intel has released 10.18.10.3907 drivers(15.36 branch), only Haswell is supported.

https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24246

https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24245

There is also support for the first time, for Broadwell-Y (Core M) HD 5300 with a unique feature of OpenCL 2.0 support.

I don't know if it's CPU or GPU support of that and if Intel will bring it to Haswell too.

itsonlyjustincase

18th September 2014, 11:04

I'm not a big Mac OS X expert. I know MAC OS X supports HW acceleration for some format but I don't know which player actually uses it.

I've gone through the web and it seems except Apple itself, no other software developper on OSX knows what it Intel Quick Sync :s ! I just don't get it as it's been available since 2011 !!! How people can make video software on OSX which use video decoding/encoding and don't know that this QSV could drastically improve performances !!!

Egur do you think you could do something on your side so that apple release the quicksync api guide ? It seems the devs don't have it so can't use quicksync

egur

18th September 2014, 15:26

I've gone through the web and it seems except Apple itself, no other software developper on OSX knows what it Intel Quick Sync :s ! I just don't get it as it's been available since 2011 !!! How people can make video software on OSX which use video decoding/encoding and don't know that this QSV could drastically improve performances !!!

Egur do you think you could do something on your side so that apple release the quicksync api guide ? It seems the devs don't have it so can't use quicksync

Apple has all the knowledge to implement HW decode, encode and video processing. What they do with it, is their choice of course.

Apple has a video a acceleration API (that of course should use the QuickSync engine). Read more via this link (https://developer.apple.com/library/mac/technotes/tn2267/_index.html).

That page also references a Qt class that can do it for you.
Note that this framework is for H264 decoding only.
I can guess that when H265 is properly supported by HW and become more mainstream, Apple will switch to it and improve the API.

The above is from searching the web BTW.

fvisagie

18th September 2014, 15:27

itsonlyjustincase

20th September 2014, 10:34

Thanks for the answers guys !!!
So whenever hardware acceleration is triggered QuickSync will be used ?

egur

22nd September 2014, 14:15

So whenever hardware acceleration is triggered QuickSync will be used ?
Unless Apple implements their own video decode engine using OpenCL. This is of course a very bad idea so they wouldn't waste time and money on it and use the QuickSync HW instead.

itsonlyjustincase

24th September 2014, 16:19

Unless Apple implements their own video decode engine using OpenCL. This is of course a very bad idea so they wouldn't waste time and money on it and use the QuickSync HW instead.

Thank you very much for your answers.

Last question. You said : "Note that this framework is for H264 decoding only." Do you have the link for the H264 encoding framework ? Or perhaps some colleague of you which may know a bit more about apple could tell you ?

theoneofgod

6th October 2014, 04:12

I'll post this here as it happens with FFDShow as well as LAV. File is stuttery when playback is with Quick Sync.

Windows 8.1 x64 - Intel 3770k - MPC-HC 1.7.7

https://www.sendspace.com/file/0w4e7l

NikosD

17th October 2014, 10:24

This time I'm faster than GTPVHD

New drivers for Haswell and Broadwell

32-bit: http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=24349

64-bit: http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=24348

P.J

17th October 2014, 20:36

for Haswell too? I can't see it in the download center.

ryrynz

18th October 2014, 06:41

for Haswell too? I can't see it in the download center.

You shouldn't be asking questions like this here it's not the forum for it. It was posted that it was for Haswell in the title, and if you loaded the page it's fairly obvious it does as it states so on the page

"4th Generation Intel® Core™ Processors with Intel® HD Graphics 5000/4600/4400/4200"

You could have just downloaded them also and just tried installing them (they're only 100MB) look harder next time.

NikosD

26th October 2014, 21:03

kalehrl

27th October 2014, 14:49

In the release notes for 3958, my haswell processor G1820 isn't mentioned as supported.
In the release notes for 3960, it is mentioned so it may well be that they packed the drivers in 2 files.

egur

28th October 2014, 00:10

I can't understand Intel's policy for Haswell.

Those drivers are for Ivybridge-Haswell too and they are in 33 family.

But Haswell-Broadwell drivers are 36 family.

So Haswell is compatible with both.

Each driver generation supports 2 big-core processors and since BayTrail one or two small core (Atom) CPUs. Current generation 15.36 support Broadwell and Haswell. Previous generation supports Haswell and IvyBridge.

Yups

1st November 2014, 19:00

And that's a poor driver policy from Intel. Nvidia and AMD have a much longer driver support. Fermi got DSR support recently. Ivy Bridge won't get CMAA support which is much newer than Fermi. Just one example.

wanezhiling

2nd November 2014, 03:45

Can't agree more!!

P.J

23rd December 2014, 21:47

It doesn't work for HD4600:

http://i.imgur.com/1nVdMZM.jpg

ryrynz

23rd December 2014, 22:12

It doesn't work for HD4600:

Morning meh.

P.J

23rd December 2014, 22:16

That's because the 4600 is Ivy Bridge, not Haswell or Broadwell as stated.

http://www.notebookcheck.net/Intel-HD-Graphics-4600.86106.0.html

:search:

ryrynz

23rd December 2014, 23:11

It doesn't work for HD4600

Obviously got mixed up with the 4000, I don't need to use search I own one.

Confirmed, didn't install on mine either, odd.

Yups

25th December 2014, 00:28

It doesn't work for HD4600:

http://i.imgur.com/1nVdMZM.jpg

It works on my HD4600. Difference could be that I'm on Windows 7 while you are possibly using Windows 8.

CharlieCL

3rd January 2015, 20:04

Just tested a software in true fullscreen with Quick Sync and LAV 0.63 enabled it worked fine in NUC Core i5 Haswell. But it worked on Ultrabook Core i7 Haswell for a while in true fullscreen then back to dead later.

It is most possible there are bugs in graphics drivers of Ultrabook.

Nintendo Maniac 64

12th January 2015, 03:02

Question - what determines codec and format support for QuickSync decoding? Is it related to the supported formats and codecs decodable in DXVA2 at all?

ryrynz

15th January 2015, 08:04

Intel 10.18.10.4080 driver for Haswell & Broadwell.

Improved video playback through partial hardware acceleration support for the VP9 video format.

GPU accelerated decode of HEVC video file format including both 8-bit and 10-bit support. This will provide improved video playback capabilities on the platforms.

NikosD

6th February 2015, 13:51

New drivers for SandyBridge iGPU HD 2000/HD 3000 but with no release notes yet (the links point to the old release notes)

You can find more info here:
https://communities.intel.com/thread/60104

32bit
https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24695&lang=eng&ProdId=3319

64bit
https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24696&lang=eng&ProdId=3319

NikosD

21st February 2015, 09:55

Each driver generation supports 2 big-core processors and since BayTrail one or two small core (Atom) CPUs. Current generation 15.36 support Broadwell and Haswell. Previous generation supports Haswell and IvyBridge.

Eric, are you going to update QS decoder in order to support the hybrid HEVC decoder of Haswell and Broadwell ?

egur

22nd February 2015, 16:43

Eric, are you going to update QS decoder in order to support the hybrid HEVC decoder of Haswell and Broadwell ?

I've started to look into this. My new laptop is a Haswell so this should speed things up.

NikosD

22nd February 2015, 19:49

There is also a VP8 decoder in Haswell, as I have said you before and as I read elsewhere there is even a hybrid VP9 decoder for Broadwell already enabled in latest drivers.

As a matter of fact, next version of Chrome will have VP9 support for Broadwell.

I don't know if your QS decoder could include those formats VP8/VP9, because they are not supported from Microsoft and DXVA and if you're interested in supporting them.

egur

24th February 2015, 16:33

What matters to me is if the codec is supported by the Media SDK.
If a codec is supported by it, I can add support for it as well.
DXVA codec can be supported by LAN w/o me doing anything...

NikosD

24th February 2015, 19:01

Well, are they supported ?

I'm not sure and I don't know an easy way to check it out.

andyvt

24th February 2015, 19:38

Well, are they supported ?

I'm not sure and I don't know an easy way to check it out.

Look at the MSDK documentation. IIRC, the most recent version does not yet support these formats, but I might have missed a release.

NikosD

24th February 2015, 20:30

Latest MSDK documentation I have seen is from January 2014, more than one years old.

And I think latest MSDK is 2014 since January 2014.
In there, there is no VP8/VP9 support for sure.

But there is support in the drivers, though.

So, the MSDK is very old, but the drivers are fully updated.

Is this possible ?

andyvt

24th February 2015, 20:49

Within the realm of possibility? Probably, but it would entail a significant amount of [otherwise unnecessary] effort because you would have to build support for those formats into the parts of the MSDK that sit above the driver.

Nintendo Maniac 64

24th February 2015, 20:51

I'd like to mention that QuickSync-accelerated VP8 decoding wouldn't even be that useful since VP8 software decoding uses even less CPU utilization than h.264 baseline.

Now VP9? I could definitely get behind that.

NikosD

24th February 2015, 22:49

I've started to look into this. My new laptop is a Haswell so this should speed things up.

What matters to me is if the codec is supported by the Media SDK.
If a codec is supported by it, I can add support for it as well.
DXVA codec can be supported by LAN w/o me doing anything...

Within the realm of possibility? Probably, but it would entail a significant amount of [otherwise unnecessary] effort because you would have to build support for those formats into the parts of the MSDK that sit above the driver.

Eric, give me a hint.

If it's so difficult to build a decoder for a format not supported by MediaSDK, like VP8/VP9 albeit they are supported by the driver, then how are you going to support the hybrid HEVC decoder, which is also not supported directly by MediaSDK, but probably via a plugin, which I think it's a SW only implementation (not hybrid).

If I had to choose between hybrid HEVC and VP9, I would definitely go to VP9, because LAV already supports hybrid HEVC and there is no VP9 decoder.

xooyoozoo

25th February 2015, 00:06

There is also a VP8 decoder in Haswell

Where did you hear this?

AFAIK, the VP8 decoder only exists in Atom SoCs (at least Bay Trail) and Broadwell. Those chips also support hybrid VP9, so I'm guessing the VP9 decoder piggybacks the VP8 hardware blocks.

I don't think Eric will be able to test VP8/VP9 on Haswell (though my mental image of Intel engineers consists of them having a buffet of Intel chips to play with :)).

NikosD

25th February 2015, 03:28

I can see it in my system.

There is a VP8 MFT decoder.

xooyoozoo

25th February 2015, 04:13

Ah, you're right. My mistake.

egur

25th February 2015, 09:31

The latest Media SDK (2015) is part of a larger SW package called INDE.
It can be downloaded from here (https://software.intel.com/en-us/media-client-solutions).
The free version is good enough for developing QuickSync Decoder.
I have already updated the code to use the headers and library (r101 in qsdecoder's SVN).

NikosD

25th February 2015, 11:16

I have already downloaded INDE 2015 update 1 in order to use latest GPA 2014 R4 which is included inside.

But I haven't found documentation for MediaSDK 2015.

Could you provide us a link with that ?

Or should I install separately MediaSDK from INDE in order to get the documentation too ?

Thanks.

EDIT:

Look at the MSDK documentation. IIRC, the most recent version does not yet support these formats, but I might have missed a release.

In the release notes of INDE 2015 Update 1 there is this paragraph:

The Intel® INDE 2015 Media SDK for Windows* introduces API version 1.13

Versions of HW SDK library having API version 1.13 also support the following features of older API versions, previously unsupported:

o HW accelerated HEVC decode MAIN 10 profile via plugin interface. HW HEVC decode plugin is distributed with graphics driver. HEVC HW UID is defined in mfxplugin.h as MFX_PLUGINID_HEVCD_HW.

o HW accelerated VP8 decode via plugin interface. HW VP8 decode plugin is distributed with graphics driver. HW VP8 UID is defined in mfxplugin.h as MFX_PLUGINID_VP8D_HW.

o HW accelerated VP9 decode via plugin interface, HW VP9 decode plugin is distributed with graphics driver. HW VP9 UID is defined in mfxplugin.h as MFX_PLUGINID_VP9D_HW.

So, Eric and andyvt, there is everything inside MediaSDK 2015 and distributed with graphics driver.

All of the above HW decoders are hybrid, GPU accelerated (not ASIC).

According to this table https://communities.intel.com/message/273816#273816, Core Haswell has no HEVC 10bit/VP9 support, but it says nothing about VP8, which I think is supported, like HEVC 8bit.

Broadwell based Celeron/Pentium/ Core M have VP9 support, but no HEVC support and Broadwell Core iX support everything (HEVC 8bit/10bit, VP9)

You can find the whole MediaSDK 2015 release notes here:
https://software.intel.com/sites/default/files/managed/eb/ee/mediasdk_release_notes.pdf

egur

11th March 2015, 22:10

I started to look at the HEVC implementation for the Intel QuickSync Decoder.

I'll also try to get a clear picture on what codec/profile is supported on which platform/driver.

When I'm done coding, I'll need to build a test clip library for HEVC. I hope you guys can share some horribly hard clips :sly:

Also, since FFDShow (R.I.P) doesn't support the new codecs, all engineering/test builds will be LAV.

Zachs

11th March 2015, 23:30

Hi egur, just wondering if you've fixed the resource leak issue I reported about half a year ago?

xooyoozoo

11th March 2015, 23:32

I don't know much about the corporate structure at Intel, but you guys do offer HEVC (and VP9) stress clips. Maybe you can borrow a few? :)

There are some high bitrate HEVC clips floating around, but that mainly stresses entropy decoding. Ideally, the clip would be "legitimately" high-bitrate, instead of just low-QP, to make sure deblocking is actually on. To add a lot more complexity, TMVP skip-mode should be disabled and 8x8 weighted bi-prediction blocks should be used almost all the time.

egur

12th March 2015, 08:36

Hi egur, just wondering if you've fixed the resource leak issue I reported about half a year ago?
Couldn't find it in my code.

I don't know much about the corporate structure at Intel, but you guys do offer HEVC (and VP9) stress clips. Maybe you can borrow a few? :)

Intel has 100K employees. The lowest level manager I have in common with the graphics guys is the Intel president :)
In the past it was much more productive to ask users for test clips.
Using the Intel test clips is a little pointless since they are already being tested at Intel...

Zachs

12th March 2015, 10:31

Couldn't find it in my code.

From memory, you did manage to replicate the issue though correct?

egur

12th March 2015, 14:31

From memory, you did manage to replicate the issue though correct?
Yes, I replicated but couldn't isolate the leak to my code, MSDK or the graphics driver.

On my HTPC, the player run for many weeks and not have any issues that could have resulted from a serious leak.

Zachs

13th March 2015, 00:30

Yes, I replicated but couldn't isolate the leak to my code, MSDK or the graphics driver.

On my HTPC, the player run for many weeks and not have any issues that could have resulted from a serious leak.

The application we are using it with plays 1 minute footage files that are seamingly merged into one big footage. We get a resource leak each time a new file is opened/closed from the QuickSync decoder, which is quite catastrophic as it is not memory that leaks but GPU resource which is highly limited.

Are you saying the QuickSync decoder is only meant for HTPC purposes?

cybersans

24th March 2015, 15:48

guys, why always get stutter video of mp4 when there is no sound in the background, and huge delay between blank screen (for example pause from one scene to another scene)? also with a crash (lots of pixellated image) when forward/reverse or dragging the progress bar to another duration.

it happens to the mp4 and mkv if using ffdshow with quicksync decoder. i have no problem if using libavcodec for mp4 or for other format such as avi and so on.
anyway i am using windows 7 with windows media player with latest ffdshow and intel hd drivers .4072
the same goes with older drivers.

egur

25th March 2015, 14:17

Do you know which splitter is used?
Does it happen with LAV filters as the decoder (also has QS support)?

VFR maniac

25th March 2015, 15:29

Hi.
I encountered some AVC-in-AVI files crash at opening when LAV Splitter + QuickSync Decoder. (For other splitters, it works fine.)
It seems workaround added at r69 (http://sourceforge.net/p/qsdecoder/code/69/) uses the bitstream handler wrongly and could do out-of-bounds read.

The following patch fixes the crash but I'm not sure that the workaround also works on what originally introduces it. And I tested only on LAV Video Decoder, not ffdshow.

From e89b6c332fe5c6e2f401a23eca611a0b3351bc79 Mon Sep 17 00:00:00 2001
From: Yusuke Nakamura <muken.the.vfrmaniac@gmail.com>
Date: Wed, 25 Mar 2015 03:59:06 +0900
Subject: [PATCH] Fix possible out-of-bounds read of workaround for
DecodeHeader.

---
QuickSyncDecoder.cpp | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/QuickSyncDecoder.cpp b/QuickSyncDecoder.cpp
index 747f348..55e4ff0 100644
--- a/QuickSyncDecoder.cpp
+++ b/QuickSyncDecoder.cpp
@@ -419,9 +419,10 @@ mfxStatus CQuickSyncDecoder::DecodeHeader(mfxBitstream* bs, mfxVideoParam* par)
{
mfxBitstream bs2 = *bs;

+ bs2.DataOffset = 0;
bs2.Data = new mfxU8[bs->DataLength + 5];
- memcpy(bs2.Data, bs->Data + bs->DataOffset, bs->DataLength - bs->DataOffset);
- bs2.MaxLength = bs2.DataLength = bs->DataLength + 5 - bs->DataOffset;
+ memcpy(bs2.Data, bs->Data + bs->DataOffset, bs->DataLength);
+ bs2.MaxLength = bs2.DataLength = bs->DataLength + 5;

// Write H264 start code + start of splice section
*((unsigned*)(bs2.Data + bs2.DataLength - 5)) = 0x01000000;
--
1.9.2.msysgit.0

cybersans

25th March 2015, 15:46

Do you know which splitter is used?
Does it happen with LAV filters as the decoder (also has QS support)?

err is it because i am using haali? need to use lav?

theoneofgod

26th March 2015, 05:59

err is it because i am using haali? need to use lav?

Video Renderer and Decoder aren't the same things.

egur

26th March 2015, 17:22

NikosD

8th April 2015, 09:32

Main features

* HW deinterlacing -auto or forced, with half or full (50/60p) output rate

I tried using HW DI of LAV Video (Enable Adaptive HW Deinterlacing) during a transcoding and the speed is almost half compared to HW DI in the encoding stage.

It seems better (almost double speed) during transcoding to use the two different functions (Encoding, Deinterlacing) by the HW encoder and decoding only by QS decoder instead of two different functions (Decoding, Deinterlacing) using QS decoder and encoding only by HW encoder.

Is it a different algorithm used by QS decoder for DI compared to HW encoders, a different use of VPP engine or is it because of different pipeline usage ?

andyvt

8th April 2015, 09:40

I tried using HW DI of LAV Video (Enable Adaptive HW Deinterlacing) during a transcoding and the speed is almost half compared to HW DI in the encoding stage.

It seems better (almost double speed) during transcoding to use the two different functions (Encoding, Deinterlacing) by the HW encoder and decoding only by QS decoder instead of two different functions (Decoding, Deinterlacing) using QS decoder and encoding only by HW encoder.

Is it a different algorithm used by QS decoder for DI compared to HW encoders, a different use of VPP engine or is it because of different pipeline usage ?

When you DI in the decoder you are forcing a 2x increase in the # of frames output at that stage. Using this in a DS pipeline where the frames are copied from GPU to system memory this will cause a significant decrease in performance.

Is the encoder decimating or are you getting the same output in either case (e.g. 1080i30 ->1080p60)?

egur

8th April 2015, 09:43

It's the same DI in both cases and the same API calls to use it.
The performance difference is the the images in the encoding scenario stay in the GPU memory.
Also, are you using the DI in double or single rate in both cases?
Also when decoding, the HW DI takes GPU resources and lowers the overall performance.

The HW DI feature in QS Decoder is to view deinterlaced content. If you have the means to deinterlace in advance that will increase the performance of the decoder.

NikosD

8th April 2015, 10:39

When you DI in the decoder you are forcing a 2x increase in the # of frames output at that stage. Using this in a DS pipeline where the frames are copied from GPU to system memory this will cause a significant decrease in performance.

The performance difference is the the images in the encoding scenario stay in the GPU memory.
Also when decoding, the HW DI takes GPU resources and lowers the overall performance.
If you have the means to deinterlace in advance that will increase the performance of the decoder.

Thanks for the replies, they certainly explain a lot.

On the other hand though, one could think that because the decoding stage is a lot easier than encoding stage, the extra process of DI should be done at the easier stage, because the decoder is already a lot faster than encoder and the lowering of performance due to extra utilization of GPU resources shouldn't delay the encoder.

If you use the GPA monitor, you 'll see that during transcoding of progressive material the decoder is used like 25-30% and the encoder like 50-60% more or less.

So adding the extra process of DI to the encoding stage which is already too busy, should lower the performance even more.

Is the GPU frame copy to system memory penalty so big than even overcomes the delay of the encoding so much that the whole transcoding has almost half speed ?

Is the encoder decimating or are you getting the same output in either case (e.g. 1080i30 ->1080p60)?

Also, are you using the DI in double or single rate in both cases?

My setup as it is right now, allows me only 1080i25fps -> 1080p25fps conversion, so I used that in both scenarios.

I don't know yet if 1080i25fps -> 1080p50fps conversion shrinks the performance gap between those two scenarios.

andyvt

8th April 2015, 12:02

Thanks for the replies, they certainly explain a lot.

On the other hand though, one could think that because the decoding stage is a lot easier than encoding stage, the extra process of DI should be done at the easier stage, because the decoder is already a lot faster than encoder and the lowering of performance due to extra utilization of GPU resources shouldn't delay the encoder.

If you use the GPA monitor, you 'll see that during transcoding of progressive material the decoder is used like 25-30% and the encoder like 50-60% more or less.

So adding the extra process of DI to the encoding stage which is already too busy, should lower the performance even more.

Either way you need to decode->DI->encode. The DI HW is the same HW either way.

When you're doing it:

1) decode->DI->2((GPU->RAM)->(RAM->GPU))->encode

v.

2) decode->(GPU->RAM)->(RAM->GPU)->DI->encode

There is a significant performance hit for 1 because your copying 2x the data GPU->RAM->GPU.

Is the GPU frame copy to system memory penalty so big than even overcomes the delay of the encoding so much that the whole transcoding has almost half speed ?

Depending on the system it can be more resource intensive to copy the frame GPU->RAM than decode it in SW...

My setup as it is right now, allows me only 1080i25fps -> 1080p25fps conversion, so I used that in both scenarios.

I don't know yet if 1080i25fps -> 1080p50fps conversion shrinks the performance gap between those two scenarios.

When DI in the decoding stage as you are your are actually doing:

1080i25->1080p50->1080p25

vs.

1080i25->1080p25 (the MSDK will auto-decimate during DI in this scenario)

JohnLai

12th April 2015, 09:36

egur, how is the HEVC QS progress?

cybersans

15th April 2015, 05:07

Haali may produce horrible time stamps with some streams.
QS decoder tries to correct them and find the frame rate. I've seen cases where the time stamp are so wrong that QS decoder will guess the wrong frame rate.
LAV is much better in that sense.

Corruption after seeks have been visible for many years. Nothing I can do about it. libavcodec handles corrupted streams much better. Ideally the splitter will produce a proper stream after a seek, but both Haali and the LAV are not perfect.

Overall, I got a much better experience with the LAV splitter.

VFR maniac
Thanks for the patch! I recently noticed the bug during my work on HEVC.

dear egur, same thing happened either using lav or haali. i still experienced delay when there is no image (blank screen between scene) or a scene without any sound. i suspect ffdshow caused that, because in ffd video decoder; intel quicksync settings; when i click enable time stamp correction, there are no video corruption or delay between blank screen, but the audio is not sync with the video. when i untick that, corruption and delay in blank screen occured.

NikosD

23rd April 2015, 14:13

New drivers for Haswell & Broadwell v4170

New API v1.15

64 - http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=24870

32 - http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=24869

NikosD

28th April 2015, 13:31

Eric,

reading the Intel forums I'm under the impression that using MSDK to decode HEVC can be done in two ways: SW and HW.

For SW you need a SW plugin which is inside the MSS (Media Server Studio) and for HW (hybrid solution) you need another plugin - the MFX_PLUGIN_HEVCD_HW - which is inside INDE.

So, it seems that there are no solutions without plugins right now.

How are you going to implement your HEVC QS decoder ?

kalehrl

28th April 2015, 18:00

Taurus

28th April 2015, 20:29

I've just installed a discrete graphics card and I can no longer choose QuickSync in LAV filters nor use Intel HW 264 encoding.
Is there a way to use a discrete graphics and be able to use these 2 things in Windows 7 64bit?
Thank you.
Did you try this: https://mirillis.com/en/products/tutorials/action-tutorial-intel-quick-sync-setup_for_desktops.html
or this:https://mirillis.com/en/products/tutorials/action-tutorial-intel-quick-sync-setup_for_desktops_2_displays.html#top
Courtesy of mirillis...

P.J

29th April 2015, 10:09

NikosD

29th April 2015, 16:41

Win 8/8.1 have no need of the "fake" monitor setup.

But Win 7 needs that trick, in order to enable QuickSync.

kalehrl

29th April 2015, 19:40

Did you try this: https://mirillis.com/en/products/tutorials/action-tutorial-intel-quick-sync-setup_for_desktops.html
or this:https://mirillis.com/en/products/tutorials/action-tutorial-intel-quick-sync-setup_for_desktops_2_displays.html#top
Courtesy of mirillis...
Thank you for pointing me to these links.
At first, I wasn't able to fix the issue because when I clicked on 'Detect' button, no additional displays would appear.
Then I went into BIOS, IGP settings and enabled multiple monitors and then the instructions worked just fine.

Taurus

29th April 2015, 22:55

Then I went into BIOS, IGP settings and enabled multiple monitors and then the instructions worked just fine.
Aaah, I forgot about this....
The same happened to me a while back :devil:

NikosD

30th April 2015, 17:28

The new INDE 2015 Update 2 includes new MSDK as well, with API v1.15 documentation, mainly about HEVC encoding of Skylake.

So, it's official:
Skylake supports HW H.265 encoding.

Release notes:
https://software.intel.com/sites/default/files/managed/48/ce/mediasdk_release_notes.pdf

GTPVHD

4th May 2015, 15:32

http://www.anandtech.com/show/9219/the-surface-3-review/4

In addition to the GPU update, the ISP and hardware decode capabilities get a bump as well. There is full hardware acceleration for decode of H.263, MPEG4, H.264, H.265 (HEVC), VP8, VP9, MVC, MPEG2, VC1, and JPEG, as well as hardware encode for H.264, H.263, VP8, MVC, and JPEG. This marks the first Intel product to ship with the company's full, fixed-function HEVC decoder, making Atom the company's most advanced media processor, at least for this short moment.

NikosD

6th May 2015, 09:57

I've just realized that LAV x64 0.65 QS decoder uses SW fallback for VC-1/ WMV3 (!)

For the other formats (H.264, MPEG2) LAV x64 QS decoder works OK.

Also LAV x86 0.65 QS decoder works OK for all formats (H.264, MPEG2, VC-1/WMV3).

wanezhiling

25th July 2015, 15:10

https://downloadcenter.intel.com/download/25143/Intel-Iris-Iris-Pro-and-HD-Graphics-Driver-for-Windows-7-8-8-1-64-bit

https://downloadcenter.intel.com/download/25146/Intel-Iris-Iris-Pro-and-HD-Graphics-Driver-for-Windows-7-8-8-1-32-bit

Intel 10.18.14.4251 driver for Haswell & Broadwell.

I can't download 64-bit driver

P.J

27th July 2015, 11:19

I can't download 64-bit driver

Me neither

P.J

30th July 2015, 09:52

Thanks :D

clsid

30th July 2015, 13:28

Does this driver version also have P010/P016 bug? You can easily test by loading a 10bit video in GraphStudioNext.

NikosD

30th July 2015, 13:36

Of course it has the bug.
It's not fixed yet.

detmek

20th August 2015, 18:33

https://downloadcenter.intel.com/download/25232/Intel-Iris-Iris-Pro-and-HD-Graphics-Driver-for-Windows-7-8-8-1-64bit

https://downloadcenter.intel.com/download/25233/Intel-Iris-Iris-Pro-and-HD-Graphics-Driver-for-Windows-7-8-8-1-32bit

Intel 10.18.14.4264 driver for Haswell & Broadwell.

Thanks. Everything works as it should.

One question if anyone knows. This and previous drivers for Windows 8 support 4k H.264 decoding on Intel Pentium G3220 (Haswell). But drivers for Windows 10 (4256) only support up to full HD QSV decoding. Is it just an omission from Intel or they are removing 4k QSV decoding in Windows 10 for Pentium processors?

leonccyiu

6th September 2015, 06:15

Thanks. Everything works as it should.

One question if anyone knows. This and previous drivers for Windows 8 support 4k H.264 decoding on Intel Pentium G3220 (Haswell). But drivers for Windows 10 (4256) only support up to full HD QSV decoding. Is it just an omission from Intel or they are removing 4k QSV decoding in Windows 10 for Pentium processors?

I've only had windows 10 on my pentium g3258 and have never seen 4k hardware h264 decoding which would be really useful for me for high bit rate content

P.J

10th September 2015, 17:53

:thanks:

NikosD

11th September 2015, 17:39

https://communities.intel.com/thread/81511

Intel 10.18.15.4279 driver for Haswell, Broadwell & Skylake.

When you post new Intel drivers it would be even better if you post the release notes too.

For example I read in release notes of this driver that it supports and is certified for OpenGL 4.4

Unfortunately only for Broadwell and Skylake.

Haswell stopped in OpenGL 4.3 and OpenCL 1.2

Broadwell and Skylake go on to OpenGL 4.4 and OpenCL 2.0

leonccyiu

11th September 2015, 22:20

https://communities.intel.com/thread/81511

Intel 10.18.15.4279 driver for Haswell, Broadwell & Skylake.

Thanks for posting! Unfortunately I still don't have 4k h264 dxva decoding on my g3258 on windows 10.

detmek

12th September 2015, 10:54

Thanks for posting! Unfortunately I still don't have 4k h264 dxva decoding on my g3258 on windows 10.

Same here on G3220. I already wrote on their forum in 4256 driver thread and nothing changed. Now I have problem logging in so I can write about this in new driver thread.

NikosD

29th October 2015, 06:57

New drivers for the 15.40 family for Haswell and better.

Especially for Haswell, it works for Windows 10 x64 only.

Driver:
https://downloadcenter.intel.com/download/25489/Intel-Graphics-Driver-for-Windows-10-15-40-4th-Gen-

Release notes:
https://downloadmirror.intel.com/25489/eng/ReleaseNotes_GFX_15.40.10.4300.pdf

leonccyiu

30th October 2015, 01:44

Thanks for posting, 4K H264 hardware acceleration works for me now, it's frustrating that I had to wait all this time since February but better now than never.

baii

30th October 2015, 15:59

I have g3258 and 4279 win 10, 4k h264 qs worked fine on bbb.

Sent from my SM-T700 using Tapatalk

P.J

30th October 2015, 19:04

Display driver crashes after resuming from S3/Sleep...

P.J

31st October 2015, 16:05

NikosD

22nd November 2015, 08:15

New beta drivers from Intel v4326
https://downloadcenter.intel.com/download/25541/Intel-Beta-Graphics-Driver-for-Windows-7-8-1-10-15-40-

Release notes:
https://downloadmirror.intel.com/25541/eng/ReleaseNotes_GFX_15%2040%204326_Final.pdf

GTPVHD

15th December 2015, 03:43

https://downloadcenter.intel.com/download/25588/Intel-Graphics-Driver-for-Windows-7-8-1-15-36-28-4332-

Intel 10.18.14.4332(15.36 older branch) driver for Haswell Win7/8.1.

iwod

26th December 2015, 05:19

I did a search and nothing came up, its there a reason why Intel Quick Sync Encoder and Decoder are not available on Mac OSX platform?

huhn

27th December 2015, 01:47

I did a search and nothing came up, its there a reason why Intel Quick Sync Encoder and Decoder are not available on Mac OSX platform?

because no one has written one. at least this decoder is written for windows directshow.

benwaggoner

27th December 2015, 19:39

because no one has written one. at least this decoder is written for windows directshow.
MacOS leverages the Intel hardware for accelerated decode and like encode, however. So it's more a lack of a direct SDK versus the MacOS X APIs.

theoneofgod

23rd March 2016, 03:42

Will QuickSync variable refresh rate playing at the maximum frame rate be fixed or is it a problem with QuickSync that can't be other than by Intel? LAV has the same issue.

I believe this is the same problem: https://trac.mpc-hc.org/ticket/5110

amayra

2nd November 2016, 12:36

is this latest version of ffdshow ?

clsid

2nd November 2016, 16:21

No, latest version is 1.3.4533.

Development of ffdshow has stopped long ago. You should use LAV Filters instead. DXVA2 is also better than QuickSync.

CruNcher

7th November 2016, 02:52

Unfortunately it had some very unique ideas that gone lost with it.

P.J

11th November 2016, 17:59

Anyone with Cherrytrail/Braswell can test to help?

https://communities.intel.com/message/433628

P.J

12th November 2016, 07:50

https://downloadcenter.intel.com/download/26228

Your graphics driver is very old, try updating to 20.19.15.4501.

That didn't install on Braswell.

CruNcher

21st November 2016, 10:12

PJ which sample is that ?

Would like to test it on the Bay Trail Celeron Decoder previous version of your Chip, essentially :)

P.J

24th November 2016, 10:06

PJ which sample is that ?

Would like to test it on the Bay Trail Celeron Decoder previous version of your Chip, essentially :)

Bay Trail doesn't support HEVC at all.

Well, I found what was the issue, Braswell can't handle any 4K 50/60fps:
https://communities.intel.com/message/436619#436619

CruNcher

24th November 2016, 14:45

As wanezhiling said no good idea to use EVR CP for such a low power platform it's overhead could be already way to much and latency for that Playback Scenario way to high.

Especialy with the OSD active.

This isn't really different as if you try a High Complexity H.264 4K with Bay Trail it will fail the same way on EVR CP it works way way better on normal EVR.

You could also try to higher the EVR CP Buffer to smooth it out but it wont do that much magic if the whole system is to underpowered for the complexity level .

This Price Range of Systems is entirely only optimized for the normal customer WEB Experience you pressuring that low cost System heavily no normal user would do that, and you expect official support for that ;) .

NO Professional would even come to the idea asking Intel this.

60fps 50mbps that is not really a normal Scenario of Complexity for a AVG usecase for such a low cost System especially not in it's so young development timeframe.

60 FPS Broadcast Decoding is a whole different area you expecting to see working for this Generation.

Jesus you should be jumping around reaching 30fps 80mbps on that first generation low cost x86 system :)

You wont get anything else from Nvidia for example that could do this in the x86 space for that price ;)

I mean you totally make yourself a fool there especially with such nonsense you majorly hurt your credibility over there

As you see, 4K doesn't even touch 1GB of VRAM and Braswell can't handle any 4K 50/60fps, no wonder since Intel makes the worst graphic cards in the world.

And you seem to have 0 knowledge of Intels GPU Architecture as well, else you wouldn't say such a nonsense, what they achived over the last years from GMA to Intel HD is pretty Amazing.

P.J

24th November 2016, 17:37

Plain EVR can't help too since Braswell iGPU is damn weak and that's not because of the RAM/VRAM as they said incorrectly.
Wonder why it crushes the colors in H.265 but no problem with H.264. HEVC 8-bit is useless too since 10-bit has already replaced it.

CruNcher

24th November 2016, 18:47

Yeah sure has already replaced it you are the only existing human on earth i guess also ;)

We are right in the transition phase to 10 bit customer content and mostly only for 4K Premium Content and you speak about has replaced it already, listen to yourself.

P.J

24th November 2016, 22:53

What exactly do you mean here? You haven't been forced to post when you can't help.

Hope someone can find a newer driver for Braswell than this one:
https://downloadcenter.intel.com/download/25176/Intel-HD-Graphics-Production-Driver-for-Windows-10-64-bit-N-Series-?product=87257

P.J

25th November 2016, 21:52

win64_154028.4501.exe
Size: 203 MB (213,422,944 bytes)

http://phota.me/wfpq.png

GTPVHD

25th November 2016, 23:33

Try uninstalling the Asus customized graphics driver and see if the Intel driver would install, since the Intel installer is detecting Asus' customized driver.

No guarantees though, make sure you have the Asus driver installer if you can't install the Intel driver so you have some working driver to fallback to.

http://www.asus.com/Notebooks/E202SA/HelpDesk_Download/

But yeah, this is one reason to hate Intel's annoying stance at not supporting their own hardware with driver updates if the OEM decides to have customizations.

P.J

26th November 2016, 16:35