【解説】ffmpeg whipのインストールから実行まで

By /

【解説】ffmpeg whipのインストールから実行まで

ライブストリーミング技術は日々進化しており、低遅延かつ高品質な配信が求められています。従来のRTMPプロトコルに代わる選択肢として、WebRTCベースのプロトコルが注目されています。その中でも、エンコーダーからの入力に特化した「WHIP (WebRTC-HTTP ingress protocol)」は、既存の配信ワークフローにWebRTCを取り入れるための鍵となります。

そして、メディア処理の強力なツールとして不動の地位を築いているのがffmpegです。ffmpegは、様々なフォーマットの変換、エンコード、デコード、ストリーミングをコマンドライン一つで実行できる非常に柔軟性の高いソフトウェアです。

この記事では、この二つの強力な技術、ffmpegとWHIPを組み合わせ、どのようにしてffmpegからWHIPプロトコルを使ってストリームを配信するのかについて、そのインストールから実行までの詳細な手順を解説します。特に、ffmpegがWHIPをサポートするためのビルド方法に重点を置き、必要な依存関係やconfigureオプション、そして実際の配信コマンド例までを網羅的に説明します。

1. はじめに：ffmpegとWHIP、そしてその組み合わせ

1.1. WHIP (WebRTC-HTTP ingress protocol) とは

WHIPは、エンコーダーやメディアプレーヤーからWebRTCベースのメディアサーバーへメディアストリームを入力するためのHTTPベースのプロトコルです。RFC 8825「WebRTC-HTTP Ingestion Protocol」として標準化が進められています。

従来のライブストリーミングの入力プロトコルとして広く使われているRTMP (Real-Time Messaging Protocol) は、Adobe Flashプラットフォームの一部として開発されたものであり、TCP上で動作し、比較的高遅延になりがちです。一方、WHIPはWebRTCをベースとしているため、UDP上でメディアを転送し、低遅延なストリーミングを実現することを目的としています。

WHIPは、WebRTCの複雑なシグナリング（SDP交換、ICEネゴシエーションなど）をHTTP上で抽象化し、エンコーダーが比較的簡単にWebRTCサーバーと接続できるように設計されています。エンコーダーはHTTP POSTリクエストを使ってSDPオファーをサーバーに送信し、サーバーはSDPアンサーを返します。その後、ICE候補の交換などが行われ、UDP上でメディア転送が開始されます。

1.2. ffmpegとは

ffmpegは、音声・動画のエンコード、デコード、トランスコード、ミキシング、ストリーミングなど、メディア処理に関するあらゆる作業を実行できる非常に強力で多機能なコマンドラインツールおよびライブラリ群です。非常に多くのフォーマットやプロトコルをサポートしており、その柔軟性からメディア処理のデファクトスタンダードとなっています。

ffmpegは libavcodec, libavformat, libavutil, libavfilter, libswscale, libswresample などのライブラリで構成されており、これらのライブラリを使うことで、多様なメディア操作が可能になります。

1.3. ffmpegとWHIPを組み合わせる意義

ffmpegは、ファイル、デバイス（Webカメラ、マイク）、ネットワークストリーム（RTMP, RTSPなど）といった多様なソースからメディアを取り込む能力を持っています。一方、WHIPは低遅延なWebRTCインジェストを実現するプロトコルです。

ffmpegがWHIPプロトコルをサポートすることで、以下のことが可能になります。

  • 多様なソースからのWebRTCインジェスト: ffmpegがサポートするあらゆる入力ソース（ビデオファイル、画面キャプチャ、キャプチャカード、別のRTMPストリームなど）を、エンコード・変換処理を経て、WHIP経由でWebRTCサーバーに送り込むことができます。
  • 高品質なエンコード: ffmpegは libx264 (H.264), libx265 (HEVC), libvpx (VP8/VP9), libopus (Opus) など、高品質なコーデックをサポートしています。これらのエンコーダーを使って最適な品質とビットレートでエンコードした上で、WHIPで配信できます。
  • 既存ワークフローとの連携: 既にffmpegベースのメディア処理パイプラインを構築している場合、出力プロトコルをRTMPからWHIPに変更するだけで、低遅延なWebRTC配信ワークフローに容易に移行できます。
  • カスタマイズ性: ffmpegの豊富なフィルタリング機能やオプションを活用し、映像や音声に様々な処理（リサイズ、クロッピング、音声ミキシング、ノイズ除去など）を施してから配信できます。

ffmpegをWHIPクライアントとして利用することで、既存の高性能なエンコーダーとしての能力を活かしつつ、低遅延なWebRTC配信ネットワークに接続できるようになります。

