@quxinna " 视频为什么 Index=CRC XOR Input Data?"正常来说，不用加速表，一个 byte 有 8bit, 每个 bit 都是有可能算一次异或的(视具体多项式而定)。
加速表把这个结果预计算后保存起来，那么现在处理一个 byte，仅需要算一次异或，大大降低了总体计算量。

@forsigner "有计划做，做个 webpack-loader 就可以"

我说的 JIT, 是类似 vue.js ，前端包含一个 js 后，页面载入前，前端能动态编译 v-if, bgOrange300 之类的，到对应的 js/css 代码。
和 webpack 没关系，总觉得我们聊的不是一个 Just In Time Compiler 。

把两边屏幕的部分裁剪下来，用 fft 2d 进行运算，画面是不是模糊处理过，频域空间一看便知。

@quxinna 说了数据是一个 bit 一个 bit 处理的，和元素有多少位没关系，表格仅仅只是为了加速运算，所以 256 个数组来加速一个字节，已经足够了。
元素是 32 位，说明最终的累加结果是 CRC-32 位的，你要把中间结果都加起来，肯定不能只用 8 位了。如果元素是 64 位，那就是 CRC-64 位算法。

@quxinna 你没懂我的意思，索引是 256 个，说明是对数据 8 个 bit 进行处理，也就是每次处理一个 byte 。
你也可以改成 4 个 bit 一次建表，那就是 lookuptable[16]。
和计算的 order 没关系。

不能做成 jit 的库吗？不想预编译啊。
反正全部都是 JS 代码，放在前端编译一次后，动态生成的 CSS 缓存在本地不是挺好的。

少壮不努力，老大徒伤悲。想一下十年后，希望自己成为什么样的人，过着什么样的生活。

现在所有的决定，都是按照未来时间节点，倒推回来的。

order 是次方的意思，CRC 原理就是多项式校验和，CRC-8 是单次计算最大 8 次方，CRC-32 是单次计算最大 32 次方。

查找表的本意是把多项式累加这个预处理过程先算一遍，和处理最终值大小没什么关系。因为对于输入的校验数据，都是按照 bit-by-bit 处理的，就算查找表也一样。

有意思，有高手能指导一下跳转原理吗？没看出来蹊跷的地方。

@Pogbag https://tv.zol.com.cn/688/6889690_all.html

这新闻有点老，但里面确实提到了电视和大显示器最本质的差别，就是输入延迟的问题。
好像很多互联网电视都刻意回避讨论这点，比如华为的电视，测试 PS4 游戏延迟上，一言难尽。

我对 AOC 低延迟的游戏电视有天生好感。
如果只看电视，我觉得各个牌子都差不多。但测试游戏延迟差别，那就大太多了。

@CEBBCAT "通过经常的练习自然而然就可以习得技巧，获得自信"
其实码农一般不太在乎对方说多少话，重要的是说了什么内容。

那着打印好的稿子读呗，这总不会遇到卡壳了。

@aneureka "不知道图片能不能正常显示"

v2 回帖里显示图片，貌似只能是 v2 图库，sina 图库，imgur 这三个。
只有发帖不受任何限制，随便一个网络图片都可以。

@aneureka 我觉得红线也挺符合条件的，汗。

拿 4k 算法插值吧，现在 AI 放大图片还是挺强的，不会模糊。
8k 图片和 8k 视频一样稀少。

你可以看这个页面 http://www.zorc.breitbandkatze.de/crc.html

所谓 CRC-8 和 CRC-32 区别，也就是 order 不一样，查表是一样的。

我猜测楼主想描述的，就是和小米电视广告屏蔽一样，不能简单只改 hosts，就把广告给删了。

个人总结下来有四种方法：
1 是和 bilibili 客户端一样，页面初始化的时候强制调用 www.bilibili.com/api 接口，再进入主页面，你肯定不能把 www.bilibili.com 给删掉吧。
2 是请求用 websocket 处理，因为是流式数据，不可能只屏蔽广告其中一个请求。还可以自己写一点协议加密。
3 是用 vue 之类属性监控方法，看 dom 有没有被外部脚本动态修改。
4 运行过程中，用遍历 dom 方式，给 http 整体签个名。不符合服务器预设签名的，直接不显示内容，用户只会觉得是广告拦截的问题。


其实最好的办法，就是检测在 chrome developer tool 里 content scripts, 所有会对你网站 DOM 进行恶意操作的脚本，都在这个列表里。只是目前不清楚怎么能获取。

绘图需要大屏幕和精准色彩，码农其实无所谓，就多看几行代码，又不能变的更强，还不如把屏幕竖过来。
工作上最终屏幕大小没什么太大影响，够用就行。
唯一特例，就是娱乐看电影和打游戏。