VidStudio – kostenloser Online-Video-Resizer und -Editor

• Ein Video-Editor, der im Browser ohne Dateiupload verarbeitet wird und Multitrack-Bearbeitung, Navigation auf Frame-Ebene sowie einen Source-Monitor bietet
• Basierend auf FFmpeg WASM und WebCodecs, sodass die gesamte Verarbeitung im Browser selbst erfolgt
• Bietet zentrale Video-Tools wie Größenanpassung, Skalierung, Zuschneiden, Schnittbearbeitung, Komprimierung, Thumbnail-Erstellung und Wasserzeichen
• Unterstützt Audioverarbeitung sowie Untertitel- und Textfunktionen und bietet Konvertierung von MP4·MOV·WebM·MKV·AVI in MP3·WAV·AAC·M4A·FLAC
• Ein webbasiertes Bearbeitungstool mit Komprimierungs-Presets für Discord, Email, WhatsApp, Slack und Twitter sowie Resize-Presets für TikTok, Instagram Reels und YouTube Shorts

---

Video-Editor

• Multitrack-Bearbeitung, Verarbeitung auf Basis von WebCodecs, Navigation auf Frame-Ebene und Source-Monitor
• Enthält die Funktion New Project
• Bietet Videobearbeitung direkt im Browser

Zentrale Verarbeitungsweise

• Basierend auf FFmpeg WASM
• Die gesamte Verarbeitung erfolgt innerhalb des Browsers

Video-Tools

• Resize & Scale

  • Bietet Funktionen zur Größenanpassung und Skalierung von Videos

• Trim & Cut

  • Bietet Funktionen zum Zuschneiden und zur Schnittbearbeitung von Videos

• Compress

  • Bietet Videokomprimierung

• Drop Zone

  • Bietet das Tool Drop Zone

• Thumbnails

  • Bietet die Erstellung von Thumbnails

• Watermark

  • Bietet eine Wasserzeichen-Funktion

Audio und Zusatzfunktionen

• Audio Processing

  • Bietet Audioverarbeitung

• Subtitles & Text

  • Bietet Untertitel- und Textfunktionen

Plattformbezogene Komprimierung

• Compress for Discord

  • Bietet Videokomprimierung für Discord

• Compress for Email

  • Bietet Videokomprimierung für Email

• Compress for WhatsApp

  • Bietet Videokomprimierung für WhatsApp

• Compress for iMessage

  • Bietet Videokomprimierung für iMessage

• Compress for Slack

  • Bietet Videokomprimierung für Slack

• Compress for Twitter

  • Bietet Videokomprimierung für Twitter

Plattformbezogene Größenanpassung

• Resize for TikTok

  • Bietet Video-Größenanpassung für TikTok

• Resize for Instagram Reels

  • Bietet Video-Größenanpassung für Instagram Reels

• Resize for YouTube Shorts

  • Bietet Video-Größenanpassung für YouTube Shorts

• Resize for Instagram Post

  • Bietet Video-Größenanpassung für Instagram Post

• Resize for LinkedIn

  • Bietet Video-Größenanpassung für LinkedIn

• Resize for Facebook

  • Bietet Video-Größenanpassung für Facebook

• Resize for Twitter

  • Bietet Video-Größenanpassung für Twitter

• Resize for Pinterest

  • Bietet Video-Größenanpassung für Pinterest

Audioformat-Konvertierung

• MP4 to MP3

  • Bietet die Konvertierung von MP4 zu MP3

• MOV to MP3

  • Bietet die Konvertierung von MOV zu MP3

• WebM to MP3

  • Bietet die Konvertierung von WebM zu MP3

• MKV to MP3

  • Bietet die Konvertierung von MKV zu MP3

• AVI to MP3

  • Bietet die Konvertierung von AVI zu MP3

• MP4 to WAV

  • Bietet die Konvertierung von MP4 zu WAV

• MP4 to AAC

  • Bietet die Konvertierung von MP4 zu AAC

• MP4 to M4A

  • Bietet die Konvertierung von MP4 zu M4A

Video in Audio konvertieren

• Video to MP3

  • Bietet die Konvertierung von Video zu MP3

