Potřebujeme zařízení, pro příjem informací o videích z kamery Full HD s SDI (Sériové datové rozhraní) na lince a informace zakódovat ve standardu H.265. Komprimovaná data musí být přenášena buď v DVB-T (Pozemní digitální televizní vysílání) nebo standardu DVB-S. Analogový výstup navrženého modulu může přijímat signály I i Q, stejně jako modulované signály.
Obsah
Q: Podporuje váš SDI Video Encoder vstup TSI? / Výstup?
A: Naše stávající kódovací deska na modulační desku přenáší data přes síťový port. Spíše než rozhraní TSI, které jste zmínil. To nemá vliv na použití vysílače k přijímači. Toto je vnitřní rozhraní vysílače.
Q: Podporujte desky dekodéru kodéru 525 i50 až 1080 P60 ve formátu videa?
A: Nyní naše desky SDI video kodéru podporují HD: 720p @ 23,98Hz/24Hz/25Hz/29,97Hz/30Hz/ 50Hz59,94Hz/60Hz a 1080p @ 23,98Hz/24Hz/25Hz/29,97Hz/30Hz/50Hz/59,94Hz/60Hz. Nepodporuje 525 i50 video formát, je to v pořádku?
Q: Podporuje váš výstupní výkon RF kodéru SDI COFDM DVB-T H265 SDI 0~10dBm？
A: Váš výstupní frekvenční bod od 400Mhz do 2800Mhz požadovaný je velmi široký.
Je obtížné dosáhnout výstupu 0~10dBm pod tak širokým frekvenčním bodem, a přidání výkonového zesilovače na desku zvýší spotřebu energie a teplo (také jste zmínil, že není potřeba ventilátor pro odvod tepla).
Jste ochotni souhlasit s naším stávajícím -3 na výstup -10dBm a poté přidejte vlastní PA (zesilovač)?
Q: Jaký je rozměr vašeho COFDM DVB-T H265 SDI kodéru?
Máte speciální požadavek na rozměry? Náš stávající rozměr je 70x45mm.
A: Naše stávající desky kodéru a dekodéru videa mohou splnit vaše projektové potřeby.
Největší starostí mého inženýra je vaše společnost, jako člen vysílacího a televizního průmyslu má poměrně vysoké požadavky na obrazovou kvalitu videa.
Naše deska pro kódování videa bude provádět ztrátovou kompresi pro nízkou latenci. Můžete vzít sadu existujících vzorků k testování a potvrzení kvality obrazu? Pokud si myslíte, že naše vzorky mohou splnit požadavky vaší společnosti, předěláme a nakreslíme desku podle požadavků vaší společnosti.
Q: Mohl byste poskytnout více informací o VBR?
Použitím videa na TX, parametr VBR se časem změní a není statickou hodnotou. Mohl byste o tom poskytnout více informací?
A: VBR je bitová rychlost kódování videa na vysílači. Protože se obraz videa mění dynamicky, VBR je samozřejmě variabilní, ale kolísá kolem kódovací bitové rychlosti nastavené přenosovým systémem: 7.81*0.8= 6,248 Mbps.
Q: Navzdory tomu, že mám na svém přijímači flash úložiště, Na obrazovce se zobrazí REC OFF a No Storage. Proč se to děje??
Řekl jsi v popisu: Key2: přepínací tlačítko pro nahrávání videa, krátkým stisknutím změníte jeho stav. Přijímač automaticky zkontroluje úložné zařízení (micro SD kartu nebo USB disk, prioritní SD karta) po zapnutí a po vložení úložného zařízení začněte nahrávat video. Pro zastavení nebo opětovné nahrávání stačí stisknout tlačítko.
A: Přijímající systém nerozpozná USB flash disk. USB flash disk je třeba naformátovat na formát, který náš systém dokáže rozpoznat.
Q: B1 i B2 jsou nulové. To znamená, že existuje a 0 % Chybovost kousnutí!!! Který rozsah těchto parametrů je přijatelný?
A: Výskyt bitové chybovosti může způsobit problémy s obrazem videa. Když je bitová chybovost velmi malá, neovlivní to obrazový efekt videa.
Q: Mohu přizpůsobit obsah obrazovky programátoru?
A: Zobrazený obsah konfiguračního panelu (programátor) není přístupná zákazníkům pro úpravy.
Q: Proč není naprogramován kanál S2? Zdá se, že druhý tuner momentálně nefunguje.
A: S2 označuje přijímací anténu 2, který může normálně fungovat. Frekvence a šířka pásma jsou stejné s1 a s2.
Q: Proč je latence, kterou jsem spočítal, obrovská? je to kolem 470 slečna.
Ve vašem popisu přichází: Výchozí normální funkce našeho přijímacího modulu lze spárovat s naším vysílacím modulem H.265. Latence HD videa od jeho vstupu z vysílače na obrazovku HDMI zobrazení přijímače je asi 200 ms až 250 ms.
A: Zpoždění, které jsme testovali, bylo kolem 250 ms. Jak jsi to testoval? Způsob zpoždění, který jsme testovali, Zkontrolujte prosím Odkaz na video na Youtube.
Q: Jakou latenci má váš vysílač SDI kodéru a modul přijímače dekodéru?
Pamatuji si, že jsi říkal, že jsi optimalizoval protokol pro lepší latenci. Protože nepoužívám vaši rychlou latenci H.264 (130 slečna) jak velkou latenci bychom měli mít na mém nastavení?
A: Potvrdili jste, že potřebujete podporovat H265, ale ne režim s nízkou latencí H264. Pro dosažení režimu nízké latence, přijímač musí být vyměněn za jiný hardware přijímače, a příslušný firmware musí být před odesláním vypálen.
Q: Mohu použít váš přijímač COFDM k získání normálního televizního kanálu DVB-T?
Říkal jsi, že jsi změnil video protokol pro lepší latenci ve TX. Mohu použít váš RX jako komerční DVB-T? jak mohu přijímat normální DVB-T kanál?
A: Pokud ho opravdu chcete používat jako běžný DVB-T přijímač, musíme upgradovat jiný firmware. (odstraňte šifrování na kodéru a dešifrování na dekodéru).
Q: Jak mohu použít funkci nabídky OSD na přijímači COFDM?
Ve vašem popisu přichází:
Modul přijímače také obsahuje funkci nahrávání DVR s Micro SD kartou nebo USB diskem. Modul přijímače také umožňuje streamování videa přes USB pro vzdálené dekodéry zařízení Android, jako jsou chytré telefony nebo Android PAD. To umožňuje více vzdáleným divákům sledovat stejné video
zároveň. Modul přijímače také podporuje řetězec znaků zobrazení na obrazovce zobrazení videa s videem v režimu OSD.
A: Vidět OSD online dokumentace.
Q: Jak mohu zapnout šifrování AES? Kam mám zadat klíč?
A: Konfigurační panel může upravovat a měnit heslo.
Q: Označte otázku s textem luku:
A: Tato volitelná funkce je vyžadována jinými produkty (funkce síťového portu se používá pro připojení k obousměrnému bezdrátovému spojení). Ve své aplikaci to prosím ignorujte.
Q: Jaké je časové zpoždění dat UART při jednosměrném přenosu?
Pro UART data z TX do RX, jsou data zpracovávaná procesem kódování nebo přenášená v reálném čase? Požaduji přenos dat v reálném čase.
A: Data a video jsou odesílány společně prostřednictvím bezdrátového balíčku cofdm. Zpoždění je tedy stejné jako u videa.
Q: Pro vysílač. Je možné změnit GI a FEC a další parametr dle Vaší tabulky v popisu?
A: Ano.
Q: Z čeho je přesná síla v tomto bodě 1350 na 1450 MHz? Potřebuji tyto informace k návrhu PA.
Maximální výkon frekvenčního pásma 1350~1450 je kolem -10±2dBm. Doporučuje se navrhovat PA na základě vstupu -15dBm. Náš vysílač lze nastavit až na -15dBm.
Q: Má váš programátor funkci obnovení továrního nastavení??
Pokud změním jakékoli parametry jakékoli strany, jako je frekvence GI nebo FEC nebo šířka pásma videa, jak mohu resetovat všechny parametry v továrním režimu? Jsem na této desce nový, a potřebuji změnit některé parametry, abych dosáhl svého přání. Ale bojím se změnit výchozí informace.
A: Naše TX / Programátor RX nemá funkci obnovení továrního nastavení.
Q: Podporuje váš vstupní kodér SDI Video 1080i25/1080i30??
Podporuje 1080i50 a 1080i60, nepodporuje 1080i25 nebo 1080i30.
Q: Můžete mi nabídnout nějaké technické soubory na opravu silové části Deska kodéru videa Vcan1731 SDI?
A: Zkontrolujte prosím soubory na níže uvedeném odkazu.
- 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
Naše myšlenka údržby je nejprve vyloučit, zda nedošlo ke zkratu a kde je zkrat. Například, odpojte magnetickou perličku nebo 0-ohmový odpor mezi napájecím integrovaným obvodem a následným obvodem, a poté pomocí multimetru změřte, zda je napájecí IC přerušený nebo zda je následný obvod zkratován. Pokud je rozbitý napájecí IC, vyměňte napájecí IC; pokud je následný obvod zkratován, musíte zkontrolovat následující okruh.
Q: Can the encoder board receive and forward UART data through UDP communication (Skutečný test může podporovat 32 uzlů pro síťování:Přístav)?
A: Ano, UART data transmission is supported under our default custom protocol, with some important considerations:
1. Vlastní protokol (Default Firmware)
Our default shipping firmware uses a custom multiplexed protocol that supports UART transparent transmission (serial passthrough).
- UART data is multiplexed together with audio/video streams.
- Proto, the receiving side must use the corresponding custom protocol demux library to separate UART data from the media stream.
- When used together with our decoder board, UART transparent transmission works properly and can be forwarded/received as expected.
Note for PC Players
Our current PC player software only demuxes and processes:
- Video data
- Zvuková data
V současnosti, to dělá ne process or output UART serial data.
2. Standard MPEG-TS Protocol
If the encoder board is flashed with the standard MPEG-TS firmware/protocol:
- Only audio and video streams are supported.
- UART/serial data transmission is není podporováno under MPEG-TS mode.
Please take this into consideration when selecting the firmware/protocol solution.
| Protocol Type | Audio / Video | UART Transparent Transmission |
|---|---|---|
| Vlastní protokol (standardní) | podporován | podporován |
| Standard MPEG-TS | podporován | Not Supported |
Q: Do you have firmware that supports raw H.264 or RTP instead of MPEG-TS for UDP streaming?
A: Our UDP firmware does not transmit raw H.264 elementary streams. UDP streaming is supported in two formats depending on firmware version:
- A custom proprietary format, nebo
- The standard MPEG-TS (MPEG Transport Stream) formát
These correspond to different firmware builds (typically distinguished by a suffix such as “T” or non-“T” versions).
Q: Do you support RTP as a standalone streaming protocol?
A: We do not provide a separate “raw RTP streaming mode.” However, RTP is already used internally within RTSP streaming. In RTSP mode, audio and video are transmitted over RTP packets as part of the RTSP/RTP/RTCP stack. Proto, RTP is supported indirectly through RTSP rather than as an independent UDP streaming format.
Q: Can the system output raw H.264 over UDP?
A: Ne. Raw H.264 elementary stream transmission is not supported over UDP. This is due to packet size and network constraints. A single I-frame can be very large and cannot be reliably transmitted in a single IP packet.
For stable transmission, video streams must be encapsulated using a transport format such as:
- MPEG-TS, nebo
- RTP (via RTSP)
Q: How is the key frame (GOP) interval configured?
A: The key frame interval is controlled by the GOP parameter ve webovém rozhraní (video settings page).
- If GOP is set to 0 (default/auto mode), the system automatically aligns the I-frame interval with the input frame rate.
- Příklad: If the input is 1080p60, then the I-frame interval will be 60 rámy (1 second GOP).
This ensures adaptive encoding behavior based on input source characteristics.
Q: Why can’t raw H.264 be transmitted directly over IP/UDP?
A: Because H.264 frames (especially I-frames) can be very large and exceed the maximum transmission unit (Muž) of network packets. Without encapsulation, reliable delivery cannot be guaranteed. Proto, video must be packetized using standardized streaming formats such as MPEG-TS or RTP for proper segmentation, načasování, and reassembly.
Q: My system latency is ~230 ms total. Decoder and display take ~45 ms, leaving ~185 ms for camera and encoder. I expect the camera contributes ~60 ms (4 frames at 60 fps), so the encoder seems to be ~120 ms. Is there a way to reduce encoder latency? I understand MPEG-TS mainly affects decoding, not encoding.
A: Latency Breakdown and Optimization Guidance
To accurately optimize system latency, it is important to first validate each stage independently before assuming bottlenecks.
1. Verify Camera Latency First (Critical Step)
Before optimizing encoding, you should confirm the actual camera contribution.
A practical measurement method:
- Connect the camera HDMI output directly to a display
- Point the camera at a high-precision stopwatch displayed on a separate PC monitor
- Capture both the live scene and HDMI output simultaneously
- Compare frame timestamps to calculate end-to-end camera latency
Poznámky:
- Use a high-precision stopwatch (smaller tick interval improves accuracy)
- Camera ISP processing is often a major contributor
- In our experience:
- 1080p cameras typically introduce ~100 ms latency
- Některé modely mohou toto překročit kvůli těžším ISP potrubím
2. Konfigurace kamery má velký dopad
Pokud je latence kamery vysoká, tam by měla začít optimalizace:
- Nižší rozlišení (NAPŘ., 720p vs 1080p) → snižuje zpoždění ISP a potrubí
- Vyšší snímková frekvence (NAPŘ., 60 fps vs 30 fps) → snižuje latenci ukládání snímků do vyrovnávací paměti
- Jednodušší proces zpracování obrazu → snižuje zatížení ISP
Tyto změny často snižují latenci účinněji než ladění kodéru.
3. Latence kodéru je pravděpodobně nadhodnocena
A 120 Zpoždění kódování ms je u typických hardwarových kodérů obecně nepravděpodobné.
Na základě interních měření:
- Hardwarový kodér + dekodér + přenos + zobrazení potrubí přes Ethernet obvykle vede:
- ~80–100 ms celková latence end-to-end
To znamená:
- Latence pouze kodéru je výrazně nižší než 120 slečna
- Kódování obvykle není dominantním přispěvatelem ve správně nakonfigurovaném systému
4. Na způsobu přenosu záleží (Zejména bezdrátové)
Ověřte, zda systém používá:
- Kabelový ethernet
- Bezdrátový přenos
Pokud se používá bezdrátové připojení:
- Malá šířka pásma (<20 Mbps) může způsobit značné zpoždění
- Přenos velkého I-snímku může způsobit zpoždění ukládání do vyrovnávací paměti a řazení do fronty
- To může výrazně zvýšit latenci end-to-end, i když je kódování efektivní
5. MPEG-TS a režie protokolu
Vaše chápání je obecně správné:
- MPEG-TS významně nepřidává latenci ve fázi kódování
- Většina režie protokolu souvisí s chováním paketizace a dekódování, nekódování samo
- Operace mux/demux jsou primárně paměťové operace a mají v typických systémech zanedbatelné zpoždění
6. Doporučený přístup k ladění
Chcete-li přesně lokalizovat zdroje latence:
- Přidejte interní časová razítka v každé fázi potrubí:
- Čas pořízení fotoaparátu
- Vstup/výstup kodéru
- Síťové odesílání/příjem
- Výstup dekodéru
- Obnovení zobrazení
- Ensure logging is lightweight and does not affect performance
- Monitor buffer depth in real time to detect queue buildup
Summary our answer
- Camera ISP delay is often a major hidden contributor (~100 ms at 1080p is common)
- Encoder latency is usually much lower than assumed
- Wireless transmission and buffering can significantly increase delay
- Systematic timestamp measurement is the most reliable way to identify the real bottleneck
Položit otázku
Děkujeme za Vaši odpověď. ✨