本文还有配套的精品资源，点击获取

简介：FFmpeg是一个功能强大的开源多媒体处理框架，支持音视频编解码、格式转换、滤镜处理、流媒体操作等核心功能。本资源提供专为Android平台编译的FFmpeg 2.0.1静态库，便于开发者在移动端快速集成音视频处理能力。通过NDK交叉编译、JNI接口调用及库文件集成，开发者可在Android应用中实现播放、录制、转码、裁剪等多种多媒体功能。尽管版本较旧，但仍适用于学习FFmpeg在Android上的基本架构与集成流程，是掌握移动多媒体开发的重要实践基础。

1. FFmpeg项目简介与核心组件

FFmpeg作为音视频处理领域的基石级开源框架，自2000年由Fabrice Bellard发起以来，已发展为支持数百种格式与协议的跨平台工具集。其架构采用模块化设计，通过七大核心库实现功能解耦： libavcodec 负责编解码核心， libavformat 处理封装与解析， libavfilter 提供滤镜处理能力， libavutil 包含通用工具函数， libswscale 实现图像缩放与色彩空间转换， libswresample 处理音频重采样，而 libavdevice 支持音视频设备输入输出。各库通过统一的数据结构（如 AVFormatContext 、 AVFrame ）协同工作，构成完整的多媒体处理流水线，为Android平台上的定制化音视频引擎开发提供强大支撑。

2. libavcodec编码解码库应用

libavcodec 是 FFmpeg 项目中最为核心的组件之一，承担着音视频数据的编解码任务。它不仅支持上百种音频和视频编码格式（如 H.264、H.265、VP9、AAC、MP3 等），还提供了高度可扩展的插件式架构，允许开发者通过注册机制动态加载编解码器。在 Android 平台进行多媒体开发时，掌握 libavcodec 的使用方式与底层原理，是实现高效、稳定音视频处理的关键所在。

本章将深入剖析 libavcodec 的内部工作机制，从编解码器的注册查找机制开始，逐步展开到 AVCodecContext 配置模型、帧包结构解析，并结合实际应用场景，分别演示视频与音频的解码流程、硬件加速集成策略、错误恢复机制以及性能优化手段。通过对这些模块的系统学习，开发者不仅能理解如何正确调用 FFmpeg 的 API 实现功能需求，更能具备调试复杂问题、优化资源占用和提升用户体验的能力。

2.1 libavcodec核心机制解析

libavcodec 的设计遵循“面向接口”和“松耦合”的原则，其核心机制围绕编解码器管理、上下文配置和数据流控制三大支柱构建。这一节将从最基础的编解码器注册与查找机制入手，深入分析 AVCodecContext 的作用模型，并详细解读 AVFrame 与 AVPacket 这两个贯穿整个音视频流水线的核心数据结构。

2.1.1 编解码器注册与查找机制

FFmpeg 在启动时会自动完成所有内置编解码器的注册工作，这一过程由全局初始化函数 av_register_all() 或更细粒度的 avcodec_register_all() 触发。虽然现代版本推荐直接调用具体解码器获取函数而不强制显式注册，但理解其背后的注册机制对于定制化编译或动态扩展至关重要。

编解码器在 FFmpeg 中以链表形式组织，每个编解码器对应一个 AVCodec 结构体实例，包含名称、ID、类型（音频/视频/字幕）、支持的像素格式或采样率等信息。当用户请求某个特定格式的解码能力时，FFmpeg 提供了 avcodec_find_decoder() 和 avcodec_find_encoder() 接口来按 ID 查找对应的编解码器。

// 示例：查找 H.264 软件解码器
AVCodec *codec = avcodec_find_decoder(AV_CODEC_ID_H264);
if (!codec) {
    fprintf(stderr, "H.264 decoder not found!\n");
    return -1;
}

上述代码通过标准枚举值 AV_CODEC_ID_H264 查找匹配的解码器指针。若返回 NULL，则说明当前编译环境中未启用该解码器（可能因 configure 阶段禁用了 --disable-decoder=h264 ）。此查找过程时间复杂度为 O(n)，但由于编解码器总数有限，实际开销可忽略。

为了提高查找效率，FFmpeg 内部维护了一个哈希映射表，在注册阶段填充索引。此外，开发者也可以手动注册自定义编解码器：

avcodec_register(&my_custom_codec);

这种方式适用于嵌入专有算法或实验性编码标准的场景。

编解码器属性	描述说明
name	编解码器短名称（如 “h264”）
type	媒体类型（ AVMEDIA_TYPE_VIDEO , AUDIO 等）
id	枚举唯一标识符（ AV_CODEC_ID_H264 ）
capabilities	支持特性标志位（如 AV_CODEC_CAP_HARDWARE , DELAY ）
supported_framerates	支持的帧率列表（视频专用）

以下 mermaid 流程图展示了编解码器查找的整体流程：

graph TD
    A[调用 avcodec_find_decoder()] --> B{是否已初始化编解码器链表?}
    B -- 否 --> C[执行 avcodec_register_all()]
    B -- 是 --> D[遍历已注册编解码器链表]
    D --> E[比较 codec_id 是否匹配]
    E -- 匹配成功 --> F[返回 AVCodec 指针]
    E -- 无匹配项 --> G[返回 NULL]

该机制体现了 FFmpeg 对扩展性的重视——只要符合 AVCodec 接口规范，任何第三方实现都可以无缝接入主框架。同时，这种静态注册+运行时查找的设计模式也保证了良好的性能与稳定性。

2.1.2 AVCodecContext与参数配置模型

AVCodecContext 是 libavcodec 中最关键的上下文结构体，用于存储编解码过程中的全部状态信息和配置参数。它是连接 AVCodec 与实际输入输出数据之间的桥梁，必须在打开编解码器前充分配置。

创建上下文的方式如下：

AVCodec *codec = avcodec_find_decoder(AV_CODEC_ID_H264);
AVCodecContext *ctx = avcodec_alloc_context3(codec);
if (!ctx) {
    fprintf(stderr, "Could not allocate video codec context\n");
    return -1;
}

avcodec_alloc_context3() 不仅分配内存，还会根据所选编解码器设置默认参数。关键字段包括：

• width / height : 视频分辨率
• pix_fmt : 像素格式（如 AV_PIX_FMT_YUV420P ）
• sample_rate / channels : 音频采样率与声道数
• time_base : 时间基，决定时间戳单位
• extradata / extradata_size : 编码特有数据（如 SPS/PPS）

对于从容器中读取的流信息，通常使用 avcodec_parameters_to_context() 函数自动填充：

// 假设 st 是 AVStream*
avcodec_parameters_to_context(ctx, st->codecpar);

这极大简化了手动赋值的繁琐操作，并确保参数一致性。

下表列出常用配置项及其意义：

参数字段	典型值示例	功能说明
thread_count	4	设置多线程解码线程数
refcounted_frames	1	启用引用计数帧，避免深拷贝
skip_frame	AVDISCARD_DEFAULT	控制跳过非关键帧以提升性能
workaround_bugs	FF_BUG_AUTODETECT	兼容损坏流的修复策略
err_recognition	AV_EF_EXPLODE	错误识别级别

完成配置后，需调用 avcodec_open2() 打开编解码器：

int ret = avcodec_open2(ctx, codec, NULL);
if (ret < 0) {
    char errbuf[128];
    av_strerror(ret, errbuf, sizeof(errbuf));
    fprintf(stderr, "Could not open codec: %s\n", errbuf);
    return -1;
}

此函数会验证参数合法性，并初始化内部缓冲区、熵解码器、运动补偿模块等子系统。一旦打开成功，即可进入解码循环。

值得注意的是， AVCodecContext 是非线程安全的，多个线程不能共享同一上下文实例。若需并发处理多路流，应为每路流独立分配上下文。

2.1.3 帧（AVFrame）与包（AVPacket）数据结构详解

在 libavcodec 的数据流动模型中， AVPacket 和 AVFrame 分别代表压缩数据与原始数据的基本单元，二者构成了解码流水线的核心载体。

AVPacket：压缩数据容器

AVPacket 封装了一段经过编码的原始字节流（bitstream），不含封装头信息。其主要字段包括：

• data : 指向压缩数据起始地址
• size : 数据长度（字节）
• pts : 显示时间戳（Presentation Time Stamp）
• dts : 解码时间戳（Decoding Time Stamp）
• stream_index : 所属流索引
• duration : 数据持续时间（以 time_base 为单位）

典型用法如下：

