[ogg-dev] ogg dirac granulepos in oggz tools

[Conrad Parker]

2008/11/21 David Flynn <davidf+nntp at woaf.net>:
> 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.

great, thanks

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

a granule is a frame, field, sample etc., and granulerate is framerate,
samplerate etc.

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

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. Currently two are defined (linear
like Vorbis PCM, or Theora's granuleshift). The granuleshift method works
for many stream types with reverse dependencies, but cannot take into
account streams that are not encoded in presentation order.

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

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

thanks for pointing that out, the wiki page is incorrect. Please refer to:

http://svn.annodex.net/standards/draft-pfeiffer-oggskeleton-current.txt

cheers,

Conrad.