[Mp4-tech] [H.264] IntraChroma Prediction in reference s/w

[Tourapis, Alexis]

Dear Hari,
The new version of the software (JM 12.0) supports a simplified intra
chroma mode decision method using the flag "FastCrIntraDecision". This
flags enables the use of a separate, low complexity, algorithm to
determine the mode for chroma, and that "best" mode is then used within
the full mode decision process. The "brute" force method is still there
(although as Gary suggests this can be hardly called the brute force
method ;)). Note that from what I understand, the reason why the
original method was implemented as is, was primarily because of the
architecture of the software and it was probably deemed easier to
implement this process using a for loop (i.e. speed was at that time not
much of an issue).... In any case, this new flag provides significant
encoding speed up while having little if any performance impact.
With regards to ctr16x16 this relates to the prediction types (lists)
used by a certain mode and only makes sense in B slices. In B slices you
can have list0, list1, and bipred. Using this flag the encoder can test
for 16x16 modes (and that is why most likely the name is ctr16x16) all
three prediction types during RDO and most likely get better
performance.
I think the comment on the order can be considered a legacy comment from
earlier versions of the software. I do not think there would be any
issue if you tried to alter this table (although I admit I have not
tested it).
Best regards
Alexis
________________________________
From: mp4-tech-bounces lists.mpegif.org
[mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Gary Sullivan
Sent: Saturday, January 20, 2024 3:33 PM
To: hari prasath; mp4-tech lists.mpegif.org
Subject: RE: [Mp4-tech] [H.264] IntraChroma Prediction in reference s/w
Hari Prasath,
Regarding question 1: The chroma decision affects the number of bits
used for representing the macroblock type information and the resulting
total distortion.  The encoder is designed to balance bits and
distortion, so since the macroblock bit usage and distortion is affected
by the chroma mode, it tries them all.  When designing your own encoder,
of course, you are under no obligation to do things that way.  The
standard does not require any particular encoder decision-making method,
and it is important to keep that in mind.  I think the software also
supports a lower complexity mode decision method as well (at some
sacrifice in compression capability), if you want to try that.
Actually it may be worth noting that even the "high complexity" mode
decision method in the software is not as exhaustive as it could be.
For example, the decision for each 4x4 luma block will affect the bit
usage and distortion of the subsequent 4x4 luma blocks in the
macroblock.  More ideally, the encoder would consider all combinations
for all 4x4 blocks in the macroblock jointly.  That would be 4*(N^16)
things to try for the macroblock (with N potential luma modes per 4x4
luma block and 4 chroma modes), which would be rather difficult.  Of
course then we need to think about the spatial cascading effect of the
decisions made on different macroblocks, etc.  Then there is the time
domain to consider, ...
I don't know the answer to your other questions that are
software-specific rather than algorithmic.
Best Regards,
Gary Sullivan
________________________________
	From: mp4-tech-bounces lists.mpegif.org
[mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of hari prasath
	Sent: Friday, January 19, 2024 11:05 PM
	To: mp4-tech lists.mpegif.org
	Subject: [Mp4-tech] [H.264] IntraChroma Prediction in reference
s/w
	Dear experts,
	This question is with reference to Intra chroma prediction in
Reference S/W in the encode_one_macroblock function.
	1)The H.264 AVC encodes the MB by iterating all the luma intra
decisions for each possible chroma intra prediction modes....i.e a for
loop which iterates for the 4 intra chroma prediction modes inside which
there is another loop which iterates for 9 modes.....Why such an
approach is used. 
	2)I am also confused about the ctr16x16 variable in the same
function.....
	3)Why the order of modes in the mb_mode_table array  should not
be altered(refering to mode_decision.c)
	Thanks in advance for clearing this doubt. 
-----------------------------------------
This message (including any attachments) may contain confidential
information intended for a specific individual and purpose.  If you
are not the intended recipient, delete this message.  If you are
not the intended recipient, disclosing, copying, distributing, or
taking any action based on this message is strictly prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20070120/7b2534b1/attachment.html