Video-Codec

Auf der Seite Codec habe ich schon einiges über die verschiedenen Kompressionsverfahren zur Audioübertragung geschrieben. Diese Seite beschreibt die Grundlagen der Video-Übertragung mit Lync. Video benötigt im Gegensatz zu Audio in der Regel schon mehr Bandbreite aber andererseits ist unser Auge viel "toleranter" was den ein oder anderen Artefakt betrifft als unser Ohr. Menschen können relativ gut hören aber beim "Sehen" von bewegten Bildern sind wir nicht sehr anspruchsvoll.

Video Bilder im RAW Format

Die Übertragen von bewegten Bilder begann mit der Verbreitung des "Fernsehens", welches aber anfangs noch gar nicht digital war. Analoge Systeme wir PAL, NTSC und SECAM übertrugen Bilder "zeilenweise". Da die Bandbreite bei analogen Verfahren begrenz waren, wurden die Bilder sogar im Halbbild-Verfahren übertragen, d.h. es wurden erst alle ungeraden Zeilen aufgebaut und dann alle geraden. Damit konnte das Bild 24/25 mal/Sek aufgebaut werden, obwohl immer nur ein "Halbbild" erneuert wurde und letztlich das Bild "Flimmerfrei" erschien. Bei PAL wurden 576 oder 625 Zeilen genutzt. Durch die Analogtechnik gab es aber keine echten "Pixel" sondern eben analoge Signale. Mit der Einführung digitaler Speicherverfahren musste eine Abtastung festgelegt werden, so dass basierend auf den maximal möglichen Frequenzen 520 oder 437 Pixel horizontal angesetzt wurden. Ein Fernsehbild hat als z.B. 625x437 Pixel. Anfangs war Fernsehen aber nur Schwarz Weiß. Erst später wurde Farbe addiert. Dies musste aber so erfolgen, dass die S/W-Geräte nicht gestört wurden. Diese ära lassen wir nun aber hinter uns, da heute fast alles Digital ist.

Digital bedeutet, dass die Bilder gleich als "Pixel" abgetastet werden. Während ein Fotoapparat nur ein Bild pro Auslösung erfasst, nimmt ein Videokamera-Sensor je nach Bildwiederholrate und manchmal in Zeitraffer sehr viel häufiger Bilder auf. Diese Bilder müssen natürlich gespeichert werden. Gehen wir mal nun von einem VGA-Bild einer Konferenz aus, welches mit 640x480 Pixel aufgenommen wird.

Als binäres Schwarz Weiß-Bild wären dies 307200 Pixel oder 38400 Bytes. Aber selbst Schwarz/Weiß-Bilder haben ja Helligkeitsunterschiede und wenn sie dazu 8bit /Pixel annehmen, ist so ein Bild dann doch wieder 307 Kilobyte groß. Kommen nun Farben dazu, dann könnten Sie nun natürlich z.B. 8bit/Farbe annehmen (RGB=Rot Grün Blau), so dass aus dem Bild dann sogar 921Kbyte nicht komprimiert werden. Wenn Sie nun 30 Bilder/Sek übertragen wollen, dann sprechen wir von 27,6 Megabyte/Sek oder 300 Megabit/Sek. So kann das also nicht funktionieren.

Anforderungen an einen Video-Codec

Ich möchte an dieser Stelle nicht in die verschiedenen Algorithmen zur Kompression von Video-Daten eingehen aber auf etwas abstrakterem Level zeige ich ihnen, wie die Video-Codecs arbeiten. Dabei muss ein Codec mehrere Ziele unter einen Hut bringen 

  • Datenreduktion
    Zuerst muss der Codec natürlich dafür sorgen, aus den Megabit/Sek eine akzeptable Datenrate zu zaubern. Das geht nur durch Kompression und Weglassen.
  • Datenverluste
    Dann sollte der Codec damit umgehen können, dass ein Teil der Pakete durch Engpässe auf dem Übertragungskabel verloren geht. "Zu Spät Angekommen" ist mit Verloren gleich zu setzen
  • Bandbreitenanpassung
    Wenn der RTP-Stack meldet, dass zu viele Packet verloren gehen, dann sollte der Codec seine Datenraten weiter reduzieren können, z.B. in dem er weniger "Bilder/Sek" sendet oder die Auflösung oder Farbtiefe anpasst.
  • Zeitverzug
    Das Analysieren der Eingangsdaten und das Komprimieren zum Versand kosten Zeit. Der Videostrom wird also zwangsläufig "verzögert". Sie können dies wunderbar beobachten, wenn Sie z.B. eine Fußballübertragung im Radio hören und parallel das Bild betrachten. Wobei oft das Bild noch ein paar Umwege (über den Satellit) geht. Bei Video-Konferenzen ist es aber auch wichtig, diese Verzögerung gering zu halten um Aktionen auf dem Bild den Teilnehmern auch zu zeigen. Passend dazu muss in der Regel der Ton nämlich künstlich verzögert werden um synchron mit dem Bild abgespielt zu werden. Würden hier aber z.B. 1-2 Sekunden insgesamt verloren gehen, dann wäre das "Erlebnis Videokonferenz" ehr eingeschränkt.
  • Ressourcensparen beim Wiedergeben
    Aus der TV-Ecke kommt der Bedarf, dass die Kompression beim Aufzeichnen durchaus etwas mehr CPU-Takte brauchen darf, wenn dadurch bei der Wiedergabe der Rechenaufwand gering bleibt. So können Abspielgeräte "billiger" gebaut werden.

