SRS は WebRTC 生放送のワンストップ ティーチングを構築します! ! ! ! ! ! _srs webrtc_Xinxin Wuhu のブログ - CSDN ブログ
SRS サービスを使用して、WebRTC Web ページの再生、プッシュ RTMP ストリーム、RTC プル ストリームを構築します。上記の URL はチュートリアルです。
以下の記事を読んでもよくわからない、設定の理由がわからないという方は上記の教則リンクからどうぞ！! !
次に、開発環境でWebRTCの再生設定に成功した後、テスト環境での黒画面の調査手順についてお話しします. 1か月後、黒画面の原因をほぼすべて確認し、最終的に黒画面を解決しました.ソースコードを勉強して画面読み込み問題！
SRSの問題を解決するには、必ずログを見ることが第一です！! ! どうしても解けない場合はソースコードに行って勉強しましょう！! 奇跡的な
黒い画面の理由 1: UDP ポート 8000 に到達できません
rtmp2rtc.conf を使用した後、イントラネット環境でのストリーミングを再生できず、黒い画面が読み込まれる SRS ログを参照してください:
RTC: session STUN done, waiting DTLS handshake.
[2023-01-09 17:13:40.781][INFO][37497][51wk8811] <- RTC RECV #13, udp 1, pps 0/0, schedule 1
[2023-01-09 17:13:40.798][INFO][37497][7hdn7z9p] DTLS: State Passive RECV, done=0, arq=0/0, r0=1, r1=0, len=159, cnt=22, size=146, hs=1
[2023-01-09 17:13:40.799][INFO][37497][7hdn7z9p] DTLS: State Passive SEND, done=0, arq=0/0, r0=-1, r1=2, len=681, cnt=22, size=82, hs=2
[2023-01-09 17:13:40.818][INFO][37497][7hdn7z9p] DTLS: State Passive RECV, done=0, arq=0/0, r0=1, r1=0, len=579, cnt=22, size=300, hs=11
[2023-01-09 17:13:40.820][INFO][37497][7hdn7z9p] DTLS: State Passive SEND, done=1, arq=0/0, r0=1, r1=0, len=554, cnt=22, size=466, hs=4
[2023-01-09 17:13:40.820][INFO][37497][7hdn7z9p] RTC: DTLS handshake done.DTLS ハンドシェイクが SRS ログに出力されない場合は、UDP ポートが接続されていないことが原因であり、DTLS は UDP セキュリティ検出プロトコルです。
次に、最初に UDP ポートを通過します; ps: udp ポートが一般的な netcat コマンド、つまり nc コマンドであるかどうかを確認してください!
ブラック スクリーンの理由 2:候補の構成が間違っている
公式の SRS ドキュメントも、候補の構成が間違っていることを示しています。基本的に問題はここにあります! !
候補構成、公式ドキュメントには、接続は次のように記載されています。
WebRTC | SRS (ossrs.net) 
https://ossrs.net/lts/zh-cn/docs/v4/doc/webrtc#config-candidate候補の値は、接続を確立できる rtc_server の IP アドレスに対応します、通常は設定 * または 0.0.0.0 であり、これら 2 つの値は同じ効果があり、すべて監視されます。また、候補 182.xxx.xxx.xxx などの指定された IP アドレスとして構成することも、候補 $CANDIDATE として構成することもできます。ローカル IP 情報を自動的に取得して SRS に送信します。
候補の構成が完了しました。SRS が開始された後、RTC ビデオを再生すると、SRS ログに次の行が表示されます。
RTC: Use candidates 192.168.2.xxx, 222.213.16.xxx, protocol=udp上記のログでは、192.168.2.xxx、222.213.16.xxx が RTC が接続を確立できる IP アドレスです。
通常、 * または 0.0.0.0として構成できます。
黒い画面の理由 3: SRS のバージョンが低すぎる
これに対する最も直接的な解決策は、最新のソース コードをダウンロードしてコンパイルすることです。
黒い画面の理由 4: 構成の http_api ポートに到達できません
http_api {
enabled on;
#listen 1985;
listen 8127;
}
http_api は WebRTC の非常に重要な構成です. RTC によって再生される Web ページ リクエストは、ここで構成されたポートを介して SRS サービスにアクセスし、ストリームをプルします. プレーヤーの Web ページ F12 でコンソールを確認し、リターンが 200OK であることを確認してください。それに応じて確認してくださいここに問題があります。
黒い画面の理由 5: ブラウザーの問題
SRS公式ソースコードの問題点によると、googleやfirefoxブラウザでは再生できず、黒い画面がグルグル回る。
この問題は、ブラウザーのプロパティに設定を追加する必要があります。次のアドレスで公式の問題を自分で確認できます。
イシュー · ossrs/srs (github.com) https://github.com/ossrs/srs/issues
黒い画面の理由 6: RTMP から RTC へのストリーミング構成が有効になっていない
vhost __defaultVhost__ {
rtc {
enabled on;
# @see https://ossrs.net/lts/zh-cn/docs/v4/doc/webrtc#rtmp-to-rtc
rtmp_to_rtc on;
# @see https://ossrs.net/lts/zh-cn/docs/v4/doc/webrtc#rtc-to-rtmp
rtc_to_rtmp on;
}
}構成では、rtmp_to_rtc on; および rtc_to_rtmp on; は、構成でオンにする必要がある rtmp および rtc ストリームのスイッチです。ストリーム データと黒い画面なしで再生; ブリッジが成功すると、SRS ログに次のように出力されます。
RTMP からの RTC ブリッジ、rtmp2rtc=1、keep_bframe=0、merge_nalus=0
RTMP ストリームから RTC ストリームをブリッジすることを示します。
黒い画面の理由 7: source_id の値は /
これが、ログで source_id の値が / として表示されている場合に発生した理由です。たとえば、以下のようになります。
RTC: 再生開始 url=/live/0211774c929013a7500_MJ_ProtocolServer_1, source_id=/ , realtime=1, mw_msgs=0
source_id の値は / であり、それが空であることを示します。ソース コードを調べたところ、/ が / の場合、source_id と現在の source_id をそれぞれ先頭に追加するだけであることがわかりました。これは、RTC ストリームがまったく見つからなかったことを意味します。
source_id は、RTC_SERVER ソース コードのソース URL に従って、RTC ストリーム マップで対応する RTC ストリームを見つけることに対応します。見つからない場合、source_id は空になります。このとき、source_id が空である理由を確認する必要があります。
上記の理由 6 により、ブリッジング スイッチがオンになっていない場合、source_id も空になります。こちらはブリッジスイッチをONにすると正常に再生できます。
私のログを見ると、ブリッジ ストリームは成功していますが、source_id はまだ空です。これは、ブリッジが成功したことを意味し、マップに RTC ストリームが存在する必要がありますが、RTC_SERVER は、地図。
これは、取得されていないことを意味します。つまり、ソース URL に問題があります。黒い画面の原因を取り除くために独自のさまざまなトラブルシューティングを行った後、最終的にソース コードを調査したところ、ソース URL に問題があることがわかりました。
ログを振り返ってみると、RTMP ストリームをプッシュしたときに次の出力が表示されました。
new live source, stream_url=/域名/08101021122A3A03300_MJ_ProtocolServer_1
source url=/域名/08101021122A3A03300_MJ_ProtocolServer_1, ip=192.168.2.51, cache=1/2500, is_edge=0, source_id=/ストリームをpushする際、RTCにRTMPがブリッジされている場合、RTCストリームのURLは上記のsource url=以降の部分となるため、RTC_SERVERがマップを読み込む際はこのurlを読み込んでストリームを取得する必要があります。
次のように、RTC によって再生される SRS ログを見てください。
RTC: start play url=/live/0211774c929013a7500_MJ_ProtocolServer_1, source_id=/, realtime=1, mw_msgs=0再生開始 URL が上記のソース URL と明らかに矛盾していることがはっきりとわかります, これにより、私自身の黒い画面が表示されました. ストリームをプッシュするときに、ストリームをプッシュするためにドメイン名を持ってきましたが、WebRTC はドメイン名の再生をサポートしていません.ということで、再生時はパブリックネットワークのIP+を使っていたのですが、ポート形式のせいでストリームをプッシュしたときのURLと不一致になり、RTCストリームが取得できないのでsource_idが空になっています。最後に、ストリームを IP ポートの形式でプッシュすることにより、イメージが正常に生成されました。
それでおしまい。
役に立つと思ったら、いいねして集めてフォローすることを忘れないでください。どうもどうも
ここに SRS 公式文書のアドレスを添付してください。