NVENC SDKを使用してOpenGL フレームをエンコードし、RTSP でストリーミングしています。NVENC は、いくつかの NAL ユニットの形式でエンコードされたデータを提供します。Live555 でストリーミングするには、開始コード(0x00 0x00 0x01) を見つけて削除する必要があります。この操作は避けたいです。
NVENC には、参照できる sliceOffset 属性がありますが、NAL ユニットではなく、スライスを示しています。実際のデータが始まる SPS および PPS ヘッダーの末尾のみを示します。スライスが NAL と等しくないことを理解しています (間違っている場合は訂正してください)。エンコードされたデータに対してすでに単一のスライスを強制しています。
次のいずれかが可能ですか？
RTSP/RTP を介して H.264 を実行しようとするすべての人が、この質問にたどり着くポイントがあるようです。さて、ここに私の2セントがあります：
１）アクセスユニットという概念がある。アクセス ユニットは、エンコードされたフレームを表す一連の NAL ユニット (1 つだけの場合もあります) です。それはあなたが取り組むべき論理のレベルです。エンコーダーに個々の NAL ユニットを提供させたいと言っている場合、エンコード手順によって 1 つの生フレームから複数の NAL ユニットが生成される場合 (例: SPS + PPS + コード化された画像)、どのような動作が予想されますか。そうは言っても、アクセスユニット内のNALユニットの数を減らすようにエンコーダーを構成する方法があります（AUD NALを含めない、SPS / PPSを繰り返さない、SEI NALを除外するなど）-その知識があれば、実際に何をすべきかを知ることができますエンコーダーがフレームごとに単一のNALを提供することを期待し、強制します（もちろん、これはすべてのフレームで機能するわけではありませんが、デコーダーに関する知識があればそれを処理できます）。私'
2) 私が言ったように、私は API に精通していないので、これに答えることができませんが、私はこれを非常に疑っています.
3) SPS と PPS は最初のアクセス ユニット (エンコーダーから取得した最初のビットストリーム) にある必要があり、ビットストリームで適切な NAL を見つけて抽出するか、特別な API 呼び出しがある可能性があります。エンコーダーから取得します。
そうは言っても、実際にビットストリームを実行し、開始コードを解析し、NAL ユニットを抽出して Live555 に 1 つずつフィードするのはそれほど難しいことではないと思います。もちろん、エンコーダーが AVCC 形式でビットストリームを出力することを提案した場合 (開始コードまたは Annex B と比較して、NAL ユニット間のインターリーブされた長さの値を使用するため、プレフィックスを探すことなく次のものにジャンプできます)。それからあなたはそれを使うべきです。RTP だけの場合、自分でトランスポートを実装するのは簡単です。私は、FU-A パケット化を適切にサポートしていない GStreamer で不運に見舞われたので、RTSP の場合、トランスポート インフラストラクチャのオーバーヘッドが大きくなり、 Live555 のようなサードパーティのライブラリを使用するのが合理的です。