x264 编译指南:从源码到第一条编码命令

音视频开发系列 · 第 040 篇

聊一个很多人嫌麻烦的事：自己编译 x264。

按理说现在 apt、brew、pacman、vcpkg 都能装预编译的 libx264，何必折腾源码。

但只要你做的事稍微深入一点，就绕不开自己编译这一步。比如：

• 想用最新版 x264 的某个新特性，发行版仓库版本太老；

• 想编出带 libavformat 输入支持的 x264.exe，能直接读 mp4 而不只是裸 YUV；

• 想交叉编译给安卓、iOS、嵌入式 Linux 用；

• 想把 x264 链进自己的 C++ 项目，需要确认 ABI 一致；

• 想确认 asm 汇编加速真的开了（这事影响 5-10 倍速度）；

• 想定制 bit depth 或 chroma format（比如只编 10bit 4:2:0 节省二进制体积）；

• 想给嵌入式平台做精简，去掉用不上的码率控制模式。

所以这篇就把 x264 编译流程从头到尾走一遍，给两套能直接抄的命令清单：Linux 一套，Windows MSYS2 一套。后面再给两个 C++ 工程示例：CMake 链接 x264 和封装一个简单的编码器类。最后再聊聊交叉编译给手机平台用、以及编译过程里那些隐蔽的坑。

x264 是什么

简单说：x264 是一个开源的 H.264/AVC 视频编码器。

VideoLAN 团队维护，GPL 协议，纯 C 写的，2004 年开始开发，至今仍在更新。

为什么它重要？

• 它是工业界 H.264 编码画质的标杆。商业编码器评测，几乎都拿 x264 慢速预设当对照组；

• FFmpeg 默认的 libx264 编码后端就是它；

• 几乎所有需要软编 H.264 的开源项目，OBS、HandBrake、ffmpeg.wasm，背后都是它；

• 代码极致优化，x86/ARM 上有大量手写汇编。

技术上，x264 不止是个标杆，更是 H.264 工具链里事实上的参考实现。

顺带提一句：x264 是 GPL 协议，意味着你的产品如果静态链接了 libx264，整个产品也要遵循 GPL 开源。商业项目想闭源用，需要单独从 x264 LLC 购买商业许可。这个许可不便宜，但流程清晰。OpenH264（Cisco 出的）是另一个开源 H.264 编码器，BSD 协议，但画质比 x264 弱不少，主要用在 WebRTC 场景。

获取源码

x264 官方仓库托管在 VideoLAN 的 git 上：

git clone https://code.videolan.org/videolan/x264.git
cd x264

国内拉不下来很正常，可以用 GitHub 的镜像 https://github.com/mirror/x264.git，或者从 ffmpeg 中文网下载源码包。

源码里有几个关键目录你心里要有数：

• common/：核心算法，DCT、运动估计、熵编码这些；

• encoder/：编码器主流程；

• common/x86/、common/aarch64/：各架构的汇编加速代码；

• tools/：x264 命令行工具源码；

• configure：configure 脚本（不是 autoconf 生成的，是手写的 shell 脚本）。

x264 的版本号有点特殊，长这样：0.165.r3211 7ed753b。第一段固定 0，第二段是 ABI 版本号（x264 内部叫 X264_BUILD），每次 ABI 不兼容时递增；第三段是从 git 起算的 commit 数；最后是 commit hash 前缀。看到这种版本号别奇怪，这是 VideoLAN 一贯风格。

依赖项要先理清楚

x264 本体几乎不依赖什么库，但有两个东西强烈推荐装上：

nasm 或 yasm（汇编器）

x264 大量使用手写 SSE/AVX/NEON 汇编，需要 nasm 把汇编源码编成目标文件。没有 nasm，所有汇编加速都不会启用，编出来的 x264 只跑纯 C 代码，速度比开汇编慢 5-10 倍。

新版 x264 推荐用 nasm，老版本用 yasm。装 nasm 2.13+ 就够了。两者的区别是 nasm 对新指令集（AVX-512 之类）支持更全，所以官方现在统一推荐 nasm，把 yasm 标为遗留兼容。

libavformat / libavcodec / libswscale（可选）

这是 FFmpeg 的库。装了之后 x264 命令行可以直接读 mp4、mkv、avi 这些容器作为输入。不装的话 x264 命令只能吃裸 YUV 或 y4m 格式。

