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

Marcelo Galvão Póvoa marspeoplester
Sun Sep 19 03:14:04 CEST 2010

On 18 September 2010 12:01, Justin Ruggles <justin.ruggles at gmail.com> wrote:
> Marcelo Galv?o P?voa wrote:
>> 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:
>> [...]
>> 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.
> You could try doing a test using a different random generator in your
> decoder and compare the 2 to see if that accounts for approximately the
> same amount of difference.

Ok, I tried using the av_mlfg_get() instead of the av_lfg_get() PRNG
and the output stddev is higher than I would expect. So the cause of
the deviation against the reference decoder may be that.

$ ./tests/tiny_psnr ~/soc_pod.wav ~/pod_new_random.wav 2
stddev:   95.96 PSNR: 56.69 MAXDIFF: 7011 bytes: 76480640/ 76480640

$ ./tests/tiny_psnr ~/ref_pod.wav ~/pod_new_random.wav 2
stddev:  101.32 PSNR: 56.22 MAXDIFF: 5758 bytes: 76480640/ 76480640


More information about the ffmpeg-devel mailing list