I see.
In the camera case, the src is hs=1080 and dst hs=1080.
The grabbed frame size = 1920 x 1080 * 3 / 2 (AV_PIX_FMT_NV12) and the destination frame size to encode is the same.
I will test a 1920 x 1080 fake buffer and a 1920 x 1088 (AV_PIX_FMT_YUV420P) and see what i get.
Thanks anyway.
The tests confirmed the dst frame buffer that will be encoded must have hs=1088.
the frame size is 1920 x 1088 * 3 / 2 for NV12.
According to the MPP docs you seem to need to copy the planes to satisfy the padding requirements.
hey anyone using the npu on dietpi? I’m not sure it supports hardware acceleration
i have run LLM inference on cpu and the performance was great but am wondering if i need to change OS to use the npu
I thought RGA would handle this padding, but no.
I converted NV12 (no padding, the frame grabbed from the camera) to RGB24, and that worked fine during encoding.
But i think there is a penalty during encoding, RGB24 will be converted again, right?
What’s the equivalent for this command in ffmpeg?
mpi_enc_test -i /dev/video11 -f 0 -w 1920 -h 1080 -o out_1920x1080.h265 -t 16777220 -n 500 -g 6:6 -rc 1 -bps 2000000 -fps 30
I tried this one but got different results:
ffmpeg -f v4l2 -framerate 30 -video_size 1920x1080 -i /dev/video11 -c:v hevc_rkmpp -b:v 2M -rc_mode 1 -g 6 -vframes 500 -y out_1920x1080.mkv
ffmpeg -init_hw_device rkmpp -f v4l2 -framerate 30 -video_size 1920x1080 -i /dev/video11 \
-vf hwupload,scale_rkrga=w=1920:h=1080:format=rgb24 -c:v hevc_rkmpp -b:v 2M -rc_mode 1 -g 6 -vframes 500 -y out_1920x1080.mkv