9-8 RTSP ストリームサーバー機能の実践チュートリアル

NexVDO SDK 実践チュートリアルのネットワークストリーミング編へようこそ！前の章では、画面のキャプチャ、スナップショットの撮影、そして映像をローカルハードドライブに保存する方法を学びました。しかし、多くの実際のアプリケーションシナリオ（セキュリティ監視センター、遠隔医療手術のライブ配信、またはドローンの映像伝送など）では、遠隔地のコンピュータやスマートフォンでも同期して視聴できるように、映像をネットワーク上に「リアルタイムでブロードキャスト（配信）」する必要があります。

このニーズを解決するために、NexVDO SDK は非常に強力な Broadcast Server Engine（ブロードキャストサーバーエンジン）を提供しています。開発者は複雑な基盤となるネットワークプロトコルを深く理解する必要はありません。わずか数行のコードで、あなたのデバイスを瞬時にプロフェッショナルな RTSP ストリームサーバーへと変身させることができます！

© Blender Foundation | Big Buck Bunny | CC BY 3.0

➤ コアコンセプト：なぜストリーミングには「ハードウェア圧縮」が必要なのか？（帯域幅とデータ量の対決）

プログラムを書き始める前に、説明しておくべき重要な概念があります。映像ストリーミングを行う際、多くの初心者がよく抱く誤解があります：「キャプチャーカードで取得した映像をそのままネットワークに投げてもいいですか？」答えは： 絶対にダメです！

簡単な計算をしてみましょう：1920x1080 の解像度、毎秒60フレーム (60FPS) の非圧縮の生映像 (Raw Data) は、毎秒最大 約 370 MB/s という膨大なデータ量を生成します。しかし、私たちが一般的に目にするローカルエリアネットワーク（LAN）の帯域幅の上限は、通常 100 MB/s 程度しかありません。

もし 370 MB/s の巨大なデータを、帯域幅が 100 MB/s しかないネットワークケーブルに無理やり押し込もうとすれば、結果としてネットワークは瞬時に麻痺し、遠隔地で見ている映像には深刻な 「コマ落ち（ Frame dropped ）」 や、ひどい場合には 「画像の乱れ（ Incomplete frame ）」が発生します。

これこそが、ブロードキャストサーバーエンジンに 「圧縮」機能が必要な理由です！ NexVDO SDK を通じて基盤となるハードウェアエンコーダを呼び出すことで、元々 370 MB/s あった非圧縮映像を、H.264 フォーマットを使用してわずか 32 MB/s（またはそれ以下）の軽量なストリームに圧縮することができます。これにより、映像は 100 MB/s のネットワークチャネルを簡単かつスムーズに行き来できるようになり、完璧で滑らかな再生が実現します。

この物理的な制限を理解すれば、今後の API 実装において、映像と音声の圧縮フォーマットの設定が RTSP サーバーを起動する上で最も重要なステップとなる理由がお分かりいただけるでしょう！

今日は、以前学んだ Callback によるデータ供給メカニズムと組み合わせて、ローカルエリアネットワーク内のすべてのデバイスが接続して視聴できる RTSP ライブ配信アプリケーションを構築します！

➤ Callback の概念の復習 : 9-5 ステータスコールバックと画像スナップショット機能のサンプル

コア API の理解 - ブロードキャストサーバーエンジン

RTSP サーバーを構築するロジックは、実は前の章の Share Record（共有録画）と非常に似ています：「エンジンの作成 ➔ プロパティの設定 ➔ 起動 ➔ Callback でのデータ供給」という流れです。

標準的な使用手順は以下の通りです：

