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

[Segher Boessenkool]

Dan Miller wrote:
> 
> 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.
> 
> 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.  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.

Except you'll have to load all codecs, just to check if they can handle
the stream.  This is quite slow (very noticable on QuickTime, for example),
unless you keep all codecs loaded always, which isn't such a good idea.

> 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.  If not, what are you going to do with the data other than discarding it?  If you do have the codec, then the interface provides the functionality necessary to map packets (granules??) or whatever to actual time stamps.

The codec needs to be initialized for the particular stream to be
able to translate granule_pos into something meaningful; that
includes it has to read all headers, and maybe the first few
data packets (it needs the first one or two data pages, for
Vorbis, for example).

> As has been mentioned, it is very important to distinguish between the spec itself and the existing apps and libraries that support the spec.  While the existing implementation may not support a specific feature (for instance, run-time codec binding), there is nothing in the spec itself that prevents anyone from developing an application with that feature.

It has been done already.

> The spec itself should not be modified unless it is shown that some feature is not possible to implement reasonably within the specification as it now exists.

Something really needs to be done about the granule_pos problem, then.

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