• Video to WAV

  • Bietet die Konvertierung von Video zu WAV

• Video to FLAC

  • Bietet die Konvertierung von Video zu FLAC

• Video to AAC

  • Bietet die Konvertierung von Video zu AAC

[GN⁺]

Hacker-News-Kommentare

• Selbst wenn FFmpeg über WebAssembly läuft, bleiben die Lizenzprobleme meiner Ansicht nach bestehen. FFmpeg steht unter LGPL 2.1, aber VidStudio wirkt wie closed source, und ich konnte auch keinen Hinweis darauf finden, dass es freie Software ist. Wenn es in einer Form an den Client-Browser ausgeliefert wird, könnte das gegen die LGPL-Bedingungen verstoßen. Die FFmpeg-Legal-Seite ist dazu ebenfalls lesenswert

  • Closed source an sich ist möglich, aber soweit ich weiß, stellt die LGPL zusätzliche Anforderungen. Zum Beispiel müsste man einen Link zum Quellcode der verwendeten FFmpeg-Version bereitstellen, bei dynamischem Linking müsste der Nutzer die Bibliothek durch seinen eigenen Build ersetzen können, und bei statischem Linking müsste man Werkzeuge bereitstellen, mit denen ein erneutes Linken mit einem kompatiblen Build möglich ist. Ich habe die LGPL erst kürzlich noch einmal durchgesehen, deshalb ist mir das noch präsent, aber korrigiert mich gern, falls ich falsch liege
  • Danke für den Hinweis, ehrlich gesagt hatte ich über Licensing anfangs nicht besonders tief nachgedacht. Ursprünglich war das nur eine Experimentier-Toolbox für Video- und Audio-Codecs, die lokal laufen sollte, aber später schien sie auch für andere nützlich genug, um sie zu veröffentlichen. Ich werde noch heute Nacht die nötigen Änderungen vornehmen, damit alles vollständig konform ist. Immerhin habe ich FFmpeg korrekt geschrieben, und wegen des wasm-Projekts habe ich auch gemerkt, dass ich den Unterschied zwischen GPL und LGPL noch besser verstehen muss
  • Ich denke, LGPL-Compliance ist auch möglich, ohne den kompletten Quellcode der App offenzulegen. Zum Beispiel könnte man die Anwendung und ffmpeg in getrennten Isolates, also separaten wasm-Prozessen, laufen lassen oder eine Möglichkeit anbieten, einen vom Nutzer selbst kompilierten FFmpeg-wasm-Build mit dem closed-source App-wasm-Code zu kombinieren. Ob allein die Trennung in Isolates auch schon für die GPL reichen würde, ließe sich vielleicht ähnlich bewerten wie ein Aufruf von FFmpeg als Kommandozeilen-Tool, aber rechtlich wirkt das auf mich etwas heikel
  • Die LGPL erlaubt für sich genommen die Nutzung der Bibliothek in proprietärer Software
  • Allerdings stehen einige beliebte Codecs unter GPL, und wenn man diese Optionen aktiviert, könnte es sein, dass auch der restliche Code unter GPL veröffentlicht werden muss

• Die Performance war wirklich beeindruckend, und auch der Zustand blieb sehr natürlich erhalten. Browserbasierte Videoeditoren, die ich früher ausprobiert habe, fingen schnell an zu ruckeln, daher hat es mich überrascht, wie gut das hier durchhält. Mit den Tracks gab es aber Probleme: Unter Firefox auf Windows konnte ich die Reihenfolge per Drag-and-drop nicht ändern. Außerdem konnte ich keine Transform-Tools finden, etwa für Position, Rotation oder Skalierung, um Videos mit unterschiedlichen Seitenverhältnissen wie Hoch- und Querformat aneinander anzupassen

  • Danke für die Unterstützung, die Track-Bearbeitung habe ich noch nicht vollständig gelöst. Deshalb kann man Clips derzeit noch nicht zwischen Tracks verschieben, und an eine Änderung der Track-Reihenfolge habe ich noch gar nicht gedacht, aber ich schaue es mir an. Die Transform-Funktionen sollten erscheinen, wenn man einen Clip auf einen Track legt und dann anklickt; rechts neben dem Programmmonitor müsste ein Panel sichtbar werden. Die Optionen sind zwar begrenzt, aber ein bisschen ist schon vorhanden. Ehrlich gesagt fühlt es sich stellenweise auch so an, als hätte ich es mit Hilfe eines LLM gerade noch zusammenbekommen

