Log in

View Full Version : Intel Media SDK - Quick Sync Video


rtabrah
26th June 2012, 22:35
Hello fellow video technologists -

Long time follower, newb poster. I'm the Product Manager for the Intel Media SDK (http://intel.com/software/mediasdk), the free SDK that allows developers to gain access to Intel's line of HW acceleration technologies now built into our main Core line of processors.

Any technical issues must be handled in Intel's free support forums (http://software.intel.com/en-us/forums/intel-media-sdk/?wapkw=(media+sdk+forums)).

I will also not be able to disclose any non-public information in a public forum, so please be understanding if any of my answers are vague around future chipset features or SDK releases.

I'll be monitoring this for general questions and comments and suggestions about our technology/samples/products/tools. You can always contact me directly via twitter @IntelMediaSDK.

In fact, we are giving away 2 Core i7 2600k CPU's by the end of the week for anyone that follows/retweets by 6/28/12 @IntelMediaSDK. (must be in the U.S.)

I'll also be at SIGGRAPH 2012 in LA - we'll be giving away some IVB Ultrabooks and Intel SSD's at the show - so ping me if you want to meet up in August.

-Ryan Tabrah

Guest
26th June 2012, 22:55
In fact, we are giving away 2 Core i7 2600k CPU's by the end of the week for anyone that follows/retweets by 6/28/12 @IntelMediaSDK. (must be in the U.S.) You mean you will randomly choose 2 followers to give the CPUs to? How do I "follow" you to be included in the drawing? Have to have a twitter account?

rtabrah
26th June 2012, 23:05
You mean you will randomly choose 2 followers to give the CPUs to? How do I "follow" you to be included in the drawing? Have to have a twitter account?

Yes - you must have a twitter account and then become a follower of @IntelMediaSDK. (this is free to do) We'll randomly choose a follower (we don't have many). If you retweet about our drawing, you'll get 2 entries.

I was literally cleaning up my cube and found these and its a tragedy that they are still in the box. These CPU's need a new home.

Guest
27th June 2012, 00:51
What if we don't want to have a twitter account? Seems a bit silly to force some stupid social media thing on people. I'm a developer that could probably do you some good. I'm excluded because I don't want a stupid twitter account? :stupid:

I've not addressed your technology previously though people have requested it because I don't have a suitable CPU. Can I at least be entered in the drawing?

http://neuron2.net

rtabrah
27th June 2012, 01:13
What if we don't want to have a twitter account? Seems a bit silly to force some stupid social media thing on people. I'm a developer that could probably do you some good. I'm excluded bcause I don't want a stupid twitter account? :stupid:

I've not addressed your technology previously though people have requested it because I don't have a suitable CPU. Can I at least be entered in the drawing? Or are you just using us for your marketing, which would violate our forum rule 5?

http://neuron2.net

We totally understand not everyone is a user or fan of social media. I'll be happy to enter you manually - no problem. I just wanted these CPU's to find a good home.

Guest
27th June 2012, 02:03
Thanks very much, Ryan!

And thank you for your PM which I will respond to shortly.

And one more thing...welcome to the forum!

ciao,
Don

CruNcher
28th June 2012, 15:15
@rtabrah
Welcome 1 request unlink the Display Connection from the DSP usage, im currently switching like in the 90s displays just to be able to use the DSP Encoder and im not sure for what you would need Virtu for this as the end result endsup in a file not on screen (Unlocked & Unleashed) ;)

@rtabrah
1 of those puppies would find a good home @ neuron2 for sure :)

mastrboy
29th June 2012, 18:40
We totally understand not everyone is a user or fan of social media. I'll be happy to enter you manually - no problem. I just wanted these CPU's to find a good home.

That might result in a DGIndexQS from neuron2, which will make a lot of the users on this forum quite happy ;)

kypec
4th July 2012, 21:08
That might result in a DGIndexQS from neuron2, which will make a lot of the users on this forum quite happy ;):goodpost:
I upvote the idea to donate one CPU directly to neuron2, he surely deserves that and might contribute to wide public much more than any other "random lucky bastard" who just happened to have a twitter account. Honestly, if only this is supposed to be a "feature" that gives one an advantage at drawing then I don't know what to say about such attitude of a donor. :eek:

rtabrah
1st August 2012, 19:25
Reminder: I'll be at SIGGRAPH 2012 in LA all next week if anyone wants to meet up - ping me or email me.

NikosD
5th January 2013, 09:15
Hello Ryan.

For some reason I didn't know about this thread, I thought only Eric had an Intel thread.

One question:
Is there any particular reason that Intel MSDK is using DXVA copy-back and not direct, vanilla DXVA ?
The latter is preffered by many people.

nevcairiel
5th January 2013, 10:16
The MSDK does nothing of that sort. Its just an API to decode video. The decision to copy the image to system ram or keep it on the D3D surface is completely up to the user of the API.

NikosD
5th January 2013, 10:56
That answer surprises me and I have to ask, then why don't we have a QuickSync decoder utilizing native DXVA through MSDK ?

