ChK/appRobotWebcam
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Compress ready

Browse Source
This commit is contained in:
chk
2026-06-07 17:13:34 +02:00
parent d9cfa7e974
commit 7f32b82e59
2 changed files with 40 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files

41
cameras.json
View File

@@ -1,38 +1,37 @@
{ {
"cameras": [ "cameras": [
{ {
"id": "cam0", "id": "cam0",
"device": "/dev/video0", "device": "/dev/video0",
"name": "Kamera 0", "name": "Kamera 0",
"position": "front", "position": "front",
"stream": true, "stream": true,
"hires": true, "hires": true,
"note": "usb-046d_0825_3BB3FE20-video-index0", "note": "usb-046d_0825_3BB3FE20-video-index0",
"hiresSize": "1280x960", "hiresSize": "1280x960",
"liveSize": "320x240" "liveSize": "320x240"
}, },
{ {
"id": "cam1", "id": "cam1",
"device": "/dev/video2", "device": "/dev/video2",
"name": "Kamera 1", "name": "Kamera 1",
"position": "left", "position": "left",
"stream": true, "stream": true,
"hires": true, "hires": true,
"note": "usb-046d_081b_342D4F40-video-index0", "note": "usb-046d_081b_342D4F40-video-index0",
"hiresSize": "1280x960", "hiresSize": "1280x960",
"liveSize": "320x240" "liveSize": "320x240"
}, },
{ {
"id": "cam2", "id": "cam2",
"device": "/dev/video4", "device": "/dev/video4",
"name": "Kamera 2", "name": "Kamera 2",
"position": "right", "position": "right",
"stream": true, "stream": true,
"hires": true, "hires": true,
"note": "usb-046d_HD_Pro_Webcam_C920_9C5591DF-video-index0", "note": "usb-046d_HD_Pro_Webcam_C920_9C5591DF-video-index0",
"hiresSize": "1920x1080", "hiresSize": "1920x1080",
"liveSize": "640x480", "liveSize": "320x240"
"encode": "h264"
} }
] ]
} }

34
doc/14_ReRender_roadmap.md
View File

@@ -1,7 +1,9 @@
# 📦 Re-Render & Compress (H.264) # 📦 Re-Render & Compress (H.264)
> Status: **Entwurf / noch nichts implementiert.** Alle Zahlen unten sind > Status: **Code implementiert (Phasen 1–3), unit-getestet.** Noch NICHT auf dem
> Hypothesen, bis sie auf dem Host gemessen sind (siehe Phase 0). > 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 ## 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. 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? 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)** **Phase 1 — Encode-Pfad**
4. 🔲 `/dev/dri`-Passthrough + VAAPI/QSV-Auto-Erkennung. 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 definieren; CPU/GPU/Latenz auf dem Host messen. 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** **Phase 2 — Server**
6. 🔲 `encode='h264'` in `videoOutArgs` / `CameraSwitch` (inkl. Init-Segment-Cache + Byte-Stream-Fan-out). 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 + Modus in `/api/cameras`. 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** **Phase 3 — Client**
8. 🔲 MSE-`<video>`-Player + Feature-Detection + Auto-Fallback auf MJPEG. 8. ✅ MSE-`<video>`-Player + `isTypeSupported`-Feature-Detection + Snapshot-Fallback ([public/viewer.js](../public/viewer.js)).
9. 🔲 `config.html`: `encode`-Auswahl. 9. ✅ `config.html`/`config.js`: Kompressions-Auswahl (MJPEG/H.264) + `encode` durch [src/configService.js](../src/configService.js).
**Phase 4 — Verifikation** **Phase 4 — Verifikation (auf dem Host, mit echten Kameras + GPU)**
10. 🔲 Bandbreite & CPU/GPU vorher/nachher vergleichen (gemessen, auf dem Host). 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.