[FFmpeg-devel] [PATCH] AMR-WB Decoder
Sat Sep 18 17:09:40 CEST 2010
Marcelo Galv?o P?voa <marspeoplester at gmail.com> writes:
> 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
>>>>>> Seems good? ?Does it differ by more than +-1?
>>>> 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
That is quite a difference.
> 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
Does the spec specify properties for this random noise, and are you
reasonably certain your noise generator meets the requirements? Would
it be feasible to disable this part or otherwise make your decoder and
the reference use the same signal for the purpose of comparing the
rest of the process?
mans at mansr.com
More information about the ffmpeg-devel