build(deps): bump third-party/build-deps from 814fa85 to 10366be

[dependabot]

Bumps third-party/build-deps from 814fa85 to 10366be.

Commits

• 10366be feat(FFmpeg): compile libva dependency (#590)
• 547d228 fix(ffmpeg): Add upstreamed MF low latency encoding patch (#587)
• 1d60a89 build(deps): bump third-party/FFmpeg/FFmpeg from e360467 to ec78e95 (#586)
• a66c5bc build(deps): bump vmactions/freebsd-vm from 1.3.3 to 1.3.4 (#584)
• d0cd4f5 build(deps): bump vmactions/freebsd-vm from 1.3.2 to 1.3.3 (#583)
• 4e0d6da build(deps): bump vmactions/freebsd-vm from 1.3.0 to 1.3.2 (#582)
• See full diff in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[codecov]

Bundle Report

Bundle size has no change ✅

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 15.32%. Comparing base (c9e0bb8) to head (48cf74f).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4563      +/-   ##
==========================================
- Coverage   15.38%   15.32%   -0.07%     
==========================================
  Files          92       92              
  Lines       18993    18993              
  Branches     8769     8769              
==========================================
- Hits         2923     2911      -12     
+ Misses      14938    12748    -2190     
- Partials     1132     3334    +2202     

Flag	Coverage Δ
Archlinux	11.54% <ø> (ø)
FreeBSD-14.3-aarch64	?
FreeBSD-14.3-amd64	13.65% <ø> (ø)
Homebrew-ubuntu-22.04	13.83% <ø> (ø)
Linux-AppImage	11.64% <ø> (ø)
Windows-AMD64	13.41% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 46 files with indirect coverage changes

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[cgutman]

@ReenigneArcher I think we may need to change our build-deps code to just use the compiled libva for the FFmpeg build without actually publishing the libs and headers into the final dist commit.

The build is failing here because the platform's libva version lacks the vaMapBuffers2() function that libva 2.21+ has. That would normally be fine because we can simply define it ourselves like this. Unfortunately, that doesn't work for us because the newer libva headers from the build-deps are getting picked up in place of the platform's libva headers, so !VA_CHECK_VERSION(1, 21, 0) is false even if the actual libva version on the system is lower than that.

Trying to make the library match the headers by linking to the built libva.a from build-deps introduces different issues. Since libva includes a hardcoded default libva driver search path, this yields a build that compiles but fails at runtime because it can't find the libva driver (and we can't hardcode it "properly" ourselves either because distros vary on the correct location for their VA drivers)

libva info: VA-API version 1.23.0
libva info: Trying to open /home/runner/work/build-deps/build-deps/build/libva/lib/dri/iHD_drv_video.so
libva info: va_openDriver() returns -1
[2026-01-06 22:05:32.658]: Error: Couldn't initialize va display: unknown libva error

If we don't expose the newer headers or libs from the libva build in build-deps and just link to what the platform has, I think we should be okay on the versions of libva for the distros we support (anything within ~4 years). Going back further than that will break though, since whole swaths of functionality like AV1 will be missing and we can't fake that with a little helper function like we can for vaMapBuffers2().

[ReenigneArcher]

@cgutman that makes sense.

Is it even worth compiling libva in build-deps then, or should we just install it? Homebrew has version 2.23. https://formulae.brew.sh/formula/libva ... though I guess it doesn't matter much. I don't think it adds much time to the total compilation.