Hi all, something which came up recently in relation to the design of Kate's granulepos was whether or not the granulepos of successive Ogg pages is allowed to be the same, ie. whether or not granulepos must be strictly increasing. As this question is more generally about Ogg granulepos, how about we answer it first and then get back to the discussion of Kate's granulepos ... Here is what some documents have to say: * Neither RFC3533 or http://www.xiph.org/ogg/doc/framing.html clarify this. * The seeking algorithm suggested in the (troublesome) email quoted at http://wiki.xiph.org/index.php/GranulePosAndSeeking is "find the earliest page with a granulepos less than but closest to 'x'" should be able to handle equal granulepos (if the earliest of a sequence of pages with equal granulepos is taken to be the first of those in the stream). * The draft mapping for Ogg Dirac uses successive equal granulepos, as the packets occur in coded order, not display order: http://wiki.xiph.org/index.php/OggDirac#Granulepos This is consistent with the definition of granulepos as the "count of decodable frames". I suggest we clarify that the granulepos of successive pages is allowed to be equal, as this is non-obvious from the available documentation. Thoughts? Conrad.
On Feb 19, 2008 5:31 AM, Conrad Parker <conrad@metadecks.org> wrote:> * The seeking algorithm suggested in the (troublesome) email quoted at > http://wiki.xiph.org/index.php/GranulePosAndSeeking is "find the > earliest page with a granulepos less than but closest to 'x'" should > be able to handle equal granulepos (if the earliest of a sequence of > pages with equal granulepos is taken to be the first of those in the > stream).Correct. Actually, the algo I had in mind was 'granulepos with a mapped time less than but closest to', but that requires the no-continued packets fix.> > * The draft mapping for Ogg Dirac uses successive equal granulepos, > as the packets occur in coded order, not display order: > > http://wiki.xiph.org/index.php/OggDirac#Granulepos > > This is consistent with the definition of granulepos as the "count of > decodable frames".Correct.> I suggest we clarify that the granulepos of successive pages is > allowed to be equal, as this is non-obvious from the available > documentation. > > Thoughts?Full agreement. Monty
> Here is what some documents have to say: > > * Neither RFC3533 or http://www.xiph.org/ogg/doc/framing.html clarify > this.The document where I found the rationale was libogg's ogg-multiplex.html, near the middle of the file ("The granule position is governed by the following rules"). However, while it spells out granules can stay put (and gives the reason for this), it also says that this is for data that "only affects codec working state without producing data and thus advancing granule position and time". The "thus" implies to me that it's thinking of time continuous codecs, where there can be only one event at the same time (vorbis, theora), so producing data must advance granule position and time. The wording "position and time" also says that the two are linked in a way that if one goes up, the other does too. Which would seem to preclude a low-bits counter which would increase granulepos, but not time :(
On Feb 19, 2008 6:37 AM, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote:> However, while it spells out granules can stay put (and gives the reason > for this), it also says that this is for data that "only affects codec working > state without producing data and thus advancing granule position and time". > > The "thus" implies to me that it's thinking of time continuous codecs, where > there can be only one event at the same time (vorbis, theora), so producing > data must advance granule position and time. > > The wording "position and time" also says that the two are linked in a way > that if one goes up, the other does too. Which would seem to preclude a > low-bits counter which would increase granulepos, but not time :(Precluding that situation had not been the original intent (indeed, I hadn't considered that) and as far as I know deciding that granpos can increase without increasing time is likely to be fine. My original desire was that any given granulepos will map to a deterministic time (which it will in your description). Time must be mappable back to a granulepos, but not necessarily uniquely (like in the shift case used by theora, where several different granposes could map to the same time). In this case, our 'shim' system needs a time to map back to the lowest-valued possible granpos for that given time. Monty
OK - I have put a ticket into trac for the Ogg RFC. This needs to go in. https://trac.xiph.org/ticket/1306 Cheers, Silvia. On Feb 19, 2008 9:40 PM, <xiphmont@xiph.org> wrote:> On Feb 19, 2008 5:31 AM, Conrad Parker <conrad@metadecks.org> wrote: > > > * The seeking algorithm suggested in the (troublesome) email quoted at > > http://wiki.xiph.org/index.php/GranulePosAndSeeking is "find the > > earliest page with a granulepos less than but closest to 'x'" should > > be able to handle equal granulepos (if the earliest of a sequence of > > pages with equal granulepos is taken to be the first of those in the > > stream). > > Correct. Actually, the algo I had in mind was 'granulepos with a > mapped time less than but closest to', but that requires the > no-continued packets fix. > > > > > * The draft mapping for Ogg Dirac uses successive equal granulepos, > > as the packets occur in coded order, not display order: > > > > http://wiki.xiph.org/index.php/OggDirac#Granulepos > > > > This is consistent with the definition of granulepos as the "count of > > decodable frames". > > Correct. > > > I suggest we clarify that the granulepos of successive pages is > > allowed to be equal, as this is non-obvious from the available > > documentation. > > > > Thoughts? > > Full agreement. > > Monty > _______________________________________________ > ogg-dev mailing list > ogg-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/ogg-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/ogg-dev/attachments/20080220/eacb8ebc/attachment.htm