Kailangan namin ng mga aparato, upang matanggap ang impormasyon sa Full HD camera video na may SDI (Serial Data Interface) sa linya at Encode impormasyon sa H.265 standard. Ang na-compress na data ay kailangang maipadala sa alinman sa DVB-T (Digital Video Broadcasting terestriyal) o DVB-S standard. Ang analog output ng dinisenyo module ay maaaring tanggapin ang parehong I at Q signal, pati na rin ang modulated signal.
Talahanayan ng nilalaman
Q: Sinusuportahan ba ng iyong SDI Video Encoder ang TSI Input / Output?
A: Ang aming umiiral na encoding board sa modulation board ay nagpapadala ng data sa pamamagitan ng port ng network. Kaysa sa interface ng TSI na nabanggit mo. Hindi ito nakakaapekto sa paggamit ng transmiter sa receiver. Ito ay isang panloob na interface ng transmiter.
Q: Sinusuportahan ba ng iyong mga encoder decoder boards 525 i50 sa 1080 P60 sa video format?
A: Ngayon ang aming SDI video encoder boards ay sumusuporta sa HD: 720p @ 23.98HZ/24HZ/25HZ/29.97HZ/30HZ/ 50HZ59.94HZ/60HZ at 1080p @ 23.98HZ/24HZ/25HZ/29.97HZ/30HZ/50HZ/59.94HZ/60HZ. Hindi ito sumusuporta sa 525 Format ng video ng i50, OK lang po ba
Q: Sinusuportahan ba ng iyong SDI COFDM DVB-T H265 SDI Encoder RF output power 0~10dBm?
A: Ang iyong output frequency point mula sa 400Mhz hanggang 2800Mhz na kinakailangan ay napakalawak.
Mahirap makamit ang 0 ~ 10dBm output sa ilalim ng tulad ng isang malawak na dalas ng punto, at pagdaragdag ng Power Amplifier sa board ay magpapataas ng power consumption at init (nabanggit mo rin na hindi na kailangan ng fan para sa heat dissipation).
Handa ka bang sumang ayon sa ating umiiral -3 sa -10dBm output at pagkatapos ay idagdag ang iyong sariling PA (kapangyarihan amplifier)?
Q: Ano ang sukat ng iyong COFDM DVB-T H265 SDI Encoder?
Mayroon ka bang isang espesyal na dimensyon na kahilingan? Ang aming umiiral na laki ay 70x45mm.
A: Ang aming umiiral na video encoder at decoder boards ay maaaring matugunan ang iyong mga pangangailangan sa proyekto.
Ang pinakamalaking pag aalala ng aking engineer ay ang iyong kumpanya, bilang isang miyembro ng industriya ng broadcast at telebisyon ay may medyo mataas na mga kinakailangan para sa kalidad ng imahe ng video.
Ang aming video encoding board ay magsasagawa ng lossy compression para sa mababang latency. Maaari ka bang kumuha ng isang hanay ng mga umiiral na sample upang subukan at kumpirmahin ang kalidad ng imahe? Kung sa tingin mo ang aming mga sample ay maaaring matugunan ang mga kinakailangan ng iyong kumpanya, Kami ay muling idisenyo at iguhit ang board ayon sa mga kinakailangan ng iyong kumpanya.
Q: Maaari ka bang magbigay ng karagdagang impormasyon tungkol sa VBR?
Sa pamamagitan ng paglalapat ng video sa TX, ang VBR parameter ay magbabago sa paglipas ng panahon at hindi isang static na halaga. Maaari ka bang magbigay ng karagdagang impormasyon tungkol dito?
A: Ang VBR ay ang video encoding bit rate sa transmiter. Dahil ang larawan ng video ay nagbabago nang dynamic, Ang VBR ay siyempre variable, ngunit ito fluctuates sa paligid ng encoding bit rate na itinakda ng transmission system: 7.81*0.8=6.248Mbps.
Q: Sa kabila ng pagkakaroon ng flash storage sa aking receiver, REC OFF at Walang Imbakan ay ipinapakita sa screen. Bakit nangyayari ito?
Sabi mo sa description: Key2: switch button para sa video recording, maikling pindutin upang baguhin ang katayuan nito. Awtomatikong susuriin ng receiver ang storage device (micro SD card o USB disk, priority SD card) pagkatapos ng powering on at simulan upang i record ang video kapag ang aparato ng imbakan ay ipinasok. Pindutin lang ang button para tumigil o mag record ulit.
A: Ang pagtanggap ng system ay nabigo upang matukoy ang USB flash drive. Ang USB flash drive ay kailangang ma format sa isang format na maaaring makilala ng aming system.
Q: Parehong B1 at B2 ay zero. Ipinapahiwatig nito na mayroong a 0 % Kagat ng rate ng error!!! Aling saklaw ng mga parameter na ito ay katanggap -tanggap?
A: Ang pangyayari ng isang bit error rate ay maaaring maging sanhi ng mga problema sa imahe ng video. Kapag ang bit error rate ay napakaliit, hindi ito makakaapekto sa video image effect.
Q: Maaari ko bang ipasadya ang mga nilalaman ng screen ng programmer?
A: Ang nilalaman ng display ng panel ng pagsasaayos (programmer) ay hindi bukas sa mga customer para sa pagbabago.
Q: Bakit hindi naka -program ang S2 channel? Lumilitaw na ang pangalawang tuner ay hindi gumagana sa ngayon.
A: Ang S2 ay tumutukoy sa pagtanggap ng antenna 2, alin ang maaaring gumana nang normal. Ang dalas at bandwidth ay pareho s1 at s2.
Q: Bakit napakalaki ng latency na kinakalkula ko? Nasa paligid ito 470 MS.
Sa iyong paglalarawan na darating: Ang default na normal na mga tampok ng aming module ng receiver ay maaaring ipares sa aming H.265 transmiter module. Ang HD video latency mula sa pagpasok nito ng transmiter sa HDMI screen display ng receiver ay tungkol sa 200ms sa 250ms.
A: Ang delay na nasubukan namin ay nasa paligid ng 250ms. Paano mo ito nasubok? Ang pagkaantala paraan namin sinubok, paki check na lang po ang Youtube link ng video.
Q: Kung magkano ang latency ng iyong SDI encoder transmiter at decoder receiver module?
Naalala ko pa sinabi mo na optimize mo ang protocol para sa mas mahusay na latency. Bilang hindi ko gamitin ang iyong mabilis H.264 latency (130 MS) magkano ba dapat ang latency natin sa setup ko?
A: Kinumpirma mo na kailangan mong suportahan ang H265, pero hindi H264 low latency mode. Upang makamit ang mababang latency mode, ang receiver ay dapat na baguhin sa isa pang receiver hardware, at ang kaukulang firmware ay kailangang masunog bago ang pagpapadala.
Q: Maaari ko bang gamitin ang iyong tagatanggap ng COFDM upang makuha ang normal na channel sa TV ng DVB-T TV?
Sabi mo binago mo ang video protocol para mas mahusay na latency sa TX. Maaari ko bang gamitin ang iyong RX bilang komersyal na DVB-T? paano ko matatanggap ang normal na DVB-T channel?
A: Kung talagang nais mong gamitin ito bilang isang normal na DVB-T receiver, kailangan pa namin mag upgrade ng ibang firmware. (alisin ang encryption sa encoder at decryption sa decoder).
Q: Paano ko magagamit ang iyong OSD menu function sa cofdm receiver?
Sa iyong paglalarawan na darating:
Kasama rin sa module ng receiver ang pag andar ng DVR record na may isang Micro SD card o USB disk. Ang receiver module ay nagbibigay daan din sa video streaming sa USB para sa mga remote na decoder ng Android device tulad ng Smartphones o Android PAD. Pinapayagan nito ang maraming mga remote na manonood na subaybayan ang parehong video
sabay sabay. Sinusuportahan din ng module ng receiver ang string ng mga character ng display sa screen ng display ng video na may video na magkasama sa OSD mode.
A: Tingnan sa OSD online na dokumentasyon.
Q: Paano ko mai -on ang pag -encrypt ng AES? Saan ko dapat ipasok ang susi?
A: Ang panel ng pagsasaayos ay maaaring i edit at baguhin ang password.
Q: Ipahiwatig ang tanong ng larawan ng bow text:
A: Ang opsyonal na function na ito ay kinakailangan ng iba pang mga produkto (Ang function ng port ng network ay ginagamit upang kumonekta sa isang dalawang daan na wireless link). Huwag mo na lang pansinin sa application mo.
Q: Ano ang oras ng pagkaantala ng data ng UART sa one-way na paghahatid?
Para sa data ng UART mula sa TX hanggang RX, ang data ba ay naproseso sa pamamagitan ng proseso ng pag encode o ipinadala sa real time? Kailangan ko ng real time na paglipat ng data.
A: Ang data at video ay ipinadala nang magkasama sa pamamagitan ng wireless cofdm package. Kaya ang pagkaantala ay pareho ng sa video.
Q: Para sa transmiter. Posible bang baguhin ang GI at FEC at isa pang parameter ayon sa iyong talahanayan sa paglalarawan?
A: Oo.
Q: Ano ang eksaktong kapangyarihan sa puntong ito mula sa 1350 upang 1450 MHz? Kailangan ko ang impormasyong ito upang magdisenyo ng isang PA.
Ang maximum na output ng 1350 ~ 1450 frequency band ay sa paligid ng -10±2dBm. Inirerekomenda na idisenyo ang PA batay sa -15dBm input. Ang aming transmiter ay maaaring iakma pababa sa -15dBm.
Q: May function ba ang programmer mo na i reset ang factory restore?
Kung babaguhin ko ang anumang mga parameter ng anumang panig tulad ng dalas GI o FEC o video bandwidth, paano po ba i reset lahat ng parameters sa reset factory mode? Ako ay bago sa board na ito, at kailangan kong baguhin ang ilang mga parameter upang makamit ang aking pagnanais. Ngunit natatakot ako sa pagbabago ng mga default na piraso ng impormasyon.
A: Ang aming TX / Ang RX programmer ay walang tampok na pag reset ng pabrika.
Q: Sinusuportahan ba ng iyong SDI Video input encoder 1080i25/1080i30?
Sinusuportahan nito ang 1080i50 at 1080i60, hindi ito sumusuporta sa 1080i25 o 1080i30.
Q: Maaari mo bang alok sa akin ang ilang mga teknikal na file para sa pagkukumpuni ng power part ng Vcan1731 SDI video encoder lupon?
A: Paki check ang mga file sa link sa ibaba.
- 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
Ang aming ideya sa pagpapanatili ay upang unang mamuno kung mayroong isang maikling circuit at kung saan ang short circuit ay. Halimbawa, idiskonekta ang magnetic bead o 0-ohm resistor sa pagitan ng power IC at ang kasunod na circuit, tapos gumamit ng multimeter para masukat kung sira ang power IC o short circuited ang kasunod na circuit. Kung sira ang power IC, palitan ang power IC; kung ang kasunod na circuit ay maikli ang sirkito, kailangan mong suriin ang kasunod na circuit.
Q: Maaari bang tumanggap at magpasa ng data ng UART ang encoder board sa pamamagitan ng komunikasyon ng UDP (IP:Port)?
A: Oo, Ang paghahatid ng data ng UART ay sinusuportahan sa ilalim ng aming default na custom na protocol, na may ilang mahahalagang pagsasaalang-alang:
1. Pasadyang protocol (Default na Firmware)
Ang aming default na firmware sa pagpapadala ay gumagamit ng a pasadyang multiplexed protocol na sumusuporta UART transparent transmission (serial passthrough).
- Ang data ng UART ay multiplexed kasama ng mga audio/video stream.
- Kaya nga, ang receiving side ay dapat gumamit ng kaukulang pasadyang protocol demux library upang paghiwalayin ang data ng UART mula sa stream ng media.
- Kapag ginamit kasama ng aming decoder board, Ang transparent na transmisyon ng UART ay gumagana nang maayos at maaaring maipasa/matanggap gaya ng inaasahan.
Paalala para sa mga PC Player
Ang aming kasalukuyang software ng PC player ay nagde-demux at nagpoproseso lamang:
- Data ng video
- Data ng audio
Sa kasalukuyan, ginagawa nito hindi proseso o output ng serial data ng UART.
2. Karaniwang MPEG-TS Protocol
Kung ang encoder board ay naka-flash gamit ang karaniwang MPEG-TS firmware/protocol:
- Mga audio at video stream lang ang sinusuportahan.
- Ang UART/serial data transmission ay hindi suportado sa ilalim ng MPEG-TS mode.
Mangyaring isaalang-alang ito kapag pumipili ng solusyon sa firmware/protocol.
| Uri ng Protocol | Audio/Video | Transparent na Transmission ng UART |
|---|---|---|
| Pasadyang protocol (Default na) | Sinusuportahan | Sinusuportahan |
| Karaniwang MPEG-TS | Sinusuportahan | Hindi Sinusuportahan |
Q: Mayroon ka bang firmware na sumusuporta sa raw H.264 o RTP sa halip na MPEG-TS para sa UDP streaming?
A: Ang aming UDP firmware ay hindi nagpapadala ng mga raw H.264 elementary stream. Ang UDP streaming ay sinusuportahan sa dalawang format depende sa bersyon ng firmware:
- A custom na pagmamay-ari na format, o
- Ang karaniwang MPEG-TS (MPEG Transport Stream) format
Ang mga ito ay tumutugma sa iba't ibang mga build ng firmware (karaniwang nakikilala sa pamamagitan ng isang suffix gaya ng mga bersyong "T" o hindi "T".).
Q: Sinusuportahan mo ba ang RTP bilang isang standalone streaming protocol?
A: Hindi kami nagbibigay ng hiwalay na "raw RTP streaming mode." Gayunpaman, Ginagamit na ang RTP sa loob ng RTSP streaming. Sa RTSP mode, ang audio at video ay ipinapadala sa mga RTP packet bilang bahagi ng RTSP/RTP/RTCP stack. Kaya nga, Ang RTP ay hindi direktang sinusuportahan sa pamamagitan ng RTSP sa halip na bilang isang independiyenteng format ng streaming ng UDP.
Q: Maaari bang ang system ay mag-output ng raw H.264 sa UDP?
A: Hindi. Ang Raw H.264 elementary stream transmission ay hindi suportado sa UDP. Ito ay dahil sa laki ng packet at mga hadlang sa network. Ang isang solong I-frame ay maaaring napakalaki at hindi mapagkakatiwalaang maipadala sa isang IP packet.
Para sa stable na transmission, ang mga video stream ay dapat na naka-encapsulated gamit ang isang transport format tulad ng:
- MPEG-TS, o
- RTP (sa pamamagitan ng RTSP)
Q: Paano ang key frame (GOP) na-configure ang pagitan?
A: Ang pagitan ng key frame ay kinokontrol ng Parameter ng GOP sa web interface (pahina ng mga setting ng video).
- Kung nakatakda ang GOP sa 0 (default/auto mode), awtomatikong inihanay ng system ang I-frame interval sa input frame rate.
- Halimbawa: Kung ang input ay 1080p60, pagkatapos ay ang I-frame interval ay magiging 60 frame (1 pangalawang GOP).
Tinitiyak nito ang adaptive encoding na gawi batay sa mga katangian ng pinagmulan ng input.
Q: Bakit hindi direktang maipadala ang raw H.264 sa IP/UDP?
A: Dahil H.264 frames (lalo na ang I-frames) ay maaaring napakalaki at lumampas sa maximum na yunit ng paghahatid (Tao) ng mga network packet. Nang walang encapsulation, hindi matitiyak ang maaasahang paghahatid. Kaya nga, dapat na naka-packet ang video gamit ang mga standardized na format ng streaming gaya ng MPEG-TS o RTP para sa tamang pagse-segment, tiyempo, at muling pagpupulong.
Q: Ang latency ng system ko ay ~230 ms sa kabuuan. Ang decoder at display ay tumatagal ng ~45 ms, umaalis ~185 ms para sa camera at encoder. Inaasahan kong nag-aambag ang camera ng ~60 ms (4 mga frame sa 60 FPS), kaya ang encoder ay parang ~120 ms. Mayroon bang paraan upang bawasan ang latency ng encoder? Naiintindihan ko na pangunahing nakakaapekto ang MPEG-TS sa pag-decode, hindi encoding.
A: Latency Breakdown at Patnubay sa Pag-optimize
Upang tumpak na i-optimize ang latency ng system, mahalagang patunayan muna ang bawat yugto nang nakapag-iisa bago ipagpalagay ang mga bottleneck.
1. I-verify muna ang Latency ng Camera (Kritikal na Hakbang)
Bago i-optimize ang pag-encode, dapat mong kumpirmahin ang aktwal na kontribusyon ng camera.
Isang praktikal na paraan ng pagsukat:
- Direktang ikonekta ang HDMI output ng camera sa isang display
- Ituro ang camera sa isang high-precision na stopwatch na ipinapakita sa isang hiwalay na PC monitor
- Kunin ang parehong live na eksena at HDMI output nang sabay-sabay
- Ihambing ang mga timestamp ng frame upang kalkulahin ang end-to-end na latency ng camera
Mga Tala:
- Gumamit ng high-precision na stopwatch (ang mas maliit na pagitan ng tik ay nagpapabuti sa katumpakan)
- Ang pagpoproseso ng ISP ng camera ay kadalasang isang pangunahing kontribyutor
- Sa aming karanasan:
- 1080Ang mga p camera ay karaniwang nagpapakilala ng ~100 ms latency
- Maaaring lumampas dito ang ilang modelo dahil sa mas mabibigat na pipeline ng ISP
2. May Malaking Epekto ang Configuration ng Camera
Kung mataas ang latency ng camera, ang pag-optimize ay dapat magsimula doon:
- Mas mababang resolution (hal., 720p vs 1080p) → binabawasan ang pagkaantala ng ISP at pipeline
- Mas mataas na frame rate (hal., 60 fps vs 30 FPS) → binabawasan ang latency ng buffering ng frame
- Mas simpleng pipeline sa pagproseso ng imahe → binabawasan ang pag-load ng ISP
Ang mga pagbabagong ito ay kadalasang binabawasan ang latency nang mas epektibo kaysa sa pag-tune ng encoder.
3. Ang Latency ng Encoder ay Malamang na Sobra sa Pagtantya
A 120 Ang pagkaantala ng pag-encode ng ms ay karaniwang hindi malamang para sa mga tipikal na encoder ng hardware.
Batay sa mga panloob na sukat:
- Isang hardware encoder + tagabukas ng Kodigo + transmission + ang display pipeline sa Ethernet ay karaniwang nagreresulta sa:
- ~80–100 ms kabuuang end-to-end latency
Ito ay nagpapahiwatig:
- Ang encoder-only latency ay mas mababa kaysa sa 120 MS
- Ang pag-encode ay karaniwang hindi ang nangingibabaw na nag-aambag sa isang maayos na na-configure na system
4. Mahalaga ang Paraan ng Paghahatid (Lalo na ang Wireless)
Paki-verify kung gumagamit ang system:
- Wired Ethernet
- Wireless transmission
Kung wireless ang ginagamit:
- Mababang bandwidth (<20 Mbps) maaaring magpakilala ng makabuluhang pagkaantala
- Malaking I-frame transmission ay maaaring magdulot ng buffering at queuing delay
- Maaari nitong kapansin-pansing mapataas ang end-to-end latency kahit na mahusay ang pag-encode
5. MPEG-TS at Protocol Overhead Clarification
Ang iyong pang-unawa sa pangkalahatan ay tama:
- Ang MPEG-TS ay hindi makabuluhang nagdaragdag ng latency sa yugto ng pag-encode
- Karamihan sa overhead ng protocol ay nauugnay sa pag-uugali ng packetization at pag-decode, hindi pag-encode mismo
- Ang mga operasyon ng mux/demux ay pangunahing mga pagpapatakbo ng memorya at may hindi gaanong pagkaantala sa mga tipikal na system
6. Inirerekomendang Debugging Approach
Upang tumpak na mahanap ang mga pinagmulan ng latency:
- Magdagdag ng mga panloob na timestamp sa bawat yugto ng pipeline:
- Oras ng pagkuha ng camera
- Input/output ng encoder
- Pagpapadala/pagtanggap ng network
- Output ng decoder
- Pag-refresh ng display
- Tiyaking magaan ang pag-log at hindi makakaapekto sa performance
- Subaybayan ang buffer depth sa real time para makita ang queue buildup
Buod ng aming sagot
- Ang pagkaantala ng ISP ng camera ay kadalasang isang pangunahing nakatagong kontribyutor (~100 ms sa 1080p ay karaniwan)
- Ang latency ng encoder ay karaniwang mas mababa kaysa sa ipinapalagay
- Ang wireless transmission at buffering ay maaaring makabuluhang tumaas ang pagkaantala
- Ang sistematikong pagsukat ng timestamp ay ang pinaka maaasahang paraan upang matukoy ang tunay na bottleneck
Magtanong ng isang katanungan
Ipinadala ang iyong mensahe