x265 — HEVC/H.265 编码器
待复核x265 是一个把原始视频压成 HEVC/H.265 码流的开源编码器。日常类比：它像更会装箱的搬家师傅，x264 已经能把衣服叠得很紧，x265 还会换更大的收纳格、重新安排顺序，用更多计算换更小的箱子。
最小例子来自它的命令行文档思路：
x265 --crf 28 input.y4m output.hevc这行命令的意思是：读入 input.y4m 这样的 Y4M 原始视频，用默认的 CRF 质量模式编码，输出 output.hevc 这样的裸 HEVC 码流。
如果 ffmpeg 是多媒体工具箱，x265 就是里面负责 H.265/HEVC 压缩的发动机；如果 x264 解决的是 H.264 时代的压缩问题，x265 解决的是 4K、8K、点播和高带宽成本下的下一代压缩问题。
不理解 x265，下面这些事就不好解释：
- 为什么同样是 4K 视频，HEVC 常能比 H.264 更省带宽，但编码会更吃 CPU。
- 为什么
CRF、bitrate、preset、tune、VBV总一起出现，因为它们共同决定质量、体积、速度和播放稳定性。 - 为什么 x265 文档反复强调多线程、WPP、NUMA 和 SIMD，因为 HEVC 算法复杂，性能不是顺手就有。
- 为什么开源许可证和专利许可要分开看，因为代码能 GPL 发布，不等于 HEVC 专利自动解决。
-
HEVC 的单位更大：H.264 常从 16x16 宏块讲起，HEVC 用更大的 CTU，把画面切成可递归拆分的区域。类比：以前按小格子整理房间，现在先看大房间，再决定哪里切成小格子，复杂处细分，简单处少花力气。
-
率控是在分配预算：
CRF追求相对稳定的主观质量，bitrate和多遍编码追求目标码率，VBV限制短时间波动。类比：家庭预算可以按生活质量花，也可以按每月上限花，还可以给钱包设一个最低余额。 -
性能靠并行和汇编撑住：x265 默认启用 WPP，让 CTU 行像波浪一样并行前进；项目代码里大量 C++、C 和汇编，目标是在多核 CPU 和 SIMD 指令上把复杂算法跑快。类比：不是一个人慢慢装箱，而是一排人按依赖顺序接力。
案例 1：离线压片，用 CRF 保持主观质量
Section titled “案例 1：离线压片，用 CRF 保持主观质量”x265 --preset slow --crf 28 input.y4m movie.hevc逐部分解释：
--crf 28：选择质量目标；数字越高，量化越重，文件通常越小，画质也越低。--preset slow：让编码器多花 CPU 搜索更好的压缩方案，通常能在同等观感下减少码流。input.y4m movie.hevc：x265 CLI 允许把第一个额外参数当输入，第二个额外参数当输出。
这个案例适合离线归档、个人压片和批量点播转码。它不保证最终大小，因为 CRF 文档明确说文件大小由素材复杂度决定。
案例 2：交付固定码率，用二遍编码
Section titled “案例 2：交付固定码率，用二遍编码”x265 --pass 1 --bitrate 3000 --stats movie.stats input.y4m /dev/nullx265 --pass 2 --bitrate 3000 --stats movie.stats input.y4m movie.hevc逐部分解释：
--bitrate 3000：把平均码率目标设为 3000 kbps，比 CRF 更适合固定带宽或固定体积交付。--pass 1：第一遍先收集每帧复杂度和编码信息，写入movie.stats。--pass 2：第二遍读取统计文件，重新调每帧 QP，尽量把比特花在更需要的地方。
这个案例适合课程平台、下载文件、机顶盒分发这类”目标码率不能太飘”的场景。x265 文档还提供 --strict-cbr，但那是更偏严格码率合规的场景。
案例 3：直播或互动，用低延迟调参
Section titled “案例 3：直播或互动，用低延迟调参”x265 --preset veryfast --tune zero-latency \ --bitrate 2500 --vbv-bufsize 5000 --vbv-maxrate 2500 \ live.y4m live.hevc逐部分解释：
--preset veryfast：直播更怕来不及编码，所以先保证速度。--tune zero-latency：关闭或缩短 lookahead、B 帧、cutree、帧线程等会增加等待的结构。--vbv-bufsize和--vbv-maxrate：给播放器缓冲和本地峰值码率设边界，减少一会儿爆码、一会儿断流。
这个案例适合实时推流、互动课堂和云端转码预览。代价也很清楚：低延迟会牺牲一部分压缩效率和画质稳定性。
-
把 x265 当容器工具：CLI 输出的是裸 HEVC bitstream，不会自动封装成 MP4；要封装通常交给 ffmpeg。
-
把 CRF 当固定码率：
--crf不追目标码率，复杂画面会自然变大，简单画面会自然变小。 -
盲目追
placebo：更慢的 preset 会测试更多编码选项，但收益递减，生产环境常被 CPU 成本反噬。 -
忽略输入格式：x265 CLI 只直接吃 raw YUV 或 Y4M，YUV 还要给分辨率、位深和色度格式；它不负责格式转换。
适用 vs 不适用场景
Section titled “适用 vs 不适用场景”适用：
- 把原始或中间格式视频压成 H.265/HEVC，用于 4K 点播、归档、机顶盒或带宽敏感分发。
- 需要在画质、体积和速度之间精细调参的媒体工程流水线。
- 想研究现代视频编码里的 CTU、WPP、lookahead、rate control、SIMD 优化。
- 作为底层库被 ffmpeg、handbrake、媒体云服务或自研转码系统调用。
不适用：
- 只想剪辑、加字幕、混音、转容器；这些是 ffmpeg、shotcut、mlt 更擅长的事。
- 追求最广泛老设备兼容；H.264/x264 的兼容面仍然更宽。
- 需要 AV1、VP9、VVC 等其他编码格式；x265 的职责只在 HEVC/H.265。
- 不想处理 GPL、商业授权或 HEVC 专利问题的产品分发场景。
历史小故事（可跳过）
Section titled “历史小故事（可跳过）”- 2013 年：MulticoreWare 启动 x265，目标是做高效率、高性能的 HEVC 软件编码器。
- HEVC 背景：HEVC/H.265 由 MPEG 与 VCEG 的联合团队推动，目标是缓解高清、超高清和点播带来的带宽与存储压力。
- x264 影响：x265 借鉴了 x264 的许多编码经验，但 HEVC 的 CTU、WPP、SAO、更多预测结构让实现复杂度明显上升。
- VideoLAN 镜像：GitHub 上
videolan/x265是项目镜像，仓库约 800 star，真正影响力更多体现在 FFmpeg、播放器和转码链路里。 - 社区演进：项目长期围绕 preset、rate control、线程模型、HDR、ARM/x86 SIMD 和商业集成需求持续打磨。
- 压缩不是简单变小：编码器是在判断哪些画面信息更值得保留，哪些可以用预测和量化省掉。
- 参数都是取舍按钮：
CRF管主观质量，bitrate管目标大小，preset管 CPU 时间，tune管特殊素材或场景。 - HEVC 更省但更重：比 H.264 更高压缩效率的背后，是更复杂的块划分、预测、滤波和并行调度。
- 工程边界要分清：x265 负责编码裸码流，封装、滤镜、音频、字幕和分发通常交给上层媒体工具。
- videolan/x265 GitHub 仓库 —— README、源码、许可证和
doc/目录入口。 - x265 CLI 文档 —— 查询
--crf、--bitrate、--pass、--vbv-*等参数。 - x265 preset/tune 文档 —— 理解速度档位、
grain、fastdecode、zero-latency。 - x265 threading 文档 —— 理解 WPP、frame threading、NUMA 和并行收益上限。
- x264 —— H.264/AVC 编码器，和 x265 是最直接的历史与工程对照。
- ffmpeg —— 最常见的上层入口，常通过
libx265调用 x265。 - handbrake —— 适合从图形界面理解 x265 参数如何暴露给普通用户。
- x264 —— x265 继承了 x264 的很多工程经验，但面向 HEVC/H.265。
- ffmpeg —— 日常转码更常通过 FFmpeg 调用
libx265，而不是直接手写 x265 CLI。 - handbrake —— GUI 转码工具会把 x265 的 preset、quality、tune 包装成用户能理解的控件。
- gstreamer —— 媒体管线框架，能把采集、过滤、编码、封装串成实时流水线。
- salsify-2018 —— 研究网络传输与编码协同，帮助理解为什么码率控制不能只看编码器内部。
- gcc-webrtc-2016 —— 实时视频拥塞控制，与 x265 的 VBV 和低延迟取舍形成上下游关系。
- kdenlive —— Kdenlive — KDE 非线性视频剪辑
- lame —— LAME — MP3 编码事实标准
- shaka-packager —— Shaka Packager — 流媒体打包工具