MPP 解码填充异常

[复制链接] · 发表于 2020-9-1 18:22:57

参考 Wiki 使用 rockchip_mpp 进行视频流解码时发现，解码图像 DecFrame ：

1080P/h264 => 填充到 1920x1088
1080P/h265 => 填充到 2304x1088
720P/h264 => 无填充
720P/h265 => 无填充

我在两台海康摄像机测试过均是这种填充模式。

各种系统库什么的都是今天检查过更新，板子是 RK3399ProD，最新的 Debian 10 系统。

请问：

1）为什么 h265 编码会在宽度方向上填充 384 像素之多（1920 本身就是 16 对齐，不需要填充才对）？
2）宽度方向有填充的情况下，如果我要用 RGA 将图像转换成 BGR 格式要如何操作？我看 RGA 接口中并没有类似 stride 这样的参数，是否这种我只能分两步，先做 crop 再做色彩转换？

谢谢各位大佬了

只看该作者 · 发表于 2020-9-2 09:00:07

1. H265是 256bit对齐的
2. rga参数有实宽和虚宽，填上就可以抠出来

只看该作者 · 发表于 2020-9-2 11:12:55

jefferyzhang 发表于 2020-9-2 09:00
1. H265是 256bit对齐的
2. rga参数有实宽和虚宽，填上就可以抠出来

这不对吧，256bit 也就是 32 字节，1920 本来就是 32 对齐的，怎么着也不至于填充 384 字节之多呀。
rockchip_rga 的库中没有找到虚宽，似乎只能用 crop 实现，这里 rga 是指底层接口？

只看该作者 · 发表于 2020-9-2 11:25:41

seanx 发表于 2020-9-2 11:12
这不对吧，256bit 也就是 32 字节，1920 本来就是 32 对齐的，怎么着也不至于填充 384 字节之多呀。
rock ...

1. 264是16对齐，265是256奇数对齐
2. 我说的虚宽就是Rockchip_rga的crop方法，给你们都封装好了已经

只看该作者 · 发表于 2020-9-2 11:36:56

seanx 发表于 2020-9-2 11:12
这不对吧，256bit 也就是 32 字节，1920 本来就是 32 对齐的，怎么着也不至于填充 384 字节之多呀。
rock ...

明白了，多谢版主。
总结下来应该是：h264 宽高方向均是 16 对齐；h265 宽度方向 256 奇数对齐，高度方向 16 对齐。
crop 方法试验有效，代码层面不需要关心具体是 16 还是 256，直接 coded_width 和 coded_height 就可以了。