diff --git a/src/h265.c b/src/h265.c
index 4655ecc..338f41c 100644
--- a/src/h265.c
+++ b/src/h265.c
@@ -473,7 +473,24 @@ static void h265_fill_slice_params(VAPictureParameterBufferHEVC *picture,
 			slice_params->ref_idx_l1[i] = slice->RefPicList[1][i];
 	}
 
-	slice_params->short_term_ref_pic_set_size = 0;  /* VAAPI doesn't expose */
+	/*
+	 * iter31 α-29: VAAPI's picture->st_rps_bits IS the bit-count of
+	 * short_term_ref_pic_set() in the slice header (per va_dec_hevc.h
+	 * doc-comment for st_rps_bits). This field is required by rkvdec
+	 * (assemble_sw_rps: line 386 in kernel rkvdec-hevc.c). When zero,
+	 * rkvdec falls back to fls(sps->num_short_term_ref_pic_sets - 1),
+	 * which is wrong when num_short_term_ref_pic_sets == 1 (BBB case).
+	 *
+	 * α-26 mis-targeted this onto decode_params->short_term_ref_pic_set_size
+	 * which rkvdec doesn't use. The actual consumer is slice_params.
+	 *
+	 * Note: VAAPI defines st_rps_bits as 0 when short_term_ref_pic_set_sps_flag=1
+	 * (i.e. when slice uses an SPS-defined RPS rather than inline). For BBB,
+	 * st_rps_bits is non-zero for non-IDR slices.
+	 *
+	 * long_term_ref_pic_set_size still 0 — VAAPI doesn't expose this.
+	 */
+	slice_params->short_term_ref_pic_set_size = picture->st_rps_bits;
 	slice_params->long_term_ref_pic_set_size = 0;
 
 	/* Pred weight table */