搞嵌入式视频开发的人第一次在 hi3516ev200 上跑 RTMP 推流的时候十个里有八个都见过这行日志SAMPLE_COMM_VENC_GetVencStreamProc-2024: get venc stream time out, exit thr。这句话看着像某个线程被强杀退出了实际上它只是视频处理平台上取编码码流的线程在规定时间内没有等到 VENC 模块送出任何一帧数据于是主动退出。这个报错不挑板子带 VENC 的芯片方案几乎都可能撞上。问题本身也不难卡住人的地方在于它可能由启动流程、绑定关系、编码配置、线程调度、网络反压等好几种原因触发而日志只有一行信息量太少。今天我把这类超时问题掰开揉碎讲清楚从根因到排查思路再到能稳定跑的配置和代码一次讲透。适合正在调视频通路、或者打算在嵌入式设备上做 H.264/H.265 RTMP 推流的开发者参考。1. 这个报错到底在说什么1.1 报错出现的代码位置与执行逻辑在官方参考代码的 venc 线程里SAMPLE_COMM_VENC_GetVencStreamProc是一个通用的取流函数它内部一般会循环调用HI_MPI_VENC_GetStream。这个调用的第三个参数是超时时间单位毫秒。设成-1表示一直等到有数据为止设成1000就是最多等 1 秒设成0就是完全非阻塞。当返回结果不是“成功”的时候参考代码会打印这行日志然后break跳出循环最后走到exit thr。所以日志里出现“exit thr”不代表整个进程崩溃更不代表 VENC 编码器本身死掉了。它只是取流线程放弃等待主动退出了而已。这里有一个容易误判的点很多人看到“time out”就以为把超时时间调大就行比如从 1000 改成 3000、改成 5000。但如果你没有搞清楚“为什么拿不到一帧”调大超时只是把问题出现的时间往后推。真正的数据链路问题不解决超时迟早还会出现而且调大了超时反而会让日志更晚暴露故障排查效率更低。1.2 超时表示的三类信号从现象往本质看HI_MPI_VENC_GetStream返回超时透露出三个信号第一个信号是 VENC 通道里没有可用的编码帧。这是最常见的情况。可能是上游 VPSS 没有往通道送图可能是编码器没有接收帧也可能是缓冲区被占满导致新帧进不来。第二个信号是取流线程本身被阻塞太久。比如线程优先级太低被其他高优先级任务抢占或者代码里某个锁没有释放导致线程在调用GetStream之前就已经卡了很久。这种情况日志也会表现为超时但问题根本不在 VENC而在线程调度和锁竞争。第三个信号是超时时间设置得太短没有覆盖启动阶段的首帧延时。系统刚上电、摄像头还没出图、编码器第一帧还在排队的时候如果超时设置只有几十毫秒很可能在启动阶段就误报。把这类“启动阶段误报”和“运行过程中的持续性超时”分开看是定位问题的第一步。2. 最容易让“get venc stream time out”出现的 5 个根因2.1 启动流程少了一步StartRecvFrame 没调用先说一个极其隐蔽但高频的原因VENC 通道创建成功之后还需要调用HI_MPI_VENC_StartRecvFrame编码器才会真正开始接收输入图像。这个调用像是给 VENC 发了一条“开始干活”的命令。很多人在官方 sample 基础上改代码的时候会习惯性地精简初始化流程。VENC 相关代码里常常只保留了HI_MPI_VENC_CreateChn然后就去创建线程调GetStream结果发现从第一次取流开始就超时。看初始化日志一切正常看通道属性也挑不出毛病唯独忘了这个启动命令。判断是否是这个原因有一个很简单的特征如果超时发生在第一次取流并且是“每次都必现”而不是偶发优先检查启动序列里有没有HI_MPI_VENC_StartRecvFrame以及它的返回值是不是成功。注意不能只检查是否调用了HI_MPI_VENC_StartRecvFrame还要检查它有没有返回错误。在实际项目里我就见过因为重复调用导致第二次返回错误但代码只处理了第一次返回值的情况结果问题被日志掩盖了。2.2 通道配置内部矛盾帧率、尺寸、码率和 GOP 互相打架VENC 通道属性看起来就是一堆结构体字段但字段之间是有约束关系的。最常见的几个坑如下帧率字段设置成 0 或者设置得比实际输入帧率低编码器会产生节奏不一致。输入帧率 25 而通道配置成 12编码器每两帧才处理一帧取流侧需要等更长时间如果上游送帧模式又是按需发送通道可能一直不输出。尺寸字段必须和输入图像尺寸匹配。比如 VPSS 送给 VENC 的分辨率是 720x1280而通道配置成 1280x720部分 SDK 版本下 VENC 无法编码队列一直为空。旋转、缩放应该在 VPSS 端做完VENC 只负责编码尺寸不匹配这种低级错误最容易让人绕远路。码率控制参数也要合理。CBR 模式下目标码率如果设得太小编码器会为了保证码率而提高量化参数甚至在某些异常参数组合下进入不输出帧的状态。GOP 设置过大会让两个 I 帧之间间隔很长但正常情况不会导致 GetStream 超时只是拉流首帧画面出现慢。我的建议是先照搬官方 sample 里同分辨率同编码格式的参数组合跑通之后再一步一步改。不要一开始就追求“最优参数”先把链路打通再来折腾画质和码率。2.3 上游绑定关系断掉VPSS 到 VENC 的数据流没建立在典型的视频处理流程里数据走向是 VI - VPSS - VENC。VPSS 的输出通道通过HI_MPI_SYS_Bind和 VENC 的通道绑定绑定之后数据才会自动从 VPSS 流入 VENC。这个环节出现问题的特征是VENC 通道创建成功启动成功但一直没有数据进来。常见原因如下第一只绑定了 VPSS 到 VENC却没有执行HI_MPI_SYS_EnableBind或对应的使能操作绑定名存实亡。第二VPSS 本身没有正常工作。VPSS 组的时钟、工作模式、通道属性如果配置不对或者 VI 端没有在出图VPSS 就没有帧可送。VENC 上游没数据取流线程等到天荒地老也等不到一帧。第三重复执行了 unbind 操作。调试过程中有人喜欢每次初始化都先HI_MPI_SYS_Unbind再Bind如果 unbind 执行了两次而 bind 只执行了一次链路就被自己弄断了。遇到这类问题单看 VENC 日志是不够的。我建议在 VPSS 通道的取帧回调里打一个计数器或者在调试工具里观察 VPSS 通道统计确认 VPSS 是不是真的在出帧。把上下游分开验证很快就能定位断点。2.4 取流后忘了 ReleaseStreamVB 缓存池被自己耗干这个原因特别容易发生在从单线程 sample 改成多线程项目时。HI_MPI_VENC_GetStream拿到的是内部缓冲区的指针。每取走一帧对应的 buffer 就处于“被借用”状态必须调用HI_MPI_VENC_ReleaseStream把 buffer 还给 VENC 模块VENC 才能继续使用这块内存存下一帧编码数据。如果你只 GetStream 不 ReleaseStream一开始可能还能拿到几帧但随着 buffer 池被消耗完编码器没有空闲 buffer 存放新编码帧后续GetStream就会一直超时或者返回 buffer 相关错误。正确做法是在取到一帧后立刻把需要的数据拷贝到自己的内存里拷贝完马上 ReleaseStream。释放之后原来的指针就不能再用了这一点要在代码审查时重点检查。我还遇到过一种变体代码里分开写了GetStream和ReleaseStream但是在ReleaseStream之前写了一堆耗时操作比如 H.264 数据解析、时间戳处理、加 debug 日志导致 buffer 被占用时间过长。这种不会立刻超时但高帧率下会越来越卡最后表现为偶发超时。正确的姿势是先拷贝先释放再做业务处理。2.5 推流网络发送堵塞反向拖垮取流线程很多人把 RTMP 推流代码写得非常“直给”取流线程拿到一帧马上调用 RTMP 发送函数发完再回来取下一帧。这个模式在局域网环境、网络良好的时候没什么问题但一旦网络波动或者流媒体服务器消费速度跟不上RTMP 发送函数就会在 socket 层阻塞。这一阻塞取流循环就没法及时执行下一次HI_MPI_VENC_GetStream。如果阻塞时间超过超时阈值日志就会打出 time out线程退出推流中断。要区分是不是这个原因可以看超时出现的时间点如果总是在推流一段时间之后出现并且网络不稳定时必现大概率就是发送阻塞。解决思路不是调大超时而是把“取流”和“发送”彻底拆开。取流线程只要负责把数据放进队列发送线程负责从队列里取数据发到网络上。队列一方面缓冲抖动另一方面避免网络反压直接影响取流线程。另外对 RTMP 的 socket 要设置发送超时不能让发送函数无限期阻塞。在嵌入式设备和弱网环境下这一步几乎是必须的。3. 5 分钟定位根因的排查路线3.1 第一步先确认线程是否还活着排除误报看到报错之后不要急着改参数。先确认程序现在的整体状态进程是不是还活着只是取流线程退了还是整个推流进程已经崩了如果进程还在只是线程退出说明退出点就是这个exit thr程序里其他逻辑还在跑。这时候要看上层有没有守护逻辑会重启这个线程。很多项目里线程退出了但没人管推流就静默中断连接状态还是“已连接”这种状态最容易迷惑人。如果进程也没了说明问题可能更严重。比如取流线程退出后主线程收到错误直接退出了进程。这时候就要去查错误传递的逻辑不要光盯 VENC 超时本身。3.2 第二步用最小编码任务验证 VENC 链路本身这是我最推荐的分解方法。写一个最小测试VENC 配置和项目完全一致但是把码流写到本地文件不经过任何网络发送。如果这个测试能稳定输出 H.264/H.265 裸流文件说明 VENC 本身没问题问题出在后续的 RTMP 组装、发送或线程逻辑上。如果连本地写文件都会超时那问题就锁定在 VENC 或它的上游。接下来再去查绑定关系、启动序列、通道配置范围小很多。这个方法虽然多花十分钟写测试代码但能一次性排除一半的怀疑对象。在项目里遇到这种“玄学报错”第一原则就是缩小范围而不是在原来的代码里四处加日志。3.3 第三步打开 MPP 日志看返回码和错误码MPP 平台提供了日志调试手段。把日志级别调高之后VENC、VPSS、SYS 模块的详细日志会输出到终端能直观看到哪一步出错。同时在自己代码里做一件几乎零成本的事每个 MPP 调用之后打印“函数名 返回值”。别小看这个习惯很多排查是靠着这些返回值日志把问题定位到具体调用的。不同返回码对应的含义并不相同。如果返回的是“VENC buffer empty”等表示队列没数据的错误码方向是上游没帧或者编码器没启动。如果返回的是“通道不存在、参数非法”这类错误说明通道属性配置有问题。如果返回值本身就是超时错误那就要重点看超时设置和线程调度。这里有一个经验错误码要结合时间上下文看。取流刚启动时返回空是正常的运行过程中持续返回空才是异常。每次取流都失败和每隔几十秒失败一次定位路线完全不同。3.4 第四步用“打桩”方式确认上下游帧号是否在涨有时候日志全开也找不到问题因为 MPP 日志只告诉你“拿不到流”没说“为什么拿不到流”。这时候我在 VPSS 取帧位置和 VENC 取流位置各加一个计数器把帧号和时间戳打出来并观察两边的增量。如果 VPSS 帧号在稳定递增VENC 却拿不到流那问题出在 VPSS 到 VENC 的绑定或 VENC 内部。如果 VPSS 本身也停住了就往上游查看 VI、sensor 出图是否正常。这种打桩方式的好处是能把“那一帧到底卡在哪个环节”这个问题从猜测变成事实。在嵌入式开发里很多 PDF 文档不会告诉你这种排查顺序但实际调板时最管用。4. 一份能稳定跑通的取流配置与代码4.1 可复用的 H.264 编码通道参数下面这套参数适用于 720P、25 帧的 H.264 编码起步配置。字段名在不同 SDK 版本里可能有细微差别以你实际使用的头文件为准但整体结构和字段含义是一致的。VENC_CHN_ATTR_S stVencAttr; memset(stVencAttr, 0, sizeof(stVencAttr)); stVencAttr.stVencAttr.enType PT_H264; stVencAttr.stVencAttr.uProfile 0; /* 用默认 profile */ stVencAttr.stVencAttr.uPicWidth 1280; stVencAttr.stVencAttr.uPicHeight 720; stVencAttr.stVencAttr.enPixelFormat PIXEL_FORMAT_YVU_SEMIPLANAR_420; stVencAttr.stVencAttr.s32FrameRate 25; stVencAttr.stVencAttr.s32Gop 50; /* 2 秒一个 I 帧 */ stVencAttr.stVencAttr.s32MaxPicWidth 1280; stVencAttr.stVencAttr.s32MaxPicHeight 720; stVencAttr.stVencAttr.s32BufSize 0; /* 0 表示模块自动分配 */ /* RC 参数先用 CBR 稳定码率跑通 */ stVencAttr.stRcAttr.enRcMode VENC_RC_MODE_H264_CBR; stVencAttr.stRcAttr.s32RcSize 600; /* 目标码率单位 Kbps */ HI_MPI_VENC_CreateChn(0, stVencAttr); /* 别忘了这一步启动接收帧 */ VENC_START_RECV_PARAM_S stStartParam; memset(stStartParam, 0, sizeof(stStartParam)); HI_MPI_VENC_StartRecvFrame(0, stStartParam);为什么推荐这样的起步配置25 帧是本地常见参数GOP 设成 50 意味着每 2 秒出一个 I 帧RTMP 推流时首帧和切换清晰度都比较友好。600 Kbps 的码率不算高但足够让 720P 画面在小码率场景下跑稳定。真正调优时再根据画面内容往上加码率。4.2 取流循环的正确写法获取、拷贝、释放、投递分离取流线程最忌讳的一件事就是在GetStream和ReleaseStream之间做耗时操作。看我常用的写法它把“获取”和“网络发送”彻底隔离了。while (g_bRunning) { VENC_STREAM_S stStream; memset(stStream, 0, sizeof(stStream)); /* 超时设 200ms既不会太久也不会让线程空转太凶 */ s32Ret HI_MPI_VENC_GetStream(0, stStream, 200); if (s32Ret ! HI_SUCCESS) { /* 先不做处理计数留作后续判断 */ g_stTimeOutCnt; continue; } /* 拿到码流后立刻拷贝到自己管理的 buffer 里 */ for (u32Idx 0; u32Idx stStream.u32PackCount; u32Idx) { memcpy(pu8OutBuf s32Offset, stStream.pstPack[u32Idx].pu8Addr, stStream.pstPack[u32Idx].u32Len); s32Offset stStream.pstPack[u32Idx].u32Len; } /* 拷贝完成马上释放返回缓冲给 VENC */ HI_MPI_VENC_ReleaseStream(0, stStream); /* 释放之后就可以安心做后续处理了交给推流线程、加时间戳、打印 debug 等 */ PushPacketToSendQueue(pu8OutBuf, s32Offset); }注意GetStream的超时值。设成-1永久阻塞只在调试时用正式代码里一旦上游异常整个线程会卡死连超时日志都打不出来。设成0又会让取流循环在没有数据时疯狂空转白白浪费 CPU。200 毫秒是我在大多数项目里试过的平衡点既能及时发现问题又不会影响响应速度。4.3 超时后的恢复策略降级重试而不是立刻退出官方 sample 的exit thr是一种最简处理但它不适合真实产品。在实际项目里我不建议因为一次超时就退出取流线程。更好的方式是维护一个连续超时计数器。当连续超时次数小于某个阈值比如 3 到 5 次只做计数和日志继续循环。如果连续超时超过阈值说明问题不是偶发抖动这时候再进入恢复流程先尝试重新调用HI_MPI_VENC_StartRecvFrame恢复接收如果还不行就重置 VENC 通道。整个过程里线程不要退出保持最外层的while循环一直运行。这个策略有一个额外的好处它能在弱网、断电重启、服务器断开等外部异常发生过后自动恢复推流而不是让设备死在那里等人来重启。嵌入式设备很多时候装在难以现场到达的地方这一点非常重要。5. 常见报错速查与实战避坑记录5.1 高频现象速查我把实际调试过程中遇到过的现象归纳成了一个速查表方便你对着现象直接找方向现象高频根因优先排查动作从第一次取流开始就必现超时没调StartRecvFrame或 VENC 启动失败检查启动序列和每个返回码运行一段时间后出现超时且越来越频繁只 GetStream 没 ReleaseStreamVB 池耗尽检查 ReleaseStream 调用覆盖率推流后网络一波动就出现超时RTMP 发送阻塞了取流线程把发送逻辑拆到独立线程正常跑偶发超时后线程退出超时设置太短或线程优先级不合理调大到 200ms 左右检查调度VPSS 端计数在涨VENC 取不到流绑定关系断裂或通道未使能检查 Bind 和 VPSS 通道属性修改分辨率后开始超时VENC 尺寸和输入尺寸不匹配核对输入图像尺寸和通道属性5.2 我踩过的几个隐蔽坑第一个坑是重复调用StartRecvFrame。调试阶段为了“确保启动”我在不同函数里调了两次第一遍成功第二遍返回错误。但错误日志被我忽略了因为程序没有崩溃只是取流超时。后来仔细读每个返回码才发现启动状态已经乱了。经验是MPP 调用链上任何一个返回值都要检查尤其是启动函数的返回值没有例外。第二个坑是永久阻塞超时的调试版本遗留问题。我在调试代码里把GetStream超时改成了-1想在线上环境里“再看看现象”结果上游一旦掉帧整个线程完全卡死连日志都不打印。最后是看门狗把系统重启了才发现问题。现在我的代码里绝对不允许出现-1作为正式超时参数调试完必须改回有限超时。第三个坑是本地调试时网线断开触发超时。当时 VENC 配置看起来完全正常本地编码也稳定但只要开始推流就超时。后来把取流和发送逻辑拆开才发现RTMP 发送函数在网线断开时阻塞了将近 3 秒直接把取流线程拖到超时。这个问题的教训是不要用“看起来逻辑正确”替代“结构上安全”取流和发送必须分开。5.3 日志和调试建议排查这类问题日志要分两层看。第一层是 MPP 平台自己的调试日志打开后能看到 VENC、VPSS、SYS 各模块内部的状态适合定位链路级问题。第二层是自己业务代码里的日志我建议在每个关键 MPP 调用点加一行带返回值的日志并且带上时间戳方便事后把日志和外部事件对应起来。生产环境的日志不要全量打印否则日志回写反而影响实时性可能造成新的卡顿。比较稳妥的做法是保留两类日志一类是初始化阶段每个调用的完整返回值另一类是运行阶段“连续超时计数变化”的摘要日志。这两类日志配合既能满足日常监控又不会拖垮系统性能。我在实际调试中总结出来的习惯是遇到这类 time out先看启动序列再看释放逻辑最后才动编码参数。网络发送永远放在独立线程。这套思路从来不只在单个板子上适用换到别的带 VENC 的芯片平台上排查顺序也基本一致。如果你也被同一行日志卡住建议从最小编码任务开始一步步排除别一上来就怀疑编码参数。
搞嵌入式视频开发的人第一次在 hi3516ev200 上跑 RTMP 推流的时候十个里有八个都见过这行日志SAMPLE_COMM_VENC_GetVencStreamProc-2024: get venc stream time out, exit thr。这句话看着像某个线程被强杀退出了实际上它只是视频处理平台上取编码码流的线程在规定时间内没有等到 VENC 模块送出任何一帧数据于是主动退出。这个报错不挑板子带 VENC 的芯片方案几乎都可能撞上。问题本身也不难卡住人的地方在于它可能由启动流程、绑定关系、编码配置、线程调度、网络反压等好几种原因触发而日志只有一行信息量太少。今天我把这类超时问题掰开揉碎讲清楚从根因到排查思路再到能稳定跑的配置和代码一次讲透。适合正在调视频通路、或者打算在嵌入式设备上做 H.264/H.265 RTMP 推流的开发者参考。1. 这个报错到底在说什么1.1 报错出现的代码位置与执行逻辑在官方参考代码的 venc 线程里SAMPLE_COMM_VENC_GetVencStreamProc是一个通用的取流函数它内部一般会循环调用HI_MPI_VENC_GetStream。这个调用的第三个参数是超时时间单位毫秒。设成-1表示一直等到有数据为止设成1000就是最多等 1 秒设成0就是完全非阻塞。当返回结果不是“成功”的时候参考代码会打印这行日志然后break跳出循环最后走到exit thr。所以日志里出现“exit thr”不代表整个进程崩溃更不代表 VENC 编码器本身死掉了。它只是取流线程放弃等待主动退出了而已。这里有一个容易误判的点很多人看到“time out”就以为把超时时间调大就行比如从 1000 改成 3000、改成 5000。但如果你没有搞清楚“为什么拿不到一帧”调大超时只是把问题出现的时间往后推。真正的数据链路问题不解决超时迟早还会出现而且调大了超时反而会让日志更晚暴露故障排查效率更低。1.2 超时表示的三类信号从现象往本质看HI_MPI_VENC_GetStream返回超时透露出三个信号第一个信号是 VENC 通道里没有可用的编码帧。这是最常见的情况。可能是上游 VPSS 没有往通道送图可能是编码器没有接收帧也可能是缓冲区被占满导致新帧进不来。第二个信号是取流线程本身被阻塞太久。比如线程优先级太低被其他高优先级任务抢占或者代码里某个锁没有释放导致线程在调用GetStream之前就已经卡了很久。这种情况日志也会表现为超时但问题根本不在 VENC而在线程调度和锁竞争。第三个信号是超时时间设置得太短没有覆盖启动阶段的首帧延时。系统刚上电、摄像头还没出图、编码器第一帧还在排队的时候如果超时设置只有几十毫秒很可能在启动阶段就误报。把这类“启动阶段误报”和“运行过程中的持续性超时”分开看是定位问题的第一步。2. 最容易让“get venc stream time out”出现的 5 个根因2.1 启动流程少了一步StartRecvFrame 没调用先说一个极其隐蔽但高频的原因VENC 通道创建成功之后还需要调用HI_MPI_VENC_StartRecvFrame编码器才会真正开始接收输入图像。这个调用像是给 VENC 发了一条“开始干活”的命令。很多人在官方 sample 基础上改代码的时候会习惯性地精简初始化流程。VENC 相关代码里常常只保留了HI_MPI_VENC_CreateChn然后就去创建线程调GetStream结果发现从第一次取流开始就超时。看初始化日志一切正常看通道属性也挑不出毛病唯独忘了这个启动命令。判断是否是这个原因有一个很简单的特征如果超时发生在第一次取流并且是“每次都必现”而不是偶发优先检查启动序列里有没有HI_MPI_VENC_StartRecvFrame以及它的返回值是不是成功。注意不能只检查是否调用了HI_MPI_VENC_StartRecvFrame还要检查它有没有返回错误。在实际项目里我就见过因为重复调用导致第二次返回错误但代码只处理了第一次返回值的情况结果问题被日志掩盖了。2.2 通道配置内部矛盾帧率、尺寸、码率和 GOP 互相打架VENC 通道属性看起来就是一堆结构体字段但字段之间是有约束关系的。最常见的几个坑如下帧率字段设置成 0 或者设置得比实际输入帧率低编码器会产生节奏不一致。输入帧率 25 而通道配置成 12编码器每两帧才处理一帧取流侧需要等更长时间如果上游送帧模式又是按需发送通道可能一直不输出。尺寸字段必须和输入图像尺寸匹配。比如 VPSS 送给 VENC 的分辨率是 720x1280而通道配置成 1280x720部分 SDK 版本下 VENC 无法编码队列一直为空。旋转、缩放应该在 VPSS 端做完VENC 只负责编码尺寸不匹配这种低级错误最容易让人绕远路。码率控制参数也要合理。CBR 模式下目标码率如果设得太小编码器会为了保证码率而提高量化参数甚至在某些异常参数组合下进入不输出帧的状态。GOP 设置过大会让两个 I 帧之间间隔很长但正常情况不会导致 GetStream 超时只是拉流首帧画面出现慢。我的建议是先照搬官方 sample 里同分辨率同编码格式的参数组合跑通之后再一步一步改。不要一开始就追求“最优参数”先把链路打通再来折腾画质和码率。2.3 上游绑定关系断掉VPSS 到 VENC 的数据流没建立在典型的视频处理流程里数据走向是 VI - VPSS - VENC。VPSS 的输出通道通过HI_MPI_SYS_Bind和 VENC 的通道绑定绑定之后数据才会自动从 VPSS 流入 VENC。这个环节出现问题的特征是VENC 通道创建成功启动成功但一直没有数据进来。常见原因如下第一只绑定了 VPSS 到 VENC却没有执行HI_MPI_SYS_EnableBind或对应的使能操作绑定名存实亡。第二VPSS 本身没有正常工作。VPSS 组的时钟、工作模式、通道属性如果配置不对或者 VI 端没有在出图VPSS 就没有帧可送。VENC 上游没数据取流线程等到天荒地老也等不到一帧。第三重复执行了 unbind 操作。调试过程中有人喜欢每次初始化都先HI_MPI_SYS_Unbind再Bind如果 unbind 执行了两次而 bind 只执行了一次链路就被自己弄断了。遇到这类问题单看 VENC 日志是不够的。我建议在 VPSS 通道的取帧回调里打一个计数器或者在调试工具里观察 VPSS 通道统计确认 VPSS 是不是真的在出帧。把上下游分开验证很快就能定位断点。2.4 取流后忘了 ReleaseStreamVB 缓存池被自己耗干这个原因特别容易发生在从单线程 sample 改成多线程项目时。HI_MPI_VENC_GetStream拿到的是内部缓冲区的指针。每取走一帧对应的 buffer 就处于“被借用”状态必须调用HI_MPI_VENC_ReleaseStream把 buffer 还给 VENC 模块VENC 才能继续使用这块内存存下一帧编码数据。如果你只 GetStream 不 ReleaseStream一开始可能还能拿到几帧但随着 buffer 池被消耗完编码器没有空闲 buffer 存放新编码帧后续GetStream就会一直超时或者返回 buffer 相关错误。正确做法是在取到一帧后立刻把需要的数据拷贝到自己的内存里拷贝完马上 ReleaseStream。释放之后原来的指针就不能再用了这一点要在代码审查时重点检查。我还遇到过一种变体代码里分开写了GetStream和ReleaseStream但是在ReleaseStream之前写了一堆耗时操作比如 H.264 数据解析、时间戳处理、加 debug 日志导致 buffer 被占用时间过长。这种不会立刻超时但高帧率下会越来越卡最后表现为偶发超时。正确的姿势是先拷贝先释放再做业务处理。2.5 推流网络发送堵塞反向拖垮取流线程很多人把 RTMP 推流代码写得非常“直给”取流线程拿到一帧马上调用 RTMP 发送函数发完再回来取下一帧。这个模式在局域网环境、网络良好的时候没什么问题但一旦网络波动或者流媒体服务器消费速度跟不上RTMP 发送函数就会在 socket 层阻塞。这一阻塞取流循环就没法及时执行下一次HI_MPI_VENC_GetStream。如果阻塞时间超过超时阈值日志就会打出 time out线程退出推流中断。要区分是不是这个原因可以看超时出现的时间点如果总是在推流一段时间之后出现并且网络不稳定时必现大概率就是发送阻塞。解决思路不是调大超时而是把“取流”和“发送”彻底拆开。取流线程只要负责把数据放进队列发送线程负责从队列里取数据发到网络上。队列一方面缓冲抖动另一方面避免网络反压直接影响取流线程。另外对 RTMP 的 socket 要设置发送超时不能让发送函数无限期阻塞。在嵌入式设备和弱网环境下这一步几乎是必须的。3. 5 分钟定位根因的排查路线3.1 第一步先确认线程是否还活着排除误报看到报错之后不要急着改参数。先确认程序现在的整体状态进程是不是还活着只是取流线程退了还是整个推流进程已经崩了如果进程还在只是线程退出说明退出点就是这个exit thr程序里其他逻辑还在跑。这时候要看上层有没有守护逻辑会重启这个线程。很多项目里线程退出了但没人管推流就静默中断连接状态还是“已连接”这种状态最容易迷惑人。如果进程也没了说明问题可能更严重。比如取流线程退出后主线程收到错误直接退出了进程。这时候就要去查错误传递的逻辑不要光盯 VENC 超时本身。3.2 第二步用最小编码任务验证 VENC 链路本身这是我最推荐的分解方法。写一个最小测试VENC 配置和项目完全一致但是把码流写到本地文件不经过任何网络发送。如果这个测试能稳定输出 H.264/H.265 裸流文件说明 VENC 本身没问题问题出在后续的 RTMP 组装、发送或线程逻辑上。如果连本地写文件都会超时那问题就锁定在 VENC 或它的上游。接下来再去查绑定关系、启动序列、通道配置范围小很多。这个方法虽然多花十分钟写测试代码但能一次性排除一半的怀疑对象。在项目里遇到这种“玄学报错”第一原则就是缩小范围而不是在原来的代码里四处加日志。3.3 第三步打开 MPP 日志看返回码和错误码MPP 平台提供了日志调试手段。把日志级别调高之后VENC、VPSS、SYS 模块的详细日志会输出到终端能直观看到哪一步出错。同时在自己代码里做一件几乎零成本的事每个 MPP 调用之后打印“函数名 返回值”。别小看这个习惯很多排查是靠着这些返回值日志把问题定位到具体调用的。不同返回码对应的含义并不相同。如果返回的是“VENC buffer empty”等表示队列没数据的错误码方向是上游没帧或者编码器没启动。如果返回的是“通道不存在、参数非法”这类错误说明通道属性配置有问题。如果返回值本身就是超时错误那就要重点看超时设置和线程调度。这里有一个经验错误码要结合时间上下文看。取流刚启动时返回空是正常的运行过程中持续返回空才是异常。每次取流都失败和每隔几十秒失败一次定位路线完全不同。3.4 第四步用“打桩”方式确认上下游帧号是否在涨有时候日志全开也找不到问题因为 MPP 日志只告诉你“拿不到流”没说“为什么拿不到流”。这时候我在 VPSS 取帧位置和 VENC 取流位置各加一个计数器把帧号和时间戳打出来并观察两边的增量。如果 VPSS 帧号在稳定递增VENC 却拿不到流那问题出在 VPSS 到 VENC 的绑定或 VENC 内部。如果 VPSS 本身也停住了就往上游查看 VI、sensor 出图是否正常。这种打桩方式的好处是能把“那一帧到底卡在哪个环节”这个问题从猜测变成事实。在嵌入式开发里很多 PDF 文档不会告诉你这种排查顺序但实际调板时最管用。4. 一份能稳定跑通的取流配置与代码4.1 可复用的 H.264 编码通道参数下面这套参数适用于 720P、25 帧的 H.264 编码起步配置。字段名在不同 SDK 版本里可能有细微差别以你实际使用的头文件为准但整体结构和字段含义是一致的。VENC_CHN_ATTR_S stVencAttr; memset(stVencAttr, 0, sizeof(stVencAttr)); stVencAttr.stVencAttr.enType PT_H264; stVencAttr.stVencAttr.uProfile 0; /* 用默认 profile */ stVencAttr.stVencAttr.uPicWidth 1280; stVencAttr.stVencAttr.uPicHeight 720; stVencAttr.stVencAttr.enPixelFormat PIXEL_FORMAT_YVU_SEMIPLANAR_420; stVencAttr.stVencAttr.s32FrameRate 25; stVencAttr.stVencAttr.s32Gop 50; /* 2 秒一个 I 帧 */ stVencAttr.stVencAttr.s32MaxPicWidth 1280; stVencAttr.stVencAttr.s32MaxPicHeight 720; stVencAttr.stVencAttr.s32BufSize 0; /* 0 表示模块自动分配 */ /* RC 参数先用 CBR 稳定码率跑通 */ stVencAttr.stRcAttr.enRcMode VENC_RC_MODE_H264_CBR; stVencAttr.stRcAttr.s32RcSize 600; /* 目标码率单位 Kbps */ HI_MPI_VENC_CreateChn(0, stVencAttr); /* 别忘了这一步启动接收帧 */ VENC_START_RECV_PARAM_S stStartParam; memset(stStartParam, 0, sizeof(stStartParam)); HI_MPI_VENC_StartRecvFrame(0, stStartParam);为什么推荐这样的起步配置25 帧是本地常见参数GOP 设成 50 意味着每 2 秒出一个 I 帧RTMP 推流时首帧和切换清晰度都比较友好。600 Kbps 的码率不算高但足够让 720P 画面在小码率场景下跑稳定。真正调优时再根据画面内容往上加码率。4.2 取流循环的正确写法获取、拷贝、释放、投递分离取流线程最忌讳的一件事就是在GetStream和ReleaseStream之间做耗时操作。看我常用的写法它把“获取”和“网络发送”彻底隔离了。while (g_bRunning) { VENC_STREAM_S stStream; memset(stStream, 0, sizeof(stStream)); /* 超时设 200ms既不会太久也不会让线程空转太凶 */ s32Ret HI_MPI_VENC_GetStream(0, stStream, 200); if (s32Ret ! HI_SUCCESS) { /* 先不做处理计数留作后续判断 */ g_stTimeOutCnt; continue; } /* 拿到码流后立刻拷贝到自己管理的 buffer 里 */ for (u32Idx 0; u32Idx stStream.u32PackCount; u32Idx) { memcpy(pu8OutBuf s32Offset, stStream.pstPack[u32Idx].pu8Addr, stStream.pstPack[u32Idx].u32Len); s32Offset stStream.pstPack[u32Idx].u32Len; } /* 拷贝完成马上释放返回缓冲给 VENC */ HI_MPI_VENC_ReleaseStream(0, stStream); /* 释放之后就可以安心做后续处理了交给推流线程、加时间戳、打印 debug 等 */ PushPacketToSendQueue(pu8OutBuf, s32Offset); }注意GetStream的超时值。设成-1永久阻塞只在调试时用正式代码里一旦上游异常整个线程会卡死连超时日志都打不出来。设成0又会让取流循环在没有数据时疯狂空转白白浪费 CPU。200 毫秒是我在大多数项目里试过的平衡点既能及时发现问题又不会影响响应速度。4.3 超时后的恢复策略降级重试而不是立刻退出官方 sample 的exit thr是一种最简处理但它不适合真实产品。在实际项目里我不建议因为一次超时就退出取流线程。更好的方式是维护一个连续超时计数器。当连续超时次数小于某个阈值比如 3 到 5 次只做计数和日志继续循环。如果连续超时超过阈值说明问题不是偶发抖动这时候再进入恢复流程先尝试重新调用HI_MPI_VENC_StartRecvFrame恢复接收如果还不行就重置 VENC 通道。整个过程里线程不要退出保持最外层的while循环一直运行。这个策略有一个额外的好处它能在弱网、断电重启、服务器断开等外部异常发生过后自动恢复推流而不是让设备死在那里等人来重启。嵌入式设备很多时候装在难以现场到达的地方这一点非常重要。5. 常见报错速查与实战避坑记录5.1 高频现象速查我把实际调试过程中遇到过的现象归纳成了一个速查表方便你对着现象直接找方向现象高频根因优先排查动作从第一次取流开始就必现超时没调StartRecvFrame或 VENC 启动失败检查启动序列和每个返回码运行一段时间后出现超时且越来越频繁只 GetStream 没 ReleaseStreamVB 池耗尽检查 ReleaseStream 调用覆盖率推流后网络一波动就出现超时RTMP 发送阻塞了取流线程把发送逻辑拆到独立线程正常跑偶发超时后线程退出超时设置太短或线程优先级不合理调大到 200ms 左右检查调度VPSS 端计数在涨VENC 取不到流绑定关系断裂或通道未使能检查 Bind 和 VPSS 通道属性修改分辨率后开始超时VENC 尺寸和输入尺寸不匹配核对输入图像尺寸和通道属性5.2 我踩过的几个隐蔽坑第一个坑是重复调用StartRecvFrame。调试阶段为了“确保启动”我在不同函数里调了两次第一遍成功第二遍返回错误。但错误日志被我忽略了因为程序没有崩溃只是取流超时。后来仔细读每个返回码才发现启动状态已经乱了。经验是MPP 调用链上任何一个返回值都要检查尤其是启动函数的返回值没有例外。第二个坑是永久阻塞超时的调试版本遗留问题。我在调试代码里把GetStream超时改成了-1想在线上环境里“再看看现象”结果上游一旦掉帧整个线程完全卡死连日志都不打印。最后是看门狗把系统重启了才发现问题。现在我的代码里绝对不允许出现-1作为正式超时参数调试完必须改回有限超时。第三个坑是本地调试时网线断开触发超时。当时 VENC 配置看起来完全正常本地编码也稳定但只要开始推流就超时。后来把取流和发送逻辑拆开才发现RTMP 发送函数在网线断开时阻塞了将近 3 秒直接把取流线程拖到超时。这个问题的教训是不要用“看起来逻辑正确”替代“结构上安全”取流和发送必须分开。5.3 日志和调试建议排查这类问题日志要分两层看。第一层是 MPP 平台自己的调试日志打开后能看到 VENC、VPSS、SYS 各模块内部的状态适合定位链路级问题。第二层是自己业务代码里的日志我建议在每个关键 MPP 调用点加一行带返回值的日志并且带上时间戳方便事后把日志和外部事件对应起来。生产环境的日志不要全量打印否则日志回写反而影响实时性可能造成新的卡顿。比较稳妥的做法是保留两类日志一类是初始化阶段每个调用的完整返回值另一类是运行阶段“连续超时计数变化”的摘要日志。这两类日志配合既能满足日常监控又不会拖垮系统性能。我在实际调试中总结出来的习惯是遇到这类 time out先看启动序列再看释放逻辑最后才动编码参数。网络发送永远放在独立线程。这套思路从来不只在单个板子上适用换到别的带 VENC 的芯片平台上排查顺序也基本一致。如果你也被同一行日志卡住建议从最小编码任务开始一步步排除别一上来就怀疑编码参数。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
