Bueno...parece que hay dos problemas: uno con en el envío de datos al navegador y otro con la red WiFi (Estoy enviando solo fotografías)
Con la red: el tiempo que informa el web server está dedicado en un 99% al envío de datos por la red y el resto para conversión a JPG y procesamientos varios.
Con el envío al navegador: acá viene lo raro.... hay veces que el envío de una foto demora 2, 3 o 4ms pero el navegador no la muestra
(lo mismo pasa con Firefox y con Edge) y un tiempo después comienza a mostrar la imagen como si aún la estuviera cargando aunque el server informa que ya transmitió toda la imagen
. Yo he visto algo parecido hace muuuuchos años y se soluciona fácil "flusheando" el stream de salida en cuanto se envían los datos...solo que acá no tengo NPI de como hacerlo en este código del servidor. Según mis cálculos, debe haber un buffer de 16K o algo similar que no se envía hasta que no se llena, y como acá las imágenes tienen 4 o 5K tengo que juntar 4 antes de que alguna salga. Voy a tener que analizar el código de envío de datos la red a ver si encuentro que ocurre...
No te voy a decir nada nuevo para vos... por lo que lei, ya mas o menos sabes por donde encaminarte, si es que ya no estas encaminado...
El "Efecto Kétchup (Segmentación de Datos o Buffering de Salida) pasa justamente cuando queres enviar sobres por correo. El sistema de red del ESP32 es como un cartero eficiente que no quiere caminar hasta el buzón por un solo sobre de 4K; el vagoneta prefiere esperar a tener la bolsa llena como dijiste (unos 14K o 16K) para hacer un solo viaje.
Como tus fotos son chicas, el cartero se queda sentado esperando la segunda, tercera y cuarta foto. De repente, cuando se llena el bolson la saca, envía todo junto de golpe. Por eso el navegador no muetranada y, de pronto, la imagen aparece escupida de una vez.
El 99% de tiempo en red, es un tiempo de espera, no de trabajo. Me paso algo similar con el bot de Telegram y pelear la parte de generación de video AVI con varios JPG y mandarlo... Ponche varias veces por conceptuar algunas cosas mal (no es tu caso)...
Ese porcentaje no significa que la red sea lenta, sino que el procesador terminó su trabajo (sacar la foto y convertirla a JPG) en un suspiro, y se queda esperando de brazos cruzados a que el hardware de red le confirme que los datos salieron. El ESP32 reporta esa espera como tiempo de red.
Para solucionar esto tenes varias vias; En mi caso tuve que decirle al servidor: "No esperes a nadie, envia lo que tenges ya".
Desactiva el Algoritmo de Nagle: Es un interruptor llamado TCP_NODELAY (app_httpd.cpp - startCameraServer()). Con esto , le quitas la "pereza" al cartero y lo obligas a salir con cada sobre sin retardos de 40ms a 200ms, por pequeño que sea.
En las ultimas versiones de CameraWebServer el servidor HTTP de Espressif ya viene optimizado para el streaming de video, pero perdes la funcionalidad del modelo que tiene las primeras versiones de vision artificial... Todo esto ya lo pari en algun moento; Tenia algunos tips mas, pero no se donde tengo esas carpetas de todas las versiones que arme
Y... De 32 a 8, hay una terrible diferencia. Si podes devolverlo por ML, ni lo dudes
NAAA, Paraa... Ahí vi bien 6404L-3SQ (o APS6404L-3SQR-SN) 64 Megabits - PSRAM (Pseudo-SRAM) QSPI
no se por que en algun momento delire mb como megabyte en mi mente
son megabits... aclaro por las dudas por que creo quelo dije en algun momento
o no? bue... por las dudas aclaro
yo estoy buscando un misero cable como la gente, el que uso siempre finiquito y me tira error 
Por lo que veo, la unica diferencia que veo es la SPRAM, el resto al parecer son bastantes similares
