Watching Spotify and listening to Netflix in 2023

As a few people already noticed, www/chromium has been recently patched to enable Widevine support. (It's debatable whether that's a good or bad thing, but the demand is certainly there.)

This is done with the help of www/foreign-cdm, which is a relatively straightforward proxy for the Content Decryption Module API. The port provides a native FreeBSD CDM implementation (a shared library) that in background transparently launches one or more Linux processes loading Widevine. They communicate through a pair of Unix sockets.

Widevine itself is available through www/linux-widevine-cdm.

So, what does that actually mean? Enabling DRM playback should now be as easy as (assuming the latest repo):
Code:
% sudo pkg install chromium # 117.0.5938.149_2 or higher

% sudo pkg install foreign-cdm
% sudo sysrc linux_enable="YES"
% sudo service linux start

% git clone --depth 1 https://github.com/freebsd/freebsd-ports
% cd freebsd-ports/www/linux-widevine-cdm
% make
% sudo make install

Use the demo at https://bitmovin.com/demos/drm or https://reference.dashif.org/dash.js/latest/samples/drm/widevine.html to test the playback. (This might require a few attempts + browser restart.)

There are, of course, some limitations:
  1. we are permanently restricted to the Widevine L3 protection level, just like Linux;
  2. there is no sandboxing yet;
  3. I'll eventually get to disabling debug logging as well as fixing a few minor memory leaks, but for the time being they remain there for everyone to enjoy.
 
Last edited:
Apparently Chromium failed to build for FreeBSD:14:amd64 (latest) the second time in the row. Well, tough luck then.
 
I just saw that www/ungoogled-chromium also got the build option "WIDEVINE" with the latest commit (version 118.0.5993.88).
Note that nothing there really depends on that option being set. That is, the corresponding patches are always applied, while the option simply changes the package dependencies. I'm still not sure what's the point.
 
Note that nothing there really depends on that option being set. That is, the corresponding patches are always applied, while the option simply changes the package dependencies. I'm still not sure what's the point.
You'll find that pattern all over the ports tree, it's more or less a way to document an optional runtime dependency. Other package managers like e.g. Debian's apt/dpkg have a concept of recommended/suggested "dependencies" for such cases, FreeBSD's pkg doesn't know that (so far?), so it's more or less the only thing a port maintainer can do. OTOH, when the option has a good description, it's more informative than e.g. a "Suggests" in some Debian package, where you won't learn what that optional dependency would enable...
 
Can somebody confirm That they got this to work? I had an issue the other day that i had to reinstall. i got to the last part

Code:
% git clone --depth 1 https://github.com/freebsd/freebsd-ports
% cd freebsd-ports/www/linux-widevine-cdm
% make
% sudo make install

it failed so then i did a make deinstall but i used BATCH=1 and it removed all my modules on my system so I'm kinda iffy on it. i really would like to listen to my spotify music
 
it failed so then i did a make deinstall but i used BATCH=1 and it removed all my modules on my system so I'm kinda iffy on it.
I'm not aware of any conditions where make deinstall in www/linux-widevine-cdm would remove any other packages.
 
Has anyone got Spotify to work with this?
For me it all installs fine, and the pages (the 2 "test" links as well as Spotify) load and confirm Widevine support.
Anyhow Spotify cannot play music and also the 2 test videos load forever but never play.
 
I did get have issue after moving from 13.2 to 14.0, after reinstalling www/linux-widevine-cdm I was able to use primevideo and amazon music.
The issue that I had previously was that the jail didn't started, when you go to spotify, does jls show some jail created ?
Also if there is an issue to play the video once, some mount will stay and prevent fcdm to work again (you will have to kill fcdm-jail, and I guess remove the lock files to be sure).
 
For example, when I try to view a video on crunchyroll while having ads blocked with dns, it will failed and the jail seems to not be created.
If I try to watch on a previously working one like prime video it no longer works.
So I have to at least remove the fcdm.lock file in order to have widevine working again.
Now, if I ensure that the ads can be played (and that I am logged in), it play the video just fine.

Long story short, if the website decide to not play the video, fcdm-jail seems to wait forever (In the log there is just the message about fcdm-jail started at pid and then nothing else).
 
For example, when I try to view a video on crunchyroll while having ads blocked with dns, it will failed and the jail seems to not be created.
If I try to watch on a previously working one like prime video it no longer works.
FCDM doesn't maintain a single jail, it's spawns each worker in its own jail (reusing the same root directory — we use read-only nullfs/tmpfs mounts, so that's fine). That means the jail only starts once a page calls Encrypted Media Extensions API. I also spawn separate workers for CreateCdmInstance/GetCdmVersion calls.

So I have to at least remove the fcdm.lock file in order to have widevine working again.
The file is simply a way to address a mutex maintained in kernel, removing it is unnecessary.

Now, if I ensure that the ads can be played (and that I am logged in), it play the video just fine.

Long story short, if the website decide to not play the video, fcdm-jail seems to wait forever (In the log there is just the message about fcdm-jail started at pid and then nothing else).
I doubt this has anything to do with jails.
 
It just gives messages like this:
Code:
lib.cpp:620: info: GetCdmVersion
lib.cpp:562: info: started process; pid = 3236
But nothing happens when I click "play".
Run /usr/local/libexec/fcdm-jail directly. Does it give you a shell?
 
Run /usr/local/libexec/fcdm-jail directly. Does it give you a shell?
As user the command hangs forever. As root though, I get a shell.
Since chrome is running under the normal user, maybe a permission issue?

P.S.: I am not using X but Wayland in case this makes any difference.
 
Back
Top