We hebben apparaten nodig, Om de informatie over volledige HD -cameravideo's met SDI te ontvangen (Seriële gegevensinterface) op de lijn en codeer informatie in de H.265-standaard. Gecomprimeerde gegevens moeten in DVB-T worden verzonden (Digitale video-uitzending via de ether) of DVB-S-standaard. De analoge uitgang van de ontworpen module kan zowel I- als Q-signalen accepteren, evenals gemoduleerde signalen.
Inhoudsopgave
Q: Ondersteunt uw SDI-video-encoder TSI-invoer / uitgang?
EEN: Ons bestaande coderingsbord naar modulatiebord verzendt gegevens via de netwerkpoort. In plaats van de TSI-interface die u noemde. Dit heeft geen invloed op het gebruik van de zender naar de ontvanger. Dit is een interne interface van de zender.
Q: Ondersteunen uw encoder-decoderborden 525 ik50 tot 1080 P60 op het videoformaat?
EEN: Nu ondersteunen onze SDI-video-encoderborden HD: 720p bij 23,98 Hz/24 Hz/25 Hz/29,97 Hz/30 Hz/50 Hz, 59,94 Hz/60 Hz en 1080p bij 23,98 Hz/24 Hz/25 Hz/29,97 Hz/30 Hz/50 Hz/59,94 Hz/60 Hz. Het ondersteunt niet 525 i50 videoformaat, is het goed?
Q: Ondersteunt uw SDI COFDM DVB-T H265 SDI Encoder RF-uitgangsvermogen 0 ~ 10dBm？
EEN: Uw vereiste uitgangsfrequentiepunt van 400 MHz tot 2800 MHz is erg breed.
Het is moeilijk om een output van 0 ~ 10 dBm te bereiken onder zo'n breed frequentiepunt, en het toevoegen van een eindversterker op het bord zal het stroomverbruik en de warmte verhogen (je zei ook dat er geen ventilator nodig is voor warmteafvoer).
Bent u bereid akkoord te gaan met onze bestaande -3 tot -10dBm output en voeg vervolgens uw eigen PA toe (vermogensversterker)?
Q: Wat is de afmeting van uw COFDM DVB-T H265 SDI-encoder?
Heeft u een speciaal afmetingsverzoek?? Onze bestaande maat is 70x45mm.
EEN: Onze bestaande video-encoder- en decoderkaarten kunnen aan uw projectbehoeften voldoen.
De grootste zorg van mijn ingenieur is dat uw bedrijf, als lid van de omroep- en televisie-industrie stelt hij relatief hoge eisen aan de beeld- en videokwaliteit.
Ons videocoderingsbord voert verliesgevende compressie uit voor een lage latentie. Kunt u een reeks bestaande monsters nemen om de beeldkwaliteit te testen en te bevestigen?? Als u denkt dat onze monsters aan de eisen van uw bedrijf kunnen voldoen, wij zullen het bord opnieuw ontwerpen en tekenen volgens de vereisten van uw bedrijf.
Q: Kunt u meer informatie geven over VBR??
Door video toe te passen op de TX, de VBR-parameter zal in de loop van de tijd veranderen en is geen statische waarde. Kunt u hier meer informatie over geven?
EEN: VBR is de bitsnelheid voor videocodering op de zender. Omdat het videobeeld dynamisch verandert, VBR is uiteraard variabel, maar het fluctueert rond de coderingsbitsnelheid die door het transmissiesysteem is ingesteld: 7.81*0.8=6,248 Mbps.
Q: Ondanks dat ik flash-opslag op mijn ontvanger heb, REC OFF en Geen opslag worden op het scherm weergegeven. Waarom gebeurt dit??
Je zei in de beschrijving: Key2: Schakelknop voor video -opname, korte pers om de status te wijzigen. De ontvanger controleert automatisch het opslagapparaat (micro SD-kaart of USB-schijf, Prioriteit SD -kaart) na het inschakelen en begin met het opnemen van video wanneer het opslagapparaat is geplaatst. Druk gewoon op de knop om te stoppen of opnieuw op te nemen.
EEN: Het ontvangende systeem kan het USB-flashstation niet detecteren. De USB-flashdrive moet worden geformatteerd naar een formaat dat ons systeem kan herkennen.
Q: Zowel B1 als B2 zijn nul. Dit geeft aan dat er sprake is van een 0 % Bijtfoutpercentage!!! Welk bereik van deze parameters is acceptabel?
EEN: Het optreden van een bit error rate kan problemen met het videobeeld veroorzaken. Wanneer de bitfoutsnelheid erg klein is, het heeft geen invloed op het videobeeldeffect.
Q: Kan ik de inhoud van het programmeerscherm aanpassen??
EEN: De weergave-inhoud van het configuratiepaneel (programmeur) staat niet open voor klanten voor wijziging.
Q: Waarom is het S2-kanaal niet geprogrammeerd?? Het lijkt erop dat de tweede tuner momenteel niet functioneert.
EEN: S2 verwijst naar ontvangstantenne 2, die normaal kan werken. Frequentie en bandbreedte zijn hetzelfde s1 en s2.
Q: Waarom de latentie die ik heb berekend enorm is? Het is in de buurt 470 Mevrouw.
In je beschrijving komt: De standaard normale functies van onze ontvangermodule kunnen worden gecombineerd met onze H.265-zendermodule. De HD-videolatentie vanaf de invoer van de zender tot de weergave op het HDMI-scherm van de ontvanger bedraagt ongeveer 200 ms tot 250 ms.
EEN: De vertraging die we hebben getest was ongeveer 250 ms. Hoe heb je het getest? De vertragingsmanier die we hebben getest, Controleer de Youtube videolink.
Q: Hoeveel latentie heeft uw SDI-encoderzender en decoder-ontvangermodule?
Ik herinner me dat je zei dat je het protocol had geoptimaliseerd voor een betere latentie. Omdat ik je snelle H.264-latentie niet gebruik (130 Mevrouw) hoeveel latentie moeten we hebben op mijn opstelling?
EEN: U heeft bevestigd dat u H265 moet ondersteunen, maar niet de H264-modus met lage latentie. Om een lage latentiemodus te bereiken, de ontvanger moet worden gewijzigd naar een andere ontvangerhardware, en de bijbehorende firmware moet vóór verzending worden gebrand.
Q: Kan ik uw COFDM-ontvanger gebruiken om het normale DVB-T TV-kanaal te ontvangen??
Je zei dat je het videoprotocol hebt gewijzigd voor een betere latentie in TX. Kan ik uw RX gebruiken als commerciële DVB-T? hoe kan ik het normale DVB-T-kanaal ontvangen?
EEN: Als je hem echt als normale DVB-T ontvanger wilt gebruiken, we moeten een andere firmware upgraden. (verwijder de codering op de encoder en decodering op de decoder).
Q: Hoe kan ik uw OSD-menufunctie op de COFDM-ontvanger gebruiken??
In je beschrijving komt:
De ontvangermodule bevat ook DVR-opnamefunctionaliteit met een Micro SD-kaart of USB-schijf. De ontvangermodule maakt ook videostreaming via USB mogelijk voor externe Android-apparaatdecoders zoals smartphones of Android PAD. Hierdoor kunnen meerdere externe kijkers dezelfde video bekijken
tegelijkertijd. De ontvangermodule ondersteunt ook tekenreeksen op het videoscherm met de video samen in OSD-modus.
EEN: Zien OSD online-documentatie.
Q: Hoe kan ik de AES-encryptie inschakelen? Waar moet ik de sleutel invoeren?
EEN: Het configuratiepaneel kan het wachtwoord bewerken en wijzigen.
Q: Geef de vraag over de striktekstafbeelding aan:
EEN: Deze optionele functie is vereist voor andere producten (de netwerkpoortfunctie wordt gebruikt om verbinding te maken met een draadloze tweerichtingsverbinding). Negeer dit in uw aanvraag.
Q: Wat is de tijdsvertraging van de UART-gegevens bij de eenrichtingstransmissie?
Voor UART-gegevens van TX naar RX, zijn de gegevens die worden verwerkt via het coderingsproces of in realtime worden verzonden? Ik heb realtime gegevensoverdracht nodig.
EEN: De gegevens en video worden samen verzonden via een draadloos cofdm-pakket. De vertraging is dus hetzelfde als bij video.
Q: Voor zender. Het is mogelijk om GI en FEC en een andere parameter te wijzigen volgens uw tabel in de beschrijving?
EEN: Ja.
Q: Waar komt het exacte vermogen op dit punt vandaan? 1350 tot 1450 MHz? Ik heb deze informatie nodig om een PA te ontwerpen.
De maximale output van de frequentieband 1350~1450 bedraagt ongeveer -10±2dBm. Het wordt aanbevolen om de PA te ontwerpen op basis van -15dBm input. Onze zender kan worden afgesteld tot -15dBm.
Q: Heeft uw programmeur de functie om de fabrieksinstellingen te herstellen??
Als ik parameters van welke kant dan ook verander, zoals frequentie GI of FEC of videobandbreedte, hoe kan ik alle parameters resetten in de fabrieksresetmodus? Ik ben nieuw op dit bord, en ik moet enkele parameters wijzigen om mijn wens te verwezenlijken. Maar ik ben bang om de standaardinformatie te veranderen.
EEN: Onze TX / RX-programmeur heeft geen fabrieksresetfunctie.
Q: Ondersteunt uw SDI-video-ingangsencoder 1080i25/1080i30?
Het ondersteunt 1080i50 en 1080i60, het ondersteunt geen 1080i25 of 1080i30.
Q: Kunt u mij enkele technische bestanden aanbieden? voor de reparatie van het voedingsgedeelte van de Vcan1731 SDI video-encoderkaart?
EEN: Controleer de bestanden via de onderstaande link.
- 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
Ons onderhoudsidee is om eerst uit te sluiten of er kortsluiting is en waar de kortsluiting zit. Bijvoorbeeld, ontkoppel de magnetische kraal of de weerstand van 0 ohm tussen het vermogens-IC en het daaropvolgende circuit, en gebruik vervolgens een multimeter om te meten of het stroom-IC kapot is of dat het daaropvolgende circuit is kortgesloten. Als het stroom-IC kapot is, vervang het stroom-IC; als het volgende circuit kortgesloten is, je moet het volgende circuit controleren.
Q: Kan de encoderkaart UART-gegevens ontvangen en doorsturen via UDP-communicatie (IK P:Haven)?
EEN: Ja, UART-gegevensoverdracht wordt ondersteund onder onze standaard aangepast protocol, met enkele belangrijke overwegingen:
1. Aangepast protocol (Standaardfirmware)
Onze standaard verzendfirmware gebruikt een aangepast gemultiplext protocol dat ondersteunt UART transparante transmissie (seriële doorvoer).
- UART-gegevens worden samen met audio-/videostreams gemultiplext.
- daarom, de ontvangende kant moet de overeenkomstige gebruiken aangepaste protocol demux-bibliotheek om UART-gegevens van de mediastream te scheiden.
- Bij gebruik in combinatie met ons decoderbord, UART-transparante transmissie werkt naar behoren en kan zoals verwacht worden doorgestuurd/ontvangen.
Opmerking voor pc-spelers
Onze huidige pc-spelersoftware demuxt en verwerkt alleen:
- Videogegevens
- Audiogegevens
Momenteel, dat doet het niet UART-seriële gegevens verwerken of uitvoeren.
2. Standaard MPEG-TS-protocol
Als de encoderkaart wordt geflasht met de standaard MPEG-TS-firmware/protocol:
- Alleen audio- en videostreams worden ondersteund.
- UART/seriële gegevensoverdracht is mogelijk niet ondersteund in de MPEG-TS-modus.
Houd hier rekening mee bij het selecteren van de firmware/protocoloplossing.
| Protocoltype | Audio / Video | UART transparante transmissie |
|---|---|---|
| Aangepast protocol (Standaard) | ondersteunde | ondersteunde |
| Standaard MPEG-TS | ondersteunde | Niet ondersteund |
Q: Heeft u firmware die raw H.264 of RTP ondersteunt in plaats van MPEG-TS voor UDP-streaming?
EEN: Onze UDP-firmware verzendt geen onbewerkte elementaire H.264-streams. UDP-streaming wordt in twee formaten ondersteund, afhankelijk van de firmwareversie:
- EEN aangepast eigen formaat, of
- De standaard MPEG-TS (MPEG-transportstroom) formaat
Deze komen overeen met verschillende firmware-builds (doorgaans onderscheiden door een achtervoegsel zoals "T" of niet-"T"-versies).
Q: Ondersteunt u RTP als een zelfstandig streamingprotocol?
EEN: We bieden geen aparte ‘raw RTP-streamingmodus’. Echter, RTP wordt al intern gebruikt binnen RTSP-streaming. In RTSP-modus, audio en video worden verzonden via RTP-pakketten als onderdeel van de RTSP/RTP/RTCP-stack. daarom, RTP wordt indirect ondersteund via RTSP in plaats van als een onafhankelijk UDP-streamingformaat.
Q: Kan het systeem onbewerkte H.264 via UDP uitvoeren??
EEN: Nee. Ruwe H.264 elementaire stroomtransmissie wordt niet ondersteund via UDP. Dit komt door de pakketgrootte en netwerkbeperkingen. Een enkel I-frame kan erg groot zijn en kan niet op betrouwbare wijze in een enkel IP-pakket worden verzonden.
Voor stabiele transmissie, videostreams moeten worden ingekapseld met behulp van een transportformaat zoals:
- MPEG-TS, of
- RTP (via RTSP)
Q: Hoe is het sleutelframe (GOP) interval geconfigureerd?
EEN: Het keyframe-interval wordt bepaald door de GOP-parameter in de webinterface (pagina met video-instellingen).
- Als GOP is ingesteld op 0 (standaard/automatische modus), het systeem lijnt het I-frame-interval automatisch uit met de invoerframesnelheid.
- Voorbeeld: Als de invoer is 1080p60, dan zal het I-frame-interval zijn 60 frames (1 tweede GOP).
Dit zorgt voor adaptief coderingsgedrag op basis van de kenmerken van de invoerbron.
Q: Waarom kan onbewerkte H.264 niet rechtstreeks via IP/UDP worden verzonden??
EEN: Omdat H.264-frames (vooral I-frames) kan erg groot zijn en de maximale transmissie-eenheid overschrijden (Man) van netwerkpakketten. Zonder inkapseling, betrouwbare levering kan niet worden gegarandeerd. daarom, video moet worden gepakketteerd met behulp van gestandaardiseerde streamingformaten zoals MPEG-TS of RTP voor een goede segmentatie, timing, en opnieuw in elkaar zetten.
Q: Mijn systeemlatentie is in totaal ~230 ms. Decoder en display nemen ~45 ms in beslag, waardoor er ~185 ms overblijft voor camera en encoder. Ik verwacht dat de camera ~60 ms bijdraagt (4 kaders bij 60 fps), dus de encoder lijkt ~120 ms te zijn. Is er een manier om de latentie van de encoder te verminderen?? Ik begrijp dat MPEG-TS vooral de decodering beïnvloedt, niet coderen.
EEN: Latency-uitsplitsing en optimalisatierichtlijnen
Om de systeemlatentie nauwkeurig te optimaliseren, het is belangrijk om elke fase eerst afzonderlijk te valideren voordat er knelpunten worden aangenomen.
1. Controleer eerst de cameralatentie (Kritieke stap)
Voordat u de codering optimaliseert, u moet de daadwerkelijke camerabijdrage bevestigen.
Een praktische meetmethode:
- Sluit de HDMI-uitgang van de camera rechtstreeks aan op een beeldscherm
- Richt de camera op een zeer nauwkeurige stopwatch die op een aparte pc-monitor wordt weergegeven
- Leg zowel de livescène als de HDMI-uitvoer tegelijkertijd vast
- Vergelijk frametijdstempels om de end-to-end cameralatentie te berekenen
Opmerkingen::
- Gebruik een uiterst nauwkeurige stopwatch (een kleiner tikinterval verbetert de nauwkeurigheid)
- Camera-ISP-verwerking levert vaak een belangrijke bijdrage
- In onze ervaring:
- 1080p-camera's introduceren doorgaans een latentie van ~100 ms
- Sommige modellen kunnen dit overschrijden vanwege zwaardere ISP-pijpleidingen
2. Cameraconfiguratie heeft een grote impact
Als de cameralatentie hoog is, Optimalisatie zou daar moeten beginnen:
- Lagere resolutie (Bijv., 720p versus 1080p) → vermindert ISP- en pijplijnvertragingen
- Hogere framesnelheid (Bijv., 60 fps vs 30 fps) → vermindert de latentie van framebuffering
- Eenvoudigere pijplijn voor beeldverwerking → vermindert de ISP-belasting
Deze wijzigingen verminderen de latentie vaak effectiever dan afstemming van de encoder.
3. Encoderlatentie wordt waarschijnlijk overschat
EEN 120 MS-coderingsvertraging is over het algemeen onwaarschijnlijk voor typische hardware-encoders.
Gebaseerd op interne metingen:
- Een hardware-encoder + decoder + overdragen + weergavepijplijn via Ethernet resulteert doorgaans in:
- ~80-100 ms totale end-to-end latentie
Dit impliceert:
- De latentie bij alleen encoders is aanzienlijk lager dan 120 Mevrouw
- Codering is doorgaans niet de dominante bijdrager in een goed geconfigureerd systeem
4. Transmissiemethode is belangrijk (Vooral Draadloos)
Controleer of het systeem gebruikmaakt van:
- Wired Ethernet
- Draadloze transmissie
Als draadloos wordt gebruikt:
- Lage bandbreedte (<20 Mbps) kan aanzienlijke vertraging opleveren
- Grote I-frame-transmissie kan buffer- en wachtrijvertragingen veroorzaken
- Dit kan de end-to-end latentie merkbaar vergroten, zelfs als de codering efficiënt is
5. MPEG-TS en protocoloverheadverduidelijking
Uw begrip is over het algemeen juist:
- MPEG-TS voegt geen significante latentie toe in de coderingsfase
- De meeste protocoloverhead houdt verband met pakketvormings- en decoderingsgedrag, zichzelf niet coderen
- Mux/demux-bewerkingen zijn voornamelijk geheugenbewerkingen en hebben bij typische systemen een verwaarloosbare vertraging
6. Aanbevolen foutopsporingsaanpak
Om latentiebronnen nauwkeurig te lokaliseren:
- Voeg interne tijdstempels toe in elke pijplijnfase:
- Camera-opnametijd
- Encoderingang/uitgang
- Netwerk verzenden/ontvangen
- Decoder-uitgang
- Weergave vernieuwen
- Zorg ervoor dat logboekregistratie lichtgewicht is en geen invloed heeft op de prestaties
- Bewaak de bufferdiepte in realtime om de opbouw van wachtrijen te detecteren
Samenvatting van ons antwoord
- Camera-ISP-vertraging is vaak een belangrijke verborgen oorzaak (~100 ms bij 1080p is gebruikelijk)
- De latentie van de encoder is doorgaans veel lager dan aangenomen
- Draadloze transmissie en buffering kunnen de vertraging aanzienlijk vergroten
- Systematische tijdstempelmeting is de meest betrouwbare manier om het echte knelpunt te identificeren
Een vraag stellen
Bedankt voor je reactie. ✨