Closed Bug 1684440 Opened 4 years ago Closed 3 years ago

[EME] Key system is unsupported when cross-compiling from Linux to Windows.

Categories

(Core :: Audio/Video: Playback, defect, P3)

78 Branch
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: alexboy94, Assigned: bryce)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 11.1; rv:78.0) Gecko/20100101 Firefox/78.0 Waterfox/78.6.0

Steps to reproduce:

Cross compiling Firefox 78 ESR from Linux to Windows, when running the build on Windows does not allow DRM playback due to errors.

Actual results:

DRM does not work, with the following complaints on websites that use DRM:

MediaKeySystemAccess::GetKeySystemStatus(com.widevine.alpha) result=available msg=''
navigator.requestMediaKeySystemAccess promise rejected 0x80530009 'Key system configuration is not supported'
navigator.requestMediaKeySystemAccess promise rejected 0x80530009 'Key system is unsupported'
MediaKeySystemAccess::GetKeySystemStatus(org.w3.clearkey) result=available msg=''
navigator.requestMediaKeySystemAccess promise rejected 0x80530009 'Key system configuration is not supported'

Expected results:

Widevine should load and run.

Flags: needinfo?(bvandyk)

Is there a specific page you're using to test? Could you provide the mozconfig you're using to build?

Assignee: nobody → bvandyk
Severity: -- → S3
Flags: needinfo?(bvandyk) → needinfo?(alexboy94)
Priority: -- → P3

Hi Bryce,

I've tried with: Bitmovin DRM Test

It works when compiling with clang-cl/VS2017 on Windows 10, any .mozconfig seems to work.

When compiling with clang-cl/VS2017 on Linux, withVS2017 and WinSDK mounted on a VFAT partition, the above error is emitted. Everything else works perfectly.

ac_add_options --target=x86_64-pc-mingw32
ac_add_options --disable-maintenance-service
TOOLTOOL_DIR=$HOME/tooltool11
CROSS_BUILD=1

mk_add_options "export LD_PRELOAD=/home/akontos/tooltool11/liblowercase/liblowercase.so"
mk_add_options "export LOWERCASE_DIRS=/mnt"

export WINDOWSSDKDIR="/mnt/WINDOW~1/10/"
export DIA_SDK_PATH="/mnt/MICROS~1/2017/Community/DIASDK~1/"

EXTRA_PATH="/mnt/MICROS~1/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64:"

# export MIDL="widl"
# export MIDL_FLAGS="-I /usr/lib/x86_64-linux-gnu/wine/fakedlls"

#export MIDL="/home/akontos/tooltool11/wine/bin/widl"
#export MIDL_FLAGS="-I/usr/lib/x86_64-linux-gnu/wine/fakedlls -I/usr/include/wine/wine/windows"

FXC=${TOOLTOOL_DIR}/fxc2/bin/fxc2.exe

mk_add_options "export PATH=${TOOLTOOL_DIR}/wine/bin:{TOOLTOOL_DIR}/fxc2/bin:/mnt/LLVM/bin:/home/akontos/tooltool11/mingw-w64-clang/bin:$EXTRA_PATH$PATH"

export CC="/home/akontos/tooltool11/mingw-w64-clang/bin/clang-cl"
export CXX="/home/akontos/tooltool11/mingw-w64-clang/bin/clang-cl"
export HOST_CC="/home/akontos/tooltool11/mingw-w64-clang/bin/clang"
export HOST_CXX="/home/akontos/tooltool11/mingw-w64-clang/bin/clang++"

I based this on glandium's post in regards to cross-compiling on Linux using clang-cl and moving over the VS install to a VFAT partition: Standing up the Cross-Compilation of Firefox for Windows on Linux

I'd expect it to work since we're using the correct headers (not mingw) directly from the source and even using wine for various tools like MT etc. Also looks like Firefox release builds are now built like this?

Not sure if related, but if building with clang/mingw on Linux, DRM doesn't work on Windows with the same error message as above, but I'd expect that since I can't imagine there's the logic for EME to work with that combo.

Flags: needinfo?(alexboy94) → needinfo?(bvandyk)

I doubt that has anything to do with cross-compilation. Local Windows builds likely have the same problem. The CDM will only work if Firefox is signed, and the build system doesn't sign it for you. Worse, even if you were able to sign it, I think it only works if it's signed with the Firefox key, which is private for obvious reasons.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID

I think there's merit to investigating further. While there is a signing element, unsigned builds should work for the bitmovin drm test -- the website can see the signing state and decide to serve video or not (or to serve lower quality video). In the case of the bitmovin test I don't think they change behaviour (I don't see a change when testing now).

On the video side we can try and figure out which part of the pipeline is busted. If you could set the env vars MOZ_LOG=sync,timestamp,EME:5,GMP:5 and MOZ_LOG_FILE to a path to dump the logs to, then zip and upload the log files that appear (there should be a number of them) to this bug, that would help me figure out what's going for the video side.

Status: RESOLVED → REOPENED
Ever confirmed: true
Flags: needinfo?(bvandyk)
Resolution: INVALID → ---

Hi bryce - apologies for not reporting back. For some odd reason, DRM started working again and I forgot to report back here.

On a related note though, cross-compiling from Linux -> Windows with mingw-w64 (such as Tor does) definitely doesn't work: https://bugzilla.mozilla.org/show_bug.cgi?id=1724682

Status: REOPENED → RESOLVED
Closed: 4 years ago3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.