1. QCAP_CREATE_BROADCAST_RTSP_SERVER ：RTSP サーバーエンジンを作成します。
2. QCAP_SET_VIDEO_BROADCAST_SERVER_PROPERTY ：サーバーの映像圧縮プロパティを設定します。
3. QCAP_SET_AUDIO_BROADCAST_SERVER_PROPERTY ： サーバーの音声圧縮プロパティを設定します。
4. QCAP_START_BROADCAST_SERVER ：RTSP サーバーエンジンを起動します。
5. QCAP_SET_VIDEO_BROADCAST_SERVER_UNCOMPRESSION_BUFFER ：Callback 内で映像の非圧縮バッファを継続的に供給します。
6. QCAP_SET_AUDIO_BROADCAST_SERVER_UNCOMPRESSION_BUFFER ：Callback 内で音声の非圧縮バッファを継続的に供給します。
7. QCAP_STOP_BROADCAST_SERVER ：RTSP サーバーエンジンを停止します。
8. QCAP_DESTROY_BROADCAST_SERVER ：RTSP サーバーエンジンを破棄（解放）します。

コアコンセプト：Server（サーバー）と Client（受信側）の役割分担

コードに本格的に入る前に、まずネットワークストリーミングにおける2つのコアな役割、サーバー (Server) と 受信側 (Client) を明確にする必要があります。

1. RTSP サーバー（サーバー側 - 本日の主役） : 私たちが NexVDO SDK を使用して開発するプログラムは、「サーバー」の役割を果たします。その任務はテレビ局のようなもので、まず「RTSP サーバーを作成 (CREATE RTSP SERVER)」し、「映像と音声の圧縮フォーマットを設定 (Set properties for encoder)」しなければなりません。サーバーが起動した後は、ブロードキャストエンジンに映像・音声データを絶え間なく供給する必要があります。サーバーの主な仕事は、画面の準備を整え、ネットワーク上で他の人が接続してくるのを待つことです。
2. RTSP クライアント（受信側 - 視聴者） : これは遠隔地の視聴者、つまりストリームを受信する側を表します。遠隔地のコンピュータにある VLC プレイヤーであったり、後で成果を検証する際に使用する ffplay 再生ツールであったりします。受信側は複雑なキャプチャや圧縮を処理する必要はありません。サーバーの IP アドレスとポート番号さえ知っていれば、接続して高品質なリアルタイム映像を「プル（取得）」して再生できます。

【開発者のまとめ】 : 今日の実装目標は「RTSP サーバーの構築」であるため、これから登場する API はすべて、サーバーをどのように起動するか、エンコードプロパティをどう設定するか、そしてサーバーが動作するためにデータをどう供給するかに焦点を当てています。自分が果たす役割を理解すれば、これらの API を呼び出す際のロジックが非常に明確になるはずです！

QCAP_CREATE_BROADCAST_RTSP_SERVER

この API はサーバーオブジェクトを初期化するために使用されます。ここで、接続に必要なアカウント、パスワード、ポート番号を設定できます。

➤ 開発者のヒント : 接続の URL フォーマットは rtsp://アカウント:パスワード@IP:ポート/session0.mpg になります。デフォルトの RTSP ポートは 554 ですが、サードパーティ製ソフトウェアとの競合を避けるため、8554 などのカスタムポートを使用することをお勧めします！

QCAP_SET_VIDEO_BROADCAST_SERVER_PROPERTY

サーバーがブロードキャストする前に、映像をどのように圧縮するかを設定する必要があります。

⚠️ 落とし穴回避ガイド : 厳格な RTSP ネットワークプロトコル標準に準拠するため、映像フォーマットは H.264 または H.265 に設定する必要があります。

QCAP_SET_AUDIO_BROADCAST_SERVER_PROPERTY

サーバーがブロードキャストする前に、音声をどのように圧縮するかを設定する必要があります。

⚠️ 落とし穴回避ガイド : 厳格な RTSP ネットワークプロトコル標準に準拠するため、音声フォーマットは AAC に設定する必要があります。

QCAP_START_BROADCAST_SERVER

コーデックの設定が完了したら、この API を通じて正式にサーバーエンジンを起動できます。

QCAP_SET_VIDEO_BROADCAST_SERVER_UNCOMPRESSION_BUFFER

➤ 開発者のヒント : 入力された画面をクロッピング（切り抜き）する必要がある場合は、代わりに末尾に _EX が付くバージョンの API を使用してください。

QCAP_SET_AUDIO_BROADCAST_SERVER_UNCOMPRESSION_BUFFER

