weird strides from vvdec2.3.0

[zhanghuicuc]

I'm using vvdec with ffmpeg and I've noticed that vvdec outputs weird strides(linesizes), which makes it more complicated to render with OpenGL.

For example, the following video's resolution is 1920x1080 and the pixel format is yuv420p10le, so I'm expecting the strides for each plane to be (3840, 1920, 1920), but the strides from vvdec for each plane is (4416, 2240, 2240).
https://bdcloud-player-new.cdn.bcebos.com/testvideo/mp4/vvc/1080p/liulangdiqiu-266-1080.mp4

I've some questions:

1. Why does vvdec add some padding for each plane?
2. Why does the stride for y plane not equals to (2 * u_plane_stride)?
3. Is there any way to remove the padding when use with ffmpeg? I saw a param called removePadding but it can't be used together with vvdec_decoder_open_with_allocator in ffmpeg.

BTW, I've also tested the strides output by ffvvc decoder, and the result from ffvvc is (3840, 1920, 1920).

[K-os]

Yes, the removePadding parameter does not work with a custom allocator, because it would need an additional copy, which defeats the purpose of a custom allocator. The padding is needed for the decoding process. Most codecs internally work like that, and if a decoder returns the frames without padding, it has to do an additional copy.

We can fix the removePadding to work with the allocator, but from a performance perspective it’s best to fix your renderer to work with stride!=width.

If performance is not an issue, you can implement copying each frame to your destination buffer line by line without the padding, in 5-10 lines of code. The removePadding parameter does nothing else.