[Mp4-tech] [Video][H.264] Decoded Reference Pic Marking (JM 9.4)

[Karsten Suehring]

Reshma,
sorry for the late reply. You are right, I will include a fix in the
next version.
Best regards,
Karsten
Reshma Prasanna wrote:
> Dear Karsten,
>   With reference to your reply below, I have the following question about
> the reference software JM version 9.4:
> 
> In the file mbuffer.c, in the function init_lists(), if the current frame
> is an I frame, the updation of picNum for short term reference frames is
> performed and after that the code
> 
>   if ((currSliceType == I_SLICE)||(currSliceType == SI_SLICE))
>   {
>     listXsize[0] = 0;
>     listXsize[1] = 0;
>     return;
>   }
> 
> causes the function to return. The updation of the long term picNum i.e.
> 
> dpb.fs_ltref[i]->frame->long_term_pic_num =
> dpb.fs_ltref[i]->frame->long_term_frame_idx;
> 
> is done only if the current frame is a P frame.
> 
> Hence, if the previous frame was marked as a long term frame and the
> current frame is an I frame and mmco operations contain mmco = 2
> (longTermPicNum = 0), then what should be done, is to set any long term
> picture with longTermPicNum = 0 as unused for reference. But in this case,
> the frame previous to the current I frame is also set as unused for
> reference because the longTermPicNum has not been set equal to
> longTermFrameIdx(since the current frame frame is I), and the default
> value for longTermPicNum = 0.
> 
> I would think that the assignment of longTermPicIdx to longTermFramePicNum
> for all long term frames in the DPB should also be done if the current
> frame is an I frame. Is this correct?
> 
> 
> Thanks & Best Regards,
> Reshma.
> 
> 
> On Wed, 23 Mar 2005, Karsten Suehring wrote:
> 
> 
>>Dear Reshma,
>>
>>please see my comments inline.
>>
>>Reshma Prasanna wrote:
>>
>>>Dear H.264 Experts,
>>>
>>>I would really appreciate it if anyone could answer my questions.
>>>
>>>Qn 1) Decoded reference picture marking.
>>>Clause 8 of the H.264 std specifies that the only restriction on invoking
>>>the decoded reference picture marking process is that the decoded picture
>>>must be a reference picture, there are no constraints on the type of frame
>>>i.e. I, P, IDR etc.
>>>
>>>Can the adaptive memory control decoded reference picture marking process
>>>be invoked if the decoded picture is an I frame but not IDR?
>>
>>Yes, that's possible.
>>
>>
>>>If yes, then consider the case when there are decoded reference pictures
>>>stored in the DPB, the current decoded picture is an I frame(not IDR) and
>>>MMCO = 1 is decoded. This means that some short term ref picture with
>>>picNum = CurrPicNum - (difference_of_pic_nums_minus_1 + 1) is to be marked
>>>as "unused for reference". Since the decoded picture has only I slices,
>>>the reference lists have not been constructed and hence picNum =
>>>FrameNumWrap has not been calculated for any short tm reference frames
>>>w.r.t the current picture's frame_num. Then how will the mmco = 1
>>>operation be properly executed? The same question holds with any other
>>>mmco operation that requires comparison to reference lists, if the current
>>>decoded picture is an I frame.
>>
>>This problem has already been identified. The text was fixed in the
>>first corrigendum to invoke the FrameNumWrap calculation also for I slices.
>>
>>This change should already be included in the recommendation/standard
>>version currently published by ITU and ISO.
>>
>>
>>>Qn 2) Consider this case in a H.264 encoder:
>>>The DPB is full and a reconstructed(decoded) picture (not IDR) is to be
>>>inserted into the DPB. If adaptive_ref_pic_marking_mode_flag = 0, then
>>>sliding window process will mark the short tm reference frm with smallest
>>>value of FrameNumWrap as "unused". But if say, the encoder wishes to mark
>>>the current picture as "used for long term reference", since the picture
>>>is not IDR, then adaptive_ref_pic_marking_mode_flag must be set equal to 1
>>>and mmco = 6 must be used. In this case, sliding window process is not
>>>invoked and hence none of the frames in the DPB will be marked as "unused
>>>for reference". There will not be any space in the DPB for the current
>>>frame.
>>
>>The unmarking must be signaled explicitly in that case.
>>
>>
>>>My understanding is that the encoder must then find which short term frame
>>>has smallest frameNumWrap and send another mmco = 1 to set this short tm
>>>reference frame as "unused" so that the current reconstructed frame can be
>>>inserted into the DPB. Is this correct?
>>
>>The encoder is free to decide which picture is marked "unused for
>>reference" (short or long-term) as long as the unmarking is done before
>>marking the current picture. That doesn't need to be the short-term
>>frame with the smallest value of frameNumWrap.
>>
>>The corrigendum text also contains some clarifications which commands
>>are allowed in which order and at which points the maximum number of
>>reference frames constraint is checked.
>>
>>I would suggest reading the updated text on MMCO.
>>
>>Best regards,
>>Karsten
>>
> 
> 
> 
> "SASKEN RATED THE BEST EMPLOYER IN THE COUNTRY by the BUSINESS TODAY Mercer Survey 2004"
> 
> 
>                            SASKEN BUSINESS DISCLAIMER
> This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited ("Sasken") unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email