[FFmpeg-devel] [PATCH] RealAudio 14.4K encoder

[Vitor Sessak]

On 06/10/2010 02:03 AM, Michael Niedermayer wrote:
> On Wed, Jun 02, 2010 at 01:13:17PM +0200, Francesco Lavra wrote:
>> 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.
>
> ok

Applied. Congrats Francesco for your first patch!

> btw, is the code stable enough to add a regresion test? or is it
> giving different results between compilers/cpus?
> a reg test would be usefull

I got a different MD5 in Mans' PPC box.

-Vitor