H264エンコーディングの場合、WebRTCはハードウェアアクセラレーションをサポートしないOpenH264を使用します。 WebRTCを含むWebRTCには多くのサードパーティコーデックが含まれています。代わりにFFmpegをどのように使用できますか? 「is_component_ffmpeg = true」は何もしていないようです。
ここでの目標は、ハードウェアアクセラレーションを使用してエンコードし、レイテンシとCPU使用率を削減することです。ハードウェアエンコーダーを実行していますが、それをwebrtcに接続する方法がわかりません。ハードウェアアクセラレーションを使用するのが最も近いオプションです。
FFmpegを使用するにはどこを見る必要がありますか?または外部でエンコードされたh264データストリームを使用しますか?
最終的に、すべてのOpenH264 API呼び出しを独自のエンコーダー呼び出しに置き換えることにより、h264_encoder_impl
を変更しました。
WebRTCは、現在利用可能な帯域幅に適していると判断した場合に、エンコーダーの実装にビットレートとフレームレートを更新するように常に要求し続けます。私たちが使用したHWエンコーダーは、オンザフライでのビットレートの更新のみをサポートし、WebRTCで正常に機能しました。フレームレートは固定値に設定されました。
WebRTCの希望どおりにフレームレートを変更せず、それでも正常に機能したため、指定されたエンコードされたバッファーに対して RTPFragmentationを適切に 実行しただけで、エンコードされたストリームも同じ方法で送信できると思います。
過去にWebRTCプロジェクトのエンコード部分をシャントしようとしましたが、運が悪かったです(すでに複数のWebRTCクライアントにエンコードされているデータをパススルーしたかったのです)。私の印象では、サービス品質と非常に緊密に統合されています。 WebRTCは、現在のネットワークトラフィックに基づいてエンコーダー設定を調整したいと考えています。
私たちが見つけた最善の解決策は、OpenWebRTCプロジェクトのdtlssrtpenc
、nicesink
、およびnicesrc
要素を使用して実際に独自のWebRTCをロールすることです。
https://github.com/EricssonResearch/openwebrtc-gst-plugins
これは簡単なことではありませんでした。 WebRTCには非常に複雑なハンドシェイクがあり、それらのGStreamer要素には多くの特別なフックアップが必要ですが、望ましい結果が得られました。
ああ、ところで私たちの経験では、openh264はWebRTCトラフィックに対して非常にうまく機能し、多くの場合にそれを使用することになりました。