➤ 開発者のヒント : ここでの pFrameBuffer の音声フォーマットが、前に QCAP_SET_AUDIO_BROADCAST_SERVER_PROPERTYで設定したフォーマットと異なる場合、ユーザーは末尾に _EX が付くバージョンの API を使用して、入力音声の実際のフォーマットをエンジンに伝える必要があります

QCAP_STOP_BROADCAST_SERVER

ブロードキャストを終了する必要がある場合、この API を呼び出すと、SDK はストリーミングを停止します。

QCAP_DESTROY_BROADCAST_SERVER

ブロードキャストを終了する必要がある場合、この API を呼び出すと、SDK はサーバーエンジンを解放（破棄）します。

UI 表示インターフェースの構築

強力なブロードキャストサーバー API について学んだところで、いよいよプロジェクトの実装フェーズに正式に入ります！私たちの RTSP サーバーに柔軟性を持たせるため、ユーザーがネットワークのポート番号をカスタマイズでき、ワンクリックでサーバーの起動と停止を制御できるグラフィカルインターフェースが必要です。

Qt Creator で mainwindow.ui ファイルを開き、以下の手順に従って大改造を行ってください：

ポート番号専用の入力ボックス ( QLineEdit ) の追加

ネットワークのポート番号がコード内にハードコーディング（固定値として記述）されるのを避けるため、ユーザーがインターフェース上で動的に調整できるように、2つのテキスト入力ボックスを追加する必要があります：

• 左側の UI ツールバーから QLineEdit ( 1行テキスト入力ボックス ) を見つけ、メインウィンドウに2つドラッグ＆ドロップしてください。
• 次に、右下のプロパティエディタ ( Property Editor ) で、これら2つの入力ボックスの objectName プロパティを、それぞれ nUdpTcpPort ( RTSP 接続を担当 ) と nHttpPort ( HTTP 接続を担当 ) に正確に命名してください。

RTSP コントロールボタン ( QPushButton ) の作成

入力ボックスができたので、サーバーのライフサイクルを制御するための2つのコアなボタンも必要です：

• 2つの QPushButtons ( ボタン ) をインターフェースの下部にドラッグ＆ドロップしてください。
• それらの text ( 表示テキスト ) をそれぞれ 「START RTSP」 と 「STOP RTSP」に変更します。

• 設定が完了したら、2つのボタンをそれぞれ右クリックし、「Go to slot... (スロットへ移動)」 を選択して、Qt Creator に mainwindow.cpp 内で専用のクリックイベントブロック (on_pushButton_clicked)を自動生成させます。

コード内でのポート番号のデフォルト値の設定

プログラムを開くたびにポート番号を再入力するのは非常に不便です！プログラムの起動時に、これらの入力ボックスに直接デフォルト値を割り当てることができます。 mainwindow.cpp を開き、コンストラクタ MainWindow::MainWindow(...)を見つけて、 ui->setupUi(this); の下に以下のコードを追加してください：

コアコードの記述

mainwindow.cpp を開いてください。「サーバーの起動」、「サーバーの停止」、「ストリームの供給」の3つの部分に分けて記述していきます。

変数の宣言と UI フールプルーフ（エラー防止）メカニズム

ボタンが用意できたら、コード内に2つの非常に重要な保護対策を追加する必要があります。まず、プログラムが起動したばかりの時はサーバーがまだ開いていないため、「STOP RTSP」ボタンはクリックできないグレーアウトの状態になっている必要があります。mainwindow.cpp のコンストラクタ MainWindow::MainWindow(...)を開き、ポート番号の初期化の下に、ボタンの初期フールプルーフ状態を追加してください：

サーバーの稼働中にユーザーが右上の「X」を直接クリックしてウィンドウを閉じてしまうと、サーバーオブジェクトが孤児（オーファン）となり、システムによって 8554 ポート番号が永久にロックされて（固まって）しまいます！

このような悲劇を防ぐために、メインウィンドウの デストラクタ ( Destructor ) 内で、停止ボタンのロジックを強制的に呼び出さなければなりません。 ~MainWindow() を見つけて、以下のコードを追加してください：

