diff --git a/src/h265.c b/src/h265.c
index 76eabef..59f06bb 100644
--- a/src/h265.c
+++ b/src/h265.c
@@ -314,18 +314,19 @@ static void h265_fill_decode_params(struct request_data *driver_data,
 	decode_params->num_poc_st_curr_after = n_st_after;
 	decode_params->num_poc_lt_curr = n_lt;
 	/*
-	 * 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).
+	 * decode_params->short_term_ref_pic_set_size is the bit-count of
+	 * short_term_ref_pic_set() inside the **SPS** (per V4L2 spec
+	 * v4l2-controls.h doc). VAAPI doesn't expose this — it exposes
+	 * picture->st_rps_bits which is the bit-count of st_ref_pic_set()
+	 * inside the **slice header** when short_term_ref_pic_set_sps_flag=0.
+	 * That value belongs in slice_params->short_term_ref_pic_set_size,
+	 * not here (see [[va-st-rps-bits-is-slice-field]] memory + α-29).
 	 *
-	 * long_term_ref_pic_set_size and num_delta_pocs_of_ref_rps_idx still
-	 * left zero (VAAPI doesn't expose either).
+	 * α-26 wrote st_rps_bits to this decode_params field in iter26 by
+	 * field-name match; rkvdec doesn't read this field at all, so the
+	 * misroute was harmless but stale. iter36 reverts to 0.
 	 */
-	decode_params->short_term_ref_pic_set_size = picture->st_rps_bits;
+	decode_params->short_term_ref_pic_set_size = 0;
 
 	/*
 	 * iter11 α-14: IRAP/IDR/NO_OUTPUT_OF_PRIOR flags. VAAPI doesn't