[ogg-dev] ogg dirac granulepos in oggz tools

[David Flynn]

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
>|grep granulepos|head
> 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
values.

> Questions:
>
> 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:

Index: src/tools/oggz_tools.c
===================================================================
--- 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
within track")

It should not check for 'out of order' packets based on GPH+L for a
dirac stream, since by definition they are.

..david