pipeline two /frame POSTs + HTTP keep-alive on the Scrypted side

Decouples network upload from firmware decode-and-paint. Before, the
inFlight boolean guard meant Scrypted sent frame N, waited for the
full ~80ms response (~40ms body upload + ~20ms decode + ~50µs paint +
ack), THEN sent frame N+1. The next ffmpeg frame arriving during that
window got dropped.

After:
- ScryptedViewportProvider keeps a per-host undici Agent with
  keepAliveTimeout 30s, connections:2, pipelining:0. Sockets stay
  open across /frame, /state, /config — saves the SYN+SYN-ACK+ACK
  round-trip every POST (small on LAN but real on Wi-Fi).
- Stream loop's inFlight boolean is now a counter capped at 2 so
  frame N+1 can begin uploading on socket B while frame N is still
  being decoded on the device via socket A. Roughly doubles effective
  throughput when body upload time dominates.

Firmware side:
- esp_http_server max_open_sockets bumped 7→4 explicitly: 2 for
  pipelined /frame + 2 spare for concurrent /state and /config slots.
  The JPEG decoder mutex still serialises decode (only one /frame
  can be decoding at a time); this change only unblocks the network
  half of the pipeline.

1 files changed, 6 insertions, 0 deletions

diff --git a/main/http_api.c b/main/http_api.c
index 28ceeeb..4e03868 100644
--- a/main/http_api.c
+++ b/main/http_api.c
@@ -486,6 +486,12 @@ esp_err_t http_api_start(void)
     cfg.max_uri_handlers = 8;
     cfg.lru_purge_enable = true;
     cfg.stack_size       = 8192;  // POST /config alone has ~2.4 KiB of stack locals
+    // Allow Scrypted to keep two POST /frame in flight at once so the
+    // body upload of frame N+1 overlaps with the JPEG decode of frame
+    // N. The decoder mutex still serialises decode itself; this only
+    // unblocks the network half of the pipeline. +1 socket reserve for
+    // a concurrent /state or /config request landing during a stream.
+    cfg.max_open_sockets = 4;
 
     httpd_handle_t server = NULL;
     ESP_RETURN_ON_ERROR(httpd_start(&server, &cfg), TAG, "httpd_start");