[FFmpeg-devel] [PATCH] adpcm: Store trellis nodes in a heap structure
Michael Niedermayer
michaelni
Fri Nov 12 13:13:13 CET 2010
On Fri, Nov 12, 2010 at 12:41:24PM +0200, Martin Storsj? wrote:
> On Thu, 11 Nov 2010, Reimar D?ffinger wrote:
>
> > On Thu, Nov 11, 2010 at 01:08:41AM +0200, Martin Storsj? wrote:
> > > > 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. :-)
> >
> > My question was rather: how does the "maximum" quality change, i.e.
> > at the highest reasonable setting.
> > I'd expect it to rather improve, but I think you so far only tested really
> > fast settings (22 seconds is not a long encoding time in any way,
> > even the original 1 minute something is still "acceptable", I remember
> > when MP3-encoding was done at I think 1/8th real-time...)
>
> Well, then I guess it's all up to how much patience you have when defining
> the "maximum" quality. If we consider 1/8th to 1/10th of realtime as
> "maximum", we get these numbers:
> Original code, -trellis 8: 245.8 seconds, stddev 83.65, PSNR 57.88
> Fully patched, -trellis 11: 189.7 seconds, stddev 83.26, PSNR 57.92
>
> However, if checking the runtime_psnr graphs at
> http://albin.abo.fi/~mstorsjo/adpcm-graphs/, one notices that the original
> (and patch #1 and patch #3) will get better PSNR/runtime if extending the
> benchmark to even larger trellis sizes. For the music1 sample, this
> happens around sometimes after ~1/15 of realtime, for the other samples it
> happens even later than that.
so id say #1-#3 are ok to commit while #4 needs more work
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101112/d5122d6a/attachment.pgp>
More information about the ffmpeg-devel
mailing list