[ogg-dev] Ordering pages by granulepos or presentation time

ogg.k.ogg.k at googlemail.com ogg.k.ogg.k at googlemail.com
Tue Mar 11 02:55:44 PDT 2008


I'm hacking on and off on oggmerge (from ogg-tools).
I've added support for Theora, Speex, and Kate, as well as a few other fixes
and changes.

Now, I've got an issue relating to the ordering of pages as done by oggmerge,
and the way oggz-validate tests for presentation time ordering.

oggmerge, when deciding what timestamp to assign to a page, uses the previous
page's granulepos. Since continuous codecs time by end time (oggmerge as in
the current xiph svn only does Vorbis), this is more or less equivalent to
assigning a page the timestamp of its starting time. I've copied this behavior
to Speex and Theora.

Now, Kate is discontinuous, so I'm assigning its pages a timestamp made from
the page's granulepos, which corresponds to its starting time. Sounds good.

However, consider what happens in the case of a Vorbis stream with 0.7 seconds
of audio data per page, and a Kate stream with an event at offset 0.6 seconds.

Once the headers have been flushed (all at zero timestamp), the first page to
be sent off will be the Vorbis page, since its timestamp will be zero (the
presentation time of its first sample). The second page will be Kate, with the
timestamp corresponding to 0.6 seconds. This feels correct, as a player will
need the data in that order.

However, when oggz-validate scans this file, it doesn't know Kate is timed by
start time, so will see the last packet in the Vorbis page at 0.7 seconds, and
will also see the Kate event at 0.6 seconds in a subsequent page, and will
then proceed to moan about it, as it sees pages misordered. Note that since
the misordering happens in different streams, it is still a valid Ogg stream.

There can be two ways to fix this that I can see:

 - change oggmerge to sort by the page's granulepos
    -> this will mean a less optimal ordering from a player's point of view

 - change liboggz to know when a stream is timed by start time
    -> not too sure what I'd do there, maybe allow a single page's offset to
       be silently allowed

Changing oggmerge to sort by a page's granulepos would mean that in practice,
pages would be sorted slightly differently, but not by that much. It is also
a much easier thing to do than changing oggz-validate.

Also, I reckon muxing streams with packets of non equal length could also
trigger this error, though that's just me thinking, I haven't got a test case.

Comments welcome.


More information about the ogg-dev mailing list