4 ms·

So they are serving lower resolutions to ARM devices with no GPU acceleration. Doesn't sound like deliberately crippling Asahi Macs to me.. more like a reasonab

So they are serving lower resolutions to ARM devices with no GPU acceleration. Doesn't sound like deliberately crippling Asahi Macs to me.. more like a reasonable default assuming those devices are something like a raspberry pi. I'm assuming it is just a default and you can select whatever resolution you like. Detecting if the device has 20 cores or whatever like he says if possible would be more invasive of privacy. They would be criticized for that too. There's just no winning lol

watermelon0 3y ago
Have to agree with this. Not saying the check should be there, but the majority of non-mobile/server ARM devices are generally underpowered, especially with per-core performance.
matheusmoreira 3y ago
That sounds reasonable but it's weird that Chrome lies by pretending to be x86_64. The same performance concerns that apply to Firefox should apply to it.
borissk 3y ago
Hmmm, serving low resolution videos to ARM devices running Linux also makes harder for a competitor to build an alternative to Android.
- deleted 3y ago
  [deleted]
- James-Livesey 3y ago
  True, but any competing operating system could just falsely report that it is running x86-64 and therefore trick YouTube into serving high-res content. Disclosure: currently (as a personal project) slowly building an alternative to Android
  - DeathArrow 3y ago
    Can you share it?
deleted 3y ago
[deleted]
gefriertrockner 3y ago
At the same time Chromium is not affected: > Why does this not affect Chromium? Because chromium on aarch64 pretends to be x86_64
OJFord 3y ago
Could it not tell if it's actually managing to play and keep up with time? Similarly to how (I believe) it'll degrade if the network is such that it's not loading 4k say quickly enough, it'll switch (if 'auto') to 1080p or whatever. > Detecting if the device has 20 cores or whatever like he says if possible would be more invasive of privacy. What he claims though is that they do already do that at least if it's not aarch64: > Quality 1080 by default. If your machine has 2 or fewer cores, quality 480. If anything ARM, quality 240.
- piaste 3y ago
  > Could it not tell if it's actually managing to play and keep up with time? Similarly to how (I believe) it'll degrade if the network is such that it's not loading 4k say quickly enough, it'll switch (if 'auto') to 1080p or whatever. Probably, but it's pretty poor UX if videos start super-choppy by default and slowly downscale to a playable resolution over several seconds. Having a good default is still important.
  - rjsw 3y ago
    The test can be during the advert before the video that you want to watch.
  - OJFord 3y ago
    Worse than stuttering if it's the network? Anyway, it could go up.
wasmitnetzen 3y ago
They already check the core count via the hardwareConcurrency API[1], check the second screenshot. [1]: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/hardwareConcurrency https://developer.mozilla.org/en-US/docs/Web/API/Navigator/h...
arp242 3y ago
Figuring out good defaults for this is really hard. In general, "Linux + aarch64 = lower performance = let's do lower resolution by default" seems like a reasonable thing, although not fool-proof obviously. Also note that the "is_arm()" is followed by "|| is_android()"-bit in his screenshot. Asahi Linux is a comparatively small project with few real users. It's pretty arrogant to assume Google is intentionally targetting them specifically. If anything, the bug here is that Chromium uses x86 on arm systems, although for Asahi specifically that's probably the right choice, it's a lot less clear to me that's the right choice for all systems.
- izacus 3y ago
  And the primary targets for that are probably ARM Chromebooks which tend to be underpowered by quite a bit. (I'm guessing those report aarch64 correctly.)
  - rany_ 3y ago
    Well, that and also when you set "Desktop site" in mobile Chromium it will report a user-agent which matches that of desktop Linux on ARM. So it is most likely trying to target those devices as well.
- gjsman-1000 3y ago
  > It's pretty arrogant to assume Google is intentionally targetting them specifically. The Asahi Linux developers have a history of taking everything personally. If Apple adds a new way to start an ELF in macOS 12.3, it's because of them. If someone criticizes them publicly on Hacker News and isn't immediately shamed, it's because the actual leadership at Hacker News hates them (not an exaggeration considering their public stunt here where they blamed @dang for everything). If someone doesn't quite agree with their politics in perfect lockstep, they will publicly try to force you to resign (look at what happened with Dlang). And, more recently, threatening to keep changes downstream and out of the mainline Linux kernel as retaliation for what they call inappropriate conduct (which, well, if the COC of Linux hasn't been violated, I'm guessing it's probably them). And of course, if it's found out that the M2 has a technical bug with audio processing that literally nobody noticed until now, it's proof that Apple is full of incompetent idiots, unlike them. It's also why, if I were running a corporation, I would almost require that anyone using Asahi on their Mac use a corporate fork for their own protection. I wouldn't rule out retaliation.
