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
--- Christer Palm <palm@nogui.se> wrote:> 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().probably if I had it all to do again I would have constrained the possible block sizes, which would have made it more practical to put the frame length in the frame header. but the bad news is that there is no way to determine the frame length except by decoding. I'm not exactly sure what the read constraint you mention means but it might be helpful to tweak the value for FLAC__BITBUFFER_DEFAULT_CAPACITY in src/libFLAC/bitbuffer.c to be something larger (just guessing). that value should probably be exposed in the API. Josh __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com
Josh Coalson wrote:> but > the bad news is that there is no way to determine the frame > length except by decoding. >Yes, I realized that... :-(> I'm not exactly sure what the read constraint you mention > means but it might be helpful to tweak the value for > FLAC__BITBUFFER_DEFAULT_CAPACITY in src/libFLAC/bitbuffer.c > to be something larger (just guessing). that value should > probably be exposed in the API. >Well, what is happening is that I get a call from a framework whenever there is data available to decode. Inside that function, I imagine two choices - put the data on hold (if I don't have enough data for a full frame), or call FLAC__stream_decoder_process_one_frame() (if I *do* have enough data for a full frame). Obviously, I can't do that currently. Right now, I kick off a separate decoding thread and have the flac_read() callback block on a condition variable whenever there's no data available to return to FLAC. It works, but it's extremely ugly :-) -- Christer Palm