HW vs SW decoding times are the same on Intel HD Graphics 4000

[Zach_J_1]

I am running a 13" MacBook Pro with bootcamp installed and running Windows 7 Ultimate, 64-bit edition.  The CPU is Intel Core i5-3210M with Intel HD Graphics 4000.  I have updated the graphics drivers to the latest version on Intel's website (9.18.10.3071).  I am following the Intel Media SDK with ffmpeg integration white paper.   

sys_analyzer output:

Intel Media SDK System Analyzer (64 bit)

The following versions of Media SDK API are supported by platform/driver:

Version Target Supported Dec Enc
1.0 HW Yes X X
1.0 SW Yes X X
1.1 HW Yes X X
1.1 SW Yes X X
1.3 HW Yes X X
1.3 SW Yes X X
1.4 HW Yes X X
1.4 SW Yes X X
1.5 HW Yes X X
1.5 SW Yes X X
1.6 HW Yes X X
1.6 SW Yes X X

Graphics Devices:
Name Version State
Intel(R) HD Graphics 4000 9.18.10.3071 Active

System info:
CPU: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
OS: Microsoft Windows 7 Ultimate 
Arch: 64-bit

Installed Media SDK packages (be patient...processing takes some time):
Intel® Media SDK 2013 (x64)

Installed Media SDK DirectShow filters:
Intel® Media SDK MP3 Decoder :
C:\Program Files\Intel\Media SDK 2013\samples\_bin\x64\imc_mpa_dec_ds.dll
Intel® Media SDK JPEG Decoder :
C:\Program Files\Intel\Media SDK 2013\samples\_bin\x64\jpeg_dec_filter.dll
Intel® Media SDK MPEG-2 Splitter :
C:\Program Files\Intel\Media SDK 2013\samples\_bin\x64\imc_mp2_spl_ds.dll
Intel® Media SDK H.264 Encoder :
C:\Program Files\Intel\Media SDK 2013\samples\_bin\x64\h264_enc_filter.dll
Intel® Media SDK MVC Decoder :
C:\Program Files\Intel\Media SDK 2013\samples\_bin\x64\mvc_dec_filter.dll
Intel® Media SDK AAC Decoder :
C:\Program Files\Intel\Media SDK 2013\samples\_bin\x64\imc_aac_dec_ds.dll
Intel® Media SDK MPEG-2 Decoder :
C:\Program Files\Intel\Media SDK 2013\samples\_bin\x64\mpeg2_dec_filter.dll
Intel® Media SDK MP4 Splitter :
C:\Program Files\Intel\Media SDK 2013\samples\_bin\x64\imc_mp4_spl_ds.dll
Intel® Media SDK MPEG-2 Muxer :
C:\Program Files\Intel\Media SDK 2013\samples\_bin\x64\imc_mp2_mux_ds.dll
Intel® Media SDK MP4 Muxer :
C:\Program Files\Intel\Media SDK 2013\samples\_bin\x64\imc_mp4_mux_ds.dll
Intel® Media SDK H.264 Decoder :
C:\Program Files\Intel\Media SDK 2013\samples\_bin\x64\h264_dec_filter.dll
Intel® Media SDK MP3 Encoder :
C:\Program Files\Intel\Media SDK 2013\samples\_bin\x64\imc_mpa_enc_ds.dll
Intel® Media SDK AAC Encoder :
C:\Program Files\Intel\Media SDK 2013\samples\_bin\x64\imc_aac_enc_ds.dll
Intel® Media SDK MPEG-2 Encoder :
C:\Program Files\Intel\Media SDK 2013\samples\_bin\x64\mpeg2_enc_filter.dll
Intel® Media SDK VC-1 Decoder :
C:\Program Files\Intel\Media SDK 2013\samples\_bin\x64\vc1_dec_filter.dll

Installed Intel Media Foundation Transforms:
Intel® Hardware M-JPEG Decoder MFT : {00C69F81-0524-48C0-A353-4DD9D54F9A6E}
Intel® Hardware VC-1 Decoder MFT : {059A5BAE-5D7A-4C5E-8F7A-BFD57D1D6AAA}
Intel® Hardware H.264 Decoder MFT : {45E5CE07-5AC7-4509-94E9-62DB27CF8F96}
Intel® Hardware MPEG-2 Decoder MFT : {CD5BA7FF-9071-40E9-A462-8DC5152B1776}
Intel® Quick Sync Video H.264 Encoder MFT : {4BE8D3C0-0515-4A37-AD55-E4BAE19AF471}
Intel® Hardware Preprocessing MFT : {EE69B504-1CBF-4EA6-8137-BB10F806B014}

Analysis complete... [press ENTER]

Both of the commands listed below execute in about 2.5 minutes for a 30s mp4 container w/ h264 encoded video stream.

sample_decode.exe h264 –i file.mp4 -hw -d3d -split –o video.yuv

sample_decode.exe h264 –i file.mp4 -d3d -split –o video.yuv

I am trying to test the first sample workflow in the ffmpeg whitepaper and I am getting the same exact decoding time if I use hw or sw decoding.  I assume that hw deciding uses the Quick Sync hardware to decode?  Shouldn't this be much faster than sw decoding?

Thanks in advance!

Zach

[Zach_J_1]

I have attached Intel Media SDK Tracer logs for the -hw option to this post.

[Anthony_P_Intel]

Hi,

The video decode is quickly being decoded in hardware but the use of a container (-split) and the writing of uncompressed file output can be significant contributers to the overall task.

[Anthony_P_Intel]

Hi,

The video decode is quickly being decoded in hardware but the use of a container (-split) and the writing of uncompressed file output can be significant contributers to the overall task. 

-Tony

[Zach_J_1]

That makes a lot of sense.  Ultimately I'm trying to integrate FFmpeg into the the sample_multi_transcode application to accept one input file, demux and decode the file and transcode and mux into multiple file formats at the same time.  I would like to pipeline the input to the outputs as well so I don't have to actually save the "uncompressed file".  Is this something that is possible?

Zach