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

[Ralph Giles]

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.

>> 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?

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

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

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