Es gibt eine ganze Menge von Codecs, die leicht unterschiedliche Verfahren zur Kompression und Reduktion anwenden. Vergleichen Sie dies z.B.: mit den verlustfreien Kompressionsalgorithmen wie ZIP, ARJ und anderen und ihren Varianten. Bei Bildern und Tönen hingegen ist es gar nicht erforderlich, dass die Daten "Verlustfrei" übertragen werden. Eine grüne Wiese muss nicht aus tausend verschiedenen Grüntönen zusammengesetzt werden. Benachbarte Pixel mit sehr ähnlichen Farben lassen sich als Gruppe zusammenfassen. Auch kommen in den meisten Bildern nicht alle 16Mio Farben (3x 8Bit) zum Einsatz. Über Paletten können die Farben effektiver codiert werden. Und so langsam können Sie erkennen, dass JPEG als Bild-Format auch bei Video zum Tragen kommen.

Kompression durch Reduzierung

Ein klassisches VGA-Bild, welches mit 640x480x16Mio erfasst wird, kann als JPEG-Bild durchaus wenige Kilobyte groß sein. Hier habe ich mit meiner einfachen WebCam ein 640x480x16Mio-Bild gemacht. Dieses Bild habe ich dann unterschiedlich komprimiert und einen Ausschnitt vergrößert.

Hinweis, auch dieses Bild ist schon als JPG komprimiert, da die meisten Browser kein BMP anzeigen.

videocodec-vga.zip
BMP-Bild original 900k

Dieses Bild habe ich dann ausschnittsweise vergrößert und mit den unterschiedlichen JPG-Qualitätsstufen gespeichert. JPEG reduziert die Datenmenge indem z.B. gleiche Pixel zusammengefasst und damit kürzer codiert werden. Das ist natürlich eine sehr vereinfachte Aussage und JPEG kann dabei sogar Informationen reduzieren (Lossy), was ein Packalgorithmus für Programme und Daten wie JHA, ZIP, ARJ natürlich nicht darf.

Für uns sind aber hier nur die Größen und die Qualität ausschlaggebend.

JPEG Qualität 100 90 75 50 25
Größe in KB

900k

34k

18k

14k

12,5k

Bildausschnitt

Bildausschnitt 2fach

Es ist recht gut zu erkennen, dann aus den 900k "RAW-Format" mit ganz wenig Qualitätseinbußen (90%) das Bild auf 34kByte eingedampft wird und wer selbst 75% nutzt, spart noch mal fast die Hälfte. Die Artefakte werden zwar in der 2-fachen Vergrößerung schon sichtbar aber dies ist auch ein "Standbild". Bei einem Film fällt dies noch weniger auf. Wird die Qualität aber noch weiter reduziert, dann spart man nur noch ein paar Kilobyte auf Kosten einer deutlich sichtbaren Verschlechterung. Da ist es dann auf jeden Fall besser die Bildrate oder Auflösung zu reduzieren.

Kompression durch Differenzen

