DE112006002677T5 - Verfahren und Vorrichtung für RTP-Ausgabe-Streaming unter Verwendung von komplementären Richtungsdateien - Google Patents

Verfahren und Vorrichtung für RTP-Ausgabe-Streaming unter Verwendung von komplementären Richtungsdateien Download PDF

Info

Publication number
DE112006002677T5
DE112006002677T5 DE112006002677T DE112006002677T DE112006002677T5 DE 112006002677 T5 DE112006002677 T5 DE 112006002677T5 DE 112006002677 T DE112006002677 T DE 112006002677T DE 112006002677 T DE112006002677 T DE 112006002677T DE 112006002677 T5 DE112006002677 T5 DE 112006002677T5
Authority
DE
Germany
Prior art keywords
streaming
data
packets
control processor
source
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE112006002677T
Other languages
English (en)
Inventor
Ambalavanar Arulambalam
Jian-Guo Chen
Hakan I. Pekcan
Kent E. Wires
Nevin C. Bethlehem Heintze
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Agere Systems LLC
Original Assignee
Agere Systems LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Agere Systems LLC filed Critical Agere Systems LLC
Publication of DE112006002677T5 publication Critical patent/DE112006002677T5/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/104—Signalling gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/752—Media network packet handling adapting media to network capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2383—Channel coding or modulation of digital bit-stream, e.g. QPSK modulation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/4104—Peripherals receiving signals from specially adapted client devices
    • H04N21/4135—Peripherals receiving signals from specially adapted client devices external recorder
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4381—Recovering the multiplex stream from a specific network, e.g. recovering MPEG packets from ATM cells
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4382—Demodulation or channel decoding, e.g. QPSK demodulation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Multi Processors (AREA)

Abstract

Streaming-Vorrichtung zum Übertragen von Datenpaketen von mindestens einer Quelle von Datenpaketen zu mindestens einem Ziel für die Datenpakete, mit:
– einem Netzwerkbeschleuniger in Datenverbindung mit der Quelle der Datenpakete und mit dem Ziel,
– einem Steuerprozessor, der derart ausgebildet ist, dass er ein Streamen der Datenpakete von der Quelle zu dem Ziel steuert,
– wobei der Steuerprozessor dazu programmiert ist, einen Satz von Parameterwerten bereitzustellen, die von dem Steuerprozessor zu dem Netzwerkbeschleuniger mindestens während eines vorbestimmten Schritts des Streamens der Datenpakete von der Quelle zu dem Ziel übertragen werden, und
– wobei der Netzwerkbeschleuniger dazu ausgebildet ist, die Datenpakete von der Quelle zu dem Ziel im Anschluss an den vorbestimmten Schritt als eine Funktion der Parameterwerte und im Wesentlichen unabhängig von dem Steuerprozessor zu streamen.

