Intel Media SDK - Quick Sync Video

[NikosD]

Originally Posted by rtabrah

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 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]

Originally Posted by NikosD

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.

Originally Posted by NikosD

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]

Originally Posted by andyvt

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.

Originally Posted by andyvt

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]

Originally Posted by NikosD

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 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.

Originally Posted by NikosD

How can you be so sure ?

About which part?

Originally Posted by NikosD

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]

@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/arti...ress-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]

Originally Posted by nevcairiel

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]

Originally Posted by andyvt

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]

Originally Posted by nevcairiel

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]

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]

Originally Posted by nevcairiel

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]

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.