View Full Version : Intel QuickSync Decoder - HW accelerated FFDShow decoder with video processing
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
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.
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
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.
So this explains the out of sync audio while converting with QSV?
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
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.
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).
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.