企业官网建设流程全解析

简介：面向Android音视频开发入门者的PDF学习资料，系统讲解音视频处理的基础理论与完整流程。内容从视频帧、帧率、空间/时间/编码/视觉/知识冗余等概念讲起，逐步深入到码率控制模式（CBR、VBR、CVBR、AVBR）、分辨率与IPB帧、GOP、DTS/PTS、颜色空间转换等关键知识点，并配有大量FFmpeg命令行示例，如抽取视频帧、图片合成GIF、mp4转YUV、码率与关键帧控制等。同时，资料还介绍了MediaCodec、AudioTrack、Surface等Android多媒体框架，并给出FFmpeg的Android版本应用建议，帮助开发者将理论落地到实际项目。整个资料包为单个PDF文件，大小6.39MB，目录结构清晰，涵盖音视频基础理论、处理流程、Android处理框架与应用场景等模块，便于按需查阅。已有1213人学习下载，适合需要系统梳理音视频知识、为后续Android音视频开发打基础的开发者。

1. Android音视频开发：为什么基础理论比API调用更值得先啃

不少做安卓音视频的开发者，都是从MediaCodec、MediaPlayer这些API直接上手，跑通了就开始写业务。但真正遇到视频花屏、音画不同步、文件体积控制不住、码流无法播放这些问题时，回头看的往往是基础理论没立住。这份《Android音视频开发与处理》PDF就是典型的“先把概念讲透、再给工具链落地”的资料，覆盖了从视频帧、帧率、码率、颜色空间，到IPB帧结构、DTS/PTS、H.264裸流解析，再到FFmpeg命令实操的完整链路。适合两类人：一是刚转入音视频方向、需要快速建立完整知识地图的客户端开发者；二是已经在用Android多媒体框架但经常被编码参数和封装细节卡住的进阶者。它不教你调API，而是先让你明白每个参数在底层到底影响什么。

2. 视频体积、码率与分辨率：如何用公式和参数控制产物大小

2.1 未压缩数据量估算：YUV与RGB的存储差异

视频的原始数据量远超大多数人直觉。文档里给了一个很实在的计算案例：1920×1080分辨率、30fps的1080P视频，在YUV颜色空间下单帧大小为 1920×1080×3/2，约2.97MB，每秒数据量接近89MB。如果是RGB颜色空间，这个数值要再乘以2，达到每秒约178MB。看这个数字就能理解，为什么所有视频系统第一步都是编码压缩，而不是传输或存储原始帧。

这个计算逻辑对Android开发尤其重要。做Camera2采集或ImageReader回调时，拿到的是YUV_420_888格式的原始帧；如果直接送进编码器，必须保证输入格式匹配。我一般会在测试工程里写一段代码先打印每帧的Size，确认一下实际数据量是否符合YUV420的预期，再决定后续走GPU转格式还是CPU转格式。一个容易忽略的细节是：YUV有两种主要排列方式——Planar（如I420，先连续存所有Y，再存所有U，再存所有V）和Semi-Planar（如NV12，Y平面后紧跟UV交错数据）。Android的YUV_420_888在底层可能对应NV21或NV12，取决于设备厂商实现，代码里不能用固定偏移去读U/V分量，必须通过Image.Plane的getPixelStride和getRowStride动态计算。

2.2 码率模式选型：CBR、VBR、CVBR与AVBR的落地场景

码率是控制视频文件大小和画质最直接的旋钮。文档整理了四种模式的定位，发人深省的就一句话：CBR适合网络传输，VBR适合文件存储，CVBR是兼顾方案，如果设备支持，优先选CVBR。

实际项目中，我的选型经验如下：

• 直播或实时通话场景选CBR，带宽恒定，码率波动小，避免因码率突增导致网络拥塞。
• 本地录制或文件生成场景选CVBR，设定最大码率上限，同时允许复杂画面临时突破平均码率，让画质在运动场景不崩。
• AVBR在实际编码器中较少被单独暴露，更多是作为VBR的一种内部策略存在。

FFmpeg码率控制命令如下：

ffmpeg -i input.mp4 -b:v 2000k -bufsize 2000k -maxrate 2500k output.mp4

