As many people have pointed out, storing compression level is generally meaningless, as even the reference encoder can be configured to not be on any predefined compression level. I see two approaches for your case: 1. Monitor the CPU usage and adjust the frequency. The possible problems with this has been outlined fairly by Brian. Additionally, you can keep a buffer of decoded data and increase the frequency if the buffer is getting low. 2. Prepare a test bed with the entire range of encoding/sample parameters (bit depth, sampling frequency, stream parameters, etc.) and build an estimation function for the MIPS required where every parameter weights in with a coefficient based on testing with the test bed.
On Thu, Mar 24, 2011 at 7:44 AM, Pierre-Yves Thoulon < [email protected]> wrote: > I would also add that the "level" is only relevant to the reference > encoder, as it is an alias to quickly set a number of parameters. Other > encoders might make different choices. > Also, I haven't looked in details at how the encoder works, but I think it > is based on heuristics to decide which is the best compression method for a > set of samples, and I'm not sure that it would give twice the same results > for encoding the same file, although those results would be statistically > similar... > -- > Pierre-Yves Thoulon > > > > On Wed, Mar 23, 2011 at 22:33, Brian Willoughby - [email protected] > <+flac-dev+pyt+81a7216403.brianw#[email protected]> wrote: > >> Hjalmar, >> >> I recall that many hardware decoders have a limit on the level that >> they can handle. At the very least, hardware encoders may only >> support a subset of the compression levels. As for the decoders, I >> cannot remember specifically whether they are all capable of decoding >> all compression levels (it certainly would be more convenient). >> >> My memory from discussions on this mailing list is that the file >> format does not have anywhere to store the compression level. The >> reason is that compression levels are just human conveniences, and >> the actual compression is much more complex than a single digit number. >> >> Look at the command-line options for flac and you'll see that each >> compression level is synonymous with a group of up to five separate >> parameters. Maximum LPC Order, blocksize, (adaptive) mid-side >> coding, Rice partition order, and an exhaustive model search. I >> would assume that the factor affecting your decoder mips is the >> model, more than anything else which may be contributing. But you >> might have some luck varying those individual parameters instead of >> the basic compression level to see if any of them have a direct >> effect on your decoding complexity. If one of them does have a >> direct effect, then it might be easier to correlate something in the >> file headers with your clock speed. >> >> Perhaps you could just monitor your CPU usage and adapt the clock >> speed. Starting at the highest clock speed (in order to guarantee >> real-time decoding) you could measure percent CPU usage and drop the >> clock speed any time you're using less than half the available time. >> >> Another possibility is that your clock speed may depend almost >> entirely upon the sample rate, not the compression level. It's >> difficult for me to tell for certain from your cited examples, but >> while it seems clear that the sample rate has a effect on the clock >> speed needed, I'm not nearly so sure that different compression >> levels for the same sample rate would vary so widely. Perhaps you >> can just look in the FLAC headers for the sample rate, and then set >> your clock speed based on that, unless you're saying that a 44.1 kHz >> level 8 file takes more processing than a 96 kHz level 1 file, or >> that a 96 kHz level 8 file takes more processing than a 192 kHz level >> 1 file. You did imply that 192 kHz takes almost twice the CPU at >> level 8 versus level 1, but I would point out that sometimes you can >> only adjust your clock speed in large increments, so it may not >> actually be possible to drop your clock speed by less than half, >> especially not at the highest clock speed (with the way clock >> dividers work). >> >> Brian Willoughby >> Sound Consulting >> >> P.S. What is your embedded platform environment? >> >> >> On Mar 23, 2011, at 10:10, hjalmar nilsson wrote: >> > I'm developing a flac decoder in an embedded environment. I have it >> > fully up and running but I am trying to optimise the performance >> > vs. the power it takes to decode the stream. >> > >> > Using the reference decoder code with a few optimisations for the >> > hw I'm on I experience quite a difference in mips depending on the >> > level. >> > For instance, on a 192kHz/24 bit file the difference is almost that >> > it takes twice as many mips on level 8 vs. level 1. >> > >> > Unfortunately I can't tell our customer that they need to decode at >> > a certain level, BUT I want to minimize the frequency the processor >> > is running on. >> > Since I have no problem reading a 441/16 from a memory stick and >> > decode it on 40 MHz, but I require almost 240 MHz on a 192/24 file, >> > I would like to dynamically change the frequency depending on the >> > file I'm about to decode. >> > >> > Now, since you managed to plough through all this, I would really >> > appreciate if you could answer one simple question: >> > Is there any way I can read out the compression level from the >> > encoding process from the file? >> >> >> _______________________________________________ >> Flac-dev mailing list >> [email protected] >> http://lists.xiph.org/mailman/listinfo/flac-dev >> >> > > _______________________________________________ > Flac-dev mailing list > [email protected] > http://lists.xiph.org/mailman/listinfo/flac-dev > >
_______________________________________________ Flac-dev mailing list [email protected] http://lists.xiph.org/mailman/listinfo/flac-dev
