1 ポイント 投稿者 GN⁺ 7 일 전 | 1件のコメント | WhatsAppで共有
  • ブラウザ上でファイルをアップロードせずに処理できる動画エディタで、マルチトラック編集、フレーム単位のナビゲーション、ソースモニター機能を提供
  • FFmpeg WASMWebCodecsを基盤としており、すべての処理がブラウザ内部で行われる
  • 動画のリサイズ、スケール、トリミング、カット編集、圧縮、サムネイル生成、ウォーターマークといった主要な動画ツールを提供
  • オーディオ処理と字幕・テキスト機能をサポートし、MP4・MOV・WebM・MKV・AVI入力からMP3・WAV・AAC・M4A・FLACへの変換機能を提供
  • Discord、Email、WhatsApp、Slack、Twitter向けの圧縮プリセットと、TikTok、Instagram Reels、YouTube Shorts向けのリサイズプリセットをあわせて提供するWebベースの編集ツール

動画エディタ

  • マルチトラック編集WebCodecsベースの処理、フレーム単位のナビゲーション、ソースモニターを提供
  • New Project作成機能を含む
  • ブラウザ内で動画編集機能を提供

主な処理方式

  • FFmpeg WASMベースの構成
  • すべての処理がブラウザ内部で行われる

動画ツール

  • Resize & Scale

    • 動画のリサイズとスケール機能を提供
  • Trim & Cut

    • 動画のトリミングおよびカット編集機能を提供
  • Compress

    • 動画圧縮機能を提供
  • Drop Zone

    • Drop Zoneツールを提供
  • Thumbnails

    • サムネイル生成機能を提供
  • Watermark

    • ウォーターマーク機能を提供

オーディオおよび追加機能

  • Audio Processing

    • オーディオ処理機能を提供
  • Subtitles & Text

    • 字幕およびテキスト機能を提供

プラットフォーム別圧縮

  • Compress for Discord

    • Discord向けの動画圧縮機能を提供
  • Compress for Email

    • Email向けの動画圧縮機能を提供
  • Compress for WhatsApp

    • WhatsApp向けの動画圧縮機能を提供
  • Compress for iMessage

    • iMessage向けの動画圧縮機能を提供
  • Compress for Slack

    • Slack向けの動画圧縮機能を提供
  • Compress for Twitter

    • Twitter向けの動画圧縮機能を提供

プラットフォーム別リサイズ

  • Resize for TikTok

    • TikTok向けの動画リサイズ機能を提供
  • Resize for Instagram Reels

    • Instagram Reels向けの動画リサイズ機能を提供
  • Resize for YouTube Shorts

    • YouTube Shorts向けの動画リサイズ機能を提供
  • Resize for Instagram Post

    • Instagram Post向けの動画リサイズ機能を提供
  • Resize for LinkedIn

    • LinkedIn向けの動画リサイズ機能を提供
  • Resize for Facebook

    • Facebook向けの動画リサイズ機能を提供
  • Resize for Twitter

    • Twitter向けの動画リサイズ機能を提供
  • Resize for Pinterest

    • Pinterest向けの動画リサイズ機能を提供

オーディオ形式変換

  • MP4 to MP3

    • MP4をMP3に変換する機能を提供
  • MOV to MP3

    • MOVをMP3に変換する機能を提供
  • WebM to MP3

    • WebMをMP3に変換する機能を提供
  • MKV to MP3

    • MKVをMP3に変換する機能を提供
  • AVI to MP3

    • AVIをMP3に変換する機能を提供
  • MP4 to WAV

    • MP4をWAVに変換する機能を提供
  • MP4 to AAC

    • MP4をAACに変換する機能を提供
  • MP4 to M4A

    • MP4をM4Aに変換する機能を提供

動画をオーディオに変換

  • Video to MP3

    • 動画をMP3に変換する機能を提供
  • Video to WAV

    • 動画をWAVに変換する機能を提供
  • Video to FLAC

    • 動画をFLACに変換する機能を提供
  • Video to AAC

    • 動画をAACに変換する機能を提供

