[FFmpeg-devel] Review request - ra288.{c,h} ra144.{c,h}

Vitor Sessak vitor1001
Sun Sep 14 20:11:52 CEST 2008


Siarhei Siamashka wrote:
> On Sunday 14 September 2008, Vitor Sessak wrote:
>> Michael Niedermayer wrote:
> [...]
>>> If you want a proof that it is better, you should compare the original
>>> pcm that is
>>>
>>> X -> encoder -> binary decoder -> Y
>>>              -> FF decoder ->Z
>>>
>>> and look at how the X-Y and X-Z change relative to each other.
>>>
>>> Also you would see a similar PSNR change relative to the binary decoder
>>> if you would output floats.
>> I've already tried comparing PSNR to the original input when I was
>> looking for a way to test float codecs in FATE.
>>
>> vitor at vitor$ ffmpeg -i luckynightmono2.ra -ac 1 -ar 8000 test.wav
>> vitor at vitor$ ffmpeg -i luckynight.wav -ac 1 -ar 8000 test2.wav
>> vitor at vitor$ tiny_psnr test.wav test2.wav 2 0 44
>> stddev: 5981.39 PSNR: 20.78 bytes:   990720/   967662
>> vitor at vitor$ tiny_psnr test.wav test2.wav 2 2 44
>> stddev: 5982.77 PSNR: 20.78 bytes:   990718/   967662
>> vitor at vitor$ tiny_psnr test.wav test2.wav 2 100 44
>> stddev: 6012.76 PSNR: 20.74 bytes:   990620/   967662
>>
>> And by looking at results, if I change the "skip bytes" parameter I
>> don't get much change in PSNR. For me, this is a signal that the value I
>> got is meaningless (since it don't change a lot if I compare it with
>> different data). I asked about it in IRC and people told me that PSNR
>> didn't worked very well to LPC vocoders. Sample in
>> http://samples.mplayerhq.hu/real/AC-28_8/ .
> 
> You can try this patch for tiny_psnr, I'm using it in my experiments with
> audio decoding. See
> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/37796/focus=38052
> and
> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/74535/
> 
> Don't know if it helps you, but I find it quite useful. For example, ffvorbis
> decoder produces inverted output and standard tiny_psnr can't be used to
> compare it with libvorbis output (it just can't see anything common in the
> files and reports a horrible PSNR with the numbers similar to what you got).

Thanks for the tip, but it didn't work. I think the problem here is more 
complicated...

-Vitor




More information about the ffmpeg-devel mailing list