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

Siarhei Siamashka siarhei.siamashka
Tue Sep 16 21:33:00 CEST 2008


On Tuesday 16 September 2008, Vitor Sessak wrote:
> Michael Niedermayer wrote:
[...]
> >>>>> how has the .ra file been generated?
> >>>>> what happens with a 2x as long input file? does the size difference
> >>>>> stay constant or grow?
> >>>>>
> >>>>> what does the binary decoder produce for it? is that also too big?
> >>>>
> >>>> Original     wav:  967706 bytes
> >>>> FFmpeg   decoder:  990764 bytes
> >>>> Original decoder: 1013804 bytes
> >>>>
> >>>> Go figure...
> >>>
> >>> the decoder outputs 3 seconds more than what is in the claimed
> >>> original. How does it sound? is the audio stretched to the bigger
> >>> length are there 3 seconds of distortion or silence somewhere?
> >>
> >> Original     wav:  967706 bytes
> >> FFmpeg   decoder:  990764 bytes   1 second  of silence in the end
> >> Original decoder: 1013804 bytes   3 seconds of silence in the end
> >>
> >> Anyway, nothing of that explains the PSNR discrepancy...
> >
> > ok, so lets forget about the PSNR, and rather try a simpler test for
> > the accuracy, just try to cast a float to an int and try lrintf()
> > and print the differens, or sum or squared differences, it should be
> > obvious which is more accurate.
>
> 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)?

Did the updated tiny_psnr that I sent before detect any shift or it failed
completely? For example, for 320 kbit mp3 file encoded with lame and all
psy-stuff disabled (-q 9), standard deviation is still something like ~200,
which is quite high, but it definitely indicates that there are similarities.

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.

-- 
Best regards,
Siarhei Siamashka




More information about the ffmpeg-devel mailing list