Fix error in sizes of H265 column width and row height, arrays
An NVIDIA internal hardware document noted: #define MAX_TILE_COLS 20 #define MAX_TILE_ROWS 22 As of this writing the VDPAU API writes: /** Only need to set 0..num_tile_columns_minus1. The struct definition reserves up to the maximum of 22. Invalid values are ignored. */ uint16_t column_width_minus1[22]; /** Only need to set 0..num_tile_rows_minus1. The struct definition reserves up to the maximum of 20. Invalid values are ignored.*/ uint16_t row_height_minus1[20]; This is not correct. The correct definitions ought to be: uint16_t column_width_minus1[20]; uint16_t row_height_minus1[22]; The H.265 Specification does not give an explicit range for the sizes of these arrays. It is possible to calculate an upper limit for a particular video frame implicitly using these equations: MinCbLog2SizeY = log2_min_luma_coding_block_size_minus3 + 3 (7-10) CtbLog2SizeY = MinCbLog2SizeY + log2_diff_max_min_luma_coding_block_size (7-11) CtbSizeY = 1 << CtbLog2SizeY (7-13) PicWidthInCtbsY = Ceil( pic_width_in_luma_samples ÷ CtbSizeY ) (7-15) num_tile_columns_minus1 ϵ [0, PicWidthInCtbsY − 1] (num_tile_rows_minus1 is similar) For a video with: log2_min_luma_coding_block_size_minus3 = 0 log2_diff_max_min_luma_coding_block_size = 0 pic_width_in_luma_samples = 4096 num_tile_columns_minus1 < 512 This seems patological. Perhaps we could cap column_width_minus1[] and row_height_minus1[] at 32 or 64 elements apiece if other hardware implementations saw a reason to do so. This change as proposed does not alter the size of VdpPictureInfoHEVC, but it *does* change the ABI. We can either add it as a fixup to the just released VDPAU 1.0, or create a follow-on patch structure. Since few have adopted VdpPictureInfoHEVC since Monday my preference is to fix the existing structure. Signed-off-by: Aaron Plattner <aplattner@nvidia.com> Acked-by: Aaron Plattner <aplattner@nvidia.com>
Please register or sign in to comment