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/ : [EMAIL PROTECTED]:~/share/dirac$ oggz validate --max-errors 0 sage-640x360.ogg 2>&1 | wc -l 135 [EMAIL PROTECTED]:~/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 ... [EMAIL PROTECTED]:~/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. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Schrodinger-devel mailing list Schrodinger-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/schrodinger-devel
