異常なビデオ画面を特定して分析する方法

バックグラウンド

映像の代表的な画像異常としては、主に「画像のフリーズ」「画像のぼやけ」「画像が表示されない」「画像のぼやけ」の4種類が挙げられます。この記事では、主に画面アーチファクトの状況について紹介します。画面アーチファクトには、アーチファクト、スプラッシュ スクリーン、グリーン スクリーン、ブラック スクリーンが含まれます。ビデオのぼやけは、マルチメディア エンジニアにとって最も一般的な問題の 1 つであり、最も困難な問題の 1 つでもあります。著者はこれまでにもそのような問題に何度か遭遇しました。今日は、私の経験をここに要約して共有します。この記事を読めば、誰もが何かを得ることができるでしょう。

問題を特定する

多くの小規模パートナーは、このような問題に遭遇すると無力感を感じることがよくありますが、その根本的な理由は、ビデオ リンクが明確ではないため、開始できないことにあります。ビデオアーチファクトに遭遇した場合、まずアーチファクトが最初に出現した段階を特定し、次にそれらをレイヤーごとに分析して特定する必要があります。RTC ビデオを例にとると、送信者、サーバー、受信者に分かれており、具体的なプロセスは次のとおりです。

 

ピアエンドの表示が異常であることが判明した場合、トラブルシューティングの順序は次のとおりです。

(1) 受信機を確認します。

(2) 送信側を確認します。

(3) サーバーを確認します。

ローカルエンドの表示が異常であることが判明した場合は、以下の順序で対処してください。

(1) 送信側を確認します。

(2) 続いてサブリンク調査。

受信側プロセス

 

• プレーヤーのプロセス

   rtmp ソリューション プロトコル デコード後処理レンダリング。

   mp4/flv-カプセル化解除-デコード-後処理-レンダリング。

プレーヤーのデータ ソースは、オンライン ビデオまたはローカル ビデオから取得されます。

ローカル ビデオに問題がある場合は、別のプレーヤー VLC/ffplay を使用して最初にローカル ビデオを再生できます。

ネットワーク ビデオに問題がある場合は、デコードする前にデータを保存し、ffplay で h264 を再生してみてください。

プレーヤーの 2 つのプロセスによれば、プロトコル解除またはカプセル化解除の段階にある場合もあるため、その後、h264 ストリームをダンプできます。

• WebRTC受信側プロセス

rtp-jitterbuffer-decoding-post-processing-rendering。

ネットワーク部分:組み込みデバイスは webrtc を使用しており、そのネットワーク カードには重大な帯域幅制限があるため、重大なパケット損失が発生します。さらに、実際のネットワーク状態が劣悪であるため、受信側で重大なパケット損失が発生する可能性があります。生成された画面がぼやけます。

デコード部分:ハードウェア デコードはエラーが発生しやすいです。第一に、さまざまなメーカーによるカスタマイズによるハードウェア デコーダーの違いがあります。多くの互換性の問題があり、エラーが発生しやすくなります。第二に、YUV 形式が異なります。ソフト ソリューションは次のとおりです。一般的には YUV420p、ハードソリューションは YUV420p ですが、NV12 などのデコーダのフォーマット仕様については、デコーダ自体の能力に注意する必要があります。デコード後に YUV データをダンプして、特定の状況を確認することもできます。ダンプを再生した後にデータに緑色の画面やぼやけた画面がある場合は、メモリ アライメントの問題、ダンプ形式が間違っている、または問題が発生している可能性があります。ハードウェアデコーダを使って。

後処理部分:画像フォーマット変換、opengl メモリ調整、GPU データのマルチスレッド同期など。

レンダリング部分：レンダリング時に色ずれが発生します。画像フォーマット変換の計算式のずれか、openglのメモリアライメントの問題である可能性があります。画面割れはダーティ データのレンダリングの問題である可能性がありますが、主な原因は GPU データのマルチスレッド同期の問題です。

送信側プロセス

 

• 収集リンク:カメラ自体からのデータが異常であり、これはハードウェア収集機器、特に一部の USB 外部カメラの異常に属します; 2 つ目は、MJPEG 形式などの元の形式を収集し、収集モジュールで MJPEG を I420 に変換することですパイプライン上で画像フォーマット変換が行われる可能性もあり、異常なデータが発生する可能性があります。

