[FFmpeg-devel] [PATCH] AMR-WB Decoder

[Marcelo Galvão Póvoa]

2010/9/18 M?ns Rullg?rd <mans at mansr.com>:
> Benjamin Larsson <banan at ludd.ltu.se> writes:
>
>> On 09/18/2010 12:15 PM, M?ns Rullg?rd wrote:
>>> Rob <robert.swain at gmail.com> writes:
>>>
>>>> On 18 September 2010 11:43, M?ns Rullg?rd <mans at mansr.com> wrote:
>>>>> Marcelo Galv?o P?voa <marspeoplester at gmail.com> writes:
>>>>>> Here is my floating point AMR-WB Decoder from GSoC. The output
>>>>>> quality seems good compared to the reference and libopencore
>>>>>> decoders.
>>>>>
>>>>> Seems good? ?Does it differ by more than +-1?
>>>>
>>>> http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/2010-September/009964.html
>>>
>>> Any difference of more than 1 from the reference needs to be understood.
>>
>> Celp codecs usually differ more cause of more steps where differences
>> can propagate.
>
> So rounding errors are amplified? ?Sounds like a bad design to me.
> However that may be, the cause discrepancies must still be understood,
> though not necessarily removed. ?If you can explain the differences,
> that is good enough for me. ?If you do not know where they come from,
> there could be bugs hiding.
>

Well, I have not tracked the errors for analyzing propagation but I
can tell that some parts (like the fixed gain and the fixed vector)
differ quite a bit between the implementations. I believe the same
applies to the existent AMR-NB decoder.

However, in all tests I did, my decoder deviation against the source
wav file (which was encoded by the reference encoder) was slightly
smaller than with the reference decoder, for example:

My decoder X original:
$ ./tests/tiny_psnr ~/am_ori.wav ~/am_new.wav 2 -190
stddev:  724.72 PSNR: 39.13 MAXDIFF: 7538 bytes:   473878/   473410

Ref decoder X original:
$ ./tests/tiny_psnr ~/am_ori.wav ~/amrwb/samples/all_men_ref.wav 2 -190
stddev:  733.69 PSNR: 39.02 MAXDIFF: 7368 bytes:   473878/   473410

My decoder X Ref decoder:
$ ./tests/tiny_psnr ~/amrwb/samples/all_men_ref.wav ~/am_new.wav 2
stddev:   54.49 PSNR: 61.60 MAXDIFF: 1088 bytes:   473600/   473600

and for a 35 min long sample:

My decoder X original:
vitor at vitor:~$ tiny_psnr orig_pod.wav soc_pod.wav 2 -190
stddev:  643.05 PSNR: 40.16 MAXDIFF:10705 bytes: 76480660/ 76480450

Ref decoder X original:
vitor at vitor:~$ tiny_psnr orig_pod.wav ref_pod.wav 2 -190
stddev:  648.78 PSNR: 40.09 MAXDIFF:10660 bytes: 76480660/ 76480450

My decoder X Ref decoder:
$ ./tests/tiny_psnr ~/ref_pod.wav ~/soc_pod.wav 2
stddev:  101.30 PSNR: 56.22 MAXDIFF: 5529 bytes: 76480640/ 76480640

The stddev when comparing both decoders is quite high I guess, but I
should point that this decoder involves a random noise excitation
generation for the higher frequency band, which may be part of the
problem.

-- 
Marcelo