★ FEATURED ARTICLE 1. 从一颗 RK3528 说起为什么 1GB 内存还能同时跑六种协议第一次看到“RK3528 1GB 内存 六协议 硬编硬解 AI 绿幕”这组参数摆在一起我的直觉是这要么是参数写错了要么是把一堆功能拆成不同固件版本分别实现的。因为按照常规经验光是软件编码加协议栈1GB 内存跑一个 1080p30 的推流就已经很紧张了更别说还要塞进 AI 推理和绿幕抠像。但把 RK3528 这颗芯片的规格摊开看事情就说得通了。RK3528 是四核 Cortex-A53 架构主频在 1.5GHz 上下集成了独立的视频编解码单元VPU和神经网络处理单元NPU。关键在于“独立”两个字——编码、解码、AI 推理这三件事走的是不同的硬件通路不抢 CPU 的通用算力也不抢同一块内存带宽的峰值窗口。1GB 内存之所以够用是因为大部分数据流转发生在硬件模块之间走的是 DMA 通道和专用缓存而不是全部塞进系统主存里反复拷贝。这就引出了整篇文章要讲的核心逻辑低成本直播方案的上限不取决于 CPU 有多强而取决于你有没有把该交给硬件的事情交给硬件把内存留给真正需要它的环节。我见过太多人拿到这类板子之后第一反应是装一个通用推流软件然后发现帧率上不去、延迟忽高忽低、开个绿幕直接卡死。问题往往不在板子本身而在于软件路径把硬件能力绕过去了。下面我会从硬件通路、协议栈选型、内存分配、AI 与绿幕的接入方式、实测调优几个层面把这条链路完整拆一遍。提示本文讨论的所有方案均基于本地局域网和常规互联网推流场景不涉及任何特殊网络配置。2. 六协议并存的真实含义不是同时推六路而是按场景切换2.1 先搞清楚“六协议”到底指哪六种标题里的“六协议”很容易让人误解成同时向六个平台推流。实际在嵌入式直播方案里更常见的定义是设备支持六种主流的流媒体传输协议根据使用场景选择其中一种或两种组合使用。这六种通常包括协议类型典型用途延迟水平硬件加速依赖RTMP推流到直播平台2-5秒编码器输出即可RTSP局域网拉流、监控回传0.5-2秒解码器参与SRT弱网环境下的稳定传输1-3秒编码器网络栈HLS兼容性最好的分发5-15秒切片由CPU处理HTTP-FLV低延迟网页播放1-3秒编码器输出WebRTC超低延迟互动0.2-1秒编解码网络栈把这六种协议全部塞进一颗 1GB 内存的板子里核心思路不是让它们同时满负荷运行而是共享同一套编解码硬件资源协议层只做封装和传输。编码器出来的 H.264/H.265 裸流可以被不同协议模块分别封装不需要重复编码。这一点是省内存的关键。2.2 协议栈的内存开销差异比想象中大很多人算内存账的时候只算编码器占用忽略了协议栈本身的开销。实测下来不同协议在 1080p30 码率 4Mbps 条件下的内存占用大致是这样的RTMP 推流模块约 15-25MB主要是发送缓冲和握手状态RTSP 服务端约 20-35MB每个客户端连接额外增加 8-12MBSRT 发送端约 30-50MB因为自带重传缓冲和延迟队列HLS 切片器约 40-80MB取决于切片时长和保留的切片数量HTTP-FLV约 15-20MB和 RTMP 接近WebRTC约 50-100MBICE、DTLS、拥塞控制都要吃内存如果六种协议同时常驻运行光协议栈就要吃掉 200MB 以上再加上系统本身 200-300MB编码器缓冲 100MB 左右1GB 内存确实所剩无几。所以正确的做法是按需加载协议模块默认只启动一种其他协议在收到切换指令时再初始化。这样常驻内存可以控制在 400MB 以内留出足够空间给 AI 和绿幕。2.3 协议切换时的状态清理最容易出问题我在实际调试中发现协议切换最大的坑不是启动新协议而是旧协议没清理干净。比如从 RTMP 切到 SRT如果 RTMP 的发送线程没有正确 join它的缓冲区就不会释放切几次之后内存就爆了。建议的做法是切换前先停止编码器输出让数据流断掉调用协议模块的 deinit 接口等待所有线程退出用free或/proc/meminfo确认内存回到基线再初始化新协议重新启动编码器这个流程看起来简单但在嵌入式环境里线程退出超时是常有的事。我的经验是给 deinit 加一个 3 秒超时超时后强制释放资源并记录日志宁可丢一次切换也不能让内存泄漏累积。3. 硬编硬解的实际调用路径别让软件路径偷走你的帧率3.1 编码器选型H.264 还是 H.265RK3528 的 VPU 同时支持 H.264 和 H.265 的硬件编码。从带宽角度看H.265 在同等画质下能省 30%-40% 的码率对网络条件不好的场景很有吸引力。但有几个现实问题需要考虑部分直播平台对 H.265 推流的支持还不完整可能收到流但无法转码分发H.265 编码的硬件延迟通常比 H.264 高 10-20ms绿幕抠像后的画面如果边缘处理不够干净H.265 的压缩会放大这些瑕疵我的建议是如果推流目标是主流直播平台优先用 H.264如果是局域网内部使用或者自建分发可以用 H.265 省带宽。两者在 RK3528 上的 CPU 占用差异很小因为都是硬件在做。3.2 从摄像头到编码器的数据通路这条通路如果走错了帧率直接腰斩。正确的硬件路径是摄像头 MIPI CSI 接口 → ISP 处理 → VPU 编码输入队列 → 硬件编码 → 码流输出如果中间任何一步走了 CPU 拷贝比如先把 YUV 数据读到用户空间再喂给编码器1080p30 的帧率就会掉到 15-20 帧。判断方法很简单用top看 CPU 占用如果编码时某个核跑满基本就是走了软件路径。在软件层面需要确认你用的采集接口是直接输出 DMA buffer 的。常见的 V4L2 采集如果配置成 MMAP 模式并且编码器支持从 DMA fd 直接导入就能避免拷贝。这一步的配置因 SDK 版本而异但核心是查清楚采集输出的 buffer 能不能被编码器直接引用。3.3 解码回显场景下的资源竞争有些直播方案需要本地预览也就是编码的同时还要解码回显。这时候 VPU 要同时做编码和解码虽然硬件支持但内存带宽压力会明显上升。实测在 1080p30 编码 1080p30 解码回显的情况下DDR 带宽占用会从 30% 左右跳到 55%-60%。如果还要叠加 AI 推理NPU 也要访问内存三者同时跑的时候带宽就可能成为瓶颈。缓解办法有两个一是降低预览分辨率比如预览用 720p二是预览帧率降到 15 帧人眼对预览的流畅度要求没有推流那么高。4. 1GB 内存的分配艺术哪些环节必须省哪些不能省4.1 系统基线内存的压缩一个带完整 Linux 系统的 RK3528 方案开机后系统本身占用通常在 250-350MB。如果用的是带桌面环境的发行版这个数字会更高。做直播推流不需要图形界面建议使用精简的根文件系统去掉不必要的服务关闭桌面环境和显示管理器内核裁剪掉不用的驱动模块用 busybox 替代完整的 coreutils这样可以把系统基线压到 180-220MB。省下来的 100 多 MB 对 1GB 内存来说非常关键。4.2 编码器缓冲区的合理设置硬件编码器需要一定数量的输入和输出缓冲。缓冲太少会导致丢帧太多会浪费内存。以 1080p30 为例每帧 YUV420 数据约 3MB如果输入队列设 8 个缓冲就是 24MB输出码流缓冲设 4 个约 2MB。这个配置在实测中比较平衡。但如果你开了绿幕抠像输入帧需要额外经过 GPU 或 NPU 处理中间会产生额外的纹理缓冲。这部分内存要在规划时预留出来通常需要多留 30-50MB。4.3 AI 模型的内存占用与加载策略NPU 跑推理时模型本身和中间张量都要占内存。一个轻量级的人体检测或人脸检测模型量化后大约 2-8MB但推理时的中间缓冲可能是模型大小的 3-5 倍。如果同时跑多个模型内存增长很快。我的做法是模型按需加载用完即卸。比如绿幕场景只需要人像分割模型那就只加载这一个。如果还需要人脸检测做特写跟踪再动态加载第二个。加载和卸载的耗时在 100-300ms 之间对直播来说可以接受只要不在推流过程中频繁切换就行。4.4 用 zram 换空间的取舍1GB 内存的设备上开 zram 做压缩交换是很常见的操作。但直播场景要谨慎zram 压缩和解压要消耗 CPU如果内存压力大到频繁换页CPU 会被拖垮编码帧率直接崩。我的建议是zram 可以开但只作为兜底不要指望它解决内存不足。设置一个较小的 zram 设备比如 256MBswappiness 调到 10 以下让系统只在极端情况下才换页。真正的手段还是前面说的按需加载和及时释放。5. AI 与绿幕的接入NPU 和 GPU 各干各的活5.1 绿幕抠像到底该用 GPU 还是 NPU这是很多人纠结的问题。传统绿幕抠像是基于颜色空间的用 GPU 做色度键控chroma key效率很高几毫秒就能处理一帧 1080p。但纯色度键控对光照变化很敏感背景不均匀时边缘会很脏。用 NPU 跑人像分割模型好处是不依赖绿幕颜色甚至不需要绿幕直接做背景替换。但 NPU 推理有延迟轻量模型在 RK3528 上跑 1080p 大概 30-50ms 一帧也就是 20-30 帧的处理能力刚好够 30 帧推流但余量不大。实际方案里我倾向于两者结合用 GPU 做快速的色度键控得到初步 mask再用 NPU 的分割结果做修正特别是头发边缘和半透明区域。这样既保证了速度又提升了边缘质量。当然如果算力实在紧张只保留 GPU 色度键控也能用只是对布景要求高一些。5.2 抠像后的合成与编码衔接抠像完成后前景需要和新的背景合成。这一步如果走 CPU 做 alpha blending1080p30 会吃掉一个核的 40%-60% 算力。更好的方式是用 GPU 的 2D 加速单元做混合或者让 NPU 输出 mask 后由 VPU 在编码前直接做混合。这里有个细节合成后的画面如果直接送给编码器要确保颜色空间一致。摄像头出来通常是 YUV420GPU 处理可能在 RGB 空间混合后要转回 YUV420 再编码。这个转换如果由 GPU 做开销很小如果由 CPU 做又是几十毫秒的消耗。5.3 AI 推理的帧率匹配问题NPU 推理帧率和编码帧率不一定要一致。如果 NPU 只能跑 20 帧而编码要 30 帧可以让 mask 以 20 帧更新中间帧复用上一帧的 mask 做插值或直接沿用。人眼对 mask 的帧率敏感度低于画面本身这种做法在实测中几乎看不出差别。但要注意如果画面中有快速运动mask 复用会导致边缘拖影。折中方案是检测运动幅度运动大时降低编码帧率到 24 帧让 NPU 跟上运动小时保持 30 帧mask 复用。6. 实测调优从能跑到跑稳之间差了什么6.1 延迟的构成与压缩空间端到端延迟可以拆成几块采集 5-10ms、处理抠像合成20-50ms、编码 10-20ms、网络传输 50-200ms、播放器缓冲 200-1000ms。硬件能控制的是前三块加起来 35-80ms。网络和播放器取决于平台和网络条件。如果发现延迟比预期高先查处理环节。用打点计时的方式在采集输出、抠像输入、抠像输出、编码输入、编码输出各记一个时间戳就能定位到是哪一段慢了。我遇到过抠像输出到编码输入之间因为格式转换多走了 30ms 的情况改成 GPU 直接输出编码器支持的格式后就消掉了。6.2 长时间运行的稳定性观察跑 10 分钟不卡不代表能跑 10 小时。长时间运行要关注几个指标内存是否有缓慢增长用watch -n 60 free -m观察温度是否稳定RK3528 长时间编码会发热散热不好会降频网络重连是否正常拔网线再插上看协议能否自动恢复我一般会做一个 24 小时的老化测试每 5 分钟记录一次内存、CPU 温度、帧率、码率。如果内存曲线是平的温度在 70 度以下帧率波动不超过 2 帧就算基本稳定了。6.3 散热对持续性能的影响RK3528 在满负荷编码AI 推理时芯片温度可以到 80 度以上。如果没有散热片几分钟后就会触发降频编码帧率从 30 掉到 20 甚至更低。加一个小的铝散热片配合机箱内的空气流动可以把温度压在 65-70 度基本不会降频。如果设备是密闭外壳建议加一个 5V 的小风扇或者把外壳做成金属的辅助散热。这点成本不能省否则前面所有的优化都会被热降频吃掉。7. 几个容易踩的坑和我的处理方式7.1 摄像头兼容性比想象中麻烦不是所有 MIPI 摄像头都能在 RK3528 上即插即用。不同厂家的 sensor 驱动、ISP 配置、时钟时序都有差异。我遇到过一款摄像头在 1080p30 下正常切到 720p60 就花屏的情况最后发现是 ISP 的某个寄存器配置没有随分辨率切换更新。选摄像头时优先选 SDK 里已经有参考配置的型号。如果没有至少要确认 sensor 驱动源码可用ISP 调优参数有文档。否则调试成本可能比板子本身还高。7.2 协议切换时的音频不同步视频协议切换时音频流如果没跟着切换会出现音画不同步。特别是从 RTMP 切到 SRT 时两者的时间戳基准可能不同。处理方式是在切换时同时重置音频和视频的时间戳基准让它们从同一个时刻重新计时。如果音频是独立采集独立编码的还要确保切换过程中音频不中断。我的做法是音频始终走同一个编码通路只切换封装和传输模块这样音频时间戳是连续的不会出现跳变。7.3 绿幕布光和抠像参数的关系绿幕抠像的效果七分靠布光三分靠算法。如果绿幕上有阴影或者褶皱再好的算法也抠不干净。布光要点绿幕本身要用均匀的柔光打亮避免热点和暗角人物要离绿幕至少 1 米减少绿色反光到人物边缘人物正面也要补光否则人脸暗部会和绿幕混在一起算法参数方面色度键控的阈值不要设得太激进宁可保留一点绿色边缘也不要把人物边缘抠缺。残留的绿色可以用边缘抑制spill suppression处理比抠缺了再补要容易。7.4 内存不足时的第一反应应该是查泄漏如果运行一段时间后内存持续下降不要急着加 swap 或者换更大内存的板子。先查泄漏用valgrind或者自己写脚本记录关键模块的分配释放次数。我遇到过协议模块每次重连都泄漏几 MB 的情况修掉之后内存曲线就平了。嵌入式环境里第三方库的泄漏很常见。如果确认是某个库的问题又没法改源码可以考虑定期重启该模块用时间换稳定。但这是下策能修则修。8. 这套方案适合谁不适合谁如果你的场景是单路 1080p 推流需要绿幕抠像和轻量 AI 分析预算有限RK3528 1GB 的方案是能跑通的。它的优势在于硬件通路完整编码、解码、AI 都有独立单元软件调优到位后可以稳定运行。但如果你需要同时推多路 4K或者要跑大模型做复杂分析这颗芯片就不够了。1GB 内存的上限摆在那里再怎么优化也突破不了物理限制。选型阶段就要想清楚不要指望后期优化能弥补硬件规格的差距。另外这套方案对软件调优的要求比较高。如果团队里没有人熟悉 V4L2、DRM、NPU 推理框架和流媒体协议栈上手周期会比较长。建议先从单协议单功能跑通再逐步叠加不要一上来就全功能开启。
阅读完成 · 觉得有帮助？
