1. 在Rockchip上为FFmpeg“能跑起来”，软件编解码与MPP硬编硬解两条路线先分清
手头这块Rockchip平台的开发板，我一开始也跟大家一样，apt install ffmpeg装完就开干。平时转个短视频、抽几帧缩略图，仓库里的版本确实够用。但真正上项目就露馅了：一路4K H.265的RTSP码流要转成H.264给下游设备用，系统自带FFmpeg一启动，CPU直接飙到接近满载，画面还一卡一卡的。折腾到这一步我才意识到，在Rockchip设备上做“编译安装FFmpeg”，重点从来不是“编译”这个动作本身，而是要把Rockchip的硬件编解码能力真正塞进这个音视频瑞士军刀里。
Rockchip平台上的视频硬编硬解，靠的是一套叫MPP（Media Process Platform）的底层媒体处理库。FFmpeg和MPP对接之后，你会看到一批带rkmpp后缀的编解码器，例如h264_rkmpp、hevc_rkmpp、mjpeg_rkmpp。它们不像软件编解码那样让CPU硬扛，而是把解码、编码工作交给芯片里的视频处理单元。问题在于，绝大多数Linux发行版仓库里的FFmpeg包，打包时不会把rkmpp相关模块编进去。所以你就算用系统FFmpeg砸掉一颗CPU核心，也调不动芯片自带的硬解硬编。
我在群里见过不少人走弯路：从网上随便找了个所谓“全功能静态FFmpeg”二进制文件，拖到板子上直接跑，结果要么缺库，要么解码器列表里根本没有rkmpp，要么是编译参数对不上芯片型号。这种事情一次两次还好，多了就明白——给Rockchip设备定制FFmpeg，最可靠的方式就是自己拉源码，自己开configure选项，自己编译安装。只有源码编译这条路，才能把硬件编解码、第三方软编解码库、滤镜组件全部按需组合起来。
接下来的内容适合这么几类人参考：想在RK35xx系列开发板上做视频监控转码的朋友，打算把FFmpeg嵌进边缘网关或自制NAS的朋友，以及被预编译包坑过、想搞明白整个编译安装链路到底怎么回事的朋友。我会把流程、参数、报错、验证方法全部摊开讲，包括我实际踩过的坑和对每个关键选择的思考过程。
不用太担心门槛，我默认你已经有一块能跑Linux的Rockchip开发板，会基本的终端操作。剩下的，按步骤来就行。
2. 编译前环境摸底：芯片型号、系统版本、MPP库与编译依赖一个都不能少
2.1 先确认芯片和系统再动手，避免南辕北辙
编译安装的第一步不是拉代码，而是确认你手里的设备到底是什么芯片、什么系统版本。Rockchip的产品线跨度很大，从老式的RK3288、RK3399，到后来的RK3568、RK3588，指令集和MPP能力都不一样。绝大部分新板子都是64位ARM环境，但也有少量32位系统或者跑Android的机器，编译前提完全不同。
我先跑这几个命令：
uname -m # 预期输出 aarch64 cat /proc/device-tree/model # 设备型号，能看到类似 Rockchip RK3588 EVB 之类的信息 nproc # 查看CPU核数 free -h # 查看内存 df -h /home # 确认编译分区剩余空间uname -m输出如果是aarch64，说明是64位系统，后面编译就用arm64/aarch64那套配置逻辑；如果输出armv7l之类，说明是32位用户空间，很多依赖包的选型就不一样。设备型号也值得看一眼，因为某些板子虽然同是RK3588，但电源策略、解码器授权可能略有差异，遇到和硬件相关的问题时，这个信息能帮你快速定位。
内存和磁盘也要心里有数。完整编译FFmpeg加第三方库，源码加中间产物大概需要3GB到5GB磁盘空间。内存方面，并行编译时每个gcc进程都可能吃几百MB，如果你手头板子内存只有2GB，编译时八成会遇到进程被系统杀掉的问题。后面我会专门说swap的处理方法，但至少现在要摸底。
2.2 把基础编译工具和依赖库装齐
我习惯在官方Debian/Ubuntu类系统上操作，先更新索引，然后一次性装齐基础工具链：
sudo apt update sudo apt install -y build-essential gcc g++ make pkg-config yasm cmake git libdrm-dev这里每个包都有它的用途，别嫌多：
build-essential：提供gcc、make、基础头文件，编译C/C++项目的标配。pkg-config：FFmpeg配置阶段查找第三方库的“雷达”。没有它，FFmpeg经常找不到已经装好的库。yasm：FFmpeg里x86优化汇编需要的东西。虽然在ARM平台上也编译C代码，但FFmpeg构建系统仍会检查yasm，缺了会在configure阶段报错。libdrm-dev：DRM（Direct Rendering Manager）开发库。rkmpp硬件编解码接口经常要配合DRM管理显存/帧缓冲，编译MPP或FFmpeg的DRM支持时大概率会用到。cmake：如果你需要额外编译MPP源码或者其他第三方库，cmake是常见构建工具。
另外我强烈建议装上libx264开发包，因为硬编码并不是所有格式都能覆盖。像H.264、H.265主流的硬编没问题，但你要是遇到某些老编码格式，或者硬编参数不能满足需求时，软编x264就是可靠的兜底方案。装软编库：
sudo apt install -y libx264-dev如果是做更重型转码，可以考虑再加libx265-dev、libvpx-dev，但本文核心是Rockchip硬件编解码，先把x264这个兜底方案搞定即可。
2.3 MPP开发库：确认系统里有没有，没有就自己编一份
现在关键问题来了：rkmpp模块编译时需要一个叫MPP的开发库，包含头文件和动态库。不同发行版对MPP的处理差异很大。有些Rockchip官方BSP或深度定制的系统镜像，librockchip_mpp.so已经躺在系统里了；但也有不少通用Debian镜像压根没有。
先查一下：
ldconfig -p | grep -i mpp ls /usr/include/rockchip 2>/dev/null || ls /usr/local/include/rockchip 2>/dev/null如果能看到类似librockchip_mpp.so.1的动态库以及头文件目录，说明系统已经带上了。如果啥都没有，就需要自己拉MPP源码编译。我用的做法是：
git clone https://github.com/rockchip-linux/mpp.git cd mpp mkdir build && cd build cmake .. make -j$(nproc) sudo make install sudo ldconfigMPP编译安装后，默认头文件会放到/usr/local/include/rockchip，库文件放到/usr/local/lib。这一步完成后再回来编译FFmpeg，--enable-rkmpp选项才有依赖可查。这里特别提醒一句：如果你发现系统里已经有MPP动态库，但configure阶段依然报找不到mpp，优先排查PKG_CONFIG_PATH，因为MPP的.pc文件可能安装在非默认搜索路径。
2.4 本机编译还是交叉编译？我的建议是直接本机编
Rockchip设备上编译FFmpeg，很多人第一反应是做交叉编译：在x86电脑上配好aarch64工具链，然后通过sysroot传输依赖。这件事情本身不难，但坑非常多。你要维护一套包含所有第三方库target版本的sysroot，还要搞清编译器前缀、链接器参数，经常是依赖库版本对不上，报错报得莫名其妙。
我的建议是，只要能ssh到板子上，就直接本机编译。以RK3588为例，8核A76处理器编译完整FFmpeg，一般十来分钟到半小时就能搞定，完全在可接受范围。本机编译的好处是不需要关心交叉编译路径、不需要为每个依赖库单独指定target前缀，configure会根据当前系统自动探测。对RK35xx这种性能不算弱的SoC，本机编译的体验远好于交叉编译。
如果板子内存偏小，编译前建议先做2GB的swap兜底。我常用这种最朴素的swap创建方式：
sudo fallocate -l 2G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile内存不足时，swap能救回一大票“莫名其妙的编译失败”。你可以把上面四行命令写成一个脚本，每次重装系统后跑一遍就行。
3. configure参数逐项拆解：从软件编解码兜底到RKMPP硬件加速的完整开关
3.1 一套经过验证的典型configure命令行
进入FFmpeg源码目录后，真正决定编译产物能力的是./configure这一步。我用的是下面这组参数，兼顾了硬件编解码、软编兜底和安装位置安全性：
cd ~/FFmpeg ./configure \ --prefix=/opt/ffmpeg \ --enable-gpl \ --enable-version3 \ --enable-libdrm \ --enable-rkmpp \ --enable-libx264 \ --enable-shared \ --enable-static \ --extra-cflags="-I/usr/local/include" \ --extra-ldflags="-L/usr/local/lib"先说明一下：不同FFmpeg版本、不同MPP分支，configure选项名可能略有差异。我的建议是先跑一条探测命令，确认你的FFmpeg源码里到底认不认这些开关：
./configure --help | grep -E "rkmpp|libdrm|libx264"如果--help里看不到rkmpp，那说明你拉取的FFmpeg版本可能太老，或者没有包含Rockchip MPP对接层的补丁。建议换成较新的发布分支再试。官方仓库的master分支一般都能看到--enable-rkmpp。
3.2 每个选项在干什么：不是背参数，是真正理解取舍
--prefix=/opt/ffmpeg是我特别想强调的一点。很多人习惯直接默认前缀/usr/local，或者更粗暴地覆盖系统/usr。我的经验是尽量安到/opt/ffmpeg，跟系统自带的FFmpeg隔离。这样系统升级、apt更新都不会互相污染，想卸载时删掉整个目录就行，不会把系统搞得乱七八糟。
--enable-gpl和--enable-version3这两个许可证选项看似无聊，其实直接决定了libx264等库能不能编进去。libx264是GPL许可，FFmpeg要链接它必须开启GPL兼容选项。如果不开，configure大概率会在探测libx264时报错。
--enable-libdrm和--enable-rkmpp是本文的主角。DRM模块提供显示/显存管理相关的接口，RKMPP硬件编解码在部分流程中依赖它来做buffer管理。--enable-rkmpp则直接打开Rockchip MPP对接层，编进去之后编解码器列表里才会出现h264_rkmpp、hevc_rkmpp。如果这两个选项没开，后面验证阶段你翻遍解码器列表也找不到硬编硬解模块。
--enable-libx264是软编兜底方案，前面说过，硬编码不是万能的。比如视频分辨率、编码格式、帧率不在硬件支持范围内时，使用的编码器会直接报错，这时候一套配置完整的x264软编能让你保证输出链路不断。我见过不少老司机“过度迷信硬编”，结果遇到不支持的输入格式时整个任务卡死，最后还得把软编重新编译进去，绕了一大圈。
--enable-shared和--enable-static我习惯两个都开。正常使用命令行工具，静态库其实更方便，拷到别的同型号设备上不用带一堆动态库。但如果你以后想在板子上自己写C程序调用FFmpeg库，或者集成到Python的imageio-ffmpeg之类组件里，动态库又是少不了的。两个都编不会带来额外安装负担，只是磁盘多占一点。
3.3 三个常见的configure报错与我的处理逻辑
我编译过程中遇到最多的三个报错，基本模式固定：
| 报错提示 | 原因 | 处理方案 |
|---|---|---|
ERROR: libx264 not found | 找不到x264头文件或库 | 确认libx264-dev已装；额外指定PKG_CONFIG_PATH=/usr/lib/aarch64-linux-gnu/pkgconfig |
ERROR: mpp requested but not found | MPP开发库没在默认路径 | 检查MPP是否编译安装；把-I/usr/local/include和-L/usr/local/lib加到extra参数里；检查.pc路径 |
ERROR: libdrm not found | DRM头文件/库缺失 | apt install libdrm-dev，确认包名匹配系统版本 |
很多配置阶段的报错都能用同一条命令快速定位：configure执行中途会生成一份config.log，记录了它探测每个依赖时执行的命令和失败原因。遇到问题时别凭猜，直接：
tail -n 100 config.log这是最快最靠谱的排错入口。顺便提醒一句，如果第一次configure失败了，你修复依赖后重新configure之前，最好先执行make distclean清掉上次的残留配置。我吃过这个亏，改了前缀，结果编译产物还是按旧路径装的，折腾了半天。
3.4 静态库还是动态库：不影响功能，但影响你部署方式
如果你追求极致的“单文件跑路”，可以只开--enable-static，生成一个独立静态链接的ffmpeg可执行文件。我记得第一次在RK3588上配好后，把静态编译出来的ffmpeg拷贝到另一块同型号板子上直接就能运行，没有动态库依赖的烦恼。
但静态编译对第三方库的依赖要求更高，任何一个库缺失都会导致整个配置失败。动态编译则更灵活，甚至可以--disable-static --enable-shared只生成动态库，配合自定义前缀使用。两种方式我都试过，实际项目里我更倾向静态为主、兼顾动态，既能单独分发，又保留了二次开发的空间。如果你只是自用，选哪一种都不影响功能。
4. 从拉取源码到make install的完整执行流程，以及我实际遇到的失败排查记录
4.1 一次顺利执行的完整命令序列
在依赖和MPP都准备好的前提下，完整流程是这样的：
git clone --depth 1 https://github.com/FFmpeg/FFmpeg.git cd FFmpeg ./configure \ --prefix=/opt/ffmpeg \ --enable-gpl \ --enable-version3 \ --enable-libdrm \ --enable-rkmpp \ --enable-libx264 make -j$(nproc) sudo make install sudo ldconfigmake -j$(nproc)理论上会启用全部核心并行编译，但我还是建议在内存不宽裕的板子上保守一点，比如RK3588这种8核设备，用-j4或-j6更稳妥。并行任务过多，每个编译进程的内存峰值叠加起来很容易触发OOM killer。
编译等待时间取决于芯片和源码版本，一般RK3588编完整FFmpeg大约十几分钟到二十分钟。中途如果看到个别warning，不用太紧张；但如果出现error:和make: ***这类字样，就得停下来排查。
4.2 踩坑记录一：OOM导致进程被静默杀掉的排查链路
我印象最深的一次失败，是编译完libavcodec后，执行链接步骤时整个进程突然消失，终端里没有报错，只是返回shell。我当时第一反应是网络问题，但重跑一遍同样在接近相同位置“静默退出”。
后来我查看了内核日志：
dmesg | tail -n 50结果看到了经典的Killed process ... total-vm:... anon-rss:...字样，这就是内存不足被OOM killer干掉了。再往后查free -h，发现板子本身内存只有2GB，可用内存在编译高峰阶段几乎归零。
解决方式就是我前面说的加swap，并且把make -j$(nproc)改成make -j2或make -j4。换成这两个改变之后，编译顺利走完。这里有个经验：arm板子编译大型项目，不要迷信“并行越多越快”，内存瓶颈往往比CPU瓶颈先到。
4.3 踩坑记录二：改了configure参数但没清理，编译出一堆“过时”产物
第二次踩坑更隐蔽。我第一次configure时没有加--enable-libx264，后来想补上软编支持，直接重新跑了configure，没有执行make distclean，然后就make && make install。编完一看，ffmpeg命令确实在，但-encoders列表里没有x264，反复确认选项没写错，却像是被无视了。
后来查资料才明白，FFmpeg构建系统会缓存上一次configure的探测结果。如果你改动configure参数，最好是make distclean清掉所有缓存和中间文件，再重新configure，尤其是新增/删除模块时更是如此。从那以后，我每次调整配置前都会顺手执行一次：
make distclean4.4 踩坑记录三：libx264颜色格式导致硬编初次测试直接失败
这个坑严格来说属于后面的验证阶段，但放在编译阶段一起说更合适。第一次硬编码H.264成功之后，我尝试把一路RGB输入的视频直接交给h264_rkmpp，结果报错提示无法处理该像素格式。查阅文档后发现，RKMPP硬件编解码器对输入色彩格式有硬性要求，很多编码器不接受任意像素格式。
给FFmpeg加一层格式转换就能解决：
-vf "format=nv12"这里的NV12是Rockchip硬件编码器最常接受的输入格式之一。如果你的视频源来自屏幕录制或某些滤镜链，输出给硬件编码器之前先统一转成NV12，可以避免绝大多数的“format not supported”问题。这个经验看起来小，但能救新手一条命。
5. 硬解硬编实测：确认rkmpp模块生效，并跑通H.264/H.265硬件转码
5.1 第一件事：确认FFmpeg里真的编进了rkmpp
编译安装完成后，不要急着转码，先做三件事验证：
/opt/ffmpeg/bin/ffmpeg -version /opt/ffmpeg/bin/ffmpeg -decoders | grep rkmpp /opt/ffmpeg/bin/ffmpeg -encoders | grep rkmppffmpeg -version输出的最后一行会包含完整configure参数，能看到--enable-rkmpp字样。第二和第三条命令会在解码器/编码器列表里过滤出带rkmpp的项目。如果能看到h264_rkmpp、hevc_rkmpp等，说明模块已生效；如果列表为空，回到configure环节重新排查。
这里有个细节：默认情况下/usr/bin/ffmpeg可能是系统仓库版本。我建议测试时始终用全路径/opt/ffmpeg/bin/ffmpeg，或者在~/.bashrc里把/opt/ffmpeg/bin加到PATH前面，避免稀里糊涂用的还是旧版本。
5.2 硬解码测试：让芯片解码单元接管繁重任务
先用一段H.265视频测试硬解码。最简单的验证方式是解码不输出视频文件，只做null输出，通过CPU占用率和帧率判断是否真正启用了硬件：
/opt/ffmpeg/bin/ffmpeg -hwaccel rkmpp -i input_hevc.mp4 -f null -加-hwaccel rkmpp的意思是优先使用RKMPP硬件加速解码。跑的时候开另一个终端看CPU占用，如果CPU占用明显偏低，而画面帧率能稳定在源视频帧率附近，说明硬解生效。如果不加这个参数，同样的文件用软件解码，CPU占用率会高出好几个数量级。
如果-hwaccel rkmpp对某些编码格式不生效，可以尝试显式指定解码器，比如-c:v hevc_rkmpp -i input_hevc.mp4。这个显式写法能避免同一种编码格式有多个解码器时FFmpeg选错。
5.3 硬编码测试：H.264与H.265一例通吃
硬编码测试我通常用一个本地视频文件作为输入，输出H.264 MP4，命令如下：
/opt/ffmpeg/bin/ffmpeg -i input.mp4 \ -vf "format=nv12" \ -c:v h264_rkmpp \ -b:v 4M \ -f mp4 -tag:v avc1 \ output_h264.mp4参数拆解：
-vf "format=nv12"：把输入视频统一转成NV12，避免像素格式不兼容的报错。-c:v h264_rkmpp：使用Rockchip硬件H.264编码器。-b:v 4M：目标码率4Mbps，可根据实际场景调整。-f mp4 -tag:v avc1：MP4封装时打上AVC1标签，保证常见的播放器能正确识别H.264视频流。这个细节非常重要，我之前生成的MP4在部分播放器里渲染异常，加上-tag:v avc1后问题消失。
H.265硬编码几乎一样，把编码器换成hevc_rkmpp即可：
/opt/ffmpeg/bin/ffmpeg -i input.mp4 \ -vf "format=nv12" \ -c:v hevc_rkmpp \ -b:v 4M \ -f mp4 -tag:v hvc1 \ output_hevc.mp4部分MPP版本还支持码率控制模式参数，比如-rc_mode CBR或-rc_mode VBR，具体以你编译的MPP分支提供的选项为准。想查看编码器支持的参数列表，可以用：
/opt/ffmpeg/bin/ffmpeg -h encoder=h264_rkmpp5.4 实际性能对比：为什么值得折腾这些模块
以一块RK3588开发板为例，我做个不严谨但有参考意义的对比：
| 处理方式 | 4K 30fps H.265解码 | 1080p转码到H.264 | CPU总体占用 |
|---|---|---|---|
| 纯软件解码+x264软编 | 帧率明显不稳 | 经常卡顿 | 70%以上 |
| rkmpp硬解+x264软编 | 稳定流畅 | 基本可实时 | 40%左右 |
| rkmpp硬解+h264_rkmpp硬编 | 稳定流畅 | 远超实时 | 10%左右 |
数据会因主板、电源、散热条件浮动，但趋势非常明显：硬件解码/编码一旦接通，CPU占用率会大幅下降。对于长期跑7x24小时转码任务的边缘设备，这个优势直接决定散热和稳定性。
我印象很深的一次实践是同时处理四路1080p H.265 RTSP流，纯软解CPU早就拉满了；切到rkmpp硬解接入后，整体CPU占用直接掉到二三十，四路同时转码游刃有余。
5.5 权限与设备节点：看不到硬编设备时的排查方向
如果你确认rkmpp解码器/编码器都存在，但执行时一直报硬件打开失败，优先检查当前用户有没有访问/dev/dri/renderD128这类GPU/VPU设备节点的权限。
ls -l /dev/dri/renderD128 groups一般解决办法是把用户加到video组，然后重新登录：
sudo usermod -aG video $USER这条经验在树莓派、Rockchip等多种设备上都通用。硬件编解码不是普通IO操作，权限问题卡住的概率比想象中高很多。
6. 把编译好的FFmpeg装进系统的后续细节：版本隔离、动态库路径与升级维护
6.1 为什么我用 /opt/ffmpeg 而不是覆盖系统目录
编译安装完成后，很多人会顺手sudo ln -s /opt/ffmpeg/bin/ffmpeg /usr/bin/ffmpeg。我强烈不建议这么做，因为系统的包管理器不知道这个文件的存在，以后但凡遇到系统更新或某个软件依赖旧版FFmpeg，就可能出现版本冲突。
更稳妥的做法是在/etc/profile.d/ffmpeg.sh里加一段环境变量，只对当前用户或登录shell生效：
export PATH=/opt/ffmpeg/bin:$PATH export LD_LIBRARY_PATH=/opt/ffmpeg/lib:$LD_LIBRARY_PATH如果你编译的时候开了--enable-shared，那LD_LIBRARY_PATH必须配上，否则执行/opt/ffmpeg/bin/ffmpeg会因为找不到libavcodec.so而报错。静态编译的话第四行可以不加，但我仍然建议加上，因为你以后可能还会往/opt/ffmpeg/lib里放其他动态库。
6.2 与系统自带FFmpeg共存的关键习惯
安装到独立前缀以后，系统里会同时存在两个ffmpeg：
/usr/bin/ffmpeg：系统仓库版，通常没有rkmpp模块。/opt/ffmpeg/bin/ffmpeg：我们编译的硬件加速版。
为了避免日常使用中“以为自己用的是新版本，结果还是旧版本”的尴尬，我建议养成两个习惯：第一，所有脚本、systemd服务里写全路径/opt/ffmpeg/bin/ffmpeg；第二，手动测试时先执行which ffmpeg确认当前终端的解析顺序。像前面说的，/etc/profile.d里的PATH会优先把/opt/ffmpeg/bin放在前面，但如果你的shell加载顺序有差异，结果可能不一样。
6.3 后续升级与维护：不要每次重编都从头再来
FFmpeg更新频率不低，过几个月可能就有新版本修复漏洞或新增编码器。升级流程其实不复杂：
cd ~/FFmpeg git pull make distclean ./configure <同样的参数> make -j4 sudo make install关键点是make distclean。如果你直接复用旧配置，很可能出现新增模块没生效、旧模块残留等问题。我建议把configure命令保存成一个shell脚本，比如build_ffmpeg.sh，每次升级时直接调用，避免重复敲命令。
6.4 动态库被调用的边界情况
如果你编译了--enable-shared，还有一个容易被忽略的问题：当板子上装了其他依赖于FFmpeg动态库的软件时，它们可能通过系统路径找到动态库，而不是通过LD_LIBRARY_PATH。比如某些Python视频处理库通过import av调用系统FFmpeg库，如果你的系统环境变量没设置好，硬编能力根本传不过去。
这种情况有两种解决思路：一是把/opt/ffmpeg/lib下的.so文件做成符号链接放进/usr/lib/aarch64-linux-gnu等系统库目录；二是在运行目标程序前显式设置LD_LIBRARY_PATH。第一种方式我踩过坑：符号链接放错位置可能被系统包管理器升级时误删，还得回头补。第二种方式其实更可控，也更适合systemd服务这类运行环境。
6.5 最后的经验：这种编译安装最大的收益是“掌控感”
从系统仓库版FFmpeg切换到自编译版之后，最大的收益不是那点性能提升，而是对整个软硬件栈的掌控感。你清楚知道哪条codec走了硬解码、哪个filter是哪个版本、哪个编解码器依赖了哪份MPP库。出问题时不再是“听说系统版本可能缺模块”这种模糊判断，而是可以直接打开/opt/ffmpeg/bin/ffmpeg -version看configure字符串，精确到每一个模块的状态。
后续如果你想把FFmpeg能力集成到GStreamer里，或者用它在板子上跑视频分析流水线，这套自定义编译的FFmpeg就是最扎实的地基。你已经知道怎么改configure、怎么加依赖、怎么清理缓存、怎么验证模块，再往后捣鼓其他媒体库，基本就是同一套方法论换皮而已。这也是我在Rockchip设备上编译完FFmpeg以后，最大的心得体会。
