简介《Android音视频开发与处理.pdf》是一份面向 Android 开发者的音视频入门与进阶学习资料围绕帧、帧率、码率、分辨率、IPB 帧、DTS/PTS、颜色空间等核心概念逐一拆解基础理论与处理流程并结合 FFmpeg 常见命令与 Android 原生多媒体框架说明落地方式帮助读者快速建立完整的音视频认知体系。压缩包仅含 1 个 PDF 文件整体大小 6.39MB。PDF 内按章节组织包含音视频基础理论、Android 音视频处理框架、应用场景以及工具与开源项目等模块结构清晰便于系统阅读和检索。目前已有 1213 人学习浏览该资源适合需要系统学习音视频基础知识或配合 MediaCodec、AudioTrack 等 API 开发播放、录制、编码功能的 Android 工程师。这份 PDF 在讲清基础概念的同时穿插了大量可复用的 FFmpeg 命令例如视频抽帧、图片合成 GIF、MP4 转 YUV、码率控制、关键帧截取等同时对 YUV/RGB 转换、DTS/PTS 等易混淆点做了集中说明既适合初学入门也能作为开发过程中的速查手册。1. 从录像到推流Android 音视频开发到底在解决什么问题接手过这类需求的人都有体会同样一段画面用系统相机录出来一切正常换到自己 App 里录要么播放器不认文件要么音画不同步要么低端机上预览掉帧掉到没法看。Android 音视频开发与处理本质上是在系统提供的相机、编码器、渲染管线之上自己把采集、编码、封装、解码、播放这条链路串起来并且对每一段的参数都做到心里有数。MediaRecorder 那种黑匣子式的封装适合快速出 demo不适合对延迟、码率、画质有硬指标的生产环境。这篇文章面向的是准备自己接管音视频链路的从业者你要么在做一个录像类功能要么在做直播推流 SDK要么在给播放器做自定义渲染。我按采集与预览、编码与封装、解码与渲染、踩坑排查这条主线往下讲命令和参数都给可复现的版本你照着搭完基本能跑通一条端到端的链路。2. 采集与预览Camera2 管线、预览帧率与 Surface 的几个关键选择2.1 打开 Camera2 设备从 Camera1 迁移过来必调的 5 个参数Camera1 时代的setPreviewDisplaystartPreview两行代码到了 Camera2 变成了一套基于回调的状态机。很多从老代码迁移过来的项目第一个坑就是openCamera报权限错误或者回调不触发。标准打开流程是权限检查 → 拿到CameraManager→ 获取CameraCharacteristics→ 选择输出尺寸 →openCamera回调里创建会话。private CameraDevice cameraDevice; private CameraCaptureSession captureSession; private Size previewSize; private Size videoSize; private void openCamera() { CameraManager manager (CameraManager) getSystemService(CAMERA_SERVICE); try { String cameraId manager.getCameraIdList()[0]; CameraCharacteristics characteristics manager.getCameraCharacteristics(cameraId); // 1. 从 StreamConfigurationMap 里选一组预览和录制尺寸 StreamConfigurationMap map characteristics.get( CameraCharacteristics.SCALER_STREAM_CONFIGURATION_MAP); previewSize choosePreviewSize(map.getOutputSizes(SurfaceHolder.class)); videoSize chooseVideoSize(map.getOutputSizes(SurfaceTexture.class)); // 2. 权限确认之后再 open否则回调直接收不到 if (checkSelfPermission(Manifest.permission.CAMERA) PackageManager.PERMISSION_GRANTED) { manager.openCamera(cameraId, stateCallback, backgroundHandler); } } catch (CameraAccessException e) { // 相机被占用或不存在需要向上层抛业务错误 } } private final CameraDevice.StateCallback stateCallback new CameraDevice.StateCallback() { Override public void onOpened(CameraDevice camera) { cameraDevice camera; createCaptureSession(); } Override public void onDisconnected(CameraDevice camera) { cameraDevice.close(); cameraDevice null; } Override public void onError(CameraDevice camera, int error) { cameraDevice.close(); cameraDevice null; } };这段代码里有五个参数值得你逐个确认。第一个是getCameraIdList()[0]前摄后摄的顺序在不同厂商上不统一量产代码不要硬编码下标。第二个是预览尺寸getOutputSizes(SurfaceHolder.class)拿到的列表和getOutputSizes(SurfaceTexture.class)不完全一致用错类别可能选出一个摄像头根本不支持的组合。第三个是chooseVideoSize()的逻辑优先挑 16:9 且不超过 1920 宽度的尺寸因为大多数编码器对 1920x1080 支持最成熟4K 在低端机上编码耗时不可控。第四个是backgroundHandler它必须绑定一个Looper否则回调堆积在主线程会导致 ANR。第五个是onDisconnected和onError都要释放资源很多线上问题就是只写了onOpened没写错误分支设备被别的 App 抢占后自己这边一直挂着死会话。2.2 预览与采集分离用两个 Surface 同时做取景和录制很多方案里预览用一个SurfaceView录制用MediaRecorder两者各跑各的结果预览分辨率 1920x1080、录制分辨率 1280x720切换时黑屏录制出来的画面比例还不对。正确的做法是让相机把同一路画面同时输出到两个目标上——一个用于预览上屏一个作为编码器输入。private void createCaptureSession() { try { // 预览 Surface 来自 SurfaceView 的 holder Surface previewSurface previewView.getHolder().getSurface(); // 录制 Surface 通过 SurfaceTexture 创建纹理 ID 随意这里用 0 占位 SurfaceTexture texture new SurfaceTexture(0); texture.setDefaultBufferSize(videoSize.getWidth(), videoSize.getHeight()); Surface encoderSurface new Surface(texture); ListSurface targets new ArrayList(); targets.add(previewSurface); targets.add(encoderSurface); cameraDevice.createCaptureSession(targets, new CameraCaptureSession.StateCallback() { Override public void onConfigured(CameraCaptureSession session) { captureSession session; startRecordingTargets(previewSurface, encoderSurface); } Override public void onConfigureFailed(CameraCaptureSession session) { // 说明 targets 组合不被支持常见原因是预览和编码尺寸超过传感器能力 } }, backgroundHandler); } catch (CameraAccessException e) { // 会话创建失败 } } private void startRecordingTargets(Surface previewSurface, Surface encoderSurface) { try { CaptureRequest.Builder builder cameraDevice.createCaptureRequest( CameraDevice.TEMPLATE_RECORD); builder.addTarget(previewSurface); builder.addTarget(encoderSurface); // 打开连续对焦录像过程中不要靠用户手点对焦 builder.set(CaptureRequest.CONTROL_AF_MODE, CaptureRequest.CONTROL_AF_MODE_CONTINUOUS_VIDEO); captureSession.setRepeatingRequest(builder.build(), null, backgroundHandler); } catch (CameraAccessException e) { // 请求发送失败 } }这里的核心是createCaptureRequest选对模板TEMPLATE_RECORD相对TEMPLATE_PREVIEW会限制自动曝光和自动白平衡的调节范围避免录像过程中画面忽明忽暗如果你用TEMPLATE_PREVIEW跑录像拍窗外时画面会频繁过曝。setDefaultBufferSize必须和编码器输入尺寸一致否则SurfaceTexture输出的 Buffer 大小和编码器期望的不匹配花屏概率很高。2.3 帧率不稳时先别怪编码器预览帧率和控制参数的调参顺序项目上线后最常见的反馈是“画面卡”排查时大家习惯性先查编码器耗时但很多情况是采集端就没按 30fps 送帧。Camera2 的帧率控制有两个入口一个是CONTROL_AE_TARGET_FPS_RANGE一个是SENSOR_FRAME_DURATION。前者是告诉相机系统“我想要这个帧率区间”后者是直接指定每帧时长纳秒。我的建议是只调前者不要动后者。// 固定 30fps上限和下限都设成 30意思是这路请求必须按 30fps 跑 builder.set(CaptureRequest.CONTROL_AE_TARGET_FPS_RANGE, new Range(30, 30));如果设备在低光环境下降帧优先检查CONTROL_AE_MODE。默认的自动曝光模式在光线不足时为了提亮会拉长曝光时间帧率自然掉到 15fps 甚至更低。生产级方案通常会设CONTROL_AE_MODE_ON_AUTO_FLASH或者直接在预览页把闪光灯状态暴露给用户。另外锁帧率失败时去看CaptureResult.get(CaptureResult.SENSOR_TIMESTAMP)的时间戳间隔间隔是 33ms 的整数倍就说明相机端是稳定的问题在编码器间隔抖动说明相机端就没锁住此时调编码器没有意义。这两个排查方向能帮你快速定位“画面卡”的负责模块。3. 编码与封装MediaCodec 与 MediaMuxer 的最低可用链路3.1 编码器配置码率、帧率、I 帧间隔怎么设才不翻车采集端把 YUV 数据送进编码器之后编码参数直接决定文件体积、画质和关键帧间隔。用MediaCodec做 H.264 编码时标准配置是COLOR_FormatSurface输入模式——相机的 Surface 可以直接接到编码器的输入 Surface省去手动拷贝 YUV 的一步也避免了 ByteBuffer 模式下的内存抖动。MediaFormat format new MediaFormat(); format.setString(MediaFormat.KEY_MIME, video/avc); format.setInteger(MediaFormat.KEY_WIDTH, 1280); format.setInteger(MediaFormat.KEY_HEIGHT, 720); format.setInteger(MediaFormat.KEY_BIT_RATE, 4_000_000); format.setInteger(MediaFormat.KEY_FRAME_RATE, 30); format.setInteger(MediaFormat.KEY_I_FRAME_INTERVAL, 2); format.setInteger(MediaFormat.KEY_COLOR_FORMAT, MediaCodecInfo.CodecCapabilities.COLOR_FormatSurface); MediaCodec encoder MediaCodec.createEncoderByType(video/avc); encoder.configure(format, null, null, MediaCodec.CONFIGURE_FLAG_ENCODE); Surface inputSurface encoder.createInputSurface(); encoder.start();码率和分辨率、帧率的关系我给一组可以直接抄的起点值720p30 用 4Mbps1080p30 用 8Mbps4K30 用 20Mbps。往上调画质变好但体积线性上涨往下调超过 40%暗部场景会出现明显的块效应。KEY_I_FRAME_INTERVAL单位是秒2 秒一个关键帧适合大多数点播场景直播场景建议 1 秒否则用户从中间拖进度条时要等关键帧才能起画面。这里要注意的是KEY_FRAME_RATE对部分编码器只是“参考值”最终帧率由你喂数据的速度决定所以采集端锁帧率这件事在编码章节依然重要。3.2 编码输出循环手动模式还是异步模式编码器启动后输出端是一个循环不断拿数据。老项目里常见的是手动dequeueOutputBuffer轮询新项目建议直接上setCallback异步模式避免循环里卡住主线程。不过异步回调里的线程池要注意回调线程和写文件的线程不是同一个视频数据和音频数据的写入顺序必须串行化。MediaCodec.BufferInfo info new MediaCodec.BufferInfo(); while (!isEncodingFinished) { // 超时时间设 10ms避免空转耗电又能及时响应停止请求 int outIndex encoder.dequeueOutputBuffer(info, 10_000); if (outIndex MediaCodec.INFO_TRY_AGAIN_LATER) { continue; } if (outIndex 0) { ByteBuffer outBuf encoder.getOutputBuffer(outIndex); // 直接把编码后的 H.264 数据写入 muxer if (muxer ! null !isEncodingFinished) { muxer.writeSampleData(videoTrackIndex, outBuf, info); } encoder.releaseOutputBuffer(outIndex, false); } }这段手动循环里dequeueOutputBuffer有两个关键返回值INFO_TRY_AGAIN_LATER代表暂时没数据继续等INFO_OUTPUT_FORMAT_CHANGED代表编码器输出格式确定此时必须重新addTrack并muxer.start()顺序反了会直接崩。向 muxer 写数据时info.bufferSize和info.presentationTimeUs必须取的是这个 buffer 自己的值不能全局复用——很多人写完后发现视频能播但时间轴是乱的就是这两字段被覆盖了。3.3 MediaMuxer 混流音视频轨时间戳同步的三种对齐方式单独的视频轨能播但加上音频轨就音画不同步这是混流阶段最典型的问题。MediaMuxer本身不做时间校准它只是把你给的时间戳原样写进 MP4。所以时间戳怎么算是你自己的责任。三种常见做法里最可靠的是以音频时钟为基准。// 视频时间戳用系统时钟换算成微秒并确保单调递增 long videoPtsUs System.nanoTime() / 1000; if (videoPtsUs lastVideoPtsUs) { videoPtsUs lastVideoPtsUs 1; } lastVideoPtsUs videoPtsUs; // 音频时间戳按采样数累计比读系统时钟稳定得多 long audioPtsUs totalAudioFramesRead * 1_000_000L / sampleRate;以音频时钟为基准的原因很简单音频数据是连续采样的帧数累计和时间严格线性视频的 Surface 输入模式时间戳来自相机硬件时钟本身没毛病但经过编码器排队后可能抖动。所以先把视频 PTS 按系统时钟算好再拿音频 PTS 去对齐它——如果某一时刻视频 PTS 落后音频超过一个阈值就少传一帧领先太多就重复上一帧。短视频项目里很多人直接拿System.currentTimeMillis()当 PTS但它返回的是挂钟时间系统在 NTP 校时后往回跳一下你的视频就定格一秒这个坑我踩过。4. 解码与渲染从硬解到 OpenGL 上屏的完整路径4.1 硬解与软解的选择MediaCodec 解码器实例化与能力查询解码端的选择比你想象的简单Android 8 之后绝大多数设备都支持了MediaCodec的硬解优先用硬解只有两种场景需要退到软解——一种是目标视频编码格式硬件不支持比如设备没带 HEVC 解码器但你要播 HEVC另一种是硬件解码耗时波动太大在低端机上丢帧严重。判断硬解是否支持的代码不算复杂MediaCodecList list new MediaCodecList(MediaCodecList.ALL_CODECS); String[] supportedTypes list.getSupportedTypes(); boolean hasHwHevc false; for (String type : supportedTypes) { if (type.equals(video/hevc)) { hasHwHevc true; break; } } if (!hasHwHevc) { // 降级到软解注意软解会占 CPU主线程不能参与解码 }另一个容易忽略的点是解码器的KEY_MAX_INPUT_SIZE。很多播放器项目里从网络流拿到一个 chunk 就直接往解码器的输入 buffer 里塞如果 chunk 大小超过解码器声明的最大输入尺寸queueInputBuffer会抛异常。正确做法是把网络数据先拼进自己的缓冲区等一个完整帧或者累积到KEY_MAX_INPUT_SIZE的 80% 再送进去。顺带提醒实例化解码器时传的MediaFormat里必须带上csd-0和csd-1也就是编码器输出的 SPS/PPS没有它们硬解首帧会花屏。4.2 Surface 输出与 ByteBuffer 输出两套渲染路径的边界解码器输出有两种模式Surface输出和ByteBuffer输出。Surface 模式效率最高解码器直接把画面渲染到你提供的Surface上零拷贝ByteBuffer 模式拿到的是 YUV 原始数据适合要做滤镜、截图、人脸识别的场景但每帧多一次拷贝内存压力大。// Surface 模式configure 时传入 Surface解码器内部直接渲染 MediaCodec decoder MediaCodec.createDecoderByType(video/avc); decoder.configure(format, renderSurface, null, 0); decoder.start(); // 如果想要 YUV 做处理configure 传 null然后从输出 buffer 拿数据 decoder.configure(format, null, null, 0);选型建议很直接如果只是播放器用 Surface 模式把renderSurface交给SurfaceView或TextureView如果一定要滤镜那就用GLSurfaceView 自定义 EGL把解码输出接到SurfaceTexture上在 Fragment Shader 里处理滤镜。这里有个常见误用很多人以为拿到 ByteBuffer 的 YUV 就能直接送滤镜实际上 Android 上 YUV 的排列有 NV21、NV12、YV12 多种直接当 RGB 用必然是绿的。统一做法是让 OpenGL 的texImage2D把 YUV 拆成三个 plane 上传或者先用RenderScript转成 RGBA 再上传后者实现快但低端机耗时不可控。4.3 音画同步AudioTrack 时钟作主时钟的常见做法播放器项目里音画同步是最后一道门。以音频为主时钟是业界惯例因为人耳对音频抖动更敏感。标准实现是拿到音频播放的位置再决定视频帧是等还是丢。// 每秒播放的采样数 → 当前播放头对应的时间微秒 long playHeadUs audioTrack.getPlaybackHeadPosition() * 1_000_000L / sampleRate; // 视频帧带自己的 PTS和音频时钟比对 long delayUs videoFramePtsUs - playHeadUs; if (delayUs 30_000) { // 视频快了暂停输出等音频追上 videoRenderer.pause(); } else if (delayUs -10_000) { // 视频慢了丢帧跟上否则积压会越来越大 videoRenderer.skipToNext(); }阈值取多少有讲究30ms 和 -10ms 是我常用的经验值。正阈值不能太小否则视频一抖动就停顿看起来更卡负阈值不能太大否则用户感知到画面明显落后于声音。getPlaybackHeadPosition在MODE_STREAM下有效如果你用MODE_STATIC播放短音频这个接口会一直返回 0音画同步就不成立了。另外微信视频通话这类低延迟场景里音频时钟还要处理设备切换——蓝牙耳机断开瞬间播放头会跳变此时要重置基准时间否则同步逻辑会疯掉。5. 避坑手册Android 音视频开发最常见的 5 个翻车现场5.1 花屏与绿屏关键帧丢失与 I 帧间隔的玄学现象录出来的视频在某些播放器上开头是花的快进后要等几秒才有画面。 原因MP4 封装时视频轨的第一帧如果不是关键帧IDR播放器必须找到第一个 IDR 才能出画编码器输出有时把 I 帧的 buffer 标成BUFFER_FLAG_SYNC_FRAME但 muxer 写入顺序或 PTS 错乱会导致这个标记丢失。另外KEY_I_FRAME_INTERVAL设得太大比如 10 秒时任何丢包或seek都会面临长时间无参考帧。 解决把 I 帧间隔压到 2 秒内录制开始时主动请求一个关键帧代码是Bundle params new Bundle(); params.putInt(MediaCodec.PARAMETER_KEY_REQUEST_SYNC_FRAME, 0); encoder.setParameters(params);。如果你的业务允许录制出的 MP4 再跑一遍转封装把 B 帧去掉也能缓解部分播放器的兼容问题——B 帧在 Android MediaCodec 编码器里一般不产但厂商实现偶尔不听话。5.2 录制视频没有声音AudioRecord 缓冲区与权限申请的先后顺序现象视频画面正常音频轨道存在但全是静音。 原因AudioRecord读取线程因为缓冲区太小不断丢数据或者是权限弹窗还没点“允许”就开始startRecording导致状态直接进入 ERROR。 解决按AudioRecord.getMinBufferSize(sampleRate, channelConfig, audioFormat)的返回值乘 2 创建缓冲区。startRecording之前检查RECORD_AUDIO权限并在onRequestPermissionsResult回调里再启动线程。注意AudioRecord读不到数据时read()返回负数很多人忽略了这个返回值把无效数据全写进了文件等播放时才发现是一段噪声。5.3 旋转 90 度后画面变形rotation 字段与 MediaFormat 的配合现象竖屏拍摄的视频播放时是横的或者横竖切换后画面被拉伸。 原因相机传感器默认是横向安装输出画面的旋转角度存在CameraCharacteristics.SENSOR_ORIENTATION里。你手动把预览旋转了但编码器那里还是原始角度。 解决一个思路是直接在编码前把 YUV 旋转但 O(1) 开销的是在MediaMuxer里做不过 muxer 的旋转能力有限。更通用的方案是在MediaFormat里把KEY_ROTATION设为 90/270播放器会按这个角度渲染。要校验这个角度是否生效最简单的方法是录一段竖屏视频用系统播放器打开看方向。厂商这块参差不齐有的只认 90 和 270有的 180 也会出错所以生产环境里旋转角度要透传给播放器别在文件里写死。5.4 内存暴涨与 OOMBuffer 释放时机现象录制或播放 10 分钟后 App 内存持续上涨低端机上 OOM。 原因编码器的输出 buffer 没有释放ByteBuffer 模式下解码输出的 YUV 数据被业务层持有没有releaseOutputBufferImageReader拿到的Image没有close()。其中 ImageReader 是最隐蔽的它由底层 BufferQueue 管理不 close 的话 BufferQueue 耗尽采集中断。 解决编码器循环里releaseOutputBuffer必须在writeSampleData之后立刻调用不要在业务回调里做重活。任何拿出来的Image用完即close。另外SurfaceView和TextureView的选择也影响内存——TextureView 是离屏渲染会一次性分配整块显存SurfaceView 是独立窗口内存占用小低端机优先。5.5 不同机型表现不一致从三个固定项查起现象同一条链路在 A 设备上流畅跑 30fps在 B 设备上预览正常但录制只有 15fps。 原因三个固定项不匹配。一是颜色格式编码器的COLOR_FormatSurface虽然通用但 ByteBuffer 模式下各厂商支持的ColorFormat不同常见是COLOR_FormatYUV420SemiPlanar和COLOR_FormatYUV420Planar混用。二是编码 Level部分设备不支持 4K 或 1080p60 的 High Level配置过高时硬件编码器直接降级或拒绝。三是尺寸对齐1080p 的宽高对大多数编码器是友好的但 1080x1080 这种非标准尺寸需要底层的crop信息对齐处理不好花屏。 解决代码里先通过MediaCodecInfo.CodecCapabilities查询实际支持的尺寸集合再做降级链优先 1080p30 H.264设备不支持就降 720p30。颜色格式统一用字节缓冲方式getInputImage()拿Image避免直接操作 ByteBuffer 时踩到排列不同的坑。这部分没法靠代码“一次兼容”只能靠真机矩阵测试收一份各机型上报的编码器能力日志才能把玄学变成可维护的配置表。6. 进阶用 MediaCodec 异步模式 自定义 EGL 环境做低延迟渲染前面几条链路都是把相机、编码器、解码器彼此独立调用模块边界清晰但数据搬运次数多延迟在 200ms 以上。对视频通话、直播这种场景核心优化思路是减少 Surface 到 Surface 之间的拷贝相机输出交给SurfaceTexture这个纹理直接作为编码器输入同时用 EGL 把它绑到预览窗口上整个过程不经过 CPU 拷贝。// 相机输出 Surface 直接接到编码器输入 SurfaceTexture cameraTexture new SurfaceTexture(0); cameraTexture.setDefaultBufferSize(videoWidth, videoHeight); Surface cameraEncoderSurface new Surface(cameraTexture); // 异步编码把数据搬离主线程 encoder.setCallback(new MediaCodec.Callback() { Override public void onOutputBufferAvailable(MediaCodec codec, int index, BufferInfo info) { ByteBuffer buffer codec.getOutputBuffer(index); muxer.writeSampleData(videoTrackIndex, buffer, info); codec.releaseOutputBuffer(index, false); } }); encoder.start();这套方案的核心价值在于照相机输出的 Surface 直接送进编码器编码器压缩后走网络另一端解码时把输出 Surface 直接绑定到GLSurfaceView的 EGL 环境全链路只在纹理层面流动。我自己的项目里用这套结构端到端延迟从 300ms 降到了 120ms 左右。注意两个细节EGL 环境的eglSwapBuffers必须在 GL 线程调用不要在onFrameAvailable回调里直接换缓冲另外MediaCodec.Callback的回调线程和写网络线程之间的数据交接要用无锁队列否则把网卡慢的账算到编码器头上排查会走弯路。还有一个值得养成的习惯每一步链路都加一个监控指标。采集端看SENSOR_TIMESTAMP间隔编码器看INFO_OUTPUT_FORMAT_CHANGED之后每个 buffer 的 PTS 间隔播放端看音画同步的丢帧率。没有这些数字所谓优化就是拍脑袋。我吃过大亏曾经优化了一个月的延迟最后发现是音频采样率设置错了导致播放时整体慢 5%跟渲染管线毫无关系。现在每次做音视频模块第一件事先把监控点埋好再谈优化——这套习惯希望帮到你。本文还有配套的精品资源点击获取
简介《Android音视频开发与处理.pdf》是一份面向 Android 开发者的音视频入门与进阶学习资料围绕帧、帧率、码率、分辨率、IPB 帧、DTS/PTS、颜色空间等核心概念逐一拆解基础理论与处理流程并结合 FFmpeg 常见命令与 Android 原生多媒体框架说明落地方式帮助读者快速建立完整的音视频认知体系。压缩包仅含 1 个 PDF 文件整体大小 6.39MB。PDF 内按章节组织包含音视频基础理论、Android 音视频处理框架、应用场景以及工具与开源项目等模块结构清晰便于系统阅读和检索。目前已有 1213 人学习浏览该资源适合需要系统学习音视频基础知识或配合 MediaCodec、AudioTrack 等 API 开发播放、录制、编码功能的 Android 工程师。这份 PDF 在讲清基础概念的同时穿插了大量可复用的 FFmpeg 命令例如视频抽帧、图片合成 GIF、MP4 转 YUV、码率控制、关键帧截取等同时对 YUV/RGB 转换、DTS/PTS 等易混淆点做了集中说明既适合初学入门也能作为开发过程中的速查手册。1. 从录像到推流Android 音视频开发到底在解决什么问题接手过这类需求的人都有体会同样一段画面用系统相机录出来一切正常换到自己 App 里录要么播放器不认文件要么音画不同步要么低端机上预览掉帧掉到没法看。Android 音视频开发与处理本质上是在系统提供的相机、编码器、渲染管线之上自己把采集、编码、封装、解码、播放这条链路串起来并且对每一段的参数都做到心里有数。MediaRecorder 那种黑匣子式的封装适合快速出 demo不适合对延迟、码率、画质有硬指标的生产环境。这篇文章面向的是准备自己接管音视频链路的从业者你要么在做一个录像类功能要么在做直播推流 SDK要么在给播放器做自定义渲染。我按采集与预览、编码与封装、解码与渲染、踩坑排查这条主线往下讲命令和参数都给可复现的版本你照着搭完基本能跑通一条端到端的链路。2. 采集与预览Camera2 管线、预览帧率与 Surface 的几个关键选择2.1 打开 Camera2 设备从 Camera1 迁移过来必调的 5 个参数Camera1 时代的setPreviewDisplaystartPreview两行代码到了 Camera2 变成了一套基于回调的状态机。很多从老代码迁移过来的项目第一个坑就是openCamera报权限错误或者回调不触发。标准打开流程是权限检查 → 拿到CameraManager→ 获取CameraCharacteristics→ 选择输出尺寸 →openCamera回调里创建会话。private CameraDevice cameraDevice; private CameraCaptureSession captureSession; private Size previewSize; private Size videoSize; private void openCamera() { CameraManager manager (CameraManager) getSystemService(CAMERA_SERVICE); try { String cameraId manager.getCameraIdList()[0]; CameraCharacteristics characteristics manager.getCameraCharacteristics(cameraId); // 1. 从 StreamConfigurationMap 里选一组预览和录制尺寸 StreamConfigurationMap map characteristics.get( CameraCharacteristics.SCALER_STREAM_CONFIGURATION_MAP); previewSize choosePreviewSize(map.getOutputSizes(SurfaceHolder.class)); videoSize chooseVideoSize(map.getOutputSizes(SurfaceTexture.class)); // 2. 权限确认之后再 open否则回调直接收不到 if (checkSelfPermission(Manifest.permission.CAMERA) PackageManager.PERMISSION_GRANTED) { manager.openCamera(cameraId, stateCallback, backgroundHandler); } } catch (CameraAccessException e) { // 相机被占用或不存在需要向上层抛业务错误 } } private final CameraDevice.StateCallback stateCallback new CameraDevice.StateCallback() { Override public void onOpened(CameraDevice camera) { cameraDevice camera; createCaptureSession(); } Override public void onDisconnected(CameraDevice camera) { cameraDevice.close(); cameraDevice null; } Override public void onError(CameraDevice camera, int error) { cameraDevice.close(); cameraDevice null; } };这段代码里有五个参数值得你逐个确认。第一个是getCameraIdList()[0]前摄后摄的顺序在不同厂商上不统一量产代码不要硬编码下标。第二个是预览尺寸getOutputSizes(SurfaceHolder.class)拿到的列表和getOutputSizes(SurfaceTexture.class)不完全一致用错类别可能选出一个摄像头根本不支持的组合。第三个是chooseVideoSize()的逻辑优先挑 16:9 且不超过 1920 宽度的尺寸因为大多数编码器对 1920x1080 支持最成熟4K 在低端机上编码耗时不可控。第四个是backgroundHandler它必须绑定一个Looper否则回调堆积在主线程会导致 ANR。第五个是onDisconnected和onError都要释放资源很多线上问题就是只写了onOpened没写错误分支设备被别的 App 抢占后自己这边一直挂着死会话。2.2 预览与采集分离用两个 Surface 同时做取景和录制很多方案里预览用一个SurfaceView录制用MediaRecorder两者各跑各的结果预览分辨率 1920x1080、录制分辨率 1280x720切换时黑屏录制出来的画面比例还不对。正确的做法是让相机把同一路画面同时输出到两个目标上——一个用于预览上屏一个作为编码器输入。private void createCaptureSession() { try { // 预览 Surface 来自 SurfaceView 的 holder Surface previewSurface previewView.getHolder().getSurface(); // 录制 Surface 通过 SurfaceTexture 创建纹理 ID 随意这里用 0 占位 SurfaceTexture texture new SurfaceTexture(0); texture.setDefaultBufferSize(videoSize.getWidth(), videoSize.getHeight()); Surface encoderSurface new Surface(texture); ListSurface targets new ArrayList(); targets.add(previewSurface); targets.add(encoderSurface); cameraDevice.createCaptureSession(targets, new CameraCaptureSession.StateCallback() { Override public void onConfigured(CameraCaptureSession session) { captureSession session; startRecordingTargets(previewSurface, encoderSurface); } Override public void onConfigureFailed(CameraCaptureSession session) { // 说明 targets 组合不被支持常见原因是预览和编码尺寸超过传感器能力 } }, backgroundHandler); } catch (CameraAccessException e) { // 会话创建失败 } } private void startRecordingTargets(Surface previewSurface, Surface encoderSurface) { try { CaptureRequest.Builder builder cameraDevice.createCaptureRequest( CameraDevice.TEMPLATE_RECORD); builder.addTarget(previewSurface); builder.addTarget(encoderSurface); // 打开连续对焦录像过程中不要靠用户手点对焦 builder.set(CaptureRequest.CONTROL_AF_MODE, CaptureRequest.CONTROL_AF_MODE_CONTINUOUS_VIDEO); captureSession.setRepeatingRequest(builder.build(), null, backgroundHandler); } catch (CameraAccessException e) { // 请求发送失败 } }这里的核心是createCaptureRequest选对模板TEMPLATE_RECORD相对TEMPLATE_PREVIEW会限制自动曝光和自动白平衡的调节范围避免录像过程中画面忽明忽暗如果你用TEMPLATE_PREVIEW跑录像拍窗外时画面会频繁过曝。setDefaultBufferSize必须和编码器输入尺寸一致否则SurfaceTexture输出的 Buffer 大小和编码器期望的不匹配花屏概率很高。2.3 帧率不稳时先别怪编码器预览帧率和控制参数的调参顺序项目上线后最常见的反馈是“画面卡”排查时大家习惯性先查编码器耗时但很多情况是采集端就没按 30fps 送帧。Camera2 的帧率控制有两个入口一个是CONTROL_AE_TARGET_FPS_RANGE一个是SENSOR_FRAME_DURATION。前者是告诉相机系统“我想要这个帧率区间”后者是直接指定每帧时长纳秒。我的建议是只调前者不要动后者。// 固定 30fps上限和下限都设成 30意思是这路请求必须按 30fps 跑 builder.set(CaptureRequest.CONTROL_AE_TARGET_FPS_RANGE, new Range(30, 30));如果设备在低光环境下降帧优先检查CONTROL_AE_MODE。默认的自动曝光模式在光线不足时为了提亮会拉长曝光时间帧率自然掉到 15fps 甚至更低。生产级方案通常会设CONTROL_AE_MODE_ON_AUTO_FLASH或者直接在预览页把闪光灯状态暴露给用户。另外锁帧率失败时去看CaptureResult.get(CaptureResult.SENSOR_TIMESTAMP)的时间戳间隔间隔是 33ms 的整数倍就说明相机端是稳定的问题在编码器间隔抖动说明相机端就没锁住此时调编码器没有意义。这两个排查方向能帮你快速定位“画面卡”的负责模块。3. 编码与封装MediaCodec 与 MediaMuxer 的最低可用链路3.1 编码器配置码率、帧率、I 帧间隔怎么设才不翻车采集端把 YUV 数据送进编码器之后编码参数直接决定文件体积、画质和关键帧间隔。用MediaCodec做 H.264 编码时标准配置是COLOR_FormatSurface输入模式——相机的 Surface 可以直接接到编码器的输入 Surface省去手动拷贝 YUV 的一步也避免了 ByteBuffer 模式下的内存抖动。MediaFormat format new MediaFormat(); format.setString(MediaFormat.KEY_MIME, video/avc); format.setInteger(MediaFormat.KEY_WIDTH, 1280); format.setInteger(MediaFormat.KEY_HEIGHT, 720); format.setInteger(MediaFormat.KEY_BIT_RATE, 4_000_000); format.setInteger(MediaFormat.KEY_FRAME_RATE, 30); format.setInteger(MediaFormat.KEY_I_FRAME_INTERVAL, 2); format.setInteger(MediaFormat.KEY_COLOR_FORMAT, MediaCodecInfo.CodecCapabilities.COLOR_FormatSurface); MediaCodec encoder MediaCodec.createEncoderByType(video/avc); encoder.configure(format, null, null, MediaCodec.CONFIGURE_FLAG_ENCODE); Surface inputSurface encoder.createInputSurface(); encoder.start();码率和分辨率、帧率的关系我给一组可以直接抄的起点值720p30 用 4Mbps1080p30 用 8Mbps4K30 用 20Mbps。往上调画质变好但体积线性上涨往下调超过 40%暗部场景会出现明显的块效应。KEY_I_FRAME_INTERVAL单位是秒2 秒一个关键帧适合大多数点播场景直播场景建议 1 秒否则用户从中间拖进度条时要等关键帧才能起画面。这里要注意的是KEY_FRAME_RATE对部分编码器只是“参考值”最终帧率由你喂数据的速度决定所以采集端锁帧率这件事在编码章节依然重要。3.2 编码输出循环手动模式还是异步模式编码器启动后输出端是一个循环不断拿数据。老项目里常见的是手动dequeueOutputBuffer轮询新项目建议直接上setCallback异步模式避免循环里卡住主线程。不过异步回调里的线程池要注意回调线程和写文件的线程不是同一个视频数据和音频数据的写入顺序必须串行化。MediaCodec.BufferInfo info new MediaCodec.BufferInfo(); while (!isEncodingFinished) { // 超时时间设 10ms避免空转耗电又能及时响应停止请求 int outIndex encoder.dequeueOutputBuffer(info, 10_000); if (outIndex MediaCodec.INFO_TRY_AGAIN_LATER) { continue; } if (outIndex 0) { ByteBuffer outBuf encoder.getOutputBuffer(outIndex); // 直接把编码后的 H.264 数据写入 muxer if (muxer ! null !isEncodingFinished) { muxer.writeSampleData(videoTrackIndex, outBuf, info); } encoder.releaseOutputBuffer(outIndex, false); } }这段手动循环里dequeueOutputBuffer有两个关键返回值INFO_TRY_AGAIN_LATER代表暂时没数据继续等INFO_OUTPUT_FORMAT_CHANGED代表编码器输出格式确定此时必须重新addTrack并muxer.start()顺序反了会直接崩。向 muxer 写数据时info.bufferSize和info.presentationTimeUs必须取的是这个 buffer 自己的值不能全局复用——很多人写完后发现视频能播但时间轴是乱的就是这两字段被覆盖了。3.3 MediaMuxer 混流音视频轨时间戳同步的三种对齐方式单独的视频轨能播但加上音频轨就音画不同步这是混流阶段最典型的问题。MediaMuxer本身不做时间校准它只是把你给的时间戳原样写进 MP4。所以时间戳怎么算是你自己的责任。三种常见做法里最可靠的是以音频时钟为基准。// 视频时间戳用系统时钟换算成微秒并确保单调递增 long videoPtsUs System.nanoTime() / 1000; if (videoPtsUs lastVideoPtsUs) { videoPtsUs lastVideoPtsUs 1; } lastVideoPtsUs videoPtsUs; // 音频时间戳按采样数累计比读系统时钟稳定得多 long audioPtsUs totalAudioFramesRead * 1_000_000L / sampleRate;以音频时钟为基准的原因很简单音频数据是连续采样的帧数累计和时间严格线性视频的 Surface 输入模式时间戳来自相机硬件时钟本身没毛病但经过编码器排队后可能抖动。所以先把视频 PTS 按系统时钟算好再拿音频 PTS 去对齐它——如果某一时刻视频 PTS 落后音频超过一个阈值就少传一帧领先太多就重复上一帧。短视频项目里很多人直接拿System.currentTimeMillis()当 PTS但它返回的是挂钟时间系统在 NTP 校时后往回跳一下你的视频就定格一秒这个坑我踩过。4. 解码与渲染从硬解到 OpenGL 上屏的完整路径4.1 硬解与软解的选择MediaCodec 解码器实例化与能力查询解码端的选择比你想象的简单Android 8 之后绝大多数设备都支持了MediaCodec的硬解优先用硬解只有两种场景需要退到软解——一种是目标视频编码格式硬件不支持比如设备没带 HEVC 解码器但你要播 HEVC另一种是硬件解码耗时波动太大在低端机上丢帧严重。判断硬解是否支持的代码不算复杂MediaCodecList list new MediaCodecList(MediaCodecList.ALL_CODECS); String[] supportedTypes list.getSupportedTypes(); boolean hasHwHevc false; for (String type : supportedTypes) { if (type.equals(video/hevc)) { hasHwHevc true; break; } } if (!hasHwHevc) { // 降级到软解注意软解会占 CPU主线程不能参与解码 }另一个容易忽略的点是解码器的KEY_MAX_INPUT_SIZE。很多播放器项目里从网络流拿到一个 chunk 就直接往解码器的输入 buffer 里塞如果 chunk 大小超过解码器声明的最大输入尺寸queueInputBuffer会抛异常。正确做法是把网络数据先拼进自己的缓冲区等一个完整帧或者累积到KEY_MAX_INPUT_SIZE的 80% 再送进去。顺带提醒实例化解码器时传的MediaFormat里必须带上csd-0和csd-1也就是编码器输出的 SPS/PPS没有它们硬解首帧会花屏。4.2 Surface 输出与 ByteBuffer 输出两套渲染路径的边界解码器输出有两种模式Surface输出和ByteBuffer输出。Surface 模式效率最高解码器直接把画面渲染到你提供的Surface上零拷贝ByteBuffer 模式拿到的是 YUV 原始数据适合要做滤镜、截图、人脸识别的场景但每帧多一次拷贝内存压力大。// Surface 模式configure 时传入 Surface解码器内部直接渲染 MediaCodec decoder MediaCodec.createDecoderByType(video/avc); decoder.configure(format, renderSurface, null, 0); decoder.start(); // 如果想要 YUV 做处理configure 传 null然后从输出 buffer 拿数据 decoder.configure(format, null, null, 0);选型建议很直接如果只是播放器用 Surface 模式把renderSurface交给SurfaceView或TextureView如果一定要滤镜那就用GLSurfaceView 自定义 EGL把解码输出接到SurfaceTexture上在 Fragment Shader 里处理滤镜。这里有个常见误用很多人以为拿到 ByteBuffer 的 YUV 就能直接送滤镜实际上 Android 上 YUV 的排列有 NV21、NV12、YV12 多种直接当 RGB 用必然是绿的。统一做法是让 OpenGL 的texImage2D把 YUV 拆成三个 plane 上传或者先用RenderScript转成 RGBA 再上传后者实现快但低端机耗时不可控。4.3 音画同步AudioTrack 时钟作主时钟的常见做法播放器项目里音画同步是最后一道门。以音频为主时钟是业界惯例因为人耳对音频抖动更敏感。标准实现是拿到音频播放的位置再决定视频帧是等还是丢。// 每秒播放的采样数 → 当前播放头对应的时间微秒 long playHeadUs audioTrack.getPlaybackHeadPosition() * 1_000_000L / sampleRate; // 视频帧带自己的 PTS和音频时钟比对 long delayUs videoFramePtsUs - playHeadUs; if (delayUs 30_000) { // 视频快了暂停输出等音频追上 videoRenderer.pause(); } else if (delayUs -10_000) { // 视频慢了丢帧跟上否则积压会越来越大 videoRenderer.skipToNext(); }阈值取多少有讲究30ms 和 -10ms 是我常用的经验值。正阈值不能太小否则视频一抖动就停顿看起来更卡负阈值不能太大否则用户感知到画面明显落后于声音。getPlaybackHeadPosition在MODE_STREAM下有效如果你用MODE_STATIC播放短音频这个接口会一直返回 0音画同步就不成立了。另外微信视频通话这类低延迟场景里音频时钟还要处理设备切换——蓝牙耳机断开瞬间播放头会跳变此时要重置基准时间否则同步逻辑会疯掉。5. 避坑手册Android 音视频开发最常见的 5 个翻车现场5.1 花屏与绿屏关键帧丢失与 I 帧间隔的玄学现象录出来的视频在某些播放器上开头是花的快进后要等几秒才有画面。 原因MP4 封装时视频轨的第一帧如果不是关键帧IDR播放器必须找到第一个 IDR 才能出画编码器输出有时把 I 帧的 buffer 标成BUFFER_FLAG_SYNC_FRAME但 muxer 写入顺序或 PTS 错乱会导致这个标记丢失。另外KEY_I_FRAME_INTERVAL设得太大比如 10 秒时任何丢包或seek都会面临长时间无参考帧。 解决把 I 帧间隔压到 2 秒内录制开始时主动请求一个关键帧代码是Bundle params new Bundle(); params.putInt(MediaCodec.PARAMETER_KEY_REQUEST_SYNC_FRAME, 0); encoder.setParameters(params);。如果你的业务允许录制出的 MP4 再跑一遍转封装把 B 帧去掉也能缓解部分播放器的兼容问题——B 帧在 Android MediaCodec 编码器里一般不产但厂商实现偶尔不听话。5.2 录制视频没有声音AudioRecord 缓冲区与权限申请的先后顺序现象视频画面正常音频轨道存在但全是静音。 原因AudioRecord读取线程因为缓冲区太小不断丢数据或者是权限弹窗还没点“允许”就开始startRecording导致状态直接进入 ERROR。 解决按AudioRecord.getMinBufferSize(sampleRate, channelConfig, audioFormat)的返回值乘 2 创建缓冲区。startRecording之前检查RECORD_AUDIO权限并在onRequestPermissionsResult回调里再启动线程。注意AudioRecord读不到数据时read()返回负数很多人忽略了这个返回值把无效数据全写进了文件等播放时才发现是一段噪声。5.3 旋转 90 度后画面变形rotation 字段与 MediaFormat 的配合现象竖屏拍摄的视频播放时是横的或者横竖切换后画面被拉伸。 原因相机传感器默认是横向安装输出画面的旋转角度存在CameraCharacteristics.SENSOR_ORIENTATION里。你手动把预览旋转了但编码器那里还是原始角度。 解决一个思路是直接在编码前把 YUV 旋转但 O(1) 开销的是在MediaMuxer里做不过 muxer 的旋转能力有限。更通用的方案是在MediaFormat里把KEY_ROTATION设为 90/270播放器会按这个角度渲染。要校验这个角度是否生效最简单的方法是录一段竖屏视频用系统播放器打开看方向。厂商这块参差不齐有的只认 90 和 270有的 180 也会出错所以生产环境里旋转角度要透传给播放器别在文件里写死。5.4 内存暴涨与 OOMBuffer 释放时机现象录制或播放 10 分钟后 App 内存持续上涨低端机上 OOM。 原因编码器的输出 buffer 没有释放ByteBuffer 模式下解码输出的 YUV 数据被业务层持有没有releaseOutputBufferImageReader拿到的Image没有close()。其中 ImageReader 是最隐蔽的它由底层 BufferQueue 管理不 close 的话 BufferQueue 耗尽采集中断。 解决编码器循环里releaseOutputBuffer必须在writeSampleData之后立刻调用不要在业务回调里做重活。任何拿出来的Image用完即close。另外SurfaceView和TextureView的选择也影响内存——TextureView 是离屏渲染会一次性分配整块显存SurfaceView 是独立窗口内存占用小低端机优先。5.5 不同机型表现不一致从三个固定项查起现象同一条链路在 A 设备上流畅跑 30fps在 B 设备上预览正常但录制只有 15fps。 原因三个固定项不匹配。一是颜色格式编码器的COLOR_FormatSurface虽然通用但 ByteBuffer 模式下各厂商支持的ColorFormat不同常见是COLOR_FormatYUV420SemiPlanar和COLOR_FormatYUV420Planar混用。二是编码 Level部分设备不支持 4K 或 1080p60 的 High Level配置过高时硬件编码器直接降级或拒绝。三是尺寸对齐1080p 的宽高对大多数编码器是友好的但 1080x1080 这种非标准尺寸需要底层的crop信息对齐处理不好花屏。 解决代码里先通过MediaCodecInfo.CodecCapabilities查询实际支持的尺寸集合再做降级链优先 1080p30 H.264设备不支持就降 720p30。颜色格式统一用字节缓冲方式getInputImage()拿Image避免直接操作 ByteBuffer 时踩到排列不同的坑。这部分没法靠代码“一次兼容”只能靠真机矩阵测试收一份各机型上报的编码器能力日志才能把玄学变成可维护的配置表。6. 进阶用 MediaCodec 异步模式 自定义 EGL 环境做低延迟渲染前面几条链路都是把相机、编码器、解码器彼此独立调用模块边界清晰但数据搬运次数多延迟在 200ms 以上。对视频通话、直播这种场景核心优化思路是减少 Surface 到 Surface 之间的拷贝相机输出交给SurfaceTexture这个纹理直接作为编码器输入同时用 EGL 把它绑到预览窗口上整个过程不经过 CPU 拷贝。// 相机输出 Surface 直接接到编码器输入 SurfaceTexture cameraTexture new SurfaceTexture(0); cameraTexture.setDefaultBufferSize(videoWidth, videoHeight); Surface cameraEncoderSurface new Surface(cameraTexture); // 异步编码把数据搬离主线程 encoder.setCallback(new MediaCodec.Callback() { Override public void onOutputBufferAvailable(MediaCodec codec, int index, BufferInfo info) { ByteBuffer buffer codec.getOutputBuffer(index); muxer.writeSampleData(videoTrackIndex, buffer, info); codec.releaseOutputBuffer(index, false); } }); encoder.start();这套方案的核心价值在于照相机输出的 Surface 直接送进编码器编码器压缩后走网络另一端解码时把输出 Surface 直接绑定到GLSurfaceView的 EGL 环境全链路只在纹理层面流动。我自己的项目里用这套结构端到端延迟从 300ms 降到了 120ms 左右。注意两个细节EGL 环境的eglSwapBuffers必须在 GL 线程调用不要在onFrameAvailable回调里直接换缓冲另外MediaCodec.Callback的回调线程和写网络线程之间的数据交接要用无锁队列否则把网卡慢的账算到编码器头上排查会走弯路。还有一个值得养成的习惯每一步链路都加一个监控指标。采集端看SENSOR_TIMESTAMP间隔编码器看INFO_OUTPUT_FORMAT_CHANGED之后每个 buffer 的 PTS 间隔播放端看音画同步的丢帧率。没有这些数字所谓优化就是拍脑袋。我吃过大亏曾经优化了一个月的延迟最后发现是音频采样率设置错了导致播放时整体慢 5%跟渲染管线毫无关系。现在每次做音视频模块第一件事先把监控点埋好再谈优化——这套习惯希望帮到你。本文还有配套的精品资源点击获取
