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

[Beni Cherniavsky]

On 2003-01-30, Segher Boessenkool wrote:

> Ralph Giles wrote:
> >
> > On Wednesday, January 29, 2003, at 02:20 am, Segher Boessenkool wrote:
> >
> > >Ralph Giles wrote:
> > >> 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.
>
How are keyframes fundamentally different from binary seeking?  You
still need to find the keyframe start, don't you?  It's just an
obvious optimization that for small enough distances you read
sequentially forward instead of doing the binary search up to the
exact byte.  It's just like Ogg seeking with one packet for each
key+differences block.  Also, decoding from the keyframe is not
balzingly fast (at least for heavy codecs).  As far as I understand,
keyframes are a technique to improve compression ratio by intorducing
dependence between packets, while bounding the effects of errors.

Or do you mean some sort of a table-of-contents for pointing to the
keyframes?  That is problematic with streaming.  Perhaps some
jump-back tables appearing from time to time could be beneficial.

> > > 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.
>
Heartily agreed.


-- 
Beni Cherniavsky <cben at tx.technion.ac.il>

Gigga incognita :-)
--- >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.