[FFmpeg-devel] AMR-NB decoder

[Vitor Sessak]

Colin McQuillan wrote:
> 2009/8/5 Vitor Sessak <vitor1001 at gmail.com>:
>> Colin McQuillan wrote:
>>> 2009/8/5 Vitor Sessak <vitor1001 at gmail.com>:
>>>> Hi, and good work!
>>>>
>>>> Colin McQuillan wrote:
>>>>> Attached is a patch for an AMR-NB decoder.
>>>>>
>>>>> It is not bit-exact.
>>>> Neither it could be, it is float-based. The best you could get would be a
>>>> stddev of ~0.05.
>>>>
>>>>> This makes it tricky to verify, but I have been
>>>>> checking that internal parameters match the 3GPP decoder for the AMR
>>>>> test sequences. The PSNR between the input and output is 3.90 to 8.42
>>>>> which is about the same as the reference decoder.
>>>> I suppose here you mean the stddev, not the PSNR. Also, what command are
>>>> you
>>>> using to compare the results? Are you setting elem_size to 2? Could you
>>>> paste the output of tiny_psnr for the test vectors (and a real-world
>>>> sample
>>>> ideally)?
>>> I forgot to add elem_size to my tiny_psnr script. PSNR is now actually
>>> between 20 and 80. (and from encoder input, the PSNR is about 20 to
>>> 40)
>>>
>>> samples/A-codecs/amr/sample.amr compared against ref decoder output:
>>> stddev:   24.22 PSNR: 68.63 bytes:   797760/   797760
>>>
>>> The test vector tiny_psnr output is attached because there's 169 of them.
>>>
>>> soc/T_102/T00_102.raw: stddev:   55.89 PSNR: 61.37 bytes:    90560/
>>>  90560
>>> soc/T_102/T01_102.raw: stddev: 5283.25 PSNR: 21.86 bytes:    90560/
>>>  90560
>>> soc/T_102/T02_102.raw: stddev:  999.99 PSNR: 36.32 bytes:   128000/
>>> 128000
>>> soc/T_102/T03_102.raw: stddev: 3327.29 PSNR: 25.88 bytes:   128000/
>>> 128000
>>> soc/T_102/T04_102.raw: stddev:  228.36 PSNR: 49.15 bytes:    95680/
>>>  95680
>>> soc/T_102/T05_102.raw: stddev:  248.60 PSNR: 48.41 bytes:    71040/
>>>  71040
>>> soc/T_102/T06_102.raw: stddev:   65.63 PSNR: 59.98 bytes:   106560/
>>> 106560
>>> soc/T_102/T07_102.raw: stddev:   72.93 PSNR: 59.06 bytes:   115520/
>>> 115520
>>> soc/T_102/T08_102.raw: stddev: 1831.37 PSNR: 31.06 bytes:   108160/
>>> 108160
>>> soc/T_102/T09_102.raw: stddev:   47.08 PSNR: 62.86 bytes:   129600/
>>> 129600
>> Wow, that's a pretty variated bunch. It really gives an impression that
>> there is some feature that is not properly decoded (an psnr of 22 is pretty
>> low). Does the output of T01_102.raw sounds the same as the ref decoder?
> 
> T01_102.raw was different, I made a mistake with how I clip samples
> and didn't rerun the tests. After reverting this change, the psnr's
> are as attached.
> 
> The T02/T03 tests still have a high PSNR but do sound the same as the
> ref decoder. T02/T03 are pure tones going from low to high. A pure
> tone will be encoded in AMR (or any CELP codec) using feedback. This
> explains why the floating-point decoder differs so much from the ref
> output - errors can accumulate. 

One way to see if this is true is to compare the original (pre-encoding) 
  data with the decoded file by both decoders. If it is just an 
arbitrary rounding that accumulates, ffamr should perform better than 
ref in about 50% of the files.

> The internal parameters are all very
> close to the reference decoder. Unfortunately I don't know how to test
> the output to show whether it's just a difference in phase.

Maybe plotting both outputs with gnuplot?

-Vitor