Cihazlara ihtiyacımız var, SDI ile tam HD kamera videoları hakkında bilgi almak için (Seri Veri Arayüzü) Hatta ve H.265 Standartında Bilgileri Kassalı. Sıkıştırılmış veriler her iki DVB-T'de iletilmelidir (Dijital Video Yayın Karasal) veya DVB-S standardı. Tasarlanan modülün analog çıkışı hem I hem de Q sinyallerini kabul edebilir, ve modüle edilmiş sinyaller.
İçindekiler
S: SDI video kodlayıcınız TSI girişini destekliyor mu / Çıktı?
bir: Mevcut kodlama kartımızdan modülasyon kartımız ağ bağlantı noktası üzerinden verileri iletir. Bahsettiğiniz TSI arayüzü yerine. Bu, vericinin alıcıya kullanımını etkilemez. Bu, vericinin dahili bir arayüzüdür.
S: Enkoder kod çözücü kartlarınızı destekleyin 525 i50 ila 1080 Video formatında p60?
bir: Şimdi SDI video kodlayıcı kartlarımız HD'yi destekliyor: 720P @ 23.98Hz/24Hz/25Hz/29.97Hz/30Hz/50Hz59.94Hz/60Hz ve 1080p @ 23.98Hz/24Hz/25Hz/29.97Hz/30Hz/50Hz/59.94Hz/60Hz. Desteklemiyor 525 i50 video biçimi, Tamam mı？
S: SDI COFDM DVB-T H265 SDI Encoder RF Çıkış Güç Desteği 0 ~ 10dbm？
bir: Çıktı frekans noktanız 400MHz ila 2800MHz gerekli.
Böyle geniş bir frekans noktası altında 0 ~ 10dbm çıkış elde etmek zor, ve tahtaya bir güç amplifikatörü eklemek, güç tüketimini ve ısıyı artıracaktır (Ayrıca ısı dağılması için bir fan gerekmediğini de belirttiniz).
Mevcut olarak kabul etmeye istekli misin -3 -10dbm çıkışına ve ardından kendi PA'nızı ekleyin (amplifikatör)?
S: COFDM DVB-T H265 SDI kodlayıcınızın boyutu nedir?
Özel bir boyut isteğiniz var mı? Mevcut boyutumuz 70x45mm.
bir: Mevcut video kodlayıcı ve kod çözücü kartlarımız proje ihtiyaçlarınızı karşılayabilir.
Mühendisimin en büyük endişesi şirketinizin, Yayın ve televizyon endüstrisinin bir üyesi olarak, görüntü video kalitesi için nispeten yüksek gereksinimlere sahiptir.
Video kodlama panomuz düşük gecikme için kayıplı sıkıştırma gerçekleştirecektir. Görüntü kalitesini test etmek ve onaylamak için bir dizi mevcut numune alabilir misiniz?? Örneklerimizin şirketinizin gereksinimlerini karşılayabileceğini düşünüyorsanız, Şirketinizin gereksinimlerine göre tahtayı yeniden tasarlayacağız ve çizeceğiz.
S: VBR hakkında daha fazla bilgi verebilir misiniz??
TX'e video uygulayarak, VBR parametresi zamanla değişecek ve statik bir değer değil. Bu konuda daha fazla bilgi verebilir misiniz??
bir: VBR, vericide bit hızını kodlayan videodur. Video resmi dinamik olarak değiştiğinden, VBR elbette değişkendir, ancak iletim sistemi tarafından belirlenen kodlama bit hızı etrafında dalgalanıyor: 7.81*0.8= 6.248Mbps.
S: Alıcımda flash depolama almasına rağmen, Rec kapalı ve ekranda hiçbir depolama görüntülenmez. Bu neden oluyor?
Açıklamada dedin: Tuş2: Video kaydı için anahtar düğmesi, Durumunu değiştirmek için kısa basın. Alıcı, depolama cihazını otomatik olarak kontrol edecektir. (mikro SD kart veya USB disk, Öncelik SD Kartı) açtıktan sonra ve depolama aygıtı takıldığında video kaydetmeye başlayın. Sadece durdurmak veya tekrar kaydetmek için düğmeye basın.
bir: Alıcı sistem USB flash sürücüsünü algılayamaz. USB flash sürücünün, sistemimizin tanıyabileceği bir formata göre biçimlendirilmesi gerekir..
S: Hem B1 hem de B2 sıfırdır. Bu bir 0 % Isırma hatası oranı!!! Bu parametrelerin hangi aralığı kabul edilebilir?
bir: Biraz hata oranının ortaya çıkması, video görüntüsü ile ilgili sorunlara neden olabilir. Bit hata oranı çok küçük olduğunda, Video görüntü etkisini etkilemez.
S: Programcı ekran içeriğini özelleştirebilir miyim?
bir: Yapılandırma panelinin ekran içeriği (programcı) Değişiklik için müşterilere açık değil.
S: S2 kanalı neden programlanmıyor? Görünüşe göre ikinci tuner şu anda çalışmıyor.
bir: S2, anten almayı ifade eder 2, Normal şekilde çalışabilir. Frekans ve bant genişliği aynı S1 ve S2.
S: Neden hesapladığım gecikme çok büyük? Etrafta 470 MS.
Açıklamanızda geliyor: Alıcı modülümüzün varsayılan normal özellikleri H.265 Verici Modülümüzle eşleştirilebilir. Vericinin girişinden alıcının HDMI ekranının görüntülenmesine kadar HD video gecikmesi yaklaşık 200 ms ila 250 ms arasındadır..
bir: Test ettiğimiz gecikme 250 ms civarındaydı. Nasıl test ettin? Test ettiğimiz gecikme yolu, Lütfen kontrol edin YouTube Video Bağlantısı.
S: SDI Encoder Verici ve Decoder Alıcı Modülünüzün Ne Kadar Gecikmesi Var?
Daha iyi gecikme için protokolü optimize ettiğini söylediğini hatırlıyorum. Hızlı H.264 gecikmenizi kullanmadığım için (130 MS) Kurulumumda ne kadar gecikmemiz olmalıyız?
bir: H265'i desteklemeniz gerektiğini doğruladınız, ancak H264 düşük gecikme modu değil. Düşük gecikme modu elde etmek için, Alıcı başka bir alıcı donanımına değiştirilmelidir, ve gönderimden önce ilgili ürün yazılımı yakılmalıdır.
S: Normal DVB-T TV kanalını almak için COFDM alıcınızı kullanabilir miyim?
TX'te daha iyi gecikme için video protokolünü değiştirdiğini söyledin. RX'inizi ticari bir DVB-T olarak kullanabilir miyim? Normal DVB-T kanalını nasıl alabilirim?
bir: Gerçekten normal bir DVB-T alıcısı olarak kullanmak istiyorsanız, Başka bir ürün yazılımını yükseltmeliyiz. (Kodlayıcıdaki şifrelemeyi ve kod çözücü üzerindeki şifre çözme).
S: COFDM alıcısında OSD menü işlevinizi nasıl kullanabilirim?
Açıklamanızda geliyor:
Alıcı modülü ayrıca bir Mikro SD kart veya USB disk ile DVR kayıt işlevi içerir. Alıcı modülü ayrıca akıllı telefonlar veya Android Pad gibi uzak Android cihaz kod çözücüleri için USB üzerinden video akışı sağlıyor. Bu, birden çok uzak izleyicinin aynı videoyu izlemesine izin verir
eşzamanlı olarak. Alıcı modülü, OSD modunda video ile birlikte video görüntüleme ekranındaki görüntü karakter dizisini de destekler..
bir: Görmek OSD Çevrimiçi Belgeleri.
S: AES şifrelemesini nasıl açabilirim? Anahtarı nereye girmeliyim?
bir: Yapılandırma paneli parolayı düzenleyebilir ve değiştirebilir.
S: Yay metin resmi sorusunu belirtin:
bir: Bu isteğe bağlı işlev diğer ürünler tarafından gereklidir (Ağ bağlantı noktası işlevi, iki yönlü bir kablosuz bağlantıya bağlanmak için kullanılır). Lütfen başvurunuzda görmezden gelin.
S: UART verilerinin tek yönlü iletimdeki zaman gecikmesi nedir?
TX'ten RX'e UART verileri için, Kodlama işlemi yoluyla işlenen veriler veya gerçek zamanlı olarak iletiliyor mu?? Gerçek zamanlı veri aktarımına ihtiyacım var.
bir: Veri ve video, kablosuz COFDM paketi ile birlikte gönderilir. Yani gecikme video ile aynı.
S: Verici için. Açıklamadaki masanıza göre GI ve FEC ve başka bir parametreyi değiştirmek mümkündür.?
bir: Evet.
S: Bu noktada tam güç nedir 1350 için 1450 MHz? Bir PA tasarlamak için bu bilgiye ihtiyacım var.
1350 ~ 1450 frekans bandının maksimum çıkışı -10 ± 2dbm civarındadır. PA'nın -15dbm girişine göre tasarlanması önerilir. Vericimiz -15dbm'ye ayarlanabilir.
S: Programcınız fabrika geri yüklemesini sıfırlama işlevine sahip mi??
Frekans GI veya FEC veya video bant genişliği gibi herhangi bir tarafın parametresini değiştirirsem, Sıfırlama fabrika modundaki tüm parametreleri nasıl sıfırlayabilirim? Bu tahtada yeniyim, Ve arzumu elde etmek için bazı parametreleri değiştirmem gerekiyor. Ama varsayılan bilgi parçalarını değiştirmekten korkuyorum.
bir: TX'imiz / RX programcısının bir fabrika sıfırlama özelliği yok.
S: SDI video giriş kodlayıcınız 1080i25/1080i30'u destekliyor mu?
1080i50 ve 1080i60'ı destekler, 1080i25 veya 1080i30'u desteklemiyor.
S: Bana bazı teknik dosyalar sunabilir misin Güç kısmının onarımı için VCAN1731 SDI Video Enkoder Kart?
bir: Lütfen aşağıdaki bağlantıdan dosyaları kontrol edin.
- 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
Bakım fikrimiz, önce kısa devre olup olmadığını ve kısa devrenin nerede olduğunu göz ardı etmektir.. Örneğin, Güç IC ile sonraki devre arasındaki manyetik boncuk veya 0-ohm dirençini ayırın, ve sonra güç IC'sinin kırılıp kırılmadığını veya sonraki devrenin kısa devreli olup olmadığını ölçmek için bir multimetre kullanın. Güç IC kırılırsa, Power IC'yi değiştirin; Sonraki devre kısa devre olursa, sonraki devreyi kontrol etmelisiniz.
S: Can the encoder board receive and forward UART data through UDP communication (IP:Liman)?
bir: Evet, UART data transmission is supported under our default custom protocol, with some important considerations:
1. Özel 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.
- bu nedenle, 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
- Ses verileri
Şu anda, öyle değil 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 desteklenmiyor under MPEG-TS mode.
Please take this into consideration when selecting the firmware/protocol solution.
| Protocol Type | Ses videosu | UART Transparent Transmission |
|---|---|---|
| Özel protokol (Varsayılan) | destekli | destekli |
| Standard MPEG-TS | destekli | Not Supported |
S: Do you have firmware that supports raw H.264 or RTP instead of MPEG-TS for UDP streaming?
bir: Our UDP firmware does not transmit raw H.264 elementary streams. UDP streaming is supported in two formats depending on firmware version:
- bir custom proprietary format, veya
- The standard MPEG-TS (MPEG Transport Stream) biçim
These correspond to different firmware builds (typically distinguished by a suffix such as “T” or non-“T” versions).
S: Do you support RTP as a standalone streaming protocol?
bir: 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. bu nedenle, RTP is supported indirectly through RTSP rather than as an independent UDP streaming format.
S: Can the system output raw H.264 over UDP?
bir: Yok hayır. 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, veya
- RTP (via RTSP)
S: How is the key frame (GOP) interval configured?
bir: The key frame interval is controlled by the GOP parameter web arayüzünde (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.
- Örnek: If the input is 1080p60, then the I-frame interval will be 60 çerçeveler (1 second GOP).
This ensures adaptive encoding behavior based on input source characteristics.
S: Why can’t raw H.264 be transmitted directly over IP/UDP?
bir: Because H.264 frames (especially I-frames) can be very large and exceed the maximum transmission unit (Adam) of network packets. Without encapsulation, reliable delivery cannot be guaranteed. bu nedenle, video must be packetized using standardized streaming formats such as MPEG-TS or RTP for proper segmentation, zamanlama, and reassembly.
S: 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.
bir: 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
notlar:
- 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
- Some models may exceed this due to heavier ISP pipelines
2. Camera Configuration Has a Major Impact
If camera latency is high, optimization should start there:
- Daha düşük çözünürlük (örneğin, 720p vs 1080p) → reduces ISP and pipeline delay
- Higher frame rate (örneğin, 60 fps vs 30 fps) → reduces frame buffering latency
- Simpler image processing pipeline → reduces ISP load
These changes often reduce latency more effectively than encoder tuning.
3. Encoder Latency Is Likely Overestimated
bir 120 ms encoding delay is generally unlikely for typical hardware encoders.
Based on internal measurements:
- A hardware encoder + şifre çözücü + aktarma + display pipeline over Ethernet typically results in:
- ~80–100 ms total end-to-end latency
This implies:
- Encoder-only latency is significantly lower than 120 MS
- Encoding is usually not the dominant contributor in a properly configured system
4. Transmission Method Matters (Especially Wireless)
Please verify whether the system uses:
- Kablolu ethernet
- Kablosuz iletim
If wireless is used:
- Low bandwidth (<20 mbps) can introduce significant delay
- Large I-frame transmission may cause buffering and queueing delays
- This can noticeably increase end-to-end latency even if encoding is efficient
5. MPEG-TS and Protocol Overhead Clarification
Your understanding is generally correct:
- MPEG-TS does not significantly add latency at the encoding stage
- Most protocol overhead is related to packetization and decoding behavior, not encoding itself
- Mux/demux operations are primarily memory operations and have negligible delay in typical systems
6. Recommended Debugging Approach
To precisely locate latency sources:
- Add internal timestamps at each pipeline stage:
- Camera capture time
- Encoder input/output
- Network send/receive
- Decoder output
- Display refresh
- 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
Bir soru sor
Yanıtınız için teşekkür ederiz. ✨