rkmedia一个头两个流, 即同一个vi通道, 接两个不同的下游通道,比如rga

标题不好起啊...
最早我有个迷思, 觉得, 每个vi的通道, 只能对应一个下游通道, 可能是被这个图误导了:

起源是当我拿vdec当作输入的时候, 发现是不是并没有必要每个进来的包, 都在两个vdec通道做两次解码, 那不是有点傻么, 后来我在做rtsp+rknn的时候, 发现另一个问题, 如果把一个节点, 比如rkispp_scanle0, 跟rkispp_scale1, 都做1920x1080输入, 直接就会报错, 原因如下图

原因是rkisp_scale1支持不了1080p, 这样便催生了这个问题, 有没有办法, 用一个头, 接后面两路输出.

应用场景如下:
一路vi进rga, 转为合适的尺寸之后, 做rknn推理, 把结果放入rknn队列.
另一路vi, 通过getMediaBuffer, 拿到vi本身的画面, 再拿来给rknn的推理结果, 画框, 画完放入rtsp当作监视器使用

相信很多人都做过这个尝试, 这里面有个问题:

当你分别使用节点比如rkispp_scanle0, 比如rkispp_scanle1的时候, 如果都使用1080p输入, 就会报错, 当你把rkispp_scanle1降为720p, rkispp_scanle0保持1080p的时候, 你画出来的框子会比rknn+yolo的预测框小, 因为它是基于720p的分辨率做的推理, 放到1080的rtsp中显示, 框子就小了, 当然你也可以手动放大.

另外一个做法是把 rkispp_scanle0也将为720p, 这样框子正确了, 但是rtsp的推出来的视频分辨率低了(当然也不是太大的问题).

另外一个应用场景, 是如果我用海思3516推流过来, 使用vdec解码之后, 做推理啊, 再rtsp推流啊, 听起来有点傻x对吧, 但是我确实想试试1126如果不从vi拉流, 会不会还那么热, 这种情况下, 难道我需要把udp拿过来的数据, 分别放在两个vdec的通道中, 解码两次??

问了友商的客服, 人家很肯定的告诉我, vi的一个通道, 可以同时绑定到下游的比如rga两个不同通道上去.

参考这个博客:
https://blog.csdn.net/baoecit/article/details/124867651

我的代码:
https://github.com/MontaukLaw/one_vi_2_rga_test

嗯, 这样就合理很多了...