aomenc tune=vmaf result in SIGFPE, Arithmetic exception #630

eclipseo · 2020-07-17T16:08:11Z

I wanted to try tune=vmaf on some picture but the process segfault. The backtrace seems to involve libvmaf.

What steps will reproduce the problem?

/usr/bin/aomenc --tile-columns=4 --cpu-used=2 --full-still-picture-hdr --passes=2 --lossless=1 --tune=vmaf_with_preprocessing --vmaf-model-path=/usr/share/model/vmaf_v0.6.1.pkl -o AOM-VMAF_out/subset1/89_-Vézelay_Basilique_2/89-Vézelay_Basilique_2-lossless.webm /tmp/308324889-_Vézelay_Basilique_2.png.y4m

What is the expected output?
A proper webm output, vmaf tuned

What do you see instead?
"aomenc" received signal SIGFPE, Arithmetic exception.

What version / commit were you testing with? (git describe can produce this
info if building from source). On what operating system?
Tested both aom 2.0.0 and the GIT tip.
libvmaf is 1.5.2
GCC 10.0.1
Fedora 32

Please provide any additional information below.

Backtrace from GDB:

Thread 2 "aomenc" received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0x7ffff4308640 (LWP 3101722)]
0x00007ffff74fe1e3 in adm_csf_den_scale_s (src=src@entry=0x7ffff4307ab0, orig_h=orig_h@entry=806, scale=scale@entry=0, w=w@entry=630, h=h@entry=403, 
    src_stride=src_stride@entry=2528, border_factor=border_factor@entry=0.10000000000000001) at ../src/feature/adm_tools.c:337
337                             accum_inner_d += val;
(gdb) bt
#0  0x00007ffff74fe1e3 in adm_csf_den_scale_s (src=src@entry=0x7ffff4307ab0, orig_h=orig_h@entry=806, scale=scale@entry=0, w=w@entry=630, 
    h=h@entry=403, src_stride=src_stride@entry=2528, border_factor=border_factor@entry=0.10000000000000001) at ../src/feature/adm_tools.c:337
#1  0x00007ffff74fd2d5 in compute_adm (ref=ref@entry=0x5555636889a0, dis=dis@entry=0x555565982f60, w=630, w@entry=1260, h=403, h@entry=806, 
    ref_stride=ref_stride@entry=5056, dis_stride=dis_stride@entry=5056, score=0x7ffff4307cc8, score_num=0x7ffff4307cd8, score_den=0x7ffff4307ce0, 
    scores=0x7ffff4307d90, border_factor=border_factor@entry=0.10000000000000001, adm_enhn_gain_limit=adm_enhn_gain_limit@entry=100)
    at ../src/feature/adm.c:183
#2  0x00007ffff743d330 in combo_threadfunc (vmaf_thread_data=<optimized out>) at ../src/combo.c:321
#3  0x00007ffff7a6a53a in start_thread () from /lib64/libpthread.so.0
#4  0x00007ffff7645283 in clone () from /lib64/libc.so.6

The text was updated successfully, but these errors were encountered:

li-zhi · 2020-07-17T16:19:52Z

It seems the error is with the latest master. Would you please try the release v1.5.2 to see if the problem persists?

…

On Fri, Jul 17, 2020 at 9:08 AM Robert-André Mauchin < ***@***.***> wrote: I wanted to try tune=vmaf on some picture but the process segfault. The backtrace seems to involve libvmaf. What steps will reproduce the problem? 1. /usr/bin/aomenc --tile-columns=4 --cpu-used=2 --full-still-picture-hdr --passes=2 --lossless=1 --tune=vmaf_with_preprocessing --vmaf-model-path=/usr/share/model/vmaf_v0.6.1.pkl -o AOM-VMAF_out/subset1/89_-*Vézelay_Basilique_2/89*-*Vézelay_Basilique_2-lossless.webm /tmp/308324889*-_Vézelay_Basilique_2.png.y4m What is the expected output? A proper webm output, vmaf tuned What do you see instead? "aomenc" received signal SIGFPE, Arithmetic exception. What version / commit were you testing with? (git describe can produce this info if building from source). On what operating system? Tested both aom 2.0.0 and the GIT tip. libvmaf is 1.5.2 GCC 10.0.1 Fedora 32 Please provide any additional information below. Backtrace from GDB: Thread 2 "aomenc" received signal SIGFPE, Arithmetic exception. [Switching to Thread 0x7ffff4308640 (LWP 3101722)] 0x00007ffff74fe1e3 in adm_csf_den_scale_s ***@***.***=0x7ffff4307ab0, ***@***.***=806, ***@***.***=0, ***@***.***=630, ***@***.***=403, ***@***.***=2528, ***@***.***=0.10000000000000001) at ../src/feature/adm_tools.c:337 337 accum_inner_d += val; (gdb) bt #0 0x00007ffff74fe1e3 in adm_csf_den_scale_s ***@***.***=0x7ffff4307ab0, ***@***.***=806, ***@***.***=0, ***@***.***=630, ***@***.***=403, ***@***.***=2528, ***@***.***=0.10000000000000001) at ../src/feature/adm_tools.c:337 #1 0x00007ffff74fd2d5 in compute_adm ***@***.***=0x5555636889a0, ***@***.***=0x555565982f60, w=630, ***@***.***=1260, h=403, ***@***.***=806, ***@***.***=5056, ***@***.***=5056, score=0x7ffff4307cc8, score_num=0x7ffff4307cd8, score_den=0x7ffff4307ce0, scores=0x7ffff4307d90, ***@***.***=0.10000000000000001, ***@***.***=100) at ../src/feature/adm.c:183 #2 0x00007ffff743d330 in combo_threadfunc (vmaf_thread_data=<optimized out>) at ../src/combo.c:321 #3 0x00007ffff7a6a53a in start_thread () from /lib64/libpthread.so.0 #4 0x00007ffff7645283 in clone () from /lib64/libc.so.6 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#630>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AECVVEEXPYN5ASUI7NV6DITR4BZRHANCNFSM4O6PXYUQ> .

eclipseo · 2020-07-17T16:22:35Z

I tried with release 1.5.2:

What version / commit were you testing with? (git describe can produce this
info if building from source). On what operating system?
Tested both aom 2.0.0 and the GIT tip.
libvmaf is 1.5.2
GCC 10.0.1
Fedora 32

eclipseo · 2020-07-17T16:23:00Z

(gdb) info locals
abs_csf_o_val_h = 9.37698559e-08
abs_csf_o_val_v = 0
abs_csf_o_val_d = 6.69693577e-16
src_h = <optimized out>
src_v = <optimized out>
src_d = <optimized out>
src_px_stride = 632
factor1 = <optimized out>
factor2 = <optimized out>
rfactor = {0.0173815377, 0.0173815377, 0.005890687}
accum_h = 384.66391
accum_v = 1189.8446
accum_d = 2.49340606
accum_inner_h = 0.65392971
accum_inner_v = 3.14131665
accum_inner_d = 0.00294110784
den_scale_h = <optimized out>
den_scale_v = <optimized out>
den_scale_d = <optimized out>
val = 0
left = 62
top = 39
right = 568
bottom = 364
i = 284
j = 303

li-zhi · 2020-07-17T16:27:43Z

I see. The problem already existed with 1.5.2.

Could you try it on 1.5.1 instead?

eclipseo · 2020-07-17T16:37:27Z

I see. The problem already existed with 1.5.2.

Could you try it on 1.5.1 instead?

I tried with 1.5.1 which is provided by Fedora and I tried with 1.5.2 which I compiled from source. In both case the error is the same.

li-zhi · 2020-07-17T16:41:54Z

In this case, we'll have to start by reproducing the issue. I know libaom tune=vmaf keeps intermediate output. Would we be able to reproduce the error message from the intermediate video frames?

eclipseo · 2020-07-17T16:43:40Z

In this case, we'll have to start by reproducing the issue. I know libaom tune=vmaf keeps intermediate output. Would we be able to reproduce the error message from the intermediate video frames?

In this case, I'm working on a single y4m video frame. My intent was to test avif.

eclipseo · 2020-07-17T17:20:20Z

I've tried with this video: https://media.xiph.org/video/derf/y4m/vidyo4_720p_60fps.y4m
Same error, the first pass works but it segfaults with the first frame of the second pass.

li-zhi · 2020-07-17T17:36:35Z

Where you able to grab the intermediate video frames generated in the second pass?

To be sure, you are encoding a single frame?

eclipseo · 2020-07-17T17:52:45Z

Where you able to grab the intermediate video frames generated in the second pass?

Not sure how I should do that? I don't have any output from aomenc, just a segfault.

To be sure, you are encoding a single frame?

That's what I was trying to do, but as mentioned above I have the same issue with a video file.

li-zhi · 2020-07-17T17:55:24Z

Have you had any successful runs using tune=vmaf on other clips? Wondering if this is a content-dependent problem or system configuration problem.

eclipseo · 2020-07-17T17:57:08Z

Have you had any successful runs using tune=vmaf on other clips? Wondering if this is a content-dependent problem or system configuration problem.

No success, I'll be trying to recompile the entire chain in a chroot, from aom to vmaf and ffmpeg. It's probably a config issue since I seem to be the only one affected?

No luck with the re-build, still fails.

eclipseo · 2020-07-21T12:56:22Z

I have tried everything I can think of and I still have this issue:

installed on a pritine systemm
rebuilt with clang to see if the error was due to the compiler
compiled git tip of both aom and vmaf
tried other models
tried with no option other than tune=vmaf
recompiled with libvmaf as a static library (it is build shared by default on my system)

li-zhi · 2020-07-21T18:44:39Z

Could this be a Fedora issue? Have you tried on an Ubuntu?

…

On Tue, Jul 21, 2020 at 5:56 AM Robert-André Mauchin < ***@***.***> wrote: I have tried everything I can think of and I still have this issue: - installed on a pritine systemm - rebuilt with clang to see if the error was due to the compiler - compiled git tip of both aom and vmaf - tried other models - tried with no option other than tune=vmaf - recompiled with libvmaf as a static library (it is build shared by default on my system) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#630 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AECVVED5N73OGQJVUAGT6K3R4WGANANCNFSM4O6PXYUQ> .

li-zhi closed this as completed Sep 2, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

aomenc tune=vmaf result in SIGFPE, Arithmetic exception #630

aomenc tune=vmaf result in SIGFPE, Arithmetic exception #630

eclipseo commented Jul 17, 2020

li-zhi commented Jul 17, 2020 via email

eclipseo commented Jul 17, 2020

eclipseo commented Jul 17, 2020

li-zhi commented Jul 17, 2020

eclipseo commented Jul 17, 2020

li-zhi commented Jul 17, 2020

eclipseo commented Jul 17, 2020

eclipseo commented Jul 17, 2020

li-zhi commented Jul 17, 2020

eclipseo commented Jul 17, 2020

li-zhi commented Jul 17, 2020

eclipseo commented Jul 17, 2020 •

edited

Loading

eclipseo commented Jul 21, 2020

li-zhi commented Jul 21, 2020 via email

aomenc tune=vmaf result in SIGFPE, Arithmetic exception #630

aomenc tune=vmaf result in SIGFPE, Arithmetic exception #630

Comments

eclipseo commented Jul 17, 2020

li-zhi commented Jul 17, 2020 via email

eclipseo commented Jul 17, 2020

eclipseo commented Jul 17, 2020

li-zhi commented Jul 17, 2020

eclipseo commented Jul 17, 2020

li-zhi commented Jul 17, 2020

eclipseo commented Jul 17, 2020

eclipseo commented Jul 17, 2020

li-zhi commented Jul 17, 2020

eclipseo commented Jul 17, 2020

li-zhi commented Jul 17, 2020

eclipseo commented Jul 17, 2020 • edited Loading

eclipseo commented Jul 21, 2020

li-zhi commented Jul 21, 2020 via email

eclipseo commented Jul 17, 2020 •

edited

Loading