セルフホスト型チューブサイトの動画エンコーディング：FFmpeg、AV1、ストレージ計算

エンコーディングこそが、チューブサイトの経済性を実際に左右する場所です。ストレージと帯域は成功とともに膨らむ2つの請求項目であり、そのどちらも「どうエンコードするか」という一つの要因の関数です。ところがチューブサイト特有のエンコーディング指南を検索しても、出てくるのはクラウドベンダーが書いた一般的なコーデック論争の記事ばかりで、結論はいつも「難しすぎるから自社プラットフォームを使え」です。本ガイドはその正反対です。2026年のセルフホスト型チューブサイトのためのFFmpeg設定、レンディションラダー、ストレージの計算を、セルフホスト側の立場から語ります。

以下のビットレートとサイズは、典型的な2Dアダルトコンテンツを想定した実務上の初期値であり、絶対的な規則ではありません。コーデックのライセンス状況やブラウザ対応率は2026年半ば時点で報告されているものです—20万本規模のカタログを単一のコーデックに全面的に委ねる前に、必ず検証してください。

レンディションラダー：3段、時には4段

ストリーミングプラットフォームがスマートTVからエレベーターの中まであらゆる環境に対応するために8段のラダーを公開しているのに対し、チューブサイトに必要なのは3段、時に4段です。

正確な数値そのものより重要な判断が2つあります。ソースを保持するかどうか。再エンコードは、保持しているものからしか行えません。独占・ライセンス済みコンテンツはオリジナルを保持し、フィードコンテンツはレンディションのみで運用しましょう。1080pを無料にするかどうか。フルHDを会員特典にすることは、最も古くから機能しているチューブサイトの収益化レバーの一つであり、同時に帯域コストも削減できます。（TubePressでは、どのレンディションをどのFFmpegオプションで用意するかを、フォーマットごとに定義できます。）

実際に重要なFFmpeg設定

チューブサイト向けのH.264エンコードは、4つの判断とその後のテンプレートで決まります。品質モード：知覚品質を一定に保つにはCRFを使い（-crf 23から始め、プレミアム層では21～22まで下げます）、-maxrate／-bufsizeで上限を設定し、動きの激しいシーン1つで配信が破綻しないようにします。速度：-preset veryfastは大量インポートの主力です—slowと比べたファイルサイズの犠牲は実在しますが小幅であり、CPU時間の差は5～10倍にもなります。より遅いプリセットはプレミアムコンテンツ用に取っておきましょう。シーク：キーフレーム間隔を固定し（-g 48–120）、チューブサイトのユーザーが絶えず行うシークバー操作をすばやく反応させます。配信：プログレッシブMP4では-movflags +faststartは譲れません。これがないと、プレーヤーはファイル全体を待ってから再生を始めてしまいます。まとめると、480pの主力レンディションは次のようになります。

ffmpeg -i src.mp4 -vf scale=-2:480 -c:v libx264 -preset veryfast -crf 23 -maxrate 1.5M -bufsize 3M -g 96 -c:a aac -b:a 96k -movflags +faststart out_480.mp4

レンディション自体に加えて、エンコードパイプラインはクリックを生み出す素材も生成します。ポスターサムネイル、アニメーションのホバープレビュー（タイムライン全体からサンプリングした低fpsのWebP／MP4の短い断片—CTRにとって不釣り合いなほど重要です）、そしてコンテンツにブランドを付けるなら透かしです。透かしとイントロバンパーは焼き込み合成であり—オーバーレイではなく再エンコードです—そのためカタログを一括処理する前に決めておく必要があります、後からではありません。TubePressのトランスコードパイプラインは、管理画面で定義したフォーマットリストからレンディション、サムネイル、プレビューを生成し、透かしとイントロの焼き込みオプションも備えています—上記と同じFFmpegのロジックが、アップロードと一括インポートのフローに組み込まれています。

2026年のAV1とH.265：正直な答え

