Compress ready

doc/14_ReRender_roadmap.md

@@ -1,7 +1,9 @@
 # 📦 Re-Render & Compress (H.264)
 
-> Status: **Entwurf / noch nichts implementiert.** Alle Zahlen unten sind
-> Hypothesen, bis sie auf dem Host gemessen sind (siehe Phase 0).
+> Status: **Code implementiert (Phasen 1–3), unit-getestet.** Noch NICHT auf dem
+> Host verifiziert — die FFmpeg-VAAPI/QSV-Pipeline lief bisher nur in Tests, nicht
+> gegen echte Kameras/GPU. Alle Bitraten/Latenz-Zahlen bleiben Hypothesen bis zur
+> Messung auf der Intel- bzw. AMD-Box (Phase 0 + 4).
 
 ## Problem
 
@@ -217,24 +219,28 @@ Nicht „nur neue Args" — betroffen sind mehrere Stellen:
 
 ---
 
-## Nächste Schritte (ToDo — ehrlicher Stand: nichts erledigt)
+## Nächste Schritte (ToDo)
 
-**Phase 0 — Messen (Vorbedingung, blockiert alles andere)**
+Legende: ✅ Code fertig & unit-getestet · 🧪 nur auf dem Host verifizierbar · 🔲 offen
+
+**Phase 0 — Messen (Vorbedingung; auf User-Wunsch parallel zur Implementierung)**
 1. 🔲 Bandbreite der heutigen Live-Streams (320×240 bzw. konfigurierte `liveSize`) auf dem Host messen, bei 1 und bei n Clients.
 2. 🔲 Hypothese 1080p-Stream gegen die echte Zielauflösung abgleichen — lohnt der Umbau?
-3. 🔲 Transport-Latenz-Test: ein Test-fMP4-Stream (MSE) vs. heutiges MJPEG, Methode wie in [doc/03_Protocoll_roadmap.md](03_Protocoll_roadmap.md) (Stoppuhr-Foto).
+3. 🔲 Transport-Latenz-Test: H.264/MSE vs. heutiges MJPEG, Methode wie in [doc/03_Protocoll_roadmap.md](03_Protocoll_roadmap.md) (Stoppuhr-Foto).
 
-**Phase 1 — Encode-Pfad (nur wenn Phase 0 positiv)**
-4. 🔲 `/dev/dri`-Passthrough + VAAPI/QSV-Auto-Erkennung.
-5. 🔲 FFmpeg-H.264-fMP4-Profil definieren; CPU/GPU/Latenz auf dem Host messen.
+**Phase 1 — Encode-Pfad**
+4. ✅ `/dev/dri`-Passthrough ([docker-compose.yaml](../docker-compose.yaml)) + GPU-Auswahl `GPU=intel|amd|none` / `HWENC` ([src/hwencode.js](../src/hwencode.js)).
+5. ✅ FFmpeg-H.264-fMP4-Profil ([src/hwencode.js](../src/hwencode.js)). · 🧪 CPU/GPU/Latenz/Bitrate auf Intel- UND AMD-Box messen + Profil/Level ggf. anpassen.
 
 **Phase 2 — Server**
-6. 🔲 `encode='h264'` in `videoOutArgs` / `CameraSwitch` (inkl. Init-Segment-Cache + Byte-Stream-Fan-out).
-7. 🔲 H.264-Stream-Route + Modus in `/api/cameras`.
+6. ✅ `encode='h264'` in [src/cameraSwitch.js](../src/cameraSwitch.js) (fMP4 + Init-Segment-Cache + MJPEG-Nebenausgang für Snapshots) + [src/fmp4Parser.js](../src/fmp4Parser.js).
+7. ✅ H.264-Stream-Route (`video/mp4`, Init-first, Fan-out) + Modus/`mseCodec` in `/api/snapshot` & `/api/cameras` ([src/snapshotService.js](../src/snapshotService.js)).
 
 **Phase 3 — Client**
-8. 🔲 MSE-`<video>`-Player + Feature-Detection + Auto-Fallback auf MJPEG.
-9. 🔲 `config.html`: `encode`-Auswahl.
+8. ✅ MSE-`<video>`-Player + `isTypeSupported`-Feature-Detection + Snapshot-Fallback ([public/viewer.js](../public/viewer.js)).
+9. ✅ `config.html`/`config.js`: Kompressions-Auswahl (MJPEG/H.264) + `encode` durch [src/configService.js](../src/configService.js).
 
-**Phase 4 — Verifikation**
-10. 🔲 Bandbreite & CPU/GPU vorher/nachher vergleichen (gemessen, auf dem Host).
+**Phase 4 — Verifikation (auf dem Host, mit echten Kameras + GPU)**
+10. 🧪 Eine Kamera testweise auf `encode='h264'` (UI oder `GPU=intel`/`amd` setzen), Bild im Browser prüfen, Codec-Log (`h264_vaapi`/`h264_qsv`) kontrollieren.
+11. 🧪 Bandbreite & CPU/GPU MJPEG vs. H.264 vergleichen; Profil (`H264_PROFILE`/`H264_MSE_CODEC`), GOP & Bitrate nachjustieren.
+12. 🧪 AMD-Box gegenprüfen (`GPU=amd`), falls sie Zielhardware ist.