Description

  • Querverweis zu zugehörigen Anmeldungen
  • Diese Anmeldung beansprucht die Priorität der vorläufigen US-Patentanmeldungen 60/724,462, eingereicht am 7. Oktober 2005, 60/724,463, eingereicht am 7. Oktober 2005, 60/724,464, eingereicht am 7. Oktober 2005, 60/724,722, eingereicht am 7. Oktober 2005, 60/725,060, eingereicht am 7. Oktober 2005 und 60/724,573, eingereicht am 7. Oktober 2005, wobei die Anmeldungen hiermit durch Bezugnahme in ihrer Vollständigkeit aufgenommen werden.
  • Hintergrund der Erfindung
  • Die Erfindung betrifft Vorrichtungen und Verfahren zur Echtzeitdatenübertragung, beispielsweise in einem digitalen Videoverarbeitungszentrum oder einem Unterhaltungssystem, einem Konferenzsystem oder anderen Applikationen, welche RTP-Streaming verwenden. Zudem kann die Erfindung für Paketdatenübertragungsapplikationen angewendet werden, wobei Informationen während der Paketbearbeitung bestimmt werden und in ausgehende Datenpaketkopfabschnitte eingefügt werden, beispielsweise als Paketadressen- oder Paketverarbeitungsinformation. Dieser Betrieb erfordert ein Schritthalten mit einer Echtzeitdatenrate für das RTP-Streaming, vorzugsweise mit begrenzter rechnertechnischer Belastung. Erfindungsgemäß wird eine Richtungsdatei durch einen Steuerprozessor gebildet und erleichtert das Einfügen von solchen Informationen während der Ausgabe der Pakete.
  • Die erfindungsgemäßen Vorrichtungen und Verfahren unterstützen verschiedene Aufnahme-, Wiedergabe- und Verarbeitungsfunktionen, wobei Inhalts- und Steuerinformationen an oder von Funktionselementen gerichtet sind, welche Daten speichern, präsentieren oder verarbeiten. Im Zusammenhang mit Daten-Streaming sind bestimmte Schritte erforderlich, wenn auf die Steuerinformation reagiert wird. Wenn beispielsweise eine Verbindung initiiert wird, ist es erforderlich, eine Datenpaketverarbeitung und Adressenarrangements einzurichten, um auf die Steuerinformation zu reagieren. Es kann erforderlich sein, Pakete, welche von einem Speichermedium oder einem Kommunikationspfad oder einem Anschluss übertragen werden sollen, zu finden oder auf die Pakete zuzugreifen. Basierend auf der Steuereingabe und auch auf der in den Paketen gefundenen Information bestimmt eine übertragungsvorrichtung, wie die Übertragung genau durchgeführt wird. Erforderliche Codes, Flags, Adressen und andere Bedingungsanzeiger können bestimmt werden müssen und bei der Signalisierung verwendet werden, beispielsweise beim Einfügen in Paketkopfabschnitte oder bei der Bereitstellung von neuen Kopfabschnitten für Datenblöcke, in welchen die ursprünglichen Pakete zu übertragen sind, usw. Diese Schritte können eine große rechnertechnische Komplexität erfordern und im Wesentlichen softwaregestützt sein.
  • Nach der Herstellung einer solchen Verbindung und dem Beginn der Datenübertragung unterscheiden sich die Anforderungen etwas. Beispielsweise sind die Information, Steuerung und Adressierung eines nächsten Pakets in einem kontinuierlichen Strom wahrscheinlich sehr eng auf die Informationen für das zuletzt übertragene Packet bezogen. Die sukzessiven Pakete können durch den Strom im Wesentlichen auf die gleiche Weise bearbeitet werden. Die Pakete können sich in inkrementalen Aspekten unterscheiden, wie beispielsweise in einer Paketsequenznummer. Für den Fall eines Lesevorgangs aus einem beliebigen Speicher, schreitet die Quellenadresse fort. Das Niveau der rechnertechnischen Komplexität ist jedoch geringer. Diese Schritte profitieren von der Geschwindigkeit und Effizienz und sind im Wesentlichen hardwaregestützt.
  • Es ist vorteilhaft, wenn wiederholende Datenverarbeitungsschritte, welche rechnertechnisch nicht komplex sind, wie beispielsweise wiederholendes Routen von Datenpaketen zu und von Speicherelementen, die mit einem Netzwerk verbunden sind, unterschiedlich zu Funktionen, wie beispielsweise Steuerungsverarbeitungs- und Adressierschritte, behandelt werden, welche rechnertechnisch komplex aber auch relativ selten sind. Erforderlich ist eine optimale Lösung.
  • Es ist allgemein vorteilhaft, potentiell verschiedene Geräte freizugeben, welche potentiell verschiedene Datenformate zur gegenseitigen Beeinflussung verwenden. Entwurfsherausforderungen werden durch den Bedarf erhöht, anpassungsfähige Datenverarbeitungssysteme bereitzustellen, während verschiedenen Geräte und Datenformate mit hohen Datenraten in Übereinstimmung zu bringen sind.
  • Industriestandards regeln das Formatieren von bestimmten Datentypen. Standards beeinflussen die Adressierungs- und Signalisierungstechniken, Datenspeicherung und Datenwiedergewinnung, Kommunikationen usw. Standards werden typischerweise auf mehreren Ebenen bzw. Schichten angewendet. Ein Paketsignalisierungsstandard oder Paketsignalisierungsprotokoll kann beispielsweise verwendet werden, wenn Videodaten übertragen werden, welche gemäß einem Videocodierstandard codiert sind, usw.
  • Paketdaten, welche zwischen einer Quelle und einem Ziel übertragen werden, können in vorteilhafter Weise Gegenstand von Zwischenverarbeitungsschritten, wie einer Datenformatkonvertierung, Berechnungen, Pufferung und ähnlicher Verarbeitungs- und/oder Speicherschritten sein. In einem Datenverarbeitungssystem, das mehrere Server und Engeräte aufweist, ist ein Teil der rechnertechnischen Belastungen auf Aktionen gerichtet, die mit einer Datenformatierung und Datenneuformatierung assoziiert sind. Teil der Belastung ist die Adressierung und das Umschalten zwischen Datenquellen und Datenzielen, welche in Reaktion auf Bedingungen, wie beispielsweise einer Benutzerauswahl, die Arrangements potentiell wechseln.
  • Ein Erfordernis, wenn ein Streaming-Vorgang mit Datenpaketen durchgeführt wird, besteht darin, dass bestimmte Informationen, welche die Pakete identifizieren, in den ausgehenden Datenpaketen bereitgestellt werden, um von Elementen verwendet zu werden, welche weiter entfernt entlang dem Streaming-Signalpfad angeordnet sind. Es könnte möglich sein, einen Steuerprozessor zu verwenden, um die Streaming-Daten während ihrer Übertragung zu analysieren, wodurch eine rechnertechnische Belastung hervorgerufen wird. Es könnte möglich sein, ein Hardwarebauelement zu verwenden, um diese Funktion auszuführen, aber dieses Bauelement würde einen komplexen Aufbau erfordern und würde die Programmieranpassungsfähigkeit verschlechtern. Daher ist eine andere Lösung erforderlich.
  • Die Anforderungen zur Beschleunigung und Vereinfachung aus Geschwindigkeitsaspekten gegenüber der einer rechnerischen Komplexität bilden jedoch sich widersprechende Entwurfsziele. Es könnte vorteilhaft sein, den konkurrierenden Bedarf an Geschwindigkeit und Datenkapazität gegenüber dem Bedarf an Rechnerleistung zu optimieren, so dass Arrangements bereitgestellt werden können, welche sowohl schnell als auch vielseitig einsetzbar sind. Die vorliegende Erfindung verteilt bestimmte Funktionen, welche zum Managen von ausgehenden Datenpaketen erforderlich sind, d. h. für die Datenausgabe, derart, dass die komplexen und adaptiven rechnertechnischen Funktionen zum Zusammensetzen der erforderlichen Ausgabeinformationen einem Steuerprozessor zugeordnet sind und im Wesentlichen als Software umgesetzt werden können.
  • In bevorzugter Ausgestaltung wird die Erfindung in Bezug auf das Echtzeitprotokoll(RTP)-Paket-Streaming vorgestellt. Eine beispielhafte Gruppe von Paketquellen- und Paketzieltypen werden diskutiert, welche zur Videodatenverarbeitung zur Unterhaltung oder für Telekonferenzen anwendbar sind, aber potentiell Sicherheitsüberwachungen, Spielsysteme und andere Anwendungen umfassen. Die Übertragungswege können drahtgebunden oder drahtlos sein und können unternehmenseigene oder öffentliche Netzwerke einschließen. Die Endgeräte zur Wiedergabe können Audio- und Videounterhaltungssysteme, Computerarbeitstationen, ortsfeste oder tragbare Geräte umfassen. Die Daten können unter Verwendung von Netzwerkservern gespeichert und verarbeitet werden. Beispielhafte Kommunikationssysteme umfassen lokale und Wide-Area-Netzwerke, Kabel- und Telekommunikationsgesellschaftsnetzwerke usw.
  • In Verbindung mit Audio- und Videodaten ist das Echtzeitprotokoll „RTP", das auch als „Echtzeitübertragungsprotokoll" bekannt ist, ein Standardprotokoll, das zum Bewegen von in Pakete aufgeteilten Audio- und/oder Bild- und Bewegtbilddaten über ein Datenkommunikationsnetzwerk mit einer Echtzeitdatenrate geeignet ist. Eine Wiedergabe von Audio- und Videodaten in einer Echtzeit- oder Liverate ist wünschenswert, um den Bedarf an Speicherpuffern zu minimieren, während das Anhalten und Starten des Inhalts vermieden wird. Bei Applikationen, wie beispielsweise bei Telekonferenzen und ähnlichen Kommunikationen, sollte das Sammeln, Verarbeiten, Übertragen und Wiedergeben von in Pakete aufgeteilten Daten in vorteilhafter Weise mit kaum wahrnehmbaren Verzögerungen und ohne Pausen konsistent mit in Echtzeit durchgeführten Angesicht-zu-Angesicht-Konferenzen und -Kommunikationen erfolgen.
  • Das RTP-Echtzeitprotokoll ist ein bekanntes Protokoll, um die Handhabung von Echtzeitdaten, einschließlich Audio- und Video, auf eine einfache Weise zu ermöglichen. Es kann für Media-on-Demand sowie für interaktive Dienstleistungen, wie Internet-Telefonie, verwendet werden. Es kann zum Übertragen von Audio und Video zu und von mehreren Quellen und Zielen verwendet werden, um eine Präsentation und/oder Aufnahme zusammen mit einer konkurrierenden Verarbeitung zu ermöglichen.
  • Die Weise, auf welche die Daten behandelt werden, kann von Zeit zu Zeit unter Verwendung von Steuer- und Adressierfunktionen verändert werden, um beispielsweise eine Verbindung, die bestimmte Quellen, Ziele oder Beteiligte einschließt, zu initiieren und zu beenden. Daher weist das RTP einen Dateninhaltsteil für die Übertragung des Inhalts und einen Steuerteil zum Variieren der Datenbehandlungsweise auf, welche Starten, Anhalten und Adressieren umfasst. Der Steuerteil des RTP wird als „RTCP" für Echtzeitsteuerprotokoll bezeichnet.
  • Der Datenteil des RTP ist ein dünnes oder verschlanktes Protokoll, welches eine Unterstützung für Applikationen mit Echtzeiteigenschaften bereitstellt, wie beispielsweise für die Übertragung von kontinuierlichen Medien, z. B. Audio und Video. Diese Unterstützung umfasst Zeitablauf rekonstruktion, Verlustdetektierung oder Verlusterkennung, Sicherheit, Inhaltsidentifikation und ähnliche Funktionen, die wiederholend sind und im Wesentlichen kontinuierlich mit der Übertragung von Medieninhalten auftreten.
  • RTCP stellt eine Unterstützung für Echtzeitkonferenzen von Gruppen beliebiger Größe innerhalb eines Kommunikationsnetzwerkes, wie beispielsweise des Internets, bereit. Diese Unterstützung umfasst eine Quellenidentifizierung und Unterstützung für Gateways wie Audio- und Video-Bridges sowie Gruppenruf-zu-Einzelruf-Übersetzern. Es bietet eine Dienstqualität, die vom Empfänger zur Gruppenrufgruppe zurückgemeldet wird, sowie eine Unterstützung für die Synchronisation von verschiedenen Medienströmen.
  • RTP und RTCP sind Datenprotokolle, die insbesondere ausgeführt sind, um die Übertragung von Daten der oben beschriebenen Arten zu erleichtern, wobei die RTP- und RTCP-Protokolle in einer vorgegebenen Netzwerkkonfiguration aber mit höheren oder niedrigeren Protokollen und Standards assoziiert werden können. Auf einer höheren Schicht können die RTP- und RTCP-Protokolle beispielsweise verwendet werden, um ein Videokonferenzsystem oder eine Anschau-und-Speicher-Technik oder andere Techniken zur Behandlung von Daten zu unterstützen. Auf einer niedrigeren oder einer mehr grundlegenden Schicht können die Pakete, die während der RTP- und RTCP-Datenübertragung verwendet werden, aktuell gemäß anderen Paketübertragungsnachrichtenprotokollen übertragen werden. Beispiele sind das Übertragungssteuerprotokoll (TCP oder TCP/IP) und das Benutzerdatagrammprotokoll (UDP).
  • Die TCP- und UDP-Protokolle dienen beide zur Paketübertragung, weisen aber grundsätzlich verschiedene Eigenschaften in Bezug auf Paketintegrität- und Fehlerüberprüfung, Empfindlichkeit gegenüber verlorenen Paketen und anderen Aspekten auf. TCP verwendet im Wesentlichen Protokollaspekte, die sicherzustellen helfen, dass eine Zweiwegverbindung während einer Übertragung erhalten bleibt und die Verbindung erhalten bleibt, bis alle assoziierten Pakete übertragen und am Empfangsende zusammengesetzt sind, wobei möglicherweise Neuversuche enthalten sind, um Pakete zu erhalten, die vermisst oder beschädigt sind. UDP bearbeitet im Wesentlichen Paketübertragungsversuche, aber es liegt an den Applikationen, welche die Pakete senden und empfangen, sicherzustellen, dass alle erforderlichen Pakete gesendet und empfangen werden. Einige Applikationen, wie das Streaming von Telekonferenzbildern, sind nicht sehr empfindlich auf Pakete, die zwischenzeitlich fallengelassen werden. Es ist aber vorteilhaft, dass das Streaming so nahtlos wie möglich weitergeführt wird, wenn Pakete fallengelassen werden.
  • Es könnte vorteilhaft sein, wenn hier Techniken ausgearbeitet werden könnten, bei denen Echtzeitübertragungen unter Verwendung eines großen Bereichs von höheren und niedrigeren Protokollen ausführbar sind, während es der Konfiguration ermöglicht wird, die Möglichkeiten der verschiedenen Protokolle zu nutzen. Es könnte insbesondere in Systemen mit hoher Leistungsfähigkeit oder hohen Anforderungen nützlich sein, die Funktionsweise so zuzuschneidern, dass die für die Kommunikation verfügbaren Ressourcen, die für die Berechnungen verfügbaren Ressourcen und situationsabhängige Umschalt- und Entscheidungsfindungsprozesse optimiert werden können.
  • Zusammenfassung
  • Ein Aspekt der Erfindung betrifft die Bereitstellung einer effizienten Verarbeitung von Videodaten und ähnlichen kontinuierlichen Streaming- bzw. Strömungsdaten durch Verwenden eines Datenverarbeitungsarrangements, das charakteristische und konkurrierende Übertragungsda tenpfade und Steuerdatenpfade aufweist, wobei die beiden Datenpfade getrennt datendurchsatzintensive Funktionen und datenverarbeitungsintensive Funktionen unter Verwendung von charakteristischen kooperativen Ressourcen verarbeiten, die geeignet unterschiedlich für die Durchsatz- bzw. Verarbeitungsleistung konfiguriert sind.
  • Insbesondere werden ein Verfahren und eine Vorrichtung zur Erleichterung und Beschleunigung von Prozessen bereitgestellt, die von einem Medienserver durch Partitionieren von Untermengen von bestimmten ressourcenintensiven Prozessen, die mit dem Echtzeitprotokoll (RTP) assoziiert sind, durchgeführt werden, wobei die Untermengen von Prozessoren und Umschaltbauelementen bearbeitet werden, welche für die ihnen zugeordneten Untermengen optimiert sind. Die Partitionierung von geschwindigkeitsbasierten Funktionen ist Geräten zugeordnet, welche die Charakteristik der Daten-Pipelines aufweisen. Die rechnertechnische Belastung ist einem oder mehreren Zentralprozessoren zugeordnet, welche die RTP-Sitzungen steuern und die rechnertechnische Seite mit weniger Prozessorbelastung zum Transportieren der Streaming-Daten in der Datenkommunikations-Pipeline bearbeiten.
  • Bei bestimmten Ausführungsformen betrifft das Verfahren die Verwendung eines Hardwareschnittstellenelements, das wenigstens teilweise die Information aufbaut, die bereitgestellt wird, um ausgehende Datenblöcke zu definieren, welche mit dem RTP-Paket-Streaming assoziiert sind. Eine Richtungsdatei wird derart zur Verfügung gestellt, dass sie vollständig oder teilweise vom Zentralprozessor verwendet werden kann und mit einem Beschleunigungselement gekoppelt ist, das in Verbindung mit der Paketausgabe auf die Richtungsdatei zugreift. Die Richtungsdatei führt den Hardwarebeschleuniger hinsichtlich der Paketausgabe. Es ist für den Prozessor nicht erforderlich jedes Paket zu analysieren, das potentiell verschiedene gleichzeitige Streaming-Verbindungen behandelt. Stattdessen richtet der Prozessor die Richtungsdatei für jede Verbindung ein, die in Gang ist, und der Beschleuniger legt die Information mit dem Aussenden der Pakete an.
  • Der Beschleuniger kann ein Hardwareschnittstellenelement sein, welches mit einer hohen Datenrate ohne wesentliche Überwachung arbeitet und die erforderliche Block- und Kopfabschnittinformation basierend auf dem Inhalt der Richtungsdatei bereitstellt. Der Steuerprozessor wird dadurch von der Steuerung der Funktionen befreit, die rechnertechnisch intensiv sind. Obwohl der Beschleuniger in der beschriebenen bevorzugten Ausführungsform ein Hardwareelement ist, kann der Beschleuniger einen Prozessor umfassen.
  • Gemäß einer Ausführungsform wird eine inhaltsadressierbare Speicher(CAM)-Datei bereitgestellt, durch die ein Hardwarebeschleuniger mehrere aktuell vorhandene Paketwarteschlangen bestimmten Adressen zuordnet. Die CAM-Datei kann verwendet werden, um die Kopfabschnittinformation zu bestimmen, insbesondere in Verbindung mit Datenpaketen, die Kopfabschnitte mit Multioffsetpegeln enthalten. Wenn eine SETUP-Anforderung empfangen wird, um eine neue Streaming-Verbindung zu einem neuen Endpunkt zu initiieren, und kein übereinstimmender Eintrag in der CAM-Datei gefunden wird, teilt dies der Hardwarebeschleuniger dem Prozessor mit und ein Eintrag wird erstellt. Dem Hardwarebeschleuniger werden zugehörige Kopfabschnittwerte zur Verfügung gestellt, indem ein Eintrag im inhaltsadressierbaren Speicher (CAM) im Vorgriff auf eine RECORD- oder SEND-Nachricht erstellt wird. Die mit dem neuen Endpunkt assoziierten Kopfabschnittwerte sind dem Steuerprozessor bekannt, der Prozessor muss jedoch nur das Routen für den neuen Endpunkt durch Aufbauen einer neuen Paketwarteschlange im inhaltsadressierbaren Speicher (CAM) einrichten. Der Hardwarebeschleuniger kann dann als Automat arbeiten, der die Warteschlangeneinträge für ein ankommendes Paket findet, die erforderlichen Werte substituiert und die Pakete in Richtung ihres Ziels weiterleitet.
  • Wenn eine RTSP-RECORD- oder SEND-Nachricht empfangen wird, die einen eingerichteten Warteschlangeneintrag aufweist, liegt die Verantwortlichkeit für die Bestimmung des ausgehenden Kopfabschnittwertes beim Hardwarebeschleuniger in Datenkommunikation mit dem Verkehrsmanager und dem Zentralprozessor. Die Verbindung kann bis zum Abschluss oder bis der Zentralprozessor erforderliche neue Steuerungen und Aktivitäten beeinflusst, wie beispielsweise einem Bestimmen des Endpunkts oder von Endpunkten des Stroms gemäß beliebiger programmierbarer Funktionen, in vollem Gange und mit dem Vorteil der hohen Datenrate verbleiben. Solche Funktionen können viele oder alle Funktionen umfassen, die sonst einen Steuerschaltkreis erfordern, um mittels einer programmierten Softwareroutine zu entscheiden, wie mit jedem weitergeleitenden Paket zu verfahren ist. Solche Funktionen können das Routen von Paketen zwischen Quellen und Zielen, Einfügen von Zwischenprozessschritten, gleichzeitiges Routen von Paketen zu zwei oder mehr Zielen, wie beispielsweise zum Aufnehmen während des Abspielens, usw. umfassen.
  • Die vorliegende Erfindung wendet eine Richtungsdatei an, welche Informationen für einen generalisierten Kopfabschnitt und einen Kopfabschnittblock enthält, welche zusätzlich zum RTP-Kopfabschnitt eingerichtet wird und in Verbindung mit der Paketausgabe, d. h. mit dem Paketausgang, verwendet wird. Daher ist die Beschleunigung des Managements der Paketausgabe eine Möglichkeit, um die Belastung des Steuerprozessors während der Übertragung zu minimieren.
  • Anforderungen an eine Streaming-Datenrate und einen Streaming-Datendurchsatz können hoch sein. Um unter Verwendung eines Prozessors Schritt zu halten, kann ein sehr schneller und geeigneter Zentralprozessor erforderlich sein, um ausreichende Rechenleistung und auch das Erfordernis eine Information für die ausgehenden Datenblöcke aufzubauen und einzufügen zu gewährleisten. Es ist ein erfinderischer Aspekt, die Richtungsdatei einzuführen, um die rechnertechnische Belastung des Zentralprozessors zu minimieren. In dem Umfang, wie die Richtungsdatei dazu konfiguriert werden kann, eine Schnittstelle mit dem Hardwarebeschleuniger zu bilden, kann die rechnertechnische Belastung wesentlich reduziert werden, um die Richtungsdatei über den Steuerschaltkreis bzw. die Steuereinheit aufzubauen und es zu ermöglichen, dass der Strom kontinuierlich Datenblöcke ohne Überwachung durch die Steuereinheit sendet.
  • Es ist ein Aspekt der Erfindung eine optimale Lösung für die Verarbeitung von Steuer- und Inhaltpaketen in einer effizienten Weise zur Verfügung zu stellen. Eine RTSP/RTP-Lösung sollte nicht vollständig in Hardware oder Software implementiert werden, sondern wird am Besten als Hybridlösung implementiert, wobei der Prozess im Wesentlichen durch Software gesteuert wird, wobei der Prozess Registerwerte und ähnliches erzeugt, die vorzugsweise unter Verwendung von Hardware verarbeitet werden, um die Datenübertragung unter Verwendung von Medienobjekten und Unterstützungsdateien zu beschleunigen, die durch Software erzeugt werden.
  • Aufgrund ihrer relativen Komplexität und seltenen Verwendung können RTSP und PRCP, nämlich Pakete, die zu ihrem größten Teil zum Managen von Steuerprozessen verwendet werden, in einem Zentralprozessor implementiert werden, ohne diesen zu überlasten, da RTSP- oder RTCP-Pakete selten die Aufmerksamkeit erfordern. Eine RTP-Verarbeitung erfordert andererseits eine Verarbeitung, um jedes ausgehende Paket im Medienstrom zu überwachen, und profitiert von der Beschleunigung.
  • Paketausgabe-Streaming sollte in Echtzeit erfolgen, d. h. im Gleichschritt mit der Echtzeitrate der Datenpakete. Die vorliegende Erfindung wendet die Richtungsdatei in einer Implementierung an, die sinngemäß Hinweise verwendet, um die Hardware mit der RTP-Paketinformation zu versorgen, welche für sie erforderlich ist, oder um direkter zur Erzeugung von den erforderlichen Ausgabeinformationen zu führen. Der Steuerprozessor kann in die Bestimmung des Inhalts der Richtungsdatei einbezogen werden. Nachdem die Richtungsdatei jedoch für eine Verbindung eingerichtet ist, beschleunigt die Hinweistechnik das RTP-Streaming in einem Server durch Entfernen des Erfordernisses, dass der Server oder die Steuereinheit die gestreamten Medien gleichzeitig analysiert, um fortzuschreiten.
  • Die erfindungsgemäße Technik schiebt die Verantwortung nicht vollständig zur zugeordneten Hardware. Die Technik erfordert beispielsweise nicht, dass die Hardware eine ausreichende Komplexität aufweist, wie es beispielsweise erforderlich sein kann, um Hinweisdaten zu analysieren.
  • Das Format für die Richtungsdatei ist vorzugsweise flexibel dargestellt, um zukünftige Erweiterungen zu ermöglichen. Gleichzeitig sollte die Flexibilität des Richtungsdateiformats nicht das Entwurfsziel zur Entlastung der wiederholenden und rechnertechnischen einfachen Aspekte der Streaming-Funktionalität des Hardwarebauelements verkomplizieren.
  • Das vorliegende Verfahren löst dieses Problem durch Einbinden der erforderlichen Information, nicht jedoch des Medienobjektes selbst, in eine komplementäre Datei, die von der Hardware verwendet werden kann. Wenn eine Mediendatei mit einem speziellen RTP-Pakettyp, nämlich mit einem Pakettyp, der gemäß FRS definiert ist, für den Streamer zugreifbar ist, und es ein Kandidat für einen Streaming-Vorgang ist, wird eine Richtungsdatei erzeugt. Diese Datei wird durch Software erzeugt, welche im Hintergrund auf dem Zentralprozessor abläuft, nämlich als Prozess mit niedriger Priorität, der verarbeitet wird, wenn Ressourcen ver fügbar sind. Die Richtungsdatei ist dahingehend einer Hinweisdatei ähnlich, dass sie dem Streamer mitteilt, wie das Objekt für das RTP-Streaming in Pakete aufgeteilt werden soll. Die erfindungsgemäße Richtungsdatei ist jedoch dahingehend spezifischer als die Hinweisdatei, wie die Ausgabe eines Pakets beeinflusst wird. Daher kann die erfindungsgemäße Technik arbeiten, wobei der Zentralprozessor sogar wenig Wissen über das systemeigene Medienobjekt hat.
  • Diese und andere Gegenstände und Aspekte werden durch die nachfolgende Beschreibung von bevorzugten Ausführungsformen und Ausführungsbeispielen deutlich.
  • Kurze Beschreibung der Zeichnungen
  • In den Zeichnungen sind bestimmte beispielhafte und nicht beschränkende bevorzugte Ausführungsformen der Erfindung dargestellt. Um den Gegenstand der Erfindung zu bestimmten, wird jedoch auf die zugehörigen Ansprüche Bezug genommen, aus denen Rechte hervorgehen. Es zeigen:
  • 1 ein Blockdiagramm, das ein erfindungsgemäßes Quelle-zu-Ziel-Datenübertragungsverhältnis, z. B. Server zu Client, darstellt, wobei eine RTP-Dateninhaltskomponente um einen Steuerungspunkt, wie beispielsweise um einen Zentralprozessor, der RTSP- und/oder RTCP-Steuersignalisierung bearbeitet, geroutet wird.
  • 2 ein Blockdiagramm zur Darstellung eines erfindungsgemäßen Streaming-Steuerschaltkreises.
  • 3 eine Tabelle zur Darstellung von Komponentenwerten in einem RTP-Kopfabschnitt.
  • 4 eine Datentabelle zur Darstellung einer Richtungsdatei entsprechend einer erfindungsgemäßen Ausführungsform.
  • 5 ein Blockdiagramm zur Darstellung der Komponenten eines Heimnetzwerks, das mit einem Unterhaltungssystem „HNAS" verbunden ist, das in vorteilhafter Weise konfiguriert ist, um die Paketdatenbearbeitungsvorschläge der Erfindung zu umfassen.
  • Detaillierte Beschreibung von bevorzugten Ausführungsformen
  • RTP macht keine Adressenressourcenreservierungen und garantiert nicht, dass eine Dienstqualität für Echtzeitdienste, wie beispielsweise Sicherstellen auf einer RTP-Protokollschicht, bereitgestellt wird, dass Verbindungen erhalten bleiben und Pakete nicht verloren gehen usw. Das Datenübertragungsprotokoll, nämlich RTP, wird durch ein Steuerprotokoll (RTCP), das für eine Sitzungssteuerung, nämlich für RTP-Übertragungen von einer Quelle zu einem Ziel, verwendet werden kann, und durch ein Gesamtpräsentationssteuerprotokoll (RTSP) ergänzt.
  • Die RTCP- und RTSP-Steuerprotokolle beziehen Signalisierungspakete mit ein, die beispielsweise übertragen werden, wenn ein Übertragungswechselpfad aufgebaut oder getrennt wird, wenn eine Übertragung in eine Richtung (PLAY) oder in eine andere Richtung (RECORD) initiiert wird, wenn eine Pause eingefügt wird usw. Die Inhaltsdatenpakete sollten so kontinuierlich wie möglich in Echtzeit mit einigen Synchronisationsbezügen strömen. Die Inhaltspakete werden zur gleichen Zeit wie die RTCP- und RTSP-Pakete übertragen, wobei die Pakete der drei entsprechenden Protokolle jedoch unterschiedlich adressierte logische Verbindungen oder Anschlussstellen verwenden.
  • Die RTCP/RTSP-Steuer- und RTP-Daten-Streaming-Protokolle stellen gemeinsam Werkzeuge bereit, die für große Gruppenrufnetzwerke skalierbar sind. RTP und RTCP sind bestimmt, um unabhängig von den unterlegten Transport- und Netzwerkschichten zu sein, und können daher mit verschiedenen Alternativen zu diesen Schichten verwendet werden. Das Protokoll kann auch die Verwendung von RTP-Schicht-Übersetzern und RTP-Schicht-Mischern unterstützen, falls erforderlich.
  • Das RTP-Steuerprotokoll (RTCP) weist die Fähigkeit auf, die Dienstqualität zu überwachen und Informationen über die Teilnehmer während einer stattfindenden Sitzung zu transportieren. Die Teilnehmerinformation ist für „locker gesteuerte" Sitzungen ausreichend, wo beispielsweise keine besondere Mitgliederkontrolle und Aufbau erfolgt, wobei eine vorgegebene Applikation jedoch mehr Anforderungsauthorisierung oder Kommunikationsanforderungen aufweisen kann, was allgemein im Geltungsbereich des RTSP-Sitzungssteuerprotokolls liegt.
  • RTP-Dateninhaltpakete, die zwischen einer Quelle und einem Ziel gestreamed bzw. geströmt werden, werden im Wesentlichen in Echtzeit einfach in Richtung Zieladresse weitergeführt. Während die Pakete in Echtzeit weitergeleitet werden, besteht ein geringer Bedarf zur Pufferspeicherung in der empfangenden Vorrichtung. Aus den gleichen Gründen besteht in der sendenden Vorrichtung typischerweise kein Bedarf an der Erzeugung einer Temporärdatei. Im Gegensatz zu einigen andern Protokollen, wie beispielsweise HTTP-Objektübertragung, teilt RTP das Objekt in Pakete mit medienspezifischen Kopfabschnitten auf. Der RTP-Empfänger ist dazu konfiguriert, sich von Paketverlusten eher zu erholen, als Wiederholungssignalisierungsfähigkeiten aufzuweisen. Die RTP-Übertragungen können ein verbindungsloses TCP/IP-Protokoll verwenden. Typischerweise werden RTP-Übertragungen mit Benutzerdatagrammprotokoll(UDP)-Paketübertragungen von RTP-Daten ausge führt, typischerweise aber nicht notwendigerweise jeweils mit einem UDP-Paket, das ein RTP-Paket bildet.
  • Ein RTP-Paket weist einen festen Kopfabschnitt, welcher das Paket als RTP identifiziert, eine Paketsequenznummer, einen Zeitstempel, eine Synchronisationsquellenidentifikation, eine möglicherweise leere Liste von beitragenden Quellenidentifizierungen und Nutzlastdaten auf. Die Nutzlastdaten enthalten eine vorgegebene Anzahl von Datenwerten, wie Audioabtastwerte oder komprimierte Videodaten.
  • Ein RTP-Streaming-System verwendet gut erkennbare Echtzeitdateninhaltpakete (RTP), Steuerpakete (RTCP) und/oder Sitzungssteuerpakete (RTSP). Die Managementpakete (RTCP, RTSP) beziehen sich auf Verbindungen, welche RTP-Inhaltpakete über eine oder mehrere Verbindungen übertragen können. Die RTCP- und RTSP-Verbindungen beziehen andere „Verbindungsanschlussstellen" als RTP ein, aber wichtiger ist, dass die Pakete in Frequenz und Funktion verschieden sind.
  • Es ist möglich, einen Prozessor in einem Empfänger bereitzustellen, wie beispielsweise einem netzwerkverbundenen Unterhaltungssystem, einem Videokonferenzsystem, einem netzwerkverbundenen Speicherbauelement usw., und den Prozessor zu programmieren, um angemessen zwischen RTP-Paketen und RTCP- oder RTSP-Steuerpaketen unterscheiden zu können. Die Datenpakete werden in Richtung ihres Ziels geleitet und die Steuerpakete werden vom Prozessor verwendet, um andere programmierte Funktionen zu beeinflussen und die Informationen zu übertragen. Damit ein solches System Schritt halten kann, müssen die RTP-Inhaltpakete in Echtzeit bearbeitet werden, und wenn der Zentralprozessor bestimmte der Pakete managen muss, welche in Paketausgaben eingefügte Felder aufweisen, muss der Prozessor mit einer hohen Datenrate arbeiten.
  • Die Steuerpakete in Streaming-Situationen können zu verschiedenen Verbindungsszenarien in eine oder mehrere Richtungen mit datenindifferenten Formaten geleitet werden und eine Mehrzahl von Endpunkte einschließen. Der Steuerprozessor erfordert eine rechnertechnische Komplexität und eine Programmierung, die erforderlich ist, um potentiell betroffene Steuerprozesse zu bearbeiten. Wenn ein vorgegebener Prozessor, der substantiell zu einer rechnertechnischen Komplexität in der Lage ist, d. h. ein kompliziertes Programm aufweist, auch einfach zum Weiterleiten von RTP-Inhaltpaketen verwendet wird, dann ist sowohl eine hohe Datenrate als auch eine hohe Rechnerkapazität erforderlich. Die Rechnerkapazität zur Bearbeitung von komplexen Steuerungsberechnungen, die selten auftreten, wird jedoch verschwendet, wenn der Prozessor den Großteil seiner Betriebskapazität zum aufeinander folgenden Weiterleiten von RTP-Paketen über eine oder mehrere leicht unterscheidbare Verbindungen verwendet.
  • Ein Aspekt der vorliegenden Erfindung besteht darin, eine Lösung bereitzustellen, durch welche die Berechnungsergebnisse, die von einem Steuerprozessor bestimmt werden, zu einem weniger komplexen aber vielleicht schnelleren Hardwarebauelement übertragen werden, um die Pakete weiterzuleiten, beispielsweise für die Paketausgabe. Dies wird unter Verwendung der erfindungsgemäßen Richtungsdateitechnik umgesetzt.
  • 1 zeigt eine einfache Netzwerkumgebung mit einem Steuerungspunkt, der zwischen einem Server, nämlich der Quelle der Streaming-Daten, und einem Client, dem Ziel, eingeschleift ist. Jede Verbindung ist mit den verschiedenen unterstützten Pakettypen für das RTP-Streaming bezeichnet. Der Erfindungsgegenstand kann allgemein für Konfigurationen angewendet werden, welche einen Steuerungspunkt einschließen und durch Bereitstellung einer Technik, durch welche Felder in Nachrichtenkopfabschnitten unter Verwendung eines beschriebenen Hard warebeschleunigers ersetzt werden, wenigstens teilweise den Bedarf einer Verarbeitung am Steuerungspunkt umgehen.
  • 2 zeigt eine beispielhafte Situation, in welcher der Steuerungspunkt durch einen Zentralprozessor repräsentiert wird, der mit einer Paketquelle, die als Server dargestellt ist, über ein Netzwerk verbunden ist. In der dargestellten Konfiguration könnte der Zentralprozessor in herkömmlicher Weise erforderlich sein, um Pakete zu einem oder mehreren Zielen weiterzuleiten, beispielsweise über einen Verkehrsmanager/Verkehrsverwalter durch Leiten der in einem Paketstrom identifizierten Pakete von der Paketquelle zu einem oder mehreren adressierbaren Zielen, wie einem mit dem Netzwerk verbundenen Speicherelement, welches bei dieser Ausführungsform durch einen Disk-Speicher und seinen Steuerschaltkreis oder ein Ausgabegerät repräsentiert wird.
  • Entsprechend einem erfindungsgemäßen Aspekt werden die Paketdaten in Teilen von einem Schnittstellenbauelement in Form eines Netzwerkbeschleunigers bearbeitet. Der Netzwerkbeschleuniger kann als Bauelement mit einem hohen Durchsatz mit einer minimalen, wenn überhaupt vorhandenen rechnertechnischen Komplexität ausgeführt werden, welches dazu konfiguriert ist, Werte in Datenblöcke einzufügen, welche RTP-Pakete umfassen, um ihre Handhabung und weitere stromabwärtige Verarbeitung zu steuern. Aus diesem Grund wird eine Richtungsdatei erzeugt, die einen generalisierten Kopfabschnittbereich aufweist, welcher einen Identifizierungscode und einen Wertesatz aufweist, der einen Paketzähler, eine Kopfabschnittblockgröße und Zeiger und/oder Längenwerte aufweist, welche die Position in den zu verarbeitenden Daten des RTP-Kopfabschnitts identifizieren.
  • Die einzelnen Quellen- und Zielelemente dieses Beispiels sind repräsentative Beispiele. Die Erfindung kann in Situationen angewendet werden, welche eine Vielzahl von potentiellen Quellen und potentiellen Zielen einschließen, welche mehr oder weniger nah oder fern in der Datenkommunikation gekoppelt sind, wie dargestellt ist, um zu einem vorgegebenen Zeitpunkt, als Quelle oder Ziel der übertragenen Pakete in der einen oder der anderen Richtung oder in beiden Richtungen zwischen zwei solchen Elementen zu funktionieren. Das bestimmte Beispiel kann für die Übertragung von Paketen in der Situation angeordnet sein, in welcher ein Inhaltsignal auf einem Wiedergabegerät dargestellt und gleichzeitig aufgenommen wird. In anderen Beispielen kann ein Datenflussarrangement aufgebaut werden, in welchem Daten aufgenommen aber nicht wiedergegeben werden oder wiedergegeben aber nicht aufgenommen werden. Andere einzelne Quellen- und Zielelemente können betroffen sein. Die gleichen ankommenden Pakete können von einer Quelle zu einem oder mehreren Zielen geroutet werden. Alternativ kann der Inhalt von zwei oder mehr Quellen für eine koordinierte Speicherung oder Wiedergabe vorgesehen werden, beispielsweise als eine Bild-im-Bild-Einfügung oder für eine gleichzeitige Seite-an-Seite-Darstellung, beispielsweise während einer Telekonferenz. Diese und andere ähnliche Applikationen sind gemäß der Erfindung einfach realisierbar.
  • Der Datenfluss zerfällt in drei Haupttypen, nämlich in RTSP-Pakete für die Gesamtpräsentationssteuerung, in RTCP-Pakete für die individuelle Sitzungsprotokollsteuerung und in RTP-Pakete für die Dateninhaltübertragung.
  • RTSP ist ein Applikationsschichtprotokoll, welches verwendet wird, um eine oder mehrere konkurrierende Präsentationen oder Übertragungen von Daten zu steuern. Eine einzelne RTSP-Verbindung kann mehrere konkurrierende und/oder aufeinander folgende RPT-Objektübertragungen steuern. Bei einem Videokonferenzarrangement, welches beispielsweise mehrere Orte umfasst, können bidirektionale Übertragungen zwischen jedem Ortspaar aufgebaut werden. Die Syntax des RTSP ist ähnlich der von HTTP/1.1, stellt aber Konventionen bereit, welche für die Medienübertragung spezifisch sind. Die Haupt-RTSP-Befehle, welche eine Sitzung definieren, sind:
    • – SETUP: Bewirkt, dass der Server Ressourcen für einen Strom und einen Start einer RTSP-Sitzung zuordnet.
    • – PLAY und RECORD: Startet die einem Strom über SETUP zugeordnete Datenübertragung von einer Quelle zu einem Ziel.
    • – PAUSE: Hält den Strom temporär an, ohne die Serverressourcen freizugeben.
    • – TEARDOWN: Gibt die mit dem Strom assoziierten Ressourcen frei. Die RTSP-Sitzung hört auf im Server zu existieren.
  • Wenn der Steuerungspunkt unter Verwendung einer RTSP-SETUP-Anforderung eine Objektübertragung anfordert, sendet er eine Anforderung an den Server und den Client, welche die Details der Objektübertragung, einschließlich Objektidentifikation, Quellen- und Ziel-IP-Adressen und Protokolports, und der zu verwendenden Transportschichtprotokolle, allgemein RTP und entweder TCP oder UDP, aufweisen. Auf diese Weise beschreiben die RTSP-Anforderungen die Sitzung zwischen dem Client und dem Server. In einigen Fällen kann die Anforderung speziell für eine Untermenge eines verfügbaren Objekts sein, wie beispielsweise für eine Audio- oder Videokomponente des Objekts.
  • Wenn alle erforderlichen SETUP-Anforderungen gemacht und bestätigt sind, kann der Steuerungspunkt in Abhängigkeit von der Richtung der Übertragung eine PLAY- oder RECORD-Anforderung ausgeben. Die Anforderung kann optional einen bestimmten Bereich des Objekts, welcher geliefert werden soll, eine normale Wiedergabezeit des Objekts und einen lokalen Zeitpunkt bestimmen, an welchem die Wiedergabe beginnen soll.
  • Nach der Beendigung der Wiedergabe wird die Präsentation automatisch unterbrochen, als ob ein PAUSE-Befehl ausgegeben worden wäre. Wenn ein PAUSE-Befehl ausgegeben wird, wird der Zeitstempel spezifiziert, an welchem der Strom pausieren soll, und der Server bzw. Client stoppt die gelieferten Daten, bis eine nachfolgende PLAY- bzw. RECORD-Anforderung ausgegeben wird.
  • Wenn eine TEARDOWN-Anforderung ausgegeben wird, wird die Datenlieferung des spezifizierten Stroms angehalten und alle zugeordneten Sitzungsressourcen werden freigegeben.
  • Ein RTSP-Befehl kann eine Außerbandübertragungssitzung spezifizieren, bei welcher RTP/UDP oder RTP/TCP für die Übertragung verwendet wird. Eine „Außerbandübertragung" bezeichnet zwei oder mehr charakteristische Übertragungs- oder Verbindungspfade. Der RTSP-Verkehr kann in diesem Fall über eine Verbindung erfolgen, und eine andere Verbindung kann durch RTSP spezifiziert werden, um die aktuelle Übertragung der RTP-Daten auszuführen.
  • Die RTP-Pakete können über TCP übertragen werden. Dies ist allgemein ineffizient, da eine UDP-Übertragung keine aufrechterhaltene Verbindung erfordert, nicht empfindlich für verlorene Pakete ist und/oder nicht versucht verlorene Pakete zu detektieren und zu erkennen, wie dies bei TCP erfolgt. Das UDP-Übertragungsprotokoll ist für eine Echtzeitübertragung von Paketen, wie beispielsweise von Audio- oder Videodatenabtastwerten, geeignet. Solche Werte sind nicht individuell kritisch, sollten aber mit einem hohen Datenvolumen übertragen werden. TCP unterscheidet sich dadurch vom UDP, dass Verbindungen aufgebaut werden, das Protokoll die Zuverlässigkeit betont, beispielsweise durch den Versuch verlorene Pakete durch eine Neuübertragung zu erhalten usw. Diese Aspekte sind mit den Bedürfnissen von RTP weniger konsistent als UDP. Diese Beschreibung setzt generell voraus, dass UDP für die RTP-Übertragung verwendet wird. Die Offenbarung sollte aber nicht auf die bevorzugte UDP-Übertragung begrenzt werden sondern schließt vielmehr TCP und andere Protokolle ein.
  • Wenn ein Server eine Anforderung für ein zu lieferndes Objekt unter Verwendung von RTP empfängt, wird das Objekt typischerweise von seinem systemeigenen Format in ein Paketformat überführt. Eine Anzahl von „Inhaltsanforderungs(RFC)"-Nachrichtenbausteinen, welche eine assoziierte RFC für verschiedene vorgegebenen Datentypen umfassen, wurden in der Industrie, wie beispielsweise von der Internet Engineering Task Force (ietf.org), entwickelt, um Probleme zu lösen, welche mit der beschriebenen Aufteilung der Daten in Pakete assoziiert sind, und um einen Online-Zugriff aufrechtzuerhalten.
  • Jeder Medienobjekttyp wird entsprechend den von der assoziierten RFC bereitgestellten standardisierten Spezifikationen typischerweise etwas unterschiedlich in Pakete aufgeteilt, sogar mit unter den Typen variierenden Kopfabschnittformaten. Die Unterschiede treten aufgrund der verschiedenen Objekte und der Probleme im Zusammenhang mit der Behandlung von verschiedenen Nutzdaten auf.
  • 3 zeigt das Format des gemeinsamen RTP-Kopfabschnitts, wie es beispielsweise in RFC 3550/3551 beschrieben ist. Die Kopfabschnittfeldabkürzungen sind wie folgt:
    „V" repräsentiert eine Versionsnummer. Die aktuelle Version ist die Version 2. Obwohl im Kopfabschnitt nichts Inhärentes vorhanden ist, welches das Paket als eindeutig im RTP-Format identifiziert, ist das Vorhandensein der Versionsnummer „2" an dieser Kopfabschnittposition ein Indikator dafür.
  • „P” ist ein Wert, der anzeigt, ob eine Auffüllung am Ende der Nutzlast existiert, welche ignoriert werden sollte, und wenn dem so ist, den Umfang der Auffüllung. Das letzte Byte des Auffüllungswerts gibt die Gesamtzahl der Auffüllungsbytes an.
  • „X" ist ein Wert, der zeigt, ob ein Erweiterungskopfabschnitt vorhanden ist oder nicht.
  • „CC" ist ein Zähler der Anzahl von beisteuernden Quellen, die in diesem Kopfabschnitt identifiziert sind.
  • „M" ist ein Markierungsbit. Die Implementierung dieses Bits ist spezifisch für den Nutzlasttyp.
  • „PT" identifiziert den Nutzlasttyp, nämlich den Typ des Objekts, das übertragen wird. Neben anderen Dingen erlaubt der Nutzlasttypidentifizierer dem Empfänger zu bestimmen, wie der RTP-Strom abgeschlossen wird.
  • „Sequenznummer" ist ein Zähler der Anzahl von übertragenen RTP-Paketen. Es wird angemerkt, dass dies zum TCP verschieden ist, das eine Sequenznummer verwendet, um die Anzahl der übertragenen Bytes anzuzeigen. Die RTP-Sequenznummer ist die Anzahl der übertragenen RTP-Pakete, d. h. ein Paketindex.
  • „Zeitstempel" ist ein Feldwert, der vom Nutzlasttyp abhängig ist. Typischerweise stellt der Zeitstempel einen Zeitindex für Pakete bereit, die gesendet wurden, und stellt in einigen Fällen ein Referenz bereit, welche es ermöglicht, den Empfänger während einer Aufnahme oder einer Wiedergabe von Paketinhalten an Zeitbedingungen anzupassen.
  • „SSRC ID" identifiziert die Quelle der Daten, die übertragen werden.
  • „CSRC ID” identifiziert eine beliebige beteiligte Quelle oder Quellen, welche die Daten, die übertragen werden, verarbeitet haben, wie beispielsweise Mischer, Übersetzer usw. Es kann eine Mehrzahl von beteiligten Quellen oder es kann außer der ursprünglichen Quelle keine weitere Quelle in der SSRC ID identifiziert werden. Wie oben ausgeführt ist, stellt der Wert CC im Kopfabschnitt einen Zähler für beteiligte Quellen bereit. Der Zähler ermöglicht, dass die unbestimmte Anzahl von beteiligten Quellenidentifikationen als solche behandelt wird und der Inhalt, der dem Kopfabschnitt folgt, aufwärts indiziert wird.
  • Wenn das X-Bit gesetzt ist, dann gibt es einen Erweiterungskopfabschnitt, der dem RTP-Kopfabschnitt folgt. Die Verwendung und die Natur des Erweiterungskopfabschnitts sind von der Nutzlast abhängig. Die nutzlastspezifischen Subkopfabschnitte werden allgemein auf eine Weise spezifiziert, die es ermöglicht, dass ein Paketverlust verbessert wird, um bis zu einer gewissen Häufigkeit des Auftretens tolerierbar zu sein. Für einige Formate, wie beispielsweise für MPEG2, können einige komplexe Subkopfabschnitte mit Video- und Audiocodierinformationen dem Haupt-RTP-Kopfabschnitt folgen.
  • Die Nutzlast folgt in dem in 3 dargestellten Paket dem letzen Subkopfabschnitt. Die Nutzlastbeziehung zum systemeigenen Medienobjekt wird auch durch den Standard bestimmt, welcher den korrespondierenden Nutzlasttyp beschreibt. Es gibt häufig keine Eins-zu-Eins-Korrespondenz zwischen dem systemeigenen Objekt und der Verkettung von RTP-Paketnutzlasten. Obwohl verschiedene Faktoren vorhanden sind, welche dazu beitragen, können einige Beispielsituationen, welche den Unterschieden zwischen der RTP-Paketnutzlastsequenzen und den Bytesequenzen der systemeigenen Objekte zugrunde liegen können, aufgrund von
    • – einem Bedarf zur Synchronisation von Audio- und Videoinformationen für einen vorgegebenen Rahmen,
    • – einer Verschachtelung von Datenblöcken innerhalb der RTP-Nutzlast,
    • – einer Wiederholung für kritische Datenelemente,
    • – einer Audio/Videodemultiplexierung, oder
    • – 1.1.3 RTCP
    entstehen.
  • Periodisch werden, während eine vorgegebene RTP-Sitzung aktiv ist, Steuerinformationen bezüglich der Sitzung über eine getrennte Verbindung unter Verwendung von RTCP ausgetauscht. Für UDP verwendet die RTP-Sitzung einen geradzahligen Zielport und die RTCP-Information wird über einen nächsthöheren ungeradzahligen Zielport übertragen. RTCP führt verschiedene Funktionen aus, einschließlich Bereitstellung einer Rückkopplung der Qualität der Datenverteilung, die für einen Server nützlich sein kann, um zu bestimmten, ob Netzwerkprobleme lokal oder global sind, insbesondere für den Fall einer IP-Gruppenrufübertragung. RTCP wirkt auch, um einen stabilen Übertragungsschichtidentifizierer für eine RTP-Quelle, den CNAME, zu tragen. Da Konflikte oder Programmneustarts eine Migration von SSRC IDs verursachen können, benötigen Empfänger den CNAME, um jeden Teilnehmer zu beobachten. Der CNAME kann auch zum Synchronisieren von Strömen mit Mehrfachbezügen von verschiedenen RTP-Sitzungen verwendet werden, um beispielsweise Audio oder Video zu synchronisieren.
  • Für alle Teilnehmer einer Übertragung ist es erforderlich, dass sie RTCP-Pakete senden. Die Anzahl der von jedem Teilnehmer gesendeten Pakete kann in vorteilhafter Weise abwärts skaliert werden, wenn die Anzahl von Teilnehmern an einer Sitzung zunimmt. Dadurch, dass jeder Teilnehmer seine RTCP-Pakete an alle anderen sendet, kann jeder Teilnehmer die Anzahl der Teilnehmer beobachten. Diese Anzahl wird wiederum verwendet, um die Rate zu berechnen, mit der Steuerpakete gesendet werden. RTCP kann verwendet werden, um minimale Sitzungssteuerinformationen zu übertragen, wie beispielsweise an der Benutzerschnittstelle anzuzeigende Teilnehmerinformationen.
  • Um diese Aufgabe umzusetzen, können RTCP-Pakete in eine der folgenden Kategorien oder Formate fallen:
    • – SR: Senderbericht für Übertragungs- und Empfangsstatistiken der Teilnehmer, welche aktive Sender sind,
    • – RR: Empfängerbericht für Empfangsstatistiken von Teilnehmern, die keine aktiven Sender sind, und in Kombination mit SR für aktive Sender, die an mehr als 31 Quellen berichten,
    • – SDES: Quellenbeschreibungselemente, einschließlich CNAME, BYE: zeigt ein Ende der Beteiligung an, und PP: applikationsspezifische Funktionen.
  • Wie RTP beginnt jede Form von RTCP-Paketen mit einem gemeinsamen Kopfabschnitt, der von Subkopfabschnitten mit variablen Längen gefolgt wird. Mehrere Pakete können zu einer Form eines zusammengesetzten Pakets verkettet werden und gemeinsam in einem einzelnen Paket des niedrigeren Schichtprotokolls übertragen werden. Dies erzeugt einen Bedarf für verschiedenen Zähler und Zeiger, um die Position von erwarteten Feldern im Strom zu unterscheiden.
  • Es ist ein Aspekt der vorliegenden Erfindung, die Handhabung von Streaming-Daten im RTP-Format zu optimieren, und insbesondere das Ausgabe-Streaming durch Einfügen einer Richtungsdatei, welche be stimmte Zähler- und Indexzeigerwerte enthält, in ein Streaming-Paket zu erleichtern.
  • Das Ausgabe-Streaming der RTP-Pakete muss in Echtzeit unterstützt werden. Die Echtzeithandhabung ist ein wichtiger Aspekt des RTP-Protokolls, das den Bedarf an Puffern oder wenigstens ihre Größe wegen der anhaltenden Natur des Stroms reduziert. Die Erfindung verwendet eine Variation einer Hinweisgabe, welche die Hardware direkt mit bestimmten RTP-Paketinformationen versorgt. Die Hinweisgabe in dieser Form kann das RTP-Streaming in einem Server durch Entfernen des Erfordernisses, dass der Server die Medien während der Übertragung analysiert, beschleunigen.
  • „Hinweisgabe" ist ein Begriff, der manchmal verwendet wird, um sich auf Informationen zu beziehen, die gemeinsam mit komprimierten Video, wie MPEG-4, codiert sind, die getrennt von den zu komprimierenden Daten gesendet werden und die typischerweise von einem zugeordneten Gerät verwendet werden, das in der Lage ist, die Hinweisdaten zu analysieren, um die mit den komprimierten Videodaten assoziierte Dekomprimierung zu unterstützen.
  • Gemäß der vorliegenden Erfindung wird eine komplementäre Informationsdatei als generalisierter Kopfabschnitt und Kopfabschnittblock zur Verfügung gestellt. Es ist in diesem Fall für die zugeordnete Hardware nicht erforderlich, die Hinweisdaten zu analysieren und mit einem spezifischen Format von vorwärts- und rückwärtsbezogenen Bilddateien umzugehen. Stattdessen ist die Richtungsdatei eine Folge von Zähler- und Zeigerwerten, welche als Kennziffern verwendet werden, um RTP-Kopfabschnitt und Paketinformationen zu lokalisieren.
  • Die Richtungsdatei unterscheidet sich von einem Dekompressionshinweisgebungsmechanismus oder ähnlichem dadurch, dass die Zeigerin formation flexibel repräsentiert wird, d. h. verschiedene Paketdatenformate repräsentieren kann, um zukünftige Erweiterungen zu ermöglichen. Durch die Bereitstellung der Flexibilität in einer Schnittstellendatei können Schwierigkeiten dadurch entstehen, dass Teile der Streaming-Funktionalität von einem Prozessor, der dazu programmiert sein kann, verschiedene Formate zu unterscheiden, zu einem Hardwareelement verlagert werden, in dem die meisten Parameter fest sind. Das vorliegende Verfahren löst dieses Problem durch Einfügen von allen erforderlichen Informationen, außer dem Medienobjekt selbst, in eine komplementäre Richtungsdatei, welche von der Hardware in Teilen verwendet werden kann, weil die Richtungsdatei Indexzeiger enthält, die zu Informationen komplementär sind, die mit bekannten Offsets und anderen Erwartungswerten formatiert sind.
  • Wenn eine Mediendatei einen spezifizierten RTP-Pakettyp aufweist, (der normalerweise durch ein RFC oder einen Kommentarfaden dokumentiert wird, was zu einer Verfeinerung führt) auf den der Streamer zugreifen kann, und ansonsten ein Kandidat für Streaming ist, wird die Richtungsdatei zuerst durch eine Software erzeugt, die auf dem Zentralprozessor vorzugsweise im Hintergrund abläuft, wenn Ressourcen verfügbar sind.
  • Die Richtungsdatei ist den Hinweisdaten ähnlich, indem sie dem Streamer mitteilt, wie das Objekt für das RTP-Streaming in Pakete aufgeteilt werden soll. Sie ist aber über die Art und Weise, wie dies durchgeführt werden soll, viel spezifischer und bewirkt, dass der Zentralprozessor sogar wenig Wissen über das systemeigene Medienobjekt aufweist. Das Format einer beispielhaften Richtungsdatei 45, einer Binärdatei, ist in 4 dargestellt.
  • Unter Bezugnahme auf 4 ist der generalisierte Kopfabschnitt nur am Beginn der Datei spezifiziert und gilt für den gesamten Block. Der generalisierte Kopfabschnitt umfasst:
    • – ein Versions/Authentikationsfeld, welches dem Streamer ermöglicht zu verifizieren, dass die Richtungsdatei das richtige Format aufweist,
    • – ein Paketgesamtzahlfeld, das die Anzahl von Paketen spezifiziert, welche übertragen werden, wenn die Gesamtdatei verwendet wird,
    • – eine Richtungsdateikopfabschnittblockgröße, welche die Anzahl von Bytes spezifiziert, die jedem Kopfabschnittblock in der Richtungsdatei zugeordnet sind.
  • Ein Kopfabschnittblock wird für jedes Paket spezifiziert, das für die Übertragung durch die Richtungsdatei 45 spezifiziert ist. Der Kopfabschnittblock weist für eine vorgegebene Richtungsdatei 45 eine feste Länge auf. Der Kopfabschnittblock umfasst:
    • – payload.ptr, eine Datei, welche den Offset der aktuellen Paketnutzlast vom Anfang des Objekts im Speicher enthält,
    • – body.skip, zeigt an, wie viele Bytes von der aktuellen Warteposition bis zum Beginn der gültigen RTP-Nutzlast zu überspringen sind, wenn überhaupt,
    • – body.length, zeigt die Länge der RTP-Nutzlast an,
    • – header.length, zeigt die Anzahl von Bytes des RTP-Kopfabschnittfelds an, die für das aktuelle RTP-Paket zu verwenden ist.
  • Wenn die Richtungsdatei erzeugt ist, wird sie gespeichert, so dass sie einem bestimmten Objekt zugeordnet werden kann. Wie bei der Hinweisdatei, können mehrere Richtungsdateien einem Objekt zugeordnet werden, wenn mehrere Wege, wie beispielsweise verschiedene Pakettypen oder verschiedene Netzwertattribute für den gleichen Pakettyp, vorhanden sind, über welche das Objekt übertragen werden kann.
  • Eine Erweiterung dieser Tatsache erlaubt dem Streamer leicht eine Trick-Plag-Funktionalität durch Erzeugen von Richtungsdateien zu implementieren, die nur auf I-Rahmen oder nur auf jeden N-ten I-Rahmen zeigen, wobei N auf die Geschwindigkeit eines schnellen Vorlaufs bezogen ist, der durch die Richtungsdatei 45 spezifiziert wird.
  • Wenn eine korrespondierende RTP-Sitzung noch nicht aufgebaut oder eingerichtet ist, bleibt die Vorrichtung bereit, bis das auf dem Kernprozessor ablaufende RTPS einen SETUP-Befehl bereitstellt, der vom Endpunkt empfangen wird. Wenn das RTSP die SETUP-Nachricht empfängt, bestimmt es einen Nachschlagparametersatz, wie z. B. Quellen- und Ziel-IP-Adressen, Ports und das Transportprotokoll, von der SETUP-Nachricht und ordnet einen Verbindungstabelleneintrag für diese Sitzung in einem inhaltsadressierbaren Speicher CAM zu, der dem Hardwarebeschleuniger zugeordnet ist. Das Gültigkeitsbit wird unverzüglich für die RTP-Sitzung im CAM gesetzt. Dann erwartet das RTSP eine nachfolgende PLAY-Anforderung vom assoziierten Steuerungspunkt. Die PLAY-Nachricht kann einen Zeitbereich für den Strom zur Wiedergabe enthalten.
  • An diesem Punkt kann die Sitzung als eingerichtet betrachtet werden und der Netzwerkbeschleuniger und der Verkehrsmanager sind bereit, Daten zu liefern. Der Verkehrsmanager weist zwei zugeordnete Warteschlangen auf, die für jede RTP-Sitzung verfügbar sind, weist eine Objektwarteschlange auf, die zum Übertragen von Daten vom systemeigenen Medienobjekt verwendet wird, und weist eine Kopfabschnittwarteschlange auf, die zur Übertragung des RTP-Kopfabschnitts verwendet wird, der aus den Richtungsdateien gelesen wird. Für jedes zu senden de RTP-Paket benutzt der Verkehrsmanager die Felder der Richtungsdatei, um den RTP-Kopfabschnitt und die Nutzlast zu extrahieren und legt die resultierenden Pakete zeitlich fest. Der Verkehrsmanager sendet die Pakete dann zum Netzwerkbeschleuniger.
  • Der Netzwerkbeschleunigerbetrieb umfasst die Schritte:
    • – Addieren eines Offsets, der durch den Zentralprozessor bestimmt und als ein Feld in dem CAM-Verbindungstabelleneintrag für die zugeordnete Übertragung gespeichert wird, zu dem Sequenznummerfeld des RTP-Kopfabschnitts des ausgehenden Pakets. Dies ist vorteilhaft, um eine Zufalls-ISS bereitzustellen, wie sie in RFC 3550 spezifiziert wird.
    • – Einstellen des ausgehenden Zeitstempels auf eine entsprechende Weise. Dies ist vorteilhaft, um eine Zufalls-IST bereitzustellen, wie sie in RFC 3550 spezifiziert wird,
    • – Erstellen und Anfügen (z. B. Voranstellen) eines Schicht-Drei- und eines Schicht-Vier-Kopfabschnitts an das ausgehende Paket, und
    • – Senden des ausgehenden Pakets an den MAC/PHY-Block.
  • Dieses Verfahren ermöglicht es, das Medienobjekt übertragen, ohne dass der Netzwerkbeschleuniger irgendein Wissen über das systemeigene Medienobjektformat hat. Da die Richtungsdatei vorzugsweise durch eine Software erzeugt wird, welche auf einem Zentralprozessor abläuft, können ausgehende Pakettypen leicht durch Software angepasst werden. Zudem trägt dieses Verfahren dazu bei, dass es möglich ist, wiederholende Datenpipelinefunktionen der Streaming-Vorrichtung vom Steuerprozessor an den mehr hardwareorientierten Netzwerkbeschleuniger zu übertragen. Diese wiederholenden Datenpipelinfunktionen, die rechnertechnisch nicht komplex sind, sind gleichwohl von hoher zeitlicher Priorität. Die Erfindung unterstützt diese Funktionen im Netz- Werkbeschleuniger optimal und reserviert die Kapazität und Verarbeitungszeit des Zentralprozessors für steuerungsorientierte, weniger häufige Anforderungen, die von der rechnertechnischen Komplexität profitieren und etwas schwierig mit den zeitlichen Anforderungen der Datenpipelinefunktionen der Streaming-Verbindung abzustimmen sind.
  • In Übereinstimmung mit der Tatsache, dass der Netzwerkbeschleuniger nur wenig oder kein Wissen über das Medienobjektformat benötigt, um die Datenpakete unter Verwendung der Richtungsdatei zu behandeln, wird vorgezogen, dass die Richtungsinformationen vielmehr in einer Datei als in einer Spur enthalten sind. Auf diese Weise ist es nicht erforderlich, dass der Server weiß, wie die Richtungsinformation für ein bestimmtes ausgehendes Paket oder einen Block von Paketen extrahiert wird.
  • Es sei angenommen, dass wenn die Richtungsdatei 45 erzeugt ist, das Objekt bereit ist, unter Verwendung der Zeiger- und Zählwerte des allgemeinen Kopfabschnitts und des Blockkopfabschnitts, die nun erzeugt sind, für einen Streaming-Vorgang beliebig oft angefordert zu werden. Der Streamer benötigt eine Möglichkeit, um auf die Richtungsinformation zuzugreifen und diese zu sortieren, was durch die Verwendung der beschriebenen Zeiger und Zähler komfortabel möglich ist. Ein zusätzlicher Vorteil wird dadurch erzielt, dass die ausgegebene Streaming-Richtungsdatei 45 nicht zum Endpunkt übertragen werden muss, welcher die Information nicht benötigt, die in Verbindung mit der Ausgabe der Streaming-Vorrichtung verwendet wird, welche das Paket oder den Block von Paketen zum Endpunkt sendet.
  • Es ist ein Aspekt der Erfindung, die Implementierung einer gesamten RTSP/RTP-Lösung durch Bereitstellung einer hybriden Hardware- und Softwarelösung zu verbessern, anstatt nur eine Hardwarelösung oder nur eine Softwarelösung bereitzustellen. Eine beliebige ausschließliche Hardwarelösung wäre ziemlich kompliziert, wenn sie für alle Steuersituationsszenarien zur Verfügung gestellt werden müsste. Im Gegensatz dazu würde eine beliebige ausschließliche Softwarelösung, die einen Prozessor und einen Code aufweist, die in der Lage ist, solche Datenübertragungen zu handhaben, nicht vollständig ausgenutzt werden. Für die meisten Funktionen werden, nachdem der Strom in Gang gesetzt ist, viele der Funktionen zur fortlaufenden Behandlung von nachfolgenden Paketen für einen vorgegebenen Strom unter Verwendung der Funktionen, die wiederholend sind und keine rechnertechnische Leistung erfordern, auf die gleiche Weise wie bei einem vorherigen Paket behandelt.
  • Die vorliegende Erfindung ist Teil einer Hybridlösung, wobei Steuerprozesse im Wesentlichen durch eine Steuereinheit bzw. einen Steuerschaltkreis aufgebaut und durchgeführt werden, die bzw. der ein potentiell komplexes und geeignetes Softwareprogramm abarbeiten kann, aber einfach Faktoren, Werte und Zeiger aufbaut, die es einem Netzwerkbeschleuniger ermöglichen, der vorzugsweise kein reines Hardwarebauelement ist, den Streaming-Vorgang fortzusetzen, den der Steuerschaltkreis aufgebaut hat, während die Verbindung aktiv ist.
  • Bezugnehmend auf 5 ist die Erfindung in einer vorteilhaften Ausführungsform in ein Datenmanipulationssystem eingebunden, das ein Plattenarraysteuerbauelement aufweist. Dieses Bauelement kann ein Speichermanagement durchführen und digitale Medienapplikationen einer Verbraucherelektronik oder andere Applikationen mit ähnlichen Eigenschaften zuführen, wie beispielsweise Kommunikations- und Telekonferenzen. Bei einer Unterhaltungsanwendung stellt das Bauelement eine Schnittstelle zwischen einem Heimnetzwerk und einem Bereich eines Datenspeicherbauelements bereit, das beispielhaft durch Festplattenlaufwerke (HDDs) zum Speichern von digitalen Medien, wie beispielsweise Audio, Video, Bilder, dargestellt ist.
  • Das Bauelement stellt vorzugsweise einen integrierten 10/100/100-Ethernet-MAC-Port zur Bereitstellung der Schnittstellenfähigkeit zum Heimnetzwerk oder einem anderen lokalen Netzwerk (LAN) zur Verfügung. Ein peripherer USB-2.0-Anschlussport wird in vorteilhafter Weise als Vernetzungsmöglichkeit von Medieneingabegeräten, wie einer Flashkarte, oder als Vernetzungsmöglichkeit von drahtlosen Heimnetzwerken über das Hinzufügen eines externen drahtlosen LAN-Adapters bereitgestellt.
  • Das bevorzugte Datenmanipulierungssystem wendet eine Anzahl von Schichten und Funktionen für geteilte Hochleistungszugriffe auf Medienarchive über eine Beschleunigungsmaschine für ein hohes Schichtprotokoll zur IP/TCP- und IP/UDP-Verarbeitung und einen sitzungsbezogenen Verkehrsmanager an. Der sitzungsbezogene Verkehrsmanager arbeitet als Zentralprozessor, der zusätzlich zum Managen des RTP-Streamings, das hier behandelt wird, eine Zuordnung von geteilten Ressourcen, wie beispielsweise Netzwerkbandbreite, Speicherbandbreite und Diskbereichbandbreite, entsprechend dem Typ der aktiven Mediensitzung freigibt. Eine Videositzung erhält beispielsweise mehr Ressourcen als eine Bildbrowsingsitzung. Des Weiteren wird die Bandbreite als garantierte Bandbreite für eine zeitkritische Mediensitzung zugeordnet oder als bestmögliche Bandbreite für nicht zeitkritische Anwendung zugeordnet, wie beispielsweise ein Medienarchivvolumenzugriff oder Multi-PC-Backup-Anwendungen.
  • Das Datenmanipulierungssystem umfasst Hochleistungs-Streaming mit einem zugeordneten redundanten Bereich von unabhängigen Platten (RAID). Der Streaming-RAID-Block kann für eine fehlergeschützte Redundanz ausgebildet sein und schützt die im Archiv gespeicherten Medien gegen den Ausfall einer beliebigen einzelnen HDD. Die HDDs können serielle ATA(SATA)-Disks sein, hier umfasst das System beispielsweise acht SATA-Disks mit einer Kapazität, um bis zu 64 gleichzeitige bidirektionale Ströme über einen Verkehrsmanager/Verkehrsverwalterblock zu bearbeiten.
  • Das Datenmanipulierungssystem in 7 ist hinsichtlich der Erfindung dargestellt und wird nur in Bezug auf die Erfindung allgemein beschrieben. Es gibt zwei separate Datenpfade innerhalb des Gerätes, nämliche den Empfangspfad und den Sendepfad. Der „Empfangspad" berücksichtigt die Richtung, durch die Verkehr von einem anderen externen Gerät zum System fließt, und der „Sendepfad" entspricht der entgegengesetzten Richtung des Datenflusses, dessen Pfad an einem bestimmten Punkt von einer Quelle in Richtung eines Ziels entsprechend dem Kontext eines vorgegebenen Stroms führt.
  • Der Prozessor (ULP) für eine hohe Schicht ist in bidirektionaler Datenverbindung entweder mit einem Gigabit-Ethernet-Steuerschaltkreis (GEC) oder dem peripheren Verkehrssteuerschaltkreis (PTC) gekoppelt. Der PTC bildet direkt eine Schnittstelle zum Verkehrsmanager/Verkehrverwalter (TMA) für nicht paketbasierte Übertragungen. Die Paketübertragungen werden wie nachfolgend erläutert durchgeführt.
  • Im Empfangspfad empfängt entweder der GEC- oder PTC-Block typischerweise die Ethernetpakete von einer physikalischen Schnittstelle, beispielsweise zu oder von einem größeren Netzwerk. Der GEC führt verschiedene ethernetprotokollbezogene Überprüfungen, einschließlich Paketintegrität, Gruppenrufadressenfilterung usw. durch. Die Pakete werden für eine weitere Verarbeitung an den ULP-Block weitergeleitet.
  • Der ULP analysiert die Kopfabschnittfelder der Schichten 2, 3 und 4, welche extrahiert werden, um eine Adresse zu bilden. Ein Verbindungsnachschlagvorgang wird dann basierend auf der Adresse durchgeführt. Unter Verwendung des Nachschlageergebnisses trifft der ULP eine Entscheidung, wohin das empfangene Paket gesendet wird. Ein ankom mendes Paket von einer bereits aufgebauten Verbindung wird mit einer vorbestimmten Warteschlangen-ID (QID) für Verkehrseinreihungsverwendungszwecke markiert, welche durch den TMA verwendet werden. Ein Paket von einer unbekannten Verbindung erfordert weitere Nachforschungen durch einen Applikationsprozessor (AAP). Das Paket wird mit einer speziellen QID markiert und zum AAP geroutet. Das endgültige Ziel eines ankommenden Pakets nach dem AAP kann entweder die Festplatten zum Speichern, wenn es Medieninhalte trägt, oder der AAP für weitere Untersuchungen sein, wenn es Steuernachrichten trägt oder das Paket durch den AAP nicht erkannt werden kann, was potentiell zum Einrichten einer neuen Warteschlangen-ID führt. Bei einer beliebigen der oben genannten Bedingungen wird das Paket zum TMA-Block gesendet.
  • Der TMA speichert den ankommenden Verkehr in dem geteilten Speicher. Für den Fall einer Medienobjektübertragung werden die ankommenden Objektdaten im Speicher gespeichert und zur Speicherung auf einer Disk zu einem RAID-Decoder- und Codierer(RDE)-Block übertragen. Der TMA verwaltet den Speicherprozess durch Bereitstellen der passenden Steuerinformation an den RDE. Der Steuerverkehr, der für eine AAP-Überprüfung bestimmt ist, wird ebenfalls im geteilten Speicher gespeichert und dem AAP wird ein Zugriff erteilt, um die Pakete im Speicher zu lesen. Der AAP benutzt diesen Mechanismus auch, um beliebige der Pakete, die außerhalb der Reihenfolge empfangen werden, neu zu ordnen. Ein Teil des geteilten Speichers und der Disks enthalten Programmanweisungen und Daten für den AAP. Der TMA verwaltet den Zugriff auf den Speicher und die Disk durch Übertragen von Steuerinformationen von der Disk zum Speicher und vom Speicher zur Disk. Der TMA gibt den AAP auch zum Einfügen von Daten und zum Extrahieren von Daten in bzw. aus einem existierenden Paketstrom frei.
  • Im Sendepfad verwaltet der TMA die wiederholenden Objektanforderungen von der Disk, die als zum Senden über den Applikationsprozessor oder die Netzwerkschnittstelle erforderlich bestimmt werden. Auf den Empfang einer Medienwiedergabeanforderung vom Applikationsprozessor empfängt der TMA die von den Disks übertragenen Daten über die MDC- und RDE-Blöcke und speichert sie im Speicher. Der TMA legt dann den zeitlichen Ablauf der Daten zum ULP-Block entsprechend der erforderlichen Bandbreite und dem Medientyp fest. Der ULP schließt die Daten für jedes ausgehende Paket in die Ethernet- und L3/L4-Kopfabschnitte ein. Die Pakete werden dann basierend auf dem spezifizierten Ziel-Port entweder zum GEC- oder PTC-Block gesendet.
  • Für ankommende Pakete auf dem Empfangsdatenpfad kann ein Verbindungsnachschlagfunktionsteil des Netzwerkbeschleunigers eine Adressenbildung, einen CAM-Tabellennachschlag und Verbindungstabellennachschlagfunktionsblöcke umfassen. Die CAM-Nachschlagadresse wird in Teilen als ein Ergebnis einer Information gebildet, die aus dem ankommenden Paketkopfabschnitt extrahiert wird. Die bestimmten der zu extrahierenden Kopfabschnittfelder sind vom verwendeten Verkehrsprotokoll abhängig. Die zu bildende Adresse hat eine eindeutige Verbindung zu repräsentieren. Für den populärsten Internetverkehr, der beispielsweise über IP-V4- und TCP/UDP-Protokolle ausgeführt wird, definieren eine Quellen-IP-Adresse, eine Ziel-IP-Adresse, eine TCP/UDP-Quellenportnummer, eine TCP/UDP-Zielportnummer und ein Protokolltyp, welche als „fünf-Tupel" des Paketkopfabschnitts bezeichnet werden, eine eindeutige Verbindung. Andere Felder können verwendet werden, um eine Verbindung zu bestimmen, wenn ein Paket von einem anderen Verkehrsprotokolltyp ist, wie beispielsweise einem IP-V6. Geeignete Steuerungen wie Flags, Identifizierungscodes können referenziert werden, wenn mehrere Protokolle unterstützt werden, um aus dem System ein hierarchisches „protokollbewußtes" zu machen. Der Prozess kann beispielsweise in drei Stufen aufgeteilt werden, wobei jede Stufe mit ei nem Niveau eines unterstützten Protokolls korrespondiert. Eine erste Stufe kann die Versionsnummer des L3-Protokolls in einem Feld überprüfen, das während des Kopfabschnittanalyseprozesses extrahiert und in einem Informationspuffereintrag für ein ankommendes Paket als Schritt im Adressenbildungsvorgang gespeichert wird. Für die zweite und dritte Stufe im Adressenbildungsprozess wird eine zusammengesetzte Hardwaretabelle bereitgestellt. Die Anzahl von Tabelleneinträgen in jeder Stufe ist von der Stufe, in welcher sich die Tabelle befindet, und der Anzahl von verschiedenen Protokollen abhängig, die in jeder Stufe unterstützt werden. Jeder Tabelleneintrag besteht immer aus einem inhaltsadressierbaren Speicher(CAM)-Eintrag und einem Positionsnummerregister. Jedes Positionsregister besteht immer aus einem Paar von Offsetumfangsfeldern. Jeder CAM-Eintrag speichert den spezifischen Protokollwert für das korrespondierende Positionsregister. Ein Offset spezifiziert die Anzahl von Bytes, welche vom Beginn des Paketkopfabschnitts bis zum zu extrahierenden Feld zu überspringen sind. Das Umfangsfeld spezifiziert die Anzahl von Halbbytes, die zu extrahieren sind. Die gleiche Adresse wird verwendet, um auf das CAM-Feld und das Positionsregister zuzugreifen.
  • Für ausgehende Paketausgaben verwendet die Erfindung Richtungsdateien, wie beschrieben, die in einem Speicher gebildet werden, auf den der Zentralprozessor an jedem Punkt der Konfiguration zugreifen kann.
  • Die Erfindung wurde in Verbindung mit beispielhaften Ausführungsformen offenbart, es sollte aber zur Bestimmung des Schutzumgangs, für den Monopolrechte beansprucht werden, auf die beigefügten Ansprüche anstatt auf die Beschreibung der Ausführungsbeispiele Bezug genommen werden.
  • Zusammenfassung
  • Eine hardwarebeschleunigte Streaming-Anordnung, insbesondere für ein RTP-Echtzeitprotokoll-Streaming, verwendet eine Richtungsdatei, welche Zeiger, Kopfabschnittlänge und Offsets für einen über ein netzwerkbeschleunigtes Streaming-System zu sendenden Block mit einem oder mehreren Datenpaketen bestimmt. Die Richtungsdatei wird durch einen Steuerprozessor eingerichtet, der beispielsweise im Hintergrund arbeitet, und gespeichert, um Informationen bereitzustellen, welche es ermöglichen, gewisse Informationen zu bestimmen, welche Kopfabschnittgröße und Zeiger auf RTP-Nutzlasten und andere Daten umfassen, ohne während der Ausgabe von Daten bezogen auf den Medientyp oder das betroffene Protokoll eine Analyse zu erfordern. Dies befreit den Steuerprozessor von Funktionen, die anderenfalls Rechenleistung binden würden, und ermöglicht es, den Ausgabeprozess auf eine wiederholende Art fortzuführen, insbesondere dadurch, dass Funktionen soweit auf Hardwareelemente verlagert werden, um die Geschwindigkeit zu erhöhen und um Rechenleistung des Steuerprozessors für Steuerfunktionen zu reservieren, die komplexer sind, aber selten und/oder nicht so zeitkritisch für das Streaming in Echtzeit sind.