AVPacket *pkt = av_packet_alloc();
while (av_read_frame(fmt_ctx, pkt) >= 0) {
    if (pkt->stream_index == video_stream_idx) {
        int send_ret = avcodec_send_packet(dec_ctx, pkt);
        // 处理接收帧...
    }
    av_packet_unref(pkt); // 重置 packet 以便复用
}
av_packet_free(&pkt);

每次调用 av_read_frame() 获取一个 packet 后，需传递给 avcodec_send_packet() 进行解码。注意： AVPacket 不拥有数据所有权，除非调用 av_packet_ref() 创建引用副本。

AVFrame：解码后的原始媒体帧

AVFrame 存储解码后的原始数据，对视频而言是 YUV 或 RGB 像素阵列；对音频则是 PCM 样本数组。重要成员包括：

• data[0..7] : 平面数据指针（Y/U/V 或 L/R）
• linesize[0..7] : 每行字节数（考虑内存对齐）
• format : 像素格式或采样格式
• width / height : 图像尺寸（视频）
• nb_samples : 每帧样本数（音频）
• pts : 显示时间戳

解码后获取帧的代码片段：

AVFrame *frame = av_frame_alloc();
int recv_ret;
while ((recv_ret = avcodec_receive_frame(dec_ctx, frame)) == 0) {
    // 此处 frame 已包含有效图像或音频数据
    process_decoded_frame(frame);
    av_frame_unref(frame); // 释放引用，准备下一次接收
}
if (recv_ret == AVERROR(EAGAIN)) {
    // 需要更多 packet 输入
} else if (recv_ret == AVERROR_EOF) {
    // 解码结束
}

AVFrame 支持引用计数（reference-counting），允许多个上下文共享同一帧数据而无需复制，这对性能敏感的应用尤为重要。

下面是一个对比表格，清晰展示两者的差异：

特性	AVPacket	AVFrame
数据类型	压缩码流（encoded）	原始数据（decoded）
主要用途	输入到解码器	输出自解码器
时间戳	pts/dts	pts
内存管理	可 ref/unref	支持引用计数
多平面支持	否	是（data[0], data[1]…）
典型生命周期	从 demuxer 到 decoder	从 decoder 到 filter/renderer

两者之间的转换关系可通过如下流程图表示：

graph LR
    Demuxer -->|输出 AVPacket| Decoder[avcodec_send_packet]
    Decoder -->|输入 AVPacket| CodecEngine((解码引擎))
    CodecEngine -->|输出 AVFrame| avcodec_receive_frame
    avcodec_receive_frame -->|返回 AVFrame| PostProcess[后处理模块]

在整个音视频处理链中， AVPacket 与 AVFrame 的高效流转决定了系统的吞吐能力和延迟表现。合理利用 av_frame_pool 和 AVBufferRef 机制，可以进一步减少内存分配次数，提升整体性能。

2.2 视频编解码实战流程

视频编解码是移动多媒体应用中最常见的需求之一，尤其在播放、录制、转码等场景中占据核心地位。本节将以 H.264/H.265 为例，完整演示从初始化到解码输出的全流程，并探讨如何集成 Android 硬件加速接口（MediaCodec）以提升效率。

2.2.1 H.264/H.265解码流程实现步骤

实现软件解码的基本流程可分为五个阶段：初始化、送包、接收帧、处理帧、清理资源。

以下是完整的 H.264 解码示例代码：

// 初始化部分
AVFormatContext *fmt_ctx = NULL;
AVCodecContext *dec_ctx = NULL;
AVPacket *pkt = av_packet_alloc();
AVFrame *frame = av_frame_alloc();
int video_stream_index = -1;

avformat_open_input(&fmt_ctx, "input.h264", NULL, NULL);
avformat_find_stream_info(fmt_ctx, NULL);

for (int i = 0; i < fmt_ctx->nb_streams; i++) {
    if (fmt_ctx->streams[i]->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
        video_stream_index = i;
        break;
    }
}

AVCodec *codec = avcodec_find_decoder(fmt_ctx->streams[video_stream_index]->codecpar->codec_id);
dec_ctx = avcodec_alloc_context3(codec);
avcodec_parameters_to_context(dec_ctx, fmt_ctx->streams[video_stream_index]->codecpar);
avcodec_open2(dec_ctx, codec, NULL);

// 解码循环
while (av_read_frame(fmt_ctx, pkt) >= 0) {
    if (pkt->stream_index == video_stream_index) {
        avcodec_send_packet(dec_ctx, pkt);
        while (avcodec_receive_frame(dec_ctx, frame) == 0) {
            // 将 YUV 数据渲染至 SurfaceView 或转换为 RGB
            render_yuv_frame(frame);
        }
    }
    av_packet_unref(pkt);
}

// 清理
av_frame_free(&frame);
av_packet_free(&pkt);
avcodec_free_context(&dec_ctx);
avformat_close_input(&fmt_ctx);

逐行逻辑分析：

• avformat_open_input() ：打开输入文件并初始化格式上下文。
• avformat_find_stream_info() ：读取若干 packet 以探测流参数（宽高、编码格式等）。
• 循环查找第一个视频流索引。
• avcodec_find_decoder() ：根据流中的 codec_id 查找对应解码器。
• avcodec_parameters_to_context() ：将流参数复制到解码上下文中。
• avcodec_open2() ：激活解码器，准备解码环境。
• 主循环中 av_read_frame() 逐个读取 packet。
• avcodec_send_packet() 将 packet 推入解码器队列。
• avcodec_receive_frame() 尝试取出解码结果；由于 B 帧存在依赖关系，可能需要多次 send 才能 receive 一帧。
• 最终释放所有资源。

此流程适用于 Annex-B 格式的裸流或 MP4 容器内的 H.264/H.265 数据。

2.2.2 使用硬件加速解码接口（如MediaCodec集成）

在 Android 上，纯软件解码（如 libx264/libx265）容易导致 CPU 占用过高，影响续航与流畅度。因此，应优先使用硬件加速解码，即通过 MediaCodec 结合 libavcodec 的 VA-API 或 OMX 接口。

FFmpeg 支持通过 hwaccel 机制绑定硬件上下文。以 mediacodec backend 为例：

// 查找支持 mediacodec 的解码器
AVCodec *hw_codec = avcodec_find_decoder_by_name("h264_mediacodec");

// 或自动探测硬件加速能力
const AVHWDeviceType hw_type = av_hwdevice_find_type_by_name("mediacodec");
if (hw_type != AV_HWDEVICE_TYPE_NONE) {
    AVBufferRef *hw_device_ctx = NULL;
    av_hwdevice_ctx_create(&hw_device_ctx, hw_type, NULL, NULL, 0);
    dec_ctx->hw_device_ctx = av_buffer_ref(hw_device_ctx);
}

随后在 avcodec_open2() 时，FFmpeg 会自动选择硬件路径。

优势在于：
- 显著降低 CPU 占用（可降至 10% 以下）
- 提升高分辨率（1080p/4K）解码稳定性
- 延长设备电池寿命

限制：
- 设备兼容性差异大（不同厂商实现不一致）
- 初始化延迟较高
- 不支持所有编码 profile

建议采用 fallback 机制：先尝试硬件解码，失败则回退至软件。

2.2.3 错误处理与解码异常恢复策略

音视频流常因网络中断、文件损坏等原因出现错误。良好的错误处理机制能防止程序崩溃并提升用户体验。

常见错误码：
- AVERROR_INVALIDDATA : 数据损坏
- AVERROR(EAGAIN) : 需要更多输入
- AVERROR_EOF : 流结束

恢复策略包括：
- 跳过错误 packet： av_packet_rescale_ts() 调整时间戳连续性
- 清空解码器缓冲： avcodec_flush_buffers(dec_ctx)
- 重新同步 I 帧：等待下一个关键帧再继续解码

例如：

if (avcodec_send_packet(dec_ctx, pkt) < 0) {
    fprintf(stderr, "Error sending packet for decoding\n");
    avcodec_flush_buffers(dec_ctx); // 清除内部状态
    continue;
}

配合 AVDictionary 设置选项 "err_detect", "ignore_err" 可忽略轻微错误。

综上， libavcodec 提供了强大而灵活的视频编解码能力，结合硬件加速与健壮的错误处理机制，可在移动端实现高性能、低功耗的音视频处理解决方案。

3. libavformat容器格式解析与生成

