[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