User reported "JPG Decompression Failed! Data format error" hitting intermittently with quality 0.35. Worker log showed actual JPEG payloads at 7959-8123 bytes per frame — right at the QEMU emulator's 8192-byte deliverable budget (8 EOFs × 1024 bytes from cam_hal's default 16-descriptor ring). The webcam JPEG encoder produces variable-size output: simple uniform scenes compress to ~6 KiB, complex/textured/moving frames bloat to ~9-10 KiB. Anything over 8192 gets truncated mid-Huffman-scan in the firmware framebuffer, my walker injects FF D9 at byte 8190 to keep cam_verify_jpeg_eoi happy, but the upstream jpg2rgb565 actually parses the structure and chokes on the truncated stream. Quality 0.28 keeps even the worst-case complex frame comfortably under 8 KiB. Visual quality is still much better than the 0.25 fallback — fine for a 160×120 preview where the user cares about "is my face there" not "did the JPEG quantization tables converge". Real long-term fix would be to bump EOFS_PER_FRAME and lift the 8 KiB ceiling — but that touches the QEMU walker (DLL rebuild cycle) and risks breaking the descriptor-ring math. Doing this frontend tweak first to unblock the demo. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| __tests__ | ||
| assets | ||
| components | ||
| data | ||
| hooks | ||
| pages | ||
| services | ||
| simulation | ||
| store | ||
| types | ||
| utils | ||
| velxio-elements | ||
| App.css | ||
| App.tsx | ||
| entry-server.tsx | ||
| index.css | ||
| main.tsx | ||
| seoRoutes.ts | ||
| vite-env.d.ts | ||