[FFmpeg-devel] [PATCH] QCELP postfilter

[Michael Niedermayer]

On Tue, Mar 30, 2010 at 07:32:30PM +0200, Vitor Sessak wrote:
> Michael Niedermayer wrote:
>> On Tue, Mar 30, 2010 at 06:42:27PM +0200, Vitor Sessak wrote:
>>> Ronald S. Bultje wrote:
>>>> Hi,
>>>> On Mon, Mar 29, 2010 at 6:34 PM, Ronald S. Bultje <rsbultje at gmail.com> 
>>>> wrote:
>>>>> I guess my patch does something wrong. ;-). I'll see if I can get ref
>>>>> minus postfilter as a comparison.
>>>> Correction. The ref decoder always turned off the postfilter, because
>>>> the patch from that mailinglist thread you pointed out never turned it
>>>> on. ;-). No wonder it got worse.
>>>> New results: http://people.gnome.org/~rbultje/cmp2.png
>>>> Note how the last arrow ref decoder+postfilter is being clipped,
>>>> whereas our results (plus postfilter) are unclipped (and thus better).
>>>> bash-3.2$ tests/tiny_psnr ~/Desktop/out-{us,ref-pf}.wav 2 0 44
>>>> stddev:  319.49 PSNR: 46.24 bytes:  8820800/  8820800
>>> [...]
>>>
>>>> bash-3.2$ tests/tiny_psnr ~/Desktop/out-{nopf,ref-nopf}.wav 2 0 44
>>>> stddev:  281.97 PSNR: 47.33 bytes:  8820800/  8820800
>>> So adding postfiltering to both increase stddev of about 20%. A little 
>>> big but acceptable IMHO.
>> you should be testing raw encoder input against decoder output for both
>> the reference decoder and ours.
>
> I'm not really sure that applies to a postfilter patch. Its main goal is 
> not to improve PSNR...

i did not say PSNR
but conventionally the goal of a codec is to store a signal as good as
possible with as little bits as possible. The deblock fileters of various
codecs also could be argued to be intended to remove blocks and not
make the signal closer to the original PSNR or subjective wise but they
do.

so what arguments do we have that the code is correct?
it does not match the reference decoder not even slightly, and you seem to
argue its better not to test how close the 2 decoders match the original
encoder input.

Is the code correct by the assumtation that the authors made no
mistakes and so dont need _any_ testing

imho, the the decoder outputs should be compared to the encoder
input, possibly using a fft that discards phase information if that
isnt preserved by celp codecs. Or if noone wants to add the 5 lines
to call our rdft then a double blind test of which of A or B is closer
to the original.

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
-------------- 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/20100330/f0b24da9/attachment.pgp>