短い答え: 受信側が実際に受け入れることができるプロトコルを選択してください。 SRT は、両端でサポートされ、パスが設定されている場合の寄与オプションです。 RTMP は、エンコーダーからプラットフォーム、または取り込みサーバーへの一般的なハンドオフのままです。ビューアーの再生と配信は、個別に構成されたダウンストリーム ジョブのままになります。
レシーバーから開始し、次にハンドオフを選択します
| 決定ポイント | SRT パス | RTMP path |
|---|---|---|
| Receiver | あなたが制御している、または制御されている SRT 対応コントリビューション レシーバー割り当て済み | パブリッシュ用に指定された RTMP インジェスト エンドポイントまたはプラットフォーム URL |
| トランスポート | UDP ベースの SRT セッション。ライブ モードには、タイミングと再送信の制御が含まれます | 設定されたエンドポイントへの TCP ベースの RTMP セッション |
| ネットワークの質問 | この 2 つは可能ですかピアは相互に接続し、モード、レイテンシ、パスフレーズ設定は一致していますか? | エンコーダーはホストに到達できますか?URL/キーはエンドポイント コントラクトと一致していますか? |
| コーデック質問 | 受信側の受け入れられたコンテナとコーデックを個別に検証する | ターゲットの受け入れられたオーディオ/ビデオ プロファイルを個別に検証する |
| 次に役立ちますジョブ | 運用または運用ワークフローへの貢献 | 取り込みサービスまたは設定された RTMP への公開サーバー |
3 つの共通の決定
- プラットフォームは URL とストリームのみを提供しますkey: そのコントラクトを使用して RTMP を公開します。
- チームは SRT レシーバーを制御します: モード、ホスト:ポート、レイテンシー、およびストリーム ID/パスフレーズが両方で合意されている場合に SRT を使用しますopens.
- SRT コントリビューションは RTMP/RTMPS プラットフォームで終了します: SRT コントリビューションとプラットフォーム パブリッシュ ハンドオフを検証します
SRT ライブ モード は、設定されたレイテンシ ウィンドウと受信機フィードバックを中心に設計されています。ウィンドウを大きくすると、回復にかかる時間が長くなりますが、これは展開上の選択であり、より良い状況を約束するものではありません。 RTMP 互換性も同様にエンドポイント固有です。 RTMP または RTMPS URL を必要とするプラットフォームは、他のコントリビューション レッグで SRT が使用されている場合でも、最終的なハンドオフを決定します。
運用上の変更点
| 最初の前接続 | 記録 |
|---|---|
| [[[CBP] ROT93]]] | SRT |
| 発信者/リスナー/ランデブーモード;ホスト:ポート;待ち時間。使用する場合はストリーム ID またはパスフレーズ。コンテナーとビデオ/オーディオ コーデック。 | RTMP |
完全な取り込み URL、アプリケーション/パス、キー。受信者が宣言したプロファイル。多くの場合、エンドポイントが要求する H.264/AAC。
スクリーンショット、チャット ログ、テスト記録に認証情報が含まれないようにします。
SRT 暗号化とRTMPS は、トランスポート セキュリティに関するさまざまな問題を解決します。SRT は暗号化を使用して設定できますが、RTMPS は TLS 上で伝送される RTMP です。 RTMPS 宛先は、別の RTMP サーバーの取り込みオプションを記述しません。
1 つのコントリビューション パスをテストします
プロトコル デモ
テストするプロトコルを 1 つ選択してください
各デモは手動で起動され、独自の一時リースを保持します。ワークフローを比較する場合は、一致するソース設定を使用します。このページでは、制御されたレイテンシのベンチマークは実行されません。
ライブSRTデモ
ライブSRT接続を試す
1時間有効な一時接続を作成します。Callerモードでパブリッシャーアドレスへフィードを送信し、 Stream IDは空のままにします。 下のMultiviewで視聴するか、Callerモードで受信側アドレスに受信側を接続します。
どちらのタブでも同じ準備されたソースを使用します。プログラム形式をロックし、ビデオとオーディオのコーデック設定をメモし、選択したテスト エンドポイントへの公開者アクセスを許可します。 1 つのプロトコル セッションを開始し、パブリッシャーの状態を確認し、プレビューを検査してから、ワークフローで使用されている場合はダウンストリーム出力を確認します。
結果により、選択したソースが一時パスとそのプレビューに到達したことが確認されます。これは設定チェックであり、比較ベンチマークではないため、遅延、品質、信頼性をランク付けするものではありません。変更された構成を新しいテストとして繰り返し、受信側のログまたはオペレーターに表示される接続データを保持します。
Callaba の適合性 Callaba の RTMP サーバーは、パブリッシャと受信側に個別のアクセス ルールを提供し、オペレータに表示されるアクティビティを表示できます。ゲスト RTMP サーバーは、事前定義されたアクセス ルールなしで開くこともできます。その SRT サーバー
は、互換性のある SRT ワークフローに対応するコントリビューション リソースです。ブラウザの観察とビューアの再生は、個別に構成されたモジュールを使用します。 RTMP パブリッシュ URL はブラウザで再生可能な URL ではありません。
- 次のステップ 構成済みの RTMP リスナーについては、 RTMP サーバー
- とそのアクセス/ライフサイクル制御。 SRT コントリビューション受信者の場合は、SRT サーバー
- を確認してください。 明示的なブリッジの場合は、文書化された RTMP コントリビューションを使用してくださいゲートウェイ
