[FFmpeg-devel] [PATCH] adpcm: Store trellis nodes in a heap structure

Martin Storsjö martin
Thu Nov 11 00:08:41 CET 2010


On Wed, 10 Nov 2010, Michael Niedermayer wrote:

> ok, testing with some music might make sense too

Good point. I tested with two different tracks, and it gave quite 
interesting results. The runtime difference became even larger, in favour 
for these patches. On one of the clips, patch #4 actually gave a slightly 
worse result (which is what should happen, theoretically), but the speed 
increase is so insanely large that I think it still is worth it.

> > For testing, I do e.g. this:
> > time ./ffmpeg -y -i adpcm-input.wav -acodec adpcm_ima_wav -trellis 7 adpcm.wav
> > ./ffmpeg -y -i adpcm.wav out.wav > /dev/null 2>&1
> > tests/tiny_psnr adpcm-input.wav out.wav 2
> > 
> > 
> > > > Also, for reference, the same input with different trellis sizes, after 
> > > > patch #4:
> > > 
> > > it would be interresting to also see this with pre #4 so one can compare it
> > 
> > Ok, here are even more numbers:
> 
> these would be easier to compare with gnuplot printing quality vs time
> 
> anyway, so far your patchset looks good and iam not insisting on more testing
> it just would be interresting as some of these patches reduce quality and
> improve speed so Time vs Distortion curves would more clearly show the
> improvment

Done, graphs available at http://albin.abo.fi/~mstorsjo/adpcm-graphs/.

The only one worth mentioning separately is 
http://albin.abo.fi/~mstorsjo/adpcm-graphs/music1/psnr.pdf, where the 
slight loss in quality due to patch #4 becomes visible at the higher 
trellis levels. This effect wasn't visible in the sample music2 nor in 
trailer, though.

If reading the runtime graph for the same sample, you'll notice that the 
effect on runtime is huge, so it very well is worth it, I'd say.

As for Reimar's question:

> In that case, do you feel like finding some setting that with all 
> patches is about the same speed as without patches and compare the 
> quality? IMO that would possibly be the most interesting comparison.

If reading the graphs at 
http://albin.abo.fi/~mstorsjo/adpcm-graphs/music1/, I find the following 
test runs quite similar:
Original code, -trellis 6: 26.7 seconds, stddev 87.67, PSNR 57.47
Fully patched, -trellis 8: 22.8 seconds, stddev 85.08, PSNR 57.73

Thus, with all the patches, you get better quality at comparable run 
times. Or just roughly similar quality at very much shorter run time. :-)

// Martin



More information about the ffmpeg-devel mailing list