We have been using a simple MFXInit() to test of Quicksync is available, but I now realized that when we run our program as a service, the very same MFXInit() always fails. That leads me to believe Quicksync (or any is not available to a Windows service...
Much to my disappointment, I found this thread : http://software.intel.com/en-us/forums/topic/311956, which leads me to indicate there is no solution for this problem, with graphics drivers not available to "session 0" .. (I have no experience with Windows services - others have worked on that part in our project). Very unfortunate - we relied on Quicksync for much improved transcoding performance.
Thanks for your reply, Sergey. It seemed clear from the thread I pointed to, services in session 0 do not have access to the necessary APIs (DirectX), which unfortunately QuickSync relies on. In any case, the error is MFX_ERR_UNSUPPORTED (-3). I guess my question really was more of a statement, expressing my frustration after having spent time and effort implementing a wickedly fast QuickSync based encoder, then having it blocked by this problem.
I am not working on that part of our code, but I will ask. It's running in session 0 and has no access to the required APIs, just like the thread describes as well as Tony writes above, where he also states it is possible on Windows 8, but not Windows 7. As there was no solution posted the thread I mentioned, I am curious what you are suggesting, that the good folks at Intel do not know about?
Argh, I just wrote another reply, and it was lost...
I wrote that we our service is a system service running for all users, and when no one is logged on. We have a separate per user systray notification exe, as well as an explorer shell extension. These three communicate via indirect means some of which are described here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms683502(v=vs.85).aspx. I guess the service could farm out encoding jobs to the systray app, in theory, but the communication would be awkward, but most importantly it would only work when someone is logged on and the systray running.
IIRC windows services run under various accounts like local sytem ,user account or network service and these services are pinned to non-visible window station.Session Zero further restricts the services from interacting directly with the desktop.I have been able to find that this parameter "SERVICE_INTERACTIVE_PROCESS" must be present in service's registry key TYPE parameter.Service which run under user account can not be marked as a interactive.
iliyapolak: Are you describing the "Allow service to interact with desktop" in the Log On tab for service properties? I tried this, and it makes no difference for Quicksync availability. I was also told "It's a deprecated option for interop with very old services".
Sergey: I agree, I am not discussing theory. My point was we cannot use a lightweight traybar app for encoding, when we need encoding services to run without a user being logged on. I am still awaiting an answer to how you are suggesting this can be solving in practice.
Microsoft's solution for "graphics device" usage from a service has been the creation of D3D11 (a.k.a. DX11). We understand this forward progress does not solve limitation in Microsoft's architecture for older platforms.
To clarify, issue on DX9-based platforms is more then just session 0 running without a user, it is 'access to graphics device acceleration' while running without a user.
Thanks, Tony, for clarifying. I am pretty sure I understand the situation on Windows 7. It is unfortunate, but an architetural/design limitation imposed by Windows DX9. We do not have time to focus on Windows 8 at the moment, but will keep that, and Quicksync in mind, for later.
Thanks, iliyapolak, but I think Tony from Intel clarified the situation well. In Windows 7 with DX9, Quicksync is not available while running without a user. In Windows 8 with DX11, Quicksync and graphics device acceleration is available.
I don't really know. I can only refer to what Tony from Intel just wrote: it requires D3D11 and Windows 8. I can only guess that Microsoft does what they usually do, and which I have been running into with their Media Foundation encoders and decoders: all the nice features require Windows 8 :( even though the basic functionality is there on Windows 7.