[vorbis-dev] Importing Ogg Vorbis

[Steve Nicolai]

on 5/18/01 3:50 PM, Kevin Marks at kmarks at apple.com wrote:

> At 9:43 pm +0200 18/5/01, Segher Boessenkool wrote:
>>> VBR support for decoding came in in 4.1
>> 
>> Yeah, but I had some serious issues with it, and was adviced that
>> that VBR support only was good for the standard MP3 codec.
> 
> I'm pretty sure that's not true. The confusion may come from the MP3
> decompressor being the only one that currently uses it.

I'm moving this discussion to the QuickTime-API list in hopes to
reach a wider audience of QuickTime knowledge.

First a little background, to make sure that we're all on the same
page (if I've got some of these facts wrong, please correct me):

0.  Ogg Vorbis is a variable bitrate audio compression format.  Details
    at http://www.xiph.org/ogg/vorbis/index.html

1.  Neither Ogg nor Vorbis has information at the front of the stream
    telling how long it is.  You need to look at the granulepos on the
    last page in the Ogg framing to learn that.  The granulepos is the
    absolute frame number in the raw stream of the last frame encoded in
    that packet/page.

2.  Vorbis has a large (~8K-16K) code book near the front of the stream
    that must be received error-free to decode the rest of the stream.

3.  Vorbis packets are small (generally less than 200 bytes).

4.  Ogg framing groups vorbis packets into pages, preserving the
    packet boundaries.  Pages are around 4K.

5.  Ogg framing is allowed to fragment a packet across pages.

6.  Ogg framing discards the granulepos information for all packets
    except for the last complete packet on that page.

7.  Either an Ogg page or a Vorbis packet can be dropped/corrupt,
    and the reader can get resynced at the start of the next page or
    packet.

Features I would like the QuickTime import and decompression component
pair to have (because other tools have them :-)

A.  Opens/Imports files quickly and efficiently.  I.e. a 5MB .ogg file
    on my iDisk shouldn't read the entire 5MB until I hit play.  (I'd
    live with an in the background import)

B.  Seeks efficiently in the file.  Decoding vorbis takes a substantial
    portion of the CPU on my 8500/120 MHz 604e, I don't want to wait
    a minute to seek to the middle of the song, because QT has to decode
    from the beginning.

C.  Support fast-start HTTP streaming playback.

I realize that the goals are at odds with each other.  Creating a single
sample description for the whole file would make A easy, but conflicts
with B & C.  Dividing the file up into multiple sample descriptions
pretty much means reading the whole file.

Sample descriptions in QuickTime are independent, they don't depend on
any other sample description for state (at least as far as the sound media
handler is concerned).

I've found that there is a set of newly "officially" undocumented import
functions (in the QT 5 reference).  I'm guessing that MovieImportIdle
and friends are the answer to C, and maybe A.  Any hints on how to implement
these?

The bigger problem is the disconnect between the fragmenting of packets
and the independence of sample descriptions.  I pretty much need a sample
description per page, but the only way I can think of making that work
with a fragmented packet is to extend the sample description to include
a portion of the previous page that begins the fragment.  If a sample
description ended with a fragment that would be discarded.  To properly
validate the checksum on the page, I'd need to allow the sample descriptions
to overlap, would that cause problems?

What I really want is a data format layer between the media handler
and the data handler.  It could deal with these issues.

Suggestions?

Steve Nicolai

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