• コールバックリンク:収集したデータを外部にコールバックし、美化などの二次処理を外部で実行しますが、これも異常なデータにつながる可能性があります。一般的な現象は、主に外部モジュールが原因で黒画面、スプラッシュ画面などです。 OpenGL が原因で間違っており、指定された GPU データが埋められないなどの結果が生じます。

• 前処理リンク:画像形式の変換と GPU テクスチャ レンダリング、および関連する前処理ビデオ アルゴリズムには例外が存在する場合があります。

• エンコーディング リンク: h264 コード ストリームをダンプして、エンコーディングによって引き起こされる問題のトラブルシューティングを行います。

• ローカル プレビュー リンク:画像形式の変換と GPU テクスチャ レンダリングでは例外が発生する場合があります。

• 送信リンク: udp 送信ではパケットロスが発生する可能性があります。ネットワークが弱いとキューにデータが蓄積し、データドロップが発生します。I フレームの高速送信など、短時間に大量のデータを送信します。

• ダンプ リンク:通常、上記の問題のいずれが発生しているかを確認するために YUV ダンプを使用しますが、再生中に設定が一貫していない場合、ダンプの形式や実際のサイズなど、ダンプ自体に問題がある可能性もあります。問題が発生します。

サーバー転送

 

• カスケード リンク:カスケード レベル間にコーデック動作 (サーバー トランスコーディング) がある場合、リスクも発生します。

• バッファ リンク:キュー オーバーフローもリスクをもたらします。

 

送信側が正常であることを確認すると、サーバー転送リンクが観察されます。

• SRS リンク: ユーザー 1 がプルしたストリームが正常であれば、SRS リンクが正常であることを意味し、そうでない場合は、SRS サーバーに問題があることを意味します。

• Alibaba CDN リンク: ユーザー 2 が異常であり、Ali CDN リンクに問題があることを示しています。

• Tencent CDN リンク: ユーザー 3 は正常ですが、ユーザー 4 は正常ではありません。これは、CDN2 リンクに問題があることを示しています。

原因分析

上記の問題を特定すると、どのリンクが画面異常を引き起こしたかが大まかに特定できるので、このリンクの原因を分析し、画面異常の具体的な原因を分析することができます。

華平の原因

• 参照フレームが欠落している

  一般に、H.264 コード ストリームには I、B、P の 3 つのフレーム タイプがあります。I フレームはキー フレーム、B フレームは双方向予測コーディング フレーム、P フレームは前方予測コーディング フレームです。

  I フレームはフレーム内圧縮により独立してデコードおよび再生できます。B フレームは、I フレームまたは後続の P フレームが失われるとデコードに失敗し、P フレームが前の I/B/P フレームを失うとデコードできません。 、デコードも失敗します。デコードが失敗する原因となります。参照フレームの損失によって引き起こされるデコードの失敗の場合、一般に画面がぼやける現象が発生します。ぼやけた画面の程度は、デコード対象のフレームに対する失われた参照フレームの重要性に依存します。まず、ストリーミング/再生のコードレベルでは、エンコード後デコード前のビデオフレームデータを破棄しないように注意する必要があります。しかし、実際のシナリオでは、ネットワークの状態が悪くエンコードされたデータを送信できない、システムのメモリが不足しており、キューにこれ以上のフレーム データを保持できないなどの状況で、必ずフレーム ロスが発生します。したがって、このような極端なケースでフレームをドロップする必要がある場合、最も合理的な戦略は、一度に GOP 全体をドロップすることです。つまり、I フレームが失われると、次の I フレームに到達するまでにすべてのビデオが失われます。すべて破棄されるため、プレーヤー側でのデコードアーティファクトを効果的に回避できます。

• プレーヤーがキーフレームからデコードを開始しない

  原理は上記と同じで、キーフレームからデコードを開始しない場合、参照情報の損失によりデコードのぼやけが避けられません。したがって、プレーヤーは、最初のブロードキャストであっても、切断して再接続した後であっても、ビデオの最初のフレームがキー フレームであるかどうかを判断する必要があり、そうでない場合は、最初のキー フレームが到着するまで待ってからデコーダに送信する必要があります。

