@老虎会游泳，@水木易安，@胡图图，算个导数，再求零点，就纠正了。。
计算过程
已知半径为
R 的球体上，经纬度为(\varphi_1,\theta_1) 的点A_1 与(\varphi_2,\theta_2) 的点A_2 间的距离S 公式为：
S = Rarccos(sin\theta_1 sin\theta_2 + cos\theta_1 cos\theta_2 cos(\varphi_2 - \varphi_1))
A_2 在不同纬度上，与A_1 间的经度差\varphi_2-\varphi_1 的导函数为：
\begin{align} {(\varphi_2 - \varphi_1)}' & = {arccos(\frac{cos(\frac{S}{R} )-sin\theta_1 sin\theta_2}{cos\theta_1 cos\theta_2})}' \\ & = \frac{sec\theta_2(cos(\frac{S}{R})sin\theta_2-sin\theta_1)}{cos\theta_1 \sqrt[]{1-\frac{(cos(\frac{S}{R})sec\theta_2-sin\theta_1tan\theta_2 )^{2}}{cos^{2}\theta_1}}} \end{align} 求其零点，得到
A_1 与A_2 经度差\varphi_2-\varphi_1 最大时，A_2 纬度\theta_2 ：\theta_2 = arcsin(\frac{sin\theta_1}{cos(\frac{S}{R})}) 结果图
std::cin >> word这个io可能比较慢确实，我改成
std::getline(std::cin, word)后，就由 28 秒 → 25 秒了。你可以自行统计一下分段用时，看看输入、计算和输出各占比多少。
我简单测了测，读取 1 亿 15 长度字符串用时。
std::cin >> word：5.1 秒std::getline(std::cin, word)：2.2 秒- 手动开 64KB 缓冲区，每次
std::cin.read()填充，std::memchr找\n，str.append()构造：1.4 秒感觉输入上，这速度也可以了。
而且，我
strace了一下 DuckDB，它也是要读到缓冲区里的，且缓冲区贼大，32MB。。且一定要填充完整 32MB，才干活。。怪不得我说，一边解压大文本/脚本实时生成内容，一边喂给 DuckDB，怎么耗时会变长。。明明 writer 产生内容的速度还挺快的呀。。
也许输入输出是大头（因为stdio是同步锁定的）
我取消与 stdio 同步了：
std::ios::sync_with_stdio(false);。这个确实很耗时间。不取消的话，总时间直接翻倍。。
把文件mmap到内存然后使用
char*指针直接访问如果想解压大文本，再通过管道喂给程序时，好像不能 mmap 了吧。。
@老虎会游泳，
DuckDB也设成单线程的了。对比起来应该算公平的？
DuckDB双线程时 14 秒，3+线程爆（笔记本 8GB 板载）内存了。。老虎看这代码，有啥不合理的地方，才拖累性能，打不过
DuckDB吗？
@tasy5kg，对了，我有一些 HEVC 视频（假设都是 30 fps，1h 的视频），但仅开头处有 1 个 I 帧，其余全是 B 帧，导致无法随意拖动进度条。
你知道，如何每 10 秒，重编码一个 B 帧为 I 帧（仅需重编码 360 帧 ），而不是全部重编码（要重编码 10.8W 帧），来修复视频吗？
@tasy5kg，看了看文档，libsvtav1 确实只支持 8/10 bit。。
但 avifenc 支持 12 bit。我搜索论坛里的 mp4 文件，选了其中三个，试了试转成动图，确实 12 bit 能比 8 bit 再小 20% 左右。
转码脚本（Windows 下可用 600KB 的 busybox-w32 来运行，要求
PATH处能找到ffmpeg、avifenc）：speed=5 quality=50 for file in *.mp4; do for depth in 8 10 12; do ffmpeg -v quiet -i "$file" -strict -1 -pix_fmt "yuv420p$( [[ $depth == 8 ]] && echo '' || echo "${depth}le" )" -f yuv4mpegpipe - | avifenc -q "$quality" -s "$speed" --min 0 --max 63 --stdin "${depth}bit_${speed}s_${quality}q_${file%.*}.avif" done done文件所在帖子：