I've asked Eric and I think he replied because of MSDK restrictions....

Nev, can you and Eric and Ryan cooperate in order to have a native QS decoder ?

Next question:

Why Intel is keeping VC-1 non DXVA compliant ?
H.264 and MPEG-2 are working fine with DXVA.

What's so special with VC-1 anyway, to have a different treatment ?

nevcairiel
5th January 2013, 11:07
Nev, can you and Eric and Ryan cooperate in order to have a native QS decoder ?


We could, but we have better things to do. The "many people" that prefer it is just you.

NikosD
5th January 2013, 11:20
Ha, ha
You are funny.

A native QS decoder with minimum CPU utilization and minimum Power requirements for desktops/ servers/ laptops is only for me ?

Why do you even bother involving to HW acceleration ?

Leave it to CPU decoding if it's only me...

andyvt
5th January 2013, 16:02
That answer surprises me and I have to ask, then why don't we have a QuickSync decoder utilizing native DXVA through MSDK ?



The MSDK includes a decoder filter that does exactly that. I modified it a little to add QS transcode support in DTB.

Guest
5th January 2013, 23:50
I'll be happy to enter you manually - no problem. I just wanted these CPU's to find a good home. Did I win? If not, who did?

rtabrah
1st February 2013, 18:27
One question:
Is there any particular reason that Intel MSDK is using DXVA copy-back and not direct, vanilla DXVA ?
The latter is preffered by many people.

then why don't we have a QuickSync decoder utilizing native DXVA through MSDK ?

Why Intel is keeping VC-1 non DXVA compliant ?
H.264 and MPEG-2 are working fine with DXVA.



Sorry for the delayed response - its been a busy January:

Your questions about DXVA copy-back vs. vanilla DXVA and VC-1 are somewhat related to design decisions around our HW/driver solution. One of the reasons the Intel Media SDK was designed and productized was to make it easier and simpler for developers to access HW features without worrying about DXVA compliance differences between driver or HW iterations. That being said, if you need help with working around these specific issues, my enabling engineers have said they'd love to support your efforts. Feel free to post specifics in a private or public fashion on our support forum (http://software.intel.com/en-us/forums/intel-media-sdk/?wapkw=(media+sdk+forums)) or you can email me directly and I can get you connected with the right folks.

rtabrah
1st February 2013, 18:31
The MSDK does nothing of that sort. Its just an API to decode video. The decision to copy the image to system ram or keep it on the D3D surface is completely up to the user of the API.

Great answer - the Intel Media SDK is actually primarily an interface to access HW acceleraters for Encode, Decode, Transcode, and Video processing filters - not just decode.

rtabrah
1st February 2013, 18:33
Did I win? If not, who did?

Unfortunately you weren't randomly picked. I'll keep you posted if there's another drawing or giveaway.

NikosD
1st February 2013, 18:47
Sorry for the delayed response - its been a busy January:

Your questions about DXVA copy-back vs. vanilla DXVA and VC-1 are somewhat related to design decisions around our HW/driver solution. One of the reasons the Intel Media SDK was designed and productized was to make it easier and simpler for developers to access HW features without worrying about DXVA compliance differences between driver or HW iterations. That being said, if you need help with working around these specific issues, my enabling engineers have said they'd love to support your efforts. Feel free to post specifics in a private or public fashion on our support forum (http://software.intel.com/en-us/forums/intel-media-sdk/?wapkw=(media+sdk+forums)) or you can email me directly and I can get you connected with the right folks.

No, I'm not a developer.
I'm a user who is helping developers and other users to implement and use things (decoders, splitters, transcoders, players) as better and free as possible.

And because PotPlayer's developers and nevcairiel have complained about proper native DXVA VC-1 support and because DXVA copy-back is slower and more power hungry implementation, that's why I asked you those questions.

So thank you for your answer about helping me, it's very kind but I would prefer helping PotPlayer's and other free software video player developers like MPC-HC, implementing native DXVA VC-1 support, because last time I checked they couldn't do it.

I hope they have read your answer and they are willing to do it.
Work together with your engineers to the job.

I think it's the first time that someone officially has said that VC-1 DXVA implementation can be supported by other decoders/players than Cyberlink and ArcSoft.

One last question:

What is the specific technical reason for not supporting 4K H.264 DXVA acceleration on SandyBridge ?

Thank you in advance

andyvt
1st February 2013, 18:57
So thank you for your answer about helping me, it's very kind but I would prefer helping PotPlayer's and other free software video player developers like MPC-HC, implementing native DXVA VC-1 support, because last time I checked they couldn't do it.


It's not that they can't provide the feature, it's that the implementation needs to be specific to Intel (i.e. you can't write once, in a HW agnostic way). If they were motivated enough they could leverage same APIs that Eric Gur did in his decoder but subtract out the copy to system RAM part at the end.



What is the specific technical reason for not supporting 4K H.264 DXVA acceleration on SandyBridge ?