在现代音视频处理系统中，容器（Container）是组织和封装音视频数据流的核心结构。它不仅承载着编码后的音视频帧，还包含时间戳、元数据、同步信息以及可能的字幕、章节等附加内容。FFmpeg中的 libavformat 库正是负责实现这一层抽象的关键组件——它提供了统一的接口来读取（demuxing）和写入（muxing）各种常见的多媒体封装格式，如 MP4、MKV、FLV 和 TS 等。该库的设计目标是解耦底层数据源与上层编解码逻辑，使得开发者可以专注于业务流程而非协议细节。

libavformat 的核心思想在于“协议无关”和“格式可插拔”。通过 AVFormatContext 上下文对象，它可以自动探测输入流类型，并动态选择合适的 demuxer 或 muxer 插件进行处理。这种模块化设计极大地提升了系统的灵活性与扩展性，尤其适用于需要支持多种输入输出场景的移动应用或嵌入式设备。更重要的是，在 Android 平台开发中，由于文件访问权限、网络稳定性及硬件资源受限等问题突出，合理使用 libavformat 不仅能提升兼容性，还能优化性能表现。

本章将深入剖析 libavformat 的工作机制，从封装理论出发，逐步展开对输入源解析、流信息提取、时间基准管理、输出封装流程等内容的讲解，并结合实际代码示例展示如何构建完整的音视频转封装管道。同时，针对移动端特有的跨平台问题，如路径处理、权限控制和网络超时机制，也将提供具体的解决方案与最佳实践建议。

3.1 容器封装理论基础

多媒体容器的本质是一种复合型数据结构，用于组织多个独立但相互关联的数据流（stream），并维护它们之间的时间关系与元数据描述。一个典型的多媒体文件（例如 .mp4 或 .mkv ）并非简单地存储压缩后的视频帧序列，而是由若干逻辑单元组成：包括头部信息（Header）、索引表（Index）、音视频流数据块（Payload）、时间戳（PTS/DTS）、元数据标签（Metadata）以及可能存在的字幕、菜单或章节信息。这些元素共同构成了用户所感知的“完整媒体体验”。

3.1.1 封装格式的基本组成：流、时间基、元数据

在 FFmpeg 中，每一个输入或输出文件都被抽象为一个 AVFormatContext 结构体实例，其中包含了所有关于该容器的信息。其主要组成部分如下：

• AVStream 数组 ：表示容器中包含的一个或多个媒体流（音频、视频、字幕等）。每个 AVStream 包含该流的编解码参数（ AVCodecParameters ）、时间基（ time_base ）、持续时间（duration）和索引位置。
• 时间基（Time Base） ：即时间单位，通常以分数形式表示（如 1/1000 表示毫秒）。它是将内部时间计数转换为真实时间（秒）的基础。不同流可能有不同的时间基，需通过 av_rescale_q() 函数进行换算。
• 元数据（Metadata） ：以键值对形式存储的附加信息，如标题、作者、创建时间、版权信息等，可通过 av_dict_get() 访问。

以下表格展示了常见封装格式的基本结构特征对比：

格式	扩展名	支持流类型	是否支持流式传输	时间索引方式	典型应用场景
MP4	.mp4	音频、视频、字幕	是（fMP4）	moov atom + stts box	移动播放、HLS 分片
MKV	.mkv	多音轨、多字幕、章节	是	Cluster + Timecode	高清本地播放
FLV	.flv	音频、视频	是	时间戳数组	RTMP 推流回放
TS	.ts	多节目节拍（MPEG-TS）	是	PCR 时间戳	IPTV、直播分发

说明 ：MP4 使用 moov 原子盒存储元数据，若位于文件末尾会导致无法边写边播；而 fragmented MP4（fMP4）通过分片方式解决此问题，广泛应用于 DASH 和 HLS 流媒体。

// 示例：遍历 AVFormatContext 中的所有流并打印基本信息
void print_stream_info(AVFormatContext *fmt_ctx) {
    for (int i = 0; i < fmt_ctx->nb_streams; i++) {
        AVStream *stream = fmt_ctx->streams[i];
        AVCodecParameters *codecpar = stream->codecpar;

        const char *type = av_get_media_type_string(codecpar->codec_type);
        AVRational tb = stream->time_base;

        printf("Stream #%d: Type=%s, Codec=%s, "
               "TimeBase=%d/%d (%.6f sec), Duration=%.2f sec\n",
               i, type,
               avcodec_get_name(codecpar->codec_id),
               tb.num, tb.den, av_q2d(tb),
               stream->duration * av_q2d(tb));
    }
}

代码逻辑逐行分析 ：
- 第 3 行：循环遍历 fmt_ctx->nb_streams 指定数量的媒体流；
- 第 5 行：获取当前流指针 AVStream* ；
- 第 6 行：提取编解码参数副本（避免直接操作 codec）；
- 第 8 行：调用 av_get_media_type_string() 将枚举值转为字符串输出；
- 第 9 行： avcodec_get_name() 获取编解码器名称（如 h264、aac）；
- 第 10–12 行：打印时间基数值及其对应的浮点时间精度；
- 第 13 行：利用 stream->duration 和 time_base 转换为实际播放时长。

该函数可用于调试阶段快速验证输入文件结构是否符合预期。

3.1.2 demuxing与muxing的工作原理对比

Demuxing（解封装）是指从容器中分离出各个独立的编码流（encoded packets），而 Muxing（封装）则是将已编码的音视频包重新打包成特定格式的输出文件或流。两者共享相同的上下文模型（ AVFormatContext ），但在方向和生命周期上存在显著差异。

Demuxing 工作流程图（Mermaid）

graph TD
    A[打开输入文件] --> B[分配AVFormatContext]
    B --> C[调用avformat_open_input()]
    C --> D[执行avformat_find_stream_info()]
    D --> E[读取AVPacket循环]
    E --> F{是否为关键帧?}
    F -->|是| G[送入解码器]
    F -->|否| G
    G --> H[解码为AVFrame]
    H --> I[渲染/播放]
    E --> J[EOF?]
    J -->|否| E
    J -->|是| K[释放资源]

说明 ：此流程图展示了标准的解封装+解码流水线。 av_read_frame() 是核心 API，用于逐个读取容器中的 packet。

Muxing 工作流程图（Mermaid）

graph LR
    P[初始化输出格式上下文] --> Q[创建AVStream并设置编码参数]
    Q --> R[写入文件头avformat_write_header()]
    R --> S[循环写入编码后AVPacket]
    S --> T[调用av_interleaved_write_frame()]
    T --> U{还有帧?}
    U -->|是| S
    U -->|否| V[写入尾部av_write_trailer()]
    V --> W[释放资源]

说明 ：muxing 过程强调顺序性和完整性。必须先写 header，再交错写入音视频帧（interleaved），最后写 trailer 以确保索引正确。

二者最根本的区别在于数据流向和状态管理：
- Demuxer 主动从源读取数据，依赖于 AVInputFormat 实现；
- Muxer 被动接收来自编码器的 packet，依赖于 AVOutputFormat 实现；
- 两者均可支持本地文件、内存缓冲区或网络流（通过自定义 IO 协议）。

3.1.3 常见格式分析：MP4、MKV、FLV、TS结构特点

为了更好地理解不同封装格式的技术差异，下面分别对其内部结构进行简要剖析。

MP4（ISO Base Media File Format）

基于 Atom（Box）结构，所有数据以嵌套盒子形式组织。关键 Box 包括：
- ftyp : 文件类型标识；
- moov : Movie Header，包含元数据和索引；
- mdat : 媒体数据主体；
- free , skip : 空白填充；
- moof + mdat : fMP4 分片结构，支持流式上传。

优势：广泛兼容，适合移动端播放；
劣势：传统 MP4 必须在文件结尾写 moov ，导致不能实时生成完整文件。

MKV（Matroska）

采用 EBML（Extensible Binary Meta Language）编码，具有高度灵活性：
- 支持无限音轨、字幕轨道；
- 可嵌入字体、章节标记；
- 自描述性强，易于扩展；
- 支持无损重 mux。

优势：适合高清蓝光备份、多语言影片；
劣势：部分老旧设备不支持。

FLV（Flash Video）

结构极简，头部仅 9 字节，后接一系列 Tag：
- Audio Tag（ID=8）
- Video Tag（ID=9）
- Script Tag（ID=18，含 metadata）

每个 Tag 包含时间戳（3 字节）、数据大小、stream ID 等。非常适合 RTMP 推流场景。

优势：低开销，适合直播推流；
劣势：已被 Adobe 弃用，安全性较低。

TS（Transport Stream）