如果你只是要编 libx264.a 链到自己的项目，不需要这个。但如果要做 x264.exe 命令行工具能直接转码 mp4，必装。一个间接好处是：configure 阶段会顺便检测到 swscale，命令行支持非 4:2:0 输入的色彩转换。

l-smash（可选）

输出 mp4 容器用的，让 x264 可以直接把编码结果写成 mp4 文件而不只是裸 .264 流。如果不装，可以编完后用 ffmpeg 把 .264 重封装成 mp4，多一步但效果一样。

Linux 编译命令清单

Ubuntu/Debian 系：

# 装依赖
sudo apt update
sudo apt install -ygit build-essential nasm pkg-config

# 可选：装 FFmpeg 开发库（让 x264 支持 mp4 输入）
sudo apt install -y libavformat-dev libavcodec-dev libswscale-dev

# 拉源码
git clone https://code.videolan.org/videolan/x264.git
cd x264

# 配置：同时编静态库和动态库
./configure --enable-shared--enable-static--prefix=/usr/local

# 编译，开 8 线程
make-j8

# 安装到 /usr/local
sudomake install

# 让动态库立刻生效
sudo ldconfig

CentOS/RHEL 系基本一样，把 apt 换成 yum/dnf，nasm 包名一样。

编译完检查：

x264 --version

输出大概是这样：

x264 0.165.r3211 7ed753b
built on Jun 21 2026, gcc: 11.4.0
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later

关键点：看 configuration 那行有没有出现汇编相关字眼。如果你看到 --disable-asm 或者编译过程里看到 nasm: command not found，那汇编没开，回去检查 nasm。

Windows MSYS2 编译命令清单

Windows 编译 x264 推荐用 MSYS2 + MinGW-w64 工具链。不要用 Cygwin，不要用 MSVC（x264 大量 GCC 扩展和汇编语法，MSVC 编不了）。

第一步：装 MSYS2，从 msys2.org 下安装包，一路下一步。

第二步：装工具链（在 MSYS2 MINGW64 终端里）：

pacman -Syu

pacman -S--needed \
git \
    base-devel \
    mingw-w64-x86_64-toolchain \
    mingw-w64-x86_64-nasm \
    mingw-w64-x86_64-pkgconf

# 可选：FFmpeg 库
pacman -S--needed mingw-w64-x86_64-ffmpeg

第三步：configure + make。注意必须在 MINGW64 终端里跑，不是 MSYS 终端：

git clone https://code.videolan.org/videolan/x264.git
cd x264

./configure \
--enable-shared \
--enable-static \
--prefix=/mingw64 \
--host=x86_64-w64-mingw32

make-j8
make install

编译产物会装到 MSYS2 的 /mingw64 目录下，大致是这些文件：

• /mingw64/lib/libx264.a — 静态库

• /mingw64/lib/libx264.dll.a — 动态库的导入库

• /mingw64/bin/libx264-165.dll — 动态库本体（数字是当前 ABI 版本）

• /mingw64/bin/x264.exe — 命令行工具

• /mingw64/include/x264.h、x264_config.h — 头文件

注意一个细节：MSYS2 的 mingw64 prefix 默认就是 /mingw64，所以 --prefix=/mingw64 实际上把库装进了 MSYS2 自己的库目录里，pkg-config 能直接找到。如果你想装到自己的项目目录，把 prefix 改成绝对路径，记得后面用 pkg-config 时设置 PKG_CONFIG_PATH。

Windows 这边最常见的坑：configure 脚本如果检测不到 nasm，会自动 fallback 成 --disable-asm，但只在屏幕上闪一行警告就过去了。然后你编出来一个慢得吓人的 x264，还以为是机器问题。

每次 configure 完，仔细看输出最后那一段总结，必须看到 assembly: yes。

第一条编码命令

x264 装好了，拿一段裸 YUV 试试。

如果你手头没有 YUV 文件，可以用 ffmpeg 现做一段：

ffmpeg -i sample.mp4 -pix_fmt yuv420p -s 1920x1080 -r25 input.yuv

然后开始编码：

x264 --input-res 1920x1080 --fps25-o out.264 input.yuv

参数拆开看：

• --input-res 1920x1080：告诉 x264 这个 YUV 是 1080p 的（裸 YUV 没有头信息，必须手动告诉）；

• --fps 25：帧率 25；