drakythe 3y ago
You are assuming incorrectly. The bug report linked in the thread the user filed with Mozilla indicates that 4K resolution isn’t available even though once he changes the user agent string it was and it worked without issue.
Garvi 3y ago
[flagged]
- matheusmoreira 3y ago
  Gotta be fair about it. There's plenty of reasons to hate Google but this doesn't seem like one of them.
- zaptheimpaler 3y ago
  Yes I prefer to find the actual facts in a situation and pick sides (if at all) in that situation based on those facts not a predetermined "corporation bad, billionaire bad". Criticism loses all meaning if not based on fact and actually hurts the cause because then even meaningful criticism can be dismissed as baseless.
sambull 3y ago
they keep serving me 380p by default that I have to change and I've got a gigabit fiber with a modern ryzen and a monster gpu running the latest windows. So whatever they are doing auto quality wise has some screws loose.
padenot 3y ago
If you want to know the media decoding capabilities of a Web Browser, you can use the MediaCapabilities API. In Firefox, when flipping the "resist fingerprinting" flag, it's spoofed appropriately based on a study of what the most common results are. This is available on all engines, desktop and mobile. Depending on the implementation, what it returns can be based on the presence of optimized software decoders for a platform, presence of hardware, resolution and other characteristics of the video, it can also be based on a decoding benchmark that the web browser runs, etc. https://w3c.github.io/media-capabilities/ https://w3c.github.io/media-capabilities/ https://developer.mozilla.org/en-US/docs/Web/API/Media_Capabilities_API https://developer.mozilla.org/en-US/docs/Web/API/Media_Capab...
hospitalJail 3y ago
Drives me crazy how regressive Apple is with computing. While it seemed to shake out that GPU AI was the only real solution, earlier this year people were(and still are) putting resources into CPU based. I can't imagine someone @-ing me because when they were 18 years old and status insecure, someone sold them a corporate identity and feel entitled to maintain their edge case. I need to stop giving away my stuff for free.
- lost_womble 3y ago
  simping for google in order to "own" apple fanboys is just an embarassing position for an adult.
jeroenhd 3y ago
According to the followup toot, Youtube seems to assume Firefox + Linux + aarch64 = HiSense 65a67gevs. This was reported elsewhere too: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2017463 https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+... ; that issue was then forwarded to Chrome's bugtracker (https://bugs.chromium.org/p/chromium/issues/detail?id=1500114 https://bugs.chromium.org/p/chromium/issues/detail?id=150011...) which was closed with the comment "I'm hopeful they'll eventually get around to fixing the bug that you've reported". It sounds less like "let's help the poor Raspberry Pi users" or "let's make Asahi's experience worse" and more like "workaround for a buggy TV that nobody bothered to implement correctly".
GeekyBear 3y ago
> So they are serving lower resolutions to ARM... Doesn't sound like deliberately crippling Asahi Macs to me. If spoofing the user agent fixes the issue despite being on ARM, then this does sound like a legitimate issue. > Chrome is not affected even if it claims to be aarch64.
michaelmrose 3y ago
Virtually all arm devices do GPU decoding they kind of have to. This was a well understood problem in the 80s if two sides need to establish a commonality one offers options and the other picks. Google controls both YouTubers and the most common browser making it uniquely positioned to handle this well.
- monocasa 3y ago
  Eh, there's pretty famous examples that don't. For instance, the RPi5 cut out the H.264 decoders versus previous gens, and now only do H.265 decoding in hardware.
