Open Video Downloaderとは

GitHub公式: https://github.com/jely2002/youtube-dl-gui

Linux用のソフトとしてダウンローダーはいくつかあります。名前もそのままのVideoDownloader(linuxパッケージでは、video-downloader)は、1つのウィンドウで1つの動画や音声ファイルしか扱えません。とてもシンプルで2つ、3つとウィンドウを開いておけば並行してダウンロードできるわけですが、やや面倒くさいのは否めません。

そこで複数のアドレスをキュー登録しておいて一挙にダウンロードできるようにしたのが、Parabolicです。これであればウィンドウをいくつも開いておく必要はなく、1つのウィンドウで対応できます。
GNOME/libadwaita製で見た目がVideoDownloaderに近くシンプルです。クリップボードの監視機能があるので、こちらもダウンロードアドレスをコピーしてアプリの左上にある「追加」を押せば自動で追加していきます。つまりペーストは不要です。どんどん追加してどんどんダウンロードしていくので、同時ダウンロード数制限もありそれらを自分で設定できます。ダウンロード速度も設定できます。
flatpak install flathub org.nickvision.tubeconverter
Tartubeというのもあります。これはダウンロードする順番や最適化を細かく制御したい人向けで、yt-dlpのフル機能GUIです。複数URLを一括投入できるのが便利ですが、そんなにダウンロードするアドレスを集められるだろうかとも思うので、おそらくはプレイリストをうまくダウンロードする仕組みなんだろうなぁと思います。プレイリストやチャンネル丸ごとと言う人には便利かと思います。

