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

[Gary Sullivan]

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
+>