nyanmisaka
commented
3 months ago Reproduced. It caused artifacts but did not crash the kernel on my end.
Closed 9426224 closed 3 months ago
nyanmisaka
commented
3 months ago Reproduced. It caused artifacts but did not crash the kernel on my end.
Liaoyyyy
commented
3 months ago 你好，关于这个问题，本地在mpi_enc_test中未能复现成功，这边请提供些基本信息：
nyanmisaka
commented
3 months ago 你好，关于这个问题，本地在mpi_enc_test中未能复现成功，这边请提供些基本信息：
- 编码类型，264 ？ 265 ? 其他？
- 当前mpp版本： android: strings libmpp.so | grep author linux: strings librockchip_mpp.so.0 | grep author
- 内核版本以及驱动版本 cat /proc/version cat /proc/mpp_service/version
It seems that YUV420P(fully-planar 420) requires different pitch alignment compared to NV12, but I didn't find documentation.
You should be able to reproduce this in my ffmpeg fork with the following command. And here's the Wiki about how to compile.
# encode yuv420p to h264, output is /tmp/broken.h264
./ffmpeg -f lavfi -i testsrc=s=2592x1944,format=yuv420p -c:v h264_rkmpp -b:v 4M -maxrate 4M -g:v 120 -vframes 1000 -y /tmp/broken.h264
# encode nv12 to h264, output is /tmp/fine.h264
./ffmpeg -f lavfi -i testsrc=s=2592x1944,format=nv12 -c:v h264_rkmpp -b:v 4M -maxrate 4M -g:v 120 -vframes 1000 -y /tmp/fine.h264
# encode yuv420p to h265, output is /tmp/broken.hevc
./ffmpeg -f lavfi -i testsrc=s=2592x1944,format=yuv420p -c:v hevc_rkmpp -b:v 4M -maxrate 4M -g:v 120 -vframes 1000 -y /tmp/broken.hevc
# encode nv12 to h265, output is /tmp/fine.hevc
./ffmpeg -f lavfi -i testsrc=s=2592x1944,format=nv12 -c:v hevc_rkmpp -b:v 4M -maxrate 4M -g:v 120 -vframes 1000 -y /tmp/fine.hevcPlease try testing with mpp_enc_test obtained after compiling the project locally.，confirm whether it's caused by external configuration. For example: mpi_enc_test -w 2592 -h 1944 -t 7 -n 1000 -bps 4000000 -g 1:120:1 -f 4 -i /sdcard/data.yuv -o /sdcard/data.264
nyanmisaka
commented
3 months ago Please try testing with mpp_enc_test obtained after compiling the project locally.，confirm whether it's caused by external configuration. For example: mpi_enc_test -w 2592 -h 1944 -t 7 -n 1000 -bps 4000000 -g 1:120:1 -f 4 -i /sdcard/data.yuv -o /sdcard/data.264
It was an alignment issue. I changed from 64 to 16 aligned and it works. https://github.com/rockchip-linux/mpp/blob/ee946af015c350c926a0fca2f02da8e429f8b079/mpp/hal/vpu/h264e/hal_h264e_vepu_v2.c#L399
Then I found another similar problem, when the width or height is an odd number (e.g. 1920x1081 or 1921x1080), the encoding result is incorrect, in some formats it fails directly.
I can reproduce the problem using mpi_enc_test. Does MPP not support encoding odd width and height?
mpi_enc_test -w 1920 -h 1081 -t 7 -n 1000 -bps 4000000 -g 1:120:1 -f 4 -i src_yuv420p.yuv -o dst_yuv420p.h264
mpi_enc_test -w 1920 -h 1081 -t 7 -n 1000 -bps 4000000 -g 1:120:1 -f 0 -i src_nv12.yuv -o dst_nv12.h264The raw yuv sources can be generated from ffmpeg:
ffmpeg -f lavfi -i testsrc=s=1920x1081,format=yuv420p -y src_yuv420p.yuv
ffmpeg -f lavfi -i testsrc=s=1920x1081,format=nv12 -y src_nv12.yuv@9426224 您好，请问问题是否解决？估计是和内存对齐有关，请参考mpp/utils/utils.c中read_image()函数对输入YUV的处理。
Liaoyyyy
commented
3 months ago @nyanmisaka The support for odd-height YUV 420p and NV12 inputs has been added. 0001-fix-enc_utils-Support-read-odd-resolution-image.patch
9426224
commented
3 months ago @9426224 您好，请问问题是否解决？估计是和内存对齐有关，请参考mpp/utils/utils.c中read_image()函数对输入YUV的处理。
已经解决 应该还是设置ctx的时候的align参数的对齐问题 目前修改后测试没有问题
由官方demo mpi_enc_test修改而来，测试编码图像分辨率设置为19201080 / 2560 1440 / 3840 2160都可以正常编码输出图像，图像显示正常 如果修改编码分辨率为类似2592 1944 或者 1680 * 1050 等等不常规的分辨率，则运行程序能够看见编码输出，但是dmesg同时会打印巨量报错信息，短暂几秒后整个系统会崩溃卡死，重启后恢复
这里的输入图像来源于opencv转换的mat格式data指针，根据16位对齐原则，buffer每次拷贝进width个数据，指针前进hor_stride个位置，每行拷贝的进行对齐
这是资源分配的部分
输出的日志类似下面这样