Jitsi

Technische Aspekte

Für die Übertragung von Video-Streams ist sowohl eine gewisse CPU-Leistung als auch Netzwerkbandbreite erforderlich, da das Videomaterial in Echtzeit codiert und übertragen werden muss. Dabei können Videoqualität, Datengröße und CPU-Leistung nicht gleichzeitig optimiert werden. Mit einer besseren Bildqualität wächst automatisch die Dateigröße oder CPU-Auslastung an – in der Regel beides. Ziel ist es daher, eine ausreichend gute Videoqualität bei akzeptabler Dateigröße in Echtzeit zu schaffen, die gut mit der Netzwerkanbindung übertragen werden kann. Der folgende Abschnitt über Videokonferenzsysteme basiert auf 1 2 3 und 4. Die Bilder der Abbildung 1 sind 5 und 6 entnommen.

Sobald mehrere Teilnehmer an einer Videokonferenz teilnehmen, entsteht bei einer Peer-to-Peer Lösung wie in Abbildung 1 das Problem, dass schnell die Bandbreite nicht mehr ausreicht, damit jeder Teilnehmer seinen Video-Stream an alle anderen senden und die Video-Streams von allen anderen Teilnehmern empfangen kann. Um das Problem zu lösen, sind mehrere Technologien entstanden.

Rechnernetze
Rechnernetze

Für den Audio-Stream kann ein zentraler Server die Tonspuren aller Teilnehmer empfangen und daraus wie in Abbildung 2 gezeigt, eine gemeinsame Tonspur erstellen, die an alle Teilnehmer verteilt werden kann. Dies wird in Abbildung 3 dargestellt. Das Mixen von Tonspuren erfordert wenig Ressourcen, sodass dieser Schritt für den Server problemlos durchführbar sein sollte. Dank des zentralen Servers, der die Tonspuren weiter verteilt, braucht ein Teilnehmer seine Tonspur nur noch einmal anstelle von $n-1$ mal zu senden. Durch das Audio-Mixing ist auch das Empfangen von nur noch einer einzigen Tonspur notwendig, was sowohl die Bandbreite der Teilnehmer als auch des Server entlastet.

Audio Mixing
Audio Mixing
Audiokonferenz
Audiokonferenz

So ein Verfahren funktioniert leider nicht für die Video-Spur. Dazu müsste der Server jedes Video in Echtzeit skalieren und alle Videos zu einem einzigen, neuen Video-Stream verarbeiten, welcher dann an alle Teilnehmer verteilt werden würde. Dieser Prozess ist in Abbildung 4 und Abbildung 5 zu sehen und würde zwar die notwendige Bandbreite massiv reduzieren, jedoch wäre ein sehr leistungsstarker Server für die Video-Verarbeitung notwendig.

Video Mixing
Video Mixing
Videokonferenz
Videokonferenz

Stattdessen kann dieses Problem durch mehrere Schritte gelöst werden. Jeder Teilnehmer verarbeitet sein eigenes Video mehrfach, sodass es in unterschiedlichen Qualitätsstufen bzw. Auflösungen vorliegt. Diese unterschiedlich aufgelösten Videos werden mit den beiden Techniken Simulcast und Scalable Video Coding (SVC) kombiniert, sodass ein hocheffizienter Stream mit diversen Auflösungen und unterschiedlichen Bitraten an den Server gesendet wird. Diese Art der Videoverarbeitung wird in Abbildung 6 dargestellt.

Simulcast und Scalable Video Coding
Simulcast und Scalable Video Coding

Der Server braucht dann nur noch jedem Teilnehmer das Video in der notwendigen Qualität ohne Neucodierung weiterzuleiten (Selective Forwarding Unit, SFU), zu sehen in Abbildung 7 und Abbildung 8. Das bedeutet in der Regel, dass jeder Teilnehmer einen oder wenige Video-Streams in hochauflösender Qualität und die restlichen Videos in mäßiger Qualität empfängt, was mit einer moderaten Bandbreite möglich ist.

RTP Relaying
RTP Relaying
Selective Forwarding Unit
Selective Forwarding Unit

Sofern die zur Verfügung stehende Bandbreite trotzdem nicht ausreichend sein sollte, greift eine Technik, die sich Last N Abbildung 9 nennt. Dabei werden vermutlich nicht benötigte Video-Streams automatisch ausgeblendet und somit nicht mehr übertragen. Insbesondere werden dabei die Videos der $N$ letzten, aktiven Sprecher angezeigt, wobei das $N$ automatisch basierend auf der noch verfügbaren Bandbreite angepasst oder als Parameter fest definiert werden kann.

Last N
Last N

Jitsi Meet (kurz Jitsi) ist eine freie, WebRTC-basierte, Open-Source Videokonferenzsoftware, die gleichermaßen Audio- und Video-Konferenzen, Chats und Bildschirmfreigaben nach dem oben beschriebenen Prinzip ermöglicht und außerdem SIP- sowie Broadcast-kompatibel ist.

Die Media-Streams werden dabei via Datagram Transport Layer Security (DTLS) und Secure Real-time Transport Protocol (SRTP) verschlüsselt übertragen. Bei zwei Teilnehmern werden alle Daten sogar Ende-zu-Ende verschlüsselt und sofern möglich, was in durchschnittlich 85% der Fälle der Fall ist, Peer-to-Peer (Abbildung 1) übertragen 1 3. An einer vollständigen Ende-zu-Ende-Verschlüsselung wird derzeit gearbeitet 2 4.

Browser

Empfohlen

Unterstützt

Nicht unterstützt

  1. Saúl Ibarra Corretgé. 2017. Jitsi - Open Source Video Conferencing. Kamailio World. https://www.youtube.com/watch?v=TGloLKOrvmo 2020-04-23. ↩︎

  2. Philipp Hancke. 2020. True End-to-End Encryption with WebRTC Insertable Streams. https://webrtchacks.com/true-end-to-end-encryption-with-webrtc-insertable-streams/ 2020-04-23. ↩︎

  3. Emil Ivov. 2013. jitsi.org - advanced real-time communication. https://www.youtube.com/watch?v=5D_VbhkKIPM 2020-04-23. ↩︎

  4. Emil Ivov. 2020. This is what end-to-end encryption should look like! https://jitsi.org/blog/e2ee/ 2020-04-23. ↩︎

  5. Mauro Bieg. 12. August 2007. https://en.wikipedia.org/wiki/File:Server-based-network.svg 2020-09-24. ↩︎

  6. Mauro Bieg. 12. August 2007. https://commons.wikimedia.org/wiki/File:P2P-network.svg 2020-09-24. ↩︎

Zurück

Zuletzt aktualisiert am 04 Feb. 2021