David Schleef
2008-Nov-13 18:22 UTC
[ogg-dev] [Schrodinger-devel] ogg dirac granulepos in oggz tools
On Thu, Nov 13, 2008 at 06:06:10PM +0900, Conrad Parker wrote:> 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 to a bugtracker where they are reported. eg.I mostly meant what you apparently fixed below, namely, showing pt, dt, dist, and delay.> conrad at chichai:~/share/dirac$ oggz dump -c dirac sage-640x360.ogg > |grep granulepos|head > 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 1763535876, granulepos > (pt:0,dt:4294967292,dist:0,delay:4), packetno 2: 19.658 kB > 00:00:00.166: serialno 1763535876, granulepos > (pt:8,dt:4294967294,dist:1,delay:10), packetno 3: 6.700 kB > 00:00:00.041: serialno 1763535876, granulepos > (pt:2,dt:0,dist:2,delay:2), packetno 4: 839 bytes> Are the reported granulepos of the packetno 2 and 3 correct? The dt > value looks large.Those should be -4 and -2, repsectively. Otherwise, those numbers appear correct.> If it is ok for packets in an Ogg Dirac bitstream to be decreasing, > which oggz-validate reports as out of order -- I assume/recall that > this is if they are sequenced in dependency order, not display order > -- then how should oggz-validate be modified to handle this properly?They should not be decreasing as long as you account for the first few having bit 63 set, i.e., "being negative". dave...
Ralph Giles
2008-Nov-13 22:59 UTC
[ogg-dev] [Schrodinger-devel] ogg dirac granulepos in oggz tools
On Thu, Nov 13, 2008 at 10:04 AM, David Schleef <ds at schleef.org> wrote:>> Are the reported granulepos of the packetno 2 and 3 correct? The dt >> value looks large. > > Those should be -4 and -2, repsectively. Otherwise, those numbers > appear correct.Conrad, I'd guess the oggz-validate test is wrong then. It's not that granulepos must be numerically non-decreasing, but that they must map to a a non-decreasing timestamp. Testing the actual field value is not technically correct, even it the dirac mapping turns out to maintain that for some choice of signedness. -r