[ogg-dev] ogg dirac granulepos in oggz tools
davidf+nntp at woaf.net
Fri Nov 21 06:01:41 PST 2008
On 2008-11-21, Conrad Parker <conrad at metadecks.org> wrote:
> 2008/11/15 David Flynn <davidf+nntp at woaf.net>:
>> On 2008-11-14, Conrad Parker <conrad at metadecks.org> wrote:
>>> It seems oggz chop, merge and sort will need some attention to deal
>>> with the Dirac granulepos and dependency ordering, so let's leave them
>>> for the next release.
>> ok. -- may be worth having them 'warn' if they are operating on
>> something containing oggdirac.
> I started patching oggz sort and merge, and discovered they were very nearly
> working. After adding a custom function to convert granulepos to time for
> Dirac, rather than just going by the result of the granuleshift, it seems to
> be working. You can review the changeset here:
I'll test this shortly. 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
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
Ie, if you were to perform a remux by:
foreach logical_stream s:
foreach page with GP64 != 0xffff_ffff_ffff_ffff:
page.muxing_time <- granule_rate * page.GP64
output_order <- sort_and_interleave (all logical_streams) using x.muxing_time
That would work for say dirac and vorbis i think and end up with
a reasonable ordering. Unfortunately, that doesn't work for the theora
granule-shift method, since mapping GP64<->time is nonlinear.
(GP64 = granule pos 64)
(GPH+L = (GP64 >> granule_shift)
+ (GP64 - ((GP64 >> granule_shift) << granule_shift))
NB, May also be written:
GPH+L = (GP64 >> granule_shift)
+ (GP64 & ((1 << granule_shift) - 1))
 Mostly with regard to a hypothetical 'timeline' -- but these are
questions for some later time.
 http://wiki.xiph.org/index.php/Ogg_Skeleton says:
allowing to map a granule position to time by calculating
"granulepos / granulerate"
But that doesn't seem to be what happened in liboggz -- it used GPH+L.
More information about the ogg-dev