• Die oben erwähnten hvc1- und 10-bit-Fehler sind meiner Meinung nach kein FFmpeg-wasm-Fallback-Problem, sondern ein Unterschied bei der Browser-Unterstützung für WebCodecs. Der HEVC-Pfad in Firefox ist nur teilweise vorhanden, und 10-bit ist noch anfälliger. In Chrome funktioniert es meistens, aber Firefox scheitert genau bei Dateien, wie sie iPhones oder aktuelle Android-Geräte standardmäßig aufnehmen. Um bei Importtests weniger Nutzer zu verlieren, wäre es wohl gut, darauf hinzuweisen, dass der Browser diesen Codec nicht dekodieren kann, und vorzuschlagen, Chrome zu verwenden

  • Das ist ein guter Vorschlag. Wenn ich die Licensing-Probleme hinter mir habe, wartet ohnehin noch ein Berg von Fehlern auf mich. Wenn ich die abarbeite, dürfte die Nutzbarkeit deutlich besser werden

• Mich würde interessieren, wie sich das im Vergleich zu https://omniclip.app/, https://tooscut.app und https://clipjs.mohy.dev/ schlägt

  • Ich war auch neugierig auf einen Vergleich mit https://pikimov.com. Das scheint noch ein weiterer browserbasierter Videoeditor zu sein, der in letzter Zeit öfter auftaucht
  • Ehrlich gesagt weiß ich das noch nicht, und die genannten Dienste waren mir neu. Ich werde sie selbst ausprobieren und vergleichen, danke für die Hinweise

• Früher war eine App komplett lokal ausgerichtet, ohne Konto und ohne Uploads, und jetzt ist genau das wieder ein interessantes Wertversprechen — das finde ich bemerkenswert

  • Diesmal gibt es zudem den Unterschied einer sandboxed Umgebung, und wer mit greasemonkey-Skripten umgehen kann, kann sie bis zu einem gewissen Grad auch anpassen. Außerdem gefällt mir, dass der gesamte Text in der App auswählbar ist und man alles kopieren und einfügen kann
  • Ich stimme zu, aber wer Geld in Softwareentwicklung steckt, muss letztlich einen Weg zur Monetarisierung finden. Ich hoffe nur, dass die Methoden nicht zu ausbeuterisch werden. Inzwischen wird alles zum Abo, und es fühlt sich oft so an, als würde Nutzern jeden Monat erneut Geld aus der Tasche gezogen
  • Im Unterschied zu früheren Apps sind solche Dinge heute allerdings keine echten OS-nativen Apps mehr

• Glückwunsch zum Launch. Ich bin mit videotobe.com einen ähnlichen Weg gegangen und habe mit ffmpeg.wasm eine vollständig clientseitige Architektur versucht, aber bei langen Videos ist das kollabiert. Wegen Speichergrenzen und Encoding-Zeiten bin ich am Ende zu einer Cloud-Verarbeitungspipeline gewechselt. Hier scheint ihr diese beiden Probleme aber mit der Aufteilung auf WebCodecs, Pixi und ffmpeg.wasm gut gelöst zu haben, und dass VidStudio sogar Medien mit über 3 Stunden Laufzeit durchhält, fand ich beeindruckend

  • Solche Erfahrungsberichte freue ich mich wirklich sehr und danke dir dafür. In letzter Zeit war ich wegen der Fehler, die sich in Sentry ansammeln, etwas demotiviert, daher hat mich das aufgemuntert. Ich habe ffmpeg wasm auch bis zum Ende ausgereizt und sogar versucht, die Speicherprobleme mit worker fs zu lösen, aber ich hatte das Gefühl, dass der Ertrag den Aufwand nicht rechtfertigt. Die Video-Codecs selbst sind großartig, aber mir wurde klar, dass ich unterschätzt hatte, wie viel ffmpeg einem bei der gesamten Decode-Transform-Encode-Pipeline abnimmt

