做音视频开发的同事应该都知道Android 系统默认的 MP4 文件写入逻辑集中在 Mpeg4Writer 这一层。它不是独立 App 能直接调用的库而是平台多媒体框架的一部分负责把编码后的音频和视频数据按 MP4 规范封装成文件。很多人第一次接触它是在排查录制出来的视频无法播放、音画不同步或者文件体积异常这类问题时。本文从实际开发视角出发把 MP4 容器格式、Mpeg4Writer 的写入路径、常见坑位和排查手段串起来讲清楚适合正在做录制功能、流媒体封装、视频编辑引擎的开发者参考。你可以把它当一份源码分析笔记也可以当问题排查手册用。1. MP4 到底在封装什么先理解容器与编码的关系1.1 为什么选 MP4 而不是其他封装格式先回答一个经常被问到的问题Android 录制模块为什么默认走 MP4市面上的封装格式很多MKV、AVI、TS、FLV 各有各的适用场景。MP4 的底层规范是 ISO/IEC 14496-12它是一个面向媒体文件的通用容器标准前身是 QuickTime 的 MOV 格式。它的优势非常明确硬件解码器支持广泛从手机到电视盒子再到网页播放器基本通吃流式播放场景下有 fragmented MP4 的扩展方案文件结构紧凑适合长期存储和二次编辑。我整理过一份简单的对比表方便你直观理解封装格式容器规范流媒体友好度兼容性文件损坏后恢复难度MP4ISO/IEC 14496-12高支持 fMP4极高中等moov 丢失影响较大MKVEBML中等较高较低分段存储较灵活AVIRIFF低高老设备高索引在文件尾部容易丢TSMPEG-2 TS极高直播高低每个包独立可解Android 平台原生选择 MP4 作为 Camera 和 MediaRecorder 的默认输出并不是拍脑袋决定的。它需要兼顾系统级硬件的解码能力、媒体扫描器的索引逻辑以及上层应用的通用性。对大多数应用开发者来说用 MediaMuxer 加 Mpeg4Writer 生成 MP4 是成本最低、收益最稳的一条路。1.2 从编码器到文件Mpeg4Writer 在链路中的坐标理解 Mpeg4Writer需要先看清它在整个录制链路中的位置。一个典型的 Android 录制流程是这样的Camera 采集画面通过 Surface 传给视频编码器麦克风采集的 PCM 数据同时送给音频编码器。两个编码器各自输出压缩码流比如 H.264/H.265 和 AAC这些码流是纯 ESElementary Stream没有时间戳也没有文件结构。MediaMuxer 负责把两路 ES 流转成 MP4 文件而 MediaMuxer 内部在 Android 平台上的真正实现就是 Mpeg4Writer。这里有个容易误解的点MediaMuxer 是 Android 开放的 APIMpeg4Writer 是 frameworks/av/media/libmedia 里的系统组件。正常 App 开发时根本接触不到 Mpeg4Writer 的代码但你在 logcat 里搜 MPEG4Writer 经常会看到它的日志因为 MediaMuxer 最终会把写文件这事委托给它。简单说MediaMuxer 是门面Mpeg4Writer 是干活的。链路大致如下Camera/Surface ↓ 视频编码器(MediaCodec) → H.264/H.265 码流 麦克风(PCM) → 音频编码器(MediaCodec) → AAC 码流 ↓ MediaMuxer.addTrack / writeSampleData ↓ MPEG4Writer → MP4 文件在 API 层面你要做的事情通常就是三步addTrack 添加轨道信息start 开始封装writeSampleData 循环写入编码器输出的缓冲区。Mpeg4Writer 在背后做的远比这三步复杂它要维护轨道元数据、计算时间戳映射还要在合适的时机落盘生成各种 box。后续章节会逐步拆开这些细节。2. MP4 盒子结构拆解ftyp、moov 与 mdat2.1 盒子/Atom 的通用格式与嵌套关系MP4 文件本质上是一个树状结构的盒子Box集合。每个盒子由头部和负载组成头部固定包含 4 字节的 size 字段和 4 字节的 type 字段负载的内容取决于盒子的类型。size 字段是整个盒子占用的总字节数type 字段是用 ASCII 表示的四个字符比如 ftyp moov mdat。盒子的类型决定了内部的解析方式。一个最小可播放的 MP4 文件至少要有三种顶层盒子ftyp 声明文件类型和兼容性moov 存放轨道元数据mdat 存放实际的音视频采样数据。真实文件里还可能出现 free、sidx、moof 等盒子其中 moof 是 fragmented MP4 特有的后面会提到。moov 盒子本身又嵌套若干子盒子。它的结构大致是这样的moov ├── mvhd文件级时长、时间刻度 ├── trak视频轨道 │ ├── tkhd轨道头宽高、时长 │ ├── mdia │ │ ├── mdhd媒体头媒体时间刻度 │ │ ├── hdlr轨道类型 │ │ └── minf │ │ └── stbl采样表 │ │ ├── stsd编码配置如 avcC │ │ ├── stts时间到采样点映射 │ │ ├── stss关键帧索引 │ │ ├── stsc采样到块映射 │ │ ├── stsz采样大小表 │ │ └── stco块偏移表 └── trak音频轨道 └── ...把 moov 想象成一本书的目录mdat 就是正文。目录要是丢了正文再完整也没法有效读取。这就是为什么有些视频文件体积完好但播放器提示文件损坏——因为目录在文件尾部下载没完成时 moov 没落盘。2.2 时间戳、采样与轨道间的数学关系MP4 使用 timescale 和 duration 来表示时间而不是直接用毫秒。timescale 是每秒的时间单位数类似于时钟频率。视频轨常用 90000音频轨常用 44100 或 48000。假设视频轨道 timescale 是 90000帧率是 30fps那么每帧采样点的时长就是 90000 除以 30等于 3000 个时间刻度。如果音频是 44100Hz、每帧 1024 个采样那么每帧的时长就是 1024 个刻度对应约 23.2 毫秒。这里的核心数据结构是 stts 表它记录了时间戳到采样点的映射关系。播放器播放时并不是从头到尾扫描每个采样点而是先读 stts建立第几个采样点到哪个时间点的映射然后结合 stsz 表知道每个采样点有多大再利用 stsc 和 stco 找到数据在 mdat 中的实际位置。这四张表配合起来才能完成随机访问。还有一个必须绕开的概念PTSPresentation Timestamp和 DTSDecode Timestamp。在没有 B 帧的编码流里两者相同一旦出现 B 帧解码顺序和显示顺序不一致写入 stts 的时间戳必须是 PTS。我在实际项目中见过不少新手把编码器输出的 presentationTimeUs 直接当 DTS 用结果播放器花屏、快进乱跳。MPEG4Writer 内部对时间戳的处理逻辑本质上就是基于这些表结构反向构建的。3. Mpeg4Writer 写入流程分析3.1 addTrack轨道如何建立CSD 如何放置Mpeg4Writer 的轨道创建依赖 addTrack 传入的 MediaFormat。这个 Format 通常由编码器通过 outputFormat 回调给出里面携带了编码格式、分辨率、采样率、声道数、比特率以及两类关键的 CSD 数据csd-0 和 csd-1。对视频来说这两个数据就是 H.264 的 SPS 和 PPS对 AAC 来说csd-0 是 AudioSpecificConfig。CSD 数据必须写入 stsd 盒子对应的编码配置项里。以 H.264 为例视频轨的 stsd 里会有一个 avcC 盒子avcC 内部结构包含 SPS、PPS 以及一些编码参数。播放器靠 avcC 里的 SPS/PPS 初始化解码器上下文如果这个信息缺失解码器拿到 mdat 里的数据也不知道该怎么解表现就是画面黑屏但音频正常或者无法播放此视频。addTrack 有一个常见的使用禁忌必须在 start 之前调用且轨道一旦添加就不允许修改。Mpeg4Writer 在添加轨道时会校验格式是否合法比如视频宽高是否为 0、音频通道数是否越界。我在项目里踩过的一个坑是部分机型在 MediaCodec 刚启动时 outputFormat 里还没有 csd-0直接 addTrack 导致封装的视频轨道缺少 SPS/PPS。正确的做法是等编码器输出第一帧后重新获取 outputFormat确认 csd 存在后再 addTrack。3.2 writeSampleData从 BufferInfo 到 mdat 的一条完整路径writeSampleData 是整个写入流程的高频操作每编码完一帧都会调用一次。它接收两个参数一个轨道索引和一个 ByteBuffer对应编码器输出的完整压缩帧同时 BufferInfo 里携带了 flag、大小和时间戳。Mpeg4Writer 拿到这些数据后会先把数据临时写进 mdat 区域同时记录这个采样点的偏移、大小和时间戳信息到内部的 Track 对象里。这里有一个设计关键MP4 文件不是按时间顺序把音视频帧交错排列在 mdat 里的而是用 chunk 的概念把采样点分块。一个 chunk 包含同一轨道的一个或多个连续采样点。音视频轨道的 chunk 会交错排列。stsc 表记录每个 chunk 里有多少个采样点stco 表记录每个 chunk 的起始文件偏移。Mpeg4Writer 会根据缓冲区大小和写入策略决定多少个采样点组成一个 chunk。BufferInfo 里的 flag 也很重要。MediaCodec.BUFFER_FLAG_KEY_FRAME 表示当前帧是关键帧也就是 IDR 帧。Mpeg4Writer 会把关键帧的信息单独记下来最后生成 stss 表。stss 表的作用是实现随机访问播放器拖动进度条时首先要找到离目标时间最近的关键帧从这个关键帧开始解码。如果你的录制流没有周期性产生关键帧那么整个视频轨的 stss 表可能只有一个条目快进体验会非常差。写入性能方面Mpeg4Writer 并不是每一帧都调用文件系统写盘一次而是做了一定的缓冲和批量写入。文件写入的粒度会影响录制的稳定性和产物大小。实测下来如果底层文件系统的 write 调用过于频繁4K 录制时很容易出现掉帧和 CPU 占用过高。3.3 时间戳同步与音视频同步逻辑Mpeg4Writer 在写入采样点时会做时间戳的归一化和同步处理。这里的核心问题是视频编码器输出的时间戳和音频编码器输出的时间戳各自独立演化需要把它们映射到同一个参考时钟上。从 Android 的应用层视角编码器的 presentationTimeUs 来自你自己填写的值。如果你用系统当前的 SystemClock.elapsedRealtimeNanos 作为参考基本能保证音视频在同一时间坐标系下。Mpeg4Writer 内部会做进一步处理它会把时间戳换算成对应轨道 timescale 下的刻度值然后在生成 stts 表时使用相邻两个采样点的时间差作为该采样点的 duration。这里有个容易被忽视的细节B 帧的存在会让时间戳不是单调递增的。Mpeg4Writer 需要把乱序的 PTS 整理成正确的时间-采样映射同时保证 buffer 输出顺序不变。如果时间戳出现抖动比如某一帧比前一帧早Mpeg4Writer 会对抖动做一定容忍和修正。过于夸张的时间戳倒置会导致生成的 stts 表出现负的 duration播放器要么不认这个文件要么播放时跳帧。4. 常见问题与排查技巧实录4.1 音画不同步与时间戳异常录制完成后播放发现音画不同步是最常见的故障之一。先别急着怀疑 Mpeg4Writer大多数情况问题出在上层时间戳管理。排查第一步是用 MediaExtractor 读取生成文件的轨道把每一帧的时间戳打印出来。具体做法是用 MediaExtractor 的 selectTrack 选中轨道循环调用 readSampleData然后用 track.getSampleTime() 拿到每个采样点的时间戳。我写过很多次这种调试脚本简单实用val extractor MediaExtractor() extractor.setDataSource(filePath) for (i in 0 until extractor.trackCount) { val format extractor.getTrackFormat(i) val mime format.getString(MediaFormat.KEY_MIME) extractor.selectTrack(i) Log.d(Track, track $i - $mime) while (true) { val info MediaCodec.BufferInfo() val ret extractor.readSampleData(byteBuffer, 0) if (ret 0) break Log.d(Sample, track$i time${extractor.sampleTime} size$ret) extractor.advance() } extractor.unselectTrack(i) }对比音视频轨的时间戳曲线如果偏差是固定的说明两个编码器的起始时间戳没有对齐如果是逐渐增大的说明其中一路编码器的时钟存在漂移。前者在写入采样点时做一次时间戳平移即可修正后者需要用一个统一的单调时钟来驱动两路时间戳而不是让两个编码器各自随便填。时间戳抖动也会造成不同步。比如视频帧率是 30fps理想情况下每帧间隔 33.3 毫秒但编码器实际输出的时间戳偶尔出现 32 毫秒、35 毫秒的波动。MP4 本身对时间戳抖动有一定容忍度但抖动超过一个帧周期后播放器就难以正确同步了。4.2 文件打不开或只有黑屏文件能生成但打不开或黑屏这类问题多半和 CSD 数据丢失、轨道格式不完整或者 moov 盒子损坏有关。先检查日志如果 logcat 里有 failed to add this track 或格式校验失败的信息基本可以确定 MediaFormat 不完整。黑屏且无声音的情况优先查视频轨的 avcC。用十六进制工具打开文件找到 stsd 盒子里的 avcC确认 SPS 和 PPS 是否存在。通常 SPS 以 67 开头PPS 以 68 开头NAL 头都是 0x00 0x00 0x00 0x01 或者 0x00 0x00 0x01。如果发现 avcC 里的参数集长度字段为 0说明 addTrack 时传入的 csd-0/csd-1 是空的。另一种常见的黑屏原因是 I 帧间隔设置不当。部分编码器配置里如果关键帧间隔设得过大录制时间又短整个文件可能只有开头一个关键帧。播放器从零开始播放时能找到它但一旦做了 seek 操作就很难定位。4.3 录制中掉帧、卡顿的排查思路录制过程中出现掉帧和卡顿首要怀疑对象不是 Mpeg4Writer而是编码器和文件系统。Mpeg4Writer 毕竟是纯写文件逻辑它不会主动丢帧。你可以通过 strace 观察录制进程的 write 系统调用看看写文件是否频繁阻塞。如果每次 write 耗时波动很大考虑是不是存储卡性能不足或者文件系统碎片化。录制约 4K 级视频时码率可能高达几十 Mbps一秒钟的数据量是几 MB。普通 SD 卡的随机写入速度很容易成为瓶颈。Mpeg4Writer 虽然内部有缓冲但面对持续的高码率写入如果底层存储跟不上系统会通过背压机制反馈到编码器链路最终表现就是掉帧。排查时可以抓 trace 文件观察 MediaCodec 的 queue 深度和 Mpeg4Writer 的写盘耗时。如果发现写盘耗时有明显的周期性尖峰大概率是文件系统后台 flush 导致的。5. 从 Mpeg4Writer 源码里学到的几个架构设计经验5.1 把写文件与编码解耦的价值Mpeg4Writer 体现了一个很好的分层思想编码器只负责产生压缩码流多路复用器只负责把码流按格式规范封装成文件。两者通过缓冲区解耦复杂度被隔离在各自的模块内部。这套设计对上层的好处是我们可以自由替换编码器比如从 H.264 换成 H.265甚至换用硬件编码器而文件的封装格式保持不变。同样的思路也值得应用在业务层。我在自己的录制模块里通常会把采集、编码、封装、上传四个阶段拆成独立的 Pipeline 节点每个节点有独立的线程和缓冲队列。这样无论后期要加美颜特效还是要做断点续传都不需要推翻整体结构。另一个启发是格式知识的沉淀方式。Mpeg4Writer 的源码里大量使用 Box 的抽象每个 Box 类只负责自己那一块数据的读写。如果你打算自己实现一个轻量级的 MP4 封装器完全可以参照这套抽象把 ftyp、mvhd、trak、stbl 都定义成独立的结构体组合起来就是完整的 moov。5.2 时间戳驱动的设计哲学做录制功能久了你会发现时间戳是整个系统的灵魂。编码、封装、播放三端全靠时间戳串联哪个环节对时间的理解不一致最终产物就会出问题。Mpeg4Writer 虽然做了很多时间戳的修正和映射工作但它无法识别业务层的时间错误。如果你把编码器的 presentationTimeUs 填得乱七八糟它只能按规范去写栈表出来的文件照样不正常。以我个人的经验做一个录制模块第一件事就是建立一个统一单调时钟源这个时钟源最好基于 SystemClock.elapsedRealtimeNanos因为它不受系统休眠和手动改时间的影响。采集层的每一帧数据都要带着这个时钟源派生出来的时间戳一路传到编码器再传到 Mpeg4Writer。不要在每一层重新取当前时间那样累积的误差会越来越大。最后再分享一个小技巧每次写完文件后别急着收工先用 ffprobe 或者 mp4info 看一眼输出文件的轨道信息、时长和编码参数。这个习惯能帮你把 80% 的格式问题在测试阶段拦截下来省得等线上用户反馈了再回来翻日志。