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.
On Sat, Nov 22, 2008 at 2:11 AM, Conrad Parker <conrad at metadecks.org> wrote:> 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: > 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 :-)Fisbone packets are built in a way that new fields can be inserted before the message header fields without breaking backwards compatibility. I would support such an extension!>> [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.I don't understand enough about how it is wrong. Can you correct the wiki page? Thanks, Silvia.
On a slightly unrelated note, i keep hitting the following error in liboggz when using the oggz tools on an ogg dirac stream: /home/davidf/project/liboggz/src/liboggz/oggz.c:202: oggz_close: Assertion `oggz_dlist_is_empty(oggz->packet_buffer)' failed. I'll supply an example file tomorrow if that would be of help. Any thoughts? ..david
2008/11/24 David Flynn <davidf+nntp at woaf.net>:> On a slightly unrelated note, i keep hitting the following error in > liboggz when using the oggz tools on an ogg dirac stream: > > /home/davidf/project/liboggz/src/liboggz/oggz.c:202: oggz_close: > Assertion `oggz_dlist_is_empty(oggz->packet_buffer)' failed. > > I'll supply an example file tomorrow if that would be of help. > > Any thoughts?I expect that will be in the code that tries to calculate granulepos when it is not present on the page, which is actually unecessary for this mapping -- so I expect it will be straightforward to fix. Of course the file will be necessary to debug it :-) thanks, Conrad.
>>> http://trac.annodex.net/changeset/3801 >> >> I'll test this shortly.Ok, i've tested muxing some audio and video together and that works fine. woo.>> 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.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.agree.> The main thing is to identify which algorithm to use for converting > granulepos to time.agree.> 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: > http://svn.annodex.net/standards/draft-pfeiffer-oggskeleton-current.txtAh, thats far more useful. It may be an idea to make that more obvious on the wiki page. ..david
On Tue, Nov 25, 2008 at 11:01 AM, David Flynn <davidf+nntp at woaf.net> wrote:>> thanks for pointing that out, the wiki page is incorrect. Please refer to: >> http://svn.annodex.net/standards/draft-pfeiffer-oggskeleton-current.txt > > Ah, thats far more useful. It may be an idea to make that more obvious > on the wiki page.I've added a link to the wiki page. -r
2008/11/26 David Flynn <davidf+nntp at woaf.net>:>>>> http://trac.annodex.net/changeset/3801 >>> >>> I'll test this shortly. > > Ok, i've tested muxing some audio and video together and that works fine. > woo.great, thanks :-) So the last remaining tool to check is oggz-chop. I at first assumed it would not work with Dirac's granulepos, but it seems to do something vaguely useful: conrad at chichai:~/share/oggz-chop$ oggz chop -s 7 -e 11 -o sage-7-11.ogv ../dirac/sage-640x360.ogg conrad at chichai:~/share/oggz-chop$ oggz dump sage-7-11.ogv |grep serialno | head -n 20 00:00:00.000: serialno 1762443388, granulepos 0, packetno 0 *** bos: 64 bytes 00:00:00.000: serialno 1763535876, granulepos (pt:0,dt:0,dist:0,delay:0), packetno 0 *** bos: 39 bytes 00:00:00.000: serialno 0719746932, granulepos 0, packetno 0 *** bos: 30 bytes 00:00:00.000: serialno 0719746932, calc. gpos 0, packetno 1: 75 bytes 00:00:00.000: serialno 0719746932, granulepos 0, packetno 2: 3.742 kB 00:00:00.000: serialno 1762443388, granulepos 0, packetno 1: 80 bytes 00:00:00.000: serialno 1762443388, granulepos 0, packetno 2: 81 bytes 00:00:00.000: serialno 1762443388, granulepos 0, packetno 3 *** eos: 0 bytes 00:00:06.923: serialno 1763535876, granulepos (pt:334,dt:332,dist:51,delay:2), packetno 2: 1.685 kB 00:00:06.965: serialno 1763535876, granulepos (pt:344,dt:334,dist:52,delay:10), packetno 3: 16.928 kB 00:00:07.007: serialno 1763535876, granulepos (pt:338,dt:336,dist:53,delay:2), packetno 4: 1.529 kB 00:00:07.048: serialno 1763535876, granulepos (pt:340,dt:338,dist:54,delay:2), packetno 5: 1.761 kB 00:00:07.090: serialno 1763535876, granulepos (pt:342,dt:340,dist:55,delay:2), packetno 6: 1.576 kB 00:00:06.857: serialno 0719746932, calc. gpos 329152, packetno 4: 1 byte 00:00:06.878: serialno 0719746932, calc. gpos 330176, packetno 5: 1 byte 00:00:06.900: serialno 0719746932, calc. gpos 331200, packetno 6: 1 byte 00:00:06.921: serialno 0719746932, calc. gpos 332224, packetno 7: 1 byte 00:00:06.942: serialno 0719746932, calc. gpos 333248, packetno 8: 1 byte 00:00:06.954: serialno 0719746932, calc. gpos 333824, packetno 9: 1 byte 00:00:06.957: serialno 0719746932, calc. gpos 333952, packetno 10: 45 bytes However I don't know if this output is correct. What it is supposed to do is create a file containing all packets for display between 7 and 11 seconds, and to include all packets required to decode those, ie. all reference frames that are required by packets from 7s onwards. The original file included two more Dirac packets immediately prior to those included in the chopped output, but I don't know how to tell if these are required reference frames for those from 7s (or from 6.965s) onwards: conrad at chichai:~/share/oggz-chop$ oggz dump ../dirac/sage-640x360.ogg |grep serialno ... 00:00:06.814: serialno 0719746932, calc. gpos 327104, packetno 406: 1 byte 00:00:06.836: serialno 0719746932, granulepos 328128, packetno 407: 1 byte 00:00:06.840: serialno 1763535876, granulepos (pt:330,dt:328,dist:49,delay:2), packetno 168: 1.603 kB 00:00:06.881: serialno 1763535876, granulepos (pt:332,dt:330,dist:50,delay:2), packetno 169: 1.683 kB 00:00:06.923: serialno 1763535876, granulepos (pt:334,dt:332,dist:51,delay:2), packetno 170: 1.685 kB 00:00:06.965: serialno 1763535876, granulepos (pt:344,dt:334,dist:52,delay:10), packetno 171: 16.928 kB 00:00:07.007: serialno 1763535876, granulepos (pt:338,dt:336,dist:53,delay:2), packetno 172: 1.529 kB 00:00:07.048: serialno 1763535876, granulepos (pt:340,dt:338,dist:54,delay:2), packetno 173: 1.761 kB 00:00:07.090: serialno 1763535876, granulepos (pt:342,dt:340,dist:55,delay:2), packetno 174: 1.576 kB 00:00:06.857: serialno 0719746932, calc. gpos 329152, packetno 408: 1 byte 00:00:06.878: serialno 0719746932, calc. gpos 330176, packetno 409: 1 byte ... So: - is the current output correct? - if not, how should the packets that a given packet depends on be determined, ie. how to determine reference frames? Is it possible to do so using only the granulepos encoding? Conrad.