[FFmpeg-devel] [PATCH] libavfilter/scale: Populate ow/oh when using 0 as w/h

[Kevin Mark]

On Mon, Jun 12, 2017 at 9:42 PM, Michael Niedermayer
<michael at 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