世界を動かす技術を、日本語で。

YouTubeをストレージとして利用する

2026年2月14日原文(github.com)

概要

  • YouTube動画 を利用したファイル保存・復元技術の解説
  • CLI/GUI 両対応、暗号化・冗長化・バッチ処理など多機能
  • FFV1/MKV 形式のロスレス動画へのエンコード・デコード
  • libsodium によるオプション暗号化
  • クロスプラットフォーム なビルド・動作環境

YouTube動画ストレージ技術 概要

  • 任意のファイルを FFV1コーデック(MKVコンテナ) のロスレス動画へエンコードし、YouTube等の動画プラットフォームに保存する技術
  • 動画から 元ファイルを完全復元 可能なデコード機能
  • コマンドラインインターフェース(CLI)グラフィカルユーザーインターフェース(GUI) を提供
  • Wirehair fountain codes による冗長化・修復機能
  • libsodium(XChaCha20-Poly1305) によるパスワード付き暗号化オプション
  • バッチ処理 やリアルタイム進捗表示、ログ出力などのGUI機能
  • マルチスレッド によるUIレスポンス維持

必要要件・インストール方法

  • CMake 3.22 以上、 C++23 対応コンパイラ
  • FFmpeg, libsodium, OpenMP, Qt6(Core/Widgets) の開発パッケージ
  • 主要OS (Ubuntu/Debian, Fedora/CentOS, Arch Linux, macOS, Windows)ごとのパッケージ例を明記
    • Ubuntu例:
      • sudo apt install cmake build-essential qt6-base-dev libavcodec-dev libavformat-dev libavutil-dev libswscale-dev libswresample-dev libsodium-dev libomp-dev ffmpeg
    • macOS例:
      • brew install cmake qt@6 ffmpeg libsodium libomp
    • Windows例:
      • vcpkg install ffmpeg libsodium openmp qt6
  • Qt Online Installervcpkg 経由での依存解決も可能

ビルド手順

  • 任意ディレクトリで
    • mkdir build
    • cmake -B build
    • cmake --build build
  • media_storage (CLI)と media_storage_gui (GUI)の2つの実行ファイル生成

使い方(CLI)

  • ファイルを動画へエンコード:
    • ./media_storage encode --input <file> --output <video> [--encrypt --password <pwd>]
  • 動画からファイルへデコード:
    • ./media_storage decode --input <video> --output <file>

使い方(GUI)

  • シングルファイル操作
    • 「Input File」でエンコード対象ファイル選択
    • 「Output File」で保存先動画ファイル指定
    • 「Encode to Video」または「Decode from Video」で処理開始
  • バッチ処理
    • 「Add Files」で複数ファイル追加
    • 出力ディレクトリ指定、「Batch Encode All」で一括エンコード
  • 進捗監視・ログ閲覧
    • 進捗バー、ステータス表示、詳細ログパネル

技術詳細

  • エンコード: ファイル分割→fountain codes冗長化→動画フレーム埋め込み
  • デコード: 動画フレームからパケット抽出→元ファイル再構築
  • 動画仕様: FFV1コーデック(MKV)、4K(3840x2160)・30FPS
  • 暗号化: XChaCha20-Poly1305 (libsodium)によるオプション暗号化

トラブルシューティング

  • Qt6/FFmpeg/libsodium/OpenMP 未検出→対応パッケージインストール確認
  • 入力ファイルが開けない →パス・権限確認
  • エンコード失敗 →出力先ディスク容量確認
  • デコード失敗 →入力動画が有効なエンコード動画か確認
  • FFV1 on mp4失敗 →FFmpeg 8以上必須。未満の場合はMKV利用推奨

ライセンス

  • GNU General Public License v3 またはそれ以降
  • 無償利用・改変・再配布 可能

関連リンク

  • 解説動画: YouTube
  • Hacker Newsスレッド: YC Hacker News
  • CI/CD Pipeline: 最新ビルド成果物のダウンロード可能

Hackerたちの意見

以前、YouTubeのインフラエンジニアに「誰も見ない動画の長い尻尾を削除する必要があると思う?」って聞いたことがあるんだけど、彼らは「気にしないよ」って言ってた。新しいデータの流入がすごい速さで増えてるから、古いデータなんてほんの一滴に過ぎないって。

それって今も当てはまるのかな?動画の量が特にAIの影響で爆発的に増えてるし、いつかはユーザーごとのストレージ制限を設ける必要が出てくるかもね。もしその制限を超えたら、有料モデルになるかも。たくさん動画をアップロードする人たちは、YouTubeから何らかの収入を得てるだろうから、そんなに大きな問題じゃないと思う。

動画は消えちゃうこともあるよ。 https://www.reddit.com/r/DataHoarder/comments/1ioz4x1/is_it_... 例を探すならhn.algolia.comで検索するとたくさん出てくるよ。 https://news.ycombinator.com/item?id=23758547 https://bsky.app/profile/sinevibes.bsky.social/post/3lhazuyn...

これってパフォーマンス的にも悪夢になりそうじゃない?テラバイトのメタデータをスキャンするのにかかる電気代は、数ヶ月分のAIトレーニングに匹敵すると思うし、時間もかかるだろうね。それに、何百万本ものランダムな360p動画を削除してMrBeastに入れ替えたら、新しいファイルの断片化がすごいことになりそう。新しいHDDを買い続ける方が安上がりかもしれないね。

いつかは重要になるよ。無限成長の影響から逃れられるのはGoogleですら無理だし、クライダーの法則は終わった。ストレージが安くなるスピードよりも早くそれを埋めることはできないし、組織はデータから得られる価値がストレージコストを上回ることを期待できない。もう他の組織はこれを理解してるよ。Googleとの違いは、彼らが広告収入を使って現実を先延ばしにしていることだけ。いつか、何を削除するか決める役割を持つ人が出てくるだろうね。それはあまり美しくない結果になると思う。古くて愛されていない動画は、圧縮率が上がるにつれてJPEGノイズに消えていく。最終的には、元の動画の複製を再生成するためのAIモデルに供給するためのテキストプロンプトだけが残るんだ。

AIのトレーニングのために全部収穫できるようになった今、その決断は一番安くて最高のことだったね。あのコンテンツにお金を払おうとしたら、地球上の誰もが供給できないし、したくもないだろうね。

HDバリエーションが削除されて、古い未視聴の動画は480p以下だけになるって読んだ気がする。元のアップロードはまだ保存されてるだろうけど、視聴はできないだろうね。

それと、Googleアカウントを悪用でバンされる方法。

情報を複数のアカウントで保存するボットネットワークを用意しておくのが大事だよ。それに、壊れた動画や削除されたアカウントを復元するための十分なパリティビット(例えば、PAR2)も必要。

すでに何百万本ものAI生成動画があるチャンネルがあるよ。

そんな動画がどんな感じか、誰か例を見せてくれない?めっちゃ気になる。ソビエトのArvidカードを思い出すな、E-180のVHSテープで2GB保存できたんだよね。

ほとんど雑音だね。これはクリエイターからのデータビデオの例だよ: https://www.youtube.com/watch?v=tIRXaQWjiA8 (このプロジェクトのYouTubeビデオ: https://www.youtube.com/watch?v=l03Os5uwWmk)

Hacker Newsで議論の続きを見る