実装：START RTSP（サーバー起動）ボタンのロジック

「START RTSP」のスロット関数では、先ほど紹介した「作成 ( Create ) ➔ プロパティ設定 (Set Properties) ➔ 起動 ( Start )」の標準プロセスに従って記述します。最も特別な点は、UI インターフェース上で設定したばかりのポート番号を動的に読み取ることです。

➤ 開発者必修の「パラメータ連動」の極意 : 実践開発において、 Format Changed Callback がトリガーされた時に、ついでに最新のデータをこれらの変数に保存しておく ことを強くお勧めします。マルチストリームエンジンを起動する準備ができ、複雑なコーデックパラメータを設定する必要がある時に、これらの変数をそのまま API に渡すことができます！これには3つの大きな利点があります：

1. 完全な手動設定不要のエラー防止（フールプルーフ） : コード内に幅、高さ、フレームレートを「ハードコーディング（固定値として記述）」する必要がありません。
2. 入力ソースとの完璧なマッチング： エンコーダ (Encoder) が受信する解像度が、現在のハードウェアキャプチャ状態と 100% 一致することを保証します。
3. 動的な変化へのシームレスな適応 : ユーザーが途中で異なる解像度のカメラに変更した場合でも、次回の起動時にパラメータが自動的に更新されます！

実装：STOP RTSP（サーバーの停止と破棄）ボタンのロジック

停止ボタンでは、Stop ( 停止 ) だけでなく、Destroy ( 破棄 ) も絶対に忘れないでください！

Callback のスイッチボードでネットワーク映像を供給する

サーバーの準備は整いましたが、現在その中には映像がありません！ハードウェア信号の処理専用である Callback スイッチボード（メイン処理）に戻り、キャプチャしたすべての NV12 映像と PCM 音声を絶え間なくサーバーに供給（フィード）する必要があります。

➤ Callback の概念の復習： 9-5 ステータスコールバックと画像スナップショット機能のサンプル

最終確認（動作検証）

すべてのサーバー側 (Server) のコードを完成させたこと、おめでとうございます！これから私たちは視聴者 (Client) の役割を演じ、あなたのコンピュータが本当にプロの放送局クラスのストリーミングサーバーへと無事に変身したかどうかをテストします。

Qt Creator の左下にある 「Build and RUN（ビルドして実行）」 （緑色の再生ボタン）をクリックして、プロジェクトをコンパイルおよび実行してください。そして、以下の手順に従って奇跡を目の当たりにしましょう：

1. サーバーの起動 : プログラムがカメラの映像を正常にキャプチャしたことを確認したら、インターフェースの左下にある 「START RTSP」 ボタンを直接クリックします。この時、あなたのプログラムはすでにバックグラウンドでネットワークブロードキャストサービスを開始しています！

© Blender Foundation | Big Buck Bunny | CC BY 3.0

2. ローカル IP アドレスの照会 : デスクトップで右クリックしてターミナル ( Terminal ) を開き、 ifconfig または ip a と入力して、この開発ボードの現在の IP アドレスを照会してください（例：192.168.180.148 ）。

© Blender Foundation | Big Buck Bunny | CC BY 3.0

3. 受信側を演じてストリームをプルする : システムのターミナル ( Terminal ) で、強力なオープンソースの再生ツール ffplayを使用してサーバーに接続します。以下のコマンドを入力してください（IP は先ほど照会した実際の IP に置き換え、ポート番号は 8554、チャンネル名は固定で session0.mpg となります）：

➤ ffmpeg のインストールについてはこちらを復習できます : 9-6 オーディオ・ビデオ録画機能の実践チュートリアル

© Blender Foundation | Big Buck Bunny | CC BY 3.0

4. 成果を楽しむ！ Enter キーを押します！ポップアップした新しいウィンドウに、メインプログラムと完全に同期した、非常にスムーズで高画質なストリーミング映像が表示されたら——おめでとうございます！

© Blender Foundation | Big Buck Bunny | CC BY 3.0

次の課題に挑む準備はできましたか？それでは、次のレッスンでお会いしましょう！