Wenn wir nun aber ein VGA-Bild mit 18Kbyte/Frame bei 30 Bildern/Sek übertragen, dann sind dass immer noch 540Kbyte/Sek oder 5 Megabit/Sek. Das ist zwar schon weniger aber noch nicht genug. Denken Sie einmal eine DVD, auf der 2 Stunden Film in HD-Format abgelegt sind. Der nächste Kniff besteht darin sich die Tatsache zu nutzen zu machen, dass bei einem Film sich von einem Bild zum anderen Bild immer nur wenige ändert. Warum sollte jedes mal ein komplettes Bild übertragen werden. Der Algorithmus subtrahiert einfach das neue Bild vom alten Bild und überträgt dann nur die Differenzen. Das bringt schon sehr viel. Betrachten Sie einfach das klassische Bild. Bei einer Videokonferenz bewegt sich überwiegend der Mund. Große Anteile des Bildes sind idealerweise "statisch. Wenn Sie mein Videobild anschauen, dann habe ich die statischen Bereiche einmal lila eingefärbt:

Bei einer normalen Konferenz bewegt sich mein Kopf hin und her und natürlich der Mund und die Augen. Dennoch sind mehr als 60% des Bildes in dieser Situation unveränderlich. Vielleicht können Sie aber auch nun ermessen wie wichtig es ist, dass z.B.: die Kamera "fest" montiert ist und nicht durch Wackeln das ganz Bild sich verändert und dass im Hintergrund auch sonst "Ruhe" herrscht. Fenster, bei denen außen ein Baum wippt oder Vorgänge wedeln ist ebenso ungünstig wie gemusterte Hintergründe, bei denen schon kleinste Veränderungen von der Kamera als PixelÄnderung erfasst werden.

Kompression durch Vektorisierung

Womit wir bei der dritten Komponente der Datenreduktion sind. Die Bereiche, die sich "bewegen" haben oft die Eigenschaft, dass sie sich auch nicht komplett verändern sondern eben "verschieben". Wenn ein Objekt sich im Bild hin und her bewegt, kann ein Algorithmus durchaus eine Gruppe von Pixel auch als zusammenhängendes Objekt erfassen. Und dann kommt der Moment, in der nicht mehr z.B. ein Bereich von 32x32 Pixel neu übertragen wird, sondern nur noch der Bereich aus dem vorherigen Bild einfach "verschoben" wird.

Weitere Tricks

Übrigens gibt es noch andere Tricks. Ein Bild besteht nicht nur aus den drei Grundfarben Rot Grün und Blau. Sie können auch die "Helligkeit" als Beschreibung mit einbeziehen. Der Trick dabei ist, dass man z.B.: die Helligkeit und die beiden Farben Grün und Rot überträgt. Der Empfänger kann aus der Differenz (Blau = Helligkeit - Grün -Rot) die Farbe blau selbst ermitteln. Der Mensch ist aber bei "Blau" ziemlich unempfindlich das die Farbe blau betrifft. Aber wenn die Daten der drei Kanäle nun unterschiedlich gewichtet werden, kann ein Empfänger z.B.: immer noch ein gutes Graustufenbild anzeigen, anstatt ein Standbild zu haben. Dieses Verfahren kommt bei Lync aber meines Wissens nicht zum Einsatz.

Optimierte Übertragung

Nun wissen Sie, wie die Datenmenge durch Kompression, Reduzierung, Differenzierung und Vektorisierung stark verkleinert werden kann. Es wäre nun aber natürlich komplett kontraproduktiv, wenn am Anfang eines Videos ein Startbit übertragen wird und dann in der Folge nur noch die Differenzen. Ein so aufgebauter Videostrom würde schnell aus dem Tritt geraten, wenn ein Paket verloren geht. Im Bereich von DVD-Wiedergaben wäre das Vor/Zurück-Spulen oder der Sprung an eine bestimmte Stelle nicht möglich. Daher werden immer wieder mal "Vollbilder" eingespielt, an die dann gesprungen werden kann.

Genau diese Umsetzung können Sie auch bei der Wiedergabe von den meisten Videos beobachten: Sie können zwar Spulen aber sie können nicht jedes einzelne Bild anspringen, sondern immer nur die "Index"-Frames (I-Frame). Bei MPEG sieht die Bildabfolge noch etwas komplizierter aus:

