[Mp4-tech] frame_num, h.264

[Gary Sullivan]

KRK Sastry,
1. Please be aware that you are quoting OLD text.  This section has been
modified by corrigendum work.  What version are you quoting?
2. Regarding your specific question "if theer are no frames then value
frame_num may not take a value equal to prevREfframeNum", I think that
is not a correct statement.  When there are no frames, the value of
frame_num in complementary reference field pairs will be equal, for
example.
Best Regards,
Gary Sullivan
+> -----Original Message-----
+> From: mp4-tech-bounces lists.mpegif.org 
+> [mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Sastry_KRK
+> Sent: Thursday, February 03, 2024 10:09 PM
+> To: Bharat Soni; mp4-tech lists.mpegif.org
+> Subject: RE: [Mp4-tech] frame_num, h.264
+> 
+> 
+> frame_num is used as a unique identifier for each short-term 
+> reference frame
+> and shall be represented by
+> log2_max_frame_num_minus4 + 4 bits in the bitstream. frame_num is
+> constrained as follows:
+> The variable PrevRefFrameNum is derived as follows.
+> - If the current picture is an IDR picture, PrevRefFrameNum 
+> is set equal to
+> 0.
+> - Otherwise (the current picture is not an IDR picture), 
+> PrevRefFrameNum is
+> set equal to the value of frame_num for
+> the previous access unit in decoding order that contains a reference
+> picture.
+> 
+> The value of frame_num is constrained as follows.
+> - If the current picture is an IDR picture, frame_num shall 
+> be equal to 0.
+> - Otherwise (the current picture is not an IDR picture), 
+> referring to the
+> primary coded picture in the previous access
+> unit in decoding order that contains a reference picture as 
+> the preceding
+> reference picture, the value of frame_num
+> for the current picture shall not be equal to 
+> PrevRefFrameNum unless all of
+> the following three conditions are true.
+> - the current picture and the preceding reference picture belong to
+> consecutive access units in decoding order
+> - the current picture and the preceding reference picture 
+> are reference
+> fields having opposite parity
+> - one or more of the following conditions is true
+> - the preceding reference picture is an IDR picture
+> - the preceding reference picture includes a
+> memory_management_control_operation syntax element equal
+> to 5
+> NOTE - When the preceding reference picture includes a
+> memory_management_control_operation syntax
+> element equal to 5, PrevRefFrameNum is equal to 0.
+> - there is a primary coded picture that precedes the 
+> preceding reference
+> picture and the primary coded
+> picture that precedes the preceding reference picture does not have
+> frame_num equal to PrevRefFrameNum
+> 
+> 
+> if theer are no frames then  value frame_num may not take a 
+> value equal to
+> prevREfframeNum . is our understanding correct
+> 
+> 
+> 
+> regards
+> 
+> KRK Sastry
+> 
+> 
+> 
+> -----Original Message-----
+> From: Bharat Soni [mailto:bharatsoni gmail.com]
+> Sent: Friday, February 04, 2024 9:58 AM
+> To: Sastry_KRK
+> Cc: mp4-tech lists.mpegif.org
+> Subject: Re: [Mp4-tech] frame_num, h.264
+> 
+> 
+> Hi,
+> 
+> I don't know if I understood your question correctly. Let me know if
+> this answer doesn't help you.
+> The statement means that, if a reference frame picture is 
+> coded as two
+> separate field pictures then  the frame_num for both the fields of
+> that reference frame will be same. In your case since there are only
+> frame pictures, frame_num will be different for all the reference
+> frames.
+> 
+> Regards,
+> Bharat
+> 
+> 
+> 
+> On Mon, 31 Jan 2024 16:57:20 +0530, Sastry_KRK 
+> <Sastry_KRK satyam.com>
+> wrote:
+> > 
+> > hello experts,
+> > 
+> > frame_num may not take a value equal to prevREfframeNum, 
+> in addition to
+> two
+> > other conditions ,  the following condition is true
+> > 
+> > " the current picture and the preceding reference picture 
+> are reference
+> > fields having opposite parity "
+> > 
+> > suppose only frames support is there and no support for fields, the
+> > frame_num will never be equal to prevREfframeNum.
+> > 
+> > could any one explain this behavior
+> > 
+> > regards
+> > 
+> > KRK Sastry
+> > 
+> > 
+> *************************************************************
+> *************
+> > This email (including any attachments) is intended for the 
+> sole use of the
+> > intended recipient/s and may contain material that is 
+> CONFIDENTIAL AND
+> > PRIVATE COMPANY INFORMATION. Any review or reliance by 
+> others or copying
+> or
+> > distribution or forwarding of any or all of the contents 
+> in this message
+> is
+> > STRICTLY PROHIBITED. If you are not the intended 
+> recipient, please contact
+> > the sender by email and delete all copies; your 
+> cooperation in this regard
+> > is appreciated.
+> > 
+> *************************************************************
+> *************
+> > _______________________________________________
+> > 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
+> >
+> *************************************************************
+> ************* 
+> This email (including any attachments) is intended for the 
+> sole use of the
+> intended recipient/s and may contain material that is 
+> CONFIDENTIAL AND
+> PRIVATE COMPANY INFORMATION. Any review or reliance by 
+> others or copying or
+> distribution or forwarding of any or all of the contents in 
+> this message is
+> STRICTLY PROHIBITED. If you are not the intended recipient, 
+> please contact
+> the sender by email and delete all copies; your cooperation 
+> in this regard
+> is appreciated.
+> *************************************************************
+> *************
+> _______________________________________________
+> 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
+>