Conrad Parker
2008-Nov-21 03:40 UTC
[ogg-dev] [Schrodinger-devel] ogg dirac granulepos in oggz tools
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 please test :-) For example you can start by ripping an existing Dirac+Vorbis stream apart: $ oggz rip -c vorbis input.ogv -o vorbis.ogg $ oggz rip -c dirac input.ogv -o dirac.ogv Then merge them back together: $ oggz merge dirac.ogv vorbis.ogg -o output.ogv I think the output is properly merged, please test in case there are any problems I have missed. Tested with liboggz r3806. Conrad.
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/3801I'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
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.