Toybrick

标题: rockchip-mpp 1.4.0 解码图像出现绿条 [打印本页]

作者: seanx 时间: 2021-1-20 17:10
标题: rockchip-mpp 1.4.0 解码图像出现绿条
你好，我这边使用 Wiki教程中的 MppDecoderCreate 方式调用 MPP 解码图像，然后用 RGA 缩放。本来一直相安无事，但是今天我用 apt upgrade（Debian，3399ProD）一下，然后 rockchip-mpp 这个包由 1.3.8-8 更新到了 1.4.0-1，结果就发现之前正常运行的程序，在解码 1080P H265 图像之后得到的图像在最下面出现了一个大概 16 像素高的绿条。

关于填充的问题，RGA 的配置应该是 OK 的，因为更新前都试过多种分辨率的输入都没有问题。

我把更新的依赖都对比了一下，发现就是 librockchip_mpp.so.0 这个文件造成的，当我把这个文件换回 1.3.8-8 版本的话，就不会有绿条，换成 1.4.0-1 绿条就出现了。

看 rockchip-mpp 这个包的更新日志里面只说了“* Merge from rk develop branch, commit 3f5b640345c505c2ee5bf11d30a87218f967339e”，并没有什么有效信息。

请教一下论坛大佬，是否这个更新对解码数据进行了什么变动吗？

作者: jefferyzhang 时间: 2021-1-20 18:16
跟改动无关，应该是你自己没去获取265出来的act width。
硬件出来的buffer是有对齐的问题的，需要用rga裁剪。
你以前代码能用只是运气好而已。

作者: seanx 时间: 2021-1-21 10:42

jefferyzhang 发表于 2021-1-20 18:16
跟改动无关，应该是你自己没去获取265出来的act width。
硬件出来的buffer是有对齐的问题的，需要用rga裁剪 ...

我这边确定 RGA 配置好的， src crop 按照 DecFrame 的 width 和 height 配置了，输入也是按 coded_width 和 coded_height 告知的实际尺寸配置的，并且打印出来核查过填充问题，之前版本也不存在所谓“运气好”的问题。

作者: seanx 时间: 2021-1-21 10:55

jefferyzhang 发表于 2021-1-20 18:16
跟改动无关，应该是你自己没去获取265出来的act width。
硬件出来的buffer是有对齐的问题的，需要用rga裁剪 ...

事实上这个问题是 rockchip-mpp 的填充规则发生了变化，1080P H265 在此前版本填充到了 2304x1088，而新版填充到 2304x1080，高度方向不为 16 的整数倍，RGA ops 就绿了。

而这个我们用户层似乎没有什么好办法，总不能说把 MPP 出来的帧再去做二次填充再送给 RGA 吧

作者: jefferyzhang 时间: 2021-1-21 11:11
这个就是你代码没有根据mpp输出的实际宽高进行裁剪造成的。不管是1080还是1088这些都是mpp解码后会输出的参数。
你之前能用只是因为刚好你心里的期望值和mpp输出值相同罢了

作者: zhuo799154051 时间: 2021-1-22 11:05
老哥你回退版本怎么退的，我用apt回退没成功

作者: seanx 时间: 2021-1-25 14:08

zhuo799154051 发表于 2021-1-22 11:05
老哥你回退版本怎么退的，我用apt回退没成功

我这边留了更新之前的 so 文件，所以直接替换下来就可以，也没有去回退。

作者: seanx 时间: 2021-1-25 14:11

jefferyzhang 发表于 2021-1-21 11:11
这个就是你代码没有根据mpp输出的实际宽高进行裁剪造成的。不管是1080还是1088这些都是mpp解码后会输出的参 ...

我这边确实是直接默认 RK 的 MPP 模块输出的数据是能够直接满足 RGA 模块输入要求的。

而且我认为这种“默认”也是合理的，都是你们一家的板子上的不同模块，如果都没法很好的串联协同工作，还需要用户再 CPU 搬一遍，那真的只能说一言难尽。。。

作者: 15992605143 时间: 2021-4-9 01:03
@jefferyzhang，MPP出来的帧，假如是1920*1080，我们应该如何处理后送入rga才能满足rga的16对齐要求？

欢迎光临 Toybrick (https://t.rock-chips.com/)