[FFmpeg-devel] [PATCH 3/7] avfilter/vf_framerate: factorize blend_frames
Marton Balint
cus at passwd.hu
Thu Jan 4 02:36:01 EET 2018
On Wed, 3 Jan 2018, Michael Niedermayer wrote:
> On Wed, Jan 03, 2018 at 08:00:24PM +0100, Marton Balint wrote:
>>
>>
>> On Wed, 3 Jan 2018, Marton Balint wrote:
>>
>>>
>>> On Tue, 2 Jan 2018, Michael Niedermayer wrote:
>>>
>>>> On Sun, Dec 10, 2017 at 11:11:18PM +0100, Marton Balint wrote:
>>>>> Signed-off-by: Marton Balint <cus at passwd.hu>
>>>>> ---
>>>>> libavfilter/vf_framerate.c | 54
>>> ++++++----------------------------------------
>>>>> 1 file changed, 7 insertions(+), 47 deletions(-)
>>>>
>>>> This broke fate-filter-framerate-up on x86-32 (gcc 4.8 (Ubuntu
>>> 4.8.5-2ubuntu1~14.04.1))
>>>>
>>>> --- tests/ref/fate/filter-framerate-up 2017-12-31 19:27:30.039451874
>>> +0100
>>>> +++ tests/data/fate/filter-framerate-up 2018-01-02 02:12:56.151674862
>>> +0100
>>>> @@ -4,12 +4,12 @@
>>>> #dimensions 0: 320x240
>>>> #sar 0: 1/1
>>>> 0, 0, 0, 1, 115200, 0x3744b3ed
>>>> -0, 1, 1, 1, 115200, 0xc44bdc65
>>>> -0, 2, 2, 1, 115200, 0xa17f0d74
>>>> -0, 3, 3, 1, 115200, 0xb0c83274
>>>> -0, 4, 4, 1, 115200, 0x232d6368
>>>> +0, 1, 1, 1, 115200, 0x3744b3ed
>>>> +0, 2, 2, 1, 115200, 0x3744b3ed
>>>> +0, 3, 3, 1, 115200, 0x3744b3ed
>>>> +0, 4, 4, 1, 115200, 0x6e318ba0
>>>> 0, 5, 5, 1, 115200, 0x6e318ba0
>>>> -0, 6, 6, 1, 115200, 0x247e846e
>>>> -0, 7, 7, 1, 115200, 0x89e27599
>>>> -0, 8, 8, 1, 115200, 0x31c5704e
>>>> -0, 9, 9, 1, 115200, 0x97e45fec
>>>> +0, 6, 6, 1, 115200, 0x6e318ba0
>>>> +0, 7, 7, 1, 115200, 0x6e318ba0
>>>> +0, 8, 8, 1, 115200, 0x6e318ba0
>>>> +0, 9, 9, 1, 115200, 0x48d65876
>>>> Test filter-framerate-up failed. Look at
>>> tests/data/fate/filter-framerate-up.err for details.
>>>> make: *** [fate-filter-framerate-up] Error 1
>>>>
>>>> in master the diff now looks like this:
>>>> --- tests/ref/fate/filter-framerate-up 2017-12-31 19:27:30.039451874
>>> +0100
>>>> +++ tests/data/fate/filter-framerate-up 2018-01-02 02:42:46.103712572
>>> +0100
>>>> @@ -4,12 +4,12 @@
>>>> #dimensions 0: 320x240
>>>> #sar 0: 1/1
>>>> 0, 0, 0, 1, 115200, 0x3744b3ed
>>>> -0, 1, 1, 1, 115200, 0xc44bdc65
>>>> +0, 1, 1, 1, 115200, 0x3744b3ed
>>>> 0, 2, 2, 1, 115200, 0xa17f0d74
>>>> 0, 3, 3, 1, 115200, 0xb0c83274
>>>> 0, 4, 4, 1, 115200, 0x232d6368
>>>> 0, 5, 5, 1, 115200, 0x6e318ba0
>>>> -0, 6, 6, 1, 115200, 0x247e846e
>>>> +0, 6, 6, 1, 115200, 0x6e318ba0
>>>> 0, 7, 7, 1, 115200, 0x89e27599
>>>> 0, 8, 8, 1, 115200, 0x31c5704e
>>>> 0, 9, 9, 1, 115200, 0x97e45fec
>>>> Test filter-framerate-up failed. Look at
>>> tests/data/fate/filter-framerate-up.err for details.
>>>> make: *** [fate-filter-framerate-up] Error 1
>>>
>>> Does not happen if compiled with -O1 or -O0. With -O2 and -O3
>>> fabsf(intepolate) becomes NaN.
>>>
>>> I am guessing that some floating point state is lost because of the SAD
>>> MMX instructions, but I don't know if this is a compiler bug or something
>>> should be done differently.
>>>
>>> Do you have an idea how to proceeed?
>>
>> I guess I will just commit the patch which eliminates the floating point
>> calculations, that should fix this failure as well.
>
> yes, less fpu is better.
>
> ive not had time to look so its a far fetched guess,
> maybe something is exactly between 2 integers rounding wise and that gets
> sent to different sides on different platforms
I don't think so, as my debugging showed NaN values for
fabsf(interpolate), so this does not look like a simple rouding error,
but some strange FPU state corruption.
In any case, integer math will solve it.
Regards,
Marton
More information about the ffmpeg-devel
mailing list