1件のコメント

 
GN⁺ 7 일 전
Hacker Newsのコメント
  • FFmpegをWebAssemblyで動かすとしても、ライセンス上の問題はそのままだと思う。FFmpegはLGPL 2.1で、VidStudioはclosed sourceのように見えるし、自由ソフトウェアだという案内も見当たらなかった。クライアントのブラウザに配布する形なら、LGPLの条件に違反している可能性がありそうで、FFmpeg legalページも参考になると思う

    • closed source自体は可能だけれど、LGPLで追加で求められることがあると記憶している。たとえば、使用したFFmpegのバージョンのソースへのリンクを提供すること、動的リンクならユーザーが自分でビルドしたライブラリに差し替えられる必要があること、静的リンクなら互換ビルドで再リンクできるツールを提供すること、という理解。最近LGPLを見直したばかりなので記憶は鮮明だけれど、間違っていたら訂正歓迎
    • 指摘してくれてありがとう。正直に言うと、最初はlicensingを深く考えていなかった。もともとはローカルで動かすために作った動画・音声コーデックの実験用ツール集だったけれど、その後ほかの人も使えるレベルだと気づいて公開した。今夜中に、完全準拠になるよう必要な変更を入れるつもり。少なくともFFmpegの綴りをちゃんと書けたのはよかったし、wasmプロジェクトの件もあってGPLとLGPLの違いをもっと勉強しないといけないと感じた
    • アプリ全体のソースを公開しなくても、LGPL準拠は可能だと思う。たとえば、アプリケーションとffmpegを別々のisolate、つまりwasmプロセスとして分離して動かすとか、ユーザーが自分でコンパイルしたFFmpeg wasmビルドとクローズドソースのアプリwasmコードを組み合わせられる方法を提供する、といったやり方はありそう。isolateの分離だけでGPLまで満たせるかは、FFmpegをコマンドラインツールとして呼び出す場合に近いと見なせるかもしれないけれど、そのあたりは法的にはやや危うい気がする
    • LGPLは、それ自体としては非公開ソフトウェアでのライブラリ利用を許可している
    • ただし、人気のある一部のコーデックはGPLなので、そのオプションを有効にすると残りのコードもGPLで配布しなければならない可能性がある
  • パフォーマンスは本当に印象的で、状態保持もとても自然に感じた。以前ブラウザベースの動画エディタを使ったときはすぐに重くなったけれど、これはかなり持ちこたえていて驚いた。ただ、トラック周りはうまくいかず、Firefox on Windowsではドラッグ&ドロップで順序を変えられなかった。縦横比の違う動画、たとえば縦動画と横動画を合わせるための位置・回転・サイズのようなtransformツールも見つけられなかった

    • 応援ありがとう。track操作はまだ完全には解決できていない。なので今のところ、クリップをトラック間で移動できないし、トラック順の変更も考え切れていなかったけれど確認してみる。transformは、クリップをトラックに置いてからクリックすると、プログラムモニターの右側にパネルが表示されるはずで、オプションは限られているけれど一応入っている。正直、LLMの助けを借りてなんとか組み上げた部分でもあると感じている
  • 上で出ていたhvc1と10-bitの失敗は、FFmpeg-wasmのフォールバックの問題ではなく、WebCodecsのブラウザ対応の差だと思う。FirefoxのHEVC経路は部分的で、10-bitはさらに弱い。Chromeはだいたい動くけれど、FirefoxはiPhoneや最近のAndroidが標準で撮るファイルでまさに失敗する。だから、インポート時の離脱を減らすには、ブラウザがこのコーデックをデコードできないことと、Chromeを試してほしいことを案内するとよいと思う

    • いい提案だと思う。licensingの問題を片づけたあとにも、解決すべきエラーが山ほどあるので、それを処理すれば使い勝手はかなり良くなるはず
  • これがhttps://omniclip.app/https://tooscut.apphttps://clipjs.mohy.dev/と比べてどうなのか気になる

    • 自分はhttps://pikimov.comとの比較も気になった。最近よく見かける別のブラウザベース動画エディタだと思う
    • 正直まだわからないし、共有してくれたサービスは初めて知った。実際に使って比較してみる。教えてくれてありがとう
  • 以前はアプリが完全にローカル中心で、アカウントもアップロードもなかったのに、今ではそういう点自体が価値提案になっているのが興味深い

    • 今回はsandboxed環境という違いもあるし、greasemonkeyスクリプトを扱えるならある程度改変もできる。それに、アプリ内のテキストがすべて選択可能で、コピー&ペーストもできるのがいいと感じる
    • 自分も同意するけれど、ソフトウェア開発にお金をかける側は、結局収益化の方法を見つけないといけないと思う。ただ、そのやり方があまりに搾取的でないことを願いたい。最近は何でもサブスクリプションになっていて、毎月ユーザーからお金を吸い上げる感じが強い
    • ただ、昔のアプリと違って、今こういうものは実際にはOSネイティブアプリではない、という違いはあると思う
  • リリースおめでとう。自分もvideotobe.comで同じ道をたどったことがあって、ffmpeg.wasmで完全クライアントサイド構成を試したけれど、長い動画では破綻した。メモリ制限とエンコード時間のせいで、結局クラウド処理パイプラインに移行した。けれど、ここではWebCodecs、Pixi、ffmpeg.wasmを分けた構成で、その2つの問題をうまく解いているように見えたし、実際3時間超のメディアでもVidStudioが耐えていたのは印象的だった

    • こういう経験の共有は本当にありがたい。最近はsentryに溜まったエラーのせいで少し意欲低下していたので励みになった。自分もffmpeg wasmを最後まで押し通して、worker fsでメモリ問題まで解こうとしたけれど、労力の割に見返りが大きくないと感じた。動画コーデック自体はすごいけれど、ffmpegがデコード・変換・エンコードのパイプラインをどれほど多く肩代わりしてくれているかを自分は過小評価していたと気づいた
  • プライバシーがデフォルトではなく機能の一つとして扱われる時代になったことに驚く。自分もこの分野で作っているけれど、アップロード不要という利点は、すでに何でもクラウドにあるべきだと学習してしまったユーザーには意外と伝わりにくいと感じる

    • 自分はむしろ、大多数のユーザーはクラウドにデータがあることを望んでいると思う。デスクトップで編集してリンクを送れば、クライアントがスマホですぐ見られて、別途exportも不要で、修正すれば即座に反映される流れは明らかに便利。ビジネス用途でなくても、家族で動画を共有してフィードバックし、その場で直すような使い方にも強みがあると思う。ローカル専用ソリューションに用途がないという意味ではなくて、大半のユーザーにとってはクラウドの利点のほうが魅力的だろうと推測している
    • その通りだけれど、同時に最も成功しているビジネスモデルが個人データの販売に依存していることを考えると、こうした流れもあまりに筋が通っているように感じる
  • ブラウザでローカル実行されるツールという発想にはとても惹かれた。ウェブサイトが実質的に配布媒体の役割しかしないので使いやすく、自分もこういうツールが必要だったので期待して試した。けれど、1回目も2回目も失敗した。Pixelのスマホで撮った動画を入れたところ、Firefoxでは"Your browser does not support the codec "hvc1.2.4.L156". Try a different video."というメッセージが出て、そこでChromeに移ったら、今度は"Audio decode failed: your browser cannot decode the audio in "..._webm.bin". Try re-encoding the file with AAC audio."が出た。残念だったけれど、ぜひ解決してほしいし、直ったら通知を受け取れる方法があるとよいと思う

    • これは自分のtodo listに入っていて、直ったらここに戻って必ず知らせる。核心の問題はコーデック対応にばらつきがあることで、自分が見てきたmuxerソフトウェアもコーデック対応に穴が多かった。それに、音声と動画のコーデック名がプラットフォームやブラウザによって違って見えることもあって、予想以上に複雑だった。できるだけ早くまた掘り下げるつもり
  • タイムラインスクラブにWebCodecsを使ったのは正しい選択だと思う。ただ、フレームキャッシュをどう処理しているのか気になる。WebCodecsのデコーダバッファはメモリマップされていて、圧力がかかるとブラウザが回収できるけれど、その上に独自のLRUキャッシュを載せているのか、それともデコーダに任せているのか知りたい。モバイル、特にiPhoneのようにメモリ制限が厳しい端末で、バックグラウンドのWebCodecsメモリ使用のせいでページが落ちる問題をどうしのいでいるのかにも興味がある

  • 下部のcompress-to-Xリンク群や、XからYへの変換ツール群が本当に気に入った。特に、Discordのサブスク段階ごとの目標ファイルサイズのプリセットがあるツールが良かった。これまではアップロード必須のサーバーベースのオンラインツールを使っていたけれど、これからはこっちを使うことになりそう。今すぐフル機能の動画エディタが必要だったわけではなく、ただ面白半分で見ていただけなのに、かなり良い発見だったと感じた