couple of questions (h264 MVC, frame packed output, CUI SDK, ...)

[madshi_net]

Hey Intel,

I'm working on a (freeware) DirectShow video renderer for HTPC use. I have a couple of questions related to that:

(1) Do any Intel GPUs support hardware decoding of h264 MVC? If so how can I access this functionality? If not, does the Media SDK support software MVC decoding?

(2) How can I switch Intel GPUs into frame packed 3D output mode? And how can I render 3D content? For simplicity's sake, let's just say I want to show a 3D photo on my HDMI 1.4 display in frame packed 1080p24 output mode. How can I do that with Intel GPUs? A small sample that does this would be awesome!

(3) I've been trying very hard for *months* to get access to the Intel CUI SDK. I've tried everything, contacting Intel support, contacting an "Authorized Distributor", writing on forums etc. No chance in hell, it seems. Why does Intel make it so hard to access such an important SDK? FWIW, both ATI/AMD and NVidia have public SDKs available which cover the same functionality as the CUI SDK.

Thank you, Mathias.

www.madshi.net
Systemsoftware Mathias Rauen

[Eric_S_Intel]

Hi Mathias,

I just wanted you to know that we got your questions and are working to get some answers to you. Its a bit outside our normal scope of MSDK support, so we have to track down the people that have this info.

-Eric

[madshi_net]

Hi Eric,

I very much appreciate that, thank you.

Best regards, Mathias.

[madshi_net]

Hi Eric,

any news on this?

It seems that the new Media SDK 3.0 Beta now includes MVC decoding. That partially answers my question (1). Can you comment on whether MVC decoding is supported in software and/or Sandy Bridge hardware? How about frame packed 3D output via HDMI 1.4?

Thanks, Mathias.

[Eric_S_Intel]

Hi Mathias,

MVC decoding is supported in software in the Media SDK Beta. Its available for download right now at:

http://software.intel.com/en-us/articles/intel-media-sdk-30-beta/

Getting the video driver to accept frame packed 3D output via HDMI 1.4 is another matter. For this issue weve been discussing it internally quite a lot. The good news is that I am confident that there will be a way for developers like yourself to set the driver into that mode. The open question is when and how. Theres a few efforts underway to have a solution available in the short term. Ill continue to update you as those efforts progress.

Eric

[madshi_net]

Thanks Eric,

that's pretty good news! :)

Can you comment on MVC hardware decoding support? From your comment it seems that Sandy Bridge does not yet support MVC hardware decoding, is that correct? No big problem for me, just for my interest.

The following two paragraphs only apply if Sandy Bridge does not support hardware MVC decoding, otherwise please ignore:

Another developer told me that he's doing MVC hardware decoding by sending the MVC slices to the DXVA2 decoder disguised as normal (left eye) 2D frames, then adding some software processing on top of that. That allows him to hardware decode large parts of MVC even with DXVA2 h264 decoders which do not really understand MVC themselves. Of course this solution works only if the DXVA2 decoder is fast enough to handle the additional load. Maybe this would be an idea that could be integrated into the Intel Media SDK, too?

What happens if I want to use as much hardware decoding as possible. Does the Intel Media SDK allow me to decode the left eye stream via hardware and the (MVC) right eye stream via software? Or is that combination not supported? That would be a small disadvantage, of course, because it would practically mean that as soon as MVC is involved, not even the left eye stream can be decoded by hardware, anymore.

Thanks again, Mathias.

[Eric_S_Intel]

Hardware based MVC decoding will be available using the Intel Media SDK 3.0 on Intels next generation platform. The beta is being made available now to get a jump start on next years media products.

Using native DXVA with multiple decoders to achieve MVC playback on Sandy Bridge will work, but the effort from a development perspective is quite large. MSDK 3.0 provides a much easier path.

-Eric

[madshi_net]

My thinking was that MSDK 3.0 could offer hardware MVC decoding for Sandy Bridge, too, by *internally* doing all the nasty work like using multiple h264 hardware decoders etc. This way MSDK 3.0 users would have a very easy MVC hardware decoding path that works for both Sandy Bridge and Ivy Bridge+.

That said, it's not really important to me at all. Software MVC decoding for Sandy Bridge is just fine with me. Actually it's great, more than I expected! :)