Sie sehen hier drei "Frames", ein viertes Frame beschreibe ich nur.

  • I-Frame (ca. 15 Kilobyte bei 640x480)
    Dies ist immer ein Vollbild und unabhängig von anderen Bildern. Es kennzeichnet auch den Beginn eines "Group of Pictures (GOP)"
  • P-Frame (ca. 8 Kilobyte bei 640x480)
    Das "Predictive-Frame" ist ein regelmäßig zwischen den I-Frames vorhandenes Frame. Das P-Frame enthält die Änderungen basierend auf dem I-Frame und den dazwischen liegenden P-Frames. Wer also vorspult, kann das I-Frame anzeigen und dann auch schnell die P-Frames abarbeiten. Beim Zurückspulen muss ein Client aber immer wieder zu den vorherigen I-Frame springen und dann wieder nach vorne rechnen.
  • B-Frame (ca. 3 Kilobyte bei 640x480)
    Diese "Bidirektionalen Frames" verweisen auf das vorherige und nach nachfolgende Frame und enthält meist Vektor-Operationen. Da solche Vektoren relativ ungenau sind uns nur kleine Änderungen abdecken, werden Sie nur wenige Bilder genutzt, ehe das Bild wieder anhand eines P-Frame neu aufgebaut wird. Aber Sie sind ausreichend um bei 25-30 Frames/Sek eben ein paar Frames zu füllen.
  • SP-Frame
    Im Bild nicht sichtbar sind die "Super-P-Frames" die Microsoft in RTVideo eingebaut hat und einmal pro Sekunde gesendet wurden. Sie basieren auf dem vorherigen I-Frame und sollten den Verlust von P-Frames abschwächen.

In diesem Beispiel umfasst die "Group of Picture", welches mit einem I-Frame beginnt, und alle drei Bilder ein P-Frame kommt insgesamt 15 Bilder. Ein Filme mit 30 Bilder/Sek hat also 2 GOPs/Sekunde und sie können quasi ein 0,5 Sekunden Schritten springen. Das ist für DVDs mit ihrem Speicherplatz optimal aber die I-Frames benötigen doch merklich Platz. Bei Video-Konferenzen gibt es kein "Vor/Zurück-Springen". Daher kann hier ein Codec mit weniger I-Frames hantieren und mehr P-Frames  und alles ist "live". Aber sie können nun leichter ermessen, warum sie bei digitalen Aufnahmen nicht immer "Einzelbildweise" springen können.

Server/Client Codec Frames/Sec I-Frame/SP-Frame Frameabfolge
OCS

CIFS

15

10Sek / 1Sek

IBPBPBPBPBPBPBSP

Lync

CIFS

15

Conf: 3Sek / 1Sek
P2P:  4Sek / 1Sek

IBPBPBPBPBPBPBPBPBPBPBPBPBPBPSP

Lync

VGA/HD

30

Conf: 3Sek / 1Sek
P2P:  4Sek / 1Sek

IBPBPBPBPBPBPBPBPBPBPBPBPBPBPSP

Wenn Sie sich ganz genau ein Video ansehen, dann können Sie teilweise sogar erkennen, dass das Bild alle 3 oder 4 Sekunden ausgetauscht wird.

Verlust und Recovery

Abhängig von der Codierung können Sie nun überlegen, welche Auswirkung der Verlust eines Frames hat.

  • I-Frame Verlust
    Im schlimmsten Fall geht ein I-Frame verloren. Dann ist das ganze GOP nicht mehr nutzbar, da der Startpunkt fehlt. Ein I-Frame ist mit ca. 15Kbyte (VGA) aber zu groß, um in einem IP-Paket übertragen zu werden. Daher fehlt nur ein Teil und um dies zu "retten" wird das I-Frame durch Prüfsummen erweitert. Es werden also nicht 12 Pakete a 1250 Byte Nutzlast gesendet sondern ein paar mehr, so dass ein Verlust eines Pakets das Bild nicht unbrauchbar macht. Sollte es aber dennoch nicht komplett sein, dann gibt es Artefakte oder im schlimmsten Fall das letzte Bild als "Standbild" zu sehen.
  • P-Frame-Verlust
    Zwischen den 3/4-Sekunden Abständen der I-Frames ist jedes zweite Frame ein P-Frame, die aufeinander aufbauen, bis das nächste I-Frame oder ein SP-Frame kommt. Im schlimmsten Fall kommt erst nach 1 Sek das nächte SP-Frame um das Bild basierend auf dem I-Frame wieder herzustellen. Artefakte sind also sichtbar
  • B-Frame-Verlust
    Diese kleinen Frame machen das Bild flüssiger und wenn eines fehlt, dann fehlt ein einzelnes Frame. Bei VGA/HD also 1/30tel Bild. Das vorherige Bild wird einfach noch weiter angezeigt. Nur sehr geübte Betrachter erkennen dies und auch nur, wenn es genug "Bewegung" gibt, die dann etwas mehr "ruckt"