The reason why HWA decode (and encode) is so fast and power efficient is because it uses fixed function HW. SNB doesn't have the HW bit necessary to handle 4K.

NikosD
1st February 2013, 19:04
It's not that they can't provide the feature, it's that the implementation needs to be specific to Intel (i.e. you can't write once, in a HW agnostic way). If they were motivated enough they could leverage same APIs that Eric Gur did in his decoder but subtract out the copy to system RAM part at the end.


I was reffering to DXVA VC-1 support as you can see in my quoted reference that you mention, because for MPEG-2 and H.264 you don't need Intel MSDK to HWA them or any other help from Intel engineers.


The reason why HWA decode (and encode) is so fast and power efficient is because it uses fixed function HW. SNB doesn't have the HW bit necessary to handle 4K.

How can you be so sure ?
Can you provide me the HW details of QuickSync 1.0 (SNB) vs QuickSync 2.0 (IVB) ?
Because QS 2.0 supports 4K without being much faster than QS 1.0

andyvt
1st February 2013, 19:30
I was reffering to DXVA VC-1 support as you can see in my quoted reference that you mention, because for MPEG-2 and H.264 you don't need Intel MSDK to HWA them or any other help from Intel engineers.


I understood your question.

The short answer is because they added support for the standard (http://msdn.microsoft.com/en-us/library/windows/desktop/ms697067%28v=vs.85%29.aspx) DXVA for those codecs and not for VC-1. It wasn't always that way, before Clarkdale (i.e. GMA X4500HD) the DXVA implementation for MPEG2/H.264 was proprietary (ClearVideo) as well.

If you're really interested in the fundamentals, fire up the MPC-HC DXVA video decoder on Intel HW in a debugger and it will become readily apparent why it [sort of] works for MPEG2/H.264 and not for VC-1.

Bottom line if they wanted to add HWA decode, the necessary bits are all there - you just don't get it for free.


How can you be so sure ?


About which part?


Can you provide me the HW details of QuickSync 1.0 (SNB) vs QuickSync 2.0 (IVB) ?
Because QS 2.0 supports 4K without being much faster than QS 1.0

I only have marketing slides on the topic. What are you looking for?

nevcairiel
1st February 2013, 19:50
@rtabrah
Eric Sardella once wrote a whitepaper how to properly use the (proprietary) ClearVideo H.264 interface back on the older Intel GPUs, which elaborated on the specific differences required to use it. Luckily SNB and IVB now implement the standard H.264 DXVA decoder, and its no longer required.
http://software.intel.com/en-us/articles/using-h264avc-directx-video-acceleration-with-the-intel-g45gm45-express-chipsets/

However, if the same kind of information present in this document could also be provided for VC-1, i would be happy to implement it for full Intel VC-1 DXVA2 support, which would be contributed back to ffmpeg for everyone to use.
I don't need a fancy document, i just need to know what to do. :)

andyvt
1st February 2013, 20:06
However, if the same kind of information present in this document could also be provided for VC-1, i would be happy to implement it for full Intel VC-1 DXVA2 support, which would be contributed back to ffmpeg for everyone to use.
I don't need a fancy document, i just need to know what to do. :)

Have you looked at the source for the DXVA VC-1 decoder included in the MSDK? Might not be what you're looking for though.

nevcairiel
1st February 2013, 20:12
Have you looked at the source for the DXVA VC-1 decoder included in the MSDK? Might not be what you're looking for though.

The actual decoder is in the MSDK itself, hidden away from our curious eyes. The sample decoder just wraps the MSDK API, like Erics QuickSync decoder does.

andyvt
1st February 2013, 20:16
The actual decoder is in the MSDK itself, hidden away from our curious eyes. The sample decoder just wraps the MSDK API, like Erics QuickSync decoder does.

Yeah, if you want to implement the DXVA part yourself it won't help, but it would get the job done; encoded video in -> dxva out :).

nevcairiel
1st February 2013, 20:25
Erics decoder could do this, its just a bit complex to do all the DXVA handling, which is why its not done yet. It would be easier to just support Intel VC-1 in ffmpegs DXVA code, one code-base for all, no special solutions, less maintenance.

andyvt
1st February 2013, 20:31
Erics decoder could do this, its just a bit complex to do all the DXVA handling, which is why its not done yet. It would be easier to just support Intel VC-1 in ffmpegs DXVA code, one code-base for all, no special solutions, less maintenance.

Can't argue with that :).

FWIW, when we met with Intel at CES I asked them to add standard VC-1 DXVA support.

andyvt
19th March 2013, 15:12
For anyone interested I modified one of the transcoding samples in the MSDK to use ffmpeg for container and audio transcoding support. The primary intended use case is to create files suitable for mobile devices. The impetus was that no retail vendors offer proper support for MKV files w/ HBR audio tracks or edit lists (i.e. where the commercials are) for transcoding mobile friendly files using QS.

Binary and source is available here (http://babgvant.com/files/folders/random/entry21946.aspx).