diff --git a/src/image.c b/src/image.c
index bd2d706..f20e6ca 100644
--- a/src/image.c
+++ b/src/image.c
@@ -372,19 +372,21 @@ VAStatus RequestQueryImageFormats(VADriverContextP context,
 	formats[n].bits_per_pixel = 12;
 	n++;
 
-	/* iter39 fresnel fix: advertise P010 UNCONDITIONALLY (was gated on
-	 * driver_data->is_10bit). ffmpeg-vaapi's hwcontext_vaapi calls
-	 * vaQueryImageFormats during hwframes context setup, BEFORE
-	 * vaCreateContext fires (so is_10bit isn't set yet). If P010 isn't
-	 * in the format catalog at that early query, hwdownload rejects
-	 * pix_fmt=p010le with "Invalid output format" and decode fails
-	 * before our backend even sees the 10-bit context.
-	 * Reporting P010 unconditionally is safe: consumers ask for it only
-	 * when their decode pipeline actually needs 10-bit, and our P010
-	 * unpack path in copy_surface_to_image gates on
-	 * image->format.fourcc == VA_FOURCC_P010 (independent of is_10bit). */
-	(void)driver_data;
-	if (n < V4L2_REQUEST_MAX_IMAGE_FORMATS) {
+	/*
+	 * iter39 Option B revert (2026-05-17): P010 advertisement is
+	 * gated on driver_data->is_10bit again. Previously advertised
+	 * unconditionally (63fed87) so ffmpeg-vaapi's early
+	 * vaQueryImageFormats (pre-vaCreateContext) could see it for
+	 * 10-bit profiles — but that broke HEVC 8-bit on fresnel:
+	 * ffmpeg-vaapi picked P010 for the HEVC hwframe pool, EndPicture
+	 * SEGV'd in the .so when the consumer-side P010 expectations met
+	 * an 8-bit NV12 CAPTURE buffer.
+	 * Safe because Option B drops VAProfileHEVCMain10 + Hi10P from
+	 * enumeration — no 10-bit decode pipeline will reach this catalog
+	 * query so the gate-on-is_10bit (which stays false for 8-bit
+	 * profiles) correctly returns NV12-only.
+	 */
+	if (driver_data->is_10bit && n < V4L2_REQUEST_MAX_IMAGE_FORMATS) {
 		memset(&formats[n], 0, sizeof(formats[n]));
 		formats[n].fourcc = VA_FOURCC_P010;
 		formats[n].byte_order = VA_LSB_FIRST;