[vorbis-dev] ogg_sync_state with discontinuous codecs

[Ralph Giles]

On Wed, Dec 03, 2003 at 10:06:18AM -0800, Aaron Colwell wrote:

> This brings up a question that I've wondered about for a while. Why are 
> the granulepos values associated with the last sample of the last complete 
> packet in a page? This is completely different than most media file 
> formats that I can think of and makes things like seeking a pain. It also 
> doesn't easily handle sparse or discontinuous media like Arc says. I'm 
> just interested in why this design decision was made.

Well, to quote framing.html:

> The rationale here is that the position specified in the frame header of the
> last page tells how long the data coded by the bitstream is. A truncated stream
> will still return the proper number of samples that can be decoded fully.

This arrangement doesn't make seeking any more of a pain than it is in any vbr stream. In a 
multiplexed stream (at least with a monotonic sort) you always have to bracket your seek point to 
make sure you have all the data to begin decoding so whether the beginning or the end of your 
bracket is what's marked is moot.

BTW, there are other approaches to the discontinous mux problem; an earlier plan was to keep the 
end-time page granulepos marks, but make the multiplexer smart enough to 'do the right thing' for 
a particular collection of data. More general, but also more complicated. The start-time idea lets 
the multiplexer just do a simple sort and moves a limited version of the choice into the codec 
itself.

FWIW,
 -r
--- >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.