• -o out.264：输出文件名，自动按后缀决定输出格式（这里输出裸 H.264 流）；

• input.yuv：输入 YUV 文件，默认按 YUV420P 解释。

跑完会得到一个 out.264 文件。可以用 ffplay 或者 VLC 直接播。

如果输出 mp4，把 -o out.264 改成 -o out.mp4 就行（前提是编译时带了 l-smash 或者 gpac）。x264 自己就能写 mp4 容器，不需要再用 ffmpeg 封装一次。

configure 几个常用选项要心里有数

x264 的 configure 脚本支持的选项不少，常用的有这么几个：

• --enable-shared：编 .so/.dll 动态库；

• --enable-static：编 .a 静态库（默认就开）；

• --enable-strip：strip 掉调试符号，二进制体积小一半；

• --disable-cli：只编库，不编 x264 命令行（嵌入到 SDK 里常用）；

• --bit-depth=8|10|all：8bit、10bit 或两者都支持，搞 HDR 必须 10 或 all；

• --chroma-format=420|422|444|all：色彩采样格式；

• --enable-pic：生成位置无关代码，给动态库链接用，64 位系统默认开；

• --cross-prefix=...：交叉编译时给的工具链前缀，比如 aarch64-linux-android-；

• --host=...--sysroot=...：交叉编译目标平台和系统根目录。

调试 x264 自身的话，加 --enable-debug 留符号；做性能分析加 --enable-profiling 让 gprof 能用。

交叉编译给安卓/iOS 用

桌面平台的编译说完，简单说一下移动端。这是工程里高频踩坑点。

安卓：用 NDK 提供的 clang 工具链。configure 大致这样：

NDK=/your/path/to/android-ndk-r25
TOOLCHAIN=$NDK/toolchains/llvm/prebuilt/linux-x86_64
TARGET=aarch64-linux-android
API=21

exportCC=$TOOLCHAIN/bin/${TARGET}${API}-clang
exportAR=$TOOLCHAIN/bin/llvm-ar
exportSTRIP=$TOOLCHAIN/bin/llvm-strip

./configure \
--host=$TARGET \
--sysroot=$TOOLCHAIN/sysroot \
--cross-prefix=$TOOLCHAIN/bin/llvm- \
--enable-pic \
--enable-static \
--disable-cli \
--prefix=$(pwd)/install_android_arm64

make-j8 && make install

armv7 把 TARGET 改成 armv7a-linux-androideabi，加上 --extra-cflags=-mfpu=neon 开 NEON。

iOS：configure 时指定 -isysroot、-arch arm64、-mios-version-min=11.0 等 cflags，编出 .a 静态库后丢进 Xcode 工程链接即可。iOS 一般不上动态库，因为 App Store 限制。

两个常见错误：

• 忘了 --enable-pic，链动态库时报 relocation R_X86_64_32 against symbol；

• 忘了 --disable-cli，编译卡在某些命令行依赖（getopt、libavformat 这些移动端没装的库）报错。

编码命令进阶：CRF / preset / tune

实际工程中，光给个分辨率帧率不够，要调画质和速度的平衡。

preset：速度档位

x264 --preset slow ...

可选值从快到慢：ultrafast / superfast / veryfast / faster / fast / medium / slow / slower / veryslow / placebo

档位越慢，画质越好但编码时间越长。medium 是默认。直播一般 veryfast 起步。点播离线转码至少 slow，追求极致画质用 veryslow。placebo 慢得离谱但提升微弱，基本只用来跑评测。

CRF：质量恒定模式

x264 --crf23--preset slow -o out.264 input.yuv

CRF 是基于感知质量的 1-pass 模式，参数范围 0-51，越小画质越好：

• CRF 18：视觉无损，文件大；

• CRF 20-23：高画质，主流点播首选；

• CRF 23：默认值，适合大部分场景；

• CRF 28：低画质，可见明显损失；

• CRF 51：最差。

CRF 之外还有 --bitrate 平均码率模式和 --pass 1/2 二次编码模式。直播用 ABR/CBR，点播用 CRF。

tune：场景调优

x264 --tune film --preset slow ...

可选值：film（电影内容）、animation（动画）、grain（强保留胶片颗粒）、zerolatency（零延迟，关 B 帧）、stillimage、fastdecode、psnr、ssim。

