レイテンシーなしでライブビデオをストリーミングする方法（ffplay、mplayer）と、ffplayで使用できるラッパーの種類は？

Question

レイテンシーの値を最小にしたかったので、さまざまなプレーヤーを使用して複数のライブストリームを再生することをテストしてきました。 gstreamerプレーヤー（gst-launch-0.01）、mplayer、totem、ffmpegプレーヤー（ffplay）を試してみました。たとえば、さまざまな構成値を使用して、それぞれのレイテンシを最小にしました。

ffplay -fflags nobuffer mplayer -benchmark

私がストリーミングしているプロトコルはudpであり、mplayerやgst-launchよりもffplayの方が良い値を取得しています。正直なところ、レイテンシーを低くするためにgstreamerでどのような構成を行う必要があるのかわかりません。さて、私が必要としているのは2つのことです。

100ミリ秒未満の低遅延でライブストリームをストリーミングすることについて、誰かがより良い提案をしているかどうかを知りたいです。私は今100ミリ秒より高くなっていますが、これは私にとってあまり効率的ではありません。
私は現在ffplayを使用しているので、これまでで最高だからです。再生と録画のボタンと3つの画面を使用して、さまざまなビデオサーバーからストリーミングする簡単なGUIを実行したいのですが、使用するラッパーの種類（非常に高速である必要があります）がわかりません。

Wil · Accepted Answer

まあ、本当に低遅延のストリーミングシナリオでは、NTSCを試すことができます。その待ち時間は、理想的には63us（マイクロ秒）未満にすることができます。

品質がNTSCに近づき、レイテンシーバジェットが40msのデジタルストリーミングについては、120Hzでのrsaxvcの回答を参照してください。OverTheAirストリーミングが必要な場合、これは私が見た中で最高の低レイテンシーオプションです。よく考えられており、解像度はハードウェア機能に応じて拡張されます。

デジタルストリーミングを意味し、優れた圧縮率、つまりWi-Fi経由で1080pが必要な場合、今日のコモディティハードウェアで100ミリ秒未満の遅延が必要な場合は、圧縮アルゴリズムが優れた圧縮率を提供するため、多くのコンテキストが必要です。たとえば、Mpeg1はipbbpbbpbbpbGOP（画像のグループ）配置で12フレームを使用しました。ここで、iは実質的にjpeg静止画である「イントラ」フレーム、apはiフレームとpフレームの間のいくつかの動きをエンコードする予測フレーム、およびbフレームです。予測がうまく機能しなかったいくつかのスポット修正をエンコードします。とにかく、60fpsでも12フレームはまだ200msなので、データをキャプチャするためだけに200ms、次にデータをエンコードするため、次に送信するため、次にデコードするため、そしてオーディオをバッファリングするためにCPUが新しいブロックをDMAメモリ領域に送信している間、サウンドカードのデータが不足することはありません。同時に、送信するには2〜3フレームのビデオをキューに入れる必要があります。デジタルディスプレイでの裂けを防ぐためのビデオディスプレイ。したがって、実際には最低15フレームまたは250ミリ秒に加えて、送信にかかる遅延があります。NTSCはアナログで送信されるため、このような遅延はありません。唯一の「圧縮」は2つの卑劣なトリックです：各フレームの半分だけが交互の行として毎回送信されるインターレース、1つのフレームでも奇数、次のフレームでは奇数、2番目のトリックは3つの黒と3つの黒を使用した色空間圧縮です白いピクセルと、表示される色を決定するための位相弁別により、色は帯域の3分の1で送信されます明るさ（ルマ）信号の幅。かっこいい？そして、オーディオには一種の「圧縮」があると言えるでしょう。自動ゲイン制御を使用して、20dBのアナログオーディオ信号を使用して、耳を頭から吹き飛ばして60dBに近い体験を提供できるようにすることができます。ショーとコマーシャルの間の2〜3秒間の無音の間に、AGCが音量を上げたことによるコマーシャル。後で私たちがより忠実なオーディオ回路を手に入れたとき、コマーシャルは実際にはショーよりも大きな音で放送されましたが、それは古いテレビが広告主に与えたのと同じ影響を与える方法でした。

ノスタルジア（tm）によってもたらされたこのウォークダウンメモリーレーン。ノスタルジアブランドのトイレ用石鹸を購入！ ;-)

これは、Ubuntu18.04でストックffmpegとmpvを使用して達成した最高のものです。これには、第3世代IntelCoreプロセッサ以降が必要です。代わりにNVidiaハードウェアコーディングを使用する方法については、ffmpegサイトを参照してください。

