[Mp4-tech] [H.264 Video] DPB and DPB bumping

Gary Sullivan garysull windows.microsoft.com
Wed Mar 28 18:55:04 EDT 2007


To provide a further explanation about what happens when an IDR picture arrives:
Actually, that seems like a pretty good question.
When an IDR picture arrives, all pictures that were previously in the DPB are marked as "not used for reference".  But that doesn't mean that they are not counted against the total DPB capacity.  They still count until their output times arrive, in timing conformance scenarios. 
This means that an IDR picture does not entirely "wipe clean" the internal state of a (time-driven) decoder (except when the no_output_of_prior_pics_flag is equal to 1 or is inferred to be equal to 1).  It only wipes clean the ability to use prior pictures as references.
Now there are differences between timed decoding and bumping decoding that are relevant here too.  Most decoders would probably want to achieve timed decoding conformance, not just output order conformance.  For output order conformance, there is no (official) need to worry about the extra pictures in the DPB when and IDR picture arrives, because they can all be bumped out once the IDR arrives.  It is guaranteed that the output time of any picture that arrived prior to the IDR picture must precede the output time of the IDR picture and any pictures that follow it.
But timing conforming decoders need to keep pictures around until their output times arrive, which may be after the decoding times of the IDR picture and some pictures that follow it.
Best Regards,
Gary Sullivan
+> -----Original Message-----
+> From: mp4-tech-bounces lists.mpegif.org 
+> [mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Gary Sullivan
+> Sent: Wednesday, March 28, 2024 5:00 PM
+> To: Tomo; mp4-tech lists.mpegif.org
+> Subject: RE: [Mp4-tech] [H.264 Video] DPB and DPB bumping
+> 
+> 
+> Who is telling you these things?  I think that is wrong.
+> 
+> Supporting the max DPB capacity, plus perhaps one or two 
+> more frames, should be enough for a hardware decoder.  For a 
+> real-time software decoder that has trouble running fast 
+> enough, you might want more, but only for purposes of 
+> smoothing out the processing time of different pictures.  
+> For correct decoding, e.g., for non-real-time, operation 
+> purposes, it should not be necessary to significantly exceed 
+> the quoted DPB capacity in an implementation
+> 
+> Best Regards,
+> 
+> Gary Sullivan
+> 
+> +> -----Original Message-----
+> +> From: mp4-tech-bounces lists.mpegif.org 
+> +> [mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Tomo
+> +> Sent: Wednesday, March 28, 2024 1:29 PM
+> +> To: mp4-tech lists.mpegif.org
+> +> Subject: [Mp4-tech] [H.264 Video] DPB and DPB bumping
+> +> 
+> +> Hi
+> +> 
+> +> I have questions regarding DPB and its bumping.
+> +> Standard specifies max DPB per level.
+> +> HRD assumes buffer management (CPB, DPB) is done 
+> instantly (meaning
+> +> zero delay), but actually it is not possible (for physical
+> +> implementation).
+> +> 
+> +> Now, in case DBP, DBP needs to be managed as described in the
+> +> standard. 
+> +> 
+> +> They say for actual decoder design, decoder needs to have 2xDPB
+> +> to handle worst case DPB bumping. I guess it could happen at the
+> +> boundary of IDR, perhaps because IDR makes DBP reset, but
+> +> all the frames in DPB have not yet been displayed and those
+> +> not-yet-displayed frames need to be saved outside of DPB.
+> +> Is my understanding correct?
+> +> If yes, then can this extream case actually happen?
+> +> I mean within standard  and actual (well, some pathological
+> +> encoder might make such case...).
+> +> 
+> +> Any comment?
+> +> 
+> +> Thanks
+> +> 
+> +> 
+> +> Tomo
+> +> _______________________________________________
+> +> 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