[Mp4-tech] frame_num, h.264

[Sastry_KRK]

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-Antitrust.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.
**************************************************************************