acdha 3y ago
They don’t need to detect the number of cores, although hardwareConcurrency is right there, but rather simply to ask the browser what it supports: https://developer.mozilla.org/en-US/docs/Web/API/Media_Capabilities_API https://developer.mozilla.org/en-US/docs/Web/API/Media_Capab... That way you can fall back for anything too old or weird to support that API, and if the vendor complains there’s a simple response: implement the standard.

watermelon0 3y ago

Have to agree with this. Not saying the check should be there, but the majority of non-mobile/server ARM devices are generally underpowered, especially with per-core performance.

matheusmoreira 3y ago

That sounds reasonable but it's weird that Chrome lies by pretending to be x86_64. The same performance concerns that apply to Firefox should apply to it.

borissk 3y ago

Hmmm, serving low resolution videos to ARM devices running Linux also makes harder for a competitor to build an alternative to Android.

deleted 3y ago
[deleted]
James-Livesey 3y ago
True, but any competing operating system could just falsely report that it is running x86-64 and therefore trick YouTube into serving high-res content. Disclosure: currently (as a personal project) slowly building an alternative to Android
- DeathArrow 3y ago
  Can you share it?

deleted 3y ago

[deleted]

gefriertrockner 3y ago

At the same time Chromium is not affected: > Why does this not affect Chromium? Because chromium on aarch64 pretends to be x86_64

OJFord 3y ago

Could it not tell if it's actually managing to play and keep up with time? Similarly to how (I believe) it'll degrade if the network is such that it's not loading 4k say quickly enough, it'll switch (if 'auto') to 1080p or whatever. > Detecting if the device has 20 cores or whatever like he says if possible would be more invasive of privacy. What he claims though is that they do already do that at least if it's not aarch64: > Quality 1080 by default. If your machine has 2 or fewer cores, quality 480. If anything ARM, quality 240.

piaste 3y ago
> Could it not tell if it's actually managing to play and keep up with time? Similarly to how (I believe) it'll degrade if the network is such that it's not loading 4k say quickly enough, it'll switch (if 'auto') to 1080p or whatever. Probably, but it's pretty poor UX if videos start super-choppy by default and slowly downscale to a playable resolution over several seconds. Having a good default is still important.
- rjsw 3y ago
  The test can be during the advert before the video that you want to watch.
- OJFord 3y ago
  Worse than stuttering if it's the network? Anyway, it could go up.

wasmitnetzen 3y ago

They already check the core count via the hardwareConcurrency API[1], check the second screenshot. [1]: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/hardwareConcurrency https://developer.mozilla.org/en-US/docs/Web/API/Navigator/h...

arp242 3y ago

Figuring out good defaults for this is really hard. In general, "Linux + aarch64 = lower performance = let's do lower resolution by default" seems like a reasonable thing, although not fool-proof obviously. Also note that the "is_arm()" is followed by "|| is_android()"-bit in his screenshot. Asahi Linux is a comparatively small project with few real users. It's pretty arrogant to assume Google is intentionally targetting them specifically. If anything, the bug here is that Chromium uses x86 on arm systems, although for Asahi specifically that's probably the right choice, it's a lot less clear to me that's the right choice for all systems.

izacus 3y ago
And the primary targets for that are probably ARM Chromebooks which tend to be underpowered by quite a bit. (I'm guessing those report aarch64 correctly.)
- rany_ 3y ago
  Well, that and also when you set "Desktop site" in mobile Chromium it will report a user-agent which matches that of desktop Linux on ARM. So it is most likely trying to target those devices as well.
gjsman-1000 3y ago
> It's pretty arrogant to assume Google is intentionally targetting them specifically. The Asahi Linux developers have a history of taking everything personally. If Apple adds a new way to start an ELF in macOS 12.3, it's because of them. If someone criticizes them publicly on Hacker News and isn't immediately shamed, it's because the actual leadership at Hacker News hates them (not an exaggeration considering their public stunt here where they blamed @dang for everything). If someone doesn't quite agree with their politics in perfect lockstep, they will publicly try to force you to resign (look at what happened with Dlang). And, more recently, threatening to keep changes downstream and out of the mainline Linux kernel as retaliation for what they call inappropriate conduct (which, well, if the COC of Linux hasn't been violated, I'm guessing it's probably them). And of course, if it's found out that the M2 has a technical bug with audio processing that literally nobody noticed until now, it's proof that Apple is full of incompetent idiots, unlike them. It's also why, if I were running a corporation, I would almost require that anyone using Asahi on their Mac use a corporate fork for their own protection. I wouldn't rule out retaliation.

