IM SDK versus Win7 MFT sync (software path) h264 transcode

[ME]

[cpp]Win7 MFT sync Transcode compared to IM SDK
(software path)
H.264
1280 x 720 shrink to half size (640 x 368)
Target is 500 kbps.  FWIW, the source is 2 Mbps
 
My normalized (software path) results:
 
                     MFT sync    IM SDK
 
 resize for speed     0.98        1.0     encode MFX_TARGETUSAGE_BEST_SPEED
 resize for quality   2.81        1.4     encode MFX_TARGETUSAGE_BALANCED
 
That is to transcode a single frame.
 
The resizer in win7 is classified as a video
effect DSP/MFT.  The one in Win8 is a real VPP,
but Win7 is stuck with the resizer.  The runs
were in real-time: 30 fps.
 
According to taskmgr:
 
CPU for the app was 10 to 15% for IM SDK.
For MFT sync it was 20 to 25%.  Each was
using the "fast" path. No, that doesn't
follow the overall transcode times...
but then...
 
I didn't mention that the Win7 MFT sync path
uses all (four) cores (when tested doing
an in-memory transcode).  That would explain
why its time-to-transcode is faster (a bit)
but uses more CPU.  Given this application
will do this only in real time (30 fps) the
lower CPU use matters much more than the time
per transcoded frame.  With IM SDK I do a
sync once per dec->vpp->enc frame.
 
A lower delay is preferred.  MFT sync or async
wants 19 frames before it outputs anything from
its decoder.  I get an encoded frame right away
using IM SDK.
 
The MFT sync CPU use was 33 to 40 % when using
the quality path of the resizer DSP/MFT. For
IM SDK using balanced, 14 to 22 %.
 
Display was at another app (same machine, MFT
async, and essentially zero CPU used for that).
 
A current CPU should be half that.
I have not done a HW path yet - TBD.[/cpp]

[Petter_L_Intel]

Hi,

Based on your message I do not fully understand your request or concern. Could you please clarify if there is a specific issue you are encountering?

Regards,
Petter 

[ME]

No concern.

Exec. summary: re: software transcode: IM SDK vs Win7 MFTs: IM SDK is about 2-3 times faster similar quality.

[wang_d_]

I use Intel Media SDK 2013 for decode the h264 video,but the speed is slowly.Who can tell me why it is?

the SDK have the sample decode project, I changed the function ParseInputString in sample_decode.cpp

insert some code like this :

pParams->videoType = MFX_CODEC_AVC;

char* test_my = "D:\\win32\\1080pTst.h264";

TCHAR* haha = char2tchar(test_my);

memcpy(pParams->strSrcFile, haha,2*wcslen(haha)+1);
pParams->bOutput = true;

char* test_dest = "D:\\win32\\Tst_yuv_1080.yuv";

TCHAR* haha_dest = char2tchar(test_dest);

memcpy(pParams->strDstFile, haha_dest,2*wcslen(haha_dest)+1);

pParams->bLowLat = true;

I deleted the for() sentence in the function (ParseInputString )

Right now it can work ,but the decode speed is solwly, decode the 2048*1536 video , its real frame rate is 11,the std frame rate is 18.

And when I decode the 1080P video ,its real frame rate is 17, but the std frame is 30.

WHO CAN TELL ME WHY? SHOULD I SET SOME PARAMETER? PLEASE ANSWER ME ,THANK YOU !

[Petter_L_Intel]

Hi Wang,

based on your description is seems that the vast majority of your execution time is spent on writing the raw decoded frames to the file system. If you want to assess the real performance of HW accelerated decode then I suggest you remove all raw data file access and any additional raw data mem copies. Also, for best performance when using HW acceleration I suggest you try to use D3D memory surfaces.

Regards,
Petter