hbiyik / FFmpeg

PLEASE USE https://github.com/nyanmisaka/ffmpeg-rockchip REPO INSTEAD.
https://github.com/nyanmisaka/ffmpeg-rockchip
Other
90 stars 7 forks source link

3 plane pixel formats are losing the alignment when copied from AVframe #17

Closed hbiyik closed 11 months ago

hbiyik commented 12 months ago

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

image

or

image

to fix rgb24 cases, increasing the MPP hor or ver stride alignment from 16 to 64 fixes the issues, but this does not work for yuv420p and yuv422p. https://github.com/hbiyik/FFmpeg/blob/d30c8c6181d5bdcff8d9a8ba37935fbedeb26a8a/libavcodec/rkmpp.h#L27

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: https://github.com/hbiyik/FFmpeg/blob/d30c8c6181d5bdcff8d9a8ba37935fbedeb26a8a/libavcodec/rkplane.c#L277 or AVframe copy routine here https://github.com/hbiyik/FFmpeg/blob/d30c8c6181d5bdcff8d9a8ba37935fbedeb26a8a/libavcodec/rkplane.c#L391

a special case of dimensions of 705x480 crashes the encoder driver, this seems to be another problem with mpp. see: https://github.com/rockchip-linux/mpp/issues/424

hbiyik commented 11 months ago

fixed in https://github.com/hbiyik/FFmpeg/commit/eb34616ece746ae58030fd4601e802dacb0d3ee2