On Mon, Jun 12, 2017 at 9:42 PM, Michael Niedermayer <mich...@niedermayer.cc> wrote: > why is there a cast at all ?
The cast is there because if you run this: ffmpeg -frames:v 5 -filter_complex "sws_flags=+accurate_rnd+bitexact;testsrc=size=320x240 [main];testsrc=size=640x360 [ref];[main][ref] scale2ref=0:print(ow/641) [main][ref];[ref] nullsink" -map "[main]" -flags +bitexact -fflags +bitexact -f md5 - This works just fine without a cast for ow. 0 == 0 is true so we set it to 640. But for oh, the print() shows that ow/641 is 0.998440. When it is truncated from a double to an integer (eval_h = res) it becomes 0. But in our comparison, 0.998440 == 0 is false so in this case eval_h will be truncated to 0 which is exactly the behavior we're trying to correct. Adding that cast resolves the issue. 0.998440 == 0 is false but (int) 0.998440 == 0 is true. For the extra cast I was talking about consider this: ffmpeg -frames:v 5 -filter_complex "sws_flags=+accurate_rnd+bitexact;testsrc=size=320x240 [main];testsrc=size=640x360 [ref];[main][ref] scale2ref=500/6:print(print(ow)*5) [main][ref];[ref] nullsink" -map "[main]" -flags +bitexact -fflags +bitexact -f md5 - That will print() 83.333333 and then 416.666667. A user might (reasonably, in my opinion) expect that the ow value (or oh) is always an integer. With the extra cast you'll see 83.000000 and 415.000000 printed. 83.333333 truncates to 83 so no (noticeable) change for ow but 416.666667 does not truncate to 415 so this is an example of a place where the lack of truncation for ow/oh does change the outcome. I hope this clears it up. Perhaps that code should just be entirely refactored to be a little more clear? Thanks, Kevin _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