直播必须 --tune zerolatency，关掉 B 帧和 lookahead，端到端延迟从几百毫秒压到一两帧。

几个 preset 的实测感受

我自己在 1080p 25fps 测试视频上跑过对比，仅供参考：

• ultrafast：编码 ~400fps，文件大约 1.6 倍于 medium；

• veryfast：~200fps，文件 1.15 倍；

• medium（默认）：~80fps，作为基准 1.0；

• slow：~40fps，文件 0.92 倍；

• veryslow：~8fps，文件 0.85 倍。

可以看到，从 medium 到 veryslow，速度慢了 10 倍，文件只小 15%。这就是边际收益递减。所以工程上 slow 是性价比最高的档位，veryslow 适合归档场景，placebo 几乎没人真用。

C++ 实战一：CMake 链接 x264

最小化的 CMake 工程，调用 x264 编一帧 YUV。

CMakeLists.txt：

cmake_minimum_required(VERSION 3.10)
project(x264_demo CXX)

set(CMAKE_CXX_STANDARD 17)

# 找 x264：用 pkg-config 是最稳的方式
find_package(PkgConfig REQUIRED)
pkg_check_modules(X264 REQUIRED x264)

add_executable(x264_demo main.cpp)
target_include_directories(x264_demo PRIVATE ${X264_INCLUDE_DIRS})
target_link_directories(x264_demo PRIVATE ${X264_LIBRARY_DIRS})
# 注意链接顺序：x264 必须放在依赖它的目标后面
target_link_libraries(x264_demo PRIVATE ${X264_LIBRARIES})

main.cpp：

#include <x264.h>
#include <stdio.h>
#include <string.h>

intmain() {
x264_param_tparam;
x264_param_default_preset(&param, "medium", nullptr);
param.i_csp=X264_CSP_I420;
param.i_width=640;
param.i_height=480;
param.i_fps_num=30;
param.i_fps_den=1;
param.i_keyint_max=60;        // 每 60 帧一个 IDR
param.b_annexb=1;
x264_param_apply_profile(&param, "high");

x264_t*enc=x264_encoder_open(&param);
if (!enc) return-1;

x264_picture_tpic_in, pic_out;
x264_picture_alloc(&pic_in, X264_CSP_I420, 640, 480);

// 一段彩条画面：Y 渐变，U/V 灰
for (inty=0; y<480; ++y)
for (intx=0; x<640; ++x)
pic_in.img.plane[0][y*pic_in.img.i_stride[0] +x] = (x+y) &0xff;
memset(pic_in.img.plane[1], 128, 640*480/4);
memset(pic_in.img.plane[2], 128, 640*480/4);

pic_in.i_pts=0;
x264_nal_t*nals=nullptr;
intnal_count=0;
intsize=x264_encoder_encode(enc, &nals, &nal_count, &pic_in, &pic_out);
printf("encoded one frame, total bytes=%d, NAL count=%d\n", size, nal_count);

x264_picture_clean(&pic_in);
x264_encoder_close(enc);
return0;
}

编译运行：

mkdir build && cd build
cmake .. && make
./x264_demo

C++ 实战二：封装一个 X264Encoder 类

实战项目里你不会到处散调 x264 API，会封装一层。封装的好处是：调用方代码干净、错误处理集中、参数变更不影响业务、单元测试好写。给个干净的最小实现：

// x264_encoder.h
#pragma once
#include <x264.h>
#include <stdint.h>
#include <vector>
#include <functional>