Nun wissen Sie aber, dass im RTP-Datenstrom eines Video drei/vier Frames in regelmäßigen Abständen auftauchen und diese können selbst bei verschlüsselten Verbindungen über die Größe und Häufung ermittelt werden.

Der richtige Codec

Die Beschreibung von I/P/B/SP-Frames lässt aber noch keine Aussage über den verwendeten Codec zu. Im RTP-Protokoll gibt es aber ein Feld, welches in 7 Bit den Codec definiert. Nun sind 7 Bit nicht gerade viel (127 Optionen). Von diesen sind zudem viele schon für Audio-Codecs vergeben:

Aber damit sind zumindest die Audio-Codecs für die Clients halbwegs "fest". für die Übertragung von Videos ist aber ein Blick in den decodierten SDP-Datensatz des INVITE erforderlich. Dort werden unter "m=video" die verschiedenen Codecs aufgeführt:

In dem Beispiel bietet der Clients die Codecs 122 121 und 123 an, die weiter unten dann auch auf einen "String" gemappt werden. Sie können auch gut sehen, dass beim Codec 121 auch jede Menge Auflösungen mit angeboten werden, die Microsoft Lync bei RTVC1 unterstützt. Entsprechend können wir mit Netmon oder Wireshark filtern.

  • Wireshark

    rtp.p_type ==121 || rtp.p_type ==122 || rtp.p_type ==123
  • NetMon

    rtp.PayloadType==121 || rtp.PayloadType==122 || rtp.PayloadType==123

Bei Lync 2013 reicht es in der Regel nach 122 (H264uc) zu suchen.
Bei Lync 2010 ist 121 meist verwendet.
Das hängt aber auch immer etwas von den Teilnehmern ab und manchmal (mit einem Roundtable) haben sie sogar mehrere Streams.

Frames auf dem Kabel (RFC1889)

Um auf eine Analyse der Pakete auf dem Kabel einzugehen, sollten Sie sich erst noch einmal aus dem oberen Bild die logische Abfolge der Pakete beim Sender in Erinnerung rufen:

Die Videoübertragung startet mit einem I-Frame, welches aber zu groß für ein einzelnes Paket ist. Daher wird es in mehreren Paketen versendet. Danach kommt ein B-Frame, welches vielleicht ein oder zwei Pakete passt. Das P-Frame dürfte aber wieder zu groß sein, um ein einem Paket gesendet zu werden. Also werden es mehrere Pakete sein. Die Nutzdaten werden in einem RTP/SRTP-Paket eingepackt versendet. Auch das RTP/SRTP-Paketformat ist in einer RFC definiert:

Das Paket ist in etwas wie folgt aufgebaut:

Hinweis
Die Bedeutung des himmelblauen Bereichs ist vom Codec abhängig. Die hier beschriebenen Felder gelten für Lync 2010 mit RT-Video. Lync 2013 nutzt aber H.264SVC und die Felder haben dort eine andere Bedeutung.

Interessant ist dabei das obere M, welches ein "MARK" darstellt und immer dann auf "1" geht, wenn es das letzte Paket einer Serie ist. Wenn ich mir dann wieder die Abfolge der Pakete auf dem Sender anschaue, dann müssten folgende Pakete ein "Mark" haben:

Welche "Nutzlast" übertragen wird, ist durch die 7 Bits des Payload (PT)-Felds vorgegeben. Da zwischen Sender und Empfänger ein "unzuverlässiges" Netzwerk die Reihenfolge der Pakete verwürfeln kann und zwischen zwei Stationen durchaus mehrere "Streams" übertragen werden können, gibt es das Feld "timestamp" und den SSRC als eindeutige Identifikation der Quelle. Erst dann kommen ein paar weitere Felder, die zusätzliche Informationen liefern:

Flag Bedeutung wenn = 1
M

Immer 1

C

Dieses Frame zeigt dem Empfänger an, das es das Paket im Cache halten soll. Es werden vermutlich B/P-Frames folgen

SP

Dies ist ein SuperFrame

L

Zeigt letztes Paket eines Videoframe an

O

Muss immer 1 sein

I

Dies ist ein I-Frame, Ansonsten ist es ein SP, P oder B-Frame

S

Sequence Header ist vorhanden

F

Erstes Paket eines VideoFrame

Interessant ist hier noch das "F"-Flag, welches den Start eines Videoframe und das L-Bit für das Ende eines Video-Frame sein. Auch das C-Bit sollten wir finden können. Die Kennzeichnung der Pakete auf dem LAN können wir also noch etwas genauer beschreiben.

