[Flac-dev] Ogg encapsulation...

[illiminable]

I'm about to do the new version of the ogg mapping and i have a few 
questions...

Here's my understanding so far...

There's a new first header... which is a header like the other ogg 
headers... with some general info, and with a stream info metadata block 
stuck to the end of it.

The next packet must be a vorbis comment meta data block, then meta data 
blocks in any order and of any number.

Other than that... it's all the same ?

OK... here's the question...  i don't use liboggflac++... just libflac++, 
and all the ogg layer stuff is done elsewhere (common code for all 
codecs)...

Currently what i've done is this... when it sees a flac stream, it keeps 
reading metadata headers until it sees the flag for the last one... then it 
sticks all the headers together in one big chunk and calls the 
____read_to_end_of_meta_data method.

Since i take it the underlying flac library hasn't changed... i'm assuming 
this means... from the new headers, i have to reconstruct a chunk of header 
data as it was in previous versions ?

So i have to discard all the start of the new header packet, grab the stream 
info bit, then stick it together with all the other headers. This sound 
about right ?

Also wondering if there are any plans in the future to provide a push model 
interface for flac at some point ? That was one of the most difficult things 
i encountered putting it into directshow... as directshow controls the data 
flow and the seeking etc. the codecs can't just say "Give me more data"... 
because there may not be any data ready yet, or the data may be being 
withheld for various reasons.

It would also make it much easier to integrate with something like 
libfishsound.

ie something like

__initialise_flac_decoder(ALL_THE_HEADERS inHeaders);
__set_decoded_callback(CALL_ME_HERE_WITH_THE_DECODED_AUDIO inCB);
__feed_flac_data(SOME_FLAC_DATA inData, BOOL inSendMeAudioYet);

Then if a full frame ins't passed in... it just waits on the data to 
complete it, instead of calling a read callback... if more than one frame is 
passed in, the decoded callback may fire several times for each feed.

Or perhaps even easier... don't even worry about a header input function... 
just let it be fed in with the feed function and a return value can tell you 
when the data is bogus, or when the last of the meta data is processed.

It'd also be handy to be able to turn off the sending of decoded audio... 
for example when you are in a stop state and feeding in data to set up the 
stream... you don't actually want any audio to be played while it's stopped.


Cheers,

Zen.