GNU ccRTP ist eine Implementierung des RTP, die Echtzeit-Transportprotokoll von der IETF (siehe RFC 3550, RFC 3551 und RFC 3555). ccRTP ist eine C ++ Bibliothek basierend auf GNU Common C ++, die eine leistungsfähige, flexible und erweiterbare Standard-konformen RTP-Stack mit Voll RTCP-Unterstützung bietet. Die Konzeption und Umsetzung von ccRTP machen es für Hochleistungs-Server und Gateways sowie persönliche Client-Anwendungen geeignet.
Bei der Gestaltung ccRTP haben wir berücksichtigt, dass RTP hat als Anwendung Level-Protokoll Rahmen statt eines typischen Internet-Transportprotokoll wie TCP und UDP definiert. So RTP wird kaum jemals als eine Schicht von der Anwendung getrennt implementiert.
Folglich RTP-Anwendungen müssen oft die anpassungs RTP-Paket-Layout und Verarbeitungsregeln anzupassen, Zeitbeschränkungen, Sitzungsmitgliedschaftsregeln sowie andere RTP und RTCP-Mechanismen. ccRTP zielt darauf ab, einen Rahmen für die RTP-Rahmen zu schaffen, anstatt nur ein RTP-Paket Manipulation Bibliothek.
Unterstützung von Audio- und Videodaten ist auch bei der Gestaltung von ccRTP berücksichtigt, dass tun können Teilrahmen teilt / Wiedermontage. Unicast, Multi-Unicast- und Multicast-Transport-Modelle werden unterstützt, sowie mehrere aktive Synchronisationsquellen, mehrere RTP-Sessions (SSRC Leerzeichen), und mehrere RTP-Anwendungen (CNAME Leerzeichen). Dies ermöglicht es verwenden, für den Aufbau aller Formen von Internet-Standards Audio- und Videokonferenzsystemen.
GNU ccRTP ist threadsicher und hohe Leistung. Es nutzt Paketwarteschlange Listen für den Empfang und die Übertragung von Datenpaketen. Sowohl inter-Medien und intra-Mediensynchronisierung wird automatisch in den ein- und ausgehenden Paketwarteschlangen abgewickelt. GNU ccRTP bietet Unterstützung für RTCP und viele andere Standard-und erweiterte Funktionen, die sowohl kompatibel und erweiterte Streaming-Anwendungen benötigt werden.
Es können mehrere Nutzlasttypen in Strom zu mischen, und können daher verwendet werden, um RFC 2833 konformen Signalisierung Anwendungen sowie andere spezielle Dinge impliment werden. GNU ccRTP bietet auch direkten RTP und RTCP-Paketfilterung.
GNU ccRTP verwendet Vorlagen zum Einfädeln und Steckdosen Abhängigkeiten zu isolieren, so dass es verwendet werden, um Echtzeit-Streaming mit verschiedenen Threading-Modelle und die zugrunde liegenden Transportprotokolle, nicht nur mit IPv4-UDP-Sockets impliment werden. Für eine ausführlichere Liste von ccRTP Funktionen können Sie einen Blick auf Hand der Programmierer haben.
Auf höchstem Niveau, bietet ccRTP Klassen für das Echtzeit-Transport von Daten über RTP-Sessions sowie die Steuerfunktionen von RTCP.
Das Hauptkonzept der ccRTP Umsetzung RTP-Sessions ist der Einsatz von Paketwarteschlangen, um die Übertragung und den Empfang von RTP-Datenpakete / Anwendungsdateneinheiten verarbeiten. In ccRTP wird ein Datenblock, indem Sie es in das Getriebe (ausgehende Pakete) Warteschlange übertragen werden, und indem sie es von der Rezeption (eingehende Pakete) Warteschlange empfangen.
Es gibt mehrere Ebenen der Schnittstelle (öffentliche Schnittstelle, öffentliche oder geschützte Vererbung, etc.) in ccRTP. Zum Beispiel ist die rtphello Demoprogramm mit ccRTP verteilt nutzt nur die öffentliche Schnittstelle des RTPSession Klasse und nicht die virtuelle Methode onGotSR neu zu definieren, damit, was dieses Programm kennt SR Berichten sind die Informationen in der letzten Senderbericht vermittelt aus jeder Quelle, die kann über die getMRSenderInfo Verfahren der SyncSource Klasse abgerufen werden.
Im Gegenteil, definiert der rtplisten Demoprogramm onGotSR durch Vererbung und konnte spezialisierte Verarbeitung dieser RTCP-Pakete zu tun. Meist sowohl die Daten- und Steuerpakete werden nicht durch die meisten externen Schnittstelle zugänglich.
Alle diese Funktionen werden durch ein paar wesentliche Klassen und Typen durchgeführt. Die grundlegenden diejenigen sind die Aufzählungstyp StaticPayloadType und die Klassen StaticPayloadFormat und DynamicPayloadFormat.
Die wichtigsten davon sind die Klassen RTPSession, SyncSource, Teilnehmer und AppDataUnit, die RTP-Sessions, Synchronisationsquellen, die Teilnehmer in einem RTP-Anwendung und Anwendungsdaten-Einheiten in RTP-Datenpakete vermittelt, jeweils für.
Bei der Verwendung von ccRTP sowohl das Senden und Empfangen von Daten über RTP-Sessions transportiert wird über Empfangs- und Sendewarteschlangen von der RTP-Stack behandelt wurde. Im häufigsten Fall wird eine gesonderte Ausführungs-Thread für jeden RTP-Sitzung verwaltet die Warteschlangen. Dieser Fall ist das Threading-Modell, das wir in der Regel in diesem Dokument übernehmen. Beachten Sie jedoch, dass ccRTP unterstützt andere Threading-Modelle, insbesondere ccRTP unterstützt die Verwendung eines einzigen Ausführungsthread, eine Reihe von RTP-Sessions zu dienen. Es ist auch möglich, jeden separaten Thread wird nicht mit jedem RTP-Sitzung manuell ruft die wichtigsten Daten und Steuerdienstmethoden aus irgendeinem anderen Thread.
Die Grundidee für die Paketempfang mit ccRTP ist, dass die Anwendung nicht direkt Pakete von Steckdosen zu lesen, aber bekommt sie von einer Empfangswarteschlange. Der Stack ist zum Einfügen von empfangenen Pakete in der Empfangswarteschlange und dem Umgang mit diesem Warteschlange verantwortlich. Im Allgemeinen hat ein Paketempfang und Einsetzen in die Empfangswarteschlange nicht gleichzeitig die Anwendung wird es in der Warteschlange auftritt.
Umgekehrt ist die Grundidee für die Paketübertragung mit ccRTP dass Pakete nicht direkt an Steckdosen geschrieben, aber in einer Übertragungswarteschlange, die durch den Stapel gehandhabt eingefügt. Im allgemeinen Paket Einsetzen und Übertragung auftreten zu unterschiedlichen Zeiten, aber es ist nicht notwendig.
. Um ccRTP verwenden, müssen Sie die Haupt-Header (#include
#include
#include
Klassen für RTP-Erweiterungen, die noch nicht fällig sind.
Sie müssen auch einen Link in der Bibliothek, die derzeit ccrtp1
Eigenschaften :..
- Sehr dehnbar Fachstapel
- · Unterstützt Unicast, Multi-Unicast und Multicast. Griffe mehrere Quellen (einschließlich Synchronisationsquellen und einen Beitrag Quellen) und Destinationen. Auch unterstützt symmetrische RTP.
- Automatische RTCP Funktionen Handhabung, wie Vereinigung von Synchronisationsquellen aus dem gleichen Teilnehmer oder NTP-RTP-Zeitstempel-Mapping.
- Generizität als für zugrunde liegende Netzwerk und Transport-Protokolle durch Vorlagen.
- Es ist thread und unterstützt nahezu alle Threading-Modell.
- Generische und erweiterbare RTP und RTCP-Header Gültigkeitsprüfungen.
- Griffe Quelle Zustände und Informationen sowie Statistiken Aufnahme.
- sorgt automatisch für SSRC Kollisionen und führt Schleifenerkennung.
- Implementiert Timer Überprüfung und Rückwärtsdenken.
- Stellt gute Zufallszahlen, basierend auf / dev / urandom oder alternativ auf MD5.
Was ist neu in dieser Pressemitteilung:
- Code-Bereinigung, Bugfixes für RTP Absender-Info, und Zusammenführen von Debian-Patches Upstream.
Kommentare nicht gefunden