Video Quality of Service (QOS)-tutorial

Inleiding

Dit document beschrijft het onderwerp van videogesprekskwaliteit en biedt een tutorial op dingen om in gedachten te houden terwijl QoS (Quality of Service) is geconfigureerd op een Cisco Unified Border Element (CUBE) of een Time-Division Multiplexing (TDM)-poort.

Bijgedragen door Baktha Muralidharan, Cisco TAC Engineer, bewerkt door Anoop Kumar.

Voorwaarden

Vereisten

Dit document is het meest voordelig voor de engineers die bekend zijn met Voice-over-IP (VoIP), hoewel anderen het nuttig kunnen vinden.

Gebruikte componenten

Er wordt geen specifieke hardware of software gebruikt om dit document te schrijven.

Achtergrondinformatie

Digitale audio in zijn meest eenvoudige vorm is een set audiemonsters, die elk monster de geluidsdruk tijdens die periode beschrijft.  Conversationele audio kan met een hoge nauwkeurigheid worden opgenomen en gereproduceerd, met slechts 8000 monsters per seconde[1].  Dit betekent dan dat zolang het netwerk de monsters zonder buitensporige vertraging, jitter en pakketverlies kan vervoeren, de audio nauwkeurig op het andere eind kan worden gereproduceerd.

In tegenstelling tot presentatie, verwerking en transport van video is veel complexer. Helderheid, contrast, kleurverzadiging, reactiviteit (op beweging) en lip-sync zijn slechts een paar eigenschappen die de kwaliteit van de video bepalen. Videomonsters hebben over het algemeen veel grotere ruimte nodig. Het zal niet verrassend zijn dat video een veel grotere vraag plaatst op netwerkbandbreedte, op het transportnetwerk. De audiokwaliteit wordt bepaald door :Microphone Luidspreker in de hoofdtelefoon Codec - de videokwaliteit van het transportnetwerk wordt beïnvloed door: Compatibiliteit met/interoperabiliteit van een cameradisplay apparaat voor videocodec

Opmerking:  Het is belangrijk om te begrijpen dat, in tegenstelling tot audio, er nogal wat doorgaat op video eindpunten als het op kwaliteit aankomt.

Doel

QoS in het algemeen is een groot en complex onderwerp dat vragen om aandacht voor de algehele verkeersvereisten (in plaats van alleen het verkeer dat u wilt verbeteren) en moet worden gecontroleerd op elke netwerkcomponent langs het pad van de mediastroom. Het bereiken van videokwaliteit in een videoconferentie is zelfs nog complexer aangezien het behalve de netwerkcomponenten omvat, onderzoek van de configuratie en het stemmen op de eindpunten. In grote lijnen houdt de videokwaliteit het volgende in:

• End-of-point tuning - optimalisatie van de configuratie van endpoints (bijvoorbeeld resolutie, frame-per-seconde)
• Optimalisatie van het transport - Optimalisatie van het netwerk om het videoverkeer per netwerk SLA te transporteren.
• Interoperabiliteitsoverwegingen - Vaak impliceren videogesprekken endpoints met verschillende mogelijkheden. Het ontwerpen en configureren van systemen om de interoperabiliteit te maximaliseren kan van invloed zijn op de videokwaliteit.

De specifieke focus in dit document zal de QoS overwegingen op de IOS gateway of CUBE zijn bij de verwerking van videooproepen.

Bij het afstemmen op de eindpunten zou een reeks parameters op de video-eindpunten worden aangepast. Dit is uiteraard afhankelijk van het product, maar hier zijn een paar algemene "knoppen":

• Resolutie (d.w.z. beeldformaat)
• Framesnelheid (d.w.z. bewegingsgevoeligheid/realiteit)
• Tagging (d.w.z. op-S-markering)

Het instellen van het netwerk voor video omvat over het algemeen het volgende:

