rtsp h256 ストリーミングウェブソフト再生
植物の根や茎
プロジェクトから変更
導入
主流のカメラはストリームをプッシュするためにrtspプロトコルをサポートし、h264ビデオストリームはwebrtcによってデコードされ、再生のためにh5のビデオタグに供給することができます。
サーバー側でデコードした場合、イメージ情報は、バックエンドに加えて、フロントエンドにプッシュされると同時に、情報の伝送に大きな遅延につながる巨大なCPUの圧力をもたらすでしょう。
このプロジェクトの目的は、h265ビデオストリームをソフトデコードし、ウェブエンドで再生することです。 一般的に、ウェブエンドはオーディオの要求なしにビデオ表示を使用するため、オーディオデコードとオーディオ/ビデオアライメントを省くことができます。
アイデア
関連記事やオープンソースプロジェクトを検索することによって、最終的に決定しました：バックエンドは、Web側をリアルタイムでプッシュした後、処理のためにh265ベアストリームを取るために、Webassemblyを使用してffmpegを介してWeb側+ソフトソリューションのブラウザ側でワーカー最終的にリアルタイム監視を表示するためにキャンバスを使用します。
達成の詳細
- h265ソフトデコードは、シングルスレッドでソフトデコードする場合、パケットロスや遅延のために解析速度が十分でない場合、マルチスレッドで解析するためにWebworkerが必要になります。
- 非同期処理のための webworker は、2 つのキーフレーム間のすべてのフレームが同じワーカーで処理されるように、解決策は、バックエンドのデータをプッシュと一緒に naluType にすることです。
- 労働者の処理速度の不整合は、フレームの乱れた出力は、フレームの特定の数をキャッシュするキューの導入は、新しいフレームが順番に挿入されるようになり、効果は非常に明白ではない、遅延につながるでしょう
- 労働者の数は、ビットレートと解像度だけでなく、CPUの性能に応じて調整する必要があり、4労働者6Kビットレート720Pビデオストリーミングマザーボードの温度が直接離陸し、電源をオフに保護します。
使用
dist/h265.html
let video = new Video.Video("playCanvas", url, "ws://.1:32000/ws",10,0)
最初のパラメータはキャンバスの ID です。
2番目のパラメータは、ウェブソケットが接続を確立した後にバックエンドに送信されるrtspアドレスです。
3番目のパラメータはウェブソケットのアドレスです。
4番目のパラメータはウェブワーカーの数です。
5番目のパラメータはキャッシュキューの長さです。
websocketコンテンツ
各パケットはバイナリストリームで、その内容はnalutype + nalu
this.ws.onmessage = function (evt) {
that.tps += 1
let nType = evt.data.charCodeAt(0)
if (nType === 32) {
that.workerIndex += 1
that.workerIndex %= that.options.worker
}
that.events.emit(EventsConfig.DateIn, {
data: evt.data,
index: that.workerIndex,
pts : that.tps
})
};
クライアントが接続すると、rtspアドレスをバックエンドに送信します。
this.ws.onopen = function () {
console.log("Connection open ...")
that.ws.send(that.url);
};
具体的な実践
カメラのビットレートを設定することは良いことではありません、Hikvisionは直接低ビットレートに設定 低ビットレート1080Pストリームをテスト キューなし5ワーカー 基本的なフレーム損失CPU占有率10％〜20％。
アフターマス
バックエンドのプログラマは、フロントエンドは、シンプルなHTMLインターフェイスを記述することができ、非ビジネスのプロジェクトでは、バックエンドの流れを取るには、Webエンドでリアルタイムh265監視を再生するために達成されている書くことを余儀なくされています。
