newsonline24

Helmut4 wurde zum fehlenden Bindeglied zwischen Storage und Editorial-Workflows – mit Projektverständnis und Flexibilität, die im Alltag vorher schlicht nicht verfügbar waren.

Die Herausforderung: Silos, Shadow Storage und Workflow-Lücken

Zuvor setzte das Team auf Reach Engine als MAM – ergänzt durch ein LTO-Archiv und ein Fiber-Channel-SAN. Reach Engine bot solide Automatisierung, war aber nicht granular genug, um Adobe-Premiere-Projekte sauber zu managen – insbesondere, weil Editoren Medien zunehmend aus unterschiedlichen Quellen bezogen, auch außerhalb des MAM.

Kernprobleme:

• Unverwaltete Medien in isolierten Projektordnern auf Shared Storage
• Keine Transparenz: Welche Assets stecken in welchen Projekten?
• Content-Duplikate (teilweise unnötige Kopien vom MAM ins SAN)
• Kein Tracking zu projektbezogener Nutzung, Storage-Verbrauch oder Ownership
• Starre Delivery-Workflows: Veröffentlichung erst nach vollständigem Ingest möglich
• Silo-Systeme: Integration zwischen Editorial-Tools und Storage-Infrastruktur war unnötig schwer

Zusätzlich verschärft: das Ende von Adobe Prelude und der Bedarf, integrierte Ingest- und Tagging-Workflows zu ersetzen.

Die Lösung: Helmut4 + helmut.cloud-Integration

Helmut4 wurde als projektzentrierte Orchestrierungsebene über Editorial-, Storage- und MAM-Systeme ausgerollt. Durch Flexibilität, Erweiterbarkeit und die agentenbasierte Architektur konnte die Franchise ihre Workflows „von Grund auf“ neu designen.

Zentrale Benefits:

• Projekt-Awareness: Helmut4 indexierte jedes Adobe-Premiere-Projekt im SAN und machte es für Media-Manager sichtbar: „Helmut4 hat ihnen etwas gegeben, von dem sie nicht einmal wussten, dass sie es brauchen: Sichtbarkeit über das komplette Projekt-Ökosystem. Damit konnten nicht-redaktionelle Media-Manager Storage und Workflows tracken, ohne Premiere verstehen zu müssen.“
• Automatisierung von Ingest & Delivery: Helmut4 hat Ingest und Delivery entkoppelt. Editoren konnten fertigen Content sofort an YouTube oder die Team-Website ausspielen – ohne auf den Ingest ins MAM zu warten. Parallel liefen Ingest-Jobs im Hintergrund weiter: Compliance/Archiv-Anforderungen erfüllt, Speed-to-Publish priorisiert. „Mit Reach Engine musste man zuerst ingestieren. Jetzt sind Delivery und Ingest mit Helmut4 zwei parallele Workflows. Das ist massiv, wenn Deadlines eng sind.“
• Verteilte Verarbeitung: Auf jeder Workstation lief ein schlanker Helmut4-Agent. So konnten Transcoding und Automationsschritte dezentral ausgeführt werden. Statt zentraler Queue-Engpässe laufen Aktionen lokal – weniger Last auf zentralen Servern, schnellere Delivery-Timelines.
• Legacy-Projekt-Relinking: Mit historischen Metadaten aus der Reach-Engine-Migration ermöglichte Helmut4 das Relinking alter Projekte auf aktuelle File-Pfade – besonders relevant nach dem Umzug zu Mimir, das Dateien über Object-IDs und cloudbasierte Systeme verwaltet.
• Erweiterbarkeit mit helmut.cloud: Um Lücken bei cloud-nativen Integrationen zu schließen, wurde helmut.cloud eingeführt – zur Verarbeitung von Webhook-Events, Metadaten-Tagging und nachgelagerter Automatisierung. Beispiele:
  • Wenn Assets in Mimir getaggt wurden, erkannte helmut.cloud das Event und passte Titel an, damit sie in Premiere besser nutzbar sind.
  • Custom-Prozesse synchronisierten Titel-Metadaten systemübergreifend, ohne Original-Dateinamen zu verändern.
• Storage-Optimierung Vor Helmut4 lag das Team oft bei 80–90 % SAN-Auslastung. Durch Erkennen von Duplikaten, Tracking ungenutzter Assets und projektbasierte Archiv-Workflows reduzierte Helmut4 Storage-Verschwendung und verschob teure SAN-Erweiterungen nach hinten. „Früher sind sie einfach davon ausgegangen, dass sie mehr SAN brauchen. Jetzt sehen sie exakt, wo die Daten liegen, wem sie gehören und wie viel davon redundant ist.“
• Das Archiv-Puzzle: Von LTO zu Backblaze: Das Team ging zunächst davon aus, das LTO-Archiv enthalte über ein Petabyte. Faktisch enthielten jedoch nur 27 von 125 Tapes verwertbare Daten. Diese Erkenntnis ermöglichte eine Migration von ca. ~45 TB aus LTO in Cloud-Storage via S3-CLI – und vereinfachte die Infrastruktur drastisch.

Heute gilt:

• Sämtlicher Content wird beim Ingest via Mimir nach Backblaze archiviert.
• helmut.cloud triggert Purge-Prozesse und entfernt gelöschte MAM-Inhalte automatisch aus dem Archiv – zur Kostenkontrolle.
• SAN-Expansion wurde minimiert – dank besserer Workflow-Sichtbarkeit und Asset-Management.

Ausblick

Nachdem die Basis-Workflows stabil laufen, evaluiert das Team:

• Erweiterte Archivierungsoptionen via helmut.cloud (z. B. Push-to-LTO für Redundanz)
• Tiefere Integration Helmut ↔ Mimir für projektbasierte Asset-Restauration
• Template-getriebene Projektanlage für wiederkehrende Shows und Kampagnen

Warum Helmut4?

Im Gegensatz zu klassischen MAMs folgt Helmut4 einem Prinzip: Projekte sind zentral. Helmut4 versteht Adobe-Premiere-Projekte als First-Class Citizens, trackt Assets auf Projektebene und schließt die Lücke zwischen Editorial-Anforderungen und IT-Infrastruktur.

„Tempo ist bei unserem leistungsstärksten Content der entscheidende Faktor – je schneller wir veröffentlichen, desto mehr Reichweite, desto mehr Wirkung und desto mehr Umsatz. Mit über 80.000 Workflows pro Monat ermöglichen uns die optimierten Abläufe mit Helmut4 und helmut.cloud, dass unsere Editoren nahtlos zusammenarbeiten und mit dem Tempo der Story arbeiten: Wir liefern aus, solange der Content noch frisch, relevant und packend ist.“

Stacy Kelleher, Produktionsleitung, Philadelphia Eagles