固定 188 字节包长度，专为抗误码设计：
- 每个 TS 包含 PID（Packet Identifier）字段，用于区分节目流；
- PCR（Program Clock Reference）提供精确时间基准；
- 支持多路复用（multiplexing）多个节目。

优势：高容错，适合广播级传输；
劣势：封装开销大（每包 4 字节头部），效率低于 MP4。

特性	MP4	MKV	FLV	TS
包大小	可变	可变	可变	固定 188B
时间同步精度	高	高	中	极高（PCR）
流式支持	fMP4 支持	是	是	是
多音轨支持	有限	完全支持	否	多节目支持
典型用途	点播	本地高清	直播回放	IPTV / DVB

综上所述，选择合适封装格式应综合考虑终端设备兼容性、网络条件、功能需求等因素。在 Android 开发中，推荐优先使用 MP4（特别是 fMP4）作为默认输出格式，兼顾通用性与流式能力。

3.2 输入源解析与流信息获取

在音视频处理链路中，准确识别输入源的格式与结构是后续解码、滤镜、同步等操作的前提。FFmpeg 的 libavformat 提供了一套强大且灵活的机制，能够自动探测输入流类型并提取关键参数。这一过程涉及多个核心 API 的协同工作，涵盖从打开文件到解析流信息的完整流程。

3.2.1 打开输入文件或网络流（AVIOContext扩展）

调用 avformat_open_input() 是启动 demuxing 的第一步。该函数会根据输入 URL 自动匹配相应的 AVInputFormat ，并完成协议层连接（如 file、http、rtsp）。

int open_input_source(const char *input_url) {
    AVFormatContext *fmt_ctx = NULL;
    int ret;

    // 1. 分配格式上下文
    if ((ret = avformat_open_input(&fmt_ctx, input_url, NULL, NULL)) < 0) {
        fprintf(stderr, "Cannot open input file: %s\n", av_err2str(ret));
        return ret;
    }

    // 2. 查找流信息（触发解封装器解析）
    if ((ret = avformat_find_stream_info(fmt_ctx, NULL)) < 0) {
        fprintf(stderr, "Cannot find stream information: %s\n", av_err2str(ret));
        avformat_close_input(&fmt_ctx);
        return ret;
    }

    // 3. 打印基本信息
    av_dump_format(fmt_ctx, 0, input_url, 0);

    // ... 继续处理
    avformat_close_input(&fmt_ctx);
    return 0;
}

