ogg dev - Nov 2008 - ogg dirac granulepos in oggz tools

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.

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



dave...

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

On Thu, Nov 13, 2008 at 2:54 PM, David Flynn <davidf+nntp at woaf.net>
wrote:
> 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.
ds and I talked about this a bit yesterday. The rfc says the special
value of 0xFFFFFFFFFFFFFFFF "indicates that no packets finish on that
page." So it's a bit misleading to say this. Moreover, it's
convenient
for duration calculation (and scanning backward) if the final page has
a granulepos. With other mappings, when considering a non-frame eos
page, we've generally concluded it's better that it carry the same
granulepos as the last frame.

In this case, the page has a packet, and while that packet affects
decoder state, it doesn't itself advance production of decodeable
output, so it make some sense for it to have presentation timestamp
the same as the last decodable frame in the stream, and perhaps a
decode timestamp likewise the same. Does this not make sense in the
dirac granulepos encoding?

 -r

2008/11/14 David Flynn <davidf+nntp at woaf.net>:
> On 2008-11-13, Conrad Parker <conrad at metadecks.org> wrote:
>> 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);
>
thanks, applied in changeset:3779

Conrad.

2008/11/14 David Flynn <davidf+nntp at woaf.net>:
> 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.
Ok, let's at least make sure the tools for inspecting streams are
working first, ie. oggz dump, info, and validate.

oggz-dump seems to be correct now (with your last dt patch).
oggz-info works.
I've fixed up oggz-validate with your suggestions below.

As for the other tools:

oggz-rip works ok.

Should oggz-comment be modified to disallow modification of Dirac
streams, ie. does Ogg Dirac never contain VorbisComment metadata?

It seems oggz chop, merge and sort will need some attention to deal
with the Dirac granulepos and dependency ordering, so let's leave them
for the next release.
>> 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.
ok, as it seems the EOS granulepos is under discussion I've not made any
checks
specific to that.

As of changeset:3782, oggz-validate reports only this one error for that file:

conrad at chichai:~/share/dirac$ oggz validate sage-640x360.ogg
sage-640x360.ogg: Error:
00:02:36.077: serialno 1763535876: Granulepos decreasing within track

>> 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.
ok, I modified that to allow negative granulepos immediately after
headers, in changeset:3781.

As for previously showing that error twice: it was effectively
remembering the higher value that it had seen before, not just the
immediately previous value.
>> 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.
Ok, so the GP64 check remains.

I modified the packet ordering check to not take the timestamp of
Dirac packets into account (changeset:3782).

So effectively, the GP64 check ensures that the ordering within the
Dirac track is ok, but the timestamps of the Dirac packets do not
affect the check for multiplexing order (ie. don't affect the checking
of Vorbis packets).

Conrad.
checking packet ordering.