• Es ist erstaunlich, dass Datenschutz nicht mehr der Standard ist, sondern wie ein Feature behandelt wird. Ich baue selbst in diesem Bereich, und ich habe das Gefühl, dass der Vorteil, nichts hochladen zu müssen, für Nutzer, die bereits daran gewöhnt sind, dass alles in der Cloud sein muss, überraschend schwer zu vermitteln ist

  • Ich glaube eher, dass die meisten Nutzer ihre Daten tatsächlich in der Cloud haben wollen. Wenn man am Desktop bearbeitet und einen Link verschickt, kann der Kunde es sofort auf dem Handy ansehen; man muss nichts extra exportieren, und Änderungen sind direkt sichtbar. Selbst außerhalb des Business-Kontexts, etwa wenn Familien Videos teilen, Feedback geben und sofort weiterbearbeiten, ist das ein klarer Vorteil. Das heißt nicht, dass lokal-only Lösungen keinen Platz hätten, aber ich vermute, dass die Cloud-Vorteile für die meisten Nutzer attraktiver sind
  • Das stimmt, aber wenn man zugleich bedenkt, dass die erfolgreichsten Geschäftsmodelle auf dem Verkauf persönlicher Daten beruhen, wirkt diese Entwicklung leider auch allzu logisch

• Die Idee eines Tools, das lokal im Browser läuft, hat mich sofort angesprochen. Die Website ist dann im Grunde nur noch das Verteilmedium, was die Nutzung sehr einfach macht, und ich brauchte ohnehin so ein Tool, deshalb habe ich es mit viel Erwartung getestet. Leider sind sowohl der erste als auch der zweite Versuch gescheitert. Mit einem auf einem Pixel-Telefon aufgenommenen Video bekam ich in Firefox die Meldung "Your browser does not support the codec "hvc1.2.4.L156". Try a different video.", also bin ich zu Chrome gewechselt und bekam dort "Audio decode failed: your browser cannot decode the audio in "..._webm.bin". Try re-encoding the file with AAC audio.". Schade, aber ich hoffe sehr, dass es behoben wird. Es wäre auch schön, wenn es eine Möglichkeit gäbe, benachrichtigt zu werden, sobald es gefixt ist

  • Das steht bereits auf meiner Todo-Liste, und wenn es behoben ist, komme ich hierher zurück und sage Bescheid. Das Kernproblem ist, dass die Codec-Unterstützung sehr inkonsistent ist, und auch die Muxer-Software, die ich mir angesehen habe, hatte bei der Codec-Unterstützung Lücken. Dazu kommt, dass Audio- und Video-Codec-Namen je nach Plattform und Browser unterschiedlich angezeigt werden, was es komplizierter macht als erwartet. Ich werde mich so schnell wie möglich wieder tief hineingraben

• Für das Scrubbing auf der Timeline war WebCodecs meiner Meinung nach die richtige Wahl. Ich frage mich aber, wie das Frame-Caching gehandhabt wird. Die Decoder-Buffer von WebCodecs sind memory-mapped und können vom Browser bei Speicherdruck freigegeben werden. Mich würde interessieren, ob ihr darüber noch einen eigenen LRU-Cache gelegt habt oder ob ihr das komplett dem Decoder überlasst. Spannend fände ich auch, wie ihr auf mobilen Geräten, vor allem auf iPhones mit ihren strengen Speicherlimits, verhindert, dass die Seite wegen der Hintergrund-Speichernutzung von WebCodecs abstürzt

• Die compress-to-X-Links unten und die Tools zum Konvertieren von X nach Y haben mir wirklich gefallen. Besonders gut fand ich das Tool mit Presets für Ziel-Dateigrößen je nach Discord-Abo-Stufe. Bisher habe ich dafür serverbasierte Online-Tools genutzt, bei denen man hochladen muss, aber künftig werde ich wohl dieses hier verwenden. Ich brauchte eigentlich gar keinen vollwertigen Videoeditor und habe nur aus Neugier hereingeschaut, aber es war trotzdem eine ziemlich coole Entdeckung