classX264Encoder {
public:
structConfig {
intwidth=1280;
intheight=720;
intfps=25;
intbitrate_kbps=2000;     // 目标码率，0 表示走 CRF
intcrf=23;                // bitrate=0 时使用
intgop=50;                // I 帧间隔
constchar*preset="veryfast";
constchar*tune="zerolatency";
constchar*profile="main";
    };

usingOutputCallback=std::function<void(constuint8_t*data, intsize, boolis_key)>;

X264Encoder() =default;
~X264Encoder() { close(); }

boolinit(constConfig&cfg, OutputCallbackcb) {
cb_=std::move(cb);
cfg_=cfg;

x264_param_tp;
if (x264_param_default_preset(&p, cfg.preset, cfg.tune) <0) returnfalse;

p.i_csp=X264_CSP_I420;
p.i_width=cfg.width;
p.i_height=cfg.height;
p.i_fps_num=cfg.fps;
p.i_fps_den=1;
p.i_keyint_max=cfg.gop;
p.b_annexb=1;
p.b_repeat_headers=1;       // 每 IDR 前重发 SPS/PPS
if (cfg.bitrate_kbps>0) {
p.rc.i_rc_method=X264_RC_ABR;
p.rc.i_bitrate=cfg.bitrate_kbps;
p.rc.i_vbv_max_bitrate=cfg.bitrate_kbps*2;
p.rc.i_vbv_buffer_size=cfg.bitrate_kbps;
        } else {
p.rc.i_rc_method=X264_RC_CRF;
p.rc.f_rf_constant= (float)cfg.crf;
        }
if (x264_param_apply_profile(&p, cfg.profile) <0) returnfalse;

enc_=x264_encoder_open(&p);
if (!enc_) returnfalse;

if (x264_picture_alloc(&pic_in_, X264_CSP_I420, cfg.width, cfg.height) <0) {
x264_encoder_close(enc_);
enc_=nullptr;
returnfalse;
        }
pts_=0;
returntrue;
    }

// 输入一帧 YUV420P。y/u/v 为三平面指针，stride 为 Y 平面行步长（U/V 默认 stride/2）
boolencode(constuint8_t*y, constuint8_t*u, constuint8_t*v, intstride_y) {
if (!enc_) returnfalse;

// 拷贝到 x264 的图像 buffer（也可以直接让 plane 指向外部内存避免拷贝）
for (introw=0; row<cfg_.height; ++row)
memcpy(pic_in_.img.plane[0] +row*pic_in_.img.i_stride[0],
y+row*stride_y, cfg_.width);
for (introw=0; row<cfg_.height/2; ++row) {
memcpy(pic_in_.img.plane[1] +row*pic_in_.img.i_stride[1],
u+row* (stride_y/2), cfg_.width/2);
memcpy(pic_in_.img.plane[2] +row*pic_in_.img.i_stride[2],
v+row* (stride_y/2), cfg_.width/2);
        }
pic_in_.i_pts=pts_++;

x264_nal_t*nals=nullptr;
intnal_count=0;
x264_picture_tpic_out;
intsize=x264_encoder_encode(enc_, &nals, &nal_count, &pic_in_, &pic_out);
if (size<0) returnfalse;

if (size>0&&cb_) {
boolis_key= (pic_out.b_keyframe!=0);
// 把所有 NAL 串起来回调出去（Annex B 已经带起始码）
cb_(nals[0].p_payload, size, is_key);
        }
returntrue;
    }

voidclose() {
if (enc_) {
// flush 缓冲帧
x264_nal_t*nals;
intnal_count;
x264_picture_tpic_out;
while (x264_encoder_delayed_frames(enc_) >0) {
intsize=x264_encoder_encode(enc_, &nals, &nal_count, nullptr, &pic_out);
if (size>0&&cb_)
cb_(nals[0].p_payload, size, pic_out.b_keyframe!=0);
            }
x264_picture_clean(&pic_in_);
x264_encoder_close(enc_);
enc_=nullptr;
        }
    }

private:
x264_t*enc_=nullptr;
x264_picture_tpic_in_{};
Configcfg_{};
OutputCallbackcb_;
int64_tpts_=0;
};

调用方式就很清爽了：

X264Encoderenc;
X264Encoder::Configcfg;
cfg.width=1280; cfg.height=720; cfg.fps=25;
cfg.bitrate_kbps=1500;
enc.init(cfg, [](constuint8_t*data, intsize, boolis_key) {
// 写文件 / 推 RTMP / 塞队列
fwrite(data, 1, size, stdout);
});

while (read_yuv_frame(y, u, v)) {
enc.encode(y, u, v, 1280);
}
enc.close();

加错误日志、加多路并发、加动态码率调整，都在这个骨架上扩。

工程上还有几个常见扩展点：

• 动态调整码率：直播场景根据网络反馈调整目标码率，调用 x264_encoder_reconfig 不需要重启编码器；

• 强制 IDR：网络重连或者关键帧请求时，把下一帧的 i_type 设为 X264_TYPE_IDR，强制插入 IDR；

• 零拷贝输入：把 pic_in.img.plane[] 直接指向外部内存而不拷贝，对于摄像头直采或 GPU 输出的 YUV 能省一次大块内存复制；