参数说明 ：
- input_url : 输入路径，可为本地文件 ( file:///sdcard/test.mp4 ) 或网络地址 ( rtsp://... );
- 第三个参数可强制指定 demuxer 类型（如 "flv" ），传 NULL 则启用自动探测；
- 第四个参数为选项字典，可用于设置超时、用户代理等。

执行逻辑分析 ：
- 第 6 行： avformat_open_input() 内部调用 avio_open() 建立底层 IO 连接；
- 若为 HTTP 流，会发送 HEAD 请求获取 Content-Type；
- 成功后填充 fmt_ctx->iformat 字段指向具体 demuxer；
- 第 13 行： avformat_find_stream_info() 强制读取若干 packet 来判断码率、帧率、GOP 结构等；
- 此步骤对某些格式（如 MPEG-TS）至关重要，否则可能导致解码失败。

此外，对于特殊场景（如加密流、自定义协议），可注册自定义 AVIOContext ：

// 示例：使用内存缓冲区作为输入源
unsigned char *buffer = ...; // 数据指针
int buffer_size = ...;

// 创建 AVIOContext
AVIOContext *avio = avio_alloc_context(
    buffer,                    // 缓冲区首地址
    buffer_size,               // 缓冲区大小
    0,                         // write_flag: 0=只读
    opaque,                    // 用户数据（回调中可用）
    &read_packet_callback,     // 读取回调
    NULL,                      // 写回调（空）
    &seek_callback             // 定位回调
);

// 关联到格式上下文
AVFormatContext *fmt_ctx = avformat_alloc_context();
fmt_ctx->pb = avio;
fmt_ctx->flags |= AVFMT_FLAG_CUSTOM_IO;

avformat_open_input(&fmt_ctx, "", NULL, NULL);

该方法常用于从 Java 层传递 ByteBuffer 到 JNI 层处理加密视频流。

3.2.2 提取音视频流索引与编解码参数

一旦完成流信息查找，即可从中提取所需流的索引号及编解码配置。

int find_video_stream(AVFormatContext *fmt_ctx, int *video_stream_idx) {
    for (int i = 0; i < fmt_ctx->nb_streams; i++) {
        if (fmt_ctx->streams[i]->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
            *video_stream_idx = i;
            return 0;
        }
    }
    return -1; // 未找到视频流
}

// 获取视频宽高、像素格式、帧率
void get_video_info(AVFormatContext *fmt_ctx, int idx) {
    AVCodecParameters *par = fmt_ctx->streams[idx]->codecpar;
    AVRational fps = av_guess_frame_rate(fmt_ctx, fmt_ctx->streams[idx], NULL);

    printf("Video: %dx%d, Format=%s, FPS=%.2f\n",
           par->width, par->height,
           av_get_pix_fmt_name(par->format),
           av_q2d(fps));
}

关键字段解释 ：
- codec_type : 区分音频、视频、字幕；
- codec_id : 如 AV_CODEC_ID_H264 ；
- format : 视频为 AVPixelFormat ，音频为 AVSampleFormat ；
- width/height : 分辨率；
- sample_rate/ch_layout : 音频专用参数。

这些信息可用于后续创建解码器上下文（ AVCodecContext ）。

3.2.3 时间戳同步与PTS/DTS处理逻辑

时间戳是实现音视频同步的核心依据。 libavformat 在 demuxing 阶段提供原始 PTS/DTS，但需注意其单位为对应流的 time_base 。

while (av_read_frame(fmt_ctx, &pkt) >= 0) {
    AVStream *st = fmt_ctx->streams[pkt.stream_index];
    int64_t pts_time_us = av_rescale_q(pkt.pts, st->time_base, AV_TIME_BASE_Q);

    printf("Stream #%d, PTS=%.2f ms\n",
           pkt.stream_index, pts_time_us / 1000.0);
    av_packet_unref(&pkt);
}

函数说明 ：
- av_rescale_q() : 将时间值从一个时间基转换到另一个；
- AV_TIME_BASE_Q 表示微秒级时间基（1/1000000）；
- 此转换后的时间可用于比较不同流之间的同步偏差。

DTS（Decoding Time Stamp）用于指示解码顺序，PTS（Presentation Time Stamp）指示显示顺序。在 B 帧存在时二者不同。

综上，输入源解析不仅是技术起点，更是保障整个处理链稳定运行的基础。熟练掌握 libavformat 的探测机制与参数提取方法，是构建健壮音视频应用的第一步。

4. libavfilter音视频滤镜处理

FFmpeg中的 libavfilter 库是实现音视频数据实时处理与增强的核心组件，它提供了一套灵活、可扩展的滤镜系统，支持开发者在不解码或重新编码的前提下对原始音视频流进行各种非破坏性操作。这一能力在现代多媒体应用中具有极高的实用价值——从简单的亮度调节到复杂的美颜算法，再到多路视频合成与音频混响处理，都依赖于 libavfilter 所提供的强大抽象机制。

不同于传统的图像处理库将所有功能封装为独立函数调用的方式， libavfilter 采用“滤镜图（Filter Graph）”模型来组织数据流动，使得多个滤镜可以串联、并联甚至分支化地组合在一起，形成高度定制化的处理流水线。这种设计不仅提升了代码复用率，也极大增强了系统的可维护性和动态配置能力。尤其在移动端场景下，面对多样化的用户需求和有限的计算资源，如何高效构建并优化滤镜链成为衡量一个音视频引擎成熟度的重要指标。

更为重要的是， libavfilter 并非仅限于软件层面的像素或采样点操作，其架构本身支持硬件加速接口的集成（如通过VAAPI、DXVA2或OpenCL后端），允许部分计算密集型滤镜（如缩放、色彩空间转换）交由GPU执行，从而显著降低CPU负载。同时，该库还提供了丰富的调试工具与性能监控接口，便于开发人员分析延迟、帧率波动等问题，确保最终输出质量稳定可靠。

本章将深入剖析 libavfilter 的工作原理与核心结构，并结合Android平台的实际应用场景，详细讲解视频与音频滤镜的典型用例及其实现方式。还将探讨如何通过日志追踪、性能测量等手段提升滤镜系统的健壮性与可观察性，帮助开发者构建既功能丰富又高效稳定的多媒体处理管道。

4.1 滤镜图（Filter Graph）工作原理

libavfilter 中最关键的概念是“滤镜图”（Filter Graph），它是整个滤镜系统运行的基础架构。每一个滤镜图由若干个滤镜节点（Filter Node）组成，这些节点通过输入/输出“pad”连接，构成一个有向无环图（DAG），用于描述音视频数据在整个处理流程中的流向。

4.1.1 AVFilterContext与AVFilterGraph构建方式

在FFmpeg中，每个滤镜实例由 AVFilterContext 表示，而整个滤镜拓扑结构则由 AVFilterGraph 统一管理。创建滤镜图的基本步骤包括：初始化图对象、注册所需滤镜、创建上下文节点、连接节点之间的pad，并最终配置和验证整个图的有效性。

// 示例：构建一个简单的视频滤镜图：scale=1280:720
#include <libavfilter/avfilter.h>
#include <libavfilter/buffersink.h>
#include <libavfilter/buffersrc.h>

int create_filter_graph(AVFilterGraph **graph, AVFilterContext **src_ctx, 
                        AVFilterContext **sink_ctx) {
    avfilter_register_all(); // 注册所有内置滤镜

    *graph = avfilter_graph_alloc();
    if (!*graph) return AVERROR(ENOMEM);

    // 创建缓冲源滤镜（buffersrc）
    const AVFilter *buffer_src = avfilter_get_by_name("buffer");
    *src_ctx = avfilter_graph_create_filter(buffer_src, "in", 
                                           "video_size=1920x1080:pix_fmt=yuv420p:time_base=1/30:pixel_aspect=1/1", 
                                           NULL, NULL, *graph);
    if (!*src_ctx) return AVERROR(EINVAL);

    // 创建缓冲接收滤镜（buffersink）
    const AVFilter *buffer_sink = avfilter_get_by_name("buffersink");
    *sink_ctx = avfilter_graph_create_filter(buffer_sink, "out", NULL, NULL, NULL, *graph);
    if (!*sink_ctx) return AVERROR(EINVAL);

    // 添加中间滤镜：scale
    AVFilterContext *scale_ctx;
    avfilter_graph_create_filter(avfilter_get_by_name("scale"), "scale",
                                 "1280:720", NULL, NULL, *graph);

    // 连接 src -> scale -> sink
    avfilter_link(*src_ctx, 0, scale_ctx, 0);
    avfilter_link(scale_ctx, 0, *sink_ctx, 0);

    // 配置图
    int ret = avfilter_graph_config(*graph, NULL);
    if (ret < 0) {
        avfilter_graph_free(graph);
        return ret;
    }

    return 0;
}

代码逻辑逐行解读：

• 第6行：调用 avfilter_register_all() 确保所有内置滤镜已加载（虽然新版FFmpeg自动注册，但仍建议显式调用）。
• 第9行：使用 avfilter_graph_alloc() 分配一个新的滤镜图对象。
• 第14–18行：获取名为 "buffer" 的源滤镜（即 buffersrc ），并通过 avfilter_graph_create_filter 创建输入上下文。参数字符串定义了输入视频的属性（分辨率、格式、时间基等）。
• 第22–26行：创建接收端滤镜 buffersink ，作为处理链的终点。
• 第29–32行：插入 scale 滤镜，设置目标分辨率为1280x720。
• 第35–36行：使用 avfilter_link 建立滤镜间的连接关系，形成数据流路径。
• 第39–45行：调用 avfilter_graph_config 完成图的验证与内部参数协商，若失败则释放资源返回错误码。

此示例展示了最基本的三段式滤镜图结构： 源 → 处理器 → 接收器 ，这是大多数实际应用的基础模板。

4.1.2 输入输出pad连接与数据流动模型

在 libavfilter 中，每个滤镜都有一个或多个输入和输出“pad”（垫片），它们是数据流入流出的通道。pad包含格式信息（如像素格式、声道布局、采样率等），并在图配置阶段进行“格式协商”（format negotiation），以确保前后滤镜兼容。

下图展示了上述滤镜图的数据流动过程：

graph LR
    A[AVFrame 输入] --> B[buffersrc]
    B --> C[scale 滤镜]
    C --> D[buffersink]
    D --> E[AVFrame 输出]

每个pad本质上是一个队列缓冲区，当上游滤镜产生一帧数据后，会推送到下游滤镜的输入pad中。一旦所有输入就绪，滤镜便触发 filter_frame 回调函数执行具体处理逻辑。

此外，pad的设计支持多输入/多输出场景。例如 overlay 滤镜有两个输入pad（主视频流和叠加层），必须等待两帧同时到达才能合成输出；而 split 滤镜则有一个输入但两个输出，可将同一帧复制发送至不同分支。

Pad 类型	方向	功能说明
Input Pad	输入	接收来自前一级滤镜的数据帧
Output Pad	输出	向后一级滤镜推送处理后的数据帧
Negotiation	双向	在配置阶段协商数据格式（pix_fmt, sample_rate 等）
Activation Mode	控制	支持主动拉取（pull-based）或被动推送（push-based）模式

值得注意的是， libavfilter 默认采用“push”模式，即上游滤镜主动推送帧到下游。但在某些复杂拓扑中（如循环反馈结构），也可切换为“pull”模式，由终端消费者反向请求数据。

4.1.3 滤镜链表达式语法解析与动态配置

FFmpeg提供了一种简洁的文本语法来描述滤镜链，称为“滤镜表达式”（Filter String），极大简化了图的构建过程。例如：

"scale=1280:720,fps=30,drawtext=text='Hello':fontsize=24"

上述字符串可通过 avfilter_graph_parse_ptr 直接解析并生成对应的滤镜图：

char filter_descr[] = "scale=1280:720,fps=30,drawtext=text='Hello':fontsize=24";

AVFilterInOut *outputs = avfilter_inout_alloc();
AVFilterInOut *inputs  = avfilter_inout_alloc();

outputs->name       = av_strdup("in");
outputs->filter_ctx = src_ctx;
outputs->pad_idx    = 0;
outputs->next       = NULL;

inputs->name        = av_strdup("out");
inputs->filter_ctx  = sink_ctx;
inputs->pad_idx     = 0;
inputs->next        = NULL;

int ret = avfilter_graph_parse_ptr(graph, filter_descr,
                                   &inputs, &outputs, NULL);
if (ret < 0) {
    fprintf(stderr, "Failed to parse filter string\n");
    return ret;
}

该方法的优势在于：
- 允许动态更改滤镜链（如根据用户操作切换美颜强度）；
- 易于与UI层交互（前端传入JSON配置即可生成滤镜）；
- 减少C/C++层胶水代码量，提升开发效率。

下表列出常用视频滤镜及其参数示例：

滤镜名称	参数示例	功能描述
scale	scale=1280:720:flags=lanczos	高质量图像缩放
rotate	rotate=PI/4	旋转45度
crop	crop=iw/2:ih/2	居中裁剪一半画面
hflip	hflip	水平翻转
eq	eq=brightness=0.1:contrast=1.2	调整明暗对比度
fade	fade=t=in:st=0:d=1	视频淡入效果

通过合理组合这些滤镜表达式，可以在不修改底层代码的情况下实现高度灵活的视觉特效系统，特别适用于短视频编辑类App的快速迭代需求。

4.2 视频滤镜典型应用场景

4.2.1 分辨率缩放、旋转、裁剪操作实现

在移动设备上，由于摄像头采集的原始分辨率往往较高（如4K），而显示界面通常只需720p或更低，因此需要实时进行分辨率缩放。 scale 滤镜是最常用的解决方案。

// 使用 scale 滤镜进行动态缩放
const char *scale_filter = "scale=854:480:flags=bilinear";

AVFilterContext *buffersrc_ctx = nullptr;
AVFilterContext *buffersink_ctx = nullptr;
AVFilterGraph *filter_graph = avfilter_graph_alloc();

// 初始化源与接收器（同前）
// ...

// 解析滤镜表达式
avfilter_graph_parse(filter_graph, scale_filter,
                     &buffersink_ctx, &buffersrc_ctx, NULL);

avfilter_graph_config(filter_graph, NULL);

参数说明：
- 854:480 ：目标宽高；
- flags=bilinear ：插值算法，可选 nearest , bilinear , lanczos 等，精度越高性能越低；
- 若省略宽高比，可用 force_original_aspect_ratio=decrease 保持原始比例。

对于旋转与裁剪，可分别使用 rotate 和 crop 滤镜：

"rotate=PI/6:c=black@0.5, crop=ih*16/9:ih"

该表达式先顺时针旋转30度（π/6弧度），背景填充半透明黑，再按16:9比例裁剪中心区域。

4.2.2 添加文字水印与图像叠加（overlay）

水印添加通常使用 drawtext 或 overlay 滤镜。前者适合纯文本，后者可用于PNG图标叠加。

"drawtext=fontfile=/system/fonts/DroidSans.ttf:text='©MyApp':fontsize=24:x=10:y=10:fontcolor=white"

关键参数解释：
- fontfile ：字体路径（Android需注意权限与路径有效性）；
- x/y ：坐标位置，支持表达式如 w-tw （右对齐）；
- fontcolor ：颜色支持十六进制（ color=0xFFFFFF ）或命名色；
- shadowcolor/shadowx ：可添加阴影增强可读性。

图像叠加示例：

"[in][wm]overlay=x=main_w-overlay_w-10:y=10[out]"

其中 [wm] 是另一个输入流（如logo.png），需提前解码为AVFrame并注入滤镜图。

4.2.3 色调调整、亮度对比度增强处理

使用 eq （equalizer）滤镜可精细控制图像色调：

"eq=brightness=0.05:saturation=1.2:gamma=0.9"

参数	取值范围	效果
brightness	-1 ~ 1	提亮或变暗
contrast	0 ~ 2	对比度增强
saturation	0 ~ 3	饱和度调节
gamma	0.1 ~ 10	伽马校正

实际项目中常结合滑动条让用户手动调节，提升交互体验。

以下是一个完整的视频滤镜链示例，集成了多种常见处理：

static const char *video_filters =
    "scale=1280:720,"
    "rotate=0.1:c=none,"
    "eq=brightness=0.05:contrast=1.1,"
    "drawtext="
    "fontfile=/system/fonts/Roboto-Regular.ttf:"
    "text='%{localtime\\:%Y-%m-%d %H\\:%M}':"
    "fontsize=20:x=(w-tw)/2:y=h-th-20:fontcolor=yellow@0.8";

此链实现了：降分辨率 → 微旋转防抖 → 色彩增强 → 时间戳水印，适用于直播前处理场景。

4.3 音频滤镜处理实践

4.3.1 音量调节、静音检测与淡入淡出效果

音频滤镜同样基于滤镜图机制。常用滤镜包括：

• volume ：调整增益
  bash volume=1.5 # 提高50%音量 volume=0.5 # 降低一半 volume='if(lt(t,3),0,t)' # 前3秒静音

• afade ：实现淡入淡出
  bash afade=t=in:ss=0:d=2 # 开头2秒淡入 afade=t=out:st=59:d=3 # 结尾3秒淡出

• silencedetect ：检测静音片段
  bash silencedetect=n=-30dB:d=1
  当连续1秒内音量低于-30dB时触发日志记录，可用于自动剪辑空白段。

4.3.2 单声道/立体声转换与声道混合

使用 channelsplit 和 channelmap 可灵活重排声道：

"channelsplit=channel_layout=stereo[left][right],"
"[left]volume=0.8[low_left],"
"[right][low_left]amix=inputs=2:duration=first:dropout_transition=2"

上述链路将立体声拆分为左右声道，左声道减弱后与右声道混合输出。

4.3.3 回声抑制与噪声过滤初步探索

尽管 libavfilter 原生未内置AEC（回声消除）模块，但可通过集成WebRTC的DSP库或使用 afftdn （基于FFT的降噪）实现基础去噪：

"afftdn=nf=-25"  # 降噪强度-25dB

更高级的语音净化方案通常需结合第三方SDK，在JNI层桥接处理。

4.4 滤镜性能监控与调试手段

4.4.1 滤镜延迟测量与帧率稳定性分析

可通过统计每帧进入与离开滤镜图的时间差估算处理延迟：

struct timeval start_tv, end_tv;
gettimeofday(&start_tv, NULL);
av_buffersrc_add_frame(src_ctx, frame);
gettimeofday(&end_tv, NULL);
double latency_ms = (end_tv.tv_sec - start_tv.tv_sec) * 1000 +
                    (end_tv.tv_usec - start_tv.tv_usec) / 1000.0;

长期监控该值可识别性能瓶颈，如某滤镜突然耗时飙升可能表明内存不足或硬件加速失效。

4.4.2 日志输出与错误追踪机制集成

启用详细日志有助于排查滤镜配置问题：

av_log_set_level(AV_LOG_DEBUG);

常见错误包括：
- Format mismatch ：前后滤镜格式不一致（如YUV420P vs YUV444P）；
- Invalid argument ：参数拼写错误或超出范围；
- Impossible to convert ：缺少必要的转换滤镜（如需插入 format 滤镜强制转换）。

推荐做法是在发布版本中关闭DEBUG日志，仅在测试环境开启，避免影响性能。

综上所述， libavfilter 不仅是FFmpeg生态系统中最具表现力的模块之一，更是构建专业级音视频处理引擎的关键支柱。掌握其核心机制与实战技巧，将使开发者能够从容应对复杂多变的业务需求，打造更具竞争力的多媒体产品。

5. Android NDK环境配置与交叉编译集成

在现代音视频应用开发中，FFmpeg 作为底层核心处理引擎，广泛用于解码、编码、滤镜、封装等复杂任务。然而，由于 Android 平台的特殊性——其基于 Linux 内核但使用 Java/Kotlin 高层语言进行开发，且运行于多样化的 CPU 架构之上（如 armeabi-v7a、arm64-v8a 等），直接将 FFmpeg 源码嵌入项目并不可行。因此，必须通过 Android NDK（Native Development Kit） 实现对 C/C++ 代码的支持，并借助 交叉编译技术 将 FFmpeg 编译为可在 Android 设备上运行的原生库文件（ .so 文件）。本章节系统阐述如何从零搭建支持 FFmpeg 的 Android 原生开发环境，涵盖 NDK 配置、交叉编译流程、JNI 接口设计以及高层 API 封装策略。

5.1 Android NDK开发环境搭建

构建一个稳定高效的 Android 原生开发环境是集成 FFmpeg 的第一步。NDK 提供了必要的工具链（包括编译器、链接器、调试器等），使得开发者可以在 Android 应用中调用高性能的 C/C++ 代码。这一过程不仅涉及 IDE 和构建系统的正确配置，还需深入理解 ABI（Application Binary Interface）架构适配机制，以确保生成的 .so 库能在目标设备上正常加载和执行。

5.1.1 NDK版本选择与CMake工具链配置

Android Studio 自 2.2 版本起引入了 CMake 和 LLDB 作为默认的原生开发支持组件，取代了旧有的 GNU Make（ndk-build）。CMake 是一种跨平台的构建系统生成器，能够解析 CMakeLists.txt 脚本并生成适用于不同平台的构建指令。对于 FFmpeg 这类复杂的开源项目，使用 CMake 可以更灵活地控制编译参数、依赖管理和输出路径。

当前主流推荐使用的 NDK 版本为 r23b 或 r25 ，这些版本提供了对 Clang 编译器的全面支持，弃用了过时的 GCC 工具链，并增强了对 C++17 标准的支持。尤其需要注意的是，从 NDK r18 开始，官方仅支持使用 Clang 进行编译，这意味着所有自定义编译脚本都必须适配 Clang 的语法和参数规范。

以下是一个典型的 CMakeLists.txt 示例，用于加载已编译好的 FFmpeg 静态库并在 Android 项目中链接：

# 设置 CMake 最低版本要求
cmake_minimum_required(VERSION 3.18)

# 定义项目名称
project("ffmpegplayer")

# 启用 C++14 标准
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

# 添加 FFmpeg 头文件路径
include_directories(src/main/cpp/include/ffmpeg)

# 导入预编译的静态库
add_library(avutil STATIC IMPORTED)
set_target_properties(avutil PROPERTIES IMPORTED_LOCATION ${CMAKE_SOURCE_DIR}/src/main/jniLibs/${ANDROID_ABI}/libavutil.a)

add_library(avcodec STATIC IMPORTED)
set_target_properties(avcodec PROPERTIES IMPORTED_LOCATION ${CMAKE_SOURCE_DIR}/src/main/jniLibs/${ANDROID_ABI}/libavcodec.a)

add_library(avformat STATIC IMPORTED)
set_target_properties(avformat PROPERTIES IMPORTED_LOCATION ${CMAKE_SOURCE_DIR}/src/main/jniLibs/${ANDROID_ABI}/libavformat.a)

add_library(swscale STATIC IMPORTED)
set_target_properties(swscale PROPERTIES IMPORTED_LOCATION ${CMAKE_SOURCE_DIR}/src/main/jniLibs/${ANDROID_ABI}/libswscale.a)

add_library(swresample STATIC IMPORTED)
set_target_properties(swresample PROPERTIES IMPORTED_LOCATION ${CMAKE_SOURCE_DIR}/src/main/jniLibs/${ANDROID_ABI}/libswresample.a)

# 创建自己的共享库
add_library(native-lib SHARED src/main/cpp/native-lib.cpp)

# 链接 FFmpeg 静态库
target_link_libraries(native-lib
                      avutil
                      avcodec
                      avformat
                      swscale
                      swresample
                      log)

逻辑分析与参数说明：

• cmake_minimum_required(VERSION 3.18) ：指定最低 CMake 版本，避免因版本不兼容导致构建失败。
• include_directories(...) ：声明头文件搜索路径，使编译器能找到 FFmpeg 的 .h 文件。
• add_library(... IMPORTED) ：导入外部预编译的静态库（ .a 文件），其中 ${ANDROID_ABI} 是 Gradle 构建过程中自动注入的变量，表示当前目标架构（如 arm64-v8a）。
• target_link_libraries(...) ：将多个静态库链接到最终生成的 .so 动态库中，注意顺序重要——依赖者应放在前面。

该配置方式实现了模块化管理，便于后续扩展新的原生功能或更换 FFmpeg 版本。

5.1.2 ABI架构适配（armeabi-v7a, arm64-v8a, x86_64）

Android 设备支持多种 CPU 架构，主要分为：
| ABI | 描述 | 典型设备 |
|------|--------|---------|
| armeabi-v7a | 32位 ARM 架构，支持硬件浮点运算 | 老款手机、低端平板 |
| arm64-v8a | 64位 ARM 架构，性能更强，现代主流 | 几乎所有新机型 |
| x86_64 | 64位 Intel 架构，模拟器常用 | Android Emulator |
| x86 | 32位 Intel 架构 | 旧版模拟器 |

若未针对特定 ABI 编译 FFmpeg，则可能出现 UnsatisfiedLinkError 错误，提示无法找到对应 .so 文件。最佳实践是为每个目标 ABI 分别编译一套 FFmpeg 库，并在 build.gradle 中启用多架构打包：

android {
    compileSdk 34

    defaultConfig {
        applicationId "com.example.ffmpegapp"
        minSdk 21
        targetSdk 34
        versionCode 1
        versionName "1.0"

        ndk {
            abiFilters 'armeabi-v7a', 'arm64-v8a', 'x86_64'
        }
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }

    externalNativeBuild {
        cmake {
            path file('src/main/cpp/CMakeLists.txt')
            version '3.18.1'
        }
    }
}

此配置确保 APK 包含三种 ABI 的 .so 文件，适配绝大多数真实设备和模拟器。同时可通过 Split APK 技术按 ABI 分包，减少单个 APK 体积。

5.1.3 gradle中externalNativeBuild设置说明

externalNativeBuild 是 Android Gradle 插件提供的关键 DSL，用于连接 CMake 或 ndk-build 构建系统。它允许开发者在标准 Gradle 构建生命周期中触发原生代码编译。

externalNativeBuild {
    cmake {
        path "src/main/cpp/CMakeLists.txt"
        version "3.18.1"
    }
}

上述配置告诉 Gradle 使用指定路径下的 CMakeLists.txt 文件来构建 native 层代码。当执行 ./gradlew assembleDebug 时，Gradle 会自动调用 CMake 生成 Makefile，并调用 Clang 编译源码，最终输出 libnative-lib.so 到 jniLibs/ABI/ 目录下。

此外，还可以通过 arguments 传递额外的 CMake 变量，例如开启调试模式或启用日志输出：

cmake {
    arguments "-DDEBUG_LOG=ON"
    cFlags "-DFFMPEG_ENABLE_TRACE"
    cppFlags "-std=c++14"
}

这种机制极大提升了构建灵活性，便于实现条件编译和功能开关控制。

5.2 FFmpeg源码交叉编译流程

要在 Android 上运行 FFmpeg，必须将其源码使用交叉编译工具链重新编译为目标平台可执行的形式。这一步骤最为关键也最易出错，涉及 configure 脚本定制、编译选项优化、Shell 脚本自动化等多个方面。

5.2.1 配置configure脚本的关键选项（–target-os=android）

FFmpeg 使用 GNU Autotools 构建系统，其核心入口为 configure 脚本。为了使其适配 Android 平台，需传入一系列交叉编译相关参数：

./configure \
    --prefix=$PREFIX \
    --target-os=android \
    --arch=$ARCH \
    --cpu=$CPU \
    --cc=$CC \
    --cxx=$CXX \
    --enable-cross-compile \
    --sysroot=$SYSROOT \
    --extra-cflags="-Os -fpic $CFLAGS" \
    --extra-ldflags="$LDFLAGS" \
    --disable-shared \
    --enable-static \
    --disable-doc \
    --disable-ffmpeg \
    --disable-ffplay \
    --disable-ffprobe \
    --disable-avdevice \
    --disable-postproc \
    --disable-symver \
    --disable-stripping

参数详解：
- --target-os=android ：明确指定目标操作系统为 Android。
- --arch 与 --cpu ：分别设定目标 CPU 架构（如 aarch64）和具体型号（如 cortex-a53）。
- --cc 与 --cxx ：指定交叉编译器路径，通常指向 $NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android21-clang 。
- --enable-cross-compile ：启用交叉编译模式。
- --sysroot ：指定系统根目录，包含头文件和库。
- --disable-shared --enable-static ：关闭动态库生成，只生成静态库，便于集成进 APK。
- --disable-... ：禁用不必要的组件以减小体积和编译时间。

此阶段生成的 config.h 和 Makefile 将指导后续编译过程。

5.2.2 编译脚本编写与自动化构建shell实现

手动执行上述命令效率低下且易出错，建议编写 Shell 脚本来自动化整个流程。以下是一个简化版的 build_ffmpeg.sh 示例：

#!/bin/bash
NDK=/home/user/android-ndk-r25b
TOOLCHAIN=$NDK/toolchains/llvm/prebuilt/linux-x86_64
API=21
ARCH=aarch64
CPU=cortex-a53
CC=$TOOLCHAIN/bin/aarch64-linux-android$API-clang
CXX=$TOOLCHAIN/bin/aarch64-linux-android$API-clang++
SYSROOT=$NDK/toolchains/llvm/prebuilt/linux-x86_64/sysroot
PREFIX=$(pwd)/android/$ARCH

./configure \
    --prefix=$PREFIX \
    --target-os=android \
    --arch=$ARCH \
    --cpu=$CPU \
    --cc=$CC \
    --cxx=$CXX \
    --enable-cross-compile \
    --sysroot=$SYSROOT \
    --extra-cflags="-I$SYSROOT/usr/include" \
    --extra-ldflags="-L$SYSROOT/usr/lib" \
    --disable-shared \
    --enable-static \
    --disable-doc \
    --disable-programs \
    && make clean && make -j$(nproc) && make install

运行该脚本后，会在 android/aarch64 目录下生成 lib/ 和 include/ 文件夹，即为可用于 Android 项目的 FFmpeg 静态库集合。

5.2.3 静态库生成与strip优化减少体积

尽管静态库无需运行时依赖，但 FFmpeg 默认编译结果仍较大（可达 10MB+）。可通过 strip 工具移除调试符号进一步压缩：

$TOOLCHAIN/bin/aarch64-linux-android-strip --strip-unneeded $PREFIX/lib/*.a

此外，还可结合 ProGuard 或 R8 在 APK 打包阶段进一步裁剪无用函数。

mermaid 流程图：交叉编译全流程

graph TD
    A[下载 FFmpeg 源码] --> B[设置 NDK 路径]
    B --> C[定义 ARCH/CPU/API]
    C --> D[配置 configure 参数]
    D --> E[执行 ./configure]
    E --> F[运行 make && make install]
    F --> G[生成静态库 .a 文件]
    G --> H[使用 strip 优化体积]
    H --> I[复制到 jniLibs 目录]
    I --> J[Gradle 构建 APK]

该流程清晰展示了从源码获取到最终集成的完整链条，适用于团队协作中的标准化部署。

5.3 JNI接口设计与Java/Kotlin调用桥接

JNI（Java Native Interface）是 Java 与 C/C++ 交互的标准桥梁。合理设计 JNI 接口不仅能提升调用效率，还能增强代码可维护性。

5.3.1 native方法声明与so库加载时机控制

在 Java/Kotlin 类中声明 native 方法：

public class FFmpegPlayer {
    static {
        System.loadLibrary("native-lib");
    }

    public native int init(String inputPath);
    public native int decodeFrame(ByteBuffer buffer);
    public native void release();
}

System.loadLibrary("native-lib") 必须在首次调用 native 方法前完成，通常放在静态块中确保只执行一次。注意库名不含 lib 前缀和 .so 后缀。

5.3.2 字符串、数组、ByteBuffer跨语言传递规范

JNI 提供了多种数据类型映射机制：

Java Type	JNI Type	C/C++ Equivalent
String	jstring	const char* (via GetStringUTFChars)
byte[]	jbyteArray	uint8_t* (via GetByteArrayElements)
ByteBuffer	jobject	void* (via GetDirectBufferAddress)

例如，在 native 层获取输入路径字符串：

JNIEXPORT jint JNICALL
Java_com_example_FFmpegPlayer_init(JNIEnv *env, jobject thiz, jstring input_jstr) {
    const char *input_cstr = (*env)->GetStringUTFChars(env, input_jstr, NULL);
    if (!input_cstr) return -1;

    // 使用 input_cstr 初始化 AVFormatContext...
    (*env)->ReleaseStringUTFChars(env, input_jstr, input_cstr); // 必须释放
    return 0;
}

对于高性能场景（如视频帧传输），推荐使用 DirectByteBuffer ，因其内存位于堆外，避免拷贝开销：

val buffer = ByteBuffer.allocateDirect(frameSize)
nativeDecode(buffer)

C 层直接访问：

uint8_t *data = (uint8_t*) env->GetDirectBufferAddress(buffer);

5.3.3 异常抛出与日志回调函数注册机制

JNI 中可通过 ThrowNew 主动抛出 Java 异常：

if (avformat_open_input(&fmt_ctx, url, NULL, NULL) < 0) {
    (*env)->ThrowNew(env, jcls_Exception, "Cannot open input file");
    return -1;
}

同时可注册日志回调，将 FFmpeg 内部日志转发至 Android Logcat：

void ffmpeg_log_callback(void *ptr, int level, const char *fmt, va_list vl) {
    va_list copy;
    va_copy(copy, vl);
    __android_log_vprint(ANDROID_LOG_DEBUG, "FFmpeg", fmt, copy);
    va_end(copy);
}

// 注册
av_log_set_callback(ffmpeg_log_callback);

5.4 应用层API封装建议

5.4.1 构建统一的MediaProcessor类对外暴露功能

建议封装一个高层 MediaProcessor 类，隐藏底层复杂性：

class MediaProcessor {
    fun decode(filePath: String, onFrame: (ImageFrame) -> Unit)
    fun applyFilter(filterExpr: String)
    fun record(camera: Surface, output: String)
}

内部通过 JNI 调用 native 方法，对外提供简洁异步接口。

5.4.2 异步任务执行与主线程通信机制（Handler/Coroutine）

音视频操作耗时长，必须在子线程执行：

GlobalScope.launch(Dispatchers.IO) {
    processor.decode("video.mp4") { frame ->
        withContext(Dispatchers.Main) {
            surfaceView.draw(frame)
        }
    }
}

利用 Kotlin 协程实现非阻塞调用，结合 Channel 或 Flow 实现高效数据流处理。

6. 音视频播放与录制功能开发实战

6.1 基于FFmpeg的轻量级播放器实现

在移动端构建一个基于 FFmpeg 的轻量级播放器，核心在于整合解封装、解码和音视频同步三大流程。整个播放链路由 libavformat 负责读取容器流， libavcodec 完成帧级解码，最终通过 Android 原生组件进行渲染输出。

6.1.1 解封装+解码+音视频同步逻辑整合

播放器主循环通常运行在一个独立线程中，避免阻塞 UI 线程。其基本处理流程如下：

while (isPlaying && av_read_frame(pFormatCtx, &packet) >= 0) {
    AVStream *stream = pFormatCtx->streams[packet.stream_index];
    double pts = av_q2d(stream->time_base) * packet.pts;

    if (packet.stream_index == videoStreamIndex) {
        // 视频解码
        decode_video_frame(&packet, pts);
    } else if (packet.stream_index == audioStreamIndex) {
        // 音频解码并送入 AudioTrack 缓冲区
        decode_audio_frame(&packet, pts);
    }

    av_packet_unref(&packet);
}

关键点说明：
- av_read_frame() 按时间顺序读取压缩包。
- 时间基（time_base）用于将 PTS 转换为秒单位，便于同步判断。
- 音视频分别送入各自的解码队列，采用双缓冲机制防止丢帧。

音视频同步策略一般以音频时钟为主时钟（audio master），视频根据当前音频播放位置动态调整显示时机：

同步类型	判断条件	处理方式
视频过快	video_pts > audio_clock + threshold	插入延迟或跳过非关键帧
视频过慢	video_pts < audio_clock - threshold	丢弃当前帧或加速渲染
正常范围	在 ±5ms 内	正常播放

该机制可通过以下伪代码实现：

double diff = video_pts - get_audio_clock();
if (diff > 0.05) {
    usleep((unsigned long)((diff - 0.05) * 1e6));
} else if (diff < -0.05) {
    skip_frame = 1;
}

6.1.2 SurfaceView或TextureView绘制YUV图像

Android 平台无法直接渲染 YUV 数据，需借助 OpenGL ES 或 ANativeWindow 接口完成格式转换与绘制。

使用 ANativeWindow 流程如下：

ANativeWindow *window = ANativeWindow_fromSurface(env, jsurface);
ANativeWindow_Buffer buffer;
ANativeWindow_lock(window, &buffer, NULL);

// 将 YUV420P 转为 RGB 并写入 buffer.bits
sws_scale(sws_ctx, 
          srcSlice, srcStride, 0, height,
          (uint8_t* const*)buffer.bits, buffer.stride * 4);

ANativeWindow_unlockAndPost(window);
ANativeWindow_release(window);

参数说明：
- jsurface : Java 层传入的 Surface 对象。
- sws_ctx : 由 sws_getContext() 创建的颜色空间转换上下文。
- buffer.stride * 4 : 假设目标格式为 RGBA_8888。

注意：频繁锁定窗口可能导致卡顿，建议使用 TextureView 配合 SurfaceTexture 实现更高效的异步更新。

6.1.3 AudioTrack播放PCM实现低延迟音频输出

AudioTrack 是 Android 提供的高性能音频输出类，支持 MODE_STREAM 模式下的实时播放。

Java 层初始化示例：

int sampleRate = 44100;
int channelConfig = AudioFormat.CHANNEL_OUT_STEREO;
int audioFormat = AudioFormat.ENCODING_PCM_16BIT;
int minBufferSize = AudioTrack.getMinBufferSize(sampleRate, channelConfig, audioFormat);

AudioTrack audioTrack = new AudioTrack(
    AudioManager.STREAM_MUSIC,
    sampleRate,
    channelConfig,
    audioFormat,
    minBufferSize,
    AudioTrack.MODE_STREAM
);
audioTrack.play();

JNI 层通过回调函数持续写入 PCM 数据：

void audio_callback(void *userdata, uint8_t *stream, int len) {
    AudioData *audio = (AudioData*)userdata;
    int pcm_size = fill_audio_buffer(audio, stream, len);
    memset(stream + pcm_size, 0, len - pcm_size); // 静音填充
}

结合 SwrContext 实现采样率与声道布局转换：

swr_convert(swr_ctx, &out_buffer, out_samples,
            (const uint8_t**)in_data, in_samples);

此结构可确保不同源格式均能正确输出至设备扬声器。

本文还有配套的精品资源，点击获取

简介：FFmpeg是一个功能强大的开源多媒体处理框架，支持音视频编解码、格式转换、滤镜处理、流媒体操作等核心功能。本资源提供专为Android平台编译的FFmpeg 2.0.1静态库，便于开发者在移动端快速集成音视频处理能力。通过NDK交叉编译、JNI接口调用及库文件集成，开发者可在Android应用中实现播放、录制、转码、裁剪等多种多媒体功能。尽管版本较旧，但仍适用于学习FFmpeg在Android上的基本架构与集成流程，是掌握移动多媒体开发的重要实践基础。

本文还有配套的精品资源，点击获取