这块要拆开理解：-b:v控制目标平均码率，-maxrate限制峰值码率，-bufsize是码率控制器的缓冲大小，它决定了编码器多快响应码率变化。-bufsize设得越小，码率越接近恒定；设得越大，码率波动越明显，画质分配越灵活。常见做法是把-bufsize设成-b:v的1到2倍，-maxrate设为平均码率的1.25到1.5倍。如果直播推流，-bufsize不要设太大，否则延迟会变高。

2.3 帧率与动态帧率：流畅度和体积的博弈

帧率25FPS是人眼能感知为连续画面的下限，30FPS是当前移动端录制的常见标准，60FPS则用于游戏录屏或高速运动场景。帧率翻倍，同样码率下每帧分配的比特数减半，画质必然下降。Android的MediaCodec在setParameters里支持通过KEY_FRAME_RATE调节帧率，但设备未必严格遵循，有些厂商的硬件编码器在低光环境下会自动降帧率。

动态帧率的概念在实际产品里很少用，但有一个变体场景很常见：录屏应用在画面静止时降低采集帧率，检测到画面变化时再拉高。这类方案的收益是编码压力和文件体积都能降下来，坏处是时间戳处理变复杂，播放端如果按固定帧率渲染，会出现忽快忽慢的现象。我做过类似功能，最终采用的是保留原始时间戳、播放端用AudioTrack的时钟做同步的方案，而不是强制重采样到固定帧率。

3. IPB帧、GOP与DTS/PTS：读懂编码结构的三个关键点

3.1 I帧、P帧、B帧的职责与代价

编码压缩的核心逻辑是跨帧去冗余。I帧是关键帧，完整保存一幅画面，解码不依赖其他帧；P帧只存与前一帧的差异，解码时需要参考帧叠加；B帧记录的是前后帧的差异，解码时既要看之前的帧，也要等后面的帧。三者的体积差距通常在10倍以上。

在Android的MediaCodec编码器里，I帧的产生时机由KEY_I_FRAME_INTERVAL控制，单位是秒。Interval越大，I帧越少，文件越小，但seek响应越慢，视频流损坏后恢复越困难。文档给了一个反直觉的点：IDR帧一定是I帧，但I帧不一定是IDR帧。IDR帧会清空参考帧列表，之后的帧不会跨过它去参考更早的帧；而普通I帧之后的帧仍然可能引用IDR之前的数据。这就是为什么播放器每遇到一个IDR帧才能重新解码出完整画面。

3.2 GOP设置、关键帧间隔与FFmpeg命令

GOP是两个I帧之间的帧数，它决定了错误恢复时间。GOP设得越大，I帧出现频率越低，文件越小；坏处是画面花屏后要等下一个I帧才能恢复。直播场景里GOP不能太大，一般控制在1到2秒，否则网络丢包引发的花屏会持续很久。

ffmpeg -i sample.mp4 -t 10 -keyint_min 10 -g 10 -sc_threshold 0 out5.mp4

提取所有关键帧：

ffmpeg -i out5.mp4 -vf select='eq(pict_type\,I)' -vsync 2 -s 512*288 -f image2 img/core-%02d.jpeg

-g 10表示每10帧一个关键帧；-keyint_min 10限制关键帧最小间隔也是10，避免编码器在场景切换时额外插入I帧；-sc_threshold 0彻底关闭场景切换检测。这三项合在一起，才能保证关键帧间隔严格均匀。如果不设sc_threshold 0，编码器检测到画面剧烈变化时会自动插入I帧，导致GOP间隔失控——这在测试环境里表现为关键帧间隔时大时小，到了线上对低延迟要求高的场景就出问题。

3.3 PTS与DTS：为什么B帧的存在让时间戳对齐变复杂

不存在B帧时，解码顺序和显示顺序一致，这很直观。一旦引入B帧，为了解码某个B帧，需要先解码它后面的参考帧，解码顺序和显示顺序就撕裂了。DTS负责告诉播放器什么时候解码，PTS告诉播放器什么时候显示，两者在没有B帧时数值一致，在存在B帧时出现偏移。

Android的MediaCodec在解码时，每个BufferInfo都携带presentationTimeUs，这个值对应PTS。编码器输出时，输入帧的时间戳也要按PTS语义传入。常见错误是录制时把系统时钟直接塞给编码器，导致播放端音画不同步，因为音频的时间戳是线性递增的，而视频时间戳受B帧重排影响会出现非线性。更稳妥的做法是统一以音频采集时钟为基准，视频帧按到达顺序分配递增时间戳，不要直接用System.currentTimeMillis()。

