[Mp4-tech] RE: cpb_removal_delay and IDR-editing

[Gary Sullivan]

Aaron et al,
That cpb_removal_delay issue is under study as item 24 of JVT-Y210.  We'll probably remove that constraint somehow, but haven't officially done it yet.
There are no other implications of the broken_link flag that I'm aware of.
Best Regards,
Gary Sullivan
+> -----Original Message-----
+> From: mp4-tech-bounces lists.mpegif.org
+> [mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Aaron Wells
+> Sent: Wednesday, February 06, 2024 2:13 PM
+> To: mp4-tech lists.mpegif.org
+> Subject: [Mp4-tech] cpb_removal_delay and IDR-editing
+>
+> All,
+>
+> Apologies in advance if this an FAQ. (...should that be "a" FAQ?)
+>
+> I see an issue was raised (item 3 in JVT-Q023.doc, Oct. 2005)
+> regarding simple IDR-based file split of AVC streams and the
+> following constraint on cpb_removal_delay in the picture timing SEI
+> message:
+> "the value of cpb_removal_delay for the first picture in the
+> bitstream
+> shall be equal to 0." (D.2.2)
+>
+> I'm looking at the July, 2006 revision of the spec, and it seems this
+> constraint is unchanged.
+>
+> Is the application required to have sufficient knowledge of
+> elementary syntax to parse into the bitstream and set
+> cpb_removal_delay to zero on the 1st picture, or is there
+> some other recommended method of handling this situation?
+>
+> For Intra-based file split, does setting the broken_link flag in a
+> recovery point SEI have any wider implication for decoder behavior
+> other than to discard the indicated broken link pictures?
+>
+> Thanks in advance
+>
+> Aaron
+>
+>
+> _______________________________________________
+> 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
+>