• Begrijpen van de samenstelling van het verkeer dat door de CUBE-lijn stroomt, bv. het piekvolume [call]-volume enz.
• Capaciteit van netwerklink/buis bekijken
• Het ontwerpen van geschikt QoS beleid, om te verzekeren dat SLA voor elke verkeersklasse wordt bereikt

Interoperabiliteit komt in het geding wanneer heterogene (videotelefonie zowel als telepresence (TP) systemen) deelnemen aan een conferentiegesprek. De ervaring die door een TP- en videotelefoonsysteem wordt geboden is fundamenteel anders. Interoperabiliteit tussen beide wordt meestal bereikt door ze te overbruggen met behulp van een proces dat cascading wordt genoemd.

Wat niet in dit artikel voorkomt

Dit is geen ontwerpdocument en ook geen uitgebreid QoS-videodocument. In dit document worden deze onderwerpen met name niet behandeld:

• Signalering [protocollen] van videogesprekken, verder dan nodig is om qos-gerelateerde aspecten te illustreren.
• Setup/configuratie van videoendpoints
• Algemene beoordeling van de QoS-mechanismen waaronder toezicht, wachtrij, traffic shaping en Burst
• Herziening van QoS fig op Layer 2-switches of vertrouwensgrensoverwegingen.

Kenmerken van het netwerkverkeer van video

Video, zoals audio is real-time.  Audio-transmissies zijn een constante-bit-rate (CBR). Het videoverkeer heeft daarentegen de neiging bursty te zijn en wordt aangeduid als variabel bits rate(VBR). Daarom zal de bit rate for video transmission niet altijd constant zijn als we een bepaalde kwaliteit moeten behouden[2].

Afbeelding 1

De bepaling van de bandbreedte en het barsten die voor video vereist zijn, is ook meer betrokken. Dit wordt later in dit document besproken.

• Het videoverkeer is zwaar.
• Videopakketten kunnen vrij groot zijn.
• Audio is altijd CBR. Video is doorgaans VBR. 

Waarom is de video-uitbarsting?

