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

[Siarhei Siamashka]

On Tuesday 16 September 2008, Vitor Sessak wrote:
> Siarhei Siamashka wrote:
[...]
> >> The problem is not just when using PSNR, but I also fail to see any
> >> similarity between the two files in a hex editor. I'd say that it is
> >> very unlikely that using lrintf() would worsen the quality (and even if
> >> it does, such a small change would be completely inaudible in such a low
> >> quality codec). So I'd change to lrintf() and put a comment explaining
> >> the situation. Are you fine with this?
> >
> > This is getting quite interesting. Could you upload original wav file and
> > encoded->decoded ones somewhere (maybe loslessly compressed)?
>
> Sure:
>
> http://samples.mplayerhq.hu/real/AC-28_8/luckynightmono2.ra
> http://samples.mplayerhq.hu/A-codecs/lossless/luckynight.flac
>
> $ ffmpeg -i luckynightmono2.ra decoded.wav
> $ ffmpeg -i luckynight.flac -ac 1 -ar 8000 original.wav
>
> > Did the updated tiny_psnr that I sent before detect any shift or it
> > failed completely?
>
> $ tiny_psnr  decoded.wav original.wav 96 - 44
> shift autodetection...
> done, detected as 78
> trying to confirm shift... failed (detected as 878)
>
> $ tiny_psnr  decoded.wav original.wav 2 96 44
> stddev: 6039.35 PSNR: 20.70 bytes:   990624/   967666
>
> $ tiny_psnr  decoded.wav original.wav 2 0 44
> stddev: 5994.93 PSNR: 20.76 bytes:   990720/   967666
>

Thanks for the files, the results are quite interesting:

./tiny_psnr decoded.wav original.wav 2 - 100000
shift autodetection...
done, detected as 318
trying to confirm shift... failed (detected as 462)

./tiny_psnr decoded.wav original.wav 2 - 200000
shift autodetection...
done, detected as 524
trying to confirm shift... failed (detected as 702)

./tiny_psnr decoded.wav original.wav 2 - 300000
shift autodetection...
done, detected as 768
trying to confirm shift... failed (detected as 946)

./tiny_psnr decoded.wav original.wav 2 - 400000
shift autodetection...
done, detected as 984
trying to confirm shift... failed (detected as 1002)

./tiny_psnr decoded.wav original.wav 2 - 500000
shift autodetection...
done, detected as 1224
trying to confirm shift... failed (detected as 1380)

Autodetector first tries to detect optimal shift for the starting 64K block of
data, then moves to the next 64K block to verify that the shift is
consistent. In the log above, a clearly visible pattern is observed. Looks
like the shift is not constant, but is gradually increasing as we progress
forward from the beginning of file to its end.

Maybe adding some kind of resampling autodetection filter to the tiny_psnr
can help to analyze such files. But it would become not 'tiny' anymore :)

> > You can try experimenting with compression of a simple signal, something
> > like sine and check if you can see similarities in the input and output
> > files. And then change this signal to something more complicated until
> > the differences start getting more visible.
>
> I'm not sure that it is worth the trouble just to decide on using
> lrintf() or not...

I see. Anyway, I don't like lrintf, it's slow, not quite portable (depends on
global rounding settings) and it is only useful on very old x86 systems (for
which 'ff_float_to_int16_c' exists). Also as far as I know, SIMD instructions
at least from 3DNOW and ARM NEON only efficiently support conversion with
rounding to zero (please correct me if I'm wrong). And conversion to int with
rounding to zero should be supported well on any hardware designed to be C
language friendly.

-- 
Best regards,
Siarhei Siamashka