[vorbis-dev] granulepos start/end revisited
Monty
xiphmont at xiph.org
Tue May 18 14:23:17 PDT 2004
On Tue, May 18, 2004 at 05:49:35PM +1000, Andr? Pang wrote:
> A simple question (with a complex answer, no doubt): what's the
> rationale for having a start-time encoded granulepos?
Start-time is used for discontinuous streams. Discontinuous streams are mostly intended to be treated like a string of randomly spaced events. By having a start-time encoded page, you guarantee that from any seek point:
1) all events that happen after the seek are ahead of you.
2) any event will 'fall out' of stream buffering before its needed,
without the buffering algorithm needing to look ahead for an
arbitrary/unbounded period of time.
The example is simple; suppose the 'event' is a subtitle intended to
be on screen for 10 seconds. If the event was encoded and multiplexed
by end-time, you would need to buffer ahead a minimum of ten seconds
to see the 'event' in time.
> It adds (1)
> another dependency
Actually it doesn't.
> and (2) the need for mode core to handle both start
> times and end times, which will also touch many parts of Ogg and
> possibly affect the code base of the codecs as well.
The codecs are not really concerned at all by this. The OggFile glue
might be, but none of that actually exists yet.
Nor does this complicate seeking at all; both cases are treated as a
marker of time between pages, one just happens to signify beginning of
page, the other the end. In fact, having the two seperate cases and a
strict monotonically increasing sort does a great deal to keep seeking
simple.
> To frame the question another way, what's wrong with the current
> end-time granulepos scheme? I've read through all the discussions and
> IRC meeting logs, and still don't understand the necessity for it.
It's all about buffering of a multiplexed stream, and making that
buffering algorithm as simple as possible. Having two stream types
(and two sort orders) eliminates a raft of special cases you'd need to
smash it all down into one master type.
It all boils down to 'this way, discontinuous streams are ignored in
managing buffers, but can still be used to seek.'
Monty
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Vorbis-dev
mailing list