同个博客的文章。
https://eclecticlight.co/2022/01/02/last-week-on-my-mac-on-m1-chips-1-1-4/
>
On an original M1, with its four E cores, low QoS ‘background’ processes run with the core clock speed at around 1000 MHz...

The two E cores on an M1 Pro are managed differently... when a second process is added... the clock speed is doubled to nearly 2000 MHz. The effective throughput then matches that of the original M1’s four E cores still running at 1000 MHz...

总结是干 Low QoS 的“重活”时，M1 Pro/Max 的 2 颗 E 核和 M1 普通版的 4 颗 E 核性能基本等同。

@shanguiyao 会压缩的。比如这个，原本是 FLAC 档，转换成 ALAC 后拖进 iTunes ，上传到 iCloud 音乐资料库的是经过 iTunes/Apple Music 转换成 iTunes+ AAC (256-Kbps) 等级的音质。
https://i.v2ex.co/64E0w51E.png

@tysb777 不管 WAV 还是 ALAC 只要不是通过 iTunes/Finder 拷贝到手机里的都要转成 256 Kbps LC-AAC 的。至于苹果的 AAC 编码器质量其实完全不用担心。见 https://v2ex.com/t/876282#r_12045556

@tysb777 可以转换 ALAC 。
@shanguiyao Apple Music/iTunes 将自己的无损曲目上传到 iCloud 音乐资料库时会在本地使用苹果的编码器压缩成 256 Kbps 的 AAC 。
@JConlee YouTube Music 上传歌曲后（无论是否有损无损）会在云端被 Google 的编码器转换成 128 Kbps AAC, 256 Kbps AAC, 160 Kbps Opus 。AAC 版本的质量非常差。

YouTube Music 有不同的来源。

用户 /版权公司上传到 YouTube 上的视频，音频部分有。
(140) 128 Kbps AAC
(251) 160 Kbps Opus
比如 https://www.youtube.com/watch?v=J9gKyRmic20

从版权库拿的，Google 会使用自己的 AAC encoder 压缩。
(140) 128 Kbps AAC
(141) 256 Kbps AAC - 会员音质
(251) 160 Kbps Opus
比如 https://www.youtube.com/watch?v=Sr9QVlUqmrw

用户自己上传到 YouTube Music 资源库的音乐，Google 会用自己的 AAC encoder 二压。
(140) 128 Kbps AAC
(141) 256 Kbps AAC - 会员音质

YouTube 播放器 Stats for nerds 可以查看播放的是哪条轨道。

不要看到 AAC 就以为音质不错了。
音频编码器和视频编码器类似。
视频 H.264 领域中不同编码器 libx264, OpenH264, Intel QuickSync, AMD AMF, NVIDIA NVENC, Apple AVE 同样的码率会有不同的质量。同一编码器不同的参数也会有不同的质量。
音频 AAC 编码器普通人能用到的有 FFmpeg, FDK-AAC, Nero AAC, Apple QuickTime (AudioToolbox)。Apple 和 FDK 的质量是最高的。Google 的 AAC 编码器在 256 Kbps 的表现甚至连它自己的 160 Kbps 的 Opus 都不如。

放几张图。
https://i.v2ex.co/6Q1k0v4e.png
iTunes/Apple Music AAC 256 Kbps | YouTube Music AAC 256 Kbps

https://i.v2ex.co/7834amiQ.png
YouTube Music Opus 160 Kbps | AAC 256 Kbps

https://i.v2ex.co/6RRJi7r4.png
无损 | 用 iTunes 转换成 AAC 256 Kbps | 上传到 YouTube Music 资料库压缩后的 AAC 256 Kbps

海外音频流媒体里会员音质这么差的还是第一次见。会员音质比非会员的还烂。

看起来像 Widevine CDM 的问题。
不清楚 iOS ，但在桌面平台只有 ChromeOS 的 Widevine CDM 能够使用硬件解码。其余都是软解的。

(至少表面上) Netflix 以这个性能考量只在 macOS 和 Windows 的 Chrome / Firefox 开放 720p 。

Windows 下的 OneDrive 也问题很多的。朋友小文件存了 60 GB 直接罢工，一直卡在处理变动。

@hanguokai 直接扔给平台提供的播放 API 不去做 UX ，那这个 PWA 和系统自带的有什么区别。系统自带的还会提示部分轨道不能播放呢。

@hanguokai https://developer.mozilla.org/en-US/docs/Web/API/Media_Capabilities_API/Using_the_Media_Capabilities_API

@codehz
非此环境的 Chrome 不支持 HEVC 。
https://www.chromium.org/audio-video/#:~:text=H.265%20%5BGoogle%20Chrome%20OS%20on%20Intel%20Gen%2011%2Dbased%20Chromebooks%20for%20protected%20content%20playback%20only%5D

@hanguokai
Chrome 、Edge 等浏览器在无硬件支持（如老款设备）或硬件支持但受平台限制（如 macOS VideoToolbox 、Windows MediaFoundation ）也会软解播放 vp9 和 av1 。

笔记本内建的 polling rate 125Hz ，Magic Trackpad 无论线还是蓝牙都是 90Hz 。

和信号线无关。Windows 的问题。某些 API 渲染的窗口 (如使用 duilib 的微信、任务管理器、Explorer.exe 等) 在 GPU 渲染的内容之上时垂直同步会很鬼畜。
你的情形就是微信窗口横跨浏览器和 IDEA 。正好裂缝就在浏览器窗口、浏览器滚动条和 IDEA 之间。

有区别的。MacBook 内置的触控板 polling rate 是 125 Hz 。蓝牙 Magic Trackpad 的 polling rate 是 90 。即使在 60 Hz 的屏幕上也能感到跳跃感。

桌面版 Safari 可以直接把整个页面导出成保持布局的 PDF （不是打印再保存为 PDF ）。之后可以自行转换成各格式。

@loopinfor 这是 Windows 的历史遗留问题。使用硬编码的字体替代列表而不是依赖当前系统语言列表顺序的字体集来 fallback 。

@ssbg2
@Mirage09

AMD 显卡在有 ≥2 台活跃显示器时显存强制运行在最高频率。这款机型上，较正常运转有 15+W 的额外功耗。Windows 平台桌面显卡也是这样的。

默认词典是第一位的。如果没有的话去词典 app 的偏好设置里勾选你需要的词典。

@GPU

https://imgur.com/F7hxxxr
软解，可见 480% 的 CPU usage 差不多是 4 个大核 4 个小核跑满。

https://imgur.com/LLIKoTc
硬解。

硬解时 (4K60 vp9) VTDecoderXPCService 活跃，此时肯定是硬解。软解时 (8K) 不活跃。
Safari 因为分出去了 Safari Graphics and Media 进程所以不太清楚。
活动监视器不会显示硬解模块的载荷。

不过按照 M1 在 Chrome 也能软解 8K60 vp9 的性能基准来看，Safari 放这片卡得不能动应该是直接扔给 VT 来硬解了，但 M1 的 vp9 解码没有 target 8K ，所以过载了。这和 target 8K24 vp9 的 AMD RDNA 系列卡放 8K60 会掉帧一样的原理。

M1 Mac mini 只需要 17 分钟。
powermetrics 显示基本是 CPU 和 ANE 在干活。