Kurmann Videoschnitt ist eine leistungsstarke Anwendung, die sich auf die Automatisierung und Verwaltung von Videoschnittprozessen konzentriert. Diese Anwendung zielt darauf ab, die Effizienz und Produktivität zu steigern, indem verschiedene Aufgaben im Videoschnitt automatisiert und optimiert werden.
Verstanden, hier ist die angepasste Version ohne die Übersetzungen:
Ein Medienset besteht aus einer Gruppe von Dateien desselben Mastervideos. Zum Beispiel ein Videoschnitt einer Wanderung auf den Pilatus. Ein Medienset enthält Dateien für unterschiedliche Einsatzzwecke und darunter auch Bereitstellungsvarianten. Ein Medienset besteht gewöhnlich aus:
Aktuell sind diese zwei Bereitstellungsvarianten vorgesehen:
Die folgenden Hauptfunktionen gelten als Ziele der Anwendung und sind derzeit in Entwicklung. Weitere Funktionen können hinzugefügt oder entfernt werden:
Videoschnitt verwendet die Kurmann.Videoschnitt.Engine als Kernmodul und erweitert diese durch spezialisierte Automatisierungsdienste. Diese Dienste sind als separate Module implementiert und kommunizieren über die zentrale Engine.
Das Docker-Image ist auf Docker Hub verfügbar. Um das Image zu erstellen und auszuführen, verwenden Sie die folgenden Befehle:
docker pull kurmann/videoschnitt
docker run -d kurmann/videoschnitt
Um das Image lokal zu erstellen und auszuführen, verwenden Sie diese Befehle:
docker build -t kurmann/videoschnitt .
docker run -d kurmann/videoschnitt
Ein Docker Compose-File wird angeboten, um die Anwendung noch einfacher zu starten. Speichern Sie das folgende Compose-File als docker-compose.yml
:
services:
videoschnitt:
image: kurmann/videoschnitt:latest
container_name: videoschnitt
volumes:
- logs:/app/logs
environment:
- ASPNETCORE_ENVIRONMENT=Production
volumes:
logs:
Um die Anwendung mit Docker Compose zu starten, verwenden Sie den folgenden Befehl:
docker-compose up -d
Die Überwachung der Anwendung erfolgt vorzugsweise über Docker-Logs:
docker logs -f videoschnitt
Kurmann Videoschnitt nutzt Docker, um eine konsistente und isolierte Umgebung für die Ausführung der Anwendung bereitzustellen. In diesem Abschnitt wird erläutert, wie Sie Volumes und Bind Mounts konfigurieren können, um lokale Verzeichnisse auf Ihrem Host-System, wie z.B. einem Synology NAS, in den Docker-Container einzubinden. Diese Mechanismen ermöglichen es, externe Verzeichnisse in den Container zu mappen, sodass Ihre .NET-Anwendung darauf zugreifen und diese überwachen kann.
Volumes:
Bind Mounts:
Die folgende docker-compose.yml
Datei zeigt, wie Volumes und Bind Mounts verwendet werden können, um Verzeichnisse vom Host-System in den Docker-Container zu integrieren.
version: '3.8'
services:
videoschnitt:
image: kurmann/videoschnitt:latest
container_name: videoschnitt
volumes:
- /path/to/media/library:/app/media # Bind Mount
- videoschnitt-config:/app/config # Docker Volume
environment:
- LocalMediaLibrary__LibraryPath=/app/media
Alternativ können Volume-Mounts und Bind Mounts direkt beim Starten des Containers mit dem Docker Run-Befehl festgelegt werden:
docker run -d \
-v /path/to/media/library:/app/media \
-v videoschnitt-config:/app/config \
-e LocalMediaLibrary__LibraryPath=/app/media \
--name videoschnitt \
kurmann/videoschnitt:latest
Die .NET-Anwendung im Container kann über Umgebungsvariablen konfiguriert werden. Diese Variablen können im Docker Compose-File oder direkt im Docker Run-Befehl gesetzt werden. Beispiel:
environment:
- LocalMediaLibrary__LibraryPath=/app/media
-e LocalMediaLibrary__LibraryPath=/app/media
Diese Variablen werden von der Anwendung ausgelesen, um Pfade und andere Konfigurationen zu definieren.
Aktuell wird nur der Library Path
als Konfigurationswert unterstützt. Die Liste der unterstützten Konfigurationswerte wird noch erweitert.
Bei der Zuweisung eines Verzeichnisses, das von der Anwendung überwacht werden soll, muss der Pfad angegeben werden, wie er innerhalb des Containers sichtbar ist. Beispiel:
/path/to/media/library
/app/media
Die Umgebungsvariable würde dann auf den Pfad innerhalb des Containers gesetzt werden:
environment:
- LocalMediaLibrary__LibraryPath=/app/media
Die Kurmann.Videoschnitt.Engine
und andere direkt oder indirekt integrierte Module müssen zwingend im Benutzerverzeichnis arbeiten. Dies hat folgende Gründe und Vorteile:
Hier ist ein Beispiel, wie Ihre .NET-Anwendung den LibraryPath
aus der Umgebungsvariablen lesen und verwenden kann:
string libraryPath = Environment.GetEnvironmentVariable("LocalMediaLibrary__LibraryPath");
if (!string.IsNullOrEmpty(libraryPath))
{
string fullLibraryPath = Path.Combine(libraryPath, "myFile.txt");
File.WriteAllLines(fullLibraryPath, myText);
}
else
{
// Fallback, falls die Umgebungsvariable nicht gesetzt ist
string defaultPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.UserProfile), "library", "myFile.txt");
File.WriteAllLines(defaultPath, myText);
}
Durch die Nutzung dieser Konfigurationsmechanismen wird sichergestellt, dass die Anwendung auf die notwendigen Verzeichnisse zugreifen und korrekt funktionieren kann, unabhängig davon, ob sie in einem Docker-Container oder auf einem Host-System wie einem Synology NAS läuft.
Um die Anwendung lokal zu installieren und zu starten, folgen Sie diesen Schritten:
git clone https://github.com/kurmann/videoschnitt.git
dotnet restore
dotnet run
Das Repository wurde als “videoschnitt” unter dem GitHub-Account “kurmann” erstellt. Diese Namenskonvention sorgt dafür, dass der Name des Docker-Images direkt aus dem Repository-Namen abgeleitet werden kann, was die Verwaltung und Nutzung des Images erleichtert. Innerhalb der Anwendung und bei der Erstellung von NuGet-Paketen wird die Punktnotation verwendet, wie es bei .NET-Projekten üblich ist, um eine klare Struktur und Namenskonvention zu gewährleisten.
Entscheid vom 18. Juni 2024
1. Nativer Betrieb auf macOS: Die Anwendung direkt auf macOS laufen zu lassen, ergibt mehr Sinn, da einige Aufgaben, wie die Videokomprimierung, direkt auf dem MacOS-System gelöst werden müssen. Dies ermöglicht eine bessere Integration mit dem Betriebssystem und nutzt die native Leistung des Mac Mini voll aus.
2. Fokus auf macOS: Der aktuelle Fokus liegt auf der Bereitstellung der Anwendung für macOS. Homebrew bietet eine benutzerfreundliche und weit verbreitete Lösung für die Verteilung von Software auf macOS, ohne die Notwendigkeit von Docker Containern. Dies vereinfacht die Installation und Verwaltung der Anwendung für Endbenutzer erheblich.
3. Vereinfachte Verteilung: Die Verteilung der Anwendung mit Homebrew anstelle von Docker Containern vereinfacht den gesamten Prozess erheblich. Mit Homebrew können Benutzer die Anwendung einfach installieren und aktualisieren, indem sie bekannte und bewährte Befehle verwenden. Dies reduziert den Aufwand für die Benutzer und stellt sicher, dass sie immer die neueste Version der Anwendung verwenden.
4. Unkontrolliertes Verhalten in DevContainers:
Es wurde festgestellt, dass die Anwendung in Visual Studio Code DevContainers teilweise unkontrolliert reagiert. Diese Instabilitäten treten insbesondere im Zusammenhang mit dem MetadataProcessor
auf. Auf einer nativen macOS-Docker-Instanz läuft die Anwendung hingegen stabil. Dies lässt Zweifel an der tatsächlichen Plattformunabhängigkeit von Docker Containern aufkommen und zeigt die Vorteile eines nativen Betriebs auf.
5. Konsistentes Benutzererlebnis: Die Bereitstellung der Anwendung über Homebrew sorgt für ein konsistentes Benutzererlebnis auf macOS. Benutzer sind bereits mit Homebrew vertraut und können die Anwendung nahtlos installieren und verwalten. Dies erhöht die Akzeptanz und Zufriedenheit der Benutzer.
6. Einfachere Wartung und Debugging: Der native Betrieb auf macOS vereinfacht die Wartung und das Debugging der Anwendung erheblich. Entwickler können direkt auf das Betriebssystem zugreifen, um Probleme zu diagnostizieren und zu beheben, ohne die zusätzliche Komplexität einer Container-Umgebung.
Durch den Wechsel von Docker Containern zu Homebrew kann die Anwendung effizienter betrieben und gewartet werden, während gleichzeitig die Benutzerfreundlichkeit und Stabilität verbessert werden.
Dieses Projekt ist unter der Apache-2.0-Lizenz lizenziert. Weitere Details sind in der Datei LICENSE im GitHub-Repository zu finden.
Falls Fragen bestehen oder Unterstützung benötigt wird, kann ein Issue im GitHub-Repository eröffnet werden.