[BUG] AFBC hor stride must be multiplied by 3/2

[hbiyik]

My rendering path is mpp -> ffmpeg (drm_prime) -> kodi(kms/gbm -> vop2)

i found out by testing that when the decoder spits AFBC frames, the horstride provided must be divided by 4.

nyanmisaka/ffmpeg-rockchip@4487c02

I do not know the reason for this but i found out by testing, when the mpp provided hor stride is provided the output is like nyanmisaka/ffmpeg-rockchip#4 (comment)

When divided by 4, everything is fine.

[FumasterLin]

The issue is weird，could you print the hor_stride value to check?

[hbiyik]

Tested file is Bigbuckbunny 1080p h264.

This is what mpp provides.

This is what i have to give to DRM Plane to render correctly.

This is how the rendering is happening:
https://github.com/xbmc/xbmc/blob/a808b5564c8416e2d84ca75b05e5bfd0fd4451c3/xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/VideoLayerBridgeDRMPRIME.cpp#L121

stride = 1920/4 = 480
offset = 4px * 480 = 1920

kernel is 5.10 rkr4

[hbiyik]

@FumasterLin

I had a mistake during testing, the actual multiplier is 3/2 not 4. So sorry for that, but i think i can make sense of 3/2 multiplier.

For a given YU08 AFBC frame, you will have a single plane. If the actual frame is NV12/16/15/20 something semiplanar yuv, you will end up with hstride=width for Y plane and hstride=width/2 for UV plane.

So may be AFBC is single plane, it expects stride as sum of all actual planes which is 1.5 of actual stride?

nyanmisaka/ffmpeg-rockchip@baf41c5

[HermanChen]

Yes, the AFBC buffer size is slightly larger then original format size.
If it is YUV420 then its FBC buffer is about 1.5 times width * height.

[hbiyik]

This is a bug. Afbc frame can not be multiple planes, therefore if you give a stride based on only Y plane size, 3/2 scale factor of actual planes size will break your alignment. I dont understand why you close the issue?

[HermanChen]

The fbc stride in MppFrame is not a buffer size stride.
The fbc buffer has two parts, the payload part and the header part.
The payload part is the compress data for each fbc block. Then the header part is the storage for each data block offset to the payload base address.
In the header part the index is not arranged all closely next to each other. It is arranged by line.
That's say 1280x720 frame fbc block is 32x32. There is 1280 / 32 = 40 block in each line. In header part 40 header info is arranged together and next 40 header info is arranged with the FBC stride distance.
So that is the fbc stride definition in mpp side. Then what is the definition in drm side?

[hbiyik]

@HermanChen thanks for the explanation, in drm it is the plane stride i was concerned about the divider portion of 3 / 2, may cause 16 byte alignment 8 byte when scaled up and down, but i tested this with width = various odd numbers * 16, each time drm picked it up correctly without any stride skew. So this works as you have intended then.

Closing to keep it clean.