起因很土。给客户发一个 60 多 M 的录屏，Gmail 说超了 25M ，扔网盘对方公司的网又打不开。
本机有 ffmpeg ，但每次都得去翻 crf 该给多少，笔记本风扇还要吼两分钟。想找个在线的，搜出来前几个一半给你打水印，一半让你先注册。
于是自己搓了一个： /ai-market-guide/ 先把话说在前面：压缩这一层我用的是 FreeConvert 的 API ，不是自建 ffmpeg 集群。剩下的东西（登录、额度、计费、下载代理、i18n 、后台）都是自己写的，Next.js + Drizzle + Supabase ，跑在 Vercel 上。
能干的事： - 直接填数字。要 18MB 就填 18 ，它按这个体积去编码，输出基本落在你要的值上 - Discord 20M 、WhatsApp 16M 、邮件附件这些常见上限做成了滑块下面的按钮，不用自己算 - 也能完全手调，CRF 、分辨率、最高码率都在高级里 - 不加水印，免费也不加 - 不登录就能直接试，单文件 500M 以内；注册了免费 30 次/月，单文件 1G 过程里有两个坑还挺值得讲的。
一、我把上游的计费方式理解错了，白烧了好几周额度。 FreeConvert 一个 job 是 import -> compress -> export 三个 task 。
我一直以为三个都按分钟计费，就在每个上都留了一分钟下限，等于每个小文件都按 3 分钟收。后来专门跑对照组，故意把 import 拖到 144 秒，账单是 0 。
只有 compress 计费，按墙上时间向上取整，最低一分钟。改完之后免费用户那 30 次额度才是真的 30 次，之前实际只够 10 次。
教训就是别信自己没量过的假设，尤其是花钱那部分。二、中间多一跳反而更快。
本来是浏览器直接把文件 POST 给上游。 593M 的文件，import 花了 127.8 秒，瓶颈在家里的上行。
改成浏览器先 PUT 到自己的 R2 ，再让上游 server-to-server 去拉，import 掉到 18.3 秒。 import 本身不计费，所以省下的是等待时间，又因为取整边界变了，计费分钟顺带从 6 分降到 4 分。
R2 出网免费，这一下等于白赚。还有个 bug 蠢得我想删库：目标体积那个滑块我写了 min={1}，传个 1.5M 的小视频进去，min 和 max 都算成 1 ，滑块直接动不了。
现在 min/max 是从源文件大小推出来的，步长也按「轨道上大概一百个位置」去选，1.5M 的片子按 0.1 走，500M 的按 5 走。顺手发现上游其实吃小数：2.8M 的源要 0.4M ，真给你压到 0.2M ，尽管它文档里那个 validation_regex 看着只收整数。
另外把套餐页上的「优先队列」和「批量处理 3/10/25 个文件」删了。这俩当初是照着同类产品抄的卖点，代码里一行都没实现，留着就是骗钱。
界面还比较糙，压缩预设的默认值也还在调。想请大家拿手上真实的视频试试，尤其想知道： - 有没有哪类文件传上去直接失败 - 压出来的画质跟你预期差多少 - 目标体积模式偏差大不大 被喷也行，我改。