[ogg-dev] [Schrodinger-devel] ogg dirac granulepos in oggz tools

[Conrad Parker]

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.