[vorbis-dev] application/ogg is a proposed Internet standard.

[Segher Boessenkool]

Ralph Giles wrote:
> 
> On Wednesday, January 29, 2003, at 02:20  am, Segher Boessenkool wrote:
> 
> > Most QuickTime codecs are vbr, too.
> 
> Can you elaborate a bit? I don't actually know much about it. Certainly
> that's true now but the impression I'd gathered was that most codecs
> were fixed-bitrate when the format was designed, and there was a bias
> there. And that that bias was responsible for a lot of the trouble we
> had implementing vorbis as a quicktime codec.

Almost all QuickTime video (and video, in general) is vbr.  Audio is
a different matter -- uncompressed and companded audio is naturally
cbr, and it is true that QuickTime as it is now isn't full-featured
wrt vbr audio needs.

> >> you give up a priori seeking,
> >
> > You don't have to -- it's a design choice.
> 
> What are the alternatives? Chris Hanson mentioned building a seek table
> (is that what 'streaming hints' are?) but I don't see that that gains
> you much except over a high latency link. For local access, binary
> search is quite an efficient alternative unless you make the seek table
> really huge.
> 
> Are there any other methods?

Keyframes and/or a table of contents.  Binary seeking is dog slow,
esp. on cd-roms and the like, but on fast hard drives, too (if you
have a high-bitrate stream).

> >> and while you can do rough seeking from
> >> the page granulepos, you have to do search and partial decode to get
> >> to
> >> a particular sample.
> >
> > Of course.  That's what QuickTime does, too.  And the burden is not
> > on the individual codecs.
> 
> How so? I've never heard how quicktime is actually able to do this.

Keyframes, basically.  The compression manager feeds the codec a
keyframe and enough difference frames until it gets the frame it wants.
Or something like that, at least; you get the general idea.

> > But it would be *so* nice if the stream identified a mapping from
> > granule_pos to some other (real-world) time system.  It's just not
> > good enough to have to decode the first few packets to get to know
> > the granule_pos of the first sample in a stream.
> 
> Why would it be so nice? Why do you need to know how to interpret the
> granule_pos without having a decoder. I don't understand what you want
> to be able to do.

Seek synchronously in two streams, for example.  There is no explicit
marker in Ogg streams that says "this stream starts at granulepos NNN";
you have to derive it from decoded packets (in the Vorbis case, at least).

For quite a few applications, synchronizing everything to some 48kHz
or 44.1kHz audio clock may be good enough, and that is of course the
prefered way to tie a video stream to an audio stream for playback, but
it certainly is not the correct solution for all applications.

<p>Segher

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