ffmpeg -f x11grab -s 1920x1080 -framerate 60 -i :0.0 \ -vaapi_device /dev/dri/renderD128 \ -vf 'format=nv12,hwupload,scale_vaapi=w=1920:h=1080' \ -c:v h264_vaapi -qp:v 26 -bf 0 -tune zerolatency -f mpegts \ udp://192.168.1.201:12345

そして、メディアボックスで：

mpv --no-cache --untimed --no-demuxer-thread --video-sync=audio \ --vd-lavc-threads=1 udp://192.168.1.201:12345

これにより、約3Mbpsで1080p @ 60hzの約250msの遅延が達成されます。これは、wifiを介した番組のストリーミングには問題ありません。 mpvはリップシンクを調整できます（再生中はCTRL +-）。メディア制御のためのデスクトップマウス/キーボードインタラクションのストリーミングには許容できますが、リアルタイムゲームには使用できません（リモートゲームについては、NVidia Shield、Google Stadiaを参照してください）。

rsaxvc · Answer

VLC、ffmpeg、そしてある程度はmplayerのような従来のメディアプレーヤーの問題は、それらが一貫したフレームレートで再生しようとすることであり、これにはある程度のバッファリングが必要であり、レイテンシーターゲットを殺します。別の方法は、着信ビデオをできるだけ速くレンダリングし、他に何も気にしないことです。

@ genpfault そして私はカスタムUDPプロトコルを作成しました。これはRCカーとクワッドの飛行用に計画されています。これは、他のほとんどすべて（解像度、ビットレート、パケットレート、圧縮効率）を犠牲にして、低遅延を目標としています。より小さな解像度では、115200ボーUARTおよびXBEEを超えて実行するようになりましたが、これらの制限の下でのビデオは、期待したほど有用ではありませんでした。今日、320x240構成でテストしています。元のセットアップがなくなったため、ラップトップ（Intel i5-2540M）で実行しています。

レイテンシーの予算を計画する必要があります。これが私が費やした場所です。

買収-125FPSPS3アイカメラを選びました。したがって、ここでのレイテンシーはせいぜい8mS強です。オンボードで圧縮を行う「よりスマートな」カメラ（h264またはMJPEG）は避けてください。また、カメラに何らかの自動露出タイミングがある場合は、カメラを無効にして最速のフレームレートでロックするか、十分な照明を提供する必要があります（現在、私の組み込みWebカメラはAEのために8 FPSしか実行していません）。
変換-可能であれば、直接圧縮できる形式（通常、EyeがネイティブにサポートするYUV形式）でフレームをカメラに出力させます。次に、このステップをスキップできますが、ここでは0.1mSを費やしています。
エンコーディング-特別に調整されたH.264を使用しました。圧縮率を犠牲にして、約2.5mSを要し、将来のフレームのバッファリングを必要としません。
トランスポート-他の多くの無線が干渉することなく正しく動作する場合は、5mS未満のUDP overWiFiを使用しました。
デコード-これは、レシーバーのCPUによってかなり制限されます。エンコーダーは、マルチスレッドでデコード可能な作業を送信することで役立ちます。これは通常、エンコードよりも高速です。今日は約1.5mS。
変換-デコーダーがこの手順を実行する場合がありますが、通常、エンコーダー/デコーダーはYUVを話し、ディスプレイはRGBを話し、誰かがそれらの間で変換する必要があります。私のラップトップで0.1mS。
ディスプレイ-VSYNCがない場合、60 FPSモニターのレイテンシーは最大17mSで、それに加えてLCDレイテンシー、おそらく6ms？それは実際にはディスプレイに依存し、このラップトップのどのパネルかわかりません持っています。

合計は40.2mSになります。

エンコーディング：

当時、X264は私たちが見つけた中で最高のH264-AnnexBエンコーダーでした。ビットレート、slice-max-size、vbv-bufsize、vbv-maxrateを制御する必要がありました。「超高速」と「zerolatency」のデフォルトから始めます。これにより、Bフレームが無効になります。

さらに、フレーム内の更新は必須です！これにより、通常の「I」フレームを切り刻み、次のPフレームと組み合わせることができます。これがないと、ビットレートの需要に「バブル」が発生し、一時的にトランスポートが詰まり、レイテンシが増加します。

エンコーディング-輸送-計画：

エンコーダーは、UDPサイズのH264NALUを生成するように調整されました。このように、UDPパケットがドロップされると、H264 NALU全体がドロップされ、再同期する必要はありませんでした。デコーダーは一種の...バースト...であり、グラフィックの破損が続きました。

最終結果320x240

それは...私のラップトップに向けられたカメラに向けられた携帯電話で確実に測定できるよりも速いです。圧縮率320x240x2B = 150kB /フレーム、3kB /フレーム強に圧縮されています。