From 3e9243fd517ec9106b0c219023cef9049e83c4d2 Mon Sep 17 00:00:00 2001
From: SteadyW <233242505+YusufB5@users.noreply.github.com>
Date: Fri, 19 Jun 2026 20:46:59 +0300
Subject: [PATCH] Clarify Adaptive Frame Codec opt-in validity

Updated Adaptive Frame Codec section to clarify opt-in validity range.
---
 README.md | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/README.md b/README.md
index 514b283..27ff7de 100644
--- a/README.md
+++ b/README.md
@@ -35,7 +35,7 @@ No autoplay restrictions. To the browser, it's just text on a canvas.
 2.  **Frontend (Vanilla JS)**: Receives binary frames via WebSockets, manages a jitter buffer, and renders to a Canvas grid.
 3.  **Communication**: Optimized WebSocket protocol with a custom `INIT` handshake for dynamic resolution/FPS adjustment.
 
-## 🗜️ Adaptive Frame Codec (opt-in, backward compatible)
+## 🗜️ Adaptive Frame Codec (opt-in,valid for mod [2-5])
 
 The original binary protocol re-sends the full grid every frame. An opt-in
 adaptive codec picks the smallest of three encodings per frame and tags it in a
@@ -58,7 +58,6 @@ the tested one.
 | content | vs. legacy |
 | :------ | :--------- |
 | static screen / slideshow | **0.3%** (≈375×) |
-| pixel mode | 11.6% (≈8.6×) |
 | high-motion / full-frame change | 63% (never worse than legacy) |
 
 An optional `--quality {lossless,high,balanced,low}` enables lossy *temporal