halfsize / X（Twitter）
视频压到能发 X（Twitter）
X 单个视频最多收 512 MB，然后几乎都会重新编码一遍。真正卡人的通常不是上限， 而是上传速度和那第二次压缩。这里讲怎么给它一个不会被压糊的文件。
512 MB 不是真正的瓶颈
手机拍的 4K 三分钟素材，本身就可能超过 512 MB；但更多人先撞上的是带宽：10 Mbps 上传传 400 MB 要五分半，断一次就得从头再来。
X 还会自己转码。与其丢一个巨大的 4K 源进去，不如先输出成它想要的样子：H.264 视频、AAC 音频、1080p、+faststart。这样平台能丢掉的东西更少。
一条命令
$ npx halfsize 片段.mp4 --for twitter
target 512 MB
plan H.264 1920x1080 21.8 Mbps audio 128 kbps 2-pass
output 片段.512mb.mp4
1.24 GB → 498 MB 小 2.5 倍 比目标小 2.7%
VMAF 96.1 SSIM 0.992 看着一样想几十秒传完，就自己定一个更小的数。一分钟的片子根本用不到 512 MB：
$ npx halfsize 片段.mp4 --to 80mb竖屏视频
手机素材通常是 1080×1920 加一个旋转标记。工具会读这个标记，输出真正的竖屏文件，而不是一条横屏视频再靠元数据转过来——后者在部分播放器里会直接横着放。不补黑边。
重新编码会损失多少画质
60 秒 1080p30、源 18 Mbps，默认设置的实测：
| 目标 | 输出 | 分辨率 | VMAF | 结论 |
|---|---|---|---|---|
| 512 MB | 498 MB | 1920×1080 | 96.1 | 看着一样 |
| 100 MB | 97.6 MB | 1920×1080 | 93.4 | 看着一样 |
| 40 MB | 39.1 MB | 1280×720 | 88.7 | 轻微变软 |
多一次编码不是白给的。上传前就把文件做成 X 偏好的格式，平台能再损失的空间就更小。
给 X 的格式清单
- 容器：MP4 +
+faststart，边下边播。 - 视频：H.264 High、
yuv420p，1080p 或更低。 - 音频：AAC 128 kbps 立体声，再高也会被转掉。
- 帧率：源是多少就多少，最高 60 fps，不要伪造更高。
halfsize 的默认值就是这份清单，所以多数时候 --for twitter 就够了。
常见问题
X 真的收 512 MB 吗？
这是目前普通账号的单视频上限，而且调整过不止一次。视频时长限制还和账号等级有关。如果你的账号显示的数字不同，用 --to 按实际数字来。
要不要传 4K？
除非多出来的分辨率比上传时间更重要。多数播放场景下 X 最终给的是 1080p，一个干净的 1080p 更划算。
为什么上传后变糊了？
X 又转码了一次。如果你给它的是 H.264、AAC、+faststart，而且码率本来就没被饿死，它能破坏的空间会小很多。
会上传文件吗？
不会。压缩全在本地完成，只有最后发布那一步才把文件传到 X。