MPP 解码填充异常

参考 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 再做色彩转换？

谢谢各位大佬了

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

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

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

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

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

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

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