5 ms·
Yes fair point, that's the only thing happening client side. But somebody else mentioned that widevine on chrome os and chrome are different. So I wouldn't hav
by floo 9y ago
Yes fair point, that's the only thing happening client side.
But somebody else mentioned that widevine on chrome os and chrome are different. So I wouldn't have expected their servers to accept those 1080p requests for chrome's version.
Edit: says so on Github:
ChromeOS apparently has a different DRM implementation than chrome, even though both use Widevine.
- tbranyen 9y agoThere are two different things going on here. One is detecting Chrome OS and the other is determining the set of stream profiles. If you were to change your useragent to get Chrome OS, like the GitHub says, this would alter code paths in other areas related to DRM. However the fix that was found was simply pushing the stream profile into the array. This doesn't affect DRM at all. The fix from the Netflix side would be to find a suitable alternative to user agent sniffing for h/w accel and swap that in to this code path.
- floo 9y agoI did read it :) What I am saying is: If they are blocking everything but chrome os intentionally, it would have been easier. According to widevine docs [1] chrome on desktops does not support security level 1. They could have and probably did block access to 1080p content on level 3. Which leads me to believe that netflix relaxed security to allow 1080p on level 3. As you said the next step would be to replace the user agent detection client side. [1] https://storage.googleapis.com/wvdocs/Widevine_DRM_Architecture_Overview.pdf