search for: multicode

OPTICODE As "Optimum Code" or "Optimized Code". Or OPTCODE as before, but also recall the "OpCodes" of processors and the web name is free. Or OPTCODER / OPTICODER as "Optimizing Coder" Alberto -------------- next part -------------- An HTML attachment was scrubbed... URL:

...bFLAC buffers data is also > > impossible to parallelize without significantly changing the api. > > why was this approach used? because the tradeoffs I described required for arbitrarily parallel encoding significantly complicate the api and implementation. libFLAC was not design for multicode file encoding on PCs, it is a reference design that is also being used in embedded devices running <100MHz, low memory, all kinds of different OSes, etc. > The API design seems to me not very smart > because it's not flexible and you're stuck in the future (like now > for multi...

...gt; > impossible to parallelize without significantly changing the api. > > > > why was this approach used? > > because the tradeoffs I described required for arbitrarily parallel > encoding significantly complicate the api and implementation. > libFLAC was not design for multicode file encoding on PCs, it is a > reference design that is also being used in embedded devices running > <100MHz, low memory, all kinds of different OSes, etc. euh :) Just make a flag or something in the api that enables the code for low cpu power devices and/or streaming and disable this...

it actually is complicated. the libFLAC api is not suited to a multithreaded design because the i/o is stream-based, not file- based. flac(.exe) is the file-based wrapper around libFLAC that allows it to work on files. the way libFLAC buffers data is also impossible to parallelize without significantly changing the api. it would take a specialty file-based encoder using an independent frame