Comparision H.264 encoder parameter between Intel MSDK with x264

[ganenew]

First, I'm sorry to compare Intel MSDK with x264, because my job is related about mirrorop domain and some

h.264 codecs must be tested or measured in order to be able to apply to our real-time application. Currently, I take

Intel MSDK and x264 to compare the encoding performance with varying parameter adjustment. Some features

can be found that1. Intel MSDK has less adjustable parameter than x264 and some important parameters which

would affect the complexity of codec have been reserved (such as MESearchType, MVSEARCHWindow or

MVPrecision etc...), (2. the encoding efficiency of x264 is best than Intel MSDK by our several tests in FFMPEG

decoder. (3. and the more parameters can not mapping between x264 and Intel MSDK except basic parameter.


I have Some question and suggestion about Intel MSDK:

1. Do these reserved parameters will open or not in future version Some parameters about inter prediction which

include motion estimation and compensation are reserved. Can I understand how to set in the part yourselves?

2. It is known that x264 has analyzed the feature of FFMPEG h.264 decoder and taken them into their encoder

design in order to increase the performance. May Intel MSDK try to this way to get more performance at

different decoder?

3. x264 sets different parameter set in varying profile or preset mode, and this is easy to use for any user.

When we utilize Intel MSDK into our program, it is confused how to adjust any parameter for getting best

performance. (the reference website: http://dev.gentoo.org/~beandog/x264_preset_reference.html)




Best Regards

[Eric_S_Intel]

Hello,

Thanks for taking the time to evaluate the Intel Media SDK. As you pointed out, there are a number of differences between the Media SDK and x264 in terms of configurability.

The Intel Media SDK is designed to be an API that takes advantage of the hardware of the platform QuickSync, and thus does not have all the control/knobs as some software based implementations. We try to balance the needs of the developer community against the complexity of the driver. We are always tracking user requests and recommending additional configurability settings if they make sense - and are possible given the interfaces available to use from lower in the stack.

Your questions:

1) Hard to say. The presence of reserved variables should not be equated with us releasing future functionality. Like I said above, turning on those params imply driver and hardware support to be active and ready to be used in addition to our API.

2) The Media SDK uses the hardware to encode, decode, and perform pixel processing. Adding additional decoders wont make much of a difference if everythings redirected to the HW for processing.

3) Right, besides Target Usage theres not a lot of control knobs to dial up best performance. There is however a great deal of documentation on getting the best performance from the MediaSDK. Id recommend checking out the Media SDK Developers Guide, the posted whitepapers, and of course this forum for performance tips/tricks.

Hope this helps

Eric