4. 颜色空间、封装格式与H.264码流：从像素排列到NALU解析

4.1 RGB与YUV：Android开发者必须记住的格式差异

RGB依靠R、G、B三个分量直接混合出颜色，YUV则把亮度Y和色度UV分离，利用人眼对亮度更敏感、对色度不敏感的特性，可以对UV分量做更高倍率的采样压缩。YUV 4:2:0采样就是每四个Y共用一组UV分量，这也是Android相机默认输出格式。

文档中给出了RGB与YUV的转换公式和四个Bitmap配置枚举：ALPHA_8、ARGB_4444、ARGB_8888、RGB_565。其中ARGB_8888占用空间最大但画质最好，RGB_565只有16位、没有Alpha通道但体积小一倍。在做Camera预览实时处理或图片压缩时，需要遵循这个原则：先确认目标解码器/显示器的颜色空间匹配，否则直接转换会产生严重的偏色。内存分配和拷贝成本也需要充分考虑，例如在东芯屏幕上显示YUV420帧前，转成RGB_565比转成ARGB_8888能省一半内存带宽。

4.2 封装格式对比：MP4、FLV、TS、MKV各自适合什么

封装格式的作用是把视频码流和音频码流按一定的数据结构存到同一个文件里。文档整理了AVI、MP4、TS、FLV、MKV、RMVB六种格式的对比，关键信息如下：AVI几乎兼容所有编码，但流媒体支持差；MP4支持H.264和AAC且流媒体支持好，是目前移动端最通用的格式；FLV支持流媒体播放但编码支持不全面；TS支持流媒体直播场景，兼容性好；MKV支持几乎所有编码格式，但流媒体支持一般。

Android开发中：本地录制应选MP4，因为MediaMuxer直接支持；推流到RTMP服务一般走FLV封装；直播拉流或HLS切片常用TS。此外需要理解，转封装不是转码，只改变存储结构、不改变编码后的数据：

ffmpeg -i input.mp4 -c vcopy -an output.flv

-c:v copy直接复制视频编码数据，不做重新编码，这个操作毫秒级完成且不损失画质。若改用-c:v libx264，则CPU耗时会显著上升，画质也可能变化。记住向目标封装格式写入之前，先确认Codec Tag兼容，比如FLV不支持H.265，直接copy会生成播放器无法识别的文件。

4.3 H.264裸流与NALU类型：用位运算定位关键帧

H.264裸流由一连串NALU组成。SPS、PPS、IDR帧、普通帧的区分方法，是找到起始码0x00000001后，取之后的第一个字节，与0x1F做位与运算，结果对应具体的nal_unit_type。SPS的类型值为7，PPS的类型值为8，IDR帧的类型值为5。

Android端解码时，MediaCodec在configure阶段需要传入包含SPS/PPS的csd-0/csd-1，如果从MP4文件中提取裸流，需要先用FFmpeg做格式转换：

ffmpeg -i h264.mp4 -c:v copy -bsf:v h264_mp4toannexb -an out.h264

-bsf:v h264_mp4toannexb这一步至关重要：MP4封装的H.264，SPS/PPS以avcC结构集中存放在moov里，没有起始码；而裸流需要把SPS/PPS转换为带起始码的NALU格式。若忽略此参数，直接把mp4里的H264数据喂给MediaCodec，解码必然失败。

SPS中包含了计算分辨率所需的字段。多数Android设备输出的H.264码流中，媒体的宽高能从SPS解析出来，但常见坑点是：部分编码器在SPS中写入的宽高是16的整数倍对齐后的值，实际有效画面比SPS中计算的结果小。此时需要结合frame_crop_*字段做修正，否则硬解输出画面会出现拉伸或裁切偏移。

5. 常见问题排查：码流分析、播放异常与编码参数陷阱

5.1 现象：转码后的视频在部分播放器上有声音没画面

原因：目标容器不支持源编码格式。比如把H.265编码的MP4直接改后缀为FLV，播放器能读出音频轨，但视频轨无法识别。

解决：先用ffprobe确认目标容器支持的编码格式。FLV容器不支持H.265，需要转封装到TS或MP4，或重新编码为H.264。转封装用-c:v copy -c:a copy；转码用-c:v libx264。排查顺序是先查编码，再查容器，最后查Level。

