RtspServer の実装と、Live555 に基づく高精細、高解像度、高ビットレートのビデオ伝送の最適化

最近、PC および組み込みプラットフォーム向けの RTSP サーバープロジェクトをいくつか実行しましたが、要件のほとんどはシンプルですが包括的な機能であり、パフォーマンスはさらに強力です。総合的な検討の結果、基本的にlive555をベースに開発を進め、Live555自体の最適化とプログラム内の映像データ伝送の最適化を行った結果、要件を満たしただけでなく、期待を上回るパフォーマンスを実現し、1080p、10Mbpsの高コードレートを実現しました。上記の解像度での HD ビデオのストリーミング。ここでは、いくつかの最適化ポイントを共有します。

なぜ Live555 をベースに開発するのか

実は以前にRTSPサーバープログラムを開発し、それを紹介する記事「Rtspサーバーの設計と実装とRTSP2.0の紹介」を書きましたが、その時の開発目的はRTSPライブブロードキャストの実現だけではありませんでした。 , しかし、それを簡素化するためでもあります。コードはカスタマイズを容易にするように設計されているため、RTSP プロトコルのすべてのインタラクションの詳細が完全に実装されているわけではありません。これに基づいてコードを完全に拡張すると、プロジェクトの進行が遅れる可能性があります。プロジェクトに関する考慮事項に基づいて、私は、RTSP サーバープログラムを開発するための基盤として、よく知っていて優れていると思う RTSP オープンソースプロジェクトである Live555 を選択しました。

Live555 は、開発言語として C++ を使用するクロスプラットフォームのストリーミングメディアソリューションであり、サーバークライアントを含む RTSP 構造全体を実装し、H.264、H.265、MPEG、AAC およびその他のビデオおよびオーディオエンコーディングをサポートしています。非常に有名なオープンソースプロジェクト。RTSP サーバーとして、ソースコードにはローカルファイルのビデオソースのみが含まれていますが、拡張性が高く、Live555 が提供するいくつかの基本クラスに基づいて独自のプロジェクトのニーズに適したサービスプログラムを開発できます。

Live555 アーキテクチャと RTSP データフロー

Live555のコアモジュール

RTSPサーバーとクライアント間の対話プロセス

Live555 ストリーミングメディアモジュールとサーバーの処理フロー

Live555 のストリーミングメディアモジュールは基本的に Source と Sink の 2 つの部分に分かれており、もちろん共通の基本クラス Medium もあります。サーバーの場合、Source はデータソース、Sink はデータ出力であり、ビデオデータは MediaSource を通じて MediaSink に渡され、最終的に RTPInterface ネットワークを通じてクライアントに送信されます。サーバーで使用されるモジュールと継承関係は次のとおりです。

ここに画像の説明を挿入します

上図に示すように、独自の ServerMediaSubsession と MediaSource を完成させることで、ブロードキャストに必要な H.264 エンコードされたデータを live555 に渡し、RTSP ライブブロードキャストを実現できます。

高ビットレート映像データ伝送の最適化ポイント

高解像度および高ビットレートのビデオ画像の場合、各フレームのビデオデータは比較的大きくなり、live555 の最適化は主にメモリの拡張に焦点を当てているため、この値は live555 のデフォルトの内部メモリ処理サイズを超えることがよくあります。バッファサイズ、およびメモリデータのコピーを回避します。以下は、実際の開発とテストに基づいてまとめられた効果的な最適化ポイントです。

拡張フレーム解析バッファサイズ、つまり BANK_SIZE のデフォルト値は 150k で、送信される H264 データフレームのサイズに応じて少なくとも 300k に設定されます。そうしないと、サイズを超えると、Live555 によって破棄される可能性があります。
オーバーサイズのフレームデータに対応するためにも OutPacketBuffer::maxSize サイズを大きくします。そうしないと、データ損失が発生する可能性があります。
RTPInterface で、ソケット送信バッファサイズ、つまり、increaseSendBufferTo 関数のパラメータ値を増やします。
MultiframedRTPSink::sendPacketIfNecessary の場合、sendNext を直接呼び出して、データパケットを送信するための RTP メッセージの形成を試みることができます。この変更の利点は、読み取りデータができるだけ早く送信されることですが、より多くのデータを消費することになります。スレッドの時間。
アプリケーションが独自のスレッドから Live555 にデータを転送するときは、メモリのコピーが Live555 イベントループをブロックするのを避けるために、できればメモリプールを介してメモリのコピーを最小限に抑える必要があります。

上記の修正とアプリケーションの内部コードの最適化により、実際のアプリケーションでは、1080p以上の高解像度HDビデオ、10Mbpsの高ビットレートでのスムーズなライブブロードキャストを実現しました。

ご協力についてはQQまでご連絡ください。(転載の際は作者と出典を明記してください〜)