[Mp4-tech] [H.264] output timing, bumping process, missing HRD parameters

[Ye-Kui.Wang nokia.com]

Hi Martin,
First of all, the bumping process is used only for output order decoder
conformance, which requires only the output order of the decoded
pictures produced by the decoder under test is the same as by the HRD.
For output order decoder conformance, it does not matter if you don't
output any picture at some time slots, or you output more than one
picture at some other time slots. So I would say both the decoder output
behaviors you mentioned below are conforming to the output order
conformance requirement. 
In case no other information is present to decide the initial DPB output
delay, num_reorder_frames (should be equal to 2 in your example) can be
used. If not present, num_reorder_frames is inferred to be equal to
max_dec_frame_buffering, which is actually also not present when
num_reorder_frames is not present, so finally inferred to be equal to
MaxDpbSize. 
Final remark: in practical systems, timing information is always present
to guide picture output/display, e.g. using the RTP timestamp in RTP
based transport. 
BR, YK 
>-----Original Message-----
>From: mp4-tech-bounces lists.mpegif.org 
>[mailto:mp4-tech-bounces lists.mpegif.org] 
>Sent: 04 May, 2006 10:57
>To: mp4-tech lists.mpegif.org
>Subject: [Mp4-tech] [H.264] output timing, bumping 
>process,missing HRD parameters
>
>Hello everyone,
>
>I have a question on H.264 regarding the relationship between 
>output timing and the bumping process in the HRD when no HRD 
>parameters are sent by the encoder:
>
>To be able to display a picture in each time slot, I obviously 
>need an initial delay between decoding and displaying the 
>first picture. Now how do I know about this delay when there 
>are no HRD parameters present?
>Is the delay inferred to be equal to max_dec_frame_buffering, 
>which is inferred to be equal to MaxDpbSize when it is not 
>present? When this is the case, I don't see where this is 
>pointed out in the standard. I will give an example about the 
>problem which can arise when the encoder behaves in some 
>manner and doesn't tell the decoder about it and there is no 
>inferred default value of that delay:
>
>Let's assume max_dec_frame_buffering = 6. The encoder could 
>however commit itself for some reason to let the output delay 
>be 2, i.e. a frame will be able to be displayed at most 2 
>decoded frames later. The picture sequence with the following 
>POCs would satisfy this constraint:
>0, 3, 2, 1, 5, 4, 6, ... (continues somehow in a manner which 
>is ok for the mentioned constraint) After the frame with POC 2 
>has been decoded (which is also the 3rd frame in decoding 
>order in this example) a decoder knowing about the delay being 
>2 could display frame 0 and then display a frame after each 
>decoded frame like this:
>decoding: 0, 3, 2, 1, 5, 4, 6, ...
>output:   -, -, 0, 1, 2, 3, 4, 5, 6, ...
>
>Let's now assume the frame with POC 4 is a non-reference 
>frame. After frame 6 has been decoded, frame 4 will be 
>displayed. So it has been output and is no reference frame, so 
>gets discarded from the DBP and a place is free for the frame 
>with POC 6.
>
>A decoder without this information must assume a delay of 6 
>since the encoder could as well base it's calculations on this 
>"worst case" delay.
>So it will not be able to output frame 0 until frame 6 has 
>been decoded.
>But now the bumping process says of course that frame 4 must 
>be evicted from the DPB to able to store frame 6. Thus, the 
>decoder would have to output frames 1 .. 3 in no time.
>
>What is the solution to this problem? Is it that the encoder, 
>when it doesn't send the appropiate information, must take the 
>worst case delay as the base for it's calculations of the DPB 
>state, which would make the above sequence non conformant with 
>the HRD? If yes, where do I find this agreement in the standard?
>
>Best regards,
>Martin Lange
>
>_______________________________________________
>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
>