Claims (18)

  1. Streaming-Vorrichtung zum Übertragen von Datenpaketen von mindestens einer Quelle von Datenpaketen zu mindestens einem Ziel für die Datenpakete, mit: – einem Netzwerkbeschleuniger in Datenverbindung mit der Quelle der Datenpakete und mit dem Ziel, – einem Steuerprozessor, der derart ausgebildet ist, dass er ein Streamen der Datenpakete von der Quelle zu dem Ziel steuert, – wobei der Steuerprozessor dazu programmiert ist, einen Satz von Parameterwerten bereitzustellen, die von dem Steuerprozessor zu dem Netzwerkbeschleuniger mindestens während eines vorbestimmten Schritts des Streamens der Datenpakete von der Quelle zu dem Ziel übertragen werden, und – wobei der Netzwerkbeschleuniger dazu ausgebildet ist, die Datenpakete von der Quelle zu dem Ziel im Anschluss an den vorbestimmten Schritt als eine Funktion der Parameterwerte und im Wesentlichen unabhängig von dem Steuerprozessor zu streamen.
  2. Streaming-Vorrichtung nach Anspruch 1, wobei die Quelle und/oder das Ziel einen Client umfassen, der mit dem Steuerprozessor über ein Datenkommunikationsnetzwerk in Verbindung steht, mit dem die Quelle und der Netzwerkbeschleuniger gekoppelt sind.
  3. Streaming-Vorrichtung nach Anspruch 1, wobei die durch den Steuerprozessor bereitgestellten Parameterwerte Adressinformationen umfassen, die mindestens zwei Clients identifizieren, die mit dem Steuerprozessor und dem Netzwerkbeschleuniger über ein Kommunikationsnetzwerk in Datenverbindung stehen.
  4. Streaming-Vorrichtung nach Anspruch 3, wobei die Parameterwerte durch den Steuerprozessor als Funktion eines Request-Signals bereitgestellt werden, das durch die Quelle oder das Ziel initiiert wird das zumindest Adressinformationen für die Quelle und das Ziel umfasst.
  5. Streaming-Vorrichtung nach Anspruch 3, wobei die Parameterwerte in einer Richtungsdatei zur Verfügung gestellt werden, die durch den Steuerprozessor verbreitet wird, und wobei weiter ein Speicher vorgesehen ist, der mit dem Prozessor gekoppelt ist und der eine Mehrzahl von Richtungsdateien umfasst, die einer Mehrzahl von konkurrierenden Streaming-Operationen entsprechen.
  6. Streaming-Vorrichtung nach Anspruch 4, wobei die Parameterwerte einen Identifikationscode, einen Paketzähler, eine Kopfabschnittblockgröße und einen Positionszeiger oder einen Zählerwert umfassen.
  7. Streaming-Vorrichtung nach Anspruch 3, wobei die Parameterwerte durch den Steuerprozessor als Funktion eines Request-Signals bereitgestellt werden und durch den Steuerprozessor zu dem Netzwerkbeschleuniger als ein generalisierter Kopfabschnitt übertragen werden, der einen Identifikationscode für die Datenpakete umfasst.
  8. Streaming-Vorrichtung nach Anspruch 7, wobei der Netzwerkbeschleuniger dazu ausgebildet ist, den generalisierten Kopf abschnitt in Pakete, die zu dem Ziel übertragen werden, einzufügen.
  9. Streaming-Vorrichtung nach Anspruch 8, wobei der Netzwerkbeschleuniger dazu ausgebildet ist, Steuerinformationen in den generalisierten Kopfabschnitt einzufügen, der zu dem Ziel übertragen wird, wenn das Streamen der Pakete fortschreitet.
  10. Streaming-Vorrichtung nach Anspruch 9, wobei der Netzwerkbeschleuniger dazu ausgebildet ist, Paketdatenzähler einzufügen, durch die das Ziel die empfangenen Pakete ordnen kann.
  11. Streaming-Vorrichtung nach Anspruch 1, – wobei der Steuerprozessor, die Quelle und/oder das Ziel und der Netzwerkbeschleuniger Präsentationssteuernachrichten, individuelle Sitzungssteuernachrichten und Echtzeit-Streaming-Pakete übertragen und – wobei der Steuerprozessor die Steuernachrichten verarbeitet, wohingegen der Netzwerkbeschleuniger die Echtzeit-Streaming-Pakete verarbeitet.
  12. Streaming-Vorrichtung nach Anspruch 11, wobei der Steuerprozessor das Streamen durch den Netzwerkbeschleuniger durch folgende Schritte steuert: – SETUP, wobei Kommunikationsressourcen einer Streaming-Operation zugeordnet werden, – PLAY und/oder RECORD, um eine Streaming-Operation in mindestens einer Lichtung zwischen der mindestens einen Quelle und dem mindestens einen Ziel zu beginnen, und – PAUSE und/oder TEARDOWN, wobei eine zuvor begonnene Streaming-Operation unterbrochen wird, wobei die Zu ordnung zu den Ressourcen für PAUSE beibehalten wird und die Ressourcen für TEARDOWN freigegeben werden.
  13. Streaming-Vorrichtung nach Anspruch 12, wobei der Steuerprozessor dazu ausgebildet ist, gemäß dem RTSP-Protokoll für die Präsentationssteuernachrichten und gemäß dem RTCP-Protokoll für die individuellen Sitzungssteuernachrichten zu arbeiten und wobei die Echtzeit-Streaming-Pakete mit dem RTP-Protokoll unter Verwendung des TCP- und/oder des UDP-Protokolls konform sind.
  14. Verfahren zum Streamen von Inhalten im Wesentlichen in Echtzeit mit den Schritten: – Bereitstellen von Dateninhalt, der in Pakete aufgeteilt ist, mit zugehörigen Kopfabschnittsinformationen, durch die der in Pakete aufgeteilte Dateninhalt in einer Quelle und/oder in einem Ziel hinsichtlich des Inhalts verarbeitet wird, – Initiieren einer Streaming-Operation, Adressieren einer Quelle und/oder eines Ziels für die Streaming-Operation und Bewirken einer Pause und/oder eines Stopps der Streaming-Operation als Funktion von programmierten Operationen eines Steuerprozessors, der in Datenverbindung mit der Quelle und/oder dem Ziel steht, – wobei der Steuerprozessor dazu ausgebildet ist, gemäß den programmierten Operationen zu arbeiten, um eine Richtungsdatei bereitzustellen, die Informationen enthält, die zumindest temporär während der Streaming-Operation beibehalten werden, und – nach dem Initiieren der Streaming-Operation, Weiterführen der Streaming-Operationsinformationen durch einen Netzwerkbeschleuniger, der Informationen verarbeitet, die durch die Richtungsdatei zur Verfügung gestellt werden und die verarbeitet werden, während die Streaming-Operation fort dauert.
  15. Verfahren nach Anspruch 14, wobei der Netzwerkbeschleuniger Informationen aus der Richtungsdatei in Paketkopfabschnitte einfügt, die während der Streaming-Operation übertragen werden.
  16. Verfahren nach Anspruch 15, wobei der Netzwerkbeschleuniger in die Paketkopfabschnitte Adressinformationen und Paketdatenzähler und/oder Paketdatenzeiger einfügt.
  17. Verfahren nach Anspruch 16, weiter umfassend ein Ändern der Streaming-Operation durch programmierte Operationen des Steuerprozessors nach dem Initiieren der Streaming-Operation.
  18. Verfahren nach Anspruch 14, weiter aufweisend ein Bereitstellen und ein Aufrechterhalten einer Mehrzahl von Richtungsdateien durch den Steuerprozessor, wobei die Richtungsdateien jeweils eine zugehörige, konkurrierend ablaufende Streaming-Operation betreffen.
