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.
IM SDK versus Win7 MFT sync (software path) h264 transcode
Lun, 04/11/2013 - 08:38