barby/hermes-erkenntnisse
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity
hermes-erkenntnisse/2026-07-24-ticket84-video-laenge-dynamisch.md

5.6 KiB
Raw Permalink Blame History

#84: Video-Länge dynamisch statt fest gedeckelt (~2 Min)

Datum: 2026-07-24 Ort: B:\barby\orchestrator\main.py (VM302, Dienst BarbyOrchestrator, Port 8197) + /opt/gpu1-status/app.py (VM201, Dienst gpu1-portal, Port 9090, öffentlich cp.go-ki.eu) Backups: B:\barby\orchestrator\main.py.bak-video-length-20260723-234947 (VM302), /opt/gpu1-status/app.py.bak-video-length-84-20260724-002728 (VM201)

Wo saß der Cap

In main.py, Konstante MAX_VIDEO_SEGMENTS = 12 (Zeile ~338, alt) und in build_plan() (Video-Zweig, ~Zeile 517-536, alt): egal wie lang der Prompt/das Drehbuch die Dauer vorgab, wurde die Segmentzahl hart auf 12 Segmente gekürzt (12 × ~3,06s/Segment ≈ 37s effektive Kappungsgrenze — der praktisch erlebte "~2 Min Deckel"). Es gab dafür kein echtes technisches Limit — Segmente werden sequenziell gerendert (render_video_segments), es gibt kein VRAM-/Parallelitäts-Limit, das die Anzahl deckelt, nur Wall-Clock-Zeit auf der A40.

Was geändert wurde (additiv, reversibel)

Backend (main.py):

  1. MAX_VIDEO_SEGMENTS bleibt als reiner Referenzwert für Renderzeit-Hinweise erhalten, deckelt aber die Länge nicht mehr.
  2. Neu: HARD_SAFETY_SEGMENT_LIMIT (ENV-konfigurierbar, Default 600 Segmente ≈ 30 Min) — eine echte Sicherheitsgrenze gegen Tippfehler/DoS ("9999 Minuten"), kein Qualitäts-/Inhalts-Cap. Nur wenn diese Grenze überschritten wird, greift ein Cap (mit klarer Hinweis-Meldung, warum).
  3. build_plan(): Segmentzahl = ceil(gewünschte_sekunden / SEGMENT_LEN_SEC), ohne Deckelung auf 12. Neues Feld im Plan: geschaetzte_rohdiffusions_minuten_a40 (reine A40-Diffusionszeit, informativ).
  4. Neues Request-Feld laenge_modus: "auto" | "fest" (GenerateRequest, /generate und /api/orchestrate+/orchestrate via _orchestrate_handler). Bei "auto" entscheidet der Inhalt (Wortzahl im Drehbuch, ~2,3 Wörter/Sekunde geschätzt) — unabhängig von der bereits vorhandenen Prompt-Phrasenerkennung (CONTENT_DECIDES_RE, z.B. "Inhalt entscheidet"), die weiterhin zusätzlich greift.
  5. video_dauer_sekunden (Parameter-Override, war schon vorhanden) hat weiterhin Vorrang vor laenge_modus=auto.

Frontend (app.py, VM201, Video-Erstellen-Tab):

  1. Dropdown #ve-laenge: neue Option 🤖 Auto (Inhalt entscheidet) (Value auto) ganz oben ergänzt, zusätzlich 5 Minuten (300s) als weitere feste Option. Default bleibt unverändert bei 60 Sekunden (additiv, kein Verhaltensbruch für bestehende Nutzung).
  2. vePipelineStart(): bei laenge==='auto' wird laenge_sekunden:null und laenge_modus:'auto' gesendet statt laenge_sekunden:parseInt('auto') (NaN). Der Portal-Endpunkt /api/studio/orchestrate ist ein reiner Passthrough zum Orchestrator (/api/orchestrate), daher kein weiterer Code auf VM201 nötig.

Beleg (Testinstanz Port 8199, main.py unverändert vom Prod-main.py, GPU-Job sofort

nach Plan-Auslesen gestoppt, um die A40 nicht unnötig zu belasten)

Test Eingabe Ergebnis vorher (Cap) Ergebnis nachher
Explizite Dauer "... 90 Sekunden Video." 12 Segmente (~37s, hart gekappt) 30 Segmente, geplante_segmente=30, Hinweis: "30 Segmente geplant (~1.5 Min reine A40-Diffusionszeit ...) - läuft vollständig durch, kein Cap mehr (siehe #84)."
Explizite Dauer (Prod, nach Restart) "... 75 Sekunden Video." 12 Segmente 25 Segmente, geschaetzte_rohdiffusions_minuten_a40=1.3
Inhalt entscheidet (Prompt-Phrase) Mehrszenen-Text + "Inhalt entscheidet die Laenge." n/a modus=inhalt_entscheidet, 6 Segmente, Quelle "39 Woerter im Drehbuch"
laenge_modus=auto (API-Feld) Mehrszenen-Text, laenge_modus:"auto" n/a modus=inhalt_entscheidet, Quelle "... Woerter im Drehbuch (laenge_modus=auto)" — funktioniert unabhängig von Prompt-Phrasen
Sicherheitsgrenze (nicht produktiv getestet, nur Codepfad geprüft) n/a greift nur ab >600 Segmenten (~30 Min), mit expliziter Hinweis-Meldung "Tippfehler-/DoS-Schutz, kein Qualitäts-Cap"

python -m py_compile B:\barby\orchestrator\main.py → exit 0 (VM302). python3 -m py_compile /opt/gpu1-status/app.py → COMPILE_OK (VM201). https://cp.go-ki.eu/ → HTTP 200, ausgeliefertes HTML enthält Auto (Inhalt entscheidet) und laenge_modus:(laenge==='auto'?'auto':null).

Echtes technisches Limit (ehrlich benannt, keine Cap-Tarnung)

  • A40 VRAM ist während EINES Segments knapp (vram_free_gb im /health-Endpunkt lag beim Testlauf bei 0.3 GB frei von 45 GB) — das begrenzt aber nicht die Anzahl der Segmente, weil sie sequenziell laufen, sondern nur, wie viel parallel dazu (Postprocessing des Vorsegments) gleichzeitig laufen kann. Das ist bereits in postprocess_segment als überlappende Async-Task gelöst (#20).
  • Wall-Clock-Zeit ist die echte Grenze: laut Code-Kommentar ~4,3 Min/Clip im Fastpath (512×896, 4-Step-Lightning-LoRA) — ein 25-Minuten-Video (500 Segmente) würde real mehrere Stunden A40-Zeit brauchen. Das steht jetzt als geschaetzte_rohdiffusions_minuten_a40 im Plan, damit das vor dem Start sichtbar ist, statt überrascht zu werden.
  • Die neue HARD_SAFETY_SEGMENT_LIMIT (600 Segmente ≈ 30 Min) ist bewusst so hoch gewählt, dass sie in der Praxis nie ein normales Drehbuch trifft, sondern nur echte Fehleingaben abfängt.

Rollback

Copy-Item B:\barby\orchestrator\main.py.bak-video-length-20260723-234947 B:\barby\orchestrator\main.py -Force
schtasks /Run /TN "BarbyOrchestrator"

ssh root@100.114.24.89 "cp -a /opt/gpu1-status/app.py.bak-video-length-84-20260724-002728 /opt/gpu1-status/app.py && systemctl restart gpu1-portal.service"