DE112006002677T 2005-10-07 2006-10-06 Verfahren und Vorrichtung für RTP-Ausgabe-Streaming unter Verwendung von komplementären Richtungsdateien Withdrawn DE112006002677T5 (de)

Applications Claiming Priority (13)

Application Number Priority Date Filing Date Title
US72506005P 2005-10-07 2005-10-07
US72446205P 2005-10-07 2005-10-07
US72457305P 2005-10-07 2005-10-07
US72446405P 2005-10-07 2005-10-07
US72472205P 2005-10-07 2005-10-07
US72446305P 2005-10-07 2005-10-07
US60/725,060 2005-10-07
US60/724,722 2005-10-07
US60/724,573 2005-10-07
US60/724,462 2005-10-07
US60/724,464 2005-10-07
US60/724,463 2005-10-07
PCT/US2006/039224 WO2007044563A1 (en) 2005-10-07 2006-10-06 Method and apparatus for rtp egress streaming using complementary directing file

Publications (1)

Publication Number Publication Date
DE112006002677T5 true DE112006002677T5 (de) 2008-11-13

Family

ID=37719120

Family Applications (2)

Application Number Title Priority Date Filing Date
DE112006002677T Withdrawn DE112006002677T5 (de) 2005-10-07 2006-10-06 Verfahren und Vorrichtung für RTP-Ausgabe-Streaming unter Verwendung von komplementären Richtungsdateien
DE112006002644T Withdrawn DE112006002644T5 (de) 2005-10-07 2006-10-06 Mediendatenverarbeitung unter Verwendung von charakteristischen Elementen für Streaming- und Steuerprozesse

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE112006002644T Withdrawn DE112006002644T5 (de) 2005-10-07 2006-10-06 Mediendatenverarbeitung unter Verwendung von charakteristischen Elementen für Streaming- und Steuerprozesse