• 多线程编码池：高分辨率高帧率场景，单实例 x264 在 lookahead 上是瓶颈，多实例并行可以拉吞吐。

几个真实踩过的坑

坑一：Windows 编译没开 asm，速度差 5-10 倍

最经典的坑。MSYS2 装的时候忘装 nasm，或者装了但没在 MINGW64 终端里跑 configure，结果 asm 自动 disable。编出来一个慢得离谱的 x264 还以为是机器问题。每次 configure 都要看输出确认 asm: yes。

坑二：链接顺序错了

GCC/Clang 的链接器是从左到右扫的，符号要在被引用之前找到。x264 依赖 pthread、m（数学库），所以要写 -lx264 -lpthread -lm，反过来就报 undefined reference。CMake 用 PkgConfig 一般会自动处理，但手写 g++ 命令的时候经常翻车。

坑三：版本号 ABI 不一致

x264 的动态库文件名带版本号，比如 libx264-165.dll。你升级了 x264 但忘记重新编自己的程序，跑起来报 entry point not found 或者 dll 找不到。x264 没有 SONAME 兼容承诺，每次升级最好都重新编一遍依赖它的程序。

坑四：直接用发行版的 libx264 太老

Ubuntu 22.04 仓库里的 libx264 还停在 0.163，新的 10-bit、HDR 相关的 API 不全。生产环境推荐自己编最新版，固定一个版本号长期用。

坑五：configure 跨行写 \ 末尾有空格

shell 脚本里反斜杠续行符后面如果不小心加了空格，整行 configure 就被截断成默认参数。这种错误肉眼看不出来。建议每次 configure 完都看一眼最后输出的总结。

坑六：CRF 和 ABR 模式混着用

直播一般是恒定码率（CBR）或平均码率（ABR），保证带宽稳定。点播一般是 CRF，画质恒定。如果你直播用了 CRF，码率会随画面复杂度剧烈波动，简单画面 500kbps，复杂画面 8Mbps，CDN 和播放器都受不了。反过来点播用 CBR 也不合适，简单画面浪费码率，复杂画面又不够清晰。

坑七：开了线程数过多反而变慢

x264 默认会用 min(cpu_count * 1.5, 16) 个线程。但如果你机器同时跑多个编码进程，每个都开十几个线程，线程切换开销反而拖累整体吞吐。批量转码场景，每个进程的线程数手动限制到 4-8 比较合理，命令行用 --threads N，API 里设 param.i_threads = N。

坑八：码率控制和 GOP 长度配合不当

CBR 模式下，如果 GOP 设得太大（比如 10 秒），码率控制器为了维持 CBR，I 帧那一刻会被强行压缩得很狠，画质明显下降。一般直播 GOP 控制在 1-2 秒比较合理，既能秒开又能保证 I 帧画质。点播或归档可以放大到 5-10 秒，CRF 模式下没什么副作用。

小结

x264 编译这件事，在不熟的人眼里是一道槛，熟了之后只是输入几行命令的事。

但「自己能编」和「只会用包管理器装」，是工程能力的一道分水岭。前者出问题能查、能改、能定制；后者只能等着升级。我见过太多人卡在「为什么我这台机器编出来的就是慢」的玄学问题上，最后查清楚原因都是一些可笑的细节：nasm 没装、链接到了系统老版本、cflags 没传到子目录之类。

更重要的是，自己编一遍 x264 你才会真正理解：为什么 nasm 这么重要、为什么 preset 慢的那么慢、为什么不同 profile 编出来的码流大小差这么多。这些直觉是用包管理装出来的人体会不到的。

实际项目里我自己的做法是这样：

• 把 x264 源码作为 git submodule 集成进自己的项目，pin 一个具体 commit；

• 写一个一键脚本，一次编出 Linux x86_64、Android arm64-v8a、Android armeabi-v7a、iOS arm64 四份静态库；

• libx264.a 直接放进项目仓库，不依赖系统包；

• CI 里跑编码 smoke test，验证版本升级不会破坏现有码流。

这样不管换什么机器、什么版本的工具链，编码行为都是稳的。

下一篇我会讲 H.264 的码流结构：NALU 是什么、SPS/PPS 怎么解、Annex B 和 AVCC 到底怎么转换。这些是做封装、推流、转码绕不开的基础。

如果觉得有用，欢迎转发给身边搞音视频的朋友。有问题可以在评论区留言，我会及时回复。