Het antwoord ligt in de manier waarop video wordt gecomprimeerd. Onthoud dat video een reeks beelden (frames) is die werden gespeeld om een visueel beweging-effect te geven. Compressietechnieken die door videocodecs worden gebruikt, gebruiken een benadering die Delta-codering[3] wordt genoemd, en die werkt door waarden van bytes op te slaan als verschillen (delta's) tussen sequentiële (beeldsamples) waarden in plaats van de waarden zelf. Bijgevolg wordt video gecodeerd (en doorgegeven) als achtereenvolgende frames die alleen de "bewegende delen" in plaats van hele frames bevatten.

U vraagt zich waarschijnlijk af waarom de audio ook stapsgewijs verandert? Wel, waar genoeg, maar "beweging" (of dynamiek) beïnvloedt audio niet net zo veel als video. De 8-bits audio-monsters comprimeren niet beter wanneer delta gecodeerd wordt, videomonsters (frames) niet. De relatieve verandering van monster (kader aan kader) in steekproef is video veel kleiner dan dat in audio. Afhankelijk van de aard en de mate van beweging, kunnen videobeeldsamples zeer verschillend in grootte zijn. Afbeelding 2 illustreert video compressie-gerelateerde

Afbeelding 2

Een I-frame is een Intra-gecodeerd beeld, in feite een volledig gespecificeerd beeld, zoals een conventioneel statisch beeldbestand.

Een P-frame (voorgespiegeld beeld) bevat alleen de wijzigingen in de afbeelding ten opzichte van het vorige frame. De encoder hoeft de onveranderlijke achtergrondpixels niet in het P-frame op te slaan, waardoor ruimte wordt bespaard. P-frames staan ook bekend als delta-frames.

Een B-frame (Bi-voorspellende afbeelding) bespaart zelfs nog meer ruimte door verschillen tussen het huidige frame en zowel de voorafgaande als de volgende frames te gebruiken om de inhoud ervan te specificeren.

Meting van de videokwaliteit

Cisco-videoapparatuur meet of rapporteert als zodanig niet over de videokwaliteit, dus de videokwaliteit wordt eerder dan gemeten. Er zijn gestandaardiseerde algoritmen die de kwaliteit meten door middel van een MOS (Mean Opinion Score). Als echter kwesties die worden gemeld met betrekking tot de audio-kwaliteit een indicatie zijn, is het waarschijnlijker dat geval van videokwaliteit (TAC) wordt geopend omdat de gebruiker de kwaliteit niet ziet, maar eerder dan rapport van een tool.

Controles op eindpunten

Factoren die de videokwaliteit beïnvloeden zijn:

• de videocodec (MPEG4, H261, H263, H264 en H265)
• formaat (1/8e scherm, 1/4 scherm, volledig scherm)
• frame rate (1 tot 30 frames per seconde, 6 standaard)
• de instelling voor compressiekwaliteit (laag, middelgroot, hoog)

Over het algemeen is elk van de bovenstaande opties selecbaar/controleerbaar op eindpunten.

Zichtbare artefacten

Kantel, komben & afgrond worden aan deze termen gebruikt, een deel van de videobeschadiging taxonomie.

SLA’s van het transportnetwerk voor videokwaliteit

Aanbevolen netwerk-SLA voor video[4] is als volgt:

• Latentie ≤ 150-300 ms
• Jitter ≤ 10-50 ms
• Verlies ≤ 0,5%

Daarnaast is de aanbevolen SLA-netwerkverbinding voor het transport van audio:

• Latentie ≤ 150-300 ms
• Jitter ≤ 20-50 ms
• Verlies ≤ 1%

Opmerking:  Video is duidelijk gevoeliger voor pakketverlies dan spraak.  Dit zou verwacht moeten worden zodra u begrijpt dat interframes informatie uit eerdere frames vereisen, wat betekent dat het verlies van interframes vernietigend kan zijn voor het proces om het videobeeld te reconstrueren.

Controle van het vervoersnet

Over het algemeen kan de SLA voor videotransport worden geleverd met behulp van QoS-beleid dat sterk lijkt op het beleid dat wordt gebruikt voor audiotransport. Er zijn echter een aantal verschillen door de aard van het videoverkeer.

  

Opmerking:  Hoewel het bereik van dit document beperkt is tot de CUBE-component, onthouden we QoS van end-to-end.

Videovariëteiten

Zijn alle video's hetzelfde? Niet helemaal. De variaties in video als medium zijn onder meer:

• Videotelefonie/videoconferencing
• Realtime interactief
• Relatief lagere bandbreedte. Tot ongeveer 1 Mbps
• TelePresence
• Realtime interactief
• Immerende ervaring
• Vereist zeer hoge bandbreedte
• Streaming
• Realtime, unidirectioneel
• Kan eenvoudig of multicast zijn
• Hoge bandbreedte
• Niet uitstellen gevoelig (de video kan een paar seconden duren om in de rij te staan)
• Grotendeels ongevoelig voor jitter (vanwege het bufferen van de applicaties)
• Het verlies mag niet meer dan 5 procent bedragen.
• Latentie mag niet meer dan 4 tot 5 seconden zijn (afhankelijk van de bufferfuncties van de videoapplicatie)
• Sommige video's (bijvoorbeeld entertainment) zijn mogelijk meegerekend voor de Scavenger-service.

Opmerking:  Met het oog op de beknoptheid worden voor elk type video die hierboven wordt genoemd, geen uitgebreide illustraties gegeven.

Codecs voor videoverkeer

• • H.261-codec werd oorspronkelijk ontworpen voor transmissie via ISDN-lijnen. Met het gebruik van video-bonding zijn videobit rates veelvouden van 64 Kbit/s.
  • H.263-Codec wordt gebruikt in IP-gebaseerde videoconferencing en in ISDN-netwerken. H.263 vereist de helft van de bandbreedte om dezelfde videokwaliteit te bereiken als in H.261. Als resultaat hiervan heeft H.263 grotendeels H.261 vervangen. H.263 is geoptimaliseerd voor een groot bereik bits en niet slechts 64K bits/s zoals bij H.261.
  • H.264/MPEG-4 - Cs is momenteel een van de meest gebruikte bestandsindelingen en gebruikt de halve of minder bit rate of MPEG-2, H.263 of MPEG-4 Part 2.
  • H265 - Een van de vele mogelijke opvolgers van de veelgebruikte H.264 en gebaseerd op de uitbreiding van dezelfde concepten. Hij ondersteunt resoluties tot 8192×4320, inclusief 8K HD.

Opmerking:  Video's, zoals audio, worden uitgevoerd in RealTime Protocol (RTP)

QoS-mechanismen voor video

In beginsel zijn de QoS-mechanismen die worden gebruikt om de SLA's voor een videovervoernetwerk te leveren meestal dezelfde als die voor audio. Er zijn echter enkele verschillen, vooral door de lastige aard van video- en VBR-transmissie.

Er zijn twee benaderingen voor QoS, namelijk geïntegreerde services (intserv) en gedifferentieerde services (diffserv).

Denk aan Intserv als actief op signaleringsniveau en diffserv op mediageniveau. Met andere woorden: het snijmodel waarborgt de kwaliteit door te werken op het bedieningspaneel; diffserv wil de kwaliteit waarborgen door op het niveau van het datumvlak te werken .

In IntServ-architectuurnetwerkapparaten vragen om statische bandbreedtereserveringen en handhaven zij de staat van alle gereserveerde stromen bij het uitvoeren van classificatie-, markering- en wachtdiensten voor deze stromen; de IntServ-architectuur opereert en integreert zowel het besturingsplane als het gegevensvlak, en is als zodanig grotendeels verlaten als gevolg van inherente schaalbeperkingen. Het protocol dat wordt gebruikt om de bandbreedtereserveringen te maken is RSVP (Resource Repubation Protocol).

Er is ook het IntServ/DiffServ-model, dat een soort mix is. Dit model scheidt de bediening van het bedieningspaneel en de werking van het datalevlak. RSVP-operatie is beperkt tot toegangscontrole; met DiffServ-mechanismen voor de verwerking van classificatie-, markering-, politie- en planningsoperaties. Als zodanig is het IntServ/DiffServ-model zeer schaalbaar en flexibel.

Opmerking:  Dit document richt zich alleen op de benadering van verschillende (viz-a-viz prioriteitenschema, LLQ).

Bandbreedtesgarantie

Bandbreedte is duidelijk de meest fundamentele QoS parameter.  Dit hangt af van verschillende parameters, met name:

• Gebruikte codec
• Framesnelheid
• Afbeeldingsgrootte
• Oproeproevenvolume (piek en gemiddelde)

De oude truc om bandbreedte op het probleem te gooien is niet altijd de oplossing. Dit geldt in het bijzonder voor de videokwaliteit. Met CUVA (Cisco Unified Video Advantage) is er bijvoorbeeld geen synchronisatiemechanisme tussen de twee betrokken apparaten (telefoon en pc). Dus moet QoS zo worden geconfigureerd dat hij zich minder schuldig maakt aan jitter, latentie, gefragmenteerde pakketten en out-of-order pakketten.

Opmerking:  Interactive Video heeft dezelfde serviceniveau-eisen als VoIP omdat een spraakoproepen in de videostream is ingebed. Streaming video heeft veel minder nodig vanwege de hoge buffersnelheid die in de toepassingen is ingebouwd.

Tot slot is het belangrijk om te begrijpen dat er in tegenstelling tot VoIP geen schone formules zijn voor het berekenen van de vereiste incrementele bandbreedte. Dit komt doordat de grootte van het videopakket en de pakkettarieven aanzienlijk verschillen en grotendeels een functie zijn van de mate van beweging binnen de videobeelden die worden verzonden. Meer daarover later.

Wachtrijen

Low Latency Queuing (LLQ) is het beleid voor wachtrij voor VoIP-audio. Gezien de strikte vertraging/jitter-gevoelige vereisten van TP en de noodzaak om audio en video voor CUVA te synchroniseren, is ook een prioriteitswachtrij (LLQ) aanbevolen voor al het videoverkeer. Merk op dat, voor video, prioriteitsbandbreedte over het algemeen met 20% wordt opgestuwd om rekening te houden met de overhead.

Kop-compressie

Niet aanbevolen voor video.

Verdeling van verbindingen en interleaving

LFI is een populair mechanisme om te verzekeren dat jitter niet uit de controle komt op langzame verbindingen, waar de seriële vertragingen hoog kunnen zijn.

Maar Interactive-Video wordt dan opnieuw niet aanbevolen voor langzame links. Dit komt doordat LLQ waaraan het videoverkeer is toegewezen, niet aan fragmentatie onderhevig is. Dit betekent dat de grote Interactive-Video pakketten (zoals 1500-byte Full-motion I-frames) seriële vertragingen konden veroorzaken voor kleinere Interactive-Video pakketten.

congestievermijding

Selectieve teruggooi op basis van RTCP

barst

Dit QoS-mechanisme is belangrijk voor het videoverkeer, dat, zoals eerder gezegd, zwaar is.

De optionele burst parameter kan worden geconfigureerd als onderdeel van de prioriteits opdracht[6].

Met H.264 zou de ergste uitbarsting het volledige scherm van (ruimtelijk gecomprimeerde) video zijn. Op basis van uitgebreide tests op TP-systemen blijkt dit 64 KB te zijn. Daarom moet de LLQ burst parameter zo worden geconfigureerd dat hij maximaal 64 KB barst per frame per scherm mogelijk maakt. Zo zou het CTS-1000-systeem dat op 1080p-Best draait (met de optionele ondersteuning van een hulpvideostroom[7]) worden geconfigureerd met een LLQ met een optimale barstparameter van 128 (2x64) KB.

Hoeveel bandbreedte?

Hoeveel bandbreedte is er nodig om een videogesprek correct te transporteren? Voordat we overgaan tot de berekeningen, is het belangrijk de volgende concepten te begrijpen, die uniek zijn voor video.

Resolutie

Dit heeft in feite betrekking op de grootte van het beeld.  Andere veelgebruikte termen hiervoor zijn videoformaat en schermgrootte.  De meest gebruikte videoformaten worden hieronder weergegeven.

Notatie	Videoresolutie (pixels)
KALF	128 x 96
QCIF	176 x 144
SCIF	256 x 192
SIF	352 x 240
CIF	352 x 288
DCIF	528 x 384
4CIF	704 x 576
16CIF	1408 x 1152

De meeste videoconferencingapparatuur wordt uitgevoerd met CIF- of 4CIF-formaten.

Ref.: http://en.wikipedia.org/wiki/Common_Intermediate_Format

Opmerking:  Er is geen equivalentie voor (video)resolutie in de audiobron

Framesnelheid

Dit verwijst naar de snelheid waarmee een beeldapparaat unieke opeenvolgende beelden produceert die frames worden genoemd. De frame-snelheid wordt uitgedrukt als frames per seconde (fps).

Opmerking:  De equivalente metriek in de audiobron is bemonsteringstijd. Bijvoorbeeld 8000 voor g.711ulaw.

Bandbreedteschatting

Bandbreedtecijfers voor videotelefoniesystemen en andere traditionele videoconferencesystemen zijn meestal eenvoudiger.

Als voorbeeld, overweeg een vraag van TP met resolutie van 1080 x1920.  De vereiste bandbreedte wordt als volgt berekend

     2.073.600 pixels per frame

        x3 kleuren per pixel

        x1 bytes (8 bits) per kleur

        x 30 beelden per seconde

        = 1,5 Gbps per scherm. ongecomprimeerd

Met compressie is een bandbreedte van 4 Mbps per scherm (> 99% gecomprimeerd) genoeg om het bovenstaande frame te transporteren!

In de volgende tabel worden enkele van de combinaties genoemd

Beeld formaat	Luminantie pixels	Luminantie lijnen	ongecomprimeerd bit rate (Mbit/s)
			10 beelden/s		30 beelden/s
			Grijs	Kleur	Grijs	Kleur
KALF	128	96	1.0	1.5	3.0	4.4
QCIF	176	144	2.0	3.0	6.1	9.1
CIF	352	288	8.1	12.2	24.3	36.5
4CIF	704	576	32.4	48.7	97.3	146.0
16CIF	1408	1152	129.8	194.6	389.3	583.9

Let op dat bovenstaande berekeningen voor één scherm zijn. Een TP vraag kon meerdere schermen omvatten en zo, totale bandbreedte voor de vraag zou een veelvoud van de per scherm bandbreedte zijn.

Raadpleeg https://supportforums.cisco.com/thread/311604 voor een goede bandbreedte-calculator voor Cisco TP-systemen.

Videoverkeer classificeren/markeren

Hoe wordt het videoverkeer geïdentificeerd/onderscheiden? Een manier om pakketten op CUBE te classificeren is door DSCP-markeringen te gebruiken.

De volgende tabel illustreert DSCP-markeringen per Cisco QoS-uitgangswaarde evenals RFC 4594.

verkeer	Layer 3 PHB	Layer 3 DSCP
Gesprekssignalering	CS3	24
Spraak	EF	46
Videoconferentie	AF41	34
TelePresence	CS4	32
Multimedia streaming	AF31	26
Broadcast-video	CS5	40

PHB - Per hop gedrag. Raadpleeg wat de router doet op het gebied van pakketclassificatie en traffic shaping-functies, zoals meting, markering, vormgeving en toezicht.

Standaard is vóór versie 9.0 CUCM (Cisco Unified Call Manager) gemarkeerd met elk willekeurig videoverkeer (inclusief TelePresence) naar AF41. Vanaf versie 9.0 stelt CUCM de volgende DSCP-waarden in:

• TelePresence (onderdrukkende video)-oproepen op CS4 en
• Video (IP-videotelefonie)-oproepen op AF41

Configuratie

Het configureren om voor audio kwaliteit te afstemmen houdt het berekenen van prioriteitsbandbreedte in en het uitvoeren van LLQ beleid op een WAN-link. Dit is over het algemeen gebaseerd op het verwachte telefoonvolume en de gebruikte audio-codec.

Hoewel de principes hetzelfde zijn, is de videobandbandbreedte via een CUBE niet zo makkelijk te berekenen. Dit is het gevolg van een aantal factoren, waaronder:

• Hoe berekent men de totale vereiste bandbreedte gegeven verschillende vraag van TP (die door CUBE vloeit) zou verschillend aantal schermen en van verschillende resoluties kunnen omvatten?
• De barstende natuur en VBR
• Een andere dimensie van complexiteit [in bandbreedteberekening] heeft te maken met "interoperabiliteitsoproepen"?  Interoperabiliteitsoproepen gebruiken TIP. TIP staat voor TelePresence Interoperability Protocol. TIP wordt gebruikt voor het multiplexen van meerdere schermen, meerdere audio streams, evenals een hulpdatascherm in twee RTP stromen, elk voor video en audio. Het maakt point-to-point sessies en multi-point sessies mogelijk evenals een combinatie van multi-scherm en single-scherm endpoints. TIP is een eigen Cisco-protocol. TIP is gebaseerd op RTCP.

Daarom wordt de bandbreedtevoorziening voor videosystemen soms in de omgekeerde volgorde uitgevoerd - d.w.z. de hoeveelheid bandbreedte die een transportnetwerk kan leveren met het LLQ-beleid eerst bepaald en op basis daarvan wordt het eindpunt gevormd. Endpoint video systemen zijn slim genoeg om de verschillende videoparameters voor de pijpgrootte aan te passen! Dienovereenkomstig, wijzen de eindpunten op de vraag.

CUBE-bandbreedtebehandeling

Dus, hoe behandelt CUBE Bandwidth in zijn (SIP) aanbod/antwoorden wanneer het signaleren van videooproepen? CUBE bevolkt de velden van de videobandbreedte in SDP als volgt:

  1. Van bandbreedte-eigenschap in de inkomende SDP. In SDP, bestaat er een bandbreedte eigenschap, die een bepaling heeft gebruikt om te specificeren naar welk type bit-rate de waarde verwijst.  De eigenschap heeft het volgende formulier: b=<modifier>:<waarde>

  2. Van videobandbreedte ingesteld op CUBE. De geschatte maximale bandbreedte wordt bijvoorbeeld berekend op basis van de functies die door CTS-gebruiker worden gebruikt en de geschatte bandbreedte is vooraf ingesteld op CUBE met behulp van de CLI-F

• <bandbreedte-video-items> of
• <bandbreedte-video as-modifier>

  3. Standaard videoband (384 Kbps)

De Call Flow die hieronder wordt getoond illustreert hoe CUBE bandbreedte in vraag signalerende berichten bevolkt

CUBE gebruikt met name de volgende logica:

• Op aanbiedingen (om vraag te DOEN) gebruikt CUBE de geconfigureerde bandbreedte.
• Op (antwoorden op EO's) stuurt CUBE bandbreedte waarvan de waarde het minimum aanbod en de lokale configuratie is.

Op het niveau van de SDP-sessie is de TIAS-waarde de maximale benodigde bandbreedte wanneer alle opgegeven mediaspelers worden gebruikt[8].

Video-codec payload-typen

Dit is een ander gebied waarin video verschilt van audio.  Audio-codecs gebruiken statische lading-typen. Video codecs daarentegen gebruiken dynamische RTP payload-typen, die het bereik 96 tot 127 gebruiken.

De reden voor het gebruik van dynamisch type lading heeft te maken met de ruime toepasbaarheid van videocodecs. Video codecs hebben parameters die een ontvanger van de eigenschappen van de stroom voorzien die zullen worden verzonden. De type videolading wordt gedefinieerd in SDP, gebruik makend van de a=rtpmap parameter. Daarnaast kan de eigenschap "a=fmtp:" worden gebruikt om parameters voor de indeling te specificeren. De fmtp string is ondoorzichtig en wordt gewoon aan de andere kant doorgegeven.

Hier is een voorbeeld:

m=video 2338 RTP/AVP 97 98 99 100
c=IN IP4 192.168.90.237
b=TIAS:768000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500;packetiza tion-mode=1
a=rtpmap:99 H263-1998/90000
a=fmtp:99 custom=1024,768,4;custom=1024,576,4;custom=800,600,4;cif4=2;custom=720,480,2 ;custom=640,480,2;custom=512,288,1;cif=1;custom=352,240,1;qcif=1;maxbr=7680
a=rtpmap:100 H263/90000
a=fmtp:100 cif=1;qcif=1;maxbr=7680

Merk op dat de twee eindpunten die betrokken zijn bij een oproep een ander type lading voor dezelfde codec kunnen gebruiken. CUBE reageert op elke kant met een a=rtpmap-lijn die op de andere poot wordt ontvangen. Dit betekent dat de configuratie "asymmetrische lading volledig" nodig is voor videooproepen om te werken.

L2-bandbreedte

In tegenstelling tot stem is in real-time IP videoverkeer in het algemeen een ietwat bursty, variabel bitsnelheidsstroom. Daarom heeft video, in tegenstelling tot spraak, geen duidelijke formules voor het berekenen van netwerk overhead omdat de grootte en de tarieven van de videopakketten proportioneel variëren aan de graad van beweging binnen het videobeeld zelf. Vanuit het gezichtspunt van een netwerkbeheerder, wordt de bandbreedte altijd vooraf ingesteld op Layer 2, maar de variabiliteit in de pakketgrootte en de verscheidenheid aan Layer 2 media die de pakketten van end-to-end kunnen verplaatsen maakt het moeilijk om de echte bandbreedte te berekenen die aan Layer 2 moet worden geleverd. De conservatieve regel die grondig is getest en veel gebruikt is echter om videoband met 20% te overdreven. Dit past de 10% burst en het netwerk over van Layer 2 aan Layer 4 aan.

Controle/meting

Zoals eerder genoemde video-endpoints melden een MOS als zodanig niet. De volgende instrumenten kunnen echter worden gebruikt om de prestaties van het transportnetwerk te meten/te controleren en de videokwaliteit te bewaken.

IP SLA’s-video

Een eigenschap ingebed in IOS, IP SLAs (Service Level Agreements) voert de actieve controle van de netwerkprestaties uit. IP SLAs-videobewerking wijkt af van andere IP-SLA-bewerkingen in die zin dat al het verkeer slechts één manier is, met een responder die lokale sequentienummers en tijdzegels moet verwerken en op een verzoek uit de bron moet wachten voordat de berekende gegevens worden teruggestuurd.

De bron stuurt een verzoek naar de responder wanneer de huidige videobewerking wordt uitgevoerd. Een dergelijk verzoek signalen geeft aan dat er niet meer pakketten arriveren en dat de videofunctie met de gootsteen kan worden uitgeschakeld. Wanneer het antwoord van de responder aan de bron komt, worden de statistieken uit het bericht gelezen en worden de relevante velden in de bewerking bijgewerkt.

CiscoWorks IPM (IOS Performance Monitor) gebruikt IP SLA-sonde en MediaTrace[9] om de prestaties en rapporten van gebruikersverkeer te meten.

CUBE VQM

De functie VQM (Video Quality Monitor), beschikbaar in CUBE, is een goed gereedschap om de videokwaliteit tussen twee punten van belang te bewaken. De resultaten worden gepresenteerd als MOS.

Dit is beschikbaar via IOS 15.2(1)T en hoger. Merk op dat VQM DSP-bronnen gebruikt.

Referentie

• http://www.cisco.com/en/US/partner/tech/tk1077/technologies_configuration_example09186a00807ca099.shtml
• http://www.cisco.com/en/US/partner/docs/video/milticomm/h320Bonding.html
• http://www.cisco.com/en/US/docs/solutions/TelePresence_Network_Systems_1.1_DG.pdf
• http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/videodg/qos.html
• http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/videodg/basics.html
• IP-videotelefonie SRND -
• http://www.cisco.com/en/US/tech/tk1077/technologies_configuration_example09186a0080111c1b.shtml
• http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/TP_InterOp_v2.html
• http://www.encoding.com/do_you_have_any_information_on_h.264_levels
• http://www.cisco.com/en/US/partner/tech/tk1077/technologies_configuration_example09186a0080111c1b.shtml
• http://www.watchpointvideo.com/pdf/Measuring%20Video%20Quality%20in%20Videoconferencing%20Systems.pdf
• http://www.broadcastpapers.com/whitepapers/Why_IPTV_is_different_from_IP_data_and_VoIP.pdf?CFID=25762102&CFTOKEN=60dc627518f1a19b-3F4F563D-FC97-8A61-6169D8F641750255
• http://en.wikipedia.org/wiki/Video_compression_picture_types
• http://inst.eecs.berkeley.edu/~ee290t/sp04/lectures/coding_standards.pdf
• http://www.cs.jhu.edu/~yairamir/cs667/Multimedia/compress.gif
• http://www.wireshark.org/lists/wireshark-users/201003/msg00125.html
• http://www.networkworld.com/news/tech/2002/0923tech.html
• http://www.javvin.com/protocolH263.html
• http://www.cisco.com/en/US/docs/ios-xml/ios/ipsla/configuration/12-2se/sla_video.html#GUID-29B155B6-AFC3-4F8B-AC1D-C127C9D797F0

 StartSelectie:0000000199 Eindselectie:000000538