• コードストリーム内のビデオのサイズが変更される

  多くのライブ配信アプリでは、横画面ライブ配信と縦画面ライブ配信では異なるプッシュストリームサイズが使用されており、プッシュストリームアドレスを変更せずにアンカーが縦画面プッシュストリームから横画面プッシュストリームに変更されると、視聴者が引っ張ったストリームが存在します。たとえば、720 x 1280 から 1280 x 720 など、途中でビデオ サイズが変更されます。プレーヤーはリアルタイムで検出する必要があり、ビデオ サイズが変更された場合は、デコーダーと関連ロジックをリセットする必要があり、そうしないと、デコード ブラーやメモリの範囲外などの異常が発生しやすくなります。

• ハードコーディングとハード解決に関する互換性の問題

  もちろん、Android のハードコードされたソリューションを使用すると、必ず不正な携帯電話に遭遇することになります。ハードコードされたハードコードされたソリューションはエラーを報告することはありませんが、出力画像は確かに異常です。Androidのハードコードされたハードソリューションの互換性の問題、コードは慎重かつ慎重で、モデルの互換性を十分に考慮し、パラメータを簡単に書き込まず、残りはホワイトリスト/ブラックリストに依存して実行できます。ハードコーディングされたハードソリューションには 16 バイトのアラインメントの問題もあります。また、デコード側で互換性がない複数のビデオ スライスの問題が発生し、画面がぼやける問題が発生する可能性もあります。

• ストリーミング側での画像サイズと形式の不適切な処理

  画像の形式とサイズは非常に重要なパラメータであり、厳密に正しく構成する必要があります。たとえば、キャプチャされたビデオが NV21 で、エンコーダが I420 のみをサポートしている場合、エンコードされた画像には当然色の問題が発生します。たとえば、シーンの切り替えの過程で、フロントカメラとリアカメラが切り替わり、ビデオのサイズが変化する場合がありますが、トリミング、処理、およびエンコードモジュールはそれに応じてサイズを変更しないため、さまざまなビデオ障害現象も発生します。現れる。

• 画像フォーマット変換

  YUV および RGB 画像形式の変換はビデオ コーデックに必ず関係しており、YUV の形式は多数あります。変換形式やアルゴリズムが間違っている場合も、ビデオのぼやけが発生します。この問題は、ビデオのレンダリングまたはビデオ処理の段階で発生します。YUV および RGB 画像フォーマットの変換によって引き起こされる画面のぼやけ現象は、判断できないものが多くありますが、基本的にこの理由が原因であると判断できる状況が 1 つあります。

(1) 画像の白黒データは正常ですが、色かぶりや乱れなどの異常な色がある場合。

(2) 全体的な画像はまだ認識できますが、明らかな色の斑点があります。

(3) 画像は正常に見えますが、色をよく比較するとわずかなずれがあります。YUV 形式と RGB 形式間の主な変換では、変換行列の違いに注意する必要があります。

 

• ダーティデータをレンダリングする

  レンダー ダーティ データは、レンダリングがまだ終了していないデータです。具体的には、ビデオ フレームが半分にレンダリングされると、次のリンクに送信されます。この問題は、ビデオ レンダリング (オフスクリーン レンダリングを含む) 中に発生します。このような問題は、GPU データのマルチスレッド問題として分類できます。

(1) 画像に明らかな破れやずれがあり、ダーティデータをレンダリングした結果、画像の半分が現在のフレームのデータ、残りの半分が前のフレームのデータになります。

(2) ダーティ データをレンダリングしても、通常は持続的なブラーが発生することはありません。

• YUV ストライドのアライメントの問題

 

外部レンダリングの場合、データが実際の Stride 値に従って読み取られてレンダリングされず、Width に従って読み取られる場合、通常の画面コンテンツと UV カラーに問題が発生します。デコードされたビデオ データ ダンプの場合、デコードされたストライド値が幅より大きい場合、ダンプの YUV データには緑色のエッジが含まれます。これらはすべて、メモリ調整のカテゴリに分類されます。Androidの一部機種のハードウェアエンコードでも発生しており、エンコード後のデータUV表示が異常になります。

スプラッシュスクリーンの理由