drakythe 3y ago

You are assuming incorrectly. The bug report linked in the thread the user filed with Mozilla indicates that 4K resolution isn’t available even though once he changes the user agent string it was and it worked without issue.

Garvi 3y ago

[flagged]

matheusmoreira 3y ago
Gotta be fair about it. There's plenty of reasons to hate Google but this doesn't seem like one of them.
zaptheimpaler 3y ago
Yes I prefer to find the actual facts in a situation and pick sides (if at all) in that situation based on those facts not a predetermined "corporation bad, billionaire bad". Criticism loses all meaning if not based on fact and actually hurts the cause because then even meaningful criticism can be dismissed as baseless.

sambull 3y ago

they keep serving me 380p by default that I have to change and I've got a gigabit fiber with a modern ryzen and a monster gpu running the latest windows. So whatever they are doing auto quality wise has some screws loose.

padenot 3y ago

If you want to know the media decoding capabilities of a Web Browser, you can use the MediaCapabilities API. In Firefox, when flipping the "resist fingerprinting" flag, it's spoofed appropriately based on a study of what the most common results are. This is available on all engines, desktop and mobile. Depending on the implementation, what it returns can be based on the presence of optimized software decoders for a platform, presence of hardware, resolution and other characteristics of the video, it can also be based on a decoding benchmark that the web browser runs, etc. https://w3c.github.io/media-capabilities/ https://w3c.github.io/media-capabilities/ https://developer.mozilla.org/en-US/docs/Web/API/Media_Capabilities_API https://developer.mozilla.org/en-US/docs/Web/API/Media_Capab...

hospitalJail 3y ago

Drives me crazy how regressive Apple is with computing. While it seemed to shake out that GPU AI was the only real solution, earlier this year people were(and still are) putting resources into CPU based. I can't imagine someone @-ing me because when they were 18 years old and status insecure, someone sold them a corporate identity and feel entitled to maintain their edge case. I need to stop giving away my stuff for free.

lost_womble 3y ago
simping for google in order to "own" apple fanboys is just an embarassing position for an adult.

jeroenhd 3y ago

According to the followup toot, Youtube seems to assume Firefox + Linux + aarch64 = HiSense 65a67gevs. This was reported elsewhere too: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2017463 https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+... ; that issue was then forwarded to Chrome's bugtracker (https://bugs.chromium.org/p/chromium/issues/detail?id=1500114 https://bugs.chromium.org/p/chromium/issues/detail?id=150011...) which was closed with the comment "I'm hopeful they'll eventually get around to fixing the bug that you've reported". It sounds less like "let's help the poor Raspberry Pi users" or "let's make Asahi's experience worse" and more like "workaround for a buggy TV that nobody bothered to implement correctly".

GeekyBear 3y ago

> So they are serving lower resolutions to ARM... Doesn't sound like deliberately crippling Asahi Macs to me. If spoofing the user agent fixes the issue despite being on ARM, then this does sound like a legitimate issue. > Chrome is not affected even if it claims to be aarch64.

michaelmrose 3y ago

Virtually all arm devices do GPU decoding they kind of have to. This was a well understood problem in the 80s if two sides need to establish a commonality one offers options and the other picks. Google controls both YouTubers and the most common browser making it uniquely positioned to handle this well.

monocasa 3y ago
Eh, there's pretty famous examples that don't. For instance, the RPi5 cut out the H.264 decoders versus previous gens, and now only do H.265 decoding in hardware.

acdha 3y ago

They don’t need to detect the number of cores, although hardwareConcurrency is right there, but rather simply to ask the browser what it supports: https://developer.mozilla.org/en-US/docs/Web/API/Media_Capabilities_API https://developer.mozilla.org/en-US/docs/Web/API/Media_Capab... That way you can fall back for anything too old or weird to support that API, and if the vendor complains there’s a simple response: implement the standard.