similar to: Seeking to granules in discontinuous streams

Hi, sorry, there is a bug in the CMML spec and wiki page ... I discussed this with Silvia earlier this week but haven't gotten around to correcting it yet. CMML granulepos is much like theora's; the previous granule is stored in the higher bits, and the delta since then is stored in the lower bits. The current timestamp is the sum of the two. This is the behavior of the implementations

> No particular answers, but I can at least point out that the way > things were designed for CMML was to work with the existing Ogg > seeking algorithm. The idea is that a generic seeking routine can work > on any Ogg file, as long as it knows the granulepos->time mapping for > the logical bitstreams in the file. That's why all the > timestamp-related info is crammed into

Hi, do you still think you need all this, if you are allowed to have equal granulepos on subsequent pages? Conrad. On 18/02/2008, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote: > Hi, > > I've now got another way of encoding granule (oh, not *again*, I hear > you cry). I believe it's an improvement over the existing "generic" > method, so

Ups! Maybe it's time somebody corrected that statement then - the wiki seems the right place to put the correct algorithm, IMHO. Cheers, Silvia. On Feb 13, 2008 10:06 AM, Ralph Giles <ralph.giles@artifex.com> wrote: > > On 12-Feb-08, at 2:57 PM, Ralph Giles wrote: > > > http://wiki.xiph.org/index.php/GranulePosAndSeeking > > I'm not sure it's helpful to

Some more thinking about this whole granulepos splitting. Sorry for the badgering :) The CMML way was presented as a similar way as the Theora way, which I didn't see (I actually use such a system to allow multiple events to start at the same time, and this feels like the Theora way). Theora can find any frame's previous keyframe granulepos by clearing the low bits of the frame's

After some more thought on this, I'm trying to work out whether the back link offset needs precision. Semantically, the only need we have for this is to be able to seek back to a point before the start of the earliest event still active at the time of the original seek. As far as I know, and please correct me if I'm wrong, nothing in Ogg mandates that this backlink actually resolves to a

Hi, I've now got another way of encoding granule (oh, not *again*, I hear you cry). I believe it's an improvement over the existing "generic" method, so I'll outline it here for your consideration. Again, it's different from what Skeleton can handle, but it's a simple superset and would be easy to add to Skeleton (and liboggz). It is also compatible with other

> The advantage of storing this in the granulepos field itself, like > theora and CMML do, is that the seek code may already understand how > to handle the back pointer. Right now everything assumes the mapping > is from 'initialized decoder' + 'granulepos from page header' => > timestamp, or in the case of theora and CMML => 'timestamp' + 'last

> Leaving aside what the hypothetical seek algorithm would or wouldn't > do, I believe that would work. It's still different from existing > schemes though. Yes, it is different technically. However, I was trying to find something sufficiently close to the system of granuleshift, which you seem to want to become the "standard" way of mapping time to granules, despite

On 12-Feb-08, at 2:54 PM, Silvia Pfeiffer wrote: > I've added Monty's email to the wiki at http://wiki.xiph.org/ > index.php/GranulePosAndSeeking , but I was unable to edit the wiki > entry page and add a "Granulepos and Seeking" link under the > "developer resources" section. Maybe somebody with more rights on > the wiki could add this. I'm

On 15-Feb-08, at 6:44 AM, ogg.k.ogg.k@googlemail.com wrote: > Well, it doesn't quite work because the second part of the gpos is > an offset, > rather than absolute, and the precision we shed on one, we need to > recover > on the other one, to keep the ability to timestamp events at the > correct > granularity. It would have worked if the second part was absolute

> It is more complex, because the granulepos is available at the page > level. Ah. Good point, I always forget about the partial page problem :( I conveniently flush pages after each data packet in my case (due to unknown/arbitrary latency), so I tend to forget easily about those. > We've generally designed the seeking algorithm so it can be > implemented without looking inside

On 2/7/08, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote: > And this is the crux of the problem, as far as I understand how it works: > you'll have to do a first bisection to find the page that maps to that > granulepos, > then, and only then, you get to know the low bits of the actual granulepos, > and then you have to do another bisection to find it.

On 06/02/2008, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote: > Hi, > > I have a question about seeking. In fact, it's more or less a kind > of rambling and thinking aloud, circling around a question. Hi, No particular answers, but I can at least point out that the way things were designed for CMML was to work with the existing Ogg seeking algorithm. The

On 11-Feb-08, at 2:46 AM, ogg.k.ogg.k@googlemail.com wrote: > For reference, my data packets start with start granule, end > granule, backlink > granule, all 64 bits, so picking the granule is just a simple > constant offset > lookup into the data packet, eg, you replace: > > backlink = granulepos<<32; > > by > > backlink =

On 12-Feb-08, at 2:02 AM, ogg.k.ogg.k@googlemail.com wrote: >> It is more complex, because the granulepos is available at the page >> level. > > Ah. Good point, I always forget about the partial page problem :( > I conveniently flush pages after each data packet in my case (due to > unknown/arbitrary latency), so I tend to forget easily about those. Ah, right. So it might

On 13/02/2008, Ralph Giles <giles@xiph.org> wrote: > > The hypothetical seeking algorithm. We should be writing it down, I > suppose This is about the closest we have to a source document on that: http://web.archive.org/web/20031201054855/http://www.xiph.org/archives/theora-dev/200209/0040.html K.

On Feb 11, 2008 9:46 PM, ogg.k.ogg.k@googlemail.com < ogg.k.ogg.k@googlemail.com> wrote: > Following on your point about a lower bound on the frequency, maybe one > could add "keepalive" packets when no data packets have been issued for > a long enough time, and such packets would carry no data but the backlink > itself. Hmm, I like the idea. The packets would be very

Hi, I've seen several implementations of Ogg demuxing that use a zero granulepos to detect headers. However, I do not recall seeing this in the Ogg docs - is this an abuse that happens to work because Vorbis is timed by end granule, or is it a proper way to check ? Thanks

David Flynn has proposed a new Ogg Dirac mapping. The draft is here: http://davidf.woaf.net/dirac-mapping-ogg.pdf This is a much bigger break from other codecs than my draft (at http://wiki.xiph.org/index.php/OggDirac). We talked a bit about it on IRC today. Below is my summary; hopefully David can correct anything I got wrong or misleading. Comments? There are two main differences