[ogg-dev] ogg dirac granulepos in oggz tools
davidf+nntp at woaf.net
Thu Nov 13 14:54:17 PST 2008
On 2008-11-13, Conrad Parker <conrad at metadecks.org> wrote:
> 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.
I believe it is -- although if correct support in the rest of the
liboggz tools is required, a little more work may need to happen.
> 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/ :
The only niggle i have with this file is that the EOS page has a bizare
timestamp. imho, because there is no picture in the eos page, there is
no meaningful time for it, so the granulepos should be -1 on the eos
page on the dirac logical stream.
> 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
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
> 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
The dirac mapping maintains the property that GP64 (the raw
granule_position) is always increasing. This value is related to dt.
In order to get the presentation time of the dirac picture, you split
the GP64 value at the granuleshift point yeilding high & low; these are
then summed. (i call this GPH+L)
Dirac is an out-of-order codec, the presentation time therefor jumps
around. What you are seeing is correct.
This also raises a few important points. When multiplexing streams
together, it is important to use the time related to the GP64 (dt)
value and not the GPH+L. Multiplexing based on dt will minimize
buffering and latency issues.
Likewise, if one wishes to retime a dirac stream (ie, make it start
at time zero), the lowest presentation time (derived from GPH+L) must
be found, then the difference between them subtracted from all dt and pt
> Are the reported granulepos of the packetno 2 and 3 correct? The dt
> value looks large.
It should be printed as a -ve number, i've obviously made an error.
This will fix it:
--- src/tools/oggz_tools.c (revision 3775)
+++ src/tools/oggz_tools.c (working copy)
@@ -460,7 +460,7 @@
uint32_t pt = (iframe + pframe) >> 9;
uint16_t dist = ((iframe & 0xff) << 8) | (pframe & 0xff);
uint16_t delay = pframe >> 9;
- int64_t dt = pt - delay;
+ int64_t dt = (int64_t)pt - delay;
ret = fprintf (stream,
"(pt:%u,dt:%" PRId64 ",dist:%hu,delay:%hu)",
pt, dt, dist, delay);
> 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?
It should check that DT (GP64) doesn't decrease ("Granulepos decreasing
It should not check for 'out of order' packets based on GPH+L for a
dirac stream, since by definition they are.
More information about the ogg-dev