[Mp4-tech] [H.264]Question about num_ref_idx_lx_active_minus1

Gary Sullivan garysull windows.microsoft.com
Wed May 10 15:07:42 ESTEDT 2006 

Marco et al,
I don't think there is any big problem in the language of the standard,
if you read it properly and completely.  However, perhaps it could be
improved.
One thing to notice is that the value of MbaffFrameFlag is unknown when
parsing the PPS (because MbaffFrameFlag is determined from
field_pic_flag, which is not in the PPS).  However, the value of
MbaffFrameFlag is known when parsing the slice header.  But the slice
header also provides the ability to override the value of the
num_ref_idx_lx_active_minus1 syntax elements.
Another thing to notice is that although there are syntax elements with
the same name in the PPS and slice header, the semantics do not need to
be exactly the same in both situations.  The semantics description that
appears in the PPS section is for the syntax element in the PPS and the
semantics description that appears in the slice header section is for
the syntax element in the slice header.
Note that although the PPS semantics allows values greater than 15 for
num_ref_idx_lx_active_minus1, we have the following statement in the
slice header semantics: "When the current slice is a P, SP, or B slice
and field_pic_flag is equal to 0 and the value of
num_ref_idx_l0_active_minus1 in the picture parameter set exceeds 15,
num_ref_idx_active_override_flag shall be equal to 1."  So
num_ref_idx_lx_active_minus1 can be greater than 15 in the PPS, but when
that is the case and the picture uses inter prediction and is not a
field picture, the value in the PPS must be overridden in the slice
header.
The key issue is to determine what value is "in effect" for
num_ref_idx_lx_active_minus1.  It says in the slice header semantics
that "num_ref_idx_active_override_flag equal to 0 specifies that the
values of the syntax elements num_ref_idx_l0_active_minus1 and
num_ref_idx_l1_active_minus1 specified in the referred picture parameter
set are in effect. num_ref_idx_active_override_flag equal to 1 specifies
that the num_ref_idx_l0_active_minus1 and num_ref_idx_l1_active_minus1
specified in the referred picture parameter set are overridden for the
current slice (and only for the current slice) by the following values
in the slice header."
For example, an encoder can set num_ref_idx_lx_active_minus1 = 31 in the
PPS and then code some pictures with field_pic_flag = 1 and
num_ref_idx_active_override_flag = 0 and code some other pictures with
field_pic_flag = 0 and num_ref_idx_active_override_flag = 1 and
num_ref_idx_lx_active_minus1 = 15.
That would be perfectly OK.
So where the standard says "When MbaffFrameFlag is equal to 1,
num_ref_idx_l0_active_minus1 is the maximum index value for the decoding
of frame macroblocks and 2 * num_ref_idx_l0_active_minus1 + 1 is the
maximum index value for the decoding of field macroblocks.", it is
referring to the value of num_ref_idx_l0_active_minus1 that is in effect
when the value of MbaffFrameFlag is in effect.  Thus it is referring to
the value of num_ref_idx_l0_active_minus1 after the value in the PPS may
have been overridden by a value in the slice header.
If we wanted to improve upon the current text, I see two possible
approaches.  One is to simply delete the statement in the PPS semantics
that says that "When MbaffFrameFlag is equal to 1,
num_ref_idx_l0_active_minus1 is the maximum index value for the decoding
of frame macroblocks and 2 * num_ref_idx_l0_active_minus1 + 1 is the
maximum index value for the decoding of field macroblocks."  This
statement is redundant with what is stated in the slice header
semantics, and is confusing since it refers to slice header decoding
results despite trying to describe something in the PPS.
Another possible improvement would be to rename the syntax elements in
the PPS and slice header so that they have distinct names.  Then instead
of talking about which one is "in effect", we could talk about inferring
the slice header syntax element to be equal to the PPS syntax element
value when num_ref_idx_active_override_flag is 0.
Best Regards,
Gary Sullivan
+> -----Original Message-----
+> From: mp4-tech-bounces lists.mpegif.org 
+> [mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of 
+> Marco.Miehe sci-worx.com
+> Sent: Wednesday, May 10, 2024 1:45 AM
+> To: Mp4-tech lists.mpegif.org
+> Subject: RE: [Mp4-tech] [H.264]Question about 
+> num_ref_idx_lx_active_minus1
+> 
+> Dear Members
+> 
+> I post this mail again. Please can someone clarify this.  
+> 
+> -----Original Message-----
+> From: mp4-tech-bounces lists.mpegif.org
+> [mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Miehe Marco
+> (SCI)
+> Sent: Friday, April 28, 2024 4:01 PM
+> To: Mp4-tech lists.mpegif.org
+> Subject: RE: [Mp4-tech] [H.264]Question about
+> num_ref_idx_lx_active_minus1
+> 
+> I agree with you, but that's not the point.
+> Let's consider the case that MbaffFrameFlag = 1, i.e., as you say,
+> mb_adaptive_frame_field_flag = 1 and field_pic_flag = 0. 
+> This means, we have an Mbaff Frame. Now, for a field macroblock, the
+> semantics of num_ref_idx_lx_active_minus1 
+> in the slice header say that the maximum index value is
+> 2*num_ref_idx_lx_active_minus1 + 1, and that the range of
+> num_ref_idx_lx_active_minus1 is from 0 to 15. This results 
+> in a maximum
+> possible index value of 2*15 + 1 = 31, 
+> which is logical since there can be up to 32 reference fields in the
+> reference list for a field MB.
+> But in the semantics of the same syntax element in the 
+> Picture Parameter
+> Set, it again says that for field MBs in Mbaff 
+> frames the maximum index value is 2*num_ref_idx_lx_active_minus1 + 1,
+> but the range of num_ref_idx_lx_active_minus1 
+> here is only limited from 0..31. This now looks as if the maximum
+> possible reference index is 2*31 + 1 = 63, 
+> which does not makes sense regarding the maximum number of 
+> 32 reference
+> fields.
+> I believe that the semantics should be the same as for
+> num_ref_idx_lx_active_minus1 in the slice header and 
+> everything would be clear. I think this is just an inaccurate
+> description here which should be corrected.
+> 
+> BR,
+> Marco Miehe
+> 
+> -----Original Message-----
+> From: mp4-tech-bounces lists.mpegif.org
+> [mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of
+> Ye-Kui.Wang nokia.com
+> Sent: Wednesday, April 26, 2024 1:18 PM
+> To: Mp4-tech lists.mpegif.org
+> Subject: RE: [Mp4-tech] [H.264]Question about
+> num_ref_idx_lx_active_minus1
+> 
+> Note that MbaffFrameFlag = ( mb_adaptive_frame_field_flag  &&
+> !field_pic_flag ), i.e. when field_pic_flag == 1, 
+> MbaffFrameFlag = 0.  
+> 
+> BR, YK
+> 
+> -----Original Message-----
+> From: mp4-tech-bounces lists.mpegif.org 
+> [mailto:mp4-tech-bounces lists.mpegif.org]
+> Sent: 25 April, 2006 15:23
+> To: Mp4-tech lists.mpegif.org
+> Subject: [Mp4-tech] [H.264]Question about 
+> num_ref_idx_lx_active_minus1
+> 
+> Dear Members
+> 
+> I have a question regarding the max size of the reference 
+> picture list.
+> 
+> In the standard ITU-T Rec. H.264 chapter 7.4.3 (Slice header 
+> semantics)
+> the variable 
+> "num_ref_idx_lx_active_minus1" says if the field_pic_flag is 
+> equal to 0
+> the max. size 
+> of the ref. pic. list is 16. And otherwise (field_pic_flag 
+> is equal to
+> 1) the max. size
+> of the ref. pic. list is 32 (num_ref_idx_lx_active_minus1 shall be in
+> range of 0..31).
+> 
+> The variable "num_ref_idx_lx_active_minus1" is also in the
+> PictureParameterSet.
+> I think this definition could be misunderstood. 
+> 
+> Picture parameter set semantics (chapter 7.4.2.2):
+> ... When MbaffFrameFlag is equal to 1, 
+> num_ref_idx_l0_active_minus1 is
+> the maximum index value for the 
+> decoding of frame macroblocks and 2 * 
+> num_ref_idx_l0_active_minus1 + 1
+> is the maximum index value for the 
+> decoding of field macroblocks. The value of 
+> num_ref_idx_l0_active_minus1
+> shall be in the range of 0 to 31, 
+> inclusive.
+> 
+> When I read this definition I might think (altough I think it dosen't
+> make sense) 
+> the max. size of the ref. pic list is 64.
+> Up to now I thought the Max. Size of the DPB is 16 and the 
+> max. size of
+> the reference picture list is also
+> 16 or 32 (in case of fields).
+> 
+> I'd appreciate if some one clarifies this.
+> 
+> Best regards,
+> 
+> Marco Miehe
+> 
+> 
+> 
+>  
+> 
+> _______________________________________________
+> >NOTE: Please use clear subject lines for your posts. 
+> Include [audio, 
+> >[video], [systems], [general] or another apppropriate identifier to 
+> >indicate the type of question you have.
+> >
+> >Note: Conduct on the mailing list is subject to the Antitrust 
+> >guidelines found at 
+> >http://www.mpegif.org/public/documents/vault/mp-out-30042-An
+> titrust.php
+> >
+> 
+> _______________________________________________
+> NOTE: Please use clear subject lines for your posts. Include [audio,
+> [video], [systems], [general] or another apppropriate identifier to
+> indicate the type of question you have.
+> 
+> Note: Conduct on the mailing list is subject to the 
+> Antitrust guidelines
+> found at
+> http://www.mpegif.org/public/documents/vault/mp-out-30042-Ant
+> itrust.php
+> 
+> _______________________________________________
+> NOTE: Please use clear subject lines for your posts. Include [audio,
+> [video], [systems], [general] or another apppropriate identifier to
+> indicate the type of question you have.
+> 
+> Note: Conduct on the mailing list is subject to the 
+> Antitrust guidelines
+> found at
+> http://www.mpegif.org/public/documents/vault/mp-out-30042-Ant
+> itrust.php
+> 
+> _______________________________________________
+> NOTE: Please use clear subject lines for your posts. Include 
+> [audio, [video], [systems], [general] or another 
+> apppropriate identifier to indicate the type of question you have.
+> 
+> Note: Conduct on the mailing list is subject to the 
+> Antitrust guidelines found at 
+> http://www.mpegif.org/public/documents/vault/mp-out-30042-Ant
+> itrust.php
+>

More information about the Mp4-tech mailing list