search for: granulespac

...uld have to be sent again. If the max lifetime is long enough, the extra bandwidth would be negligible (only needed for those very long events). This would have to be balanced against the bits we take off that backlink (low bits for precision, high bits for lifetime). And we get those bits back as granulespace fodder. Am I missing something here that would make this unworkable or breaking spec ? Thanks

...eora (eg, > clear off the low > bits). The high bits are now the backlink, and the low bits are the > granulepos are the > actual granule of the current packet (not an offset from the frame as > Theora does, > but closer to what it does). > > You still lose 32 bits of granulespace, of course, which really > bothers me. At millisecond > precision, 32 bits (signed) just give 24 days. Yeah, I know I've said > it before :) > > Anyway, this makes a generic seeking algorithm handle Theora and CMML the same > way, clear off the low bits below the granule...

...granuleshift is zero, it resolves back to the theora/CMML system, I think. I have implemented it, so I may be missing something that doesn't work though. It means it is slightly more complex, yes, but allows a codec to decide whether it wants less precision on the backlink in exchange for more granulespace bits. Theora does not need this, as it only needs 8 bits (I think) max between keyframes, so there is no granulespace shortage. Now, if your point is just that it's different, then fair enough, but I tried to make it as close as possible to the granuleshift system, and it is backward compatib...

...r Kate, which can have any number of active events at a given time, though that might be OK for CMML. But if this is enough, then it doesn't matter at all that the granulepos of the previous clip be shoved into the lower bits of the granulepos of the current packet, this would just decrease the granulespace by 4 billionfold for no gain. And I don't really want to do that for Kate anyway since I need a few bits for allowing multiple events at the same time (this avoids things like increasing granulepos's necessarily mapping to different times). Anyway, this means that you have to do two seeks...

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

...in time), and this would be more similar to Theora (eg, clear off the low bits). The high bits are now the backlink, and the low bits are the granulepos are the actual granule of the current packet (not an offset from the frame as Theora does, but closer to what it does). You still lose 32 bits of granulespace, of course, which really bothers me. At millisecond precision, 32 bits (signed) just give 24 days. Yeah, I know I've said it before :) Anyway, this makes a generic seeking algorithm handle Theora and CMML the same way, clear off the low bits below the granule shift and start off from there.

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

...et pairs, along with the number of bits each requires. For a timestamping precision of 1ms, as you can see by running the program, the existing method can't handle a base+offset of more than about 50 days. If you move the granuleshift around, since the two are added together, you just move the granulespace from base to offset or the other way round, without getting more actual space. With the method I've described, one can choose to lengthen the usable time space by losing precision on the base. As shown by running the program, the default setup (25 bits for the base, 2 kill bits) can encode bo...

...> bits each requires. > > For a timestamping precision of 1ms, as you can see by running the > program, the existing method can't handle a base+offset of more than > about 50 days. If you move the granuleshift around, since the two are > added together, you just move the granulespace from base to offset or > the other way round, without getting more actual space. > > With the method I've described, one can choose to lengthen the usable > time space by losing precision on the base. As shown by running the > program, the default setup (25 bits for the base...