Motion estimation block in intel ipp h.264 Encoder

[suchethanswaroop]

Hi all,

I am curious to know as to how the motion estimation part is done in the intel ipp H.264 encoder... Are there any changes than the conventional way it is done ( in terms of
a. different block sizes used for motion compensation
b. intra prediction modes used
c. inter prediction modes used
d. number of reference frames used
e. motion vectors used, etc ) ?
I wish to know the functioning of intel IPP h.264 codec and not the order of the classes in which they are called and executed.
(As you all know, Motion estimation is the most time consuming process in the encoder)

Regards,
Suchethan

[Emmanuel_W_]

Quoting - suchethanswaroop

Hi all,

I am curious to know as to how the motion estimation part is done in the intel ipp H.264 encoder... Are there any changes than the conventional way it is done ( in terms of
a. different block sizes used for motion compensation
b. intra prediction modes used
c. inter prediction modes used
d. number of reference frames used
e. motion vectors used, etc ) ?
I wish to know the functioning of intel IPP h.264 codec and not the order of the classes in which they are called and executed.
(As you all know, Motion estimation is the most time consuming process in the encoder)

Regards,
Suchethan

Nothing special about motion estimation/mode decisionin the IPP implementation.
ME can be carried using different algorithm full search, log etc
All Intra modes are tested as well as all inter modes (depending on the quality settings).
For intra the smoothness of the MB is tested before starting I4x4 and I8x8 search
8x8 transforms are tested using aSATD test.
The encoder can be setup in a mode similar to the low complexity mode of the JM or do a full R-D search.
The encoder can use multiple reference frames.
Except for a simple threshold testing that is not enabled by default, there is no fast mode decision implemented as far as I can see.
The SKIP mode decision is a little unusal. It is tested several time during mode decision but also after reconstruction.

Emmanuel

[suchethanswaroop]

Quoting - eweber

hi Emmanuel,

so is 16*16 or any other Block size not used for SATD ?

How is the smoothness of the Macroblock tested ?where can i find it ?

Where can i find the threshold to enable it and make the mode decisions faster ?

Thanks a million !

warm regards,

Suchethan

Nothing special about motion estimation/mode decisionin the IPP implementation.
ME can be carried using different algorithm full search, log etc
All Intra modes are tested as well as all inter modes (depending on the quality settings).
For intra the smoothness of the MB is tested before starting I4x4 and I8x8 search
8x8 transforms are tested using aSATD test.
The encoder can be setup in a mode similar to the low complexity mode of the JM or do a full R-D search.
The encoder can use multiple reference frames.
Except for a simple threshold testing that is not enabled by default, there is no fast mode decision implemented as far as I can see.
The SKIP mode decision is a little unusal. It is tested several time during mode decision but also after reconstruction.

Emmanuel

[Emmanuel_W_]

Usage of SATD as opposed to SAD is a flag that you can be turned on explicitely in the code.
SAD is used for low complexity search and SATD otherwise by default.

The smoothness is tested with the ippiEdgesDetect16x16 primitive.

The threshold is QP dependent, I think in any case you might be better off implementing one of the fast mode algorithm that can be found in the litterature.

You should look at the code if you want more detail info.

Emmanuel

[suchethanswaroop]

Quoting - eweber

Is there some document where i can find the flow diagram of motion estimation part in intelH264 encoder. The code seems to be confusing as der are many concepts involved at every point.

Thanks and regards,

Suchethan

Usage of SATD as opposed to SAD is a flag that you can be turned on explicitely in the code.
SAD is used for low complexity search and SATD otherwise by default.

The smoothness is tested with the ippiEdgesDetect16x16 primitive.

The threshold is QP dependent, I think in any case you might be better off implementing one of the fast mode algorithm that can be found in the litterature.

You should look at the code if you want more detail info.

Emmanuel