[ogg-dev] ogg dirac granulepos in oggz tools

[David Flynn]

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:
>
> http://trac.annodex.net/changeset/3801

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
particularly rigorous[1].

Actually, i don't even know what the definition of granule_rate applies
to when a granule_shift is present[2].  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.

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))

[1] Mostly with regard to a hypothetical 'timeline' -- but these are
questions for some later time.

[2] 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.

..david