简介：面向Android开发者的RTSP播放示例工程，演示通过MediaPlayer播放RTSP实时流媒体的完整链路，适合需要对接监控摄像头、网络摄像机或直播流的移动端开发者，也适合刚接触流媒体播放的新手作为自定义视频播放器的参考起点。压缩包共55个文件，包含5个Java源码、8个XML界面布局、15张PNG资源图，以及编译好的APK、so库和android-support-v4.jar等依赖，整体体积仅4.73MB，可直接导入Eclipse工程运行。代码覆盖MediaPlayer初始化、setDataSource注入RTSP地址、prepareAsync异步准备、OnPreparedListener触发播放等关键步骤，同时通过start、pause、stop、seekTo展示了播放控制与错误监听、资源释放的完整写法；附带的SurfaceView/TextureView显示方案和播放控制界面，能让读者快速理解流媒体播放器的基本架构。示例允许修改RTSP地址切换不同视频源，工程结构清晰，配合注释可边运行边学习，已有727人学习浏览，对入门Android RTSP开发具有不错的参考价值。
1. 一个能跑的RTSP播放DEMO，比你想象的更依赖协议细节
手里拿着摄像头、编码器或者流媒体服务器的RTSP地址，想在Android上快速验证画面能不能出，第一反应通常是找一个现成的播放DEMO。但真把地址填进去，黑屏、卡住、有声无画、画质撕裂这些现象会接踵而来。android rtsp播放DEMO看起来是个小工程，实际把网络协议、解封装、解码、渲染、音画同步全串起来了，任何一环不对都出不了稳定画面。这篇笔记从选型讲到解码参数，再到几个最容易翻车的坑，最后给一份能自检链路是否健康的测试方法，适合刚接手RTSP播放、被地址和格式折腾过的开发者照着落地。
2. Android播放RTSP的三种主流路线：选型决定后续所有坑
RTSP本身不带码流，它负责协商会话，真正的音视频数据走RTP。Android端播放RTSP，常见做法是三条路：直接用系统组件、用现成播放器库套壳、或者基于FFmpeg自研解码渲染。选型不一样，后面遇到的黑匣子也完全不一样。
2.1 系统MediaPlayer与ExoPlayer：为什么Demo跑不通
系统MediaPlayer在Android早期版本里支持RTSP，但它是黑盒实现，对H.264的SPS/PPS解析、RTP打包方式、音频AAC的ADTS头处理都很挑剔。很多RTSP流用MediaPlayer能出声音但不出画面，或者onPrepared一直不回调。ExoPlayer从设计上就不是为了RTSP来的，它原生支持的是HTTP渐进式下载和DASH，RTSP要么靠扩展，要么靠第三方模块，而第三方模块大多只支持部分RTP封包。
我见过不少开发者直接把RTSP地址丢给MediaPlayer，结果在Android 9之后直接抛出“Can't play video”的通用错误。原因不是地址错，而是MediaPlayer内部解析RTP时遇到H.264的FU-A分片就放弃。ExoPlayer的情况稍微好一点，但它的RTSP扩展模块对UDP超时处理得很激进，稍微丢包就直接ERROR_CODE_TIMEOUT。
2.2 基于FFmpeg的软解方案：可控但工程量在渲染
FFmpeg在Android上的集成方案很成熟，常见做法是用FFmpeg拉流、解封装、解码，然后通过SurfaceView或TextureView渲染。这条路的最大好处是可控，RTSP的所有协商细节都暴露在代码里，哪个环节出问题能通过日志定位。代价是得自己管音视频同步、缓冲策略、Surface生命周期和解码器适配，这也是很多Demo最终止步于“能出一帧画面但没法长时间播放”的原因。
我在实际项目里更倾向于用FFmpeg的解封装能力，把RTSP转成标准格式再做解码，而不是直接用FFmpeg的decode API去解每一帧。原因是FFmpeg的decode API在硬解支持上不如MediaCodec直接，尤其是H.264的high profile和10bit色深，软解能解但性能消耗大，低端机上发热明显。
2.3 选型对照：延迟、格式兼容、集成成本
| 路线 | 首帧延迟 | 格式兼容性 | 集成成本 | 适合场景 |
|---|---|---|---|---|
| MediaPlayer | 受系统实现影响，平均2-4秒 | 差，遇FU-A分片、异常SPS即失败 | 很低，几行代码 | 只做一次本地验证 |
| ExoPlayer + RTSP扩展 | 1-3秒 | 中，对部分摄像头RTSP兼容性尚可 | 低，依赖扩展模块 | 演示场景，要求不高 |
| FFmpeg解封装 + MediaCodec解码 | 0.5-1.5秒可控 | 高，几乎所有RTSP流都能拉 | 高，需要自己写渲染循环 | 正式项目，需要稳定和低延迟 |
选型的核心结论是：如果只是临时验证一个RTSP地址能不能出画面，用系统组件可能三分钟就能看到结果，但要承担“地址能播但显示失败”这种更让人困惑的情况。如果要做成产品级或长时间运行的Android端，直接走FFmpeg解封装加MediaCodec硬解这条路，后面处理具体格式问题时才有的商量。
3. 用FFmpeg加MediaCodec搭一个最小自研Demo：从拉流到上屏
既然选型定了，我直接给出一个可复现的最小实现结构。这套结构不依赖任何全家桶式播放器SDK，只用FFmpeg的so库加系统MediaCodec，能把RTSP流稳定地显示在SurfaceView上。
3.1 最小Java层流程：四个类搞定播放
一个能跑的最小Demo至少需要四个核心类：拉流解码线程、视频渲染器、音频渲染器、控制器。拉流解码线程负责读取RTSP源，分离出视频帧和音频帧，分别交给两个渲染器。控制器管理状态切换，比如播放、暂停、停止、重连。
// 拉流解码线程核心逻辑 public class RtspDecodeThread extends Thread { private Surface videoSurface; private AudioTrack audioTrack; private boolean isRunning; @Override public void run() { // 打开RTSP地址，设置超时和缓冲参数 long avFormatCtx = nativeOpenRtsp(url, timeoutMs); while (isRunning) { // 读取一个包，可能是视频也可能是音频 NativePacket packet = nativeReadPacket(avFormatCtx); if (packet.isVideo()) { // 送进MediaCodec解码，输出到Surface decodeVideo(packet.getBuffer()); } else { // 音频走AudioTrack播放 audioTrack.write(packet.getBuffer()); } } } }这段代码的逻辑是：native层用FFmpeg打开RTSP，读取过程中不断返回AVPacket。Java层拿到包后根据stream index区分是视频还是音频。视频包可以交给MediaCodec，音频包可以直接用AudioTrack播放，前提是音频格式是PCM或AAC裸流。如果是AAC，需要先解析出ADTS头，否则AudioTrack只认PCM。
参数说明：timeoutMs是打开RTSP时的网络超时，我一般设3000毫秒，太短在网络抖动时直接失败，太长会让人感觉卡死。nativeOpenRtsp里还要设置两个关键参数，一个是rtsp_transport，另一个是buffer_size，下面展开。
3.2 硬解优先还是软解优先：MediaCodec与surface的配合
MediaCodec硬解是首选，因为Android设备普遍支持H.264硬解，功耗和帧率都比软解好。但硬解有一个重要前提：必须保证H.264的SPS/PPS在关键帧之前到达。很多RTSP服务器不会主动发送SPS/PPS，而是把它放在RTP的payload里以带内方式传输，FFmpeg在解封装时会自动提取并组装好，但如果你直接用MediaCodec的input buffer喂裸的H.264码流，解码器可能不认识。
我用一个稳妥的写法：先把FFmpeg解出来的extradata（SPS/PPS）通过MediaFormat设置给MediaCodec，然后再输入帧数据。
MediaFormat format = MediaFormat.createVideoFormat("video/avc", width, height); // 从FFmpeg拿到的csd-0和csd-1填进去 format.setByteBuffer("csd-0", spsBuffer); format.setByteBuffer("csd-1", ppsBuffer); mediaCodec.configure(format, surface, null, 0);这段代码的关键是csd-0和csd-1。如果不设置，MediaCodec会认为输入流里没有参数集，很多解码器会直接拒解。还有一种情况是FFmpeg已经把SPS/PPS拼进每一帧的关键帧之前，这时候可以不设置csd，但为了保险，我一般还是会从extradata中解析并设置，避免某些设备在播放中途出现花屏。
3.3 首帧延迟与缓冲参数：demo里就该设对的三组值
RTSP播放的体验很大程度上取决于缓冲设置。默认的FFmpeg缓冲策略会为了平滑而预读大量数据，这在本地文件播放没问题，但直播场景下会让延迟飙到好几秒。Demo里就要把这三组值调对，不然后面产品化时很难改。
第一组是rtsp_transport，可选tcp或udp。TCP延迟稍高但稳定，UDP丢包会让画面花屏。我在同一局域网内用UDP，公网环境用TCP。
av_dict_set(opts, "rtsp_transport", "tcp", 0); av_dict_set(opts, "stimeout", "3000000", 0); // 底层socket超时，单位微秒 av_dict_set(opts, "buffer_size", "1024000", 0); // 接收缓冲区1MB第二组是最大缓冲时长。FFmpeg在读取码流时会默认积累一定时长再返回数据，可以通过avformat的max_delay参数限制，单位是微秒。
av_opt_set_int(formatContext, "max_delay", 500000, 0); // 500毫秒第三组是解码后渲染的丢帧策略。如果解码器输出的帧率高于屏幕刷新率，会造成积压，最简单的做法是根据当前系统时间戳判断该帧是否已经过期，过期就跳过不渲染。
if (ptsUs > systemClockUs) { // 未到显示时间，稍微等待 videoSurface.wait(); } else { // 已经过期，直接丢弃，避免卡顿 continue; }这三组值设好之后，内网首帧延迟基本能在1秒以内。公网场景如果网络抖动严重，适当把max_delay调大到1秒，换稳定性。
4. 绕不开的坑：RTSP自带时序、RTP载荷、NAT与音频同步
自研RTSP播放Demo做到能出画面之后，接下来就是无尽的细节坑。这里记录我实际踩过的四类典型问题，每一条都按现象、原因、解决来梳理，希望能帮你省掉几个晚上的排查时间。
4.1 现象一：花屏或黑屏但不报错
播放几分钟后画面碎成马赛克，或者一开始就是黑屏，但logcat里没有任何异常。这种情况多半不是解码器问题，而是RTP包乱序或者丢包。UDP传输情况下，RTP包不保证按序到达，FFmpeg虽然会重排，但重排依赖一个合理的接收窗口。如果RTSP服务器发送的RTP时间戳跳变，或者有大片丢包，FFmpeg的排序逻辑会失效。
解决方法是先确认丢包率。在FFmpeg里开启日志，看有没有“RTP: missed packets”之类的输出。如果丢包率高于1%，优先把传输方式改成TCP，或者加大接收缓冲区。另外要检查摄像头是不是把H.264切片设置得特别小，导致同一帧被拆成很多RTP包，任何一个包丢失都会让整个帧无法解码。这种情况下可以尝试在服务器端把切片大小调到接近MTU，比如1200字节。
4.2 现象二：播放中途卡死，logcat只有"Received fatal exception"
画面卡住不动，logcat反复输出MediaCodec的fatal exception，通常不是解码器崩溃，而是MediaCodec在dequeueOutputBuffer时返回了INFO_OUTPUT_FORMAT_CHANGED，但你的Demo没有正确处理这个事件。这个事件在硬解场景中可能出现，表示解码器输出的尺寸、颜色格式发生了变化，常见于H.264码流中分辨率中途改变。
解决方式是在循环里捕获这个状态，重新获取输出格式，更新渲染器的Surface大小。很多Demo忽略了这一分支，导致解码器认为自己还在工作，但Surface没有更新，画面就像冻住了一样。
MediaCodec.BufferInfo info = new MediaCodec.BufferInfo(); int outIndex = mediaCodec.dequeueOutputBuffer(info, 10000); if (outIndex == MediaCodec.INFO_OUTPUT_FORMAT_CHANGED) { MediaFormat newFormat = mediaCodec.getOutputFormat(); // 通知渲染器更新显示区域 renderer.updateSize(newFormat.getInteger("width"), newFormat.getInteger("height")); continue; }4.3 现象三：音频正常视频不动，或反之
音频和视频各自解码正常，但一个在动另一个不动，这是RTSP播放里最常见也最折磨人的不同步。原因通常有两个。一是音频和视频的启动时间戳基准不同，RTSP的RTP时间戳基于不同的时钟频率，视频是90kHz，音频是采样率本身。如果只拿绝对时间戳做同步，必然错位。
二是音频缓冲与视频缓冲的起始策略不同。我的处理办法是统一以系统当前时间为基准，在收到第一个视频帧和第一个音频帧时，记录它们的RTP时间戳差值，然后以此为偏移量对齐后续所有帧。这样就算音视频流各自乱序，也能对齐到同一个时间轴。
如果问题只在播放开始阶段出现，可以尝试先等三个关键帧再开始渲染，让缓冲更充分。很多服务器在推流初期会发送不完整的帧，直接播放会把后面所有帧的参考关系打乱。
4.4 现象四：公网拉流秒断，局域网正常
同一个地址，在同一WiFi下播放正常，换到4G网络地址连一秒断一下。这通常是RTSP的UDP端口被NAT阻断。默认情况下FFmpeg用UDP接收RTP数据，端口是随机的，如果路由器没有把这些端口映射到内网，RTP包进不来，只有RTSP控制信令走TCP，于是流一旦开始传输就立刻中断。
解决方法是强制使用TCP传输。RTSP over TCP会把RTP数据复用到TCP连接里，避开了UDP端口映射问题。虽然TCP会有队头阻塞，延迟略高，但稳定性能换回来。代码设置和前面一样，用rtsp_transport=tcp。如果在公网场景下还是断，检查RTSP服务器是不是限制并发连接数，有些设备默认只允许两路拉流。
5. 让Demo具备交付感：切换清晰度、断线重连与后台保活
能稳定播放不等于能交付。要把它变成让别人愿意用的Demo，至少还要处理清晰度切换、异常断线自动恢复和切后台再回来这三个高频场景。
5.1 清晰度切换的本质是重写Track
很多人以为切换清晰度是改变解码分辨率，其实源头是重新拉一条新的RTSP流。不同清晰度对应不同URL或不同参数，切换时需要先释放旧的解码器和Surface，再走一遍打开、配置、解码的流程。这里有一个细节：不要直接复用同一个MediaCodec实例，因为不同分辨率需要不同的csd数据，强行复用会造成花屏。
public void switchStream(String newUrl) { stopDecodeThread(); releaseDecoder(); initDecoder(newUrl); startDecodeThread(); }stopDecodeThread要确保积压的解码数据全部清空，并且Surface重新初始化。如果SurfaceView复用同一个Surface，可能会出现黑屏闪现。我习惯在切换期间把Surface锁定，等新流的第一帧渲染成功后再解锁，视觉效果会流畅很多。
5.2 断线重连：用指数退避而不是无限重连
RTSP流的生命周期不稳定，网络波动、服务器重启、摄像头重启都会导致连接断开。自研Demo必须包含重连逻辑，但无限重连会把系统资源耗尽，也解决不了服务器还没恢复的问题。我一般用指数退避策略，第一次断开等1秒重连，第二次等2秒，第三次4秒，最多等30秒。如果连续重连失败超过5次，就抛给上层通知用户。
int reconnectDelayMs = 1000; int maxDelayMs = 30000; while (isRunning && !connected) { connected = tryOpenRtsp(url); if (!connected) { Thread.sleep(reconnectDelayMs); reconnectDelayMs = Math.min(reconnectDelayMs * 2, maxDelayMs); } }这里要特别注意，重连时不能只重新打开RTSP，还得把MediaCodec重新configure一遍。很多摄像头会因旧连接未释放而拒绝新连接，所以在执行重连前要先主动断开旧连接，并等待几百毫秒让服务器清理会话。
5.3 后台播放与surface销毁的重建时机
播放过程中按Home键退到后台，Activity的Surface会被销毁。如果解码线程还在往Surface上输出，会导致崩溃。常见的处理方式有两种：一种是检测到Surface不可用就暂停解码线程，等回到前台再重建；另一种是用SurfaceTexture缓存最后一帧，后台不销毁纹理。对于Demo来说，前一种足够。
我在处理这个场景时，会把解码线程的运行状态和Surface的可用状态分开判断。Surface销毁时，解码线程等当前帧输出完成后自动退出；Surface重建后，重新创建MediaCodec并喂入SPS/PPS，再从关键帧开始解码。
public void surfaceDestroyed(SurfaceHolder holder) { isSurfaceAvailable = false; decodeThread.pause(); } public void surfaceCreated(SurfaceHolder holder) { isSurfaceAvailable = true; decodeThread.resume(); }这段逻辑的关键是resume后，必须重新设置MediaCodec的Surface，而不是直接继续喂帧。否则解码器虽然在工作，但输出目标已经失效，画面永远不会出现。
6. 从Demo到产品：用一项测试证明你的播放链路是健康的
做了这么多，怎么证明这套RTSP播放链路是真的健康，而不是恰好在这个地址、这个网络、这台手机上能跑？我的方法是用一个“24小时拉流稳定性测试”来验证。这个测试不复杂，但能暴露绝大多数隐蔽问题。
具体做法：准备一台低端测试机，连接一个会持续推流的RTSP源，让Demo循环播放24小时。每播放10分钟记录一次当前系统时间、播放时长、累计失败重连次数、解码失败帧数、音视频同步偏差。如果24小时内重连次数大于3，或者解码失败帧数超过总帧数的0.1%，就说明链路有隐患。
这里有个更实用的技巧：在Demo里加一个隐藏的统计页面，把每次解码的时间戳、丢包情况、重连时间点都打印出来，方便远距离排查。只要测试期间logcat里没有出现“fatal exception”和“surface already released”这类致命错误，链路大概率是健康的。
我还有一个个人习惯，就是每次改完音视频同步逻辑，都强制把设备切换到飞行模式再恢复，模拟一次短暂断网。如果恢复后能自动重连且音画恢复同步，这个重连才算真正合格。很多Demo在主动断流时表现良好，但在被动断网时因为旧socket没有及时关闭，导致重连一直失败，这种问题只有靠这种实战习惯才能发现。
希望这篇笔记能帮少走一些弯路。把基础链路打通很容易，但让一个RTSP播放Demo稳定地跑上一天一夜，其中的时序、缓冲、重连策略才是真正值钱的部分。
本文还有配套的精品资源，点击获取
