Intel Media SDK within a locked desktop (session 0)

Intel Media SDK within a locked desktop (session 0)

When we will have access to the GPU decoding/encoding within a locked desktop (from session 0) after all? This will increase the performance of server/terminal applications dramatically. And, therefore, determined the choice of the "right" hardware manufacturer. As far as I know, to date, only nvidia tesla provides such opportunities.

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi dj_alek,

Can you expand a bit more on your issue. What do you mean by locked desktop? Are you referring to machine that does not have a display attached?


I mean access to the hardware decoding/encoding/resizing/etc (GPU, not CPU). DirectX layer is used for this purpose.Hardware DX isn't available at session 0 (services sandbox). Microsoft says: for security reasons - onlyinteractive user (who sees the desktop on a locally mounted display) can access hardware DX. So, need to create separate process on behalf of the interactive user. Furthermore, local desktop must never be locked (via Win+L, for example).Thus, we have the serious complexity of implementation (and absence of hardwarefor some times) withusers switching, serverappliances, etc.What kind of "increased security"in question, when we make a server with never locked desktop?To which sticker "in any case, do not block the desktop!!!"is attached:)In my opinion, allowing access to hardware from session 0 is disadvantageous to operating systems manufacturers, but is profitable for GPU manufacturers.Not a bad decision: to add a driver of some "calculation device" (with separate access control settings, not restricted to interactive user only), in addition to videocard driver, imho.

Best Reply

Thanks for clarifying, I completely understand what it is you are after now.

Unfortunately, as you also point out, we cannot use Media SDK with HW acceleration in a Windows service due to OS restrictions. This is a well known limitation that we do not have control over. We may explore alternative approaches in future releases of the SDK but for now there is nothing we can do.

This subject was also discussed in earlier forum thread, including reference to external forum thread where potential workarounds are discussed.


I'll be glad to see it in future versions.

Leave a Comment

Please sign in to add a comment. Not a member? Join today