[FFmpeg-devel] [PATCH 3/7] avfilter/vf_framerate: factorize blend_frames

Michael Niedermayer michael at niedermayer.cc
Fri Jan 5 00:40:30 EET 2018


On Thu, Jan 04, 2018 at 01:36:01AM +0100, Marton Balint wrote:
> 
> 
> 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.

if the FPU state is corrupted then i dont thing using integer will solve "that".
tracing back where it becomes corrupted and (likely adding a emms) would fix
it

IIRC there was a patch that did check the FPU state in some memory alloc 
related functions

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180104/d5e47a8e/attachment.sig>


More information about the ffmpeg-devel mailing list