[ogg-dev] [Schrodinger-devel] ogg dirac granulepos in oggz tools

David Schleef ds at schleef.org
Thu Nov 13 10:22:40 PST 2008

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


More information about the ogg-dev mailing list