search for: constant_offset

...in the granulepos itself ? 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 = read64le(op.packet+constant_offset); Hardly complex. > decoders to find all the relevant data. Put another way, start-time > labelling for substreams with low page frequency helps buffering after > they're muxed, but it only goes so far if there's not also a lower > bound on that frequency. If I understand wha...

...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 = read64le(op.packet+constant_offset); It is more complex, because the granulepos is available at the page level. We've generally designed the seeking algorithm so it can be implemented without looking inside the packets beyond looking up the samplerate in the first few packets. And you can repeat both the samplerate and...

> 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