2. WHIPプロトコルのもう少し詳しい解説

WHIPはWebRTCの複雑さを隠蔽しつつ、エンコーダーがサーバーへストリームを送るためのシンプルなインターフェースを提供します。その核心は、HTTP POSTリクエストによるSDP交換と、それに続くWebRTCの確立プロセスです。

  1. 初期接続: エンコーダー（ffmpeg）は、指定されたWHIPエンドポイントURLに対してHTTP POSTリクエストを送信します。このリクエストのContent-Typeは application/sdp で、ボディにはエンコーダーがサポートするメディア能力を示すSDPオファーが含まれます。
  2. SDPアンサーの受信: WHIPサーバーは、エンコーダーのSDPオファーを受け取り、自身のメディア能力や設定（例えば、利用可能なトランスポートなど）を含んだSDPアンサーを生成します。このSDPアンサーは、HTTP 201 Created レスポンスのボディとして、Content-Type application/sdp でエンコーダーに返されます。レスポンスには、ICE候補の交換やその他の後続処理に使用される新しいリソースURLが Location ヘッダーで含まれることがあります。
  3. WebRTC確立: エンコーダーは受信したSDPアンサーを使ってWebRTCピアコネクションを確立しようとします。これには、ICE (Interactive Connectivity Establishment) プロトコルを使ったネットワークアドレスの探索と候補の交換が含まれます。ICE候補は通常、SDP内に含まれるか、または必要に応じて Location ヘッダーで示されたリソースURLに対するHTTP PATCHリクエストを使って交換されます。
  4. メディア転送: ICEネゴシエーションが成功し、ピアコネクションが確立されると、RTP/RTCPパケットを使った実際のメディアストリームの転送がUDP (通常はDTLSの上) 上で開始されます。

WHIPは「Ingress Protocol」（入力プロトコル）であるため、エンコーダーからサーバーへの一方向のメディアフローを扱います。サーバーからエンコーダーへの制御信号などは、SDP交換時やICE交換時にHTTPレスポンスやPATCHリクエストで行われます。

ffmpegがWHIPをサポートするということは、ffmpegがこのWHIPプロトコルのクライアント側の振る舞い（SDPオファー生成、POSTリクエスト送信、SDPアンサー受信、ICE候補処理、DTLS/RTP/RTCP送信）を実装していることを意味します。

3. ffmpegのインストール（WHIPサポートを含めて）

標準的なパッケージマネージャーからインストールされるffmpegは、WHIPサポートを含むすべての最新機能が有効になっているとは限りません。特にWHIPサポートは比較的新しいため、確実に利用するにはソースコードからビルドすることが強く推奨されます。

3.1. なぜソースコードからビルドするのか

  • 最新機能の利用: WHIPのような新しい機能は、最新のffmpegバージョンまたは開発版で利用可能になります。パッケージマネージャーのリポジトリにあるバージョンはしばしば古い場合があります。
  • 必要なライブラリの有効化: ffmpegは様々な外部ライブラリに依存しています。WHIPサポートには、TLS/SSL（OpenSSLなど）やHTTP/HTTPSクライアント（libcurlなど）のサポートが不可欠です。また、高品質なエンコーダー（libx264, libx265, libvpxなど）やオーディオコーデック（libopusなど）も別途インストールし、ffmpegビルド時に有効化する必要があります。ソースからのビルドであれば、これらのライブラリを自分で選択し、ffmpegに組み込むことができます。
  • カスタマイズ: 特定のフォーマットやプロトコル、フィルタだけを有効にして、ビルドサイズを小さくするなどのカスタマイズが可能です。

3.2. 前提条件

ソースコードからffmpegをビルドするには、開発環境が必要です。

  • オペレーティングシステム: Linux (Debian/Ubuntu, Fedora/CentOSなど) が最も一般的で推奨されますが、macOSやWindows (WSLなどを使用) でも可能です。本記事ではLinuxを想定して説明します。
  • 開発ツール: C/C++コンパイラ (GCC, Clangなど), make, git (ソースコードの取得), yasm/nasm (一部アセンブリコードのビルドに必要)。
  • 必要なライブラリのヘッダーファイルと開発パッケージ: ffmpegが依存する外部ライブラリの開発用ファイルが必要です。これらは通常 -dev または -devel というサフィックスの付いたパッケージとして提供されます。
  • インターネット接続: ソースコードや依存ライブラリをダウンロードするために必要です。
  • ディスク容量とCPU: ビルドプロセスにはある程度のディスク容量とCPUリソースが必要です。

3.3. 必要な依存関係のインストール

