Matt Zimmerman wrote:> > As I understand it, the current Ogg/FLAC implementation simply wraps the Ogg > bitstream format around a normal FLAC stream, thus not utilizing the > features of Ogg, and duplicating various bookkeeping data. If the Ogg folks > were to spec out a FLAC-based codec for Ogg, it would likely look different > from the current implementation. >Right. And to "fix" that in the reference implementation, the API would probably need to expose a new layer of functionality below the "stream" abstraction, so that frame headers and subframes could be processed separately outside the FLAC stream context. Making that change would also open up a whole new world of possibilities of encapsulating FLAC frames in various stream formats. I'd be happy to put some effort into making that happen, but after having looked at the code as it currently stands I realize that this would require some quite substantial changes, and it would probably be wise to have an open discussion about whether and how such a change should be implemented before hacking away on it. What is your opinion about this, Josh? -- Christer Palm
--- Christer Palm <palm@nogui.se> wrote:> Matt Zimmerman wrote: > > > > > As I understand it, the current Ogg/FLAC implementation simply > wraps the Ogg > > bitstream format around a normal FLAC stream, thus not utilizing > the > > features of Ogg, and duplicating various bookkeeping data. If the > Ogg folks > > were to spec out a FLAC-based codec for Ogg, it would likely look > different > > from the current implementation. > > > > > Right. > > And to "fix" that in the reference implementation, the API would > probably need to expose a new layer of functionality below the > "stream" > abstraction, so that frame headers and subframes could be processed > separately outside the FLAC stream context. > > Making that change would also open up a whole new world of > possibilities > of encapsulating FLAC frames in various stream formats. > > > I'd be happy to put some effort into making that happen, but after > having looked at the code as it currently stands I realize that this > would require some quite substantial changes, and it would probably > be > wise to have an open discussion about whether and how such a change > should be implemented before hacking away on it. What is your opinion > > about this, Josh?I'd be interested in hearing what you have in mind. As far as FLAC being part of the Ogg project... first I think Monty still has an idea of redoing Squish someday; but vorbis is lot of work and maybe he will eventually settle for FLAC. Second, it may not be much of a roadblock but I don't plan on switching to a BSD license. Maybe that means separate codebases, maybe that means a reimplementation. Josh __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com
> And to "fix" that in the reference implementation, the API would > probably need to expose a new layer of functionality below the "stream" > abstraction, so that frame headers and subframes could be processed > separately outside the FLAC stream context.Yes, and until this is done, we should agree to put something more useful into the granulepos of the Ogg pages than 0, e.g. the bytes written so far, which means a file pointer of the encapsulated FLAC file. Regards, Ingo
Josh Coalson wrote:> --- Christer Palm <palm@nogui.se> wrote: > >> >>I'd be happy to put some effort into making that happen, but after >>having looked at the code as it currently stands I realize that this >>would require some quite substantial changes, and it would probably >>be >>wise to have an open discussion about whether and how such a change >>should be implemented before hacking away on it. What is your opinion >> >>about this, Josh? >> > > I'd be interested in hearing what you have in mind. >As a matter of fact, I haven't spent much time thinking about any specifics. The reason I was digging through the code in the first place was to see if; 1) there was a simple way to break out the decoding of the frame header so that I could find out how much data I need to buffer up before calling FLAC__stream_decoder_process_one_frame(), because the application I'm working on cannot request more data from within the flac_read() callback, and 2) see if I could get the decoder to work on my own buffer in order to avoid an unneccesary memcpy(). So although this is somewhat related, I haven't, for example, looked much at the encoder. -- Christer Palm