コーデック論争の記事が正しく指摘している点が一つあります。AV1は同等の画質でH.264に対しておおよそ30～50%のビットレート削減を実現し、ブラウザ対応も現行バージョンでは広く行き渡っています。それらの記事が省略しているのが、運営者にとってのコスト表です。

• エンコードコストが跳ね上がる。ソフトウェアによるAV1エンコードは、チューブサイトで使う設定においてx264より何倍も遅くなります。カタログ規模ではこれは現実のサーバー費用です—ハードウェアAV1エンコーダー（最近のGPUや一部のCPU）を自分のエンコード用マシンが備えていれば、この状況は変わります。
• 古いデバイスは今もH.264でしか再生できない。アダルトのトラフィックは非常に長いデバイステールに偏っています。テール部分のデバイスがデコードできないコーデックはサポートチケットの原因になるため、AV1はH.264の代わりにではなく並行して提供することになります—つまり整理するまでは、ストレージは減るのではなく増えます。
• ライセンス。AV1は設計上ロイヤリティフリーです（対抗するパテントプール側の主張は長年にわたり報告されていますが、エコシステムはおおむねそれを気にせず前進してきました）。H.265の複数プールにまたがる煩雑なライセンス体系こそが、ウェブが無料コンテンツ向けにはH.265をほぼ見送ってきた主な理由です。

セルフホスト型チューブサイトにとっての2026年の実務的な方針はこうです。ベースラインとしてはあらゆる場所でH.264を使い、トップトラフィックのコンテンツにのみ、帯域削減がエンコードコストに見合う範囲でAV1レンディションを追加する。ソースのワークフローがH.265を渡してくるのでない限り、ウェブ配信用にはH.265は無視して構いません。大手アダルトCMSプラットフォームがAV1／H.265対応を2026年のリリースでようやく搭載したという事実そのものが物語っています—この業界の主流は、まさにここにあるのです。

カタログ規模別のストレージ計算

3段のラダー（240＋480＋720、10分の動画1本あたり全部で≈ 0.35 GB）と4段のラダー（1080pを含めて≈ 0.75 GB）を使い、平均動画尺を15分として計算すると次の通りです。

この表から導かれるルールがあります。専用ストレージサーバーの大容量HDDは、チューブサイトの規模ではクラウドオブジェクトストレージより価格面で大きく上回ります（現在のエグレス費用と照らし合わせて自分で計算してみてください—たいてい僅差ではありません）。レンディションは再生成可能なので、RAIDによる冗長化とソースのバックアップの組み合わせは、すべてを二重にバックアップするより優れています。そして誰も見ていない動画の1080pレンディションを間引くことは、労せず得られる節約です。ホスティングガイドでは配信側の話—CDNの選び方、大手CDNの規約がアダルトに対して実際に何を許可しているか、予算別のリファレンス構成—を扱っています。

「動画は絶対にセルフホストするな」—ベンダーの主張を計算にかけてみる

クラウド動画業界は「動画を絶対にセルフホストしてはいけない15の理由」といったコンテンツを絶えず発信しています。その理由は、プロダクトデモをホストする5人規模のSaaS企業にとっては真実です。しかしチューブサイトの規模では逆転します。ホスト型動画プラットフォームは保存時間と配信時間で課金します—2026年半ば時点で公開されている料金では、実トラフィックを伴う控えめな5万本規模のカタログでも月額5桁の価格になり、しかもそれはプラットフォームのコンテンツポリシーが自分のコンテンツと衝突する前の話です（主要な動画SaaSの規約の大半は、アダルトを完全に対象外としています）。上記のラダーを運用するストレージサーバー＋CDNなら、同じ仕事を月額数百ドルでこなせます。動画のセルフホストはチューブサイト運営のハードモードではありません。それこそがこのビジネスモデルそのものなのです。

TubePressは、このパイプライン全体を設定項目に変えます。管理画面で定義するフォーマットとレンディション、サムネイル・ホバープレビュー・透かし焼き込み付きのFFmpegトランスコード、そしてマルチサーバーストレージ—すべて無料でセルフホスト型です。ダウンロードして、自分の請求書だと思ってエンコードしましょう。事実、そうなのですから。