要不要每个人加个操作频率上限，避免害群之马瞎填。

如果能每次求出一个排列就进行统计的话，内存就应该够了。而不是把指数级的的可能结果全部放到一个数组里再一个一个统计。
另外推荐仔细学习一下全排列的代码，把你这个 impossibleObjects 的逻辑放到全排列里进行剪枝，性能会好很多。

上来就求全排列，12!=479001600 种情况，每一个都是 12 长度的字符串数组，每几十上百 GB 内存是不够的

加点钱，加一个 wasm 或者 asmjs 的 ffmpeg 转码功能。如果传了 wmv 就页面里转，慢得要死，同时提示如果自己转会快很多，给个下载链接。

抓包又何必在控制台

直接进专门的 youtube 下载网站，复制链接进去，他给你生成链接的那种

## 画每一片：

参考链接：
https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Compositing
https://stackoverflow.com/a/18387192/2244973

如果每一片形状的数量是有限的，或者形状是无规律的：
1. drawImage 画 mask(即描述形状的图片)
2. globalCompositeOperation = 'source-in'; 设置为只允许画在 mask 上
3. drawImage 画图片本体
注意调整画图的 src 位置和 dest 位置

如果每一片形状的数量是非常多且有规律的：
1. 画一个 path，作为形状
2. context.clip(); 设置为只能在范围内画
3. context.drawImage 画图片本体

## 变成一体
这个没什么特别的吧，判断组合然后依次画上去就行了
在松鼠标的时候，判断一下原图中周围的块是不是真的在旁边，如果在就用并查集连在一起。再拖动的时候，这个集合的块全部一起移动，松开的时候，全部判断新的组合

2 个

如果不精确要求时间的话，不重新编码，用 2L 的那个
如果要求精确时间，就需要重新编码，快不了

骑到 i 点下车的最小代价 cost[i] = min { cost[j] + 骑 j 车到 i 点的代价 }，j 从电量骑到 i 点的车里选，把每个点选择的 j 存下来最后反查

就是用文字作为 mask，在原图上画一张预先准备好的或者生成的有颜色图片。

nircmd 有 win move 、win center 、win max 等命令，应该能满足需求了，移动窗口，居中，最大最小化等

P 帧应该是依赖前一个 I 帧，B 帧依赖前后各一个 I 帧。记录好当前 I 帧和下一个 I 帧的位置，随便给你一帧就能找到这一帧依赖的所有帧了。
不过确实按照 1L 说的，想要知道下载量，只看播放量肯定不行啊，感觉想要真正解决问题还是从下载部分入手比较好。

https://twitter.com/gavkar/status/1329263147920756739

"I was waiting for this. Our display pipes are many years ahead of the industry & this is just 1 of that. From contrast to accessibility to color management many teams at Apple, including my display driver team, put so much effort to it. Glad to see it makes a difference."

要加规模肯定要设计大芯片啊，以前 ipad 用的芯片好多都是带 X 的新设计的芯片。苹果没有 CPU 间高速互联的经验，民用产品搞 numa 不太可能。

F2 F5 F6 F7 F8 F9 F10 F12 用得很多

去年 TGA 上死亡搁浅参加了一圈儿了，10 个提名，得了其中 2 个。今年肯定不能上了吧。

ARM 的影响最多最多到总线一级，和外围设备互联没啥关系，我觉得就是 M1 没有设计这么多 IO