Mit dieser Vorarbeit können sie nun also einen Videostream zwischen z.B.: zwei Clients mitschneiden und sich die Pakete genauer anschauen. Sobald SRTP zum Einsatz kommt, was bei Lync der Standard ist, können Sie natürlich nicht mehr die Nutzdaten so einfache sehen und selbst ohne Verschlüsselung können weder Wireshark noch NetMon aus den Videodaten wieder Bilder machen. Maximal die I-Frames sind "JPG-Bilder" und könnte man vielleicht noch extrahieren. Es bleibt also rein eine "quantitative" Betrachtung der Daten.

Hier ein Mitschnitt einer Richtung eines Lync 2013 Clients zu einem Lync 2013 Windows 8.1 App-Client. Sie sehen gut, dass es nur einen "SSRC=2964642783" als Sender gibt, der aber hier zwei Sequenzen hat, die ich durch rote und blaue umrandungen gekennzeichnet haben.

Schon diese grobe Betrachtung zeigt ein paar interessante Daten:

  • 0,37 Sekunden Dauer (7.1851380 - 7.5574290)
    Alle Pakete sind in weniger als einer halben Sekunden versendet worden. Sie können also schon sehen, dass Video nicht nur Bandbreite sondern auch sehr viele Pakete versendet
  • Ein ganz großes I-Frame startet den Stream
    Addiert man die RTP-Payload-Bytes zusammen, kommt man auf 19511 Bytes, was einem VGA-Bild entsprechen dürfte
  • Kleine B-Frames und mittlere P-Frames wechseln sich ab
    Es ist gut zu sehen, dass es dann vermutlich mit einem B-Frame weiter geht (3 Pakete mit 2290Bytes), welches von einem größeren P-Frame (10 Pakete mit 8552 Bytes gefolgt wird. Dies wechselt sich immer ab. Nicht alle P und B-Frames sind gleich groß.

Leider kann aktuell weder Netmon noch Wireshark die Felder decodieren, wenn der RTP-Payload = 122 ist. Selbst der Lync Network Monitor Parser kommt hier nicht weiter.

Lync Network Monitor Parsers
http://www.microsoft.com/en-us/download/details.aspx?id=22440

Denken Sie daran, dass Sie den neuen Parser noch aktivieren müssen.

Allerdings ist es auch nicht wirklich erforderlich so tief den Bits nachzuforschen. Das ist eher etwas für Programmierer, die selbst einen RTP-Stack oder Codec bauen und die Ausgaben ihrer Programme überprüfen wollen.

MCU - Mixen oder Switchen ?

Kommen wir zuletzt zur Konferenz. Die Übertragung von Video zwischen zwei Endpunkten ist relativ einfach, da es eine Punkt zu Punkt-Verbindung ist. für eine Konferenz ist dies aber nicht ausreichend. Sobald drei oder mehr Parteien in einer Konferenz zusammen geschaltet sind, muss das Bild einen Umweg über eine MCU gehen. Ich kenne kein ernst zu nehmendes Produkt, welches einer 3er Konferenz nur über die Endpunkte durchführt. Jeder Endpunkt müsste dann zu jedem anderen Teilnehmer sein Video senden und empfangen und jeder weitere Teilnehmer würde die Volumen exponentiell anwachsen lassen. Selbst wenn das Netzwerk dies könnte dürften viele Clients damit überfordert sein. Wenn dann noch unterschiedliche Auflösungen dazu kommen, ist dies nicht zu schaffen.

Daher senden in einer Konferenz alle Teilnehmer ihr Bild und ihren Ton an eine zentrale Konferenzeinheit, die die Bilder annimmt und wieder an die Teilnehmer weiter verteilt. Hierbei gibt es zwei grundlegende Verfahren:

  • Switchen
    Eine Switching MCU macht nichts anderes als die Daten eines Clients an die anderen Clients weiter zu senden ohne am Codec was zu ändern. Dies war bis Lync 2010 Standard mit der Folge, dass es einen "Active Speaker" gab, d.h. die MCU hat bestimmt, welcher Konferenzteilnehmer "aktiv" ist, hat von diesem das Bild angefordert und an alle anderen Teilnehmer verteilt.
    Lync 2013 ist weiterhin ein "Switcher" aber kann nun mehrere Videostreams von verschiedenen Clients anfordern und verteilen. Allerdings senden hier dann die Clients neben einem großen Bild auch ein "kleines Bild" mit, welches in der Gallery angezeigt wird.
  • Mixen
    Große Konferenzsysteme können aber auch "Mixen", d.h. Sie empfangen die Videodaten der Teilnehmer, nehmen Sie dann auseinander, setzen z.B. aus vier Einzelstreams ein neues 4/4tel-Bild zusammen, codieren dies neu und verteilen dies. Diese Aufgabe ist allerdings sehr CPU-Intensiv und funktioniert daher nur mit entsprechender Hardware, die entsprechend teuer ist.

Selbst heute ist die Codierung eines HD-720p Videostroms für einen normalen PC eine durchaus anspruchsvolle Aufgabe. Schon Lync 2010 Clients haben HD nur gesendet, wenn die Empfängerseite das Bild wirklich in 1920x1080 angezeigt hat und der Sender eine Quadcore-CPU hatte. Heute sind CPUs zwar schneller und diverse Videokameras übernehmen schon die Codierung in H.264 aber für die Lync-MCU bleibt es dennoch beim Switching.

Video-Codecs

Die meisten Codec übertragen zu bestimmten Zeiten, z.B. alle 10 Sekunden (H.264) oder 3 bzw. 4 Sekunden (RTVideo) ein komplettes Bild und füllen die Zwischenräume mit unterschiedlichen "Differenzbildern" auf. Kommen diese "I-Frames" nicht an, dann bemerken Sie dies an einem "Rucken" des Bilds. Auch das Vor-und Zurück-Spulen eines solchen Films (DVDs und HDTV codieren ähnlich) kann dann immer erst wieder an so einem I-Frame aufsetzen.

Diese I-Frames sind natürlich "Groß", so dass Sie nicht in ein einzelnes Ethernet-Paket (151kbyte) passen. Ein normales VGA Bild mit 640x480 Pixel hat schon mal ein paar KB, so dass daraus meist um die 10 Ethernet-Pakete werden. Wer also nur 1% der Pakete auf der Leitung verliert, verliert im Schnitt 10% dieser "Vollbilder". Ohne Fehlersicherung würde das Video also immer mal wieder "hängen" bleiben. Daher sendet z.B. RTVIDEO zusätzliche Pakete, um den Verlust zu kompensieren. Wenn jemand 10 Pakete sendet und ein 11tes Paket die Prüfsummer (wie bei einem RAID) enthält, dann kann ein Verlust eines Pakets heraus gerechnet werden.

Auch der Endpunkt ist zu betrachten. Selbst die Komprimierung von 640x480 Videobildern mit 30 fps erfordert schon einen Dual-Core, wenn man daneben noch etwas anderes machen will. Bei HD, was bei Videokonferenzen meist nur 720p (1280x720) anstelle von 1080 (1920x1080) bedeutet, kann auch einen Quad-Core schon gut auslasten.

Die erforderliche Bitrate ist auch hier wieder Abhängig von den "Änderungen " auf dem Bild und wie der Codec damit umgeht, z.B. indem er Informationen weglässt (unscharf) oder die Bitrate erhöht. Auch ist die Auflösung nicht an einen Codec gebunden.

Codec Format
xx/y/fps
Bandbreite (Max ohne FEC) Einsatzzweck

RTVideo QCIF

176x144

 

Es gibt Konferenzsysteme, die die Bilder mehrerer Teilnehmer in ein neues Bild zusammensetzen. Da das resultierende Bild dann mehrere Kacheln mit weniger Auflösung je Bild hat. Dann reicht es vielleicht, wenn die Teilnehmer alle nur ein "Viertel-CIF" senden. Das Format ist interessanterweise auch auf die Auflösung früherer kleiner Handy-Displays. Aber ich habe schon lange nicht mehr gesehen, dass es eingesetzt wurde.

RTVideo CIF

352x288

260kbs

Der Standardcodec für Videos im CIFS-Format. Auch wenn die Anzahl der Pixel lächerlich wenige erscheint, so reicht dies für einfache Meetings schon aus.

RTVvdeo VGA

640x480/30fps

600kbs

Wer mehr braucht, kann einfach zu VGA schalten. Dies machen die Clients aber nur, wenn Sie das Fenster auch entsprechend "groß" ziehen und in einer Konferenz genug Personen dies anfordern.
Beachten Sie, dass aber auch ein DSL6000-Anschluss nur 576kByte upstream bereit stellt.

RTVideo HD

1280x720/30fps

1500kbs

Die 720p-Auflösung erfolgt nur, wenn der sendende Client einen Quadcore hat und der Empfänger auch das Fenster entsprechend "groß" gemacht hat. Der Bandbreitenbedarf ist aber zumindest beim Sender nicht zu unterschätzen und oft immer noch mehr als DSL-Anschlüsse hergeben.
Erst DSL 16000 kann wohl bis zu 3,5 MBit als upload liefern.

PANO

1056x144 (22:3) 15fps

350kbit

Besonderes Format, welches beim Einsatz der Roundtable zum Einsatz kommt und dann als zusätzlicher Datenstrom gesendet und verteilt wird

H.263

 

 

Diesen Codec hat der Lync Client noch mit an Bord. primär als Rückwärtskompatibilität zu anderen Clients.
http://en.wikipedia.org/wiki/H.263

H.264

 

 

Lizenzpflichtig und nicht von Lync genutzt

Bei Konferenzen beschränkt sich OCS und Lync aber darauf, die Daten des aktiven Sprechers (anhand der Audioinformation) anzufordern und an alle Teilnehmer zu verteilen. Die MCU ist hierbei also kein Mixer sondern ein Switch. Über das Steuerprotokoll RTCP werden die Clients angewiesen, ihr Bild zu senden oder eben auch nicht. Kleine Information am Rande: OCS/Lync bekommt auch das Bild des "vorherigen" Sprechers und sendet dieses an den aktiven Sprecher. Das ist nicht jedem Teilnehmer bekannt aber so hat der aktive Sprecher nicht sich selbst im Bild bekommt zumindest ein einer Person ein Feedback.

Zu dem Thema Codec könne man noch viel mehr schreiben und erläutern und auf all die Feinheiten und Kniffe, die z.B. Microsoft in seinen RTVideo eingebaut hat, kann ich hier nicht eingehen.

Alle Konferenzen beginnen übrigens erst mal mit "CIFS. Über das RTCP-Protokoll melden die Clients auch, welches Videoformat sie gerne hätten. Anhand einer Formel entscheidet dann die MCU, ob z.B. VGA angefordert und dann auch verteilt werden soll.

H.264 SVC

Die MCU von Skype for Business und früher haben noch nie Video-Streams transcodiert sondern immer nur geswitched. H.264 SVC .ist dahingehend ein sehr interessanter Codec, da er mehrere Streams kombiniert.

  • 1:1 Verbindung
    Wenn ich ein HD-Bild sendet aber die Gegenseite nur SD anzeigt, dann verschwende ich Bandbreite. Bei einer 1:1 Verbindung kann mit die Gegenseite aber sagen, was sie kann und ich kann meine Qualität anpassen.
  • 1:n Konferenz
    Wenn mein Bild von mehreren Teilnehmer einer Konferenz in unterschiedlichen Auflösungen gesehen wird, dann muss ich entweder die verschiedenen Auflösungen senden oder die MCU rechnet die kleineren Bilder um. Das ist sehr "teuer" für die MCU-Betreiber

Mit H.264 SVC sende ich z.B. drei eigene Streams. Die Bandbreite hängt davon ab, ob es ein relativ "ruhiges" Bild oder ein stark veränderliches Bild ist.

Stream Zielauflösung Mio Pixel Bandbreite kbit/Sek Beschreibung

360p

480×360

0,26

500-1000

Das Basisbild kann ein einfaches SD-Video sein, welches in der Qualität etwas dem analogen alten Fernsehbild (768 x 576) entspricht.

720p delta

1280x720

1

1500-4000

Dieser Stream ist nun aber kein voller 720p Stream sondern wertet das 360p-Bild durch zusätzliche Pixel und mehr Bildern auf

1080p delta

1920×1080

2

2500-6000

Der letzte Stream ergänzt dann die Zwischenbilder und Pixel, damit der Empfänger ein volles 1080p-Bild anzeigen kann

Dieser Codec bedeutet natürlich erst einmal mehr Arbeit für den den Sender aber erlaubt sich nicht nur dynamisch an die verfügbare Bandbreite beim Sender und den Empfängern anzupassen sondern die MCU muss nichts umcodieren und kann jedem Empfänger nur die Streams senden, die dieser auch unter Berücksichtigung seiner Bandbreite und Bildschirmtechnik verarbeiten kann.

Live Video Communications: Video Coding Using SVC
https://www.youtube.com/watch?v=B6ukW3P8fE0
Was Vidyo hier beschreibt ist mittlerweile aber schon Standard

Weitere Links