search for: gp64

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

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

...63535876: Granulepos decreasing within track >> 00:00:00.166: serialno 1763535876: Granulepos decreasing within track > > These two are understood -- infact, the fact it has errored twice > possibly points to an error in oggz-validate treating granulepos as > signed. The value of GP64 is increasing between the two packets, it > then overflows past zero for the third packet. ok, I modified that to allow negative granulepos immediately after headers, in changeset:3781. As for previously showing that error twice: it was effectively remembering the higher value that it had seen...

...serialno 1763535876: Granulepos decreasing within track Ok, that is due to the invalid granulepos in the EOS page (the actual value doesn't make sense -- and is infact invalid (see in a moment)) The mapping spec sets two bits (8 & 30) to be zero. It may be worth checking for them (if the GP64 isn't -1). The GP64 of the EOS page in the sage- stream doesn't pass this test. Infact, i was wondering why that granulepos looks so wrong: 00:02:36.077: -362377 -> (pt:7484,dt:0,dist:65399,delay:7484) the way i calculated dt in oggz is actually redundant. dt is defined to be: dt=pt-...

David Flynn has proposed a new Ogg Dirac mapping. The draft is here: http://davidf.woaf.net/dirac-mapping-ogg.pdf This is a much bigger break from other codecs than my draft (at http://wiki.xiph.org/index.php/OggDirac). We talked a bit about it on IRC today. Below is my summary; hopefully David can correct anything I got wrong or misleading. Comments? There are two main differences

...:00:00.000: serialno 1763535876: Granulepos decreasing within track > 00:00:00.166: serialno 1763535876: Granulepos decreasing within track These two are understood -- infact, the fact it has errored twice possibly points to an error in oggz-validate treating granulepos as signed. The value of GP64 is increasing between the two packets, it then overflows past zero for the third packet. > 00:00:00.041: serialno 1763535876: Packet out of order (previous 00:00:00.166) Best explained with the output of oggzdump > conrad at chichai:~/share/dirac$ oggz dump -c dirac sage-640x360.ogg >|gr...

Hi, I'm wondering if the Dirac granulepos parsing in liboggz and display in the oggz tools is currently correct, as I'd like to do a release of these soon. A couple of days ago David Schleef mentioned there were some problems. David, is that currently true (ie. since David Flynn's recent updates to support Dirac), and if so could you please explain what the problems are, or point me

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,

...gree. > 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% pre...

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