diff --git a/src/h265.c b/src/h265.c
index ba764ee..e32331e 100644
--- a/src/h265.c
+++ b/src/h265.c
@@ -312,9 +312,19 @@ static void h265_fill_decode_params(struct request_data *driver_data,
 	decode_params->num_poc_st_curr_before = n_st_before;
 	decode_params->num_poc_st_curr_after = n_st_after;
 	decode_params->num_poc_lt_curr = n_lt;
-	/* short_term_ref_pic_set_size, long_term_ref_pic_set_size,
-	 * num_delta_pocs_of_ref_rps_idx left zero (VAAPI doesn't expose;
-	 * matches FFmpeg's behavior for non-bitstream-driven population). */
+	/*
+	 * iter26 α-26: VAAPI DOES expose short_term_ref_pic_set bit-count
+	 * via picture->st_rps_bits. Without populating this, rkvdec's
+	 * DPB reference resolution for P/B frames uses the wrong slice-
+	 * header skip and reads the wrong reference; frame 1 (IDR) decodes
+	 * correctly but frames 2+ diverge (iter25 evidence: cmp differs at
+	 * byte 1382401 = frame 2 boundary, kdirect bytes 4-5 = 0x0a 0x00,
+	 * libva = 0x00 0x00).
+	 *
+	 * long_term_ref_pic_set_size and num_delta_pocs_of_ref_rps_idx still
+	 * left zero (VAAPI doesn't expose either).
+	 */
+	decode_params->short_term_ref_pic_set_size = picture->st_rps_bits;
 
 	/*
 	 * iter11 α-14: IRAP/IDR/NO_OUTPUT_OF_PRIOR flags. VAAPI doesn't