スプラッシュ スクリーンの問題の根本的な原因は、再生プロセス中に 2 つの異なる画面が前後に切り替わり、「スプラッシュ スクリーン」のように見えることです。たとえば、2 つの白黒画像が交互にレンダリングされます。

• プレーヤーのバッファリングメカニズムの理由

ネットワークが悪い場合、プレーヤーは頻繁にバッファリングします。以前、ライブ配信アプリがバッファリング中に広告画像を使用するケースに遭遇しました。ネットワークが非常に弱い状況では、頻繁にバッファリングが発生し、実際の再生画面と広告が表示されます。映像が素早く切り替わり、ちらつき現象が発生します。

この状況は、プレーヤーのバッファリング戦略によって完全に回避できます。各バッファリングの後、フレームを受信した直後にレンダリングするのではなく、より多くのデータを適切にバッファリングしてから、バッファリング終了メッセージを送信することで、頻繁なミリ秒が生成されるスプラッシュ スクリーンが生成されます。レベルバッファの切り替え。

• ストリーミング配信の理由

ストリーミング側でスプラッシュ スクリーンを生成するストリームは、重畳された透かし、カメラ/画像の切り替えプッシュ ストリーム、共同ホスティングなどの画面合成を備えたコード モジュールで頻繁に発生します。画像を合成する際の注意点は、いずれの場合も合成画像と非合成画像が入れ替わることを避ける必要があります。

• GPU データのキャッシュの問題

特に、PBO によるダブル バッファリングの誤った処理、以前のテクスチャ データと既存のテクスチャの交互使用の問題などです。特定の機能モジュールがオンとオフを繰り返す場合、その機能モジュールはテクスチャ キャッシュを処理しません。これは、テクスチャが多重化されていることが多いためです。これにより、機能がオフになり、最後のフレームを保存し、その後機能がオンになります。 CPU から GPU への非同期の理由により、最後のビデオ フレームである可能性がある最新のビデオ フレームをすぐに使用することができず、ちらつきの問題が発生します。

• 消費者向けシンクマウントの問題

2 つのデータ ソースが同じコンシューマ シンクにデータを送信すると、明らかなスプラッシュ スクリーンの問題が発生します。

グリーンスクリーンの原因

• 場合によっては、一部の USB カメラに異常があり、画像が緑色の画面で表示されることがあります。

• ビデオのマルチスライスの問題は、デコード側でこの状況と互換性がないため、グリーン スクリーンの問題が発生します。

• デコードエラーがあると緑色の画面が表示されます。

 

黒い画面の原因

• アンカー側のカメラ許可の問題

  Android、iOSに関わらず、アプリはカメラの使用許可を申請する必要があり、特にAndroid 6.0以降では、アプリレベルで特別な処理を行わないとカメラの許可が無効になる可能性があります。アプリがカメラの許可を取得しない場合、ビデオは正常にキャプチャされず、起動されたストリームの音声データのみが生成されます。解決策: アプリ レベルでは、許可の問題は慎重に処理する必要があり、対応する許可が取得されていないことが検出された場合、ブロードキャストが禁止されるか、アンカーに繰り返し許可を与えるよう求められます。また、カメラのプレビュー画面があるかどうかをアンカーに尋ねることもできますが、アプリに権限がない場合はプレビュー画面はありません。

• カメラのフレームアウト問題

  カメラを起動した最初の数フレームは、カメラの露出の問題により、画面の明るさが十分でないことがよくあります。Android端末では、システムROMの問題により、高フレームレートを選択するとカメラの画像処理に問題があり、黒いフレームが表示される場合があります。

• アンカー側でエンコードに失敗しました

  ビデオ データが収集された後、次のステップはエンコーダを通過することです。一部のモデルのパラメータ設定またはハードコードされた互換性の問題により、データがエンコーダに送信された後、エンコードが失敗し、出力がないため、ビデオ データはストリーミング モジュールに送信されません。解決策: 一般に、プッシュ ストリーム SDK はプッシュ ストリームのリアルタイム ビデオ フレーム レートをカウントし、CDN サーバーもフレーム レートを監視します。したがって、これらの統計によって取得されたプッシュ ストリームのフレーム レートが0 と同時に、データが収集されていないことを確認します。これは主にエンコーダーの原因であるため、モデルのログをチェックして特定のエラー メッセージを確認する方法を見つけることができます。

• ビデオキャンバスの問題

  キャンバス マウントが正しく設定されていない場合、またはキャンバスが表示されていない場合、ユーザーは画面を見ることができません。ビデオのレンダリングが異常であるため、画像を正しくレンダリングできず、黒い画面が表示されます。

• ビデオのデコードに失敗しました

  プレーヤーがサポートされていないビデオ形式に遭遇した場合、またはデータのコンテンツ/形式が異常である場合、デコードに失敗し、デコードされたビデオ出力が得られません。サポートされていない形式の場合: サポートされていない形式の再生を避けるために、H.264、mp4v、aac など、プレーヤー自体がどのオーディオおよびビデオ形式をサポートしているかを事前に確認してください。ハードまたはソフト デコードが失敗した場合、プレーヤーはログにエラーを報告するか、ユーザーにアプリケーション層を思い出させる例外をスローする必要があります。ビデオ データ コンテンツ エラーの場合は、コード ストリーム ファイル自体を分析する必要があります。一般的なデータ コンテンツ エラーが原因で発生する いくつかのタイプがあります。

(1) デコーダに送信されたフレーム データが不完全です。

(2) H.264 ビデオ ストリームには、SPS や PPS などの必要な情報ヘッダーがありません。

(3) iOS 用の VideoToolbox デコードは、avcc モードでパッケージ化された H.264 データのみをサポートします。

(4) 一部の Android モデルのハードコーディングされたデータには、余分な naul ヘッダーがあります。

(5) ビデオのマルチスライス問題には対応していません。

• 異常なGPU動作

テクスチャと描画ウィンドウのデータはメモリであり、メモリ作成後の初期値は0、RGBAに対応する色は0、つまり黒画面となります。

したがって、次の状況では黒い画面が表示されます。

(1)ビューポートが正しく設定されていない: OpenGL はレンダリング領域のサイズと位置を知る必要があるため、ビューポートが正しく設定されていない場合、黒い画面が発生する可能性があります。

(2) 投影行列 (Projection Matrix ) が正しく設定されていない:投影行列はスクリーン上のオブジェクトの位置とサイズを決定します。投影行列が正しく設定されていない場合、黒い画面が発生する可能性があります。

(3) モデル ビュー マトリックスが正しく設定されていない:モデル ビュー マトリックスは、世界座標系でのオブジェクトの位置、回転、スケーリングを決定しますが、正しく設定されていない場合、黒い画面が発生する可能性があります。

(4) 深度バッファ (Depth Buffer) が正しく有効になっていない:深度バッファは、遠くのオブジェクトが近くのオブジェクトを遮るのを防ぐことができます。深度バッファが有効になっていない場合、黒い画面が発生する可能性があります。

(5) カラー バッファとデプス バッファが正しくクリアされていない:各描画の前に、カラー バッファとデプス バッファをクリアする必要があります。クリアされていない場合、黒い画面が発生する可能性があります。

(6) シェーダ エラー:頂点シェーダまたはフラグメント シェーダのコンパイル エラー、リンク エラーなど、シェーダ プログラムにエラーが発生し、黒い画面が表示される可能性があります。

(7) 間違ったテクスチャ形式が使用されている:間違ったテクスチャ形式が使用されている場合、黒い画面が発生する可能性があります。たとえば、OpenGL ES 2.0 を使用する場合、圧縮テクスチャ形式は使用できません。使用しないと、黒い画面が表示されます。

(8)空のテクスチャをレンダリングするか、使用する FBO を正しくバインドしないと、黒い画面が表示される場合があります。

(9)異なるスレッドにおいて、共有 OpenGL コンテキストを使用しない場合、テクスチャ データをスレッドをまたいで使用することはできません。

(10) コンテキストがない場合、GL 操作を使用した結果は黒い画面になります。

要約する

異常なビデオ画像は、多くのオーディオおよびビデオ関係者が直面する必要がある問題であり、このような問題のトラブルシューティングの効率を向上させるには、効率的に特定して分析する方法が最も効果的な手段です。この体系的な記事が、普段疑問を抱いている友人の助けになれば幸いです。千里の道も一歩から始まる複雑な問題に直面したとき、私たちはより良いイノベーションを起こすために物事の本質を解き明かし、把握する必要があることがよくあります。