>> There general idea with Ogg has been to distinguish non-fatal from >> fatal errors. libogg reports these by returning -1 while still >> returning the next valid bit of data. > > ok, would non-fatal translate into a SHOULD recommendation in the > spec, and fatal translate into a MUST?I assume there there are cases where a MUST isn't respected, yet libogg is still able to recover something. If it's just a SHOULD that isn't respected, it shouldn't be considered as an error in the first place. Cheers, Jean-Marc
On Tue, Feb 26, 2008 at 4:48 PM, Jean-Marc Valin < jean-marc.valin@usherbrooke.ca> wrote:> >> There general idea with Ogg has been to distinguish non-fatal from > >> fatal errors. libogg reports these by returning -1 while still > >> returning the next valid bit of data. > > > > ok, would non-fatal translate into a SHOULD recommendation in the > > spec, and fatal translate into a MUST? > > I assume there there are cases where a MUST isn't respected, yet libogg > is still able to recover something. If it's just a SHOULD that isn't > respected, it shouldn't be considered as an error in the first place. >Hmm, good point. Maybe it requires a MUST specification... But then, it would not be conformant to have a partial packet on the last page.... S. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/ogg-dev/attachments/20080226/dbed015c/attachment.html
On 26/02/2008, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:> > Hmm, good point. Maybe it requires a MUST specification... But then, it > would not be conformant to have a partial packet on the last page....I'd definitely prefer that the recommendation to not have an incomplete packet on a page marked eos is a SHOULD not a MUST, so that eos pages don't need to be completely rebuilt after chopping. Conrad.