5.2 现象：直播推流后花屏持续好几秒

原因：GOP间隔设置过大。编码器每2秒甚至4秒才输出一个关键帧，网络丢包后播放端无法恢复。

解决：将GOP控制在1到2秒。FFmpeg通过-g参数设置，例如视频30fps时设置-g 30到-g 60；同时设置-sc_threshold 0，避免场景切换打乱关键帧节奏。如果推流端网络连续抖动，还可以主动请求编码器强制插入关键帧，Android端通过MediaCodec的KEY_REQUEST_SYNC_FRAME可强制出IDR帧。

5.3 现象：YUV文件用工具打开是绿屏或花屏

原因：找不到YUV的宽度、高度和像素格式信息。YUV裸数据不携带分辨率、颜色空间等元数据，不知道格式就无法正确解析。

解决：常见做法是用ffprobe确认源视频的宽高和pix_fmt，再用ffmpeg -pix_fmt yuv420p明确指定输出格式；打开YUV文件时，在播放器工具里手动填入分辨率，例如512x288和yuv420p。容易踩的坑是：源视频实际为yuv444p，但输出时没指定参数，结果按yuv420p去解析，每帧大小对不上。

5.4 现象：Android端MediaCodec解码H.264时，configure阶段直接报错

原因：从MP4文件提取H.264数据时，没有经过h264_mp4toannexb转换，SPS/PPS被封装成avcC结构，解码器读不到。

解决：不依赖MediaCodec自己解析csd的情况，用FFmpeg转换后再提取。或者手动解析mp4的avcCbox，把SPS和PPS单独抽出后写入csd-0和csd-1。如果是从摄像头实时编码拿MediaCodec输出，需要在INFO_OUTPUT_FORMAT_CHANGED回调里读取csd-0和csd-1，这两个字段在MediaFormat里，直接传给解码端。

6. FFmpeg命令行在Android调试中的实际应用：三板斧

6.1 快速定位视频元数据：ffprobe的隐藏用法

开发中遇到“不知道这个文件是什么编码”的情况，ffprobe一行命令比任何播放器信息面板都可靠：

ffprobe -v error -show_streams -show_format input.mp4

重点看codec_name、profile、level、width、height、r_frame_rate、avg_frame_rate这几个字段。其中r_frame_rate是帧率的分数表示，如30000/1001表示29.97fps，需要做换算后再传参给编码器。解码器的profile和level决定兼容性，Android设备硬解能力差异巨大，高Profile的H.264（如High Profile Level 5.1）在老设备上可能不支持。

6.2 提取关键帧走查GOP结构：线上问题的离线复现

遇到线上视频无法seek或seek后花屏严重的问题，可以直接提取所有关键帧看看分布是否合理。先确认GOP间隔正常，如果发现I帧间隔分布不均、某段长时间没有关键帧，用前面提到的select='eq(pict_type\,I)'命令解析。多数情况是编码器参数没有配合好：要么没设-g，要么没关sc_threshold。为排查目标，可以用固定GOP重编码一份测试文件。推荐步骤是先做copy转封装备份，再对备份做完整分析，不要直接在生产文件中反复操作，避免破坏原始数据。

6.3 用YUV帧检查法验证颜色空间配置

视频偏色且只偏色不花屏时，先怀疑解码端颜色空间解析错误。做法是抽出一帧未编码的YUV数据，分别按I420与NV21两种布局去显示，看哪种与预期颜色一致，再核对编码器输入端的像素格式是否与此匹配。命令可以直接用FFmpeg转换：

ffmpeg -i input.mp4 -pix_fmt yuv420p note.yuv

打开后如果画面呈紫绿调，基本可以判定实际是NV12或NV21，但被按I420方式解析了。Android相机输出在多数设备上是NV21（Y平面 + VU交错），而部分华为、三星设备输出NV12（Y平面 + UV交错），代码里要通过getPixelStride()判断，写死任何一种格式都是潜在隐患。

这套基础理论的价值，是在问题发生之前就预判到它。从那以后，我每次接到新的视频相关需求，都强制走一遍固定流程：先确认视频编码格式和容器，再核对时间戳口径，最后在真机上用ffprobe验证一遍输出参数。这份PDF里的不少内容初看是枯燥概念，但每一条命令背后都是可以落地的排查手段，希望帮到你更快定位到问题。

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