[EME] Key system is unsupported when cross-compiling from Linux to Windows.
Categories
(Core :: Audio/Video: Playback, defect, P3)
Tracking
()
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.
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
Is there a specific page you're using to test? Could you provide the mozconfig you're using to build?
Reporter | ||
Comment 2•4 years ago
|
||
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.
Comment 3•4 years ago
|
||
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.
Assignee | ||
Comment 4•4 years ago
|
||
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.
Reporter | ||
Comment 5•3 years ago
|
||
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
Description
•