Country Status (6)

Country Link
US (2) US20080285571A1 (de)
JP (2) JP2009512279A (de)
KR (2) KR100926007B1 (de)
DE (2) DE112006002677T5 (de)
GB (2) GB2448799A (de)
WO (2) WO2007044563A1 (de)

Families Citing this family (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101026616B (zh) * 2006-02-18 2013-01-09 华为技术有限公司 基于ip多媒体子系统的交互式媒体会话建立方法
US8539065B2 (en) * 2006-07-26 2013-09-17 Cisco Technology, Inc. Method and apparatus for providing access to real time control protocol information for improved media quality control
US8014322B2 (en) * 2007-02-26 2011-09-06 Cisco, Technology, Inc. Diagnostic tool for troubleshooting multimedia streaming applications
US20090135724A1 (en) * 2007-11-27 2009-05-28 Tellabs Operations, Inc. Method and apparatus of RTP control protocol (RTCP) processing in real-time transport protocol (RTP) intermediate systems
US20090135735A1 (en) * 2007-11-27 2009-05-28 Tellabs Operations, Inc. Method and apparatus of RTP control protocol (RTCP) processing in real-time transport protocol (RTP) intermediate systems
US8904031B2 (en) 2007-12-31 2014-12-02 Genesys Telecommunications Laboratories, Inc. Federated uptake throttling
US8949470B2 (en) * 2007-12-31 2015-02-03 Genesys Telecommunications Laboratories, Inc. Federated access
US9003051B2 (en) * 2008-04-11 2015-04-07 Mobitv, Inc. Content server media stream management
US7886073B2 (en) 2008-08-08 2011-02-08 Cisco Technology, Inc. Systems and methods of reducing media stream delay
US8015310B2 (en) 2008-08-08 2011-09-06 Cisco Technology, Inc. Systems and methods of adaptive playout of delayed media streams
US7969974B2 (en) * 2008-10-15 2011-06-28 Cisco Technology, Inc. System and method for providing a multipath switchover between redundant streams
US8239739B2 (en) 2009-02-03 2012-08-07 Cisco Technology, Inc. Systems and methods of deferred error recovery
US8711771B2 (en) * 2009-03-03 2014-04-29 Qualcomm Incorporated Scalable header extension
US20120144056A1 (en) * 2009-08-12 2012-06-07 Nederlandse Organisatie Voor Toegepast- Natuurwetenschappelijk Onderzoek Tno Dynamic RTCP Relay
US20110110382A1 (en) * 2009-11-10 2011-05-12 Cisco Technology, Inc., A Corporation Of California Distribution of Packets Among PortChannel Groups of PortChannel Links
FR2961651B1 (fr) * 2010-06-22 2012-07-20 Alcatel Lucent Procede et dispositif de traitement de flux media entre une pluralite de terminaux media et une unite de traitement a travers un reseau de communication
US8706889B2 (en) * 2010-09-10 2014-04-22 International Business Machines Corporation Mitigating connection identifier collisions in a communication network
CN102624752B (zh) * 2011-01-26 2014-06-18 天脉聚源(北京)传媒科技有限公司 一种m3u8直播流防盗链方法和系统
US9769231B1 (en) * 2011-04-01 2017-09-19 Arris Enterprises Llc QoS for adaptable HTTP video
DE102011103740A1 (de) 2011-05-31 2012-12-06 Smartrac Ip B.V. Verfahren und Anordnung zum Bereitstellen und Verwalten von mit RFID-Datenträgern verknüpften Informationen in einem Netzwerk
CN102968422B (zh) * 2011-08-31 2015-06-17 中国航天科工集团第二研究院七0六所 流数据存储控制系统及其方法
US9176912B2 (en) * 2011-09-07 2015-11-03 Altera Corporation Processor to message-based network interface using speculative techniques
WO2013100986A1 (en) * 2011-12-28 2013-07-04 Intel Corporation Systems and methods for integrated metadata insertion in a video encoding system
US20140112636A1 (en) * 2012-10-19 2014-04-24 Arcsoft Hangzhou Co., Ltd. Video Playback System and Related Method of Sharing Video from a Source Device on a Wireless Display
US9148379B1 (en) * 2013-01-09 2015-09-29 “Intermind” société à responsabilité limitée Method and system for prioritizing audio traffic in IP networks
US10161993B2 (en) 2013-02-21 2018-12-25 Advantest Corporation Tester with acceleration on memory and acceleration for automatic pattern generation within a FPGA block
US11009550B2 (en) 2013-02-21 2021-05-18 Advantest Corporation Test architecture with an FPGA based test board to simulate a DUT or end-point
US10162007B2 (en) * 2013-02-21 2018-12-25 Advantest Corporation Test architecture having multiple FPGA based hardware accelerator blocks for testing multiple DUTs independently
US9952276B2 (en) 2013-02-21 2018-04-24 Advantest Corporation Tester with mixed protocol engine in a FPGA block
CN103354522B (zh) * 2013-06-28 2016-08-10 华为技术有限公司 一种多级流表查找方法和装置
US9235564B2 (en) 2013-07-19 2016-01-12 International Business Machines Corporation Offloading projection of fixed and variable length database columns
US9275168B2 (en) 2013-07-19 2016-03-01 International Business Machines Corporation Hardware projection of fixed and variable length columns of database tables
JP6268066B2 (ja) * 2013-09-20 2018-01-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 送信方法、受信方法、送信装置及び受信装置
EP3917112B1 (de) 2013-11-27 2022-10-05 Telefonaktiebolaget LM Ericsson (publ) Hybrides rtp-nutzlastformat
US10523730B2 (en) * 2014-03-12 2019-12-31 Infinesse Corporation Real-time transport protocol (RTP) media conference server routing engine
US10015048B2 (en) 2014-12-27 2018-07-03 Intel Corporation Programmable protocol parser for NIC classification and queue assignments
US9912774B2 (en) * 2015-12-22 2018-03-06 Intel Corporation Accelerated network packet processing
US10735438B2 (en) * 2016-01-06 2020-08-04 New York University System, method and computer-accessible medium for network intrusion detection
US10067809B2 (en) 2016-04-20 2018-09-04 International Business Machines Corporation System and method for batch transport using hardware accelerators
US10970133B2 (en) 2016-04-20 2021-04-06 International Business Machines Corporation System and method for hardware acceleration for operator parallelization with streams
KR102610480B1 (ko) * 2016-09-26 2023-12-06 삼성전자 주식회사 스트리밍 서비스를 제공하는 방법 및 장치
US10419366B1 (en) 2017-01-31 2019-09-17 Barefoot Networks, Inc. Mechanism for communicating to remote control plane from forwarding element
CN106940673A (zh) * 2017-03-15 2017-07-11 郑州云海信息技术有限公司 一种监测项间隔智能调整方法及系统
US10694006B1 (en) 2017-04-23 2020-06-23 Barefoot Networks, Inc. Generation of descriptive data for packet fields
US10826840B1 (en) 2017-07-23 2020-11-03 Barefoot Networks, Inc. Multiple copies of stateful tables
US10594630B1 (en) 2017-09-28 2020-03-17 Barefoot Networks, Inc. Expansion of packet data within processing pipeline
WO2020242443A1 (en) * 2018-05-24 2020-12-03 SmartHome Ventures, LLC Protocol conversion of a video stream
US10976361B2 (en) 2018-12-20 2021-04-13 Advantest Corporation Automated test equipment (ATE) support framework for solid state device (SSD) odd sector sizes and protection modes
CN111510394B (zh) * 2019-01-31 2022-04-12 华为技术有限公司 一种报文调度方法、相关设备及计算机存储介质
US11137910B2 (en) 2019-03-04 2021-10-05 Advantest Corporation Fast address to sector number/offset translation to support odd sector size testing
US11237202B2 (en) 2019-03-12 2022-02-01 Advantest Corporation Non-standard sector size system support for SSD testing
US10884847B1 (en) 2019-08-20 2021-01-05 Advantest Corporation Fast parallel CRC determination to support SSD testing
US11706163B2 (en) * 2019-12-20 2023-07-18 The Board Of Trustees Of The University Of Illinois Accelerating distributed reinforcement learning with in-switch computing
US11601355B2 (en) * 2021-03-16 2023-03-07 Dell Products L.P. Contextual bandwidth management of audio/video conference
US20220303150A1 (en) * 2021-03-16 2022-09-22 Zoom Video Communications, Inc Systems and methods for video conference acceleration
KR20240065966A (ko) * 2022-11-07 2024-05-14 엑사비스 주식회사 효율적으로 데이터를 저장하는 네트워크 검사 방법 및 이를 수행하는 시스템

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6543053B1 (en) * 1996-11-27 2003-04-01 University Of Hong Kong Interactive video-on-demand system
US6173333B1 (en) * 1997-07-18 2001-01-09 Interprophet Corporation TCP/IP network accelerator system and method which identifies classes of packet traffic for predictable protocols
US6977930B1 (en) * 2000-02-14 2005-12-20 Cisco Technology, Inc. Pipelined packet switching and queuing architecture
US7032031B2 (en) * 2000-06-23 2006-04-18 Cloudshield Technologies, Inc. Edge adapter apparatus and method
US20020107971A1 (en) * 2000-11-07 2002-08-08 Bailey Brian W. Network transport accelerator
WO2002087235A1 (en) 2001-04-19 2002-10-31 Vividon, Inc. System for applying metric to multimedia files over network
US20040128342A1 (en) * 2002-12-31 2004-07-01 International Business Machines Corporation System and method for providing multi-modal interactive streaming media applications
US7701884B2 (en) * 2004-04-19 2010-04-20 Insors Integrated Communications Network communications bandwidth control

Also Published As

Publication number Publication date
US20080285571A1 (en) 2008-11-20
KR20080068691A (ko) 2008-07-23
KR100926007B1 (ko) 2009-11-11
GB2444675A (en) 2008-06-11
WO2007044562A1 (en) 2007-04-19
WO2007044563A1 (en) 2007-04-19
US20090147787A1 (en) 2009-06-11
GB0805653D0 (en) 2008-04-30
DE112006002644T5 (de) 2008-09-18
GB2448799A (en) 2008-10-29
JP2009512280A (ja) 2009-03-19
GB0805654D0 (en) 2008-04-30
KR20080068690A (ko) 2008-07-23
JP2009512279A (ja) 2009-03-19

Similar Documents

Publication Publication Date Title
DE112006002677T5 (de) Verfahren und Vorrichtung für RTP-Ausgabe-Streaming unter Verwendung von komplementären Richtungsdateien
DE69832247T2 (de) Auf einem verteilten Internet- Protokollen basierte Echtzeit- Multimedia- Datenströmungs- Architektur
US8499091B2 (en) Method and an apparatus for data recording and streaming
DE60110002T2 (de) System zur Übertragung von Streaming-Daten und Zwischenverstärker dafür
DE60103005T2 (de) Datenstrom in einer peer-to-peer Architektur
DE69925004T2 (de) Kommunikationsverwaltungssystem für computernetzwerkgestützte telefone
DE112012002159T5 (de) Kontextsensitive Client-Pufferschwellenwerte
DE69933281T2 (de) Verfahren und Vorrichtung zur Mediendatenübertragung
DE112012001770T5 (de) Auf Echtzeitverarbeitungsfähigkeit basierende Qualitätsanpassung
DE112011101911T5 (de) Fragmentierte Dateistruktur für die Ausgabe von Live-Medien-Streams
DE112006004258B4 (de) Serielle und parallele Verarbeitung von Daten unter Verwendung von Informationen über die Daten und Informationen über ein Streaming-Netz
DE112013002247T5 (de) Kombinierte Broadcast- und Unicast-Übermittlung
KR20080108568A (ko) 서버로부터 클라이언트로의 스트리밍
DE112011101908T5 (de) Qualitätseinstellung unter Verwendung eines fragmentierten Medienstroms
CN101352012A (zh) 使用不同元件对流进行媒体数据处理以及控制方法
DE60116341T2 (de) Kommunikationsverwaltungsystem für computernetzbasierte telefone
KR102137858B1 (ko) 송신 장치, 송신 방법, 수신 장치, 수신 방법 및 프로그램
DE10231941A1 (de) Datenpaketstruktur für direkt adressiertes Multicast-Protokoll
KR102176404B1 (ko) 통신 장치, 통신 데이터 생성 방법, 및 통신 데이터 처리 방법
CN1468002A (zh) 基于因特网的流媒体压缩、传输与存贮系统
DE10231958A1 (de) Direkt adressiertes Multicast-Protokoll
DE102005052207A1 (de) Verfahren zum Übertragen von einem Datenstrom von einer Datenquelle zu einer Datensenke sowie Datensenkengerät, Datenquellgerät und Gerät zur Durchführung des Verfahrens
EP3507987A1 (de) Verfahren zur übertragung von echtzeitbasierten digitalen videosignalen in netzwerken
Cranley et al. Quality of Service for Streamed Multimedia over the Internet
DE102005046382A1 (de) Verfahren, Kommunikationsanordnung und dezentrale Kommunikationseinrichtung zum Übermitteln von Multimedia-Datenströmen

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee

Effective date: 20110502