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

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

概要

  • 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)

ステガノグラフィーがないの?お願い、見えないチェリーを乗せて!:-) これで始めてみて:

ビデオ圧縮アーティファクトを通すのは難しいね。

これめっちゃクールだけど、同時に共有資源に対する潜在的な負担にも感じるな。

何兆ドルもの企業が、いくつもの国を買えるっていうのに、彼らは広告を最適化するために新しいデータセンターを立ち上げるとき、公共の利益を気にするんだね。

どうやって機能するのか全然わからない。 > エンコーディング:ファイルはチャンクに分割され、ファウンテンコードでエンコードされ、動画フレームに埋め込まれる。YouTubeが動画を圧縮・再エンコードしてデータを台無しにしないの?(ビット単位で正確に復元したい場合)。もしこれに対抗するための冗長性があったら、すごく非効率的じゃない?(正直言って、「ファウンテンコード」って聞いたことないから、どう機能するのか理解するのに重要かもしれない。)

そうだね、非効率的だよ。でもYouTubeがストレージ代を払ってくれるからね(笑)。(無料アカウントには多分制限があるし、TOSに違反してるかもね。)

うん、トランスコードが最終的にはこれを壊すと思うな…

こんにちは、ブランダンだよ(開発者)。ここに説明ビデオをアップロードしたから、見てみるといいかも! :D https://youtu.be/l03Os5uwWmk?si=nJDwz4s7_E4WFOwC

彼はDCT係数の符号としてビットをエンコードしてるけど、これって最適とは言えない気がするな。個人的には、AC係数を無視して、代わりにDCにブロックごとにいくつかのビットをエンコードする方がいいと思う。クロミナンスを使わないのももったいない感じがするし。

技術的にはクールだけど、TOSにはこう書いてあるよ。「サービスの誤用制限 - 目的制限:このサービスは動画の視聴と共有を目的としており、一般的なクラウドベースのファイルストレージサービスではありません。」だから、正当な理由でファイルを削除できるんだ。

この具体的な使い方がすでにTOSに含まれているのは面白いね。最初のYouTubeストレージプロジェクトがいつ始まったのか、今までにいくつあったのか気になるな。

こんにちは、ブランダンだよ(開発者)。興味がある人のために説明ビデオをアップロードしたから、見てみるといいかも! :D https://youtu.be/l03Os5uwWmk?si=nJDwz4s7_E4WFOwC

面白いことに、これはもっと一般的なアイデアの具体的な実装なんだ。ソーシャルメディアを利用して暗号化されたコンテンツを保存し、信頼できるアプリを通じてデコードしないと実際のコンテンツが見れないようにするってやつ。AIツールはこれをメッセージングサービスとして使うことができて、否認もできる。人間もすでにこういう使い方してると思う。昔の新聞の広告も、否認できるメッセージングサービスの一種だったよね。

過去数年の似たようなプロジェクト: https://news.ycombinator.com/item?id=31495049 と https://news.ycombinator.com/item?id=34866808