[FFmpeg-devel] AMR-NB decoder
Thu Aug 6 02:11:24 CEST 2009
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel