Created attachment 210189 [details] v1 Let's enable hardware acceleration on Intel GPUs. QSV adds more features on top of VAAPI, using CM runtime to offload more work to GPU. For encoding iHD driver is required, see https://github.com/ffmpeg/ffmpeg/commit/468f00384338 Disclaimer: I don't use Handbrake. Only build was tested but h264_qsv works fine in *system* FFmpeg.
Created attachment 210190 [details] v1.1 (In reply to Jan Beich from comment #0) > For encoding iHD driver is required, see https://github.com/ffmpeg/ffmpeg/commit/468f00384338 Looks like "H.264 (Intel QSV)" shows up even with only i965 driver. During encoding intel_gpu_top shows 30% usage on Skylake but, like with iHD, CPU usage is abnormally high compared to ffmpeg. Let's not force iHD dependency as it only works on Broadwell or later.
Thanks for the patch. It's a nice Christmas present to me. But unfortunately my FreeBSD machine has crashed by accident. All of my zfs pools have gone... I'm installing FreeBSD and setting up my PC now. So please wait for my recovering the development environment. I will check your patch as soon as possible. My PC has Skylake processor that is enough to check QSV, I think.
If you want the feature on /quarterly (default package set on -RELEASEs) to get widest exposure try to review/test before 2020-01-01 (UTC) when 2020Q1 is planned to branch. Otherwise, it'd bake on /latest (default on -CURRENT and -STABLE) until 2020Q2.
Sorry for my late response. v1.1 works fine with the latest intel-media-sdk. It looks good to me. I don't mind about quarterly branch. I can't help because my test was not in time. pkubaj@ Please check that v1.1 patch can be built and works as same as before on your powerpc64 machine. I think v1.1 has no functional change for powerpc64.
(In reply to Yuichiro NAITO from comment #4) > I don't mind about quarterly branch. > I can't help because my test was not in time. If you want I can add MFH tag to commit message in order to ask for approval from ports-secteam@. No guarantee they're going to reply at all due to being understaffed and not very good at assessing risk. Most MFHs land via blanket approval as bustage/security/reliability/regression fixes.
(In reply to Yuichiro NAITO from comment #4) Looks ok on both 12.1 and CURRENT.
(In reply to Jan Beich from comment #5) >If you want I can add MFH tag to commit message in order to ask for approval >from ports-secteam@. No guarantee they're going to reply at all due to being >understaffed and not very good at assessing risk. Most MFHs land via blanket >approval as bustage/security/reliability/regression fixes. Thanks for the information. QSV support is very important to HandBrake users, I want to add MFH tag for them. (Of course I understand there is no guarantee.) And for me, I want to make a presentation of this patch in FreeBSD workshop in Tokyo (the organizer is hrs@) on Jan, 16th. If it would be MFHed, I could introduce this feature more easy way. Any way, please commit v1.1 patch. Thank you!
A commit references this bug: Author: jbeich Date: Fri Jan 3 09:01:26 UTC 2020 New revision: 521913 URL: https://svnweb.freebsd.org/changeset/ports/521913 Log: multimedia/handbrake: enable Intel Quick Sync Video PR: 242849 Approved by: Yuichiro NAITO (maintainer) Tested by: Yuichiro NAITO, pkubaj (powerpc64) MFH: 2020Q1 (opt-in at runtime, requested by maintainer) Changes: head/multimedia/handbrake/Makefile head/multimedia/handbrake/files/patch-contrib_ffmpeg_module.defs head/multimedia/handbrake/files/patch-gtk_configure.ac head/multimedia/handbrake/files/patch-libhb_handbrake_ports.h head/multimedia/handbrake/files/patch-libhb_module.defs head/multimedia/handbrake/files/patch-libhb_ports.c head/multimedia/handbrake/files/patch-libhb_qsv__common.c head/multimedia/handbrake/files/patch-make_configure.py head/multimedia/handbrake/files/patch-make_include_main.defs head/multimedia/handbrake/files/patch-test_module.defs
A commit references this bug: Author: jbeich Date: Fri Jan 3 18:45:04 UTC 2020 New revision: 521951 URL: https://svnweb.freebsd.org/changeset/ports/521951 Log: multimedia/handbrake: fix r521913 upstreaming issues - Unbreak QSV build on non-FreeBSD - LIBHB.dll is only used on MinGW - No need to touch __deps__, just exclude MODULE PR: 242849 Changes: head/multimedia/handbrake/files/patch-contrib_ffmpeg_module.defs head/multimedia/handbrake/files/patch-libhb_module.defs head/multimedia/handbrake/files/patch-make_include_main.defs
Created attachment 210422 [details] future Here's the diff I've used when upstreaming. It may help you to prepare for the next release when the patches from here are integrated.
(In reply to Jan Beich from comment #10) Thank you very much! As HandBrake-1.3.1 has been released, I start to update HandBrake port.
With QSV enabled by default, after I upgraded my ports HandBrake failed to start with an illegal instruction error. I have an amd64 machine with an Nvidia graphics card. No Intel devices to do the work. Disabling the option for QSV and rebuilding yielded a working HandBrake. Setting the default to disabled would have avoided some hours of troubleshooting this issue. IDK if HandBrake is supposed to enable/disable the capability at runtime, but it did not in my case. output of uname -rms FreeBSD 11.3-RELEASE-p9 amd64 output of HandBrake -x HandBrake -x (null): create_builder_or_die() (null): ghb_ui_update() activity_location (null): get_setting_key () (null): ghb_widget_to_setting (null): get_setting_key () (null): get_setting_key () Illegal instruction (core dumped)
Would you show me your stack trace when HandBrake failed. You can see it by following steps. 1. make sure that `make config` has MFX option. 2. rebuild with debug symbols. `make -DWITH_DEBUG=YES reinstall` 3. run HandBrake 4. check your corefile and show back trace Ex. lldb /usr/local/bin/ghb -c ghb.core (lldb)bt
A commit references this bug: Author: jbeich Date: Tue May 26 04:11:59 UTC 2020 New revision: 536569 URL: https://svnweb.freebsd.org/changeset/ports/536569 Log: multimedia/intel-media-sdk: drop global -msse4.2 PR: 242849 Reported by: bitbucket63-it@yahoo.com Changes: head/multimedia/intel-media-sdk/Makefile head/multimedia/intel-media-sdk/distinfo
A commit references this bug: Author: jbeich Date: Tue May 26 04:12:35 UTC 2020 New revision: 536570 URL: https://svnweb.freebsd.org/changeset/ports/536570 Log: MFH: r536569 multimedia/intel-media-sdk: drop global -msse4.2 PR: 242849 Reported by: bitbucket63-it@yahoo.com Approved by: ports-secteam blanket (crashfix) Changes: _U branches/2020Q2/ branches/2020Q2/multimedia/intel-media-sdk/Makefile branches/2020Q2/multimedia/intel-media-sdk/distinfo
(In reply to bitbucket63-it from comment #12) If it still crashes build intel-media-sdk with WITH_DEBUG=1 as well. (In reply to Yuichiro NAITO from comment #13) > `make -DWITH_DEBUG=YES reinstall` -DWITH_DEBUG or WITH_DEBUG=1. Using both -D and = would lead to = being part of the variable name. $ make -DWITH_DEBUG=YES -V WITH_DEBUG $ make -DWITH_DEBUG=YES -V WITH_DEBUG=YES 1
(In reply to Jan Beich from comment #16) I’ll give that a shot. Might be a day or two before I can report back.
(in reply to comment #13 and comment #16) I tried making multimedia/intel-media-sdk using WITH_DEBUG=YES but it did not work -- there was a compiler error. So I did make clean && make CCACHE_DISABLE=yes reinstall for it. Then in multimedia/handbrake I did make clean && make CCACHE_DISABLE=YES WITH_DEBUG=YES reinstall. Here is what I got from the backtrace: lldb /usr/local/bin/ghb -c ghb.core (lldb) target create "/usr/local/bin/ghb" --core "ghb.core" Core file '/home/jtm/tmp/ghb.core' (x86_64) was loaded. (lldb) bt * thread #1, name = 'ghb', stop reason = signal SIGILL * frame #0: 0x0000000817f9cdce libmfxhw64.so.1`___lldb_unnamed_symbol3840$$libmfxhw64.so.1 + 542 frame #1: 0x0000000817f9fb6a libmfxhw64.so.1`___lldb_unnamed_symbol3881$$libmfxhw64.so.1 + 410 frame #2: 0x000000081812c8e2 libmfxhw64.so.1`___lldb_unnamed_symbol10114$$libmfxhw64.so.1 + 1586 frame #3: 0x0000000817e55d66 libmfxhw64.so.1 frame #4: 0x0000000802a8b85e ld-elf.so.1`objlist_call_init(list=<unavailable>, lockstate=<unavailable>) at rtld.c:2697:6 frame #5: 0x0000000802a902ea ld-elf.so.1`dlopen_object(name="libmfxhw64.so.1", fd=<unavailable>, refobj=<unavailable>, lo_flags=<unavailable>, mode=2, lockstate=0x0000000800000002) at rtld.c:3419:2 frame #6: 0x0000000802a8cb5d ld-elf.so.1`rtld_dlopen(name="libmfxhw64.so.1", fd=-1, mode=<unavailable>) at rtld.c:3284:13 frame #7: 0x00000008095a54a4 libmfx.so.1`___lldb_unnamed_symbol1$$libmfx.so.1 + 20 frame #8: 0x00000008095a5782 libmfx.so.1`___lldb_unnamed_symbol2$$libmfx.so.1 + 626 frame #9: 0x00000008095a64a6 libmfx.so.1`MFXInitEx + 134 frame #10: 0x00000008095a63fd libmfx.so.1`MFXInit + 205 frame #11: 0x000000000049c6dd ghb`hb_qsv_info_init + 301 frame #12: 0x0000000000486cb6 ghb`hb_global_init + 38 frame #13: 0x000000000045191d ghb`ghb_backend_init + 13 frame #14: 0x0000000000440186 ghb`ghb_activate_cb + 1798 frame #15: 0x0000000805ecfd5d libgobject-2.0.so.0`g_closure_invoke + 189 frame #16: 0x0000000805ee6068 libgobject-2.0.so.0`___lldb_unnamed_symbol208$$libgobject-2.0.so.0 + 2488 frame #17: 0x0000000805ee6b78 libgobject-2.0.so.0`g_signal_emit_valist + 2104 frame #18: 0x0000000805ee7216 libgobject-2.0.so.0`g_signal_emit + 134 frame #19: 0x0000000804a958fe libgio-2.0.so.0`___lldb_unnamed_symbol1198$$libgio-2.0.so.0 + 1438 frame #20: 0x0000000804a93fb1 libgio-2.0.so.0`g_application_run + 353 frame #21: 0x00000000004414f4 ghb`main + 260 frame #22: 0x0000000000421b8c ghb`_start + 140 (lldb) I hope this is helpful.
(In reply to bitbucket63-it from comment #18) Thanks for showing me the backtrace. I'm little confused about the result. The backtrace shows that illegal instruction is in unknown function name. And the function is called from `objlist_call_init()` that calls initialize function (usually _init() is written in elf header) of dynamic link library. I think initialize function is generated by the compiler. If it is broken, that means all dynamic link libraries compiled by the same compiler would fail initialization. I think such kind of things hardly happen. To see what instruction is illegal, Would you disassemble by the following lldb command? $ lldb /usr/local/bin/ghb -c ghb.core (lldb) disassemble -f This will show all instructions in that function.
(In reply to Yuichiro NAITO from comment #19) Here is the output I got from that. (lldb) target create "/usr/local/bin/ghb" --core "ghb.core" Core file '/home/jtm/tmp/ghb.core' (x86_64) was loaded. libmfxhw64.so.1`___lldb_unnamed_symbol3840$$libmfxhw64.so.1: 0x817f9cbb0 <+0>: pushq %rbp 0x817f9cbb1 <+1>: movq %rsp, %rbp 0x817f9cbb4 <+4>: pushq %r15 0x817f9cbb6 <+6>: pushq %r14 0x817f9cbb8 <+8>: pushq %r13 0x817f9cbba <+10>: pushq %r12 0x817f9cbbc <+12>: pushq %rbx 0x817f9cbbd <+13>: subq $0x28, %rsp 0x817f9cbc1 <+17>: movq %rcx, -0x48(%rbp) 0x817f9cbc5 <+21>: movq %rdx, %r14 0x817f9cbc8 <+24>: movq %rsi, %r15 0x817f9cbcb <+27>: movq %rdi, -0x38(%rbp) 0x817f9cbcf <+31>: movq %rdx, %rdi 0x817f9cbd2 <+34>: callq 0x19cfe0 ; ___lldb_unnamed_symbol3842$$libmfxhw64.so.1 0x817f9cbd7 <+39>: movq %rax, %r12 0x817f9cbda <+42>: movq 0x8(%r15), %r13 0x817f9cbde <+46>: testq %r13, %r13 0x817f9cbe1 <+49>: je 0x19cbfe ; <+78> 0x817f9cbe3 <+51>: leaq -0x1(%r13), %rcx 0x817f9cbe7 <+55>: testq %r13, %rcx 0x817f9cbea <+58>: je 0x19cc03 ; <+83> 0x817f9cbec <+60>: cmpq %r13, %r12 0x817f9cbef <+63>: movq %r12, %rdx 0x817f9cbf2 <+66>: jb 0x19cc09 ; <+89> 0x817f9cbf4 <+68>: movq %r12, %rax 0x817f9cbf7 <+71>: xorl %edx, %edx 0x817f9cbf9 <+73>: divq %r13 0x817f9cbfc <+76>: jmp 0x19cc09 ; <+89> 0x817f9cbfe <+78>: jmp 0x19cd0c ; <+348> 0x817f9cc03 <+83>: movq %rcx, %rdx 0x817f9cc06 <+86>: andq %r12, %rdx 0x817f9cc09 <+89>: movq (%r15), %rax 0x817f9cc0c <+92>: movq (%rax,%rdx,8), %rax 0x817f9cc10 <+96>: testq %rax, %rax 0x817f9cc13 <+99>: movq %rdx, -0x40(%rbp) 0x817f9cc17 <+103>: je 0x19cd0c ; <+348> 0x817f9cc1d <+109>: movq (%rax), %rbx 0x817f9cc20 <+112>: testq %rbx, %rbx 0x817f9cc23 <+115>: je 0x19cd0c ; <+348> 0x817f9cc29 <+121>: movq (%r14), %rsi 0x817f9cc2c <+124>: movzwl 0x8(%r14), %edi 0x817f9cc31 <+129>: movzwl 0xa(%r14), %r8d 0x817f9cc36 <+134>: movb 0xc(%r14), %r9b 0x817f9cc3a <+138>: movb 0xd(%r14), %r10b 0x817f9cc3e <+142>: movb 0xe(%r14), %r11b 0x817f9cc42 <+146>: movb 0xf(%r14), %al 0x817f9cc46 <+150>: movb %al, -0x2c(%rbp) 0x817f9cc49 <+153>: movb 0x10(%r14), %al 0x817f9cc4d <+157>: movb %al, -0x2b(%rbp) 0x817f9cc50 <+160>: movb 0x11(%r14), %al 0x817f9cc54 <+164>: movb %al, -0x2a(%rbp) 0x817f9cc57 <+167>: movb 0x12(%r14), %al 0x817f9cc5b <+171>: movb %al, -0x29(%rbp) 0x817f9cc5e <+174>: movb 0x13(%r14), %r14b 0x817f9cc62 <+178>: nopw %cs:(%rax,%rax) 0x817f9cc6c <+188>: nopl (%rax) 0x817f9cc70 <+192>: movq 0x8(%rbx), %rax 0x817f9cc74 <+196>: cmpq %r12, %rax 0x817f9cc77 <+199>: je 0x19cc9e ; <+238> 0x817f9cc79 <+201>: testq %r13, %rcx 0x817f9cc7c <+204>: je 0x19cc96 ; <+230> 0x817f9cc7e <+206>: cmpq %r13, %rax 0x817f9cc81 <+209>: jb 0x19cc99 ; <+233> 0x817f9cc83 <+211>: xorl %edx, %edx 0x817f9cc85 <+213>: divq %r13 0x817f9cc88 <+216>: movq %rdx, %rax 0x817f9cc8b <+219>: movq -0x40(%rbp), %rdx 0x817f9cc8f <+223>: cmpq %rdx, %rax 0x817f9cc92 <+226>: je 0x19cc9e ; <+238> 0x817f9cc94 <+228>: jmp 0x19cd0c ; <+348> 0x817f9cc96 <+230>: andq %rcx, %rax 0x817f9cc99 <+233>: cmpq %rdx, %rax 0x817f9cc9c <+236>: jne 0x19cd0c ; <+348> 0x817f9cc9e <+238>: cmpq %rsi, 0x10(%rbx) 0x817f9cca2 <+242>: jne 0x19cd00 ; <+336> 0x817f9cca4 <+244>: cmpw %di, 0x18(%rbx) 0x817f9cca8 <+248>: jne 0x19cd00 ; <+336> 0x817f9ccaa <+250>: cmpw %r8w, 0x1a(%rbx) 0x817f9ccaf <+255>: jne 0x19cd00 ; <+336> 0x817f9ccb1 <+257>: cmpb %r9b, 0x1c(%rbx) 0x817f9ccb5 <+261>: jne 0x19cd00 ; <+336> 0x817f9ccb7 <+263>: cmpb %r10b, 0x1d(%rbx) 0x817f9ccbb <+267>: jne 0x19cd00 ; <+336> 0x817f9ccbd <+269>: cmpb %r11b, 0x1e(%rbx) 0x817f9ccc1 <+273>: jne 0x19cd00 ; <+336> 0x817f9ccc3 <+275>: movzbl -0x2c(%rbp), %eax 0x817f9ccc7 <+279>: cmpb %al, 0x1f(%rbx) 0x817f9ccca <+282>: jne 0x19cd00 ; <+336> 0x817f9cccc <+284>: movzbl -0x2b(%rbp), %eax 0x817f9ccd0 <+288>: cmpb %al, 0x20(%rbx) 0x817f9ccd3 <+291>: jne 0x19cd00 ; <+336> 0x817f9ccd5 <+293>: movzbl -0x2a(%rbp), %eax 0x817f9ccd9 <+297>: cmpb %al, 0x21(%rbx) 0x817f9ccdc <+300>: jne 0x19cd00 ; <+336> 0x817f9ccde <+302>: movzbl -0x29(%rbp), %eax 0x817f9cce2 <+306>: cmpb %al, 0x22(%rbx) 0x817f9cce5 <+309>: jne 0x19cd00 ; <+336> 0x817f9cce7 <+311>: cmpb %r14b, 0x23(%rbx) 0x817f9cceb <+315>: je 0x19ceb0 ; <+768> 0x817f9ccf1 <+321>: nopw %cs:(%rax,%rax) 0x817f9ccfb <+331>: nopl (%rax,%rax) 0x817f9cd00 <+336>: movq (%rbx), %rbx 0x817f9cd03 <+339>: testq %rbx, %rbx 0x817f9cd06 <+342>: jne 0x19cc70 ; <+192> 0x817f9cd0c <+348>: movl $0x30, %edi 0x817f9cd11 <+353>: callq 0x5604c ; symbol stub for: operator new(unsigned long) 0x817f9cd16 <+358>: movq %rax, %rbx 0x817f9cd19 <+361>: movq -0x48(%rbp), %rax 0x817f9cd1d <+365>: movups (%rax), %xmm0 0x817f9cd20 <+368>: movups 0x10(%rax), %xmm1 0x817f9cd24 <+372>: movups %xmm1, 0x20(%rbx) 0x817f9cd28 <+376>: movups %xmm0, 0x10(%rbx) 0x817f9cd2c <+380>: movq %r12, 0x8(%rbx) 0x817f9cd30 <+384>: movq $0x0, (%rbx) 0x817f9cd37 <+391>: movq 0x18(%r15), %rax 0x817f9cd3b <+395>: incq %rax 0x817f9cd3e <+398>: js 0x19cd4a ; <+410> 0x817f9cd40 <+400>: xorps %xmm0, %xmm0 0x817f9cd43 <+403>: cvtsi2ssq %rax, %xmm0 0x817f9cd48 <+408>: jmp 0x19cd62 ; <+434> 0x817f9cd4a <+410>: movq %rax, %rcx 0x817f9cd4d <+413>: shrq %rcx 0x817f9cd50 <+416>: andl $0x1, %eax 0x817f9cd53 <+419>: orq %rcx, %rax 0x817f9cd56 <+422>: xorps %xmm0, %xmm0 0x817f9cd59 <+425>: cvtsi2ssq %rax, %xmm0 0x817f9cd5e <+430>: addss %xmm0, %xmm0 0x817f9cd62 <+434>: movq %r13, %rcx 0x817f9cd65 <+437>: shrq %rcx 0x817f9cd68 <+440>: movl %r13d, %eax 0x817f9cd6b <+443>: andl $0x1, %eax 0x817f9cd6e <+446>: orq %rcx, %rax 0x817f9cd71 <+449>: testq %r13, %r13 0x817f9cd74 <+452>: movq -0x40(%rbp), %rcx 0x817f9cd78 <+456>: js 0x19cd89 ; <+473> 0x817f9cd7a <+458>: cvtsi2ssq %r13, %xmm2 0x817f9cd7f <+463>: movss 0x20(%r15), %xmm1 ; xmm1 = mem[0],zero,zero,zero 0x817f9cd85 <+469>: jne 0x19cd9a ; <+490> 0x817f9cd87 <+471>: jmp 0x19cdab ; <+507> 0x817f9cd89 <+473>: cvtsi2ssq %rax, %xmm2 0x817f9cd8e <+478>: addss %xmm2, %xmm2 0x817f9cd92 <+482>: movss 0x20(%r15), %xmm1 ; xmm1 = mem[0],zero,zero,zero 0x817f9cd98 <+488>: je 0x19cdab ; <+507> 0x817f9cd9a <+490>: mulss %xmm1, %xmm2 0x817f9cd9e <+494>: ucomiss %xmm2, %xmm0 0x817f9cda1 <+497>: ja 0x19cdab ; <+507> 0x817f9cda3 <+499>: movq %rcx, %r12 0x817f9cda6 <+502>: jmp 0x19ce32 ; <+642> 0x817f9cdab <+507>: leaq (%r13,%r13), %rcx 0x817f9cdb0 <+512>: movl $0x1, %eax 0x817f9cdb5 <+517>: cmpq $0x3, %r13 0x817f9cdb9 <+521>: jb 0x19cdc7 ; <+535> 0x817f9cdbb <+523>: leaq -0x1(%r13), %rdx 0x817f9cdbf <+527>: xorl %eax, %eax 0x817f9cdc1 <+529>: testq %r13, %rdx 0x817f9cdc4 <+532>: setne %al 0x817f9cdc7 <+535>: orq %rcx, %rax 0x817f9cdca <+538>: divss %xmm1, %xmm0 -> 0x817f9cdce <+542>: roundss $0xa, %xmm0, %xmm0 0x817f9cdd4 <+548>: movss 0x19e784(%rip), %xmm1 ; xmm1 = mem[0],zero,zero,zero 0x817f9cddc <+556>: movaps %xmm0, %xmm2 0x817f9cddf <+559>: subss %xmm1, %xmm2 0x817f9cde3 <+563>: cvttss2si %xmm2, %rcx 0x817f9cde8 <+568>: movabsq $-0x8000000000000000, %rdx ; imm = 0x8000000000000000 0x817f9cdf2 <+578>: xorq %rcx, %rdx 0x817f9cdf5 <+581>: cvttss2si %xmm0, %rsi 0x817f9cdfa <+586>: ucomiss %xmm1, %xmm0 0x817f9cdfd <+589>: cmovaeq %rdx, %rsi 0x817f9ce01 <+593>: cmpq %rsi, %rax 0x817f9ce04 <+596>: cmovaeq %rax, %rsi 0x817f9ce08 <+600>: movq %r15, %rdi 0x817f9ce0b <+603>: callq 0x19ced0 ; ___lldb_unnamed_symbol3841$$libmfxhw64.so.1 0x817f9ce10 <+608>: movq 0x8(%r15), %r13 0x817f9ce14 <+612>: leaq -0x1(%r13), %rax 0x817f9ce18 <+616>: testq %r13, %rax 0x817f9ce1b <+619>: je 0x19ce2f ; <+639> 0x817f9ce1d <+621>: cmpq %r13, %r12 0x817f9ce20 <+624>: jb 0x19ce32 ; <+642> 0x817f9ce22 <+626>: movq %r12, %rax 0x817f9ce25 <+629>: xorl %edx, %edx 0x817f9ce27 <+631>: divq %r13 0x817f9ce2a <+634>: movq %rdx, %r12 0x817f9ce2d <+637>: jmp 0x19ce32 ; <+642> 0x817f9ce2f <+639>: andq %rax, %r12 0x817f9ce32 <+642>: movq (%r15), %rcx 0x817f9ce35 <+645>: movq (%rcx,%r12,8), %rax 0x817f9ce39 <+649>: testq %rax, %rax 0x817f9ce3c <+652>: je 0x19ce4a ; <+666> 0x817f9ce3e <+654>: movq (%rax), %rcx 0x817f9ce41 <+657>: movq %rcx, (%rbx) 0x817f9ce44 <+660>: movq -0x38(%rbp), %rsi 0x817f9ce48 <+664>: jmp 0x19ce8f ; <+735> 0x817f9ce4a <+666>: leaq 0x10(%r15), %rax 0x817f9ce4e <+670>: movq 0x10(%r15), %rdx 0x817f9ce52 <+674>: movq %rdx, (%rbx) 0x817f9ce55 <+677>: movq %rbx, 0x10(%r15) 0x817f9ce59 <+681>: movq %rax, (%rcx,%r12,8) 0x817f9ce5d <+685>: movq (%rbx), %rax 0x817f9ce60 <+688>: testq %rax, %rax 0x817f9ce63 <+691>: movq -0x38(%rbp), %rsi 0x817f9ce67 <+695>: je 0x19ce92 ; <+738> 0x817f9ce69 <+697>: movq 0x8(%rax), %rax 0x817f9ce6d <+701>: leaq -0x1(%r13), %rcx 0x817f9ce71 <+705>: testq %r13, %rcx 0x817f9ce74 <+708>: je 0x19ce85 ; <+725> 0x817f9ce76 <+710>: cmpq %r13, %rax 0x817f9ce79 <+713>: jb 0x19ce88 ; <+728> 0x817f9ce7b <+715>: xorl %edx, %edx 0x817f9ce7d <+717>: divq %r13 0x817f9ce80 <+720>: movq %rdx, %rax 0x817f9ce83 <+723>: jmp 0x19ce88 ; <+728> 0x817f9ce85 <+725>: andq %rcx, %rax 0x817f9ce88 <+728>: shlq $0x3, %rax 0x817f9ce8c <+732>: addq (%r15), %rax 0x817f9ce8f <+735>: movq %rbx, (%rax) 0x817f9ce92 <+738>: incq 0x18(%r15) 0x817f9ce96 <+742>: movb $0x1, %al 0x817f9ce98 <+744>: movq %rbx, (%rsi) 0x817f9ce9b <+747>: movb %al, 0x8(%rsi) 0x817f9ce9e <+750>: movq %rsi, %rax 0x817f9cea1 <+753>: addq $0x28, %rsp 0x817f9cea5 <+757>: popq %rbx 0x817f9cea6 <+758>: popq %r12 0x817f9cea8 <+760>: popq %r13 0x817f9ceaa <+762>: popq %r14 0x817f9ceac <+764>: popq %r15 0x817f9ceae <+766>: popq %rbp 0x817f9ceaf <+767>: retq 0x817f9ceb0 <+768>: xorl %eax, %eax 0x817f9ceb2 <+770>: movq -0x38(%rbp), %rsi 0x817f9ceb6 <+774>: jmp 0x19ce98 ; <+744> 0x817f9ceb8 <+776>: movq %rax, %r14 0x817f9cebb <+779>: movq %rbx, %rdi 0x817f9cebe <+782>: callq 0x5610c ; symbol stub for: operator delete(void*) 0x817f9cec3 <+787>: movq %r14, %rdi 0x817f9cec6 <+790>: callq 0x565ac ; symbol stub for: _Unwind_Resume 0x817f9cecb <+795>: int3 0x817f9cecc <+796>: int3 0x817f9cecd <+797>: int3 0x817f9cece <+798>: int3 0x817f9cecf <+799>: int3
(In reply to bitbucket63-it from comment #20) > -> 0x817f9cdce <+542>: roundss $0xa, %xmm0, %xmm0 Looks like a SSE4.1 instruction. After comment 14 it shouldn't show up anymore. $ objdump -D /usr/local/lib/libmfxhw64.so.1 | fgrep roundss $ Can you show full build log?
(In reply to Jan Beich from comment #21) I did a portsnap and rebuilt multimedia/intel-media-sdk and HandBrake ran without error after that. The build log for multimedia/intel-media-sdk can be found here. https://www.dropbox.com/s/v62p3y6oxwu922e/intel-media-sdk-build.log?dl=0