と、まぁ色んなダウンローダーがあるわけですが、紹介したいのはOpen Video Downloaderというソフトです。以前紹介したGear Leverを使用して、AppImageファイルを管理するとより一層と便利に感じると思います。
Gear Lever、あるいは他のAppImage管理ソフトでも良いですが、実行権限を与えるだけで起動するようになります。
AppImageとは
ソフトを起動するために必要な本体、ライブラリ、アイコン、メタデータなどを全部まとめた配布方法です。Linuxでは実行権限を与えるだけでインストール不要で使用することができるようになります。
Gear Leverとは
AppImageを管理するためのソフトです。指定フォルダ(デフォルトでは ~/Applications)にまとめて管理でき、移動またはコピーも可能です。AppImageの更新の確認や適用もでき、古いバージョンを残すこともできます。ダウンロードしたファイルに問題があり起動できなくても古いバージョンが残せるので継続して使用ができるという仕組みです。更新機能はそういうバージョン検知機能が搭載されていればですが、GithubのリポジトリURLやダウンロードリンクを登録しておけばGear Lever経由で最新版の確認・取得も可能になります。 アップデート時に古いバージョンを上書きして消すか、そのまま残すこともできますのでまずは残してアップデートし不要なら後から古いバージョン捨てればよいかと思います。
実行できるようになったら、ディストリビューションのドックバーなどに登録もできるでしょうから、そこから起動すると簡単ですが、この速度が爆速なわけです。
Open Video Downloaderはクロスプラットフォームで、Windows / macOS(Intel & Apple Silicon) / Linux(x64 & aarch64)に対応しています。
どんなPCとディストロを使用しているかにもよりますが、Thinkpad T470s + CachyOS + Hyprland(DankMaterialShell)では、Open.Video.Downloader_3.1.2_amd64.AppImage で動きました。リンクはGithubのリリースページへのリンクなので、自身の環境に合うもので試してみて下さい。
Open Video Downloaderの技術仕様
- フロントエンド: Vue3 + TypeScript + Tailwind CSSです
- バックエンド: Rust + Tauriで作られています
2025年11月に完全にRust + Tauriに書き換えられました。それまではElectron + jQueryで作られていましたが、V3で上記のフロントエンド、バックエンドに刷新されたおかげで爆速で起動するようになりました。
なぜ爆速で起動できるようになったかについては、Electronに問題があり、ElectronではChromiumを内包していて、表示をこれらが行っています。ブラウザを持ち歩くのと同じなので起動にも時間がかかる上に、メモリ使用量も、ファイルサイズも大きいわけですが、Tauriで置き換えた場合、バイナリサイズが1/10~1/100になり、起動は200ms以内、メモリ使用量が15~50MBと激減します。
Electronをディスっているように見えるかも知れませんが、Electronが登場したおかげでクロスプラットフォームでソフトが動作したり、あるいはソフトを作ることの敷居を下げたとも言えるので、ElectronがあったからこそTauriが生まれたとも言えるのではないかと思います。
Tauriの特徴
フロントエンドはそのままで開発できます。JavaScriptやTailwind CSS、TypeScriptなどいわゆるWebブラウザで動作するようなものが使用できます。
| 特徴 | Electron(従来型) | Tauri(新世代) |
|---|---|---|
| 描画エンジン | Chromiumを内包 | OS標準のWebViewを利用 |
| バックエンド | node.js | Rust |
| 起動速度 | 数秒~ | 200ms以内 |
| メモリ使用量 | 数百MB | 15~50MB |
他はまぁどうでも良いですが、一応書いておくと、
- ダウンロードエンジン: yt-dlp
- 1000以上のサイト対応(YouTube、X(Twitter)、Instagram、TikTokなどほぼ全部)
- TauriはOS標準のセキュアなストレージ(キーチェーン)との連携でCookie/パスワードを安全保持
- Tauri自体がOSのキーチェーン(LinuxならSecret Service/gnome-keyring、WindowsならCredential Manager等)にアクセスする機能を持っています
- 署名付き自動更新(Gear Lever使う時は設定で切っておいても良いかも知れません)
- バックグラウンド処理がRustで最適化されているので、同時ダウンロードの安定性が高い
- クリップボード自動検知があり、動画アドレスをコピーした瞬間にダウンロードリンク欄に自動入力される(設定でon/off可能)
- D&D対応で、URLやテキストファイルもOK(と言う話)((複数アドレスを書いて改行したテキストは読み込めましたが、何かしら問題があるらしくキュー登録は不可でした))
- 要注意)色々検証しましたがYoutubeでプレイリストのアドレスを登録してadd、リストから個別にキュー登録することは可能でした。しかし、自身で作成した動画アドレス改行区切り一覧を一挙にキュー登録はできませんでした。現状は今後のアップデートで機能することを期待と言う感じです。
- 擁護をするなら
url1,url2,url3...と区切られたアドレスをまとめてキューに登録ができないということはまずないはずなので、おそらくは各個人で書いたアドレスは微妙に正しくなかったり(個別動画の中にプレイリストが混じっていたりなど)、整形できないエッジケースがあって、キュー登録だけではなく他にも影響を及ぼすなどで一時保留(ペンディング)されているのではないかと。
- 同時ダウンロード数最大で32本(設定で制限可能)
- スマートキューリングで、PCのCPU/ディスク/ネットワーク負荷を監視しながら並行実行
- どこまで可能かは試してないのでわからないですが、たくさん同時に処理をしてPCが重くなる問題を回避しています
- 一時停止・再開がV3.1.2で強化
- 音声/動画ファイルで別フォルダに振り分けが可能(細かくはできない)
- 画質/音質プリセットは Best / 1080p / 720p / MP3 など
- MP4 / MKV / WebM / FLAC / WAV などのフォーマットに対応
このような機能があるとされていますが、どこまでできるのかは不明です。しかしGithubを見ると問題点などは報告されているので作者側も知っていて、今後改善されていくと思います。
アプリ体験レポート
実際にOpen Video Downloaderを使用して、キューに複数登録、同時ダウンロード(2本設定)してみましたが、動画のマージ(FFmpeg結合)時にCPU使用率が跳ね上がり、ファンがかなり唸るレベルになりました。通常のVideoDownloaderで2ウィンドウ並行より明らかに負荷が高い印象です。マージが発生していないところでも案外ファンガ回っている印象でした。
2ウィンドウでVideoDownloaderを使用した場合、1本が終われば次のアドレス登録まで時間がかかるので、その間にもう1本のダウンロードが進み、同時にダウンロードが終わるということは稀なため負荷は減るのだろうとも思います。
速度自体はネットワークが同じなため、アプリのクリップボード監視などの恩恵で手間が減り、1.2〜1.5倍程度速くなりますが、yt-dlpベースなので純粋に「ダウンロード速度が速くなる」わけではなく、使い勝手の向上が本質です。
おそらくですが、アプリ自体の起動は速くなったけれども、内部処理がまだ完全には最適化されていないのではないかと思います。
Linux特有の機能としては
- Pythonのインストールは不要(yt-dlpは内蔵されていて、必要なら自動でダウンロードされる)
- AppImageが一番手軽に使えます
- Wayland対応済み(通知も許可していたら可能。Hyprlandでも動作確認しました)
- FFmpegは自動で検出
などと、書いてることはとても優秀そうに見えますが、Windowsでよくあるダウンローダーのような感じの機能です。アプリを起動すると、必要なライブラリを自動でインストールするので、本体だけダウンロードして、あとは起動してからという感じになります。ちょっと記憶が曖昧ですが、AppImageファイル本体 100MB + 必要なものが200MBには達しないぐらいだったかと思います。
設定などは英語ですが、だいたい意味はわかると思います。どうしてもわからなくなったらGithubのwiki(これも英語ですが)を確認してみるのも良いと思います。
LinuxとWindowsのメモリ管理とかの話
Open Video Downloaderの起動の速さ
知ってほしいのは動画ダウンロードの是非ではなく、そのソフトの技術です。ソフト本体の中身や表示はWebサイトっぽい感じは否めないものの、その速さに注目して欲しいわけです。
Electronの代表格としてVS Codeなどがありますが、対象が巨大・複雑・機能満載なので、おいそれとはRust + Tauriに移行できないのでしょう。しかし、 比較的ユーティリティ系の軽めなソフトであれば、Rust + Tauriの組み合わせで作られたものは爆速です。今後「Rust + Tauri製」という情報だけで、ソフトの動作が軽快だろうと想像できると思います。
Rustは高速だと言われますが、むしろ高速な上にメモリ関連の問題点がないという認識でも良いかも知れません。問題があればコンパイルできない仕組みになっているので。ソフトのコード自体にバグがあればそれはRustでもC/C++でも同様に問題が起きます。
よく「昔からあるソフトのソースコードを、CからRustにリライトした」と言う話を聞きます。書き換えられるぐらいのポテンシャルとセキュリティ面の充実が、Rustが選ばれる理由でもあるかと思います。
どれだけ褒めちぎってもPCの性能以上に速度アップはしないことは理解して下さい。むしろ(Open Video Downloaderに限らず)同じ物を同じPCで動かしてるのにどうしてWindowsは遅いんだという点に疑問を持ってほしいのです。
Windowsのモッサリ感
Windowsのモッサリ感は複雑な要因が絡んでいます。無駄なプロセスが状態を監視しているとか、本来正しく機能すれば素晴らしい機能なのにメモリリークや不要なイベントを大量に作ったりしてしまうわけです。
ここから考えるに、仮に(古いPCで物理的に必要な場合を除いて)32GB以上を積んだとして、追加メモリの分の空きが体感できるほどの差になるだろうかと思うわけです。ある人の話では、メモリのスタンバイリストのサイズには実質上限があると言われています。非公式なものの、RAMの30%~50%程度を目安に、それを超えると古いものを積極的に捨て始めるというのです。
メモリのスタンバイリストとは
Windowsが一度使用したデータをキャッシュとしてメモリ上に残している領域のことです。頻繁に使うデータを保持して次回高速に読み込めるようにする機能であり、システムが必要と判断すれば即座に解放されて空きメモリになります。基本は自動管理され、満タンでも問題はありません。
人間が実際にアクセスするデータは、全体のメモリに対して非常に偏っていて、8GBでも16GBでも、実際に頻繁に使用するデータは数GB程度で済むことが多く、それは追加したメモリがキャッシュとして役立つ機会が減るということなのではと。
ゲームなどで急激にメモリが要求されるとスタンバイリストからの解放が遅延して、ディスクスワップが起こります。それでもNVMeが高速だったりすると案外気が付かなかったりするわけです。
ディスク・スワップ(単にスワップとも)とは
パソコンの物理メモリ(RAM)が不足した際に、一時的にHDDやSSDなどのストレージ領域(スワップ領域)を仮想的なメモリとして使用し、データを退避・交換する機能。 これによりメモリ不足によるシステム停止を防げますが、ストレージの読み書き速度はメモリより遅いため、頻繁に発生するとPCの動作が著しく低下します。
物理的にメモリが足りなければその原因はメモリに違いないわけですが、急激なメモリの要求をさばききれないCPUやネットワーク速度、SSDなどの速度も関係するかも知れません。しかし、どんどん積めるだけ積めとメモリだけを疑うのはどうも…と、疑問が残るのです。
16GBのPCでスタンバイリストを使っては解放とする方がPCは快適に使えそうにも思いますし、32GB積んでいるPCでも積極的にスタンバイリストをクリアすれば体感速度は速くなりそうです。
メモリレイテンシ(Memory Latency)とは
CPUがメインメモリ(RAM)に対してデータの読み書きを要求してから、実際にデータが転送され始めるまでの「待ち時間」のこと。 一般的にナノ秒(ns)単位で測定され、この値が小さいほど、CPUが待たされる時間が減り、パソコンの応答速度や動作が高速になります。主に「CL(CAS Latency)」という数値で指標化されます。
Microsoftがこの辺りを認識しているくせにメモリの管理方法を変えないのは、低スペックユーザー(日本とかだけではなく海外の新興国や企業が大量導入する事)を切り捨てたくないからだと思います。
本来であればメモリ量によって最適な振る舞いが変わるのが理想であるのに、OSが一貫した考えを押し付けているのがジレンマだとも言えます。
Linuxではどうなんだろうか?
Linuxでもメモリ管理があまりうまくないと、もっと最適化できるはずだという人もいます。しかしそんな中でもWindowsよりマシとも言えるのは、Windowsと同様にメモリを最大限使用するようになっているけれども、Linuxは使っていないメモリをキャッシュとして積極的に活用して、ディスクの読み書きを高速化しているからです。
Linuxのカーネルはキャッシュとして使っていないメモリを有効活用していると前述しましたが、Linuxカーネルは長期間使用されていないデータから順に整理する仕組みも持っています。必要なものだけを物理メモリ上に残すため限られた容量を効率よく使えるわけです。
つまり、「ギリギリまで使い倒して速度を稼ぎ、足りなくなったら賢く整理する」という、実用性に振り切った構造になっているからです。
- Windowsは「常に余裕を持たせて安定感を演出し、足りなくなっても粘り強く処理を続けようとする」
- Linuxは「今ある資源を100%使い切って速度を最大化し、ダメなら何かを犠牲にしてシステムを守る」
というような違いがあるのです。これはサーバー用途側に振るか、デスクトップ用途に振るかというような性質の違いかも知れません。
Windowsは次に備えるのは良いが、備えるものが多すぎるわな、Superfetch / SysMain、お前の事やぞという感じです。
Windowsでゲームをしていて大量のメモリを要求された場合、ディスクスワップが起こります。この時、Windowsは粘り強くなんとか処理し続けるわけですが、ガタつきが起こると思います。
Linuxでは本来なら、そういうプロセスは自動で切り捨てます。突然ゲームが終了してしまうということがありえます。システム自体が終了するのを嫌うためプロセスを切るわけです。
CachyOSや他のゲームディストロでは?
最近のディストリビューションには、zswap/zramという仕組みが採用されているものもあります。これはメモリが足りなくなるとSSDに書く前に、メモリ内でもう一度データを圧縮して詰め込むと言う処理をします。
ゲームを例にここまで書きましたが、そんなことはメーカーも知っていて、正常なゲームプレイ中に大量メモリを突発的に要求するような極端な挙動は設計上起こりません。
これらを言う人はたいていブラウザでタブを大量に開いていたり、大量の拡張機能があったり、純粋にゲームだけをプレイしているというわけではないのではないでしょうか?
ゲームでメモリ要求が激しくなった時、WindowsではOS全体がモッサリし始めますが、CachyOSなどでは独自のチューニングがされているため、ゲーム以外の背景プロセスの優先度を下げるような最適化が行われていたり、メモリ逼迫で何かを強制終了させる際の挙動を調整して、ゲーム以外のバックグラウウンドで動作している不要なもの(例えばブラウザのタブ)を優先的に整理するように調整されています。
なので、一概に「Linuxは」とひとまとめにできないわけです。
まとめ
「何をするかによりけり」ではありますが、メモリ量やグラボ・SSD・CPUの選定、調整はWindowsもLinuxも同じです。何もしないで買ったままで最大限のパワーを出すためには札束で買うぐらいのPCが必要でしょう。
ここから普段遣いにPCを使う人、ゲームは軽いタイトルしかしないという人にとっては、ゲーマーの言うことは聞かなくてもいいと言えるかと。
彼らゲーマーはゲームの時の不具合を恐れて余裕を最大限持たせるような構成を想定しているわけです。
ゲーマーが言う最高級のCPU、最速大容量のメモリ、最高のグラボが必要なのは、Windowsというものが動きながらその余力でゲームをしているからです。ゲーマーはその余力を高級パーツとして買っているとも言えます。
ただPCはゲームだけをするわけではないからこそ、無駄があってしょうがないのです。
WindowsにしろLinuxに想定外のことが起これば問題も起こります。そういう想定外のことをしなければどっちも快適に使えるとも言えます。しかし、Windowsはバックグラウンドプロセス、AIのための余力、テレメトリーなどの情報収集、不具合でのメモリを圧迫するようなゴミが生み出されるなど、それって必要?な部分があるため、モッサリしているのではないかと思うのです。
ゲーマーはパーツの性能アップより、OSの無駄をなくすことに声を上げるべきです。そうすれば余力は生まれ、ゲーマーが持っているようなPCならメモリが足らないということは起こらないはずです。しかしそれは現実には起こっていて、もっと積まなきゃもっと積まなきゃとなってしまっています。
そのPCにはゲームと限られたものだけ入れて、できるだけ他のものは入れず、他のことはサブPCのLinuxに任せれば、Windows PCには余力が生まれるのです。
全部の事を1台で済まさず余力を作るための工夫が必要で、ゲームをするPCはWindowsで極力ゲーム以外のものを入れず余力を作り、他でしていたことはサブノートPCにLinux(以外でも良いですが)を入れて行えば、すべてが快適に近づくと、私はそう思うのです。
見て下さい、Open Video DownloaderはElectronの重い部分をRust + Tauriで置き換えたことで、起動が爆速になり、メモリも激減したでしょう?まさに「余力を作る」とはこういうことです。