[FFmpeg-devel] [PATCH] RealAudio 14.4K encoder
Francesco Lavra
francescolavra
Wed Jun 2 13:13:17 CEST 2010
On Sun, 2010-05-23 at 20:52 +0200, Francesco Lavra wrote:
[...]
> Floating point, with orthogonalization, with gain quantization done the
> fast way
> stddev: 210.14 PSNR: 49.88 bytes: 200000/ 200320
> stddev: 202.50 PSNR: 50.20 bytes: 143680/ 144000
> stddev: 196.30 PSNR: 50.47 bytes: 744960/ 745280
> stddev: 786.06 PSNR: 38.42 bytes: 5370560/ 5370880
> stddev: 422.29 PSNR: 43.82 bytes: 814080/ 814400
> stddev: 495.53 PSNR: 42.43 bytes: 432320/ 432640
> stddev: 396.24 PSNR: 44.37 bytes: 1741120/ 1741440
>
> Floating point, with orthogonalization, with gain quantization done
> taking into account the rounding error of the 5 best entries
> stddev: 210.49 PSNR: 49.86 bytes: 200000/ 200320
> stddev: 201.69 PSNR: 50.24 bytes: 143680/ 144000
> stddev: 200.05 PSNR: 50.31 bytes: 744960/ 745280
> stddev: 786.22 PSNR: 38.42 bytes: 5370560/ 5370880
> stddev: 419.41 PSNR: 43.88 bytes: 814080/ 814400
> stddev: 497.65 PSNR: 42.39 bytes: 432320/ 432640
> stddev: 395.23 PSNR: 44.39 bytes: 1741120/ 1741440
>
> I'd say we should go for the fast gain qantization, and in attachment is
> an cleaned up patch for it, with code duplication removed.
> I still have to try the iterative method, will do that in a few days I
> think.
I have implemented an algorithm with multiple iterations in the codebook
search, and here are the results with 2 iterations:
Floating point, with orthogonalization, with gain quantization done the
fast way, 2 iterations
stddev: 212.22 PSNR: 49.79 bytes: 200000/ 200320
stddev: 213.08 PSNR: 49.76 bytes: 143680/ 144000
stddev: 210.23 PSNR: 49.88 bytes: 744960/ 745280
stddev: 768.60 PSNR: 38.62 bytes: 5370560/ 5370880
stddev: 402.07 PSNR: 44.24 bytes: 814080/ 814400
stddev: 501.12 PSNR: 42.33 bytes: 432320/ 432640
stddev: 390.40 PSNR: 44.50 bytes: 1741120/ 1741440
As you can see, no sensible improvements are brought by this approach,
and in some cases PSNR is even worse.
In case you want to take a look a the code, it's attached: at each
iteration, the vectors used to search a given codebook are
orthogonalized with the previously found vectors from the other two
codebooks.
So my proposal is to go for the simpler method, with no iterations, like
in the attached (updated to latest svn) patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ra144enc_iterative.c
Type: text/x-csrc
Size: 16213 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100602/6edf99c6/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 05_ra144enc.patch
Type: text/x-patch
Size: 22257 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100602/6edf99c6/attachment.bin>
More information about the ffmpeg-devel
mailing list