[Flac-dev] Ogg encapsulation...

[Josh Coalson]

somehow I missed this mail, answers below:

--- illiminable <ogg at 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