Raspberry-Pi-OS-64bit
Raspberry-Pi-OS-64bit copied to clipboard
raspberrypi
Widevine Doesn't Seem to Work
After installing 64-Bit Raspberry Pi OS, and then installing Widevine, I've noticed that Widevine doesn't show up in the Chromium browser.
After a fresh install of 64-Bit Raspberry Pi OS, I did the following, in order to install Widevine:
sudo apt update
sudo apt full-upgrade
sudo apt install libwidevinecdm0
After running these commands, Widevine doesn't show up as being installed in Chromium. If I open the Chromium web browser, and type chrome://components, Widevine isn't listed.
According to the following article:
https://pimylifeup.com/raspberry-pi-widevine/comment-page-1/#comment-62789
and also according to a video, which I watched on YouTube, it's supposed to be as easy as simply running the above three commands in order to install Widevine. Has something changed, or are these sources simply wrong about how to install Widevine?
Thanks for your time and attention.
See also https://github.com/raspberrypi/Raspberry-Pi-OS-64bit/search?q=widevine&type=issues
Thanks for the link, @lurch. The craziest thing is that I actually had this working, less than a week ago. I installed the 64-bit Raspberry Pi OS, and tried playing an amazon video. It worked, but I was watching it via VNC, and the video was a bit choppy. I overwrote the SD card, not thinking that it'd be difficult to set it up again. However, now, after reinstalling the 64-bit Raspberry Pi OS, it just doesn't work.
Unfortunately, I have no way of showing what I did, the first time. All I know is that it was working. I was watching the beginning of "Invincible" on Amazon Prime, on my Raspberry Pi 4, via a VNC connection. I really wish I had backed up that SD card before writing over its contents.
VNC. I have, both, a Raspberry Pi 4 and a Raspberry Pi 3. I currently don't have my HDMI cable for my Raspberry Pi 4. So I installed 64-Bit Raspberry Pi OS on my Raspberry Pi 3, and then noticed that it was extremely slow. So I popped the SD card into my Raspberry Pi 4, and used tightVNCserver to view it via my laptop. That's when I was able to see it working. I've tried to do this again, to no avail. I may try it again, because it was working.
I don't think VNC has anything to do with widevine, either. I was just explaining the specific means, by which, it ended up working.
The craziest thing is that I actually had this working, less than a week ago.
If you can reproduce that, then I can take a look. To the best of my knowledge, that's no possible without having a 32-bit version of chromium installed (which is a solution we may go with).
I don't know what I did, but I know it's possible because it was actually working. Maybe it was running on a 32-bit version of chromium. I don't know. I just know that I was using it to watch "Invincible" on Amazon Prime, back then. This was after Google stopped supporting 32-bit Widevine.
I truly wish I had backed up that SD card, since I haven't been able to get it to work again. I still kick myself over this.
I just got Netflix to work on my Raspberry Pi 4. I'm using the 32-bit version of the Raspberry Pi OS.
I'm beginning to think that I popped in an SD card that already had the 32-bit version of the Raspberry Pi OS, and noticed that it could play videos in Amazon Prime.
Once Google dropped Widevine support for 32-bit machines, I figured I'd see if it worked on the Raspberry Pi 4, which uses 64-bit hardware. So I probably popped in the first SD card which already had the Raspberry Pi OS on it, and noticed that it worked.
I'm glad that this works. I don't really care that it's 32-bit, as long as it works.
So, from what I can tell, Widevine doesn't care whether or not your operating system is 64-bit. It only cares that your hardware is 64-bit. That's the way it seems, anyway, since I can't get any streaming platforms, other than YouTube, to work on my laptop; which has 32-bit hardware.
On arm, there only exists a 32-bit version of the widevine library. There does not exist a 64-bit version. Therefore you can only use widevine on Raspberry Pi OS 32-bit. There is no solution for widevine on Raspberry Pi OS 64-bit.
The processor in Pi3 and Pi4 (and newer versions of Pi2) can boot in either 32-bit or 64-bit mode. Use RpiOS 32-bit if widevine is important to you.
If you believe you had widevine working on Pi4 in the past, I'm sure you were using a 32-bit image of RpiOS.
I see it's a quite old issue, but I've managed to find a workaround just recently.
It's true that libwidevinecdm0 seems to be provided only in 32-bit version and does not work with 64-bit chromium.
If you still want to watch widevine protected stuff while keeping 64-bit os it's possible to use dpkg multiarch functionality to install 32-bit version of the browser only:
~~sudo dpkg --add-architecture armhf <- this will add 32-bit arm architecture
sudo apt update~~
sudo apt install chromium-browser:armhf <- this will remove chromium-browser and install its 32-bit version along with dependencies
I can confirm it works flawlessly now with recent RpiOS-64 (tested with Netflix and HBO)
EDIT: It seems I've reinvented the wheel :) https://www.raspberrypi.com/news/raspberry-pi-os-64-bit/
We developers at Pi-Apps are watching the Widevine space closely to see if Google plans to enable Widevine in its 64-bit ChromeOS userspace. This commit to the Chromium source code was made in March, so they appear to be heading that way internally.
Thanks, if you notice them publish an image with the new arm64 library do respond here and we'll look into integrating it...
I done the same thing but Spotify is not playing even then but it shows 32 bit chromium
widevine only supports 32-bit arm. widevine works on RPiOS 32 chromium by default.
On 64-bit RPiOS you can install 32-bit chromium and widevine and it will work. See this blog post
A 64bit widevine build has just been added and chromium-browser updated accordingly.
libgcc_hide.so is created from this script:
#!/bin/bash
OLD_ARCHIVE=${OLD_ARCHIVE:-/lib/gcc/aarch64-linux-gnu/10/libgcc.a}
NEW_ARCHIVE=${NEW_ARCHIVE:-libgcc_hide.a}
NEW_ARCHIVE_SO=${NEW_ARCHIVE_SO:-libgcc_hide.so}
OBJS="ldadd_4_4.o swp_4_4.o"
for i in $OBJS; do
ar xv /lib/gcc/aarch64-linux-gnu/10/libgcc.a $i
unhide.py $i
done
ar rcs $NEW_ARCHIVE $OBJS
rm $OBJS
gcc -o $NEW_ARCHIVE_SO -shared -Wl,--whole-archive $NEW_ARCHIVE -Wl,--no-whole-archive
using unhide.py from here
You could also compile it yourself using the code here: https://github.com/xbmc/inputstream.adaptive/pull/1130/files#diff-cb49b4f5a6e2a38d51a696be771430404f8a6c7f7012b92d5d27da461825f790R1674
__attribute__((target("no-outline-atomics")))
int32_t __aarch64_ldadd4_acq_rel(int32_t value, int32_t *ptr)
{
return __atomic_fetch_add(ptr, value, __ATOMIC_ACQ_REL);
}
__attribute__((target("no-outline-atomics")))
int32_t __aarch64_swp4_acq_rel(int32_t value, int32_t *ptr)
{
return __atomic_exchange_n(ptr, value, __ATOMIC_ACQ_REL);
}
maybe someone in this thread can be of assistance
how could the widevine lib be patched to not require fcntl64 which was added in glibc 2.28 and is not available on ubuntu bionic?
You could also compile it yourself using the code here: https://github.com/xbmc/inputstream.adaptive/pull/1130/files#diff-cb49b4f5a6e2a38d51a696be771430404f8a6c7f7012b92d5d27da461825f790R1674
__attribute__((target("no-outline-atomics"))) int32_t __aarch64_ldadd4_acq_rel(int32_t value, int32_t *ptr) { return __atomic_fetch_add(ptr, value, __ATOMIC_ACQ_REL); } __attribute__((target("no-outline-atomics"))) int32_t __aarch64_swp4_acq_rel(int32_t value, int32_t *ptr) { return __atomic_exchange_n(ptr, value, __ATOMIC_ACQ_REL); }
I've just tried this approach and it also works. I'll switch to it, since it makes GPL compliance simpler.
I am not sure which user is Serge Schneider [email protected] as the debian maintainer of the glibc package.
I am attempting to modify the glibc 2.31 patchs for glibc 2.27 (bionic) so that I can use widevine. I have modified them, then apply, and the deb builds successfully but I get this error when running chromium or with ldd on the widevine binary.
Inconsistency detected by ld.so: get-dynamic-info.h: 143: elf_get_dynamic_info: Assertion `info[DT_RELRENT]->d_un.d_val == sizeof (ElfW(Relr))' failed!
the patches themselves that were added to ubuntu bionic glibc are here: glibc-2.27-patches.zip
hid my preview comment (the patch had a mistake)
was able to get widevine working on L4T Ubuntu Bionic as well as L4T Fedora 37
chromium-browser patch https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2008433/+attachment/5649663/+files/widevine-enable-all-architectures.patch
GLIBC PATCHES GLIBC 2.36+: https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/devel/glibc/patches/arm/glibc-HACK-Don-t-check-GLIBC_ABI_DT_RELR-support-for-Chrom.patch https://cdn.discordapp.com/attachments/567232809475768320/1078517350137090098/glibc-tls-libwidevinecdm.so-since-4.10.2252.0-has-TLS-with.patch
GLIBC 2.27: https://cdn.discordapp.com/attachments/567232809475768320/1078517349776359485/glibc-2.27-sht_relr_new.diff https://cdn.discordapp.com/attachments/567232809475768320/1078517350137090098/glibc-tls-libwidevinecdm.so-since-4.10.2252.0-has-TLS-with.patch
LD_PRELOAD the following symbols/functions for widevine GLIBC 2.27:
#include <fcntl.h>
#include <stdarg.h>
#include <stdint.h>
int fcntl64(int fd, int cmd, void*arg) {
return (fcntl(fd, cmd, arg));
}
__attribute__((target("no-outline-atomics")))
int32_t __aarch64_ldadd4_acq_rel(int32_t value, int32_t *ptr)
{
return __atomic_fetch_add(ptr, value, __ATOMIC_ACQ_REL);
}
__attribute__((target("no-outline-atomics")))
int32_t __aarch64_swp4_acq_rel(int32_t value, int32_t *ptr)
{
return __atomic_exchange_n(ptr, value, __ATOMIC_ACQ_REL);
}
GLIBC 2.28+
#include <stdarg.h>
#include <stdint.h>
__attribute__((target("no-outline-atomics")))
int32_t __aarch64_ldadd4_acq_rel(int32_t value, int32_t *ptr)
{
return __atomic_fetch_add(ptr, value, __ATOMIC_ACQ_REL);
}
__attribute__((target("no-outline-atomics")))
int32_t __aarch64_swp4_acq_rel(int32_t value, int32_t *ptr)
{
return __atomic_exchange_n(ptr, value, __ATOMIC_ACQ_REL);
}
WIDEVINE BINARY PATCHING (GLIBC 2.27 and 2.28) Mark the required missing symbols as WEAK by patching the widevine binary (fcntl64 if missing is provided above in the preload, other symbols will fall back to older versions available in system glibc) follow this guide: https://www.lightofdawn.org/wiki/wiki.cgi/NewAppsOnOldGlibc
@XECDesign just to be clear, there is now a new build of chrome on 64bit rpi os with patches needed for arm64 bit widevine cdm? And I suspect rpi are now hosting the 64bit widevine cdm as well now?
Oh. Found this that tells me yes to above https://forums.raspberrypi.com/viewtopic.php?t=347736
