Bug 242849 - multimedia/handbrake: enable Intel Quick Sync Video
Summary: multimedia/handbrake: enable Intel Quick Sync Video
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2019-12-24 05:43 UTC by Jan Beich
Modified: 2020-06-18 03:17 UTC (History)
3 users (show)

See Also:
naito.yuichiro: maintainer-feedback+


Attachments
v1 (13.17 KB, patch)
2019-12-24 05:43 UTC, Jan Beich
no flags Details | Diff
v1.1 (13.08 KB, patch)
2019-12-24 05:57 UTC, Jan Beich
no flags Details | Diff
future (13.57 KB, patch)
2020-01-03 18:51 UTC, Jan Beich
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer 2019-12-24 05:43:10 UTC
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.
Comment 1 Jan Beich freebsd_committer 2019-12-24 05:57:47 UTC
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.
Comment 2 Yuichiro NAITO 2019-12-24 08:21:25 UTC
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.
Comment 3 Jan Beich freebsd_committer 2019-12-28 19:34:11 UTC
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.
Comment 4 Yuichiro NAITO 2020-01-02 15:18:59 UTC
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.
Comment 5 Jan Beich freebsd_committer 2020-01-02 17:06:58 UTC
(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.
Comment 6 Piotr Kubaj freebsd_committer 2020-01-02 21:36:29 UTC
(In reply to Yuichiro NAITO from comment #4)
Looks ok on both 12.1 and CURRENT.
Comment 7 Yuichiro NAITO 2020-01-03 08:43:46 UTC
(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!
Comment 8 commit-hook freebsd_committer 2020-01-03 09:02:03 UTC
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
Comment 9 commit-hook freebsd_committer 2020-01-03 18:45:52 UTC
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
Comment 10 Jan Beich freebsd_committer 2020-01-03 18:51:18 UTC
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.
Comment 11 Yuichiro NAITO 2020-01-04 22:43:42 UTC
(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.
Comment 12 bitbucket63-it 2020-05-25 19:37:26 UTC
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)
Comment 13 Yuichiro NAITO 2020-05-26 03:07:28 UTC
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
Comment 14 commit-hook freebsd_committer 2020-05-26 04:12:56 UTC
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
Comment 15 commit-hook freebsd_committer 2020-05-26 04:12:58 UTC
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
Comment 16 Jan Beich freebsd_committer 2020-05-26 04:17:28 UTC
(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
Comment 17 bitbucket63-it 2020-05-26 14:54:19 UTC
(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.
Comment 18 bitbucket63-it 2020-05-27 05:17:31 UTC
(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.
Comment 19 Yuichiro NAITO 2020-05-29 08:52:00 UTC
(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.
Comment 20 bitbucket63-it 2020-06-04 03:37:39 UTC
(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
Comment 21 Jan Beich freebsd_committer 2020-06-04 14:56:25 UTC
(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?
Comment 22 bitbucket63-it 2020-06-08 04:11:52 UTC
(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