[ogg-dev] ogg dirac granulepos in oggz tools

[Conrad Parker]

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 to a bugtracker where they are reported. eg.
There's nothing in
http://trac.annodex.net/query?status=new&component=liboggz

Here's some oggz output that seems a bit fishy. Using
http://diracvideo.org/download/test-streams/ogg/sage-640x360.ogg and
current liboggz svn, http://svn.annodex.net/liboggz/trunk/ :

conrad at chichai:~/share/dirac$ oggz validate --max-errors 0
sage-640x360.ogg 2>&1 | wc -l
135

conrad at chichai:~/share/dirac$ oggz validate sage-640x360.ogg
sage-640x360.ogg: Error:
00:00:00.000: serialno 1763535876: Granulepos decreasing within track
00:00:00.166: serialno 1763535876: Granulepos decreasing within track
00:00:00.041: serialno 1763535876: Packet out of order (previous 00:00:00.166)
00:00:00.208: serialno 1763535876: Packet out of order (previous 00:00:00.333)
00:00:00.375: serialno 1763535876: Packet out of order (previous 00:00:00.500)
00:00:00.481: serialno 0719746932: Packet out of order (previous 00:00:00.667)
00:00:00.709: serialno 1763535876: Packet out of order (previous 00:00:00.834)
00:00:00.876: serialno 1763535876: Packet out of order (previous 00:00:01.001)
00:00:00.972: serialno 0719746932: Packet out of order (previous 00:00:01.168)
00:00:01.002: serialno 0719746932: Packet out of order (previous 00:00:01.043)
00:00:01.210: serialno 1763535876: Packet out of order (previous 00:00:01.335)
oggz-validate --max-errors 10: maximum error count reached, bailing out ...

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
00:00:00.083: serialno 1763535876, granulepos
(pt:4,dt:2,dist:3,delay:2), packetno 5: 764 bytes
00:00:00.125: serialno 1763535876, granulepos
(pt:6,dt:4,dist:4,delay:2), packetno 6: 915 bytes
00:00:00.333: serialno 1763535876, granulepos
(pt:16,dt:6,dist:5,delay:10), packetno 7: 8.431 kB
00:00:00.208: serialno 1763535876, granulepos
(pt:10,dt:8,dist:6,delay:2), packetno 8: 986 bytes
00:00:00.250: serialno 1763535876, granulepos
(pt:12,dt:10,dist:7,delay:2), packetno 9: 927 bytes
00:00:00.292: serialno 1763535876, granulepos
(pt:14,dt:12,dist:8,delay:2), packetno 10: 699 bytes

Questions:

Are the reported granulepos of the packetno 2 and 3 correct? The dt
value looks large.

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?

cheers,

Conrad.