没有 降低码率 的算法。

降低码率本质上是指用更低的码率重新压缩视频。

比如原始的未压缩视频是 20000kbps，你先压缩到 100kbps，现在要重新压缩到 70kbps，这意味着你先把视频解压成 20000kbps，然后用和第一次压缩类似的算法，丢弃更多的细节后，压缩到 70kbps 。

至于视频的压缩，这是一个很庞大的话题，几千字是说不清的，可以考虑去啃资料和教程，或者去听一些大学或者研究生课程。简单来说有几步。首先是帧间动态预测，一组相似的画面可以通过帧间压缩来降低码率，整个画面被切割成 MB 或者 CU，然后每个块与前后帧进行比较，如果残差比较省空间，就编码成残差，否则就原样按照画面编码。接下去跑 DCT 转换成频域，然后量化砍细节，最后执行无损压缩。

不，你还是换了个方法写「代码」
你不能说因为没有 if else 就不算写代码，那 brainf*ck 一定也是低代码零代码。
你不能说拖拖空间就不算写代码，那 scratch 吹什么学习代码的工具呢，趁早废了吧。

编程是一门古老艺术的现代表现形式，这门古老的艺术名字叫做「思考」。

https://lxml.de/performance.html

目前通常认为是 lxml 最快

识别计算模型，确实有币能绕过，之前 V2 上有人贴过测试，以太坊直接减半了，但另一个我甚至不记得名字的，好像说也是 hash，影响不大，还是有识别的敏感度和特异度两难问题。

C(1000, 400) > 4e290
10 秒内打印，也就是说每秒打印 >4e289 种可能性。
要区分这 >4e290 种可能性，需要 > log_2 4e290 > 962 bit > 120 bytes
也就是说每秒需要传输 > 4e289*120 B > 4e291 B 的数据

作为比较：yes | pv > /dev/null
采用目前输出速率最高的 GNU yes，2.92GiB/s 即每秒输出 3.135e9 B
中间差了 282 个数量级。

——

@necomancer 让咱们再假定你流式进行处理，每个操作只需要占用一个 CPU 周期，并且你的 CPU 有 64 核，且所有核心超频到 10GHz
4e290 / 64 / 10e9 > 6e278 秒 > 1e271 年
好吧，再让我们用上 GPU 加速每个操作可以用一个 CUDA 核心的一个时钟周期完成，一块 RTX 3090 按照 10496 CUDA 核心，假设超频到 3GHz，需要花费
4e290 / 10496 / 3e9 > 1e277 秒 > 3e269 年
这个数据量太离谱，itertools 也根本没得作用。

——

如果要把 C(1000, 400) 量级的数据在 10 秒内输出，不要说比特币 51% 攻击了，99% 攻击都能发动了。
直接把链算到底，连计算难度都来不及变更，变更了也没用；这 CPU 比当今所有的 GPU 都快几百个数量级。
比特币暴跌，然后我能买到显卡了。

再脑洞下

处理大量信息时，根据 Landauer's principle，必然产生热量，随便地瞎估一下，应远大于
2.805zJ*4e290 相当于 2.682×10^260 吨 TNT 当量
你这不是 CPU，这是 1e250 吨的质量弹

标题陈述有误？
你这是在 mock 一个装饰器吧

简单的情况下，你不能。
yyy:timeit():wrap 已经生成并从 yyy:timeit() 里买定离手了。
除非你去魔改 yyy:timeit():wrap 的字节码

当然，如果你高兴的话可以把每一个被 yyy:timeit() 装饰过的函数全部替换为 xxx:mock_timeit() 修饰的版本。
还有一种，就是修改 yyy:timeit() 的实现方式，把它从一个函数转变为一个 class，其中定义了 yyy:timeit.__around__(self, func)(args, *kwargs) 。