[FFmpeg-devel] AMR-NB decoder

[Michael Niedermayer]

On Wed, Aug 05, 2009 at 08:08:23PM +0100, 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. 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.

can be easily done in FFT domain, or simply by spliting the file up
in reasonable chunks and then instead of just comparing them against the
co-located piece try all shifts between -C ... C and use the best matching.
anyway, i think both these tests would be overkill. If the files sound
equally good than the reference there isnt much point in investigating this
much more than has already been done

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090806/14994d9e/attachment.pgp>