ffmpegのビルドには多くの依存ライブラリがあります。WHIPサポートのために特に重要なのはTLS/SSLライブラリとlibcurlです。その他、一般的なライブストリーミングに必要なコーデックライブラリも合わせてインストールします。

Debian/Ubuntu系Linuxの場合:

“`bash

開発ツールのインストール

sudo apt update
sudo apt upgrade -y
sudo apt install -y build-essential cmake git pkg-config yasm nasm

ffmpegが依存する主要ライブラリ（コーデック、フォーマット、プロトコルなど）

WHIPに必要な libssl-dev, libcurl4-openssl-dev を含む

sudo apt install -y \
libass-dev libfreetype6-dev libfontconfig1-dev libharfbuzz-dev \
libfribidi-dev libmp3lame-dev libopus-dev libvorbis-dev libvpx-dev \
libx264-dev libx265-dev libnuma-dev libsdl2-dev libtheora-dev libv4l-dev \
libxcb1-dev libxcb-shm0-dev libxcb-xfixes0-dev zlib1g-dev \
libbluray-dev libdav1d-dev libaom-dev \
libssl-dev libcurl4-openssl-dev # <- WHIP/HTTPSに必要なライブラリ
“`

Fedora/CentOS/RHEL系Linuxの場合:

“`bash

開発ツールのインストール

sudo dnf update -y # または yum update -y
sudo dnf groupinstall “Development Tools” -y # または yum groupinstall “Development Tools” -y
sudo dnf install -y git pkg-config yasm nasm # または yum install -y git pkgconfig yasm nasm

ffmpegが依存する主要ライブラリ

WHIPに必要な openssl-devel, libcurl-devel を含む

sudo dnf install -y \
freetype-devel fontconfig-devel harfbuzz-devel fribidi-devel \
lame-devel opus-devel libvorbis-devel libvpx-devel \
libx264-devel libx265-devel numactl-devel SDL2-devel theora-devel v4l-utils-devel \
libxcb-devel libxcb-shm-devel libxcb-xfixes-devel zlib-devel \
libbluray-devel dav1d-devel aom-devel \
openssl-devel libcurl-devel # <- WHIP/HTTPSに必要なライブラリ
“`

これらのコマンドは一般的な依存関係をインストールしますが、環境やffmpegのバージョンによっては追加のライブラリが必要になる場合があります。エラーメッセージを確認しながら適宜対応してください。

3.4. ffmpegソースコードの取得

最新のffmpegソースコードをgitリポジトリからクローンします。開発中の最新バージョンを取得することで、WHIPサポートが確実に行われているブランチを利用できます。

bash
cd ~ # ホームディレクトリなど任意の場所に移動
git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg
cd ffmpeg

これはmasterブランチ（開発版）をクローンします。特定の安定版リリースをビルドしたい場合は、クローン後に git checkout release/x.y のようにタグやブランチを指定してください。しかし、WHIPは比較的最近導入された機能なので、masterブランチか、WHIPが公式にマージされた後の最新リリース版を選ぶのが良いでしょう。

3.5. configureスクリプトの実行

ビルドの前に、configureスクリプトを実行してビルドオプションを設定します。ここで必要な外部ライブラリの検出や、有効化したい機能の指定を行います。

WHIPサポートには、--enable-libcurl (HTTP/HTTPSクライアントとして必要) と --enable-openssl (HTTPS/WSS接続やDTLSに必要なTLS/SSLサポート) が不可欠です。また、一般的に使用されるコーデックを有効化するためのオプションも追加します。

bash
./configure \
--prefix="$HOME/ffmpeg_build" \
--pkg-config-flags="--static" \
--extra-cflags="-I$HOME/ffmpeg_build/include" \
--extra-ldflags="-L$HOME/ffmpeg_build/lib" \
--extra-libs="-lpthread -lm" \
--bindir="$HOME/bin" \
--enable-gpl \
--enable-libass \
--enable-libfreetype \
--enable-libfontconfig \
--enable-libharfbuzz \
--enable-libfribidi \
--enable-libmp3lame \
--enable-libopus \
--enable-libvorbis \
--enable-libvpx \
--enable-libx264 \
--enable-libx265 \
--enable-libtheora \
--enable-libdav1d \
--enable-libaom \
--enable-libv4l2 \
--enable-libxcb \
--enable-libxcb-shm \
--enable-libxcb-xfixes \
--enable-libbluray \
--enable-zlib \
--enable-openssl \
--enable-libcurl \
--enable-nonfree # x264やx265などにGPLまたはnonfreeライセンスが必要な場合

上記のオプションは一例です。それぞれのオプションの意味は以下の通りです。

  • --prefix="$HOME/ffmpeg_build": ffmpegをインストールするディレクトリを指定します。 $HOME/ffmpeg_build の下にライブラリやヘッダーファイルが、 $HOME/bin の下に実行ファイル (ffmpeg, ffprobeなど) がインストールされます。
  • --pkg-config-flags="--static": pkg-config使用時に静的リンクを試みます。
  • --extra-cflags, --extra-ldflags, --extra-libs: カスタムインストールしたライブラリへのパスを指定する場合に使います。上記の例では --prefix と同じ場所を指定しています。
  • --bindir="$HOME/bin": 実行ファイルがインストールされるディレクトリを指定します。システムのPATHに追加すると便利です。
  • --enable-gpl: GPLライセンスのコンポーネントを有効にします（例: libx264, libx265）。
  • --enable-lib...: 各外部ライブラリのサポートを有効化します。
    • --enable-openssl: OpenSSLライブラリを使ったTLS/SSLサポートを有効にします。HTTPSやWSS (WebSocket Secure) でWHIPサーバーに接続する場合に必要です。また、WebRTCのDTLSにも使われる可能性があります。
    • --enable-libcurl: libcurlライブラリを使ったHTTP/HTTPSクライアントサポートを有効にします。WHIPの初期SDP交換やICE候補交換のためのHTTPリクエストに使用されます。
    • その他: libx264, libx265, libvpx (VP8/VP9), libopus, libmp3lameなどは、それぞれH.264, HEVC, VP8/VP9ビデオ、Opus, MP3オーディオエンコードに必要です。これらは使用したいコーデックに応じて有効化します。
  • --enable-nonfree: --enable-gpl に加えて、さらに制限的なライセンスのコンポーネントを有効にします。通常、--enable-gpl と一緒に使用されることが多いです。

configureスクリプトがエラーなく完了すれば、必要な依存関係が検出され、ビルドの準備が整います。もしエラーが出る場合は、エラーメッセージを確認し、必要な依存ライブラリの開発パッケージがインストールされているか、パスが正しく設定されているかを確認してください。

特に --enable-openssl や --enable-libcurl が有効になっていることを確認してください。configureの出力ログに “Enabled protocols:” のリストが表示されますが、whip はffmpegの出力フォーマットとして実装されているため、プロトコルリストには直接表示されないかもしれません。しかし、必要な基盤 (https, http) がlibcurlとOpenSSLによってサポートされていることが重要です。

3.6. ビルドとインストール

configureが成功したら、makeコマンドでビルドを実行します。-j N オプションでN個のジョブを並列実行することで、ビルド時間を短縮できます（NはCPUコア数などを目安に設定）。

bash
make -j $(nproc) # $(nproc)は利用可能なCPUコア数を返すLinuxコマンド

ビルドにはCPU性能によりますが、数分から数十分かかることがあります。

ビルドが成功したら、インストールを実行します。--prefix で指定したディレクトリにファイルがコピーされます。

bash
make install

3.7. インストールの確認

インストールが完了したら、正しくffmpegがビルドされ、WHIPサポートが有効になっているかを確認します。

まずは、インストールしたffmpegの実行ファイルにパスを通します。~/.bashrc や ~/.profile などに以下の行を追加し、ターミナルを再起動するか source ~/.bashrc などで設定を反映させます。

bash
export PATH="$HOME/bin:$PATH"

新しいターミナルを開くか、パスを反映させた後、ffmpegコマンドを実行してバージョン情報などを確認します。

bash
ffmpeg -version

出力されるコンパイルオプションのリストに --enable-libcurl と --enable-openssl が含まれていることを確認してください。

さらに、ffmpegがサポートするフォーマットリストを確認し、whip が含まれていることを確認します。

bash
ffmpeg -formats

出力リストの中に以下のような行があれば、WHIP出力フォーマットが正しく有効化されています。

E whip WebRTC-HTTP ingestion protocol

E は出力 (Encoding) をサポートしていることを意味します。

これで、WHIPサポートが有効なffmpegのインストールは完了です。

パッケージマネージャーからのインストールについて（補足）:

もしソースビルドが難しい場合や、試用目的であれば、パッケージマネージャーからインストールすることも可能です。

  • Debian/Ubuntu: sudo apt install ffmpeg
  • Fedora: sudo dnf install ffmpeg
  • macOS (Homebrew): brew install ffmpeg --with-libcurl --with-openssl (オプションは適宜確認・追加)

ただし、これらの方法でインストールされたffmpegにWHIP出力フォーマットが含まれているかどうかは、OSのバージョンやパッケージのリポジトリによります。インストール後に ffmpeg -formats で whip がリストにあるか必ず確認してください。もし含まれていない場合は、やはりソースからのビルドが必要です。

4. WHIPサーバーの準備

ffmpegはWHIPクライアントとして機能し、ストリームをWHIPサーバーに送信します。したがって、ffmpegでWHIP配信を行うには、まずWHIPプロトコルを受け付けられるサーバー（メディアサーバーやカスタムアプリケーション）が必要です。

WHIPサーバーの構築は本記事のスコープ外ですが、いくつかの選択肢があります。

  • メディアサーバー: Janus Gateway, Mediasoup, Kurento Media Server など、WebRTCに対応したオープンソースまたは商用のメディアサーバーの多くがWHIPインジェストをサポートするプラグインや機能を開発中、あるいは既に提供しています。
  • カスタム実装: Node.js, Python, Go, Rustなど、様々な言語でWHIPエンドポイントを独自に実装することも可能です。
  • テスト用サービス: WebRTC関連の開発者向けに、一時的に利用できるWHIPテストエンドポイントを提供しているサービスがあるかもしれません。

WHIPサーバーのセットアップ方法や設定は、利用するサーバーソフトウェアによって大きく異なります。いずれの場合も、以下の情報が必要です。

  • WHIPエンドポイントURL: ffmpegがPOSTリクエストを送信するサーバーのURLです (例: https://your.whip.server/app/streamkey).
  • 認証情報: サーバーによっては、認証（例: HTTP Basic Auth, Bearer Tokenなど）が必要な場合があります。

ffmpegでWHIP配信を行う際は、このWHIPエンドポイントURLをffmpegコマンドの出力先として指定します。

5. ffmpegを使ってWHIPでストリーミングする

WHIPサポートが有効なffmpegをインストールし、WHIPサーバーのエンドポイントURLが準備できたら、実際にストリーミングを実行できます。

基本的なコマンド構文は以下のようになります。

bash
ffmpeg [global_options] [input_options] -i [input_url] [output_options] -f whip [whip_url]

  • [global_options]: 全体的な設定（例: -y 上書き確認なし）。
  • [input_options]: 入力に関する設定（例: -re 入力をネイティブフレームレートで読み込む）。
  • -i [input_url]: 入力ソースの指定（ファイルパス、デバイス名、ネットワークURLなど）。
  • [output_options]: エンコード設定やストリーム処理に関する設定（例: -c:v libx264 -preset veryfast -c:a libopus -b:a 96k）。
  • -f whip: 出力フォーマットとしてWHIPを指定します。これがWHIP配信の鍵となるオプションです。
  • [whip_url]: WHIPサーバーのエンドポイントURL。

5.1. 主要なWHIP出力オプション

ffmpeg -h muxer=whip コマンドでWHIPミュクサーのオプションを確認できます。主要なオプションは以下の通りです（バージョンによって異なる場合があります）。

  • -whip_buffer_size <bytes>: WHIPストリームの送信バッファサイズを設定します（デフォルトは適切に設定されていることが多いです）。
  • -whip_write_timeout <seconds>: ストリーム書き込みのタイムアウトを設定します。
  • -whip_retry <count>: 接続が失敗した場合のリトライ回数を設定します。
  • -whip_retry_delay <seconds>: リトライ間の待機時間を設定します。
  • -whip_headers <string>: WHIP HTTPリクエストに追加のヘッダーを指定します。例えば、認証情報を含むヘッダー (Authorization: Bearer token) を追加する場合に使用します。複数のヘッダーは Header1: Value1\r\nHeader2: Value2 のように指定します。
  • -whip_user_agent <string>: HTTPリクエストのUser-Agentヘッダーを設定します。

5.2. 具体的なコマンド例

例1: ローカルのビデオファイル (MP4) をH.264/OpusでエンコードしてWHIP配信

bash
ffmpeg -re -i input.mp4 \
-c:v libx264 -preset veryfast -tune zerolatency -b:v 2000k -pix_fmt yuv420p \
-c:a libopus -b:a 96k \
-f whip "https://your.whip.server/app/streamkey"

  • -re: 入力ファイルをリアルタイム（ネイティブフレームレート）で読み込みます。ライブ配信のように動作させる場合に重要です。
  • -i input.mp4: 入力ファイルとして input.mp4 を指定。
  • -c:v libx264: ビデオエンコーダーとして libx264 (H.264) を使用。
  • -preset veryfast: エンコード速度のプリセット。veryfast は比較的低CPU負荷で低遅延に適しています。
  • -tune zerolatency: 低遅延配信向けにエンコーダー設定を調整。
  • -b:v 2000k: ビデオビットレートを2000kbpsに設定。帯域幅に合わせて調整してください。
  • -pix_fmt yuv420p: ピクセルフォーマットを指定（Web互換性のために一般的に使用されます）。
  • -c:a libopus: オーディオエンコーダーとして libopus を使用。WebRTCでよく使われる低遅延コーデックです。
  • -b:a 96k: オーディオビットレートを96kbpsに設定。
  • -f whip "https://your.whip.server/app/streamkey": 出力フォーマットをWHIPとし、指定されたURLに送信します。

例2: Webカメラとマイクからの入力をVP9/OpusでエンコードしてWHIP配信

デバイス名やインプットフォーマットはOSによって異なります。以下の例はLinux (V4L2/ALSA) を想定しています。

“`bash

デバイス名の確認 (Linux)

Video: v4l2-ctl –list-devices

Audio: arecord -L

ffmpeg -f v4l2 -framerate 30 -video_size 640×480 -i /dev/video0 \
-f alsa -ac 1 -i default \
-c:v libvpx-vp9 -b:v 1500k -cpu-used 8 \
-c:a libopus -b:a 64k \
-f whip “https://your.whip.server/app/streamkey”
“`

  • -f v4l2 -framerate 30 -video_size 640x480 -i /dev/video0: V4L2インプットフォーマットで /dev/video0 (Webカメラ) を指定。フレームレートと解像度を設定。
  • -f alsa -ac 1 -i default: ALSAインプットフォーマットでデフォルトのマイク (default) を指定。チャンネル数を1 (モノラル) に設定。
  • -c:v libvpx-vp9 -b:v 1500k -cpu-used 8: ビデオエンコーダーとして VP9 を使用。ビットレートとエンコード速度 (cpu-used オプションはvpx特有) を設定。
  • -c:a libopus -b:a 64k: オーディオエンコーダーとして Opus を使用。
  • -f whip "https://your.whip.server/app/streamkey": WHIP出力先を指定。

例3: RTMPストリームを受信し、WHIPで再配信 (トランスレート)

bash
ffmpeg -i "rtmp://your.rtmp.server/app/streamkey" \
-c:v copy -c:a copy \
-f whip "https://your.whip.server/app/streamkey"

  • -i "rtmp://your.rtmp.server/app/streamkey": 入力ソースとしてRTMPストリームを指定。
  • -c:v copy -c:a copy: ビデオとオーディオを再エンコードせずにそのままコピーします。これは入力ストリームのコーデックがWebRTC/WHIPでサポートされている場合（例: H.264とAACやOpus）に有効です。コーデック変換が必要な場合は、上記例1や2のように -c:v や -c:a でエンコーダーを指定してください。
  • -f whip "https://your.whip.server/app/streamkey": WHIP出力先を指定。

例4: 認証情報が必要なWHIPエンドポイントへの配信

WHIPサーバーが認証を要求する場合、whip_headers オプションを使用して認証情報を追加します。例えば、Bearerトークンを使用する場合：

bash
ffmpeg -re -i input.mp4 \
-c:v libx264 -preset veryfast -tune zerolatency -b:v 2000k \
-c:a libopus -b:a 96k \
-f whip -whip_headers "Authorization: Bearer YOUR_AUTH_TOKEN" \
"https://your.whip.server/app/streamkey"

HTTP Basic認証を使用する場合：

bash
ffmpeg -re -i input.mp4 \
-c:v libx264 -preset veryfast -tune zerolatency -b:v 2000k \
-c:a libopus -b:a 96k \
-f whip -whip_headers "Authorization: Basic YOUR_BASE64_ENCODED_CREDENTIALS" \
"https://your.whip.server/app/streamkey"

Base64エンコードされたクレデンシャルは username:password という文字列をBase64エンコードしたものです。

HTTPS (https://) や WSS (wss://) を使用する場合、ffmpegはOpenSSLとlibcurlを使って自動的にTLS/SSLハンドシェイクを行います。自己署名証明書など、信頼できない証明書を使用しているサーバーに接続する場合は、OpenSSLの設定で検証を無効にする必要があるかもしれませんが、これはセキュリティリスクを伴うため推奨されません。通常は正しく署名された証明書を使用してください。

5.3. 実行中の確認と停止

ffmpegコマンドを実行すると、コンソールにログが出力されます。これにより、入力の読み込み状況、エンコードの進行、そしてWHIPサーバーへの接続試行とストリーム送信状況を確認できます。

接続が成功すると、通常はSDP交換、ICEネゴシエーション、そしてメディアパケットの送信に関するログが表示されます。エラーが発生した場合は、ログメッセージを確認して原因（URL間違い、サーバーエラー、認証失敗、ネットワーク問題など）を特定してください。

ストリーミングを停止するには、ターミナルで Ctrl+C を押します。ffmpegはクリーンアップ処理を行って終了します。

6. トラブルシューティング

ffmpegとWHIPを使った配信で発生しうる一般的な問題と、その解決策をいくつか紹介します。

6.1. ffmpegのビルド失敗

  • 依存ライブラリが見つからない: configureスクリプトが ERROR: ... not found のようなメッセージを出力して停止する場合、必要な開発ライブラリがシステムにインストールされていないか、ffmpegがその場所を見つけられていません。
    • 前述の「必要な依存関係のインストール」セクションを参照し、対応するパッケージがインストールされているか確認してください。
    • カスタムパスにライブラリをインストールした場合は、--extra-cflags や --extra-ldflags でそのパスを正しく指定しているか確認してください。
    • pkg-configが正しく設定されているか確認してください (pkg-config --libs --cflags libname でライブラリ情報が表示されるか)。
  • コンパイルエラー: make 中にエラーが発生する場合、コンパイラやライブラリのバージョン incompatibilities、あるいはffmpegソースコード自体の問題である可能性があります。
    • make コマンドの出力を詳しく確認し、エラーメッセージやスタックトレースから原因を探ります。
    • ffmpegのメーリングリストやフォーラムで同じエラーが出ていないか検索します。
    • gitで最新のmasterブランチを使用している場合、一時的なビルドエラーの可能性もあります。少し時間を置いて再度 git pull してからビルドしてみるか、直前のコミットや安定版ブランチを試してみてください。

6.2. WHIP接続エラー

  • Protocol not found または Output format not found: ffmpeg -f whip ... を実行した際にこのエラーが出る場合、ビルドしたffmpegにWHIP出力フォーマットが含まれていません。
    • ffmpeg -formats を実行し、whip が出力リストにあるか確認してください。
    • ビルド時の configure オプションに --enable-libcurl と --enable-openssl が含まれていたか、そして configure 実行時にこれらのライブラリが正しく検出されたかを確認してください。再ビルドが必要になる場合があります。
  • HTTPエラー（400, 401, 403, 404, 500など）: ffmpegがWHIPサーバーへの初期POSTリクエストでHTTPエラーを受け取る場合。
    • WHIPエンドポイントURLが正しいか、タイプミスがないか確認してください。
    • WHIPサーバーが起動していて、指定されたURLでリクエストを受け付けているか確認してください。
    • 認証が必要な場合 (-whip_headers オプション)、認証情報が正しいか、ヘッダーの形式がサーバーの要求に合っているか確認してください (例: Authorization: Bearer token, Authorization: Basic base64credentials)。
    • サーバー側のログを確認し、リクエストがサーバーに到達しているか、サーバー側でどのようなエラーが発生しているかを確認してください。
    • ファイアウォールがffmpegクライアントからサーバーへの接続をブロックしていないか確認してください。
  • TLS/SSLエラー: HTTPS (https://) URLを使用している場合に発生することがあります。
    • サーバー証明書が有効で、ffmpegを実行しているシステムから信頼されているか確認してください。
    • 自己署名証明書などの場合は、OpenSSLの設定で検証を一時的に無効にする必要があるかもしれませんが、これは推奨されません。
  • ICE/DTLSネゴシエーションエラー: 初期SDP交換は成功したが、その後のWebRTCピアコネクション確立に失敗する場合。
    • サーバー側が正常にSDPアンサーを返しているか確認してください。
    • UDPポート（通常は1024-65535の範囲）がファイアウォールでブロックされていないか確認してください。ICEはこれらのポートを使ってメディアを転送します。
    • NATやファイアウォールの背後にある場合は、TURNサーバーが正しく設定され、ffmpegとサーバー双方がTURNを利用できるか確認してください。
    • ネットワーク環境に問題がないか確認してください。

6.3. ストリーム品質問題

  • エンコード品質が悪い: 映像がブロックノイズだらけ、音声が不明瞭など。
    • ビットレート (-b:v, -b:a) が低すぎる可能性があります。エンコード設定を見直してください。
    • エンコーダープリセット (-preset) が速度重視すぎると品質が犠牲になります。CPU負荷と品質のバランスを調整してください。
    • 入力ソース自体の品質が低い可能性もあります。
  • 遅延が大きい: WebRTC/WHIPの目的である低遅延が実現できていない。
    • エンコーダー設定で低遅延オプション (-tune zerolatency, -flags +global_header, キーフレーム間隔など) が適切か確認してください。
    • ネットワーク帯域幅が不足している可能性があります。ビットレートを下げるか、ネットワーク環境を改善してください。
    • WHIPサーバー側の処理遅延の可能性もあります。サーバー側の負荷や設定を確認してください。
  • フレーム落ち/音声途切れ: ストリームがスムーズでない。
    • ffmpegを実行しているマシンのCPU負荷が高すぎる可能性があります。より高速なエンコーダープリセットを使う、解像度を下げる、ビットレートを下げるなどで負荷を軽減してください。
    • ネットワーク帯域幅が不足している可能性があります。
    • 入力ソースの読み込みに問題がある可能性もあります。 -re オプションが適切に機能しているか確認してください。

ffmpegのログレベルを -v debug または -v trace に上げて実行すると、より詳細な情報を得られます。これにより、SDP交換の内容、ICE候補、DTLSハンドシェイクの状況などが確認でき、デバッグに役立ちます。

7. 応用例

ffmpegとWHIPの組み合わせは、様々なライブストリーミングやWebRTC関連のアプリケーションで活用できます。

  • プロフェッショナルなエンコーダーとしての利用: ハードウェアエンコーダーやOBS StudioのようなGUIツールに加えて、ffmpegを高度な設定が可能なエンコーダーとして使用し、WHIP経由でWebRTCプラットフォームに高品質なストリームを入力します。
  • 既存システムのWebRTC化: 既にファイルベースの処理やRTMP入力を中心としたシステムを構築している場合、ffmpegを使ってRTMPをWHIPに変換することで、既存のインフラを活かしながらWebRTCによる低遅延配信フローを組み込むことができます。
  • カスタムデバイスからのストリーミング: 監視カメラ、特殊なキャプチャカード、センサーデータなどを入力とし、ffmpegで処理・エンコードしてWHIPで配信するシステムを構築できます。
  • Webブラウザとの連携: WHIPで入力されたストリームを、メディアサーバーを介してWebブラウザ（WHEP: WebRTC-HTTP Egress Protocol などを使用）で再生することで、低遅延なライブ視聴体験を提供できます。
  • ビデオ会議システムへの入力: 一部のビデオ会議システムやWebRTCベースのミーティングプラットフォームでは、外部からのWHIP入力を受け付けて、会議参加者への配信ソースとして利用できる場合があります。

これらの応用例では、ffmpegの柔軟な入力、処理、エンコード能力と、WHIPの標準化されたWebRTCインジェスト能力が組み合わされることで、強力なメディアパイプラインが実現します。

8. まとめ

この記事では、メディア処理の強力なツールであるffmpegを、WebRTCベースの低遅延インジェストプロトコルであるWHIPに対応させるための詳細な手順を解説しました。

ffmpegがWHIPクライアントとして機能することで、ファイルやデバイス、ネットワークソースなど多様な入力から、高品質なエンコードを経て、WHIPプロトコルを介してWebRTCサーバーに低遅延でストリームを送信することが可能になります。

WHIPサポートを含むffmpegの利用には、多くの場合、ソースコードからのビルドが必要です。記事では、そのための前提条件、必要な依存ライブラリ（特にlibcurlとOpenSSL）、configureオプション (--enable-libcurl, --enable-openssl, -f whip など）、ビルド、インストールの手順を詳しく説明しました。

また、WHIPサーバーが必要であること、基本的なWHIP配信コマンドの構文、主要なオプション (-f whip, -whip_headers など)、具体的な配信コマンド例、そして発生しうるトラブルシューティングのポイントについても触れました。

ffmpegとWHIPの組み合わせは、プロフェッショナルな配信ワークフローからカスタムメディアアプリケーションまで、幅広いシーンで低遅延なライブストリーミングを実現するための強力な基盤を提供します。この記事が、その導入と活用の一助となれば幸いです。

今後、WHIPおよび関連プロトコル（WHEPなど）の普及が進むにつれて、WebRTCはライブストリーミングの主流の一つになっていくと予想されます。ffmpegのような柔軟なツールがこれらの新しいプロトコルをサポートすることは、技術の進化に適応し、新たな可能性を開く上で非常に重要です。

9. 参考文献・リソース

これらのリソースは、ffmpegやWHIPについてさらに深く学びたい場合に役立ちます。特にffmpegのドキュメントは膨大ですが、各オプションの詳細や、サポートされているフォーマット・コーデックについて正確な情報が得られます。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール