Ettersom vi arbeider med video, design av skjermløsninger, kameraovervåking og IP nettverk har det etterhvert falt naturlig å skrive noen ord om“Video over IP” i tillegg til artiklene om skjermer, lys, interface kablede og trådløse nettverksløsninger, protokoller og lag, etc, etc.
Video signaler har stort sett alltid blitt overført over kabel i alle år. Kvaliteten har vært varierende, og den første standarden for video i farger var composite. Senere har det kommet en mengde andre standarder som til en viss grad har forbedret kvaliteten fra composite signalene (som forøvrig fortsatt er i utstrakt bruk). Likevel er composite blitt hengende igjen som en standard for CVBS overføringer og applikasjoner innenfor CCTV. Irontech designet for en del år tilbake skjermer for et system som bl.a. skulle øke bildekvaliteten ved bruk av composite signal. Irontech leverte et slikt system til Flytoget basert på ønske om å benytte en del gamle komponenter, og løsningen er fortsatt i bruk der med veldig lav feilrate. For å kunne benytte mer moderne skjermer i 16:9 format kan composite fortsatt benyttes til f.eks. 720i standarden, men dette krever også andre kamera løsninger.
Rundt 2005 begynte imidlertid digital video overføring å bre seg, og raskt ble det IP nettverk som fikk suksess for profesjonelt bruk. Video over IP nettverk hadde begrenset oppløsning og bildefrekvens den første tiden både pga kabel og IP standarden men også pga kamera teknologien som ble benyttet samt komprimeringen. Kabelnettet som benyttes er det samme som bl.a. benyttes for kablet Ethernet, og kan overføre både video, lyd, div seriell informasjon, generell datakommunikasjon, div kontroll- og overvåkingsignaler samt POE (dvs bl.a. power for kamera) etc, etc. Etterhvert som video og annet blir mer og mer tatt i bruk har mye av datakommunikasjonen flyttet seg over på optisk (fiber) nettverk.
Irontech har derfor snart klar med neste generasjon overvåkingsystem for offentlig transport som tog, T-bane, trikk, buss,og andre miljøer som kan være vanskelig for tradisjonell elektronikk. Men også andre former for transport, oljebransjen, industrielle systemer, etc, etc har glede av robuste video løsninger som tåler spenningsvariasjoner, temperatur, risting, vanskelige lysforhold, kondens, etc, etc. Samtidig som vi har laget et «inteligent system» har vi også valgt å lage et enkelt brukergrensesnitt men med funksjoner som tidligere ikke har vært implementert i slike overvåkningsystemer.
Video over IP og TSN Task-Group
Nå har imidlertid trådløse wifi standarder også blitt oppgradert til mulighet for alternativer til kablet nettverk. Spesielt 801.11ac er en standard som gir rom for trådløs overføring. Også forbedrede kompresjonstandarder har bedret mulighetene for video over IP.
Men med stadig høyere oppløsning på bildene og kanskje flere kamera tilkoplet er det vanskelig å vite hva som fungerer og ikke. I tillegg er det mange nye applikasjoner som skal benytte de samme nettverkene.
For å bedre situiasjonen er det oppretttet en ny arbeidsgruppe som skal arbeide videre med bl.a. video over IP, IP telefoni, etc, etc. Standarden som denne gruppen arbeider med vil i hovedsak relatere seg til 802.1Q, men også sikkerhetstandarder som 802.1X og 802.1A er områder det arbeides med. Det inkluderer også områder som Stream reservation, path control, path reservation. AVTP som står for Audio Video Time Protocol er en av de tingene det arbeides med for å få et raskere og sikrere nettverk der denne typen overføring skal fungere feilfritt og trygt. Den gamle gruppen het AVB Task-Group men har fått nytt navn til TSN Task-Group der TSN står for Time Sensitive Networking.
På http://www.ieee802.org er det mulig å holde seg oppdatert på det som skjer. Irontech arbeider bare med spesifikke prosjekter og vi holder oss dermed bare delvis oppdatert. Leverandører av nettverksutstyr og kamera løsninger vil imidlertid være vesentlig bedre oppdatert enn det vi er. Her er det imidlertid en link til en pdf som er status i skrivende stund (dette er skrevet i april 2015).
som Men også datakraft kan ha en del å si såfremt det skal vises video fra harddisken. F.eks oppdaget en av våre kunder at de fikk problemer med å kjøre Full HD (1920 x 1080) video fra harddisken på en maskin basert på Atom N270 med 2GB RAM. Dette oppstod pga det som beskrives som “overhead” (for hardware og OS) og begrenset dermed overføring av den bildekvaliteten som var ønskelig. For å løse dette uten å kjøpe nytt utstyr valgte de å gå over til Linux på den samme maskinen ettersom Linux har mindre overhead.
Beregning av båndbredde for overføring
Men for video fra kamera er det i første omgang overføringen som er problemet og ikke nødvendigvis operativsystemet. I slike tilfelle kan det være kjekt å ha en ide om hva som kreves av båndbredde for å kunne overfør informasjonen uten for store problemer
I hovedsak vil en beregning basere seg på bildeoppløsning (antall punkter som skal vises), antall farger på bildene og antall bilder pr sekund. De to første utgjør det som beskrives som “frame size” når de ganges med hverandre. I tillegg vil variabler som båndbredde for lyd (om lyd skal overføres),protokollene og kompresjons standardene som skal benyttes til overføringen + noe “smårusk” som overhead, etc men dette kan en delvis se bort fra.
La oss velge et eksempel med en standard som kaller seg D1 (en forholdsvis lav-oppløselig digital bildestandard) som bruker 720 x 480 punkter. Vi antar videre at det er snakk om en 24bits fargedybde (dette er matematisk det samme som 224, dvs mulighet for litt over 16 millioner farger). Ofte er fargedybden beskrevet som bpp eller bits per pixel. Antall bilder settes til 30 bilder pr sekund som er en mye brukt standard som ikke gir akseptabel bildekvalitet uten for mye flimmer.
Regnestykket for nødvendig båndbredde vil da se slik ut:
720 x 480 (oppløsning på bildet) x 24 (fargedybde) x 30 (antall bilder pr sekund) vil da kreve en båndbredde på 248.832.000, dvs nesten 250Mbps.
Ved å gå ned til 12 bits fargedybde (dvs 212 som tilsvarer 4096 farger) vil krav til overføringshastighet på nettverket bli 720 x 480 x 12 x 30 = 124.416.000 (ca 125Mbps)
Dette er såkalt «rå-data» fra f.eks. et overvåkingskamera og ingen overfører i praksis data av denne typen over ethernet. Så godt som alle benytter en eller annen form for komprimering.
Komprimering
Dette er naturligvis så mye at det er altfor mye for de fleste systemer. bl.a. vil det kreve 1Gbit ethernet linje (Cat 6) noe som ikke fantes da overføring begynte å brukes. For å klare så stor dataoverføring måtte det innføres video komprimering.
Vha populære komprimeringsalgoritmer som MJPEG,MPEG4 og H.264 ble datamengden redusert med 80-95%. Dette tilsier at beregningene ovenfor med krav om overføring av 250Mbps eller 125Mbps vil bli redusert til hhv. 25Mbps og 12,5Mbps med en kompresjon på 90%, noe som skaper mulighet for å overføre video over de fleste kablede nettverk. Med MPEG4 komprimering har en kommet ned under 5Mbps for HD video, og med slike tall kan en få ganske mange videokilder inn på nettverkskabel, routere og switcher uten å investere i de siste ekstreme løsningene mht tilgjengelig båndbredde. Men flere kamera forutsetter at det er mindre av annen ethernet trafikk.
Valg av kompresjonsløsning kan være vanskelig og er avhengig av bruksområde. På generell basis vil vi påstår at H.264 er en bedre kompresjonsløsning enn f.eks. MPEG4 når det gjelder algoritmen og målet med å få pakkene som oversendes så små som mulig. MEN -, det er en klar ulempe at H.264 krever mer datakraft for og fullføre komprimeringen. En må derfor vurdere om en skal benytte løsningen i et miljø der en har god tilgang på datakraft (f.eks kontor miljø) eller om en har begrenset tilgang til datakraft (f.eks. i industri miljø der en må benytte mindre vifteløse systemer).
Om nettverket ikke kan håndtere video overføring ihht ønsket kvalitet
Alle video standarder benytter en konstant overføringshastighet (beskrevet som CBR – Constant Bit Rate). Desto høyere bit rate desto bedre kvalitet kan bli oppnådd på videoen som blir vist, men aldri bedre enn den opprinnelige kilden eller det svakeste ledd (kamera router eller lagret video, etc). Det er imidlertid også på dette området enkelte leverandører som har introdusert sine egne løsninger om det f.eks. blir “trafikk kork” pga for mye annen trafikk på nettet og f.eks. reduserer bildefrekvensen i slike situasjoner. Dette tilsier at om en har et nettverk med store datamengder må en velge mellom dårligere bildekvalitet på video eller tregere kommunikasjon for annen type data. Ryktene sier at slike funksjoner som endring av “frame rate” etc i realiteten er basert på Qos protokollen i slike applikasjoner som i her snakker om, men dette kan jeg ikke si noe sikkert om. Eksakt hvor mye båndbredde som kreves for video er imidlertid umulig å si da det er avhengig av kompleksiteten på bildet. De fleste forstår at et bilde som er mer eller mindre helt svart (f.eks natt bilder) vil kunne komprimeres til mye mindre datamengde enn et komplekst bilde med mange farger og høy oppløsning.
Måle hastighet på et lokalt nettverk
Å måle hastigheten på et lokalt nettverk er vanskelig og ikke noe jeg vil anbefale hvem som helst å forsøke da det kan gi helt feil verdier (hastigheter).
En del driftsteknikere som drifter lokale nettverk kan imidlertid ha glede av å vurdere flaskehalser og evt bedre nettverket i slike tilfeller.
Et verktøy som kan benyttes i miljø som Linux, Unix og Windows er Netperf. Dette kan lastes ned fra flere nettsider, men vær forberedt på en del «fikling» for å få riktige tallverdier. For de som arbeider i Linux og Unix miljø er i tillegg ttcp et alternativ.
En del produsenter av switcher tilbyr imidlertid en del avanserte funksjoner for de som ønsker å benytte SNMP overvåking. Vha SNMP kan en detektere feil ved enkelte porter på switcher og evt belastning av en switch eller en enkelt port samt få alarmer om en port slutter å fungere, etc, etc. En mulig feil eller behov for å bytte en switch kan o så tilfelle faktisk detekteres før det oppstår et problem slik at nettet eller en switch kan utbedres på et tidlig tidspunkt. Mer om slik overvåking har vi på vår nettside som omhandler SNMP.
Hastighet og «lagging» er dessuten problemstillinger som får endret betydning om en skal bevege seg mellom flere aksess punkt og roaming tider for å etablere kontakt om det nyttes TCP/IP.
TCP vers UDP protokoll
I eksemplene ovenfor har vi definert «video on Demand» som en video/film, en forespørsel fra server eller over internett. Survilance eller overvåkningsvideo vil ofte bli håndtert med UDP protokoll fremfor TCP protokoll. UDP er forøvrig den løsningen som også benyttes av SNMP for overvåking.
TCP protokollen benytter «handshake» signal og en del annen overhead informasjon for å sikre at riktig data blir overført. UDP benytter kun noen kontroll bit og “streamer” video uten å vente på svar om riktig info er mottatt etc. På denne måten er et mulig å oversende en større mengde data (video) med UDP fremfor TCP. Litt mer om protokoller finner du her.
Copyright © 2020
Jørn Jensen
Gjengitt med tillatelse.
Om ønsker informasjon som ikke finnes på våre sider, ber vi deg kontakte oss med f.eks. en mail til vår support avdeling. Vi vil da forsøke å få opp mer informasjon så raskt som mulig.