[ogg-dev] ogg dirac granulepos in oggz tools
davidf+nntp at woaf.net
Tue Nov 25 11:01:42 PST 2008
>> I'll test this shortly.
Ok, i've tested muxing some audio and video together and that works fine.
>> My only initial concern is about the definition
>> of granule_rate. My intention is to add some guidance to the oggdirac
>> mapping spec on how to apply oggskeleton. This raises the slight
>> problem for me in that i don't find the specification of skeleton
>> particularly rigorous.
>> Actually, i don't even know what the definition of granule_rate applies
>> to when a granule_shift is present. Is it the whole number or the higher
>> word. If we assume it is the higher word, i believe the granulerate would
>> need to be 2*(1<<9)*fps_n/fps_d; in order to allow dumb tools to get things
>> vaguely right.
> a granule is a frame, field, sample etc., and granulerate is framerate,
> samplerate etc.
Err, yes -- just that GPH+L + 1 doesn't advance time by one picture
> Yeah; I've been thinking we should at least add a field to skeleton to
> accomodate the Dirac mapping.
> The main thing is to identify which algorithm to use for converting
> granulepos to time.
> The way the current Dirac mapping works doesn't really fit into either of
> those granulepos schemes, though it does do an awesomely clever job of
> allowing pt to be calculated with the Theora granuleshift method :-)
The Dirac one tries to pretend to be both:
- vorbis like: GP64 * gp64_rate = decode/muxing time + jitter
- granuleshift like: GPH+L * gphplusl_rate = presentation time + jitter
And if one knows how to decode it fully, the jitter disapears. So it is
a bit quantum: it sometimes behaves like granuleshift and sometimes
linear, neither of which give you 100% precision.
> thanks for pointing that out, the wiki page is incorrect. Please refer to:
Ah, thats far more useful. It may be an idea to make that more obvious
on the wiki page.
More information about the ogg-dev