デバイスが必要です, SDIを使用したフルHDカメラビデオの情報を受信するには (シリアルデータインターフェース) 回線上で情報を H.265 標準でエンコードします. 圧縮データはいずれかの DVB-T で送信する必要があります (地上波デジタルビデオ放送) またはDVB-S規格. 設計されたモジュールのアナログ出力は、I 信号と Q 信号の両方を受け入れることができます, 変調信号だけでなく.
目次
Q: SDI ビデオ エンコーダは TSI 入力をサポートしていますか / 出力?
A: 当社の既存のエンコードボードから変調ボードへネットワークポート経由でデータを送信します。. あなたが言及したTSIインターフェイスではなく. これは、送信機から受信機への使用には影響しません。. これは送信機の内部インターフェースです.
Q: エンコーダ デコーダ ボードはサポートしていますか 525 i50から 1080 ビデオフォーマットのP60?
A: SDI ビデオ エンコーダ ボードが HD をサポートするようになりました。: 720p @ 23.98Hz/24Hz/25Hz/29.97Hz/30Hz/ 50Hz59.94Hz/60Hz および 1080p @ 23.98Hz/24Hz/25Hz/29.97Hz/30Hz/50Hz/59.94Hz/60Hz. サポートしません 525 i50ビデオフォーマット, 大丈夫ですか？
Q: SDI COFDM DVB-T H265 SDI エンコーダ RF 出力電力は 0 ～ 10dBm をサポートしていますか?
A: 必要な出力周波数ポイントは 400Mhz から 2800Mhz まで非常に広いです.
このような広い周波数点で 0 ～ 10dBm の出力を達成することは困難です, ボードにパワーアンプを追加すると、消費電力と発熱が増加します。 (放熱用のファンは必要ないとも言っていましたね).
私たちの既存の内容に同意しますか? -3 -10dBm出力に設定し、独自のPAを追加します (パワーアンプ)?
Q: COFDM DVB-T H265 SDI エンコーダの寸法はどれくらいですか??
特別な寸法のご要望はありますか? 現在のサイズは70x45mmです.
A: 当社の既存のビデオ エンコーダおよびデコーダ ボードはプロジェクトのニーズを満たすことができます.
私のエンジニアの最大の心配は、あなたの会社が, 放送およびテレビ業界の一員として、画像ビデオ品質に対する要求は比較的高い.
当社のビデオ エンコーディング ボードは非可逆圧縮を実行して低遅延を実現します。. 画質をテストして確認するために既存のサンプルのセットを採取してもらえますか? 当社のサンプルが貴社の要件を満たせると思われる場合, 御社の要件に応じてボードを再設計して描画します.
Q: VBR について詳しく教えていただけますか?
TXにビデオを適用することで, VBR パラメータは時間の経過とともに変化し、静的な値ではありません. これについてさらに詳しい情報を提供していただけますか?
A: VBR は送信機でのビデオ エンコード ビット レートです。. 映像がダイナミックに変化するので, VBRはもちろん可変, ただし、伝送システムによって設定されたエンコード ビット レートを中心に変動します。: 7.81*0.8=6.248Mbps.
Q: 受信機にフラッシュストレージがあるにもかかわらず, 画面にREC OFFとNo Storageが表示される. なぜこのようなことが起こっているのか?
説明文で言ってましたね: KEY2: ビデオ録画用の切り替えボタン, 短押ししてステータスを変更します. 受信機は自動的にストレージデバイスをチェックします (マイクロSDカードまたはUSBディスク, 優先SDカード) 電源を入れた後、ストレージデバイスが挿入されるとビデオの録画が開始されます. ボタンを押すだけで停止または再度録音できます.
A: 受信側システムが USB フラッシュ ドライブを検出できません. USB フラッシュ ドライブは、システムが認識できる形式にフォーマットする必要があります.
Q: B1 と B2 は両方ともゼロです. これは、 0 % バイトエラー率!!! これらのパラメータのどの範囲が許容されるか?
A: ビットエラーレートが発生すると映像に問題が生じる可能性があります. ビットエラーレートが非常に小さい場合, ビデオ画像効果には影響しません.
Q: プログラマ画面の内容をカスタマイズできますか?
A: 設定パネルの表示内容 (プログラマー) お客様による変更は受け付けていません.
Q: S2 チャネルがプログラムされていないのはなぜですか? 2番目のチューナーが現在機能していないようです.
A: S2 は受信アンテナを指します 2, 正常に動作できるもの. 周波数と帯域幅は同じ s1 と s2.
Q: 計算したレイテンシが非常に大きい理由? あたりです 470 ミズ.
これからのあなたの説明では: 当社の受信機モジュールのデフォルトの通常機能は、H.265 送信機モジュールとペアリングできます。. 送信機の入力から受信機の HDMI 画面表示までの HD ビデオ遅延は約 200ms ～ 250ms です。.
A: テストした遅延は約 250ms でした. どのようにテストしましたか? 私たちがテストした遅延方法, をチェックしてください Youtubeビデオリンク.
Q: SDI エンコーダ トランスミッタおよびデコーダ レシーバ モジュールのレイテンシはどれくらいですか?
遅延を改善するためにプロトコルを最適化したとおっしゃっていたのを覚えています. 高速な H.264 遅延を使用しないため、 (130 ミズ) 私のセットアップではどれくらいのレイテンシーが必要ですか?
A: H265 をサポートする必要があることを確認しました, ただし、H264 低遅延モードではありません. 低遅延モードを実現するには, 受信機を別の受信機ハードウェアに変更する必要がある, 出荷前に対応するファームウェアを書き込む必要があります.
Q: COFDM レシーバーを使用して通常の DVB-T TV チャンネルを取得できますか?
TX の遅延を改善するためにビデオ プロトコルを変更したと言いました. RX を商用 DVB-T として使用できますか? 通常の DVB-T チャンネルを受信するにはどうすればよいですか?
A: どうしても通常のDVB-Tレシーバーとして使いたい場合, 別のファームウェアをアップグレードする必要があります. (エンコーダーの暗号化とデコーダーの復号化を削除します。).
Q: COFDM受信機でOSDメニュー機能を使用するにはどうすればよいですか?
これからのあなたの説明では:
受信機モジュールには、Micro SD カードまたは USB ディスクを使用した DVR 録画機能も含まれています. レシーバー モジュールにより、スマートフォンや Android PAD などのリモート Android デバイス デコーダに対して USB 経由でのビデオ ストリーミングも可能になります。. これにより、複数のリモート視聴者が同じビデオを監視できるようになります。
同時に. 受信機モジュールは、OSDモードでビデオと一緒にビデオ表示画面に文字列を表示することもサポートしています.
A: 見る OSDオンラインドキュメント.
Q: AES暗号化を有効にするにはどうすればよいですか? どこにキーを入力すればよいですか?
A: 設定パネルではパスワードを編集および変更できます.
Q: 弓のテキスト画像の質問を示してください:
A: このオプション機能は他の製品に必要です (ネットワーク ポート機能は双方向ワイヤレス リンクに接続するために使用されます。). アプリケーションでは無視してください.
Q: 片方向送信における UART データの遅延時間はどれくらいですか??
TX から RX への UART データの場合, エンコードプロセスを通じて処理されたデータ、またはリアルタイムで送信されたデータです? リアルタイムのデータ転送が必要です.
A: データとビデオはワイヤレス cofdm パッケージを介して一緒に送信されます. つまり遅延はビデオと同じです.
Q: 送信機用. 説明内の表に従って、GI、FEC、および別のパラメータを変更することが可能です?
A: はい.
Q: この時点での正確なパワーはどれくらいですか 1350 に 1450 メガヘルツ? PAを設計するにはこの情報が必要です.
1350～1450周波数帯域の最大出力は約-10±2dBmです。. -15dBm 入力に基づいて PA を設計することをお勧めします。. 当社の送信機は-15dBmまで調整可能です.
Q: あなたのプログラマーには工場出荷時の状態にリセットする機能がありますか??
周波数GI、FEC、ビデオ帯域幅などのいずれかの側のパラメータを変更した場合, 工場出荷時リセットモードですべてのパラメータをリセットするにはどうすればよいですか? 私はこの掲示板を初めて利用します, 希望を達成するにはいくつかのパラメータを変更する必要があります. でもデフォルトの情報を変えるのは怖い.
A: 私たちのTX / RX プログラマーには工場出荷時設定へのリセット機能がありません.
Q: SDI ビデオ入力エンコーダは 1080i25/1080i30 をサポートしていますか??
1080i50および1080i60をサポートします, 1080i25 または 1080i30 はサポートされていません.
Q: いくつかの技術ファイルを提供していただけますか の電源部分の修理に Vcan1731 SDI ビデオ エンコーダ ボード?
A: 以下のリンクからファイルを確認してください.
- https://ivcan.com/wp-content/uploads/Vcan1731-Component-Part-Number-Map-1.pdf
- https://ivcan.com/wp-content/uploads/Vcan1731-Component-Part-Number-Map-2.pdf
- https://ivcan.com/wp-content/uploads/vcan1731_A01_power.pdf
当社のメンテナンスの考え方は、まず短絡の有無と短絡の場所を特定することです。. 例えば, 電源ICと後続回路の間の磁気ビーズまたは0Ω抵抗を外してください。, マルチメータを使用して、パワーICが壊れているか、後続の回路がショートしていないかを測定します。. 電源ICが壊れた場合, 電源ICを交換してください; 後続回路が短絡した場合, 後続の回路を確認する必要があります.
Q: エンコーダボードは UDP 通信を通じて UART データを受信および転送できますか (IP:ポート)?
A: はい, UART データ送信は、当社の以下の条件でサポートされています。 デフォルトのカスタムプロトコル, いくつかの重要な考慮事項とともに:
1. カスタムプロトコル (デフォルトのファームウェア)
デフォルトの出荷ファームウェアでは、 カスタム多重化プロトコル サポートするもの UART透過伝送 (シリアルパススルー).
- UART データはオーディオ/ビデオ ストリームとともに多重化されます.
- 故に, 受信側は対応するものを使用する必要があります カスタム プロトコル デマルチプレクサ ライブラリ UART データをメディア ストリームから分離するため.
- 弊社デコーダーボードと併用の場合, UART 透過送信は適切に動作し、期待どおりに転送/受信できます。.
PCプレイヤー向けの注意事項
現在の PC プレーヤー ソフトウェアは、多重化解除と処理のみを行っています。:
- 映像データ
- 音声データ
現在のところ, それはあります ではありません UARTシリアルデータを処理または出力する.
2. 標準 MPEG-TS プロトコル
エンコーダボードがフラッシュされている場合は、 標準 MPEG-TS ファームウェア/プロトコル:
- オーディオとビデオのストリームのみがサポートされています.
- UART/シリアルデータ送信は サポートされていません MPEG-TSモード時.
ファームウェア/プロトコル ソリューションを選択する際は、これを考慮してください。.
| プロトコルの種類 | オーディオビデオ | UART透過伝送 |
|---|---|---|
| カスタムプロトコル (デフォルト) | サポートされています | サポートされています |
| 標準MPEG-TS | サポートされています | サポートされていません |
Q: UDP ストリーミング用の MPEG-TS ではなく、生の H.264 または RTP をサポートするファームウェアはありますか??
A: 当社の UDP ファームウェアは生の H.264 エレメンタリ ストリームを送信しません. UDP ストリーミングは、ファームウェアのバージョンに応じて 2 つの形式でサポートされます:
- A カスタム独自フォーマット, 若しくは
- ザ・ 標準MPEG-TS (MPEGトランスポートストリーム) フォーマット
これらはさまざまなファームウェア ビルドに対応します (通常、「T」バージョンまたは「T」以外のバージョンなどの接尾辞によって区別されます。).
Q: RTP をスタンドアロン ストリーミング プロトコルとしてサポートしていますか??
A: 個別の「raw RTP ストリーミング モード」は提供しません。しかし, RTP は RTSP ストリーミング内ですでに内部的に使用されています. RTSPモードの場合, オーディオとビデオは、RTSP/RTP/RTCP スタックの一部として RTP パケットを介して送信されます。. 故に, RTP は、独立した UDP ストリーミング形式としてではなく、RTSP を通じて間接的にサポートされます。.
Q: システムは生の H.264 over UDP を出力できますか?
A: いいえ. 未加工の H.264 エレメンタリ ストリームの送信は UDP ではサポートされていません. これはパケット サイズとネットワークの制約によるものです. 1 つの I フレームは非常に大きくなる可能性があり、1 つの IP パケットで確実に送信することはできません。.
安定した伝送のために, ビデオ ストリームは、次のようなトランスポート形式を使用してカプセル化する必要があります。:
- MPEG-TS, 若しくは
- RTP (RTSP経由)
Q: キーフレームはどうですか (共和党) 設定された間隔?
A: キーフレーム間隔は、 GOPパラメータ Webインターフェースで (ビデオ設定ページ).
- GOP が に設定されている場合 0 (デフォルト/自動モード), システムは I フレーム間隔を入力フレーム レートに自動的に調整します。.
- 例: 入力が 1080P60, I フレーム間隔は次のようになります。 60 フレーム (1 2番目の共和党).
これにより、入力ソースの特性に基づいた適応的なエンコード動作が保証されます。.
Q: 未加工の H.264 を IP/UDP 経由で直接送信できないのはなぜですか?
A: H.264フレームなので (特にIフレーム) 非常に大きくなり、最大伝送単位を超える可能性があります (男) ネットワークパケットの. カプセル化なし, 確実な配達は保証できません. 故に, ビデオを適切にセグメンテーションするには、MPEG-TS や RTP などの標準化されたストリーミング形式を使用してパケット化する必要があります, タイミング, そして再組み立て.
Q: 私のシステムの遅延は合計約 230 ミリ秒です. デコーダと表示には最大 45 ミリ秒かかります, カメラとエンコーダに約 185 ミリ秒を残す. カメラが最大 60 ミリ秒の影響を与えると予想します (4 のフレーム 60 FPS), したがって、エンコーダは約 120 ミリ秒であるようです. エンコーダのレイテンシを短縮する方法はありますか? MPEG-TS は主にデコードに影響を与えると理解しています, エンコードしていない.
A: レイテンシーの内訳と最適化のガイダンス
システム遅延を正確に最適化するには, ボトルネックを想定する前に、まず各段階を個別に検証することが重要です.
1. 最初にカメラの遅延を確認する (クリティカルステップ)
エンコードを最適化する前に, 実際のカメラの寄与を確認する必要があります.
実践的な測定方法:
- カメラのHDMI出力をディスプレイに直接接続します
- 別の PC モニターに表示される高精度ストップウォッチにカメラを向けます
- ライブシーンとHDMI出力の両方を同時にキャプチャ
- フレームのタイムスタンプを比較して、エンドツーエンドのカメラ遅延を計算します
ノート:
- 高精度のストップウォッチを使用する (ティック間隔を小さくすると精度が向上します)
- 多くの場合、カメラ ISP 処理が主な原因となります
- 私たちの経験では:
- 1080p カメラでは通常、最大 100 ミリ秒の遅延が発生します
- 一部のモデルは、ISP パイプラインが重いため、これを超える可能性があります
2. カメラ構成が大きな影響を与える
カメラの遅延が大きい場合, 最適化はそこから始めるべきです:
- 解像度が低い (例えば, 720p vs 1080p) → ISP とパイプラインの遅延を削減
- より高いフレームレート (例えば, 60 fps vs 30 FPS) → フレームバッファリングの遅延を削減します。
- シンプルな画像処理パイプライン → ISP の負荷を軽減
これらの変更は、多くの場合、エンコーダーの調整よりも効果的にレイテンシーを削減します。.
3. エンコーダのレイテンシは過大評価されている可能性があります
A 120 一般的なハードウェア エンコーダでは、ミリ秒のエンコード遅延は一般的に起こりそうにありません。.
内部測定に基づく:
- ハードウェアエンコーダ + デコーダ + トランスミッション + イーサネット経由のディスプレイ パイプラインは通常、次のような結果になります。:
- エンドツーエンドの総遅延時間は約 80 ～ 100 ミリ秒
これはつまり、:
- エンコーダのみのレイテンシは、 120 ミズ
- 通常、適切に構成されたシステムではエンコーディングが主要な要因ではありません。
4. 送信方法が重要 (特にワイヤレス)
システムが使用しているかどうかを確認してください:
- 有線イーサネット
- 無線伝送
無線を使用する場合:
- 低帯域幅 (<20 Mbpsの) 大幅な遅延が発生する可能性があります
- 大きな I フレームを送信すると、バッファリングとキューイングの遅延が発生する可能性があります
- これにより、エンコードが効率的であっても、エンドツーエンドの遅延が著しく増加する可能性があります。
5. MPEG-TS とプロトコル オーバーヘッドの明確化
あなたの理解は概ね正しいです:
- MPEG-TS はエンコード段階で遅延を大幅に増加させません。
- プロトコルのオーバーヘッドのほとんどはパケット化とデコード動作に関連しています, それ自体をエンコードしない
- マルチプレクサ/デマルチプレクサ操作は主にメモリ操作であり、一般的なシステムでは遅延は無視できます。
6. 推奨されるデバッグ手法
レイテンシの原因を正確に特定するには:
- 各パイプラインステージで内部タイムスタンプを追加します。:
- カメラのキャプチャ時間
- エンコーダ入出力
- ネットワーク送受信
- デコーダ出力
- 表示の更新
- ロギングが軽量であり、パフォーマンスに影響を与えないことを確認する
- バッファの深さをリアルタイムで監視し、キューの蓄積を検出します
私たちの答えを要約します
- 多くの場合、カメラ ISP の遅延が隠れた主要な原因となっています (1080p で ~100 ミリ秒が一般的です)
- エンコーダのレイテンシは通常、想定よりもはるかに低いです
- ワイヤレス送信とバッファリングにより遅延が大幅に増加する可能性があります
- 体系的なタイムスタンプ測定は、実際のボトルネックを特定する最も信頼できる方法です
質問する
ご回答をありがとうございました。 ✨