[Flac-dev] Ogg encapsulation

[Josh Coalson]

it's good you brought this up, I want to finalize the Ogg FLAC
bitstream mapping and add it to the docs.  currently the way it
is done in flac 1.1.0 is not ideal and probably should change.

--- Arc Riley <arc at Xiph.org> wrote:
> I've been implementing Ogg FLAC support in an editor I'm working on,
> and 
> I must admit to being frustrated by the lack of support for the codec
> on 
> the Ogg layer... and this is more than lacking granulepos.

lacking granulepos?  not sure what you mean, flac 1.1.0 writes
a granulepos of 0 for metadata packets and the correct granulepos
for audio packets.

> The codec's I've worked with, and my own (Writ), use Page 0 for
> general 
> information about the codec.  Specifically, the samplerate, bitrate, 
> quality, number of channels, all that jazz that end users may want to
> know.  Codec setup is often in a second header page, etc.
> 
> I have yet to fully grok where things have been mapped from the FLAC 
> spec to where they actually are in an Ogg FLAC file.  What I have
> seen 
> is that this is not readily accessable in specifically marked Ogg 
> headers, and this is also a hurdle to getting native support in
> Icecast 
> for chaining FLAC with other codecs in a stream.  Page 0 should
> really 
> contain enough information to atleast preform granulepos -> time
> mapping 
> and the codec version for future use.

in flac 1.1.0, what ends up in page 0 is not clearly defined,
which is not good.  I don't remember the ogg documentation
giving any recommendations as to what should be in the first
page and I didn't really investigate it.

the way *CVS* libOggFLAC currently writes is as follows:

- the 4 byte 'fLaC' header is put in the first packet
- each FLAC metadata block is put in its own packet
- each FLAC audio frame is put in its own packet

granulepos is 0 for the fLaC packet and metadata packets.
(I recall somewhere someone suggesting using a granulepos
of -1 for non-audio header packets?)

when the fLaC packet and metadata packets are written, the
library currently calls ogg_stream_flush() on each packet
so that each fLaC/metadata packet is in its own page.

but because some metadata packets can exceed the Ogg nominal
page size of 4K, and even the max Ogg page size (~64K?), some
metadata packets may not fit in a single page.

what is your recommendation here?  is it that the fLaC and
first STREAMINFO (which holds sample rate, #samples,
resolution, etc) packets be flushed together so that they
are in the same page, page 0?  the total size of both packets
is 42 bytes so this seems to be no problem.

but adding in the codec version to the first page.... in
FLAC the codec version is in the vendor tag of the vorbis
comments.  the vorbis comments are in their own metadata
block/packet, but there is no requirement for the vorbis
comments to follow the STREAMINFO immediately.  there may
be other metadata in between.  now, I can enforce it in
libOggFLAC that it follows STREAMINFO immediately, but then
the question is, how can you guarantee that the whole vorbis
comment packet will also fit in page 0, given that there is
not much restriction on the size of comments?  is it enough
that the first part of the vorbis comment packet that contains
the vendor string is in page 0?

audio packets are written out with ogg_page_out() with no
attempt to manipulate the page boundaries.  but the first
audio packet will always start a page because all the metadata
is flushed out to pages before audio data is written.  is this
also OK?

> My recommendation, and my offer, is to redesign the "OggFLAC" stream 
> and leave an easy compatability system in place for software that
> wants 
> to support both older and newer OggFlac files.  This will make
> adoption 
> of FLAC alongside Theora, etc, much easier (and thus faster).  This 
> should be fully documented along with the rest of the FLAC format
> spec.

your help is appreciated.  I wouldn't worry too much about
backward compatibility with old-and-previously-unwieldy Ogg
FLAC because 1) not many people (anyone?) are using it yet since
it has had no seeking support until recently in CVS; 2) it is
trivial to decode an old stream with an old decoder and
re-encode it with a newer encoder that complies to an official
Ogg FLAC bitstream mapping.

> I believe this transition should happen along with porting libOggFlac
> to 
> libogg2, and would like to make this happen in the very near future. 
> I 
> would also like to put energy into helping complete the transition
> from 
> sourceforge to Xiph servers, including transition from cvs to svn,
> now 
> that motherfish-III is setup and our server situation has stabalized.

I haven't been following Ogg2 (are there any docs for it?) so
I don't know what that entails.

Josh



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail