search

rockchip-linux / mpp

Media Process Platform (MPP) module
472 stars 157 forks source link

3588/3588s 使用图片进行编码直播推流，观看段的呈现图颜色不正确 #457

Closed Danjuanlab closed 5 months ago

Danjuanlab commented 9 months ago

测试开发板：radax rock5b（soc3588）、香橙派pi5（3588s）。两块开发板的RKSDK均为12版本

其他相关设备：sony A7M4微单相机、sony zve10微单相机、台式电脑、elgato camlink 4K采集卡、ezcap camlink 4k采集卡、blackmagic 12G调色盒子。Larix直播软件

直播测试平台：bilibili、抖音

测试流程： 1.在直播的环境中，将相机信号通过采集卡接入电脑OBS Studio软件，并截屏画面作为原始素材【A】。 1436c6d2e0d5f4567fe41707dac8337

2.将相机信号接入电脑端抖音直播伴侣，并直播。然后使用苹果12手机观看直播并截图颜色。 3.将相机信号接入rock 5b开发板，并直接在开发板上打开抖音app，然后抖音app直接调用HDMI IN的信号进行直播。注意，此处直播清晰度已设置成最高清蓝光且关闭美颜和滤镜等对画面有影响的设置。随后用苹果12手机观看直播并截图。 4.将相机信号通过UVC采集卡接入rock 5b开发板，并如上进行直播测试和截图。 5.将相机信号通过UVC采集卡接入香橙派pi5开发板并进行如上的直播测试和截图。

第一轮测试结果对比： 8d3679bcf7c5c3a86aa2b858321b33e c3b17cd8a65e13e93d8020a7453fcba

1.电脑端直播的画面，在手机上呈现的颜色与原始素材【A】高度吻合。 2.相机信号不论接HDMI IN还是接两款UVC采集卡直播，在两个品牌的开发板上直播出去的结果都非常近似，且都明显偏离原始素材【A】的颜色。 3.通过观察2这个现象，我们猜测是色彩空间的解码出现了问题，相机信号都是BT709的规格进行编码，而开发板上都是以BT601的标准进行解码。

————————————————————————————————————————————————————

为了验证第一轮观察的猜想，后续做了如下的测试： 1.我们在达芬奇中制作了一个33point精度的BT709转BT601的颜色转换3D LUT文件，并将这个文件写入blackmagic 12G调色盒子。 2.先将相机的HDMI OUT信号接入1步骤中的调色盒子，然后将调色后的画面再次通过HDMI IN以及uvc采集卡输入开发板进行直播测试和截图。

经过对比后，我们发现开发板直播的颜色已经比较接近原始素材【A】的颜色，但是在一些高饱和度的颜色上与原素材不同，这是因为601的色彩空间小于709的色彩空间。所以当做了下变换后，饱和度高的颜色会被压缩，故颜色不同。所以这一步测试基本说明我们的猜想是正确的。下一步我们将测试这个颜色的转换问题出现在哪个层级的代码中。

————————————————————————————————————————————————————

第三轮测试流程： 1.我们将原始素材【A】这张图片原图通过usb拷贝到两张开发板卡中，并将他加载到Larix直播软件的overlay系统中作为直播的图片，此时图片完全覆盖下方的camera层。 2.通过快速的开关overlay的原图，我们对比原图和hdmi in的实时相机信号，在开发板上观察的颜色和原图无明显区别。 3.将overlay打开，并将bilibili和抖音的rtmp地址输入Larix进行直播测试，并手机截图。 4.此时观察到手机截图的颜色与第一次开发板直播测试时的颜色区别很小，直接三方直播的呈现画面颜色也是错误的。 5.随后我们使用相同的测试步骤，在小米12手机上（MIUI 14）使用larix进行图片直播。经过对比手发现，手机观看截图颜色是正确的，与原始素材【A】高度一致。

测试结果与推论： 经过第三轮测试，出问题的代码不在camera HAL层，应该为更下层的代码中。

————————————————————————————————————————————————————

第四轮测试： 1.给香橙派5刷了官方的ubuntu系统，并使用ffmpeg和obs直接以原始素材【A】图片推流到Bilibili，手机观看直播效果截图。 2.经过对比发现，在linux下推流的直播效果和安卓的直播效果是相同的。与元素素材A都有较大的差别。 11700c1d6e865827c4ea3bcf6ba1328 c5699a45f0144706bac61e6c7caa2a4

推测：

这个颜色的问题不在系统层面，而应该是内核或者mpp部分。

以上的测试和推测以让香橙派公司员工协助发给rk工程师，但是一个多月都没有任何回复，故发到github上希望RK进行debug，并解决这个问题。

HermanChen commented 9 months ago

最好提供下码流，编码器本身对数据处理过程都只是压缩，看看解码之后的 YUV 数据是否有很大变化 如果有比较大的变化，说明是编码前的格式转换出现问题，如果没有大的变化，说明是颜色空间标记的问题

Danjuanlab commented 9 months ago

最好提供下码流，编码器本身对数据处理过程都只是压缩，看看解码之后的 YUV 数据是否有很大变化 如果有比较大的变化，说明是编码前的格式转换出现问题，如果没有大的变化，说明是颜色空间标记的问题

如何提供码流？从整个测试来看，就是色彩空间上的问题（因为在测试2中，通过制作反转色彩空间的lut后，最终观看端显示色彩是非常接近正确颜色。），只是这个标定的问题点并不在系统层级，而在底层，作为消费者无法自己解决debug

nyanmisaka commented 9 months ago

假设rk3588的HDMI IN和外置采集卡全部输入BT.709的BGR24/BGR888源，如果你不在MPP编码器中指定输入源图像色彩空间为BT.709的话，它会默认使用BT.601，造成RGB2YUV转换矩阵和实际不匹配，编出来的图像颜色就有偏差。

https://github.com/rockchip-linux/mpp/blob/d127b5c78b96beb57baca76758834e12d17dfe7c/mpp/hal/rkenc/common/vepu5xx_common.h#L42-L47

https://github.com/rockchip-linux/mpp/blob/d127b5c78b96beb57baca76758834e12d17dfe7c/mpp/hal/rkenc/common/vepu5xx_common.c#L58-L80

https://github.com/rockchip-linux/mpp/blob/d127b5c78b96beb57baca76758834e12d17dfe7c/osal/mpp_soc.cpp#L841-L854

android下编码软件我不清楚，抖音估计走的mediacodec，最后还是到mpp。linux下你ffmpeg大概率使用的是社区的版本，里面还没有对编码器设定色彩空间，obs肯定也使用它的libavcodec。有能力就自己改改代码吧。

Danjuanlab commented 9 months ago

假设rk3588的HDMI IN和外置采集卡全部输入BT.709的BGR24/BGR888源，如果你不在MPP编码器中指定输入源图像色彩空间为BT.709的话，它会默认使用BT.601，造成RGB2YUV转换矩阵和实际不匹配，编出来的图像颜色就有偏差。

https://github.com/rockchip-linux/mpp/blob/d127b5c78b96beb57baca76758834e12d17dfe7c/mpp/hal/rkenc/common/vepu5xx_common.h#L42-L47

https://github.com/rockchip-linux/mpp/blob/d127b5c78b96beb57baca76758834e12d17dfe7c/mpp/hal/rkenc/common/vepu5xx_common.c#L58-L80

https://github.com/rockchip-linux/mpp/blob/d127b5c78b96beb57baca76758834e12d17dfe7c/osal/mpp_soc.cpp#L841-L854

android下编码软件我不清楚，抖音估计走的mediacodec，最后还是到mpp。linux下你ffmpeg大概率使用的是社区的版本，里面还没有对编码器设定色彩空间，obs肯定也使用它的libavcodec。有能力就自己改改代码吧。

感谢你的帮助和分析，经过你的提示，我下午使用香橙派5在官方ubuntu下使用obs studio+图片推流到B站，编码颜色709。不论x264还是rockchip mpp硬编，最终推流到B站得到的颜色与原图完全吻合！

由此可论证你的推测，在安卓一些列直播软件中没有对编码颜色做传递时，mpp会用默认的601色彩空间进行颜色转换，导致最终推流结果错误，包括我之前使用ffmpeg社区版的方案也是。问题的病灶终于是找到了！！！！！

那么问题来了，自己如何修改这段代码能给点提示吗~谢谢

Danjuanlab commented 9 months ago

会改了，这个就改个index就行了@nyanmisaka

eznode commented 6 months ago

mark

Danjuanlab commented 6 months ago

@HermanChen 我请香橙派的员工帮我编译了一版更改mpp index的so文件，我拿到这个so文件放入安卓系统中，重新为香橙派3588 编译安卓12系统，但是在新系统中，这个推流的颜色依旧是错的。是否可以重新打开这个issue

Danjuanlab commented 5 months ago

最好提供下码流，编码器本身对数据处理过程都只是压缩，看看解码之后的 YUV 数据是否有很大变化 如果有比较大的变化，说明是编码前的格式转换出现问题，如果没有大的变化，说明是颜色空间标记的问题

请问在安卓或者ubuntu下如何去获取到您说的码流数据，然后进行进一步的debug呢？

HermanChen commented 5 months ago

了解下编码器使用的输入输出流程，在对应的代码流程里存文件

Danjuanlab commented 5 months ago

了解下编码器使用的输入输出流程，在对应的代码流程里存文件

就是我上述流程走下来，录制一个本地的视频文件，从这个源文件解析对吗？

HermanChen commented 5 months ago

可以的