简介面向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如NV12Y平面后紧跟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 selecteq(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与YUVAndroid开发者必须记住的格式差异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的类型值为7PPS的类型值为8IDR帧的类型值为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.264SPS/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帧间隔分布不均、某段长时间没有关键帧用前面提到的selecteq(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相机输出在多数设备上是NV21Y平面 VU交错而部分华为、三星设备输出NV12Y平面 UV交错代码里要通过getPixelStride()判断写死任何一种格式都是潜在隐患。这套基础理论的价值是在问题发生之前就预判到它。从那以后我每次接到新的视频相关需求都强制走一遍固定流程先确认视频编码格式和容器再核对时间戳口径最后在真机上用ffprobe验证一遍输出参数。这份PDF里的不少内容初看是枯燥概念但每一条命令背后都是可以落地的排查手段希望帮到你更快定位到问题。本文还有配套的精品资源点击获取