[FFmpeg-devel] Call for "make fate2" tests

[Ronald S. Bultje]

Hi,

On Fri, Jul 16, 2010 at 4:57 AM, Vitor Sessak <vitor1001 at gmail.com> wrote:
> On 07/16/2010 12:18 AM, Ronald S. Bultje wrote:
>> On Thu, Jul 15, 2010 at 5:59 PM, Vitor Sessak<vitor1001 at gmail.com> ?wrote:
>>> On 07/15/2010 11:28 PM, Ronald S. Bultje wrote:
>>>> On Thu, Jul 15, 2010 at 5:19 PM, Vitor Sessak<vitor1001 at gmail.com>
>>>> ?wrote:
>>>>> There are a few formats that could use some tests for "make fate2".
>>>>> Could
>>>>> the maintainers send a patch or at least suggest one or more files to
>>>>> test?
>>>>
>>>> WMAVoice!!!
>>>
>>> Ok course, how could I forgot it?! Can you send a sample/patch?
>>
>> http://samples.mplayerhq.hu/A-codecs/WMSP/
>>
>> I used the streaming_CBR-{7,11,19}K.wma, together they pretty much
>> expose all features of the decoder.
>
> Unfortunately, wmavoice has the same problem of AMR: the floating-point
> errors add up, making the output across arches vary considerably. Comparing
> my core duo with Mans' ppc box:
>
> stddev: ? ?0.16 PSNR:111.87 MAXDIFF: ? 10 bytes: ? 264014/ ? 264014
> stddev: ? ?1.12 PSNR: 95.34 MAXDIFF: ? 58 bytes: ? 264014/ ? 264014
> stddev: ? ?2.50 PSNR: 88.36 MAXDIFF: ? 98 bytes: ? 527906/ ? 527906

I wonder if the vocoder experts can guess with me on whether we can
create a "bitexact" version that does not have this problem. I guess
the real question is what causes this problem. Is it phase differences
b/c of slightly different return values for functions such as
cos()/sin()? In general, would this be greatly diminished if we would
replace e.g. a comfort noise with actual zeroes if the bitexact flag
is set, thereby "synchronizing" the stream?

Ronald