简介：面向Android开发者的IjkPlayer播放RTSP/RTMP视频流可运行Demo，聚焦实时流媒体播放需求，解决系统MediaPlayer对RTSP/RTMP等协议支持不足的问题。项目基于Bilibili开源的IjkPlayer搭建，采用Kotlin与Java混合编写，集成ijkplayer-java-release.aar及对应so库，演示了从初始化、配置数据源、prepareAsync异步准备到播放控制的完整闭环。工程内包含Xml布局资源、Proguard混淆规则、Gradle构建脚本、Properties配置文件及Png图标等，可直接导入Android Studio编译运行，亦可将核心代码抽取到既有项目中。压缩包共147个文件，整体约13.68MB，so动态库覆盖不同ABI，aar封装播放器核心，结构清晰，便于定位与裁剪。通过学习可掌握SurfaceView/TextureView渲染、状态回调、错误监听、暂停停止及资源释放等关键操作，并理解RTSP与RTMP地址在Android端的接入流程。目前已有980人浏览学习，适合需要快速接入实时视频播放的初、中级开发者参考，也可作为二次开发的基础模板。
1. 项目背景与方案选型：为什么盯上 IjkPlayer
做Android音视频开发的人，基本都会碰到一个绕不开的坎：怎么在App里流畅播放RTSP或RTMP流。尤其是这两年，摄像头接入、直播拉流、安防大屏这类需求越来越多，客户端拿到的往往不是现成的HTTP-FLV或HLS地址，而是rtsp://xxx或rtmp://xxx这种带协议的裸流地址。Android自带的MediaPlayer和ExoPlayer虽然对HTTP协议支持不错，但碰到RTSP就有点力不从心——ExoPlayer对RTSP的支持直到1.0版本才慢慢成熟，RTMP更是基本放弃治疗。这时候，B站开源并维护的IjkPlayer就成了一个非常务实的备选方案。
我这次做的Demo，核心目标就一句话：在Android Studio里跑通一个能播放RTSP和RTMP流的可运行工程，不搞花里胡哨的UI，不堆复杂架构，就是把最核心的播放链路打通，让大家拿过去能直接用、能改、能跑。
为什么选IjkPlayer而不是其他方案？我对比过几条路线：一是用VLC的libVLC库，功能确实强，但库体积大，初始化慢，商用授权也有讲究；二是用ExoPlayer扩展RTSP模块，需要自己加依赖和配置，RTMP依然无解；三是自己用FFmpeg底层写解码器，那工作量直接起飞。IjkPlayer的好处在于它是基于FFmpeg的封装，天然支持RTSP、RTMP、HLS、本地文件等多种协议，API设计又高度兼容Android的MediaPlayer，老Android开发者几乎零成本上手。虽然项目现在已经停止更新维护（最后稳定版本停在0.8.8），但在RTSP/RTMP这种偏传统的播放场景里，它依然是最稳妥的选择，社区踩坑资料也足够多。
这个Demo适合谁看？我觉得有三类人最合适：第一类是刚接触Android音视频的初级开发，想找个能跑的工程做参考；第二类是做安防、物联网、直播相关项目的工程师，需要快速集成RTSP/RTMP播放能力；第三类是那些被ExoPlayer折腾得够呛，想换个思路的人。如果你只是想播放HTTP-FLV，那IjkPlayer不是最优解，现在的ExoPlayer+DASH或腾讯云超级播放器更合适，但如果你手里只有RTSP/RTMP地址，那这篇文章应该能帮你省下半天到一天的摸索时间。
2. 核心原理与准备工作：搞懂RTSP、RTMP和IjkPlayer的三角关系
2.1 RTSP和RTMP到底差在哪儿
先说RTSP。RTSP（Real Time Streaming Protocol）是一个网络控制协议，它本身不负责传输媒体数据，而是负责发起和引导流媒体会话，真正的音视频数据是通过RTP（Real-time Transport Protocol）协议传输的。典型流程是：客户端先发一个OPTIONS请求探测服务器能力，然后依次发DESCRIBE获取媒体描述（SDP格式，里面包含了编码格式、分辨率、码率等关键信息），再发SETUP建立传输会话，最后发PLAY开始拉流。你可以把RTSP理解成看电视时手里的遥控器——换台、音量、暂停这些控制动作走的是RTSP，而电视画面本身走的是RTP通道。
RTMP（Real Time Messaging Protocol）则是Adobe推出的流媒体协议，基于TCP长连接，默认端口1935。它的特点是低延迟、兼容性好，早期直播领域几乎被它统治。RTMP传输的不是裸流，而是被封装成FLV格式的消息块（Chunk），通过AMF（Action Message Format）协议进行握手和命令交互。服务器端通过推流工具（如OBS）把视频信号推给流媒体服务器（如Nginx-RTMP），客户端再通过RTMP拉流地址进行播放。
用一张表来看它们的核心差异会比较直观：
| 对比项 | RTSP | RTMP |
|---|---|---|
| 传输层 | 基于RTP/UDP（也可走TCP） | 基于TCP长连接 |
| 默认端口 | 554 | 1935 |
| 控制方式 | 独立控制协议（OPTIONS/DESCRIBE/SETUP/PLAY） | 内置命令通道（FMLE/connect/createStream） |
| 典型场景 | 安防摄像头、IP Camera、视频监控 | 直播推流、直播拉流、互动直播 |
| 延迟表现 | 通常在200ms~1s，视GOP设置而定 | 通常在1s~3s，视缓冲策略而定 |
| 播放器支持 | 需要支持RTSP/RTP解析 | 需要支持RTMP握手和FLV解封装 |
有一个常见的认知误区需要澄清：很多人以为RTSP和RTMP是同一类东西，直接互换地址就能播。实际上摄像头厂商给的RTSP地址（比如海康威视的格式）在浏览器里通常放不了，就是因为浏览器原生不支持RTSP协议，而IjkPlayer基于FFmpeg做了协议解析，才能在Android端直接解码播放。至于RTMP地址，浏览器同样是没法直接播放的，HTTP-FLV才是浏览器端的常用方案，这也是为什么很多在线考场问"RTMP地址怎么在浏览器播"——本质上需要一个协议转换层。
2.2 IjkPlayer的架构与核心模块
IjkPlayer的底层核心是FFmpeg，它把FFmpeg的解封装和解码能力封装成了一套类似Android MediaPlayer的接口。整个架构分为三层：最上层是Java层的IjkMediaPlayer类，它继承自MediaPlayer的抽象接口，Android开发者熟悉的所有方法——setDataSource、prepareAsync、start、pause、seekTo——在IjkPlayer里全部保留；中间层是Native层，由C++实现的播放器核心，负责音视频同步、渲染控制、缓冲策略管理；最底层是FFmpeg的各模块，包括协议层（rtsp、rtmp、http等）、解封装层（demuxer）、解码层（decoder）。
IjkPlayer有几个独门配置项值得关注。以播放RTSP流为例，ijkopenssl这个配置项决定是否启用OpenSSL加密，如果你的RTSP地址是带鉴权的（如rtsp://admin:password@192.168.1.64:554/...），就需要确认so库中包含了openssl模块；rtsp_transport是RTSP传输层协议设置，可选tcp或udp，默认是udp，但实际项目中我通常建议显式设置为tcp，后面细说原因；probesize和analyzeduration决定探测缓存大小和时长，直接影响首屏加载速度，对于RTSP这种需要协商的协议来说，设置不当容易导致播放器花很长一段时间停在黑屏状态。
2.3 运行环境与前置工具准备
在动手写代码之前，先把环境准备好。这个Demo我用的开发环境如下，供参考：
- 操作系统：Windows 10 / Ubuntu 20.04（两个系统都测过）
- Android Studio：版本不限，建议2021.1以上
- Android SDK：API 21~34都行，建议minSdk设置21（Android 5.0）
- 编译工具：NDK不是必装项，除非你需要自己编译IjkPlayer的so库（后面会讲到）
我在Demo里使用的方式是直接从Maven仓库引入编译好的IjkPlayer依赖，省去了最令人头疼的NDK编译过程。如果你不需要定制FFmpeg功能，这种方式完全够用。但如果你想深入了解so库的编译流程，或者需要裁剪体积，那就需要准备NDK r14b以下版本（IjkPlayer官方建议），克隆ijkplayer的GitHub仓库然后跑编译脚本，这个流程比较复杂，不是这个Demo的重点，我会在后面的注意事项里提一下。
3. 快速搭建可运行的Demo工程
3.1 新建工程与添加依赖
打开Android Studio，新建一个Empty Activity项目，项目名为IjkPlayerDemo，包名随意（我这里用com.demo.ijkplayer）。语言选Java还是Kotlin都行，我这里用Java写核心代码，因为IjkPlayer的示例代码和网上资料绝大多数都是Java的，直接参考不容易踩坑。
工程建好后，在app/build.gradle里添加依赖。IjkPlayer的Maven依赖有两个版本要分清：tv.danmaku.ijk.media:ijkplayer-java是Java层的播放器API，tv.danmaku.ijk.media:ijkplayer-armv7a是ARM平台的so库，还有ijkplayer-arm64和ijkplayer-x86等不同CPU架构的包。实际项目中我建议按需引入，比如只保留armv7a和arm64，可以显著减少APK体积。
android { defaultConfig { minSdk 21 targetSdk 33 } } dependencies { implementation 'tv.danmaku.ijk.media:ijkplayer-java:0.8.8' implementation 'tv.danmaku.ijk.media:ijkplayer-armv7a:0.8.8' implementation 'tv.danmaku.ijk.media:ijkplayer-arm64:0.8.8' // 如果需要在模拟器上调试，再加 x86 架构 // implementation 'tv.danmaku.ijk.media:ijkplayer-x86:0.8.8' }这里有个细节需要注意：0.8.8版本的ijkplayer-java包在Maven仓库里存在，但so库的groupId写法是tv.danmaku.ijk.media，而不是之前某些教程里写的com.github.bjweishen之类。如果你是从GitHub上找的依赖写法，记得核对一下，避免依赖下载404。
3.2 布局文件：一个SurfaceView就够了
IjkPlayer的渲染默认依赖TextureView或SurfaceView。这个Demo里我用了TextureView，相比SurfaceView，TextureView可以更好支持截图、透明度调节和动画变换，在视频播放场景中更灵活。
<?xml version="1.0" encoding="utf-8"?> <RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent"> <TextureView android:id="@+id/video_view" android:layout_width="match_parent" android:layout_height="match_parent" /> <ProgressBar android:id="@+id/loading_view" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_centerInParent="true" android:visibility="gone" /> <TextView android:id="@+id/status_text" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignParentBottom="true" android:layout_margin="10dp" android:text="准备播放" android:textColor="#FFFFFF" android:textSize="14sp" /> <EditText android:id="@+id/url_input" android:layout_width="match_parent" android:layout_height="48dp" android:layout_alignParentTop="true" android:hint="请输入RTSP/RTMP地址" android:inputType="textUri" android:paddingLeft="12dp" android:importantForAutofill="no" /> <Button android:id="@+id/btn_play" android:layout_width="wrap_content" android:layout_height="48dp" android:layout_alignParentTop="true" android:layout_alignParentRight="true" android:text="播放" /> </RelativeLayout>这里我特意加了一个EditText用于输入流地址，方便测试不同的RTSP/RTMP源。实际项目中你可能需要从扫码、接口或配置中心获取地址，这个输入框只是一个调试便利功能，正式环境可以去掉。
3.3 Java代码：核心播放链路写出来
Java端的核心代码不复杂，关键在于正确初始化IjkPlayer并处理TextureView的Surface生命周期。
public class MainActivity extends AppCompatActivity { private IjkMediaPlayer ijkMediaPlayer; private TextureView textureView; private ProgressBar loadingView; private TextView statusText; private EditText urlInput; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); textureView = findViewById(R.id.video_view); loadingView = findViewById(R.id.loading_view); statusText = findViewById(R.id.status_text); urlInput = findViewById(R.id.url_input); // 测试地址，可按实际情况替换 urlInput.setText("rtsp://admin:password@192.168.1.64:554/Streaming/Channels/101"); findViewById(R.id.btn_play).setOnClickListener(v -> playVideo(urlInput.getText().toString())); } private void playVideo(String url) { if (TextUtils.isEmpty(url)) { statusText.setText("地址不能为空"); return; } releasePlayer(); textureView.setSurfaceTextureListener(new TextureView.SurfaceTextureListener() { @Override public void onSurfaceTextureAvailable(SurfaceTexture surface, int width, int height) { startPlay(url, new Surface(surface)); } @Override public void onSurfaceTextureSizeChanged(SurfaceTexture surface, int width, int height) { } @Override public boolean onSurfaceTextureDestroyed(SurfaceTexture surface) { return false; } @Override public void onSurfaceTextureUpdated(SurfaceTexture surface) { } }); if (textureView.isAvailable()) { startPlay(url, new Surface(textureView.getSurfaceTexture())); } } private void startPlay(String url, Surface surface) { try { ijkMediaPlayer = new IjkMediaPlayer(); // 开启硬解码（部分机型有问题时可改为软解） ijkMediaPlayer.setOption(IjkMediaPlayer.OPT_CATEGORY_PLAYER, "mediacodec", 1); ijkMediaPlayer.setOption(IjkMediaPlayer.OPT_CATEGORY_PLAYER, "mediacodec-auto-rotate", 1); ijkMediaPlayer.setOption(IjkMediaPlayer.OPT_CATEGORY_PLAYER, "mediacodec-handle-resolution-change", 1); // RTSP传输协议，建议tcp，稳定但延迟稍高；udp延迟低但容易丢包 ijkMediaPlayer.setOption(IjkMediaPlayer.OPT_CATEGORY_FORMAT, "rtsp_transport", "tcp"); // 设置探测时间和缓冲大小，降低首屏延迟 ijkMediaPlayer.setOption(IjkMediaPlayer.OPT_CATEGORY_FORMAT, "probesize", 1024 * 1024); ijkMediaPlayer.setOption(IjkMediaPlayer.OPT_CATEGORY_FORMAT, "analyzeduration", 500 * 1000); ijkMediaPlayer.setOption(IjkMediaPlayer.OPT_CATEGORY_PLAYER, "packet-buffering", 0); ijkMediaPlayer.setDataSource(url); ijkMediaPlayer.setSurface(surface); ijkMediaPlayer.prepareAsync(); ijkMediaPlayer.setOnPreparedListener(mp -> { loadingView.setVisibility(View.GONE); statusText.setText("播放中"); mp.start(); }); ijkMediaPlayer.setOnErrorListener((mp, what, extra) -> { loadingView.setVisibility(View.GONE); statusText.setText("播放错误: what=" + what + ", extra=" + extra); return true; }); ijkMediaPlayer.setOnInfoListener((mp, what, extra) -> { if (what == IjkMediaPlayer.MEDIA_INFO_BUFFERING_START) { loadingView.setVisibility(View.VISIBLE); statusText.setText("缓冲中"); } else if (what == IjkMediaPlayer.MEDIA_INFO_BUFFERING_END) { loadingView.setVisibility(View.GONE); statusText.setText("播放中"); } return true; }); ijkMediaPlayer.prepareAsync(); } catch (Exception e) { statusText.setText("初始化失败: " + e.getMessage()); } } private void releasePlayer() { if (ijkMediaPlayer != null) { ijkMediaPlayer.stop(); ijkMediaPlayer.release(); ijkMediaPlayer = null; } } @Override protected void onPause() { super.onPause(); if (ijkMediaPlayer != null) { ijkMediaPlayer.pause(); } } @Override protected void onResume() { super.onResume(); if (ijkMediaPlayer != null) { ijkMediaPlayer.start(); } } @Override protected void onDestroy() { super.onDestroy(); releasePlayer(); } }这里有几个关键点必须强调。第一，prepareAsync()不能重复调用，如果播放完一个流后再播另一个，必须先reset()或release()再重新new一个实例，我在playVideo方法里先调了releasePlayer()，就是为了避免这个坑。第二，setSurface需要在prepareAsync之前调用，否则画面可能无法渲染。第三，硬解码配置项mediacodec在某些低端机或定制系统上会出兼容性问题（画面绿屏、花屏），如果遇到这种问题，把硬解选项关掉即可，后面在问题排查部分我会单独说。
还需要在AndroidManifest.xml里添加网络权限：
<uses-permission android:name="android.permission.INTERNET" />如果你的RTSP地址是明文带账号密码的，比如rtsp://admin:123456@192.168.1.64/...，URL中的账号密码会被IjkPlayer解析后以明文形式传输，这在公网环境下有泄露风险，建议仅在局域网或内网测试时使用这种地址。
3.4 可用的测试流地址参考
没有摄像头设备验证怎么办？我这里提供几个公开可用的测试源地址。需要说明的是，公开测试源随时可能失效，如果连不上只能换其他地址测试，这是所有公开源的通病。
| 类型 | 地址示例 | 说明 |
|---|---|---|
| RTSP（本地摄像头模拟） | rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mp4 | Wowza官方测试源，延迟较高但稳定 |
| RTSP（通用测试） | rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mp4 | 另一组Wowza测试节点 |
| RTMP（直播流） | rtmp://live.hkstv.hk.lxdns.com/live/hks | 香港卫视的测试直播流，经常会变 |
| RTMP（测试流） | rtmp://ns8.indexforce.com/home/mystream | 不稳定，需要多试 |
我自己实测下来，第一组Wowza的RTSP地址在连通性上表现比较稳，但因为是跨国节点，延迟较高，国内网络环境下首屏可能需要2~5秒。如果你手头有海康威视、大华、宇视等品牌摄像头，直接用公司内网的RTSP地址测试效果会好得多，局域网内拉流延迟基本在500ms以内。
4. 传输协议与播放参数调优：让RTSP/RTMP播放更流畅
4.1 RTSP的TCP和UDP之争，到底选哪个
这个问题几乎每个做RTSP播放的人都会纠结。官方默认的rtsp_transport参数是UDP，UDP的优点是没有TCP的拥塞控制，在网络状况良好的局域网里延迟可以做到很低；但缺点是丢包不重传，一旦网络抖动，画面就会出现马赛克、卡顿甚至花屏。TCP则相反，虽然因为有握手和重传机制导致延迟略高，但数据完整性有保障，在跨网段、跨运营商或无线网络场景下表现更稳定。
我的实践经验是：优先用TCP，除非你对延迟有极致要求并且网络环境非常可靠。以安防监控为例，绝大多数摄像头都部署在Wi-Fi或复杂网络环境中，UDP丢包的概率远比想象中高。我曾经在一个项目中用UDP拉取海康摄像头画面，客户反馈画面每隔几分钟就花屏一次，后来把rtsp_transport改成TCP就彻底解决了。用TCP的代价是延迟会高出100~200ms，但在绝大多数监控场景中这个延迟完全可以接受。
还有一个小技巧：如果你需要同时拉取多路摄像头画面，每路连接都配置TCP会导致摄像头连接数增加。部分摄像头设备有最大连接数限制（比如海康某些型号限制在6路左右），这时候要么降低码率、要么改用UDP、要么走摄像头厂商的SDK，这是方案层面的取舍，不单是播放器能解决的。
4.2 缓冲参数与首屏延迟的平衡术
IjkPlayer有几个参数直接影响首屏加载速度和播放流畅度。第一个是probesize，它表示播放器在开始解码前需要探测的最大字节数，默认是5000000（约5MB），对于RTSP这种流媒体来说，这么大的探测值会导致首屏延迟非常明显。我把它调成了1024 * 1024（1MB），首屏时间能快不少。第二个是analyzeduration，单位微秒，默认是5000000（5秒），也就是说播放器最多花5秒时间分析媒体信息。对于已知编码格式的RTSP流，可以适当调小这个值，我设为500 * 1000（500ms），首屏基本能在1秒内出画面。
第三个参数是packet-buffering，默认情况下IjkPlayer会缓冲一定数量的数据包再开始播放，好处是播放过程更平滑，坏处是延迟增加、且实时性变差（播放的可能不是最新画面而是几秒前的画面）。如果需要低延迟的实时监控场景，把packet-buffering设为0可以显著降低延迟，但缺点是网络波动时更容易卡顿。
这里还需要注意sync-av-start和start-on-prepared这两个参数。sync-av-start控制是否音视频同步启动，start-on-prepared控制prepare完成后是否立即播放。IjkPlayer的典型行为是prepare完成后调用start就开始播放，不需要额外设置。如果遇到"有声音没画面"或"有画面没声音"的情况，多半是音视频同步问题，可以尝试调整framedrop参数（设置为1表示允许丢帧，保证音频节奏优先）。
4.3 直播模式下的延迟优化配置
如果你的场景是直播拉流（比如从Nginx-RTMP服务器拉取OBS推的流），延迟就是头号痛点。RTMP协议本身延迟一般在1~3秒，但我实测发现，如果不做任何优化，IjkPlayer播放RTMP甚至可能延迟到5秒以上。原因在于IjkPlayer默认采用的缓冲策略是按时间窗口缓冲的，网络状况良好时它也会攒够一定量的数据才播放。
针对直播场景，我常用的优化参数组合如下：
ijkMediaPlayer.setOption(IjkMediaPlayer.OPT_CATEGORY_PLAYER, "packet-buffering", 0); ijkMediaPlayer.setOption(IjkMediaPlayer.OPT_CATEGORY_FORMAT, "fflags", "nobuffer"); ijkMediaPlayer.setOption(IjkMediaPlayer.OPT_CATEGORY_PLAYER, "max-buffer-size", 4096); ijkMediaPlayer.setOption(IjkMediaPlayer.OPT_CATEGORY_PLAYER, "framedrop", 1);其中fflags=nobuffer是FFmpeg层面禁用缓冲，max-buffer-size限制最大缓冲字节数，这两项配合packet-buffering=0能显著降低延迟。不过这种组合方案在弱网环境下会频繁卡顿，所以不能盲目照搬，需要根据自己的网络状况和业务容忍度来取舍。如果你的业务对延迟要求不高（比如点播回放、视频文件播放），保留默认缓冲策略反而体验更好。
5. 常见问题与排查技巧实录
5.1 黑屏但有声音，或者直接不播放
这是IjkPlayer播放RTSP时最常遇到的问题，几乎每个新手都会栽一次。造成黑屏的原因通常有以下几种：
原因一：Surface未正确绑定。IjkPlayer的视频渲染需要Surface，如果TextureView的Surface还没准备好就调了setSurface，画面就无法显示。解决方法是确保在onSurfaceTextureAvailable回调后再创建播放器并设置Surface，而不是在onCreate里直接创建。
原因二：硬解码兼容性问题。部分设备（尤其是一些国产定制ROM）的MediaCodec实现有bug，对H.264或H.265的高帧率、高分辨率视频硬解会出现黑屏或马赛克。排查方法是把mediacodec选项设为0（强制软解），如果恢复正常，说明是硬解兼容问题。软解的代价是CPU占用升高、发热增加，但在兼容性优先的场景下也只能接受。
原因三：编码格式不支持。IjkPlayer自带的FFmpeg虽然功能完整，但某些特殊编码（如MJPEG、MPEG4）或私有编码可能无法解码。这种情况一般会在logcat里看到Could not open codec之类的报错，排查时重点关注ijkplayer标签下的日志信息。
5.2 RTSP地址带鉴权播放不了
很多摄像头（尤其是海康、大华）的RTSP地址格式是rtsp://username:password@ip:port/...。如果你在浏览器或VLC里都能成功播放，但在IjkPlayer里却报错，大概率是URL中的特殊字符（比如@、#、空格）没有被正确编码。正确的做法是对密码部分做URL编码，例如：
String username = "admin"; String password = "pass@word"; String encodedPwd = Uri.encode(password); String url = "rtsp://" + username + ":" + encodedPwd + "@192.168.1.64:554/Streaming/Channels/101";另外，有些摄像头开启了RTSP加密（RTSP over TLS），这类地址在IjkPlayer里默认不支持，需要在编译so库时启用openssl，并且播放器端配置证书相关参数。这个操作比较进阶，一般项目里遇到的可能性不高，但如果碰到rtsp://但实际是加密流的情况，排查起来会非常痛苦。
5.3 播放过程中画面卡顿、延迟越来越高
直播场景下经常出现"延迟越播越大"的现象，这其实是播放器持续缓冲导致的。发生这种情况时，我一般会按这个顺序排查：先看网络质量和摄像头码率设置，如果摄像头码率设得过高（比如2K分辨率还推8Mbps码率），在普通Wi-Fi环境下很容易卡顿；然后检查播放器是否启用了packet-buffering，如果启用了，尝试关闭；最后检查是否有内存泄漏（长时间播放后内存飙升导致GC频繁），IjkPlayer在长时间运行后确实需要关注内存回收问题。
如果画面出现花屏或马赛克，优先怀疑UDP丢包，改TCP基本能解决。如果画面出现周期性卡顿（比如每10秒卡一下），大概率是摄像头GOP（关键帧间隔）设置过大或网络拥塞，可以尝试调整摄像头的关键帧间隔参数（一般建议设为1~2秒）。
5.4 真机安装后闪退或so库加载失败
如果你用的是自己编译的IjkPlayer so库，而不是Maven依赖，很容易遇到UnsatisfiedLinkError或libijkffmpeg.so is not found的错误。这种问题通常是CPU架构不匹配导致的，比如在64位手机（arm64-v8a）上安装了只含armv7a so库的APK，系统会尝试加载armv7a的库，但Android 8.0以上系统对32位库的限制越来越多，更容易出问题。
解决方案有三种：一是引入全部架构的依赖（armv7a、arm64、x86），让系统自动选择兼容的架构；二是检查APK内libs目录的so库是否完整；三是看是否有第三方SDK内置了不同版本的FFmpeg，导致so文件冲突。最后一种情况排查起来最麻烦，我曾经遇到过项目里同时集成了IjkPlayer和一个OCR库，两个库各自带了一份不同版本的FFmpeg，导致运行时崩溃，最后只能通过exclude排除冲突依赖才解决。
5.5 常见问题速查表
| 问题现象 | 可能原因 | 排查/解决方案 |
|---|---|---|
| 黑屏但有声音 | Surface绑定时机不对/硬解兼容性问题 | 确保onSurfaceTextureAvailable后再播放；关掉mediacodec硬解 |
| prepare后一直缓冲 | 网络慢/摄像头码率过高/缓冲参数不合理 | 检查网络；降低码率；调整probesize和analyzeduration |
| 播放过程中花屏 | UDP丢包/网络抖动 | 改用rtsp_transport=tcp |
| 延迟越来越大 | packet-buffering开启/缓冲策略积累 | 关闭packet-buffering；设置fflags=nobuffer |
| 部分地址能播放部分不能 | 编码格式不支持/地址格式错误 | 看logcat报错；检查URL编码；确认编码格式 |
| 安装后闪退 | so库架构不匹配/依赖冲突 | 引入全架构依赖；检查so库完整性；排除冲突依赖 |
| 有画面无声音 | 音频解码失败/声道配置异常 | 检查音频编码；尝试设置audiotrack参数 |
6. 扩展思考：这个Demo还能往哪些方向走
6.1 多路播放与画面拼接
单路播放跑通之后，很多人第一个想法就是做多画面拼接墙（比如4路、9路摄像头同时显示）。Android端的IjkPlayer支持创建多个播放器实例，但受限于移动设备的解码能力和内存，同时硬解4路1080P已经是极限，再往上就会明显发热和掉帧。实际项目中更可行的方法是：在服务器端做视频合成或转码，再将合成后的单路流推给Android端播放。这涉及服务器转码设计，不在Demo范围内，但可以作为方案储备。
6.2 播放器UI与交互封装
这个Demo的UI刻意保持极简，实际项目中需要封装控制条（播放/暂停、进度拖动、全屏切换）、手势调节音量/亮度、手势控制拖动等能力。IjkPlayer的进度控制方法（seekTo）是直接可用的，但对于RTSP实时流，很多摄像头设备并不支持seek操作，开发时需要对可拖动和不可拖动的流做差异化处理。还有一点，全屏切换时需要动态调整TextureView的尺寸和Surface的宽高比，避免画面拉伸变形。
6.3 低延迟方案的更多选择
虽然IjkPlayer在这个Demo里表现不错，但如果你对延迟极其敏感（比如远程操控、语音对讲场景），RTSP/RTMP这类传统的推拉流协议可能已经不适合了。近年来WebRTC在低延迟领域越来越流行，通过WebRTC可以实现端到端500ms以内的低延迟传输。不过WebRTC在Android端的集成复杂度比IjkPlayer高出不少（需要处理信令服务器、STUN/TURN穿透、音视频引擎对接等），不适合作为入门Demo的一部分。我的建议是：先把IjkPlayer这个扎实的思路吃透，再根据实际业务需求决定是否升级方案。
最后再分享一个实际项目中的细节：IjkPlayer的日志输出默认非常完整，调试时务必在logcat里过滤ijkplayer这个tag，它会输出FFmpeg上报的详细错误信息（比如Could not find codec parameters、Failed to open RTSP connection），这些信息在排查问题时远比播放器的顶层错误码更有价值。我经常看到有人对着"Error -10000"这种通用错误码一头雾水，其实真相就在日志里，只是没人教他们怎么去看。希望这篇Demo记录能让你少走几步弯路。
本文还有配套的精品资源，点击获取
