You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 6, 2024. It is now read-only.
happens with only yuv420p, yuv422p, bgr24 pixfmts, and when the decoder in used feeds in the soft avframes to rkmpp encoders
For a width 704 -> 784 pixel with 16 aligned hor stride, misaligns on the multipliers of 44,45,46,47,48 of 16.
Below is the visual output of an example
The interleaved or semiplanar or 4 plane rgbA/0 formats are not impacted by the issue
My guess is that MPP is handling all plane buffer as a continuous plane with common stride size, if there are planes multiples of 2 ie: 1,2,4 then, accessing the sub planes are also aligned, but if it is 3 then the size of the planes maz not be aligned (?). Internally, mpp or ffmpeg should be handling those cases differently, since ffmpeg holds a seperate buffer for each plane.
This is most likely related to plane calculation here:
happens with only yuv420p, yuv422p, bgr24 pixfmts, and when the decoder in used feeds in the soft avframes to rkmpp encoders
For a width 704 -> 784 pixel with 16 aligned hor stride, misaligns on the multipliers of 44,45,46,47,48 of 16.
Below is the visual output of an example
to reproduce
ffmpeg -t 1 -f lavfi -i testsrc=s=720x480,format=yuv420p -c:v h264_rkmpp_encoder -y out.mp4
or
to fix rgb24 cases, increasing the MPP hor or ver stride alignment from
16
to64
fixes the issues, but this does not work for yuv420p and yuv422p.FFmpeg/libavcodec/rkmpp.h
Line 27 in d30c8c6
The interleaved or semiplanar or 4 plane rgbA/0 formats are not impacted by the issue
My guess is that MPP is handling all plane buffer as a continuous plane with common stride size, if there are planes multiples of 2 ie: 1,2,4 then, accessing the sub planes are also aligned, but if it is 3 then the size of the planes maz not be aligned (?). Internally, mpp or ffmpeg should be handling those cases differently, since ffmpeg holds a seperate buffer for each plane.
This is most likely related to plane calculation here:
FFmpeg/libavcodec/rkplane.c
Line 277 in d30c8c6
FFmpeg/libavcodec/rkplane.c
Line 391 in d30c8c6
a special case of dimensions of 705x480 crashes the encoder driver, this seems to be another problem with mpp.
see: rockchip-linux/mpp#424
The text was updated successfully, but these errors were encountered: