flac dev - Oct 2004 - Ogg encapsulation...

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.

somehow I missed this mail, answers below:

--- illiminable <ogg@illiminable.com> wrote:
> 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 ?
yes.
> 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 ?
you should only have to strip off the first 9 bytes of the
first Ogg packet, then all subsequent packet data can be
passed to libFLAC through the read callback.
> 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.
yes, this is something I've been thinking about.  the current
API is being used in a lot of places, so I'm not sure whether
to do a separate lib or add another push-based decoder API to
libFLAC.

the thing that makes the push-based decoder hard is due to a
really bad deficiency in native FLAC, that the frame lengths
are not known in advance.  this has caused all kinds of problems
but it's too late to go back and fix now.  but you can see the
problem here: if someone passes in a partial frame, libFLAC
won't know it's partial until it consumes it all, at which point
it has to save the entire decoder state (which can be right in
the middle of a rice-coded integer decoding) before exiting up.
when it gets called again to decode more it has to unwind all
the state to get back where it was.
> 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.
hmm... you want the decoded samples to stay buffered and no
write callback to be called?  or you want samples dropped while
off?

Josh



		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail