On 2/2/2016 6:13 AM, Hendrik Leppkes wrote: >> tiny_psnr doesn't seem to do s32 either, only f32. How hard would it be to >> add >> it, or s24? > > If anything I think we should make it test f32 since thats the native > output mode, or stick to the usual s16 as converted by swr. > Using the bitexact fixed point code path for those samples to get s24 > out of the decoder would leave the float path entirely untested. >
I didn't mean using bitexact fixed point decoding, just adding s24/32 support to tiny_psnr and use that, which should behave the same way as s16 (dca decodes as float, swr converts to int, tiny_psnr compares that). But in any case f32 is ok. >> >>> Would require more careful tuning of the test though, as the precision >>> on different systems will definitely differ then. >> >> Changing the tests to make them use f32 seems to need a FUZZ of at least 7. > > mp3 uses a fuzz of 17, so its likely going to require higher fuzz > values on different systems. > Will only find out after seeing it fail on FATE on a bunch of systems though. > >> >> I'd like foo86 to chime in and give his opinion in the matter, but in any >> case >> this is not a blocker so if you think s16 is fine then go ahead. > > We can also go with f32, its not going to be "worse" than a s16 test, > just need to be prepared to update the fuzz values in the first couple > days. It should be better at best or the same at worst, assuming we don't go too lax with the FUZZ value. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
