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

[Ralph Giles]

On Tuesday, January 28, 2003, at 07:52  pm, Dan Miller wrote:

> I had a reasonably long discussion with Monty about this.  The present 
> theory of operation is as follows (Monty as always, please correct if 
> I'm wrong):

Thanks for the excellent summary, Dan. This fits with my understanding 
of the proper design as well.

> Each logical stream has an identification header.  By convention, this 
> header must include magic data that uniquely identifies the required 
> codec.  IE, after the packet ID, vorbis headers contain the string 
> "vorbis"; theora headers say "theora", etc.

And this is just convention. Adding the 'should' clause I suggested 
would document that at the ogg level. I don't know if that's worthwhile 
or not. The 'is this yours?' query method for stream identification you 
describe is sufficient even without that addition.

> Perhaps we should codify this convention.  But even if we didn't, it's 
> entirely reasonable to have each codec take a look at the ID header 
> and report as to whether it can parse this stream.

/ID header/b_o_s packet/ After all there's nothing in the ogg spec 
that even says the header magic has to be byte-aligned.

>   If all codecs fail, you haven't installed (linked in) a codec that 
> can deal with this data.  This situation is identical to the case in 
> Quicktime or Windows Media where you have a file but don't have the 
> codec.  If the codec is installed, you send it the data; if it's not 
> installed, you don't.  The ID query should be nearly instantaneous, so 
> it shouldn't be any kind of latency or performance problem.
>
> As for the timing/seeking issues, I'm just getting up to speed on it, 
> but I suspect the answer is similar: yes, the methods necessary to 
> locate position in a stream are codec-dependent, but that's fine; 
> either you have the codec or you don't.

This is correct. One distinction that has been made with e.g. quicktime 
is that the xiph codecs are all primarily variable bit rate, for which 
you give up a priori seeking, 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. From that perspective, having to ask the codec for 
timebase conversion isn't a significant complexity burden. The 
advantage is that each codec can use the granulepos in the most natural 
way.

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