[go: up one dir, main page]

DE112006002644T5 - Mediendatenverarbeitung unter Verwendung von charakteristischen Elementen für Streaming- und Steuerprozesse - Google Patents

Mediendatenverarbeitung unter Verwendung von charakteristischen Elementen für Streaming- und Steuerprozesse Download PDF

Info

Publication number
DE112006002644T5
DE112006002644T5 DE112006002644T DE112006002644T DE112006002644T5 DE 112006002644 T5 DE112006002644 T5 DE 112006002644T5 DE 112006002644 T DE112006002644 T DE 112006002644T DE 112006002644 T DE112006002644 T DE 112006002644T DE 112006002644 T5 DE112006002644 T5 DE 112006002644T5
Authority
DE
Germany
Prior art keywords
data
content
packets
streaming
data packets
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
DE112006002644T
Other languages
English (en)
Inventor
Ambalavanar Arulambalam
Jian-Guo Chen
Hakan I. Pekcan
Kent E. Wires
Nevin C. 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 DE112006002644T5 publication Critical patent/DE112006002644T5/de
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/16Analogue secrecy systems; Analogue subscription systems
    • H04N7/173Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/102Gateways
    • H04L65/1023Media gateways
    • H04L65/103Media gateways in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/102Gateways
    • H04L65/1033Signalling gateways
    • H04L65/104Signalling gateways in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/75Media network packet handling
    • H04L65/752Media network packet handling adapting media to network capabilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/568Storing data temporarily at an intermediate stage, e.g. caching
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling 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/63Routing a service request depending on the request content or context
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238Interfacing 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/2383Channel coding or modulation of digital bit-stream, e.g. QPSK modulation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41Structure of client; Structure of client peripherals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41Structure of client; Structure of client peripherals
    • H04N21/4104Peripherals receiving signals from specially adapted client devices
    • H04N21/4135Peripherals receiving signals from specially adapted client devices external recorder
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing 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/438Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4381Recovering the multiplex stream from a specific network, e.g. recovering MPEG packets from ATM cells
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing 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/438Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4382Demodulation or channel decoding, e.g. QPSK demodulation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/643Communication protocols
    • H04N21/6437Real-time Transport Protocol [RTP]

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 mit Feldern, die einen Steuerwert, eine Ursprungsadresse, eine Zieladresse und/oder einen Nutzlasttyp repräsentieren, mit
– einem Kommunikationspfad zum Empfangen der Datenpakete von einem Server, wobei entlang des Kommunikationspfads mindestens ein Teil eines Inhalts der Datenpakete zu mindestens einem Client in Abhängigkeit von Verfahren übertragen wird, die teilweise von den Feldern der Datenpakete bestimmt werden,
– wobei die Verfahren mindestens zwei Alternativen umfassen, durch welche die Datenpakete zu dem mindestens einen Client auf mindestens zwei unterschiedliche Arten übertragbar sind,
– einem Steuerprozessor, der mit dem Kommunikationspfad gekoppelt ist, wobei der Steuerprozessor dazu ausgebildet ist, eines der Verfahren zu bestimmen, das auf die jeweiligen Alternativen anzuwenden ist,
– einem Netzwerkbeschleuniger mit einem Speicher, wobei der Steuerprozessor dazu ausgebildet ist, den Speicher des Netzwerkbeschleunigers mit Daten zu laden, welche die mindestens zwei Alternativen repräsentieren, durch welche die Datenpakete auf bestimmte Arten übertragen werden, und...

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 alle Anmeldungen hiermit ausdrücklich 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 Anwendungen, welche RTP-Streaming verwenden. Zudem ist die Erfindung allgemein für Paketdatenübertragungsapplikationen anwendbar, bei welchen Übertragungskopplungen zwischen Quellen und Zeilen gestartet, angehalten und von Zeit zu Zeit gemäß der Programmierung eines Steuerprozessors verändert werden.
  • 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. Erfindungsgemäß werden sich wiederholende Datenverarbeitungsübertragungsfunktionen, die vorzugsweise im Bezug auf eine Datenrate anspruchsvoll aber rechnertechnisch nicht komplex sind, wie beispielsweise wiederholtes Routen von Datenpaketen zu oder von Speicherelementen, die mit einem Netzwerk verbunden sind, getrennt von Funktionen behandelt, wie Steuerverarbeitungs- und Adressierschritte, die rechnertechnisch komplex aber auch sehr selten sind. In bevorzugter Ausgestaltung werden Beschleuniger, die Hardwareelemente umfassen, in Datenverbindung mit Steuerungsprozessoren und Datenspeicherbauelementen, die mit dem Netzwerk verbunden sind, bereitgestellt. Die Beschleuniger sind im Wesentlichen den Übertragungsfunktionen zugeordnet, wodurch eine hoher Datendurchsatz erzielt wird, während Prozessoren davon befreit werden, Steuerfunktionen gemäß der Programmierung zu behandeln, was zu einer anpassungsfähigen und optimierten Möglichkeit für die Änderung von Anforderungen führt.
  • Es ist allgemein vorteilhaft, potentiell verschiedene Geräte freizugeben, welche potentiell verschiedene Datenformate zur gegenseitigen Interaktion 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 Signalisierungstechni ken, Datenspeicherung und Datenwiedergewinnung, Kommunikationen usw. Standards werden typischerweise in mehreren 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 Speicherschritte sein. In einem Datenverarbeitungssystem, das mehrere Server und Engeräte aufweist, ist ein Teil der Rechenleistung auf Aktionen gerichtet, die einer Datenformatierung und Datenneuformatierung zugeordnet sind. Teil der Rechenleistung ist die Adressierung und das Umschalten zwischen Datenquellen und Datenzielen, welche in Reaktion auf Bedingungen, wie beispielsweise einer Benutzerauswahl, die Konfiguration potentiell wechseln.
  • Einige der anwendbaren Datenverarbeitungs- und Kommunikationsfunktionen sind sich wiederholende Funktionen, in welchen sequentielle Datenpakete im Wesentlichen auf die gleiche Weise zur Übertragung von einer Quelle zu einem Ziel behandelt werden. Diese Funktionen können von einer Verschlankung und Vereinfachung einer Datenpipelinekonfiguration profitieren, um die Geschwindigkeit zu maximieren.
  • Andere Datenverarbeitungs- und Kommunikationsfunktionen sind mehr verwaltend und rechenintensiver. Wenn beispielsweise ein Datenübertragungspfad rekonfiguriert wird, um Quellen- und Zielknoten hinzuzufügen, zu entfernen oder zwischen Quellen- und Zielknoten umzuschalten oder um zwischen Funktionen zu wechseln, kann ein Steuerprozessor programmiert werden, um verschiedene andere Schritte aufzurufen, ne ben den für aufeinanderfolgende Pakete wiederholt einzustellenden Adressen usw. Diese Funktionen können von der Flexibilität profitieren, was eine programmierungs- und rechnertechnische Komplexität indiziert.
  • Die Anforderungen zur Rationalisierung und Vereinfachung aus Gründen der Geschwindigkeit gegenüber den Anforderungen einer rechnertechnischen Komplexität bilden jedoch sich widersprechende Entwurfsrandbedingungen. Es könnte vorteilhaft sein, den Bedarf hinsichtlich Geschwindigkeit und Datenkapazität und den konkurrierenden Bedarf an Rechnerleistung zu optimieren, so dass Anordnungen bereitgestellt werden können, welche sowohl schnell als auch vielseitig einsetzbar sind. Die vorliegende Erfindung teilt bestimmte Funktionen, welche für die Datenübertragung erforderlich sind, in Gruppen auf. Relativ einfache Hochgeschwindigkeitsfunktionen und typischerweise Wiederholungsfunktionen werden einem Beschleunigungselement zugeordnet, das vollständig oder teilweise in Hardware ausgeführt ist, d. h. einen Hardwarenetzwerkbeschleuniger bildet. Relativ komplexe und flexible rechnertechnische Funktionen werden einem Steuerprozessor zugeordnet und im Wesentlichen als Software ausgeführt. Als eine seiner Funktionen generiert der Steuerprozessor Bedingungen und Faktoren und speichert diese im Hardwarenetzwerkbeschleuniger, wie beispielsweise Adresseninformationen, die während einer bestimmten Operation, welche die Übertragung von aufeinander folgenden Paketen umfasst, wiederholt verwendet werden.
  • 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 Übertragungspfade 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 Local- 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 Übertragen von in Paketen 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 Anwendungen, wie beispielsweise bei Telekonferenzen und ähnlichen Kommunikationen, sollte das Sammeln, Verarbeiten, Übertragen und Wiedergeben von in Paketen aufgeteilten Daten in vorteilhafter Weise mit kaum wahrnehmbaren Verzögerungen und ohne Pausen gleichzeitig mit in Echtzeit durchgeführten Video-Konferenzen erfolgen.
  • Das RTP-Echtzeitprotokoll ist ein bekanntes Protokoll, um die Handhabung von Echtzeitdaten, einschließlich Audio- und Video, auf eine effektive 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 Art und 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 bzw. 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 das Echtzeitsteuerprotokoll bezeichnet.
  • Der Datenteil des RTP ist ein dünnes oder verschlanktes Protokoll, welches eine Unterstützung für Anwendungen mit Echtzeiteigenschaften bereitstellt, wie beispielsweise für die Übertragung von kontinuierlichen Medien, z. B. Audio und Video. Diese Unterstützung umfasst Zeitablaufrekonstruktion, Verlustdetektierung oder Verlusterkennung, Sicherheit, Inhaltsidentifikation und ähnliche Funktionen, die wiederholt auftreten und im Wesentlichen begleitend zu 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 so lange erhalten bleibt, bis alle zugehörigen 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 Anwendungen, welche die Pakete senden und empfangen, sicherzustellen, dass alle erforderlichen Pakete gesendet und empfangen werden. Einige Anwendungen, wie das Streaming von Telekonferenzbildern, sind nicht sehr empfindlich im Hinblick 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, Techniken zur Verfügung zu stellen, bei denen Echtzeitübertragungen unter Verwendung eines weiten Bereichs von hohen und niedrigen Schichten ausführbar sind, während es der Konfiguration ermöglicht wird, die möglichen Parameter der unterschied lichen Protokolle zu nutzen. Es könnte insbesondere in Systemen mit hoher Leistungsfähigkeit oder hohen Anforderungen nützlich sein, die Funktionsweise so anzupassen, 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 besteht in der Bereitstellung einer effizienten Verarbeitung von Videodaten und ähnlichen kontinuierlichen Strömungs- bzw. Streamingdaten durch Bereitstellen einer Datenverarbeitungsvorrichtung, die charakteristische und konkurrierende Übertragungsdatenpfade und Steuerdatenpfade aufweist, wobei die beiden Datenpfade getrennt datendurchsatzintensive Funktionen und datenverarbeitungsintensive Funktionen unter Verwendung von charakteristischen kooperativen Ressourcen verarbeiten, die getrennt für Durchsatz bzw. Verarbeitungsleistung ausgebildet 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 dem Echtzeitprotokoll (RTP) zugeordnet sind, durchgeführt werden, wobei die Untermengen von Prozessoren und Schaltbauelementen bearbeitet werden, welche für die ihnen zugeordneten Untermengen optimiert sind. Die Partitionierung von geschwindigkeitsbasierten Funktionen ist Geräten zugeordnet, welche die Charakteristik von Daten-Pipelines aufweisen. Die Rechenfunktionen sind einem oder mehreren Zentralprozessoren zugeordnet, welche die RTP-Sitzungen steuern und die rechnertechnischen Aspekte mit geringerer Rechnerlast zum Übertragen der Streaming-Daten in der Datenkommunikations-Pipeline behandeln.
  • Bei bestimmten Ausführungsformen betrifft das Verfahren die wiederholte Verwendung eines Hardwareschnittstellenelements, um Kopfabschnittsdaten, die in ausgewählten Paketen, die unter der Steuerung eines Zentralprozessors gesendet und empfangen werden, gefunden werden, zu ersetzen. Der Zentralprozessor kann Kriterien aufbauen, wie eine Koordinierung von Paketen, die bestimmte Identifizierungsattribute aufweisen, um auf eine bestimmte Weise behandelt zu werden, wie beispielsweise zu einer bestimmten Adresse geroutet zu werden. Diese Kriterien können vom Zentralprozessor gespeichert werden, um das Hardwareschnittstellenelement zu steuern. Das Hardwareschnittstellenelement fügt die Ergebnisse in die Übertragungsdaten ein, was ein Ersetzen von Kopfabschnittsdatenwerten einschließt, die jeweils in fortlaufenden Paketkopfabschnitten mit empfangenen Daten gefunden werden, die vom Steuerprozessor ausgelesen oder als Ergebnis von Daten erzeugt werden, die vom Steuerprozessor ausgehen.
  • Das Hardwareschnittstellenelement kann mit einer hohen Datenrate ohne wesentliche Überwachung arbeiten und das Streaming der RTP-Pakete zu oder von Zielen bzw. Quellen steuern, wie audiovisuelle Präsentationsgeräte und netzwerkverbundene Speicherbauelemente. Auf diese Weise beschleunigt das Hardwareschnittstellenelement die Bearbeitung der Daten, während der Steuerprozessor von der Steuerung der Funktionen befreit wird, die rechnertechnisch intensiver als IF/THEN-Ersetzungen von bestimmten Kopfabschnittswerten durch definierte Ersatzwerte sind, was nun durch den Hardwarebeschleuniger erledigt wird.
  • In einer Daten-Streaming-Kommunikationsvorrichtung, die auf einer Übertragung von adressierten Datenpaketen basiert, tragen, unabhängig davon, ob die Vorrichtung ein Local- oder Wide-Area-Netzwerk aufweist, die gleichen Datenpfade, welche die den wiederholten Streaming-Funktionen zugeordneten Datenpakete tragen, auch die den rechner technisch fordernden Funktionen zugeordneten Steuer- und Adressierpakete, welche zum Verwalten des Daten-Streamings erforderlich sind. Gemäß einem Aspekt der Erfindung wird eine Datei für einen inhaltsadressierbaren Speicher (CAM) erzeugt, durch die ein Hardwarebeschleuniger mehreren aktuell vorhandenen Paketwarteschlangen mit bestimmten Adressen zugeordnet wird. Wenn eine SETUP-Anforderung empfangen wird, um eine neue Streaming-Verbindung zu einem neuen Endpunkt zu initiieren, wird kein übereinstimmender Eintrag in der CAM-Datei gefunden. Der Hardwarebeschleuniger wird mit zugehörigen Kopfabschnittswerten bereitgestellt, indem ein Eintrag im inhaltsadressierbaren Speicher (CAM) im Vorgriff auf eine RECORD- oder SEND-Nachricht initiiert wird. Die mit dem neuen Endpunkt assoziierten Kopfabschnittswerte 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 Kopfabschnittswertes beim Hardwarebeschleuniger in Datenverbindung mit dem Verkehrmanager und dem Zentralprozessor. Die Verbindung kann bis zum Abschluss oder bis der Zentralprozessor erforderliche neue Steuerungen und Aktivitäten beeinflusst, wie beispielsweise Bestimmen des Endpunkts oder von Endpunkten des Stroms gemäß beliebiger programmierbarer Funktionen, in vollem Gange und mit dem Vorteil der hohen Datenrate aufrecht erhalten bleiben. Solche Funktionen können viele oder alle Funktionen umfassen, die sonst eine Steuereinheit erfordern, um über eine programmierte 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 inhaltsadressierbare Speichertechnik zum Ersetzen von bestimmten Kopfabschnittswerten durch gespeicherte Werte ist relativ mechanisch und kann schnell umgesetzt werden. Einige RTP-Steuerfunktionen, wie beispielsweise eine RTP-Abschlussroutine, können etwas komplexer sein und nicht optimal durch Hardware bearbeitet werden, beispielsweise weil eine Mehrzahl von Paketen und nicht ein Eins-zu-Eins-Austausch involviert ist, oder weil gegebenenfalls bedingte Schritte involviert sind, die komplexer als auf gespeicherten Werten basierte IF/THEN-Ersetzungen sind.
  • Andererseits können Anforderungen an Streaming-Durchsätze hoch sein. Um den Durchsatz auf herkömmliche Weise zu erfüllen, kann ein sehr schneller und geeigneter Zentralprozessor erforderlich sein, um die erforderliche Rechenleistung zu gewährleisten und die Kopfabschnittswertersetzung während der Übertragung auszuführen. Es ist ein erfinderischer Aspekt, den Hardwarebeschleuniger einzuführen, um die Kopfabschnittswertersetzung durchzuführen, nachdem der Zentralprozessor die Ersatzwerte und Ersatzkriterien bereitstellt.
  • Wenn die Warteschlangeneinträge eingerichtet sind, wird jedes Paket im Strom anfänglich an den Netzwerkbeschleuniger angelegt, d. h. die Hochgeschwindigkeitseinheit ist im Wesentlichen als Hardware implementiert. Der Beschleuniger vergleicht die Pakete mit Informationen in der CAM-Verbindungstabelle, zerlegt beispielsweise die Schicht-Drei- und Schicht-Vier-Kopfabschnitte und fügt neue lokale Kopfabschnitte ein. Das Paket, das nun einen potentiell ersetzten lokalen Kopfabschnitt, einen RTP-Kopfabschnitt und eine RTP-Nutzlast enthält, wird durch den Verkehrsverwalter zu seinem Ziel gesendet, beispielsweise während einer RECORD-Operation in eine adressierte Platte geschrieben, oder während einer PLAY-Operation zu einem Präsentationsgerät oder zu einigen anderen Adressen gesendet, um zwei oder mehr solche Operationen gleichzeitig auszuführen, usw.
  • Ein Vorteil dieses erfindungsgemäßen Verfahrens besteht darin, dass ankommender RTP-Verkehr behandelt und unmittelbar durch Software gesteuert werden kann. Wenn ein neuer und verschiedener RTP-Nutzlasttyp aufkommt oder wenn die Definitionen von bekannten Nutzlasttypen sich verändert, kann Unterstützung für diese von einem Streamer bereitgestellt werden. Zusätzlich kann die gewünschte Funktion einer persönlichen Videoaufnahme (PVR) von während der Aufnahme verzögerten Darstellungen (delayed-view-while-recording) sehr effektiv unterstützt werden.
  • Ein Nachteil der erfindungsgemäßen Technik kann darin bestehen, dass das Speichern des Objekts im lokalen RTP-Kopfabschnitt das Objekt nicht mehr für HTTP-Übertragungen zugänglich macht oder in einigen Situationen Operationen erfordert, um diese Effekte aufzuheben. Geeignete Softwareroutinen auf einem Hostprozessor können jedoch verwendet werden, um das ursprüngliche Medienobjekt wieder zusammenzusetzen, entweder sofort, um das Objekt sofort für Nicht-RTP-Clients verfügbar zu machen, oder dann, wenn Ressourcen verfügbar sind und/oder eine Anforderung für das Objekt vorliegt.
  • 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. Der Schutzbereich wird jedoch durch die Ansprüche bestimmt. 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 durchführt, geroutet wird.
  • 2 ein Blockdiagramm zur Darstellung einer erfindungsgemäßen Streaming-Steuereinheit.
  • 3 eine Tabelle zur Darstellung von Komponentenwerten in einem RTP-Kopfabschnitt.
  • 4 ein Datentabellendiagramm zur Darstellung eines RTP-Kopfabschnitts, der vorne an einen lokalen Adressenkopfabschnitt angefügt wird.
  • 5 ein Blockdiagramm zur Darstellung eines Datenflusses und von Datenkomponenten, die in Verbindung mit einem inhalt adressierbaren Speicher zum wiederholten Anlegen von Werten verwendet werden, die anfänglich vom Zentralprozessor erzeugt werden.
  • 6 ein logisches Flussdiagramm zur Darstellung von Funktionen, die bei einem Aufbau und einem Aufrechterhalten einer Daten-Streaming-Verbindung ausgeführt werden.
  • 7 ein Blockdiagramm zur Darstellung der Komponenten eines Unterhaltungssystem „HNAS", das in vorteilhafter Weise dazu konfiguriert ist, die erfindungsgemäße Paketdatenbearbeitung zu umfassen.
  • 8 ein Blockdiagramm zur Darstellung einer Addition eines Kopfabschnittsoffsets, der Verwendung findet, wenn Protokolle, die charakteristische Offsets aufweisen, verkettet werden, und eines Beispiels, mit welchem eine Paketadresse im Hinblick auf den Offset bestimmt wird.
  • 9 ein logisches Diagramm zur Darstellung einer Kaskadierung von inhaltadressierbaren Speicherelementen gemäß einer bevorzugten Ausführungsform.
  • 10 ein Datentabellediagramm zur Darstellung eines Layouts eines lokalen Adressenkopfabschnitts, welcher durch die Verwendung der Erfindung an ein Datenpaket angelegt wird.
  • Detaillierte Beschreibung von bevorzugten Ausführungsformen
  • Ein Echtzeitprotokoll oder „RTP" stellt Ende-zu-Ende-Netzwerkübertragungsfunktionen bereit, die für Anwendungen geeignet sind, die Echtzeitdaten, wie beispielsweise Audio-, Video- oder Simulationsdaten, über Gruppenruf- oder Einzelrufnetzwerkdienste übertragen.
  • RTP macht keine Adressenressourcenreservierungen und garantiert keine Dienstqualität für Echtzeitdienste, wie beispielsweise Sicherstellen auf einer RTP-Protokollschicht, 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 auch durch ein Gesamtpräsentationssteuerprotokoll (RTSP) ergänzt.
  • Die RTCP- und RTSP-Steuerprotokolle beziehen Signalisierungspakete mit ein, die beispielsweise übertragen werden, wenn ein Übertragungspfad aufgebaut oder aufgetrennt wird, wenn eine Übertragung in eine Richtung (PLAY) oder in eine andere Richtung (RECORD) initiiert wird, wenn eine Pause eingefügt wird usw. Die Inhaltdatenpakete 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 dazu entwickelt, 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-Niveau-Übersetzern und RTP-Niveau-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 ausgefü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 Aspekt des Systems, das charakteristische Echtzeitdateninhaltpakete (RTP) gegenüber Steuer(RTCP)- und/oder Sitzungs(RTSP)-Paketen verwendet, besteht darin, dass alle drei Typen oder Pakete über den gleichen Datenpfad gesendet und empfangen werden, aber sich in Frequenz und Funktion sehr unterscheiden. Es ist möglich, einen Prozessor in einem Empfänger bereitzustellen, wie beispielsweise in einem als Netzwerk verbundenen Unterhaltungssystem, einem Videokonferenzsystem, einem mit einem Netzwerk verbundenen Speicherbauelement usw., und den Prozessor dazu zu programmieren, 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, muss der Zentralprozessor mit einer hohen Datenrate arbeiten, um die RTP-Inhaltpakete in Echtzeit zu übertragen. Zudem muss der Prozessor leistungsfähig genug und dazu programmiert sein, potentiell involvierte Steuerprozesse zu behandeln, wobei die Leistungsfähigkeit des Prozessors nicht verwendet wird, wenn einfach RTP-Pakete weitergeleitet werden, und die hohe Datenratenfähigkeit des Prozessors für eine Behandlung der Steuerberechnungen nicht erforderlich ist, die vergleichsweise selten sind.
  • Ein Aspekt der vorliegenden Erfindung besteht darin, charakteristische Datenpfade für die RTP-Daten und die Signalisierungsdaten bereitzustellen, so dass die Rechenleistung des Zentralprozessors oder der Zentralprozessoren nicht für die Bearbeitung von Routinen zur Weiterleitung der RTP-Daten verwendet werden müssen und frei für spezielle Fälle von Sitzungsverarbeitungen sind, aber grundsätzlich von der gleich bleibenden Behandlung der RTP-Sitzungen befreit sind. Diese Partitionierung ist aufgrund der Leistungsfähigkeitsvorteile, die durch Verwendung von Hardwareumschaltbauelementen zum Daten-Streaming erzielt werden können, und des Zentralprozessors vorteilhaft, um die Komplexität von mehreren unterstützten Protokollen in höheren und/oder niedrigeren Applikationsschichten handzuhaben, wie beispielsweise von verschiedenen Eingabe- und Ausgabeprotokollen, Geräten, Adressen und Funktionen.
  • 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 Hardwarebeschleunigers 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 Verkehrsverwalter/Zuteiler 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 Plattenspeicher und seine Steuereinheit oder ein Ausgabegerät repräsentiert wird.
  • Entsprechend einem erfindungsgemäßen Aspekt werden die Paketdaten in einem ersten Fall 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, das dazu konfiguriert ist, Kopfabschnittswerte in den ankommenden strömenden RTP-Paketen zu ersetzen, um deren Handhabung zu steuern. Insbesondere werden Werte im inhaltsadressierbaren Speicher des Netzwerkbeschleunigers durch die Steuereinheit gesetzt. Die Werte können beispielsweise ein direkter Ersatz der Kopfabschnittswerte durch lokale Adressenwerte sein, welche die Pakete zu einem Spei cherbauelement oder zu einem Auslesegerät oder zu anderen lokalen Zielen routet. Alternativ kann der Hardwarebeschleuniger von der Steuereinheit dazu gesteuert werden, die Pakete anders zu routen, wie beispielsweise Weiterleiten von zwei oder mehr Kopien des gleichen Inhalts zu zwei Zielen, wodurch der Signalpfad effektiv geteilt wird.
  • Aus diesem Grund umfasst der inhaltsadressierbare Speicher des Hardwarebeschleunigers eine Tabelle, die mit einer Serie von Adressen, Kopfabschnittswerten, Flags oder ähnlichem gefüllt ist, die mit einem bestimmten Strom korrespondieren, wenn die Verarbeitung des Stroms initiiert wird. Wenn zusätzliche Pakete in Echtzeit ankommen, greift der Hardwarebeschleuniger auf die korrespondierende Information im inhaltsadressierbaren Speicher durch Lokalisieren der Tabelleneinträge für den zugehörigen Strom zu und ersetzt die Kopfabschnittswerte in den Paketen durch Kopfabschnittswerte, die im inhaltsadressierbaren Speicher gefunden oder aus den im inhaltsadressierbaren Speicher geladenen Werten erzeugt werden. Wenigstens eine Untermenge der Werte im inhaltsadressierbaren Speicher sind Werte, die vom Steuerprozessor stammen, um beispielsweise Benutzerbefehle auszuführen. Eine Untermenge der Werte im inhaltsadressierbaren Speicher kann optional durch eine Operation des Hardwareprozessors unabhängig vom Steuerprozessor erzeugt werden. Der Hardwareprozessor kann beispielsweise einen Zähler oder Addierer umfassen, welche eine Sequenznummer erhöhen oder Zeitstempelinformationen unter bestimmten Bedingungen einstellen, um sich beispielsweise von einem Verlust eines UDP-Pakets zu erholen oder um kontinuierliche Übergänge während Schaltfunktionen zu bewirken.
  • 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 Daten kommunikation gekoppelt sind, wie dargestellt, 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 gezeigte Beispiel kann für die Übertragung von Paketen in einer Situation ausgebildet sein, in der ein Inhaltsignal auf einem Wiedergabegerät dargestellt und gleichzeitig aufgenommen wird. In anderen Anwendungsbeispielen 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 Videokonferenz. Diese und andere ähnliche Anwendungen sind gemäß der Erfindung leicht möglich.
  • 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.
  • RPSP 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, wel che 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 dem Strom zugeordneten 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 aufweisen, einschließlich Objektidentifikation, Quellen- und Ziel-IP-Adressen und Protokolports, und der zu verwendenden Transportschichtprotokolle, allgemein RTP und entweder TCP oder UDP. Auf diese Weise beschreiben die RTSP-Anforderungen die Sitzung zwischen dem Client und dem Server. In einigen Fällen kann die Anforderung spezifisch 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, wie wenn 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 zugehörigen 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 geschieht. Das UDP-Übertragungsprotokoll ist für eine Echtzeitübertragung von Paketen geeignet, wie beispielsweise von Audio- oder Videodatenabtastwerten. 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 vereinbar als mit UDP. Diese Beschreibung geht davon aus, dass UDP für die RTP-Übertragung verwendet wird. Die Erfindung sollte aber nicht auf die bevorzugte UDP-Übertragung beschränkt 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 einen zugehörigen 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 die beschriebene Aufteilung der Daten in Pakete betrifft, und um einen Online-Zugriff aufrechtzuerhalten.
  • Jeder Medienobjekttyp wird entsprechend den von dem zugehörigen RFC bereitgestellten standardisierten Spezifikationen typspezifisch in Pakete aufgeteilt, sogar mit unter den Typen variierenden Kopfabschnittsformaten. 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 dem RFC 3550/3551 beschrieben ist. Die Kopfabschnittsfeldabkü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 Kopfabschnittsposition ein Indikator dafür.
  • „P” ist ein Wert, der anzeigt, ob eine Auffüllung am Ende der Nutzlast existiert, welche ignoriert werden sollte, und gegebenenfalls 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 es 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 sei angemerkt, dass sich dies vom TCP unterscheidet, 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 eine 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 es, 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 Effekt eines Paketverlusts reduziert 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 auf den 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 RTCP-Pakete können zu einer Form eines zusammengesetzten RTCP-Pakets verkettet werden und gemeinsam in einem einzelnen Paket des niedrigeren Schichtprotokolls übertragen werden.
  • 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 eine reine Hardwarelösung oder eine reine Softwarelösung bereitzustellen. Eine reine Hardwarelösung würde ziemlich kompliziert sein, wenn sie für alle Steuersituationsszenarien zur Verfügung gestellt werden müsste. Im Gegensatz dazu würde eine reine Softwarelösung, die einen Prozessor und eine Software aufweist, die in der Lage ist, eine derartige Komplexität zu beherrschen, nicht vollständig ausgenutzt werden. Für die meisten Funktionen werden, nachdem der Stream bzw. Strom in Gang gesetzt ist, viele der Funktionen zur fortlaufenden Behandlung von nachfolgenden Paketen eines vorgegebenen Stroms auf die gleiche Weise wie bei einem vorhergehenden Paket gehandhabt, wodurch wenig Rechenleistung erforderlich ist.
  • In einer vorteilhaften Ausführungsform der Erfindung wird eine Hybridlösung bereitgestellt, wobei der Steuerprozess im Wesentlichen durch eine Steuereinheit aufgebaut und koordiniert wird, welche ein potentiell komplexes und geeignetes Softwareprogramm bearbeitet. Spezialisierte Hardware, die das Medienobjekt und unterstützende Dateien verwenden, die durch Software erzeugt werden, wird dazu verwendet, Übertragungen zu beschleunigen.
  • Aufgrund der relativen Komplexität und Seltenheit der Ausführung können RTSP- und RTCP-Funktionen, die stark auf Steuerfunktionen bezogen sind, in Software auf dem Zentralprozessor implementiert werden, ohne diesen zu überlasten. RTP erfordert andererseits eine Verarbeitung von jedem ankommenden und ausgehenden Paket in einem Medienstrom in Sequenz oder in naher Sequenz mit einer Echtzeitdatenrate und profitiert erfindungsgemäß durch den Hardwarebeschleuniger.
  • Nachfolgend wird ein Beispiel zum Implementieren einer einzelnen Untermenge der Streaming-Funktionalität beschrieben, nämliche die Verwendung von RTSP/RTP mit einer hardwaremäßigen Entnahme des RTP-Inhalts. Diese Funktionalität wird allgemein in persönlichen Videorecordern (PVR) gefunden und kann als Akzeptieren eines Eingabe stroms von verkapselten RTP-Daten von einem Endpunkt und einem sofortigen oder nach einer willkürlichen Zeitspanne durchgeführten Senden der gleichen verkapselten RTP-Daten entweder zum gleichen oder zu einem anderen Endpunkt beschrieben werden. Es ist eine Eigenschaft einer solchen Funktion, dass die Endpunkte temporär sein können und beispielsweise gemäß einer Benutzerauswahl gewechselt oder umgeschaltet werden können. Die besondere Eigenschaft der Endpunkte ist für die Funktion der Erfindung nicht kritisch, wie nachfolgend ausgeführt. Die Endpunkte können ein ausgehendes Anzeigegerät oder ein Endanzeigegerät, wie beispielsweise eine Videokamera bzw. ein Wiedergabeempfänger, oder ein Zwischenelement, wie ein Komprimierungs/Dekomprimierungs- oder Formatwechselgerät, oder eine beliebige Kombination dieser oder anderer Elemente sein, von welchen oder an welche ein Paketdatensignal in einem Strom gerichtet wird.
  • Wie aus 2 hervorgeht, umfasst der Medien-Streamer drei Hauptarchitekturelemente, nämlich einen Zentralprozessor, einen Verkehrsverwalter/Zuteiler und einen Netzwerkprotokoll- oder Hardwarebeschleuniger. Diese Strukturen können in der physikalischen Ausführung variieren und mehr oder weniger komplex in Bezug auf Schaltkreise bzw. Steuerprozesse sein. Wenn die Schaltkreise durch mehr oder weniger fest verdrahtete Bauelemente verkörpert sind, sind Funktionen derartiger Bauelemente hier insoweit beschrieben, als sie die Handhabung von RTSP/RTP-Verkehr betreffen.
  • Der Zentralprozessor steuert die Systemprozesse. Der Netzwerkprotokollbeschleuniger oder „Hardwarebeschleuniger" steuert bzw. behandelt ressourcenintensive aber sich wiederholende oder iterative Verarbeitungsaufgaben. Auf diese Weise entlastet der Hardwarebeschleuniger den Zentralprozessor von sich häufig wiederholenden Operationen mit geringer Komplexität. Basierend auf Informationen, die zum Teil durch die in 3 dargestellten ankommenden RTP-Paketkopfabschnitte und zum Teil von Werten bereitgestellt werden, die vom Steuerschaltkreis 39 eingerichtet werden, wenn ein Strom aufgebaut wird, kann ein in 4 dargestellter lokaler Kopfabschnitt dem RTP-Kopfabschnitt des in 4 dargestellten Pakets 22 vorangestellt werden. Auf diese Weise verläuft der Datenfluss, wie im Blockdiagramm gemäß 5 dargestellt ist, mit programmbeeinflussbaren lokal adressierbaren Kopfabschnittsfeldern, die unter Verwendung des inhaltsadressierbaren Speicher ersetzt werden, ohne dass es hierzu erforderlich ist, jedes Paket durch den Steuerschaltkreis 39 zu leiten.
  • Der Netzwerkhardwarebeschleuniger umfasst einen inhaltsadressierbaren Speicher (CAM) oder eine Tabelle mit Werten, die im Speicher wenigstens solchen Strömen zugeordnet sind, die aktuell ausgeführt werden. Der inhaltsadressierbare Speicher speichert Verbindungsparameter für hardwaremäßig beschleunigte Verbindungen, welche wenigstens eine Teilmenge der Verbindungen umfassen, die unter Verwendung der Vorrichtung als gesamtes möglich sind. Der Hardwarebeschleuniger umfasst einen Schaltkreis, der ausreicht zu bestimmen, ob ein ankommendes Paket zu einem Strom gehört, der bereits in einer Nachrichtenwarteschlangeninformation eingerichtet ist, welche im inhaltsadressierbaren Speicher gespeichert ist. Wenn ein Nachrichtenwarteschlangeneintrag existiert, behandelt der Hardwarebeschleuniger die ankommenden Pakete auf eine Weise, die bereits durch den Nachrichtenwarteschlangeneintrag bestimmt ist. Wenn das Paket keinen existierenden Eintrag aufweist, verweist der Hardwarebeschleuniger auf den Zentralprozessor, um durch diesen einen neuen Nachrichtenwarteschlangeneintrag einrichten zu lassen, wenn das Paket ein Teil eines beschleunigten Stroms werden soll. Die Behandlungsweise des Pakets kann den Ersatz von Paketkopfabschnittswerten durch lokale Adressen, überprüfte Kopfabschnittswerte, um mit einer bestimmten Situation umzugehen, veränderte Werte, die einer anderen Protokollschicht zugeordnet sind, usw. umfassen.
  • Der Verkehrsverwalter/Zuteiler wird verwendet, um eine Speicher- und Plattenzugriffsverwaltung sowie das Verwalten von ankommendem und ausgehendem Verkehr bereitzustellen. Er verwaltet eine Anzahl von Warteschlangen, die einer Eingabe und Ausgabe von verschiedenen hardwaremäßig beschleunigten Verbindungen zugeordnet werden können, und den Zentralprozessor.
  • Das Verfahren der Erfindung ist in einem Datenflussdiagramm gemäß 4 und in einem Flussdiagramm gemäß 6 dargestellt. Die Medien-Streamer-Vorrichtung empfängt einen Strom von RTP-Paketen von einem Endpunkt und ist dazu ausgebildet, die Daten mit einer ausreichenden Effizienz und Geschwindigkeit zu verarbeiten, um mit dem Echtzeitpaket Schritt zu halten, und eine ausreichende Flexibilität aufzuweisen, um mit Veränderungen in Anforderungen für die Datenbehandlung, wie beispielsweise mit dem Aufrufen oder Beenden von neuen Quellen/Zielverhältnissen mit Endpunkten oder mit Zwischenelementen, die einen weiten Bereich von dynamisch variierenden RTP-Nutzlasttypen involvieren können, für die Quellen und die Ziele kompatibel zu sein.
  • RTSP- und RTCP-Operationen sind so selten, dass sie in Software implementiert werden können, die auf dem Zentralprozessor abläuft, wobei das ausgeführte Programm komplex sein kann, ohne typischerweise Probleme mit dem Schritthalten mit dem Dateninhalt aufzuweisen. Daher werden diese Funktionen vorzugsweise in Software implementiert, die auf dem Zentralprozessor abläuft.
  • Gleichbleibendes RTP-Streaming bedingt andererseits eine wiederholte Behandlung der Pakete, beispielsweise das Leiten von allen Paketen in einem Strom zu einem bestimmten Ziel, das temporär zugewiesen wird, während der Strom aktiv ist. Die Funktion wird in der zugeordneten Hardware des Netzwerkbeschleunigers und des Verkehrsverwalters/Zuteilers behandelt.
  • Es können jedoch mehrere Ströme zur gleichen Zeit aktiv sein. Um Pakete für einen vorgegebenen Strom auf gleich bleibende Weise zu behandeln, enthält der inhaltsadressierbare Speicher einen Wertesatz, wie beispielsweise Zieladresse, letzte Paketsequenznummer usw., der auf den Strom anwendbar ist. Der Hardwareprozessor kann ein Register enthalten, welches Stromidentifikationsinformationen hält, die mittels des inhaltsadressierbaren Speichers zugehörigen Paketdatenwerten zugeordnet werden. Bei einem Vergleichsvorgang, der eine Verknüpfung und einfache Berechnungen umfassen kann, vergleicht der Hardwarebeschleuniger die Identifikationsinformationen eines ankommenden Pakets mit einem Eintrag des inhaltsadressierbaren Speichers und gibt die Informationen für die übereinstimmenden Pakete aus. Dieser Prozess wird beispielsweise dazu verwendet, Datenwerte in einem Paketkopfabschnitt, wie die Kopfabschnittsadresseninformation, durch lokale Adresseninformationen zu ersetzen, welche aus dem inhaltsadressierbaren Speicher für den Strom gelesen werden, dem das Paket entspricht.
  • Das Ersetzen von Werten ist ein einfacher und sich wiederholender Prozess, der im Wesentlichen durch das Flussdiagramm in 6 dargestellt wird. Wenn das nächste Paket als Teil eines aktuellen Stroms auftritt, weist es einen Warteschlangeneintrag auf. Die Stromidentifikationsinformation, wie z. B. die Adresseninformation, wird mit einem Eintrag in der Warteschlange verglichen, d. h. im inhaltsadressierbaren Speicher. Wenn kein Eintrag gefunden wird, wird dies dem Prozessor mitgeteilt und ein Eintrag kann durch den Prozessor eingerichtet werden, der dazu programmiert ist, den passenden Warteschlangeneintragwert zu bestimmen und im inhaltsadressierbaren Speicher des Hardwarebeschleunigers zu speichern, wobei die Prozessorfunktionen durch einen gestrichelt dargestellten Block dargestellt sind. Während der fortlaufen den und weiteren Verarbeitung bestimmt der Hardwarebeschleuniger die Einträge für die nächsten empfangenen Pakete, ersetzt die ursprünglichen Kopfabschnittswerte durch Werte aus dem inhaltsadressierbaren Speicher und fährt bis zu einem Ende des Stroms fort, worauf der Warteschlangeneintrag im inhaltsadressierbaren Speicher für diesen Strom freigegeben wird. Die Streaming-Vorrichtung ist bereit, eine neue Verbindung unter Verwendung der dadurch freigegebenen Ressourcen zu unterstützen.
  • Der durch den Zentralprozessor ausgeführte Softwareprozess implementiert Schnittstellen zu den Hardwareelementen über eine Applikationsprogrammschnittstellte (API), welche bestimmte Operationen initiieren, beenden und zwischen bestimmten Operationen umschalten kann, beispielsweise um Benutzereingabeauswahlmöglichkeiten zu behandeln. Die API kapselt die direkte Schnittstelle zwischen dem Zentralprozessor und den Hardwareeinheiten, wie beispielsweise Lese- und Schreibregister, Zugriffshardwarewarteschlangen.
  • In bevorzugter Ausgestaltung kann die Funktionalität eines persönlichen Videorecorders (PVR) wie folgt implementiert werden, wobei diese Beschreibung selbstverständlich ein nicht beschränkendes Beispiel betrifft.
  • RTSP-Funktionen, welche in der Programmierung des Zentralprozessors ablaufen, suchen nach einem SETUP-Befehl, der von einem Endpunkt empfangen wird, der eine Quelle oder ein Ziel eines Datenpakets sein kann. Pakete bzw. ein Paket, welches eine RTSP-SETUP-Anforderung aufweist, werden/wird von dem Netzwerkbeschleuniger empfangen und der darin identifizierte Strom stimmt nicht mit einem Eintrag in der CAM-Nachschlagtabelle überein. Der Netzwerkbeschleuniger ordnet diese der passenden Verkehrsverwalterwarteschlange zu, welche der Warteschlange entspricht, welche zu dem ankommenden Verkehr für den Zentralprozessor gehört. Wenn der RTSP-Prozess eine vollstän dige SETUP-Nachricht empfängt, werden die CAM-Nachschlagparameter, wie Quellen- und Ziel-IP-Adressen, Ports und das Übertragungsprotokoll, vollständig oder in Teilen aus der SETUP-Nachricht bestimmt. Ein Verbindungstabelleneintrag in der CAM-Tabelle wird für eine RTP-Sitzung eingerichtet.
  • RTSP wartet dann auf eine nachfolgende RECORD-Anforderung vom zugehörigen Endpunkt. Wenn eine RTSP-RECORD-Nachricht empfangen wird, wird diese vom Netzwerkbeschleuniger zum Verkehrsverwalter und weiter zum Zentralprozessor über den gleichen Pfad wie die SETUP-Nachricht übertragen. Die RECORD-Nachricht kann einen Zeitbereich des aufzunehmenden Stroms enthalten. An diesem Punkt kann die Sitzung als eingerichtet betrachtet werden und der Netzwerkbeschleuniger ist bereit, um Daten zu empfangen. Der Zentralprozessor sendet eine Objektgröße basierend auf dem Bereich, wobei der maximale Wert gesendet wird, wenn kein Bereich spezifiziert ist, und eine verfügbare Warteschlangenidentifikationen QID wird an den Verkehrsverwalter zur zeitlichen Einteilung eingereicht. Dies ermöglicht es dem Hardwarebeschleuniger die Pakete durch eine einfache Ersetzung der Kopfabschnittswerte zu bearbeiten, so lange der Strom ohne Veränderungen besteht.
  • Veränderungen können durch Beenden oder Modifizieren der CAM-Tabelleneinträge durchgeführt werden. Wenn beispielsweise ein lokales Speichergerät bereit ist, mit der Aufnahme eines ankommenden Stroms zu beginnen, kann ein Eintrag, der diesen Strom zu einem Wiedergabegerät leitet, modifiziert werden, so dass Pakete auch zur Plattensteuereinheit geleitet werden. Alternativ kann ein anderer Eintrag hinzugefügt werden, der den Strom einem Endpunkt am lokalen Speichergerät zuordnet.
  • Die RTP-Abschlussroutinen, Schaltoprationen, welche entsprechend der Bedingungen variieren können, und ähnliche rechnertechnisch intensive Funktionen können zu komplex sein, um in einer relativ einfachen Hardware ausgeführt zu werden. Die zeitlichen Anforderungen an die Streaming-Datenpakete in Echtzeit sind gleichermaßen zu hoch, um es einem Zentralprozessor mit einer extensiven Programmeffizienz zu ermöglichen, den ankommenden Verkehr zu allen Zeiten, beispielsweise während der Übertragung, rechtzeitig zu behandeln. Der Erfindung implementiert ein alternatives Verfahren, in welchem jedes Paket des Stroms durch den Netzwerkbeschleuniger empfangen wird, welcher die Pakete in der Verbindungstabelle vergleicht, die Schicht-Drei- und Schicht-Vier-Kopfabschnitte auftrennt, einen lokalen Kopfabschnitt einfügt und jedes Paket mit dem lokalen Kopfabschnitt, dem RTP-Kopfabschnitt und der RTP-Nutzlast an den Verkehrsverwalter sendet, um es in das Ziel, wie beispielsweise die lokale Platte zu schreiben.
  • Das Format der ankommenden Pakete ist derart, dass der lokale Kopfabschnitt eine 32-Bit-Länge aufweist, in der ein Wert für die Gesamtlänge des Pakets und beliebige erforderliche Flags enthalten sind. Diese Felder definieren die Grenzen eines jeden RTP-Pakets und bleiben nützlich, nach dem das Paket auf der Platte gespeichert ist. Während das Objekt in diesem Format gespeichert wird, können die gespeicherten Pakete für die Rücklieferung an den ursprünglichen Endpunkt in einer Bestätigung zeitlich eingerichtet werden, oder zu einem anderen Endpunkt im Netzwerk geroutet werden. Der Verkehrsverwalter muss die Fähigkeit aufweisen, das Objekt paketweise zu lesen, so dass er das Längefeld für jedes Paket aus dem lokalen Kopfabschnitt extrahieren kann, um es als Übertragungsgröße zu verwenden. Der Verkehrsverwalter sendet die Längenbytedaten an den Netzwerkbeschleuniger und rückt die Warteschlange zum Start des nächsten Pakets vor.
  • Wenn ein Paket vom Verkehrsverwalter empfangen wird, zerlegt der Netzwerkbeschleuniger den lokalen Kopfabschnitt und addiert einen Offset. Der Offset wird anfänglich vom Zentralprozessor bestimmt und ist als ein Feld in der CAM-Tabelle für die zugehörige Übertragung gespeichert, um zur Bestimmung der Platzierung des Sequenznummernfelds im ausgehenden Paket-RTP-Kopfabschnitt durch den Hardwarebeschleuniger beizutragen. Dies ermöglicht die Bereitstellung eines zufälligen ISS, wie es in RFC 3550 spezifiziert ist.
  • Der ausgehende Zeitstempel wird auf eine vergleichbare Weise eingestellt. Dies ermöglicht die Bereitstellung eines zufälligen ISS, wie es in RFC 3550 spezifiziert ist.
  • Die Schicht-Drei- und Schicht-Vier-Kopfabschnitte sind ähnlich wie der Kopfabschnitt des ausgehenden Pakets aufgebaut und platziert. Das ausgehende Paket wird zum MAC/PHY-Block gesendet.
  • Ein Vorteil dieses Verfahrens besteht darin, dass ankommender RTP-Verkehr durch Software behandelt werden kann. Wenn mehrere verschiedene RTP-Nutzlasttypen zur Anwendung kommen, oder sich vielleicht in der Definition ändern, kann eine Unterstützung für diese von der erfindungsgemäßen Streaming-Vorrichtung erhalten werden. Zusätzlich kann eine PVR-Funktionalität einer Aufnahme während einer verzögerten Darstellung (delayed-view-while-recording) unterstützt werden.
  • Ein Nachteil besteht darin, dass während das Objekt im RTP-Kopfabschnittsformat gespeichert ist, HTTP-Übertragungen nicht darauf zugreifen können. Software auf dem zentralen Hostprozessor kann verwendet werden, um das ursprüngliche Medienobjekt neu anzuordnen, um das Objekt durch Neuanordnung für Nicht-RTP-Clients oder für beliebige andere Clienten sofort oder so lange verzögert verfügbar zu machen, bis die erforderlichen Ressourcen verfügbar sind.
  • Bezugnehmend auf 7 ist die Erfindung bei einer vorteilhaften Ausführungsform in ein Datenmanipulationssystem eingebunden, das ein Plattenbereichsteuerbauelement aufweist. Dieses Bauelement kann ein Speichermanagement durchführen und digitale Medienapplikationen einer Verbraucherelektronik oder andere Anwendungen mit ähnlichen Eigenschaften unterstützen, wie beispielsweise Kommunikations- und Videokonferenzen. 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, erläutert wird.
  • Das Bauelement stellt vorzugsweise einen integrierten 10/100/100-Ethernet-MAC-Port zur Bereitstellung der Schnittstellenfähigkeit zum Heimnetzwerk oder einem anderen lokalen Bereichsnetzwerk (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 Verkehrsverwalter an. Der sitzungsbezogene Verkehrsverwalter arbeitet als Zentralprozessor, der zusätzlich zum Verwalten des RTP-Streamings, das hier behandelt wird, eine Zuordnung von geteilten Ressourcen, wie beispielsweise Netzwerkbandbreite, Speicherbandbreite und Plattenbereichsbandbreite, entsprechend dem Typ der aktiven Mediensitzung freigibt. Eine Videositzung erhält beispielsweise mehr Res sourcen als eine Bildbrowsingsitzung. Des Weiteren wird die Bandbreite als garantierte Bandbreite für eine zeitkritische Mediensitzung oder als bestmögliche Bandbreite für nicht zeitkritische Anwendungen zugeordnet, wie beispielsweise ein Medienarchivvolumenzugriff oder Multi-PC-Backup-Anwendungen.
  • Das Datenmanipulierungssystem umfasst ein Hochleistungs-Streaming mit einem zugehörigen 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. Vorliegend umfasst das System beispielsweise acht SATA-Disks und eine Kapazität, um bis zu 64 gleichzeitige bidirektionale Ströme über einen Verkehrmanager/Zuteilerblock zu bearbeiten.
  • Das Datenmanipulierungssystem ist im Hinblick auf die Erfindung in 7 dargestellt. 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 Datenverbindung zu/von entweder mit einer Gigabit-Ethernet-Steuereinheit (GEC) oder der peripheren Verkehrssteuereinheit (PTC) verbunden. Die PTC bildet direkt eine Schnittstelle zum Verkehrsverwalter/Zuteiler (TMA) für nicht paketbasierte Übertragungen. Die Paketübertragungen werden wie nachfolgend ausgeführt behandelt.
  • 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. Die 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 Kopfabschnittsfelder der Schichten 2, 3 und 4, welche extrahiert werden, um eine Adresse zu bilden. Ein Verbindungsnachschlagevorgang wird dann basierend auf der Adresse durchgeführt. Unter Verwendung des Nachschlageergebnisses trifft der ULP eine Entscheidung, wohin das empfangene Paket gesendet wird. Ein ankommendes 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 Festplatte 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 Platte 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 anzuordnen. 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 Platte durch Übertragen von Steuerinformationen von der Platte zum Speicher und vom Speicher zur Platte. 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 Platte, 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 Platten ü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 Kopfabschnittsfelder sind vom verwendeten Verkehrsprotokoll abhängig. Die zu bildende Adresse hat eine eindeutige Verbindung zu repräsentieren. Für den gebräuchlichsten Internetver kehr, der beispielsweise über IP-V4- und TCP/UDP-Protokolle transportiert 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 einer Schicht eines unterstützten Protokolls korrespondiert. Eine erste Stufe kann die Versionsnummer des L3-Protokolls in einem Feld überprüfen, das während des Kopfabschnittsanalyseprozesses 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 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.
  • Es ist möglich, dass die Kopfabschnittslänge in einem bestimmten Protokollniveau nicht festgelegt ist. Die TCP- und IP-Kopfabschnittslängen können beispielsweise aufgrund von „Optionsfeldern" wechseln. Eine potentiell variable Kopfabschnittslänge von einem äußeren Protokollniveau würde Feldpositionen des inneren Protokollniveaus relativ versetzen, einschließlich der Kopfabschnittslänge des inneren Niveaus selbst. Um variierende Kopfabschnittslängen auszugleichen, kann ein Protokollkopfabschnittlängenfeld als Teil des Adressennachschlagprozesses für dies Schicht extrahiert werden, welche ein Längenfeld aufweisen. Es ist auch möglich, dass einige Protokolle, wie beispielsweise IP-V6 und UDP, keine Längenfelder im Kopfabschnitt aufweisen. In diesem Fall kann keine Kopfabschnittslänge extrahiert werden, es ist aber durch andere Techniken möglich, die anwendbar sind, eine feste Kopfabschnittslänge während einer vorgegebenen Verbindung zu setzen und aufrechtzuerhalten.
  • Der Adressenbildungsprozess ist in 8 grafisch dargestellt. Während des Adressenbildungsprozesses wird ein Paket gepuffert und die erste Protokollschicht, z. B. eine Versionsnummer für ein IP-Protokoll, wird identifiziert und in einer Paketinformationstabelle gespeichert. Zu einem bestimmten Zeitpunkt gibt es viele Einträge in die Paketinformationstabelle, und auf den Eintrag im Kopfabschnitt des Paketinformationspuffers wird zuerst zugegriffen. Die Kopfabschnittslänge, z. B. die IP-Kopfabschnittslänge, wird aus der Paketinformationstabelle extrahiert, wenn der Längeneintrag existiert. Der Protokolltypcode, der von der ersten Stufe extrahiert wird, beeinflusst, wo die Protokollwerte der zweiten Stufe zu finden sind.
  • Der CAM unterstützt beliebige mögliche Kombinationen von Protokollen und Offsets. Der erste bestimmte Offsetgrößenwert führt zur Extrahierung des zweiten Protokollniveaus, z. B. des Protokollfelds für das IP-Protokoll in diesem Beispiel. Die Positionsnummerregistereinträge korrespondieren eins-zu-eins mit der Anzahl von CAM-Einträgen in jeder Stufe. Es gibt zwei Positionsregisterpaare für jeden Eintrag in der zwei ten Stufe. Das Kopfabschnittslängenfeld, z. B. die IP-Kopfabschnittslänge, wird vom Paketkopfabschnitt entsprechend dem spezifizierten Offset im zweiten Positionsregisterpaar extrahiert, wenn es existiert.
  • Der Feldextrahierungsprozess in der dritten Stufe ist ähnlich zu dem in der zweiten Stufe. Der CAM-Zugriff in der dritten Stufe muss jedoch die Verkettung der Protokolltypen abbilden, die von der ersten und zweiten Stufe usw. extrahiert werden. Es gibt nun acht Paare von Offsetgrößenfeldern zum Extrahieren von Werten aus acht Feldern. Die mehreren Felder, die von jedem Eintrag im Hinblick auf den Protokolltypwert extrahiert werden, werden verwendet, um den Eintrag zu identifizieren, so dass Werte miteinander verkettet sind, um eine Endadresse zu bilden.
  • Die Felder, auf die im Puffer oder in den Adressenbildungsregistern zugegriffen wird, und der inhaltsadressierbare Speicher werden vom Netzwerkbeschleuniger verwendet. Der Steuerprozessor im ULP liest nur die Werte, die erforderlich sind, um eine Nachschlagadresse zu konstruieren, um die Adresse eines erforderlichen Werts im CAM zu bestimmen. Wenn ein CAM-Nachschlagfehler während des Adressenbildungsprozesses auftritt, kann der Prozess abgebrochen werden und die ankommenden Pakete mit einem Fehlerflag markiert werden.
  • Es ist möglich, wenn die in jeder Stufe extrahierten Protokollfelder verschiedene Längen für verschiedene Protokolle aufweisen, den Eintrag aufzufüllen, um eine festgelegte Offsetgröße zu erhalten. Ungenutzte Bits füllen Speicheradressen bis zur festgelegten Große auf, um einen CAM-Nachschlag mit einer festgelegten Länge zu ermöglichen.
  • Die Dimensionen der Adressenbildungsregister können aufsummiert werden. Die zweite Stufe weist zwei Registereinträge, zwei CAM-Einträge und ein Paar von Positionsregistern für jeden Nachrichtenwarteschlangeneintrag auf. Die dritte Stufe weist acht Registereinträge, acht CAM-Einträge und acht Paare von Positionsregistern auf. Jedes Positionsregister umfasst 16 Bits, wobei 10 Bits den Offset repräsentieren, um 512 Bytes abzudecken, und 6 Bits für die Größe, um 64 Halbbytes zu repräsentieren.
  • Der im Adressenbildungsbereich geformte Wert wird zusammen mit der vorher in Reaktion auf die Ankunft von Paketen vom Steuerprozessor bzw. vom Applikationsprozessor gespeicherten Information verwendet, als eine Verbindung eingerichtet wurde, nämlich beim Eintreffen von Paketen, die eine Initialisierung einer Verbindung für die Übertragung von bestimmten Daten zwischen bestimmten Quellen- und Zielpunkten signalisiert haben. Der Steuerprozessor füllt den inhaltsadressierbaren Speicher (CAM) mit Einträgen. Jeder Eintrag im CAM bestimmt eine eindeutige Verbindung.
  • Wenn das System initialisiert wird, d. h. bevor eine beliebige Übertragungsverbindung aufgebaut wurde, gibt es keinen Eintrag im CAM. Daher wird, wenn ein erstes Paket ankommt, im Vergleich mit Adresseninformationen im CAM kein übereinstimmender Adressierungseintrag gefunden, und die Pakete werden tendenziell als CAM-Nachschlagfehler betrachtet. In diesem Fall wird eine spezielle Warteschlangen-ID (QID) dem Paket an einer Speicherposition zugeordnet, die für den Steuerprozessor, nämlich den Applikationsprozessor AAP, reserviert ist.
  • Der AAP kann den Bedarf an einem Aufbau einer Verbindung aufgrund einer Analyse des ankommenden Pakets bestimmen. Ein freier Eintrag wird im CAM gefunden, z. B. einer von 64 möglichen Strömen, welche das System gleichzeitig unterstützen kann. Die freie Eintragadresse wird verwendet, um die Verbindungstabelle für den neuen Strom aufzubauen. Der AAP schreibt die Verbindungsadresse in den freien Eintrag des CAM, so dass später ankommende Pakete mit der gleichen Adresse mit dem Eintrag im CAM übereinstimmen. Dies ermöglicht eine Verarbei tung der später ankommenden Pakete ohne Beteiligung des AAPs, weil die Pakete durch die erläuterte Netzwerkbeschleunigungsfunktion verarbeitet werden.
  • Wenn ein ankommendes Paket gefunden wird, das mit einer existierenden Verbindung mit einem Eintrag im CAM übereinstimmt, d. h. es liegt ein CAM-Treffer vor, wird die Adresse des übereinstimmenden CAM-Eintrags verwendet, um die Verbindungstabelleninformation, die QID und andere Informationen nachzuschlagen. Im erläuterten Beispiel sind 64 CAM-Einträge vorhanden, um 64 Verbindungen zu unterstützen. Jedem CAM-Eintrag sind bis zu 256 Bits zugeordnet. Selbstverständlich sind andere spezifische Werte möglich.
  • Auf die belegten CAM-Einträge und die freien CAM-Einträge kann vom Steuerprozessor AAP aus zugegriffen werden. Der Steuerprozessor AAP ist verantwortlich für den Aufbau, Abbau und die Wiederverwertung von CAM-Einträgen.
  • Das CAM-Bauelement selbst kann auf verschiedene Arten ausgeführt sein, die generell Register und Verknüpfungsarrangements aufweisen, die es ermöglichen, dass wenigstens eine Teilmenge der möglichen Eingabedatenwerte als Adresseneingaben verwendet werden können, um aus dem Speicher einen korrespondierenden Ausgabedatenwert zu extrahieren. Speicherbauelemente mit direktem Zugriff speichern typischerweise durch Adressierung von speziellen Speicherpositionen Daten und gewinnen sie wieder, wobei jeder mögliche Eingabewert mit einer Speicherposition korrespondiert. Eine große Anzahl von Adressenbits korrespondiert mit einer großen Anzahl von Speicherpositionen. Wenn die Anzahl von Speichereinträgen nicht zu groß ist, kann die erforderliche Zeitspanne zum Auffinden eines vorgegebenen Eintrags im Speicher durch Hardwareverknüpfungen, welche einen digitalen Vergleich mit einem Teil des im Speicher gespeicherten Dateninhalts er möglichen, anstatt durch Spezifizieren einer Speicheradresse reduziert werden. Ein Speicher auf den auf diese Weise zugegriffen wird, wird als inhaltsadressierbarer Speicher (CAM) bezeichnet und ist für einen Applikationstyp, wie dem beschriebenen, vorteilhaft.
  • In dem erläuterten Beispiel kann der CAM in der Breite der gespeicherten Werte von 4 bis 144 Bit variieren, und eine Tiefe von 6 bis 1024 Einträge aufweisen. In einer in 9 dargestellten Ausführungsform werden zwei verkettete CAM-Bauelemente bereitgestellt, wobei jedes ein Bauelement mit 64 Einträgen zu 129 Bits umfasst, um bis zu 64 bidirektionale Ströme zu unterstützen. Von den 129 Bits werden 128 Bits zur Datenspeicherung verwendet und ein Bit wird als Eintraggültigkeitsbit verwendet. Diese Anordnung, die ein 64 zu 256 CAM bildet, ist in 9 als ein vereinfachtes CAM-Nachschlaglogikdiagramm repräsentiert, wobei ein 256 Bit-Wort in zwei 128-Bit-Teilworte aufgeteilt wird, und jedes Teilwort mit dem Inhalt eines separaten CAM-Bauelements verglichen wird. Bei dieser Anordnung ist es möglich, dass das eine oder andere der 128-Bit-Teilworte mit mehreren Einträgen in jedem CAM-Bauelement übereinstimmt. Der gesamte 256-Bit-Eintrag kann jedoch nur mit einem eindeutigen gespeicherten Wert korrespondieren. Diese Operation kann durch koordiniertes Adressieren und Kaskadieren des Vergleichs der zwei CAM-Bauelemente erleichtert werden.
  • Wenn ein CAM-Treffer für ein ankommendes Paket vorhanden ist, wird die CAM-Adresse des Eintrags verwendet, der mit der ankommenden Adresse übereinstimmt, um auf die verschiedenen Informationswerte zuzugreifen, welche die Verbindung betreffen. Dies wird durch die nachfolgende Tabelle 1 umrissen. Tabelle 1
    Feldname Größe (Bits) Beschreibung
    QID 6 Warteschlangen-ID, wird zum Verkehrsmanagement verwendet, wenn kein Nachschlagproblem auftritt
    Header_Keep 1 Header_Keep-Bit, zeigt an, ob der ULP L2-, L3- und L4-Kopfabschnitte auftrennen soll, wenn die Pakete zum TMA gesendet werden. Es ist zu beachten, dass dieses Bit nur angelegt wird, wenn QID verwendet wird. Wenn ein Error_QID verwendet wird, wird der Kopfabschnitt immer gehalten.
    OOS_QID 6 ID für außerhalb der Warteschlangenreihenfolge: Diese QID wird für Pakete usw. verwendet, die außerhalb der Reihenfolge sind.
    Local Header Enable 1 Wenn gesetzt, wird der ULP einen lokalen Kopfabschnitt vor jedes ankommende Paket einsetzen.
  • Für einige Verbindungen wird ein lokaler Kopfabschnitt erzeugt und jedem ankommenden Paket vorangesetzt. Eine solche Kopfabschnitterzeugung ist durch den AAP konfigurierbar. Ein lokaler ULP-Kopfabschnitt wird erzeugt, wenn ein Paket vom Netzwerk ankommt. Der lokale Kopfabschnitt weist eine feste Größe von 32 Bits mit einem Format auf, das in 10 spezifiziert wird. Der ULP stellt die durch Zählen eines jeden empfangenen Paketbytes hergeleitete Paketlänge voran. Zusätzlich bettet es die Flags ein, die durch den Gigabit-Ethernet-Steuerschaltkreis und durch Nachschlagen im lokalen Kopfabschnitt selber erzeugt werden. Der ULP addiert den lokalen Kopfabschnitt solange mit dem gleichen Format, so lange der Kopfabschnitt unabhängig vom Paketziel freigegeben ist.
  • Die Erfindung wird beispielhaft durch eine Vorrichtung beschrieben, kann aber auch als ein erfindungsgemäßes Verfahren betrachtet werden. Unter Bezugnahme auf die dargestellten Figuren leitet die erfindungsgemäße Streaming-Vorrichtung, siehe 1, 2, 7, Datenpakete 22, welche Felder 24 aufweisen, welche wenigstens einen Steuerwert, eine Quellenadresse, eine Zieladresse und/oder einen Nutzlasttyp aufweisen, zwischen einer Quelle 27 und einem Ziel 29. Ein Kommunikationspfad 32 empfängt die Datenpakete von einem Server 27 oder ähnlichem, und wenigstens ein Inhaltsteil 33 der Datenpakete 22 wird zu wenigstens einem Client 35 geleitet, entsprechend den Regeln, welche von den Feldern des Datenpakets 22 bestimmt sind.
  • Die Regeln umfassen Alternativen, durch welche die Datenpakete zu einem oder mehr Clients über charakteristische Wege geleitet werden können, wie beispielsweise an verschiedene spezifische Geräte adressiert zu sein, durch verschiedene Protokollbehandlungsspezifikationen verarbeitet zu werden usw. Ein Steuerprozessor 39 ist mit dem Kommunikationspfad gekoppelt. Die Funktionen des Steuerprozessors können vollständig oder teilweise in einem Prozessor (ULP) für obere Schichten und/oder einem Applikationsprozessor (AAP) oder in einer zusätzlichen Steuereinheit bereitgestellt werden. In jedem Fall bestimmt der Steuerprozessor wenigstens teilweise Prozeduren, die für die wenigstens zwei Alternativen zum Verarbeiten der Pakete angewendet werden können, wenn eine Verbindung oder ein Strom aufgebaut werden.
  • Gemäß einem erfindungsgemäßen Aspekt, wird ein Netzwerkbeschleuniger 42, der einen Speicher 43 aufweist, mit dem Steuerprozessor 39 gekoppelt, der den Speicher 43 des Netzwerkbeschleunigers mit Daten lädt, die wenigstens zwei alternative Verfahren repräsentieren, durch welche Datenpakete auf charakteristische Weise weitergeleitet werden können. Die Verfahren umfassen, sind aber nicht darauf beschränkt, Weiterleiten der Pakete an charakteristische lokale Adressen oder Remoteadressen. Der nachfolgende Netzwerkbeschleuniger 42 arbeitet im Wesentlichen unabhängig vom Steuerschaltkreis 39, um die Datenpakete 22 zum Client 35 weiterzuleiten. Die Datenpakete 22 weisen Kopfabschnitte 24 auf, siehe 3, welche die Felder umfassen, und der Netzwerkbeschleuniger 42 wird in Abhängigkeit von den Feldern betrieben, um besagte Felder zu ersetzen und/oder zu ergänzen, um zwischen den wenigstens zwei Alternativen auswählen zu können.
  • Die Vorrichtung ist für die Handhabung des RTP-Echtzeitprotokoll-Streamings ausgebildet. Zusätzlich zu den Paketen, die Programminhalte aufweisen, wie beispielsweise Datenabtastwerte oder komprimierte Datenprogramme in RTP, umfassen die Datenpakete weiter Steuerinformationen gemäß dem RTSP- und/oder RTCP-Streaming-Steuerprotokoll.
  • In den bevorzugten Ausführungsformen enthält der Netzwerkbeschleuniger einen inhaltsadressierbaren Speicher, der Datenwerte aufweist, die beispielsweise für eine lokale Adressierung eines jeden ablaufenden Stroms, der aktiv ist, verwendet werden. Die Steuereinheit baut die Datenwerte auf, die für einen vorgegebenen Strom verwendet werden. Unter Verwendung des inhaltsadressierbaren Speichers werden wenigstens einige der gleichen Datenwerte in aufeinander folgenden Paketen desselben Stroms verwendet, ohne die rechnertechnischen Ressourcen des Steuerschaltkreises wesentlich in Anspruch zu nehmen, während gleichzeitig eine hohe Datenrate möglich ist, welche durch die Verwendung des Hardwarebeschleunigers ermöglicht wird, der den inhaltsadressierbaren Speicher enthält oder mit diesem gekoppelt ist.
  • Die entsprechenden Komponenten werden betrieben, um eine Verfahren zu realisieren, welches die Schritte umfasst: Aufteilen des Inhalts in Pakete mit zugehörigen Kopfabschnittsinformationen, welche wenigstens eine Variable repräsentieren, durch welche der in Pakete aufgeteilte Inhalt als Funktion der besagten Variablen selektierbar zwischen einer oder mehreren Quellen und einem oder mehreren Zielen übertragbar ist, einschließlich Steuerinformationen im Streaming-Inhalt, wobei die Art und Weise der selektierbaren Behandlung des in Pakete aufgeteilten Inhalts entsprechend den Steuerinformationen variabel ist, Aufbauen oder Umleiten, Pausieren oder anderweitiges Wechseln eines Stroms des in Pakete aufgeteilten Inhalts zwischen einer Quelle und einem Ziel, und nachfolgend Bestimmen eines Werts der Variablen wenigstens teilweise aus den Steuerinformationen und Speichern des besagten Wertes im Netzwerkbeschleuniger zusammen mit einer Identifikation des Stroms. Anschließend wird, wenn der in Pakete aufgeteilte Inhalte für einen Storm empfangen werden, der im Netzwerkbeschleuniger gespeicherte Wert, der zu der Identifikation des Stroms gehört, verwendet, um den empfangenen in Pakete aufgeteilten Inhalt zu bearbeiten.
  • Entsprechend wird der in Pakete aufgeteilte Inhalt des ankommenden Stroms selektiv in großen Teilen durch den Netzwerkbeschleuniger mit minimalem Aufwand durch den Steuerprozessors behandelt.
  • Die Erfindung wurde in Verbindung mit beispielhaften Ausführungsformen offenbart, der Schutzbereich ergibt sich jedoch durch die beigefügten Ansprüche.
  • Zusammenfassung
  • Eine hardwarebeschleunigte Streaming-Anordnung, insbesondere für RTP-Echtzeitprotokoll-Streaming, leitet Datenpakete für einen oder mehrere Ströme zwischen Quellen und Zielen unter Verwendung von Adressierungs- und Behandlungskriterien, die zum Teil von Steuerpaketen erzeugt und verwendet werden, um Kopfabschnitte zu modifizieren oder zu ergänzen, die den Datenpaketen zugeordnet sind. Ein programmierter Steuerprozessor reagiert auf Steuerpakete im RTCP- oder RTSP-Format, wobei die Behandlung oder Leitung von RTP-Paketen verändert werden kann. Der Steuerprozessor speichert Daten für die neuen Adressierungs- und Behandlungskriterien in einem Speicher, auf den ein Hardwarebeschleuniger zugreift, der dazu ausgebildet ist, die Kriterien für mehrere zur gleichen Zeit bestehende Ströme zu speichern. Wenn ein Datenpaket empfangen wird, werden dessen Adressierungs- und Behandlungskriterien im Speicher gefunden und durch Aktionen des Netzwerkbeschleunigers angewendet, ohne dass der Steuerprozessor beteiligt sein muss. Der Netzwerkbeschleuniger arbeitet wiederholt, um das Anwenden der Kriterien auf die Pakete für einen vorgegebenen Strom fortzusetzen, wenn der Strom fortgeführt wird, und kann mit einer hohen Datenrate betrieben werden. Der Prozessor kann dazu programmiert werden, die Kriterien auf eine vielseitige Weise zu überprüfen, einschließlich von aufwendigen Berechnungen, wenn dies erforderlich ist, da der Prozessor von den wiederholenden Verarbeitungsaufgaben entlastet wird, welche durch den Netzwerkbeschleuniger ausgeführt werden.

Claims (16)

  1. Streaming-Vorrichtung zum Übertragen von Datenpaketen mit Feldern, die einen Steuerwert, eine Ursprungsadresse, eine Zieladresse und/oder einen Nutzlasttyp repräsentieren, mit – einem Kommunikationspfad zum Empfangen der Datenpakete von einem Server, wobei entlang des Kommunikationspfads mindestens ein Teil eines Inhalts der Datenpakete zu mindestens einem Client in Abhängigkeit von Verfahren übertragen wird, die teilweise von den Feldern der Datenpakete bestimmt werden, – wobei die Verfahren mindestens zwei Alternativen umfassen, durch welche die Datenpakete zu dem mindestens einen Client auf mindestens zwei unterschiedliche Arten übertragbar sind, – einem Steuerprozessor, der mit dem Kommunikationspfad gekoppelt ist, wobei der Steuerprozessor dazu ausgebildet ist, eines der Verfahren zu bestimmen, das auf die jeweiligen Alternativen anzuwenden ist, – einem Netzwerkbeschleuniger mit einem Speicher, wobei der Steuerprozessor dazu ausgebildet ist, den Speicher des Netzwerkbeschleunigers mit Daten zu laden, welche die mindestens zwei Alternativen repräsentieren, durch welche die Datenpakete auf bestimmte Arten übertragen werden, und wobei der Netzwerkbeschleuniger nachfolgend dazu ausgebildet ist, im Wesentlichen unabhängig von dem Steuerprozessor die Datenpakete an den wenigstens einen Client auf die bestimmten Arten gemäß den zugehörigen Verfahren zu übertragen.
  2. Streaming-Vorrichtung nach Anspruch 1, wobei die Datenpakete Kopfabschnitte aufweisen, welche die Felder enthalten, und wobei der Netzwerkbeschleuniger dazu ausgebildet ist, in Abhängigkeit von den Feldern die Felder zu ersetzen und/oder anzufügen, um zwischen den mindestens zwei Alternativen auszuwählen.
  3. Streaming-Vorrichtung nach Anspruch 1, wobei die Datenpakete an den mindestens einen Client auf unterschiedliche Arten übertragen werden, einschließlich durch Ändern von Adressinformationen, die den Paketen zugeordnet sind.
  4. Streaming-Vorrichtung nach Anspruch 3, wobei die Datenpakete mit lokalen Adressen versehen sind, an welche die Datenpakete gemäß den Regeln zu übertragen sind.
  5. Streaming-Vorrichtung nach Anspruch 1, wobei die Datenpakete Inhaltspakete umfassen, die gemäß dem RTP-Streaming-Protokoll konfiguriert sind und die Adressinformationen umfassen, und wobei die Inhaltspakete durch den Netzwerkbeschleuniger mit Zusatz- oder Ersatzadressinformationen zur Verfügung gestellt werden.
  6. Streaming-Vorrichtung nach Anspruch 5, wobei die Datenpakete weiter Steuerinformationen gemäß dem RTSP- oder RTCP-Streaming-Steuerprotokoll umfassen.
  7. Streaming-Vorrichtung nach Anspruch 6, wobei Informationen in mindestens einigen der Datenpakete, die Steuerinformationen gemäß dem RTSP- oder RTCP-Streaming-Steuerprotokoll umfassen, gemäß einer Programmierung des Steuerprozessors dazu verwendet werden, Regeln zu definieren, durch welche die Inhaltspakete zu dem mindestens einen Client übertragen werden.
  8. Streaming-Vorrichtung nach Anspruch 7, wobei der Netzwerkbeschleuniger einen inhaltsadressierbaren Speicher umfasst, der durch den Steuerprozessor mit Informationen geladen wird, welche die Regeln definieren, und wobei der Netzwerkbeschleuniger auf eine vorgegebene Regel zugreift, die auf ein gegebenes Paket anzuwenden ist, indem er aus dem Speicher Daten liest, die gemäß der Programmierung des Steuerprozessors gespeichert sind.
  9. Streaming-Vorrichtung nach Anspruch 8, wobei die Datenpakete Audiodaten und/oder Videodaten repräsentieren und wobei sich die Regeln auf unterschiedliche geschaltete Prozesse eines Audio- oder Video-Speichers, eines Unterhaltungsgeräts, einer Audiokommunikationseinrichtung oder eines Telefons beziehen.
  10. Streaming-Vorrichtung nach Anspruch 9, wobei der Netzwerkbeschleuniger dazu ausgebildet ist, die Pakete an ein Zielgerät und an eine Netzwerkspeichervorrichtung gemäß den Regeln zu übertragen.
  11. Streaming-Vorrichtung nach Anspruch 9, wobei der Netzwerkbeschleuniger dazu ausgebildet ist, die Pakete gemäß den Regeln an ein Zielgerät umfassend ein Lesegerät, ein Speichergerät, einen Zwischendatenprozessor zum Übertragen der Pakete, ein lokales Terminal und ein Remoteterminal zu übertragen.
  12. Verfahren zum Streamen eines Inhalts im Wesentlichen gleichzeitig mit einer Echtzeitreferenz des Inhalts mit den Schritten: – Aufteilung des Inhalts mit zugehörigen Kopfabschnittsinformationen, die mindestens eine Variable repräsentieren, durch welche der in Pakete aufgeteilte Inhalt wählbar von einer und mehreren Quellen und von einem oder mehreren Zielen in Abhängigkeit von der Variablen gehandhabt wird, – Einfügen von Steuerinformationen in den Streaming-Inhalt, wobei die Art und Weise, wie der in Pakete aufgeteilte Inhalt wählbar gehandhabt wird, von den Steuerinformationen abhängt, – Ermöglichen eines Zugriffs auf die Steuerinformationen durch einen Steuerprozessor und Ermöglichen eines Zugriffs auf den in Pakete aufgeteilten Inhalt durch einen Netzwerkbeschleuniger, – beim Aufbauen, Umleiten, Pausieren oder bei einem anderen Ändern eines Streams des in Paketen aufgeteilten Inhalts zwischen der mindestens einen Quelle und dem mindestens einem Ziel, Bestimmen eines Werts der Variablen zumindest teilweise aus den Steuerinformationen und Speichern des Werts in dem Netzwerkbeschleuniger in Bezug auf eine Identifikation des Streams, – beim Empfangen eines in Pakete aufgeteilten Inhalts des Streams, Bestimmen des Wertes, der in Bezug auf die Identifikation des Streams gespeichert ist, von dem Netzwerkbeschleuniger und Handhaben des empfangenen in Pakete aufgeteilten Inhalts zwischen der einen oder den mehreren Quellen und dem einen oder den mehreren Zielen basierend auf dem Wert, der von dem Netzwerkbeschleuniger bestimmt worden ist, wobei der in Pakete aufgeteilte Inhalt eines fortlaufenden Stroms mit minimalem Aufwand durch den Steuerprozessor wählbar handhabbar ist.
  13. Verfahren nach Anspruch 12, weiter beinhaltend ein Ändern des in dem Netzwerkbeschleuniger gespeicherten Werts, wobei das Ändern durch eine Operation des Steuerprozessors vorgenommen wird.
  14. Verfahren nach Anspruch 13, wobei der Steuerprozessor den in dem Netzwerkbeschleuniger gespeicherten Wert als ein Ergebnis einer Verarbeitung von aufeinanderfolgend empfangenen Steuerinformationen ändert.
  15. Verfahren nach Anspruch 12, beinhaltend ein Bereitstellen einer Mehrzahl von identifizierten Streams mit Einträgen in dem Hardwarebeschleuniger, wobei der Hardwarebeschleuniger selektiv einen der Mehrzahl der in dem Hardwarebeschleuniger in Bezug auf einen korrespondierenden, identifizierten Stream gespeicherten Werte auf Inkremente des in Pakete aufgeteilten Inhalts anwendet.
  16. Verfahren nach Anspruch 15, beinhaltend ein Bereitstellen eines inhaltsadressierbaren Speichers, der eine Nachrichtenwarteschlange umfasst, wobei die Einträge der identifizierten Streams zugänglich sind, und beinhaltend ein Bestimmen des einen der mehreren Werte durch Vergleichen eines Eintrags mit einer Identifikation eines korrespondierenden der identifizierten Streams.
DE112006002644T 2005-10-07 2006-10-06 Mediendatenverarbeitung unter Verwendung von charakteristischen Elementen für Streaming- und Steuerprozesse Withdrawn DE112006002644T5 (de)

Applications Claiming Priority (13)

Application Number Priority Date Filing Date Title
US72446305P 2005-10-07 2005-10-07
US72446405P 2005-10-07 2005-10-07
US72446205P 2005-10-07 2005-10-07
US72506005P 2005-10-07 2005-10-07
US72472205P 2005-10-07 2005-10-07
US72457305P 2005-10-07 2005-10-07
US60/724,463 2005-10-07
US60/724,462 2005-10-07
US60/724,573 2005-10-07
US60/724,464 2005-10-07
US60/725,060 2005-10-07
US60/724,722 2005-10-07
PCT/US2006/039223 WO2007044562A1 (en) 2005-10-07 2006-10-06 Media data processing using distinct elements for streaming and control processes

Publications (1)

Publication Number Publication Date
DE112006002644T5 true DE112006002644T5 (de) 2008-09-18

Family

ID=37719120

Family Applications (2)

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
DE112006002677T Withdrawn DE112006002677T5 (de) 2005-10-07 2006-10-06 Verfahren und Vorrichtung für RTP-Ausgabe-Streaming unter Verwendung von komplementären Richtungsdateien

Family Applications After (1)

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

Country Status (6)

Country Link
US (2) US20080285571A1 (de)
JP (2) JP2009512280A (de)
KR (2) KR100926007B1 (de)
DE (2) DE112006002644T5 (de)
GB (2) GB2444675A (de)
WO (2) WO2007044563A1 (de)

Families Citing this family (60)

* 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
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
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
US8949470B2 (en) * 2007-12-31 2015-02-03 Genesys Telecommunications Laboratories, Inc. Federated access
US8904031B2 (en) 2007-12-31 2014-12-02 Genesys Telecommunications Laboratories, Inc. Federated uptake throttling
US9003051B2 (en) * 2008-04-11 2015-04-07 Mobitv, Inc. Content server media stream management
US8015310B2 (en) 2008-08-08 2011-09-06 Cisco Technology, Inc. Systems and methods of adaptive playout of delayed media streams
US7886073B2 (en) * 2008-08-08 2011-02-08 Cisco Technology, Inc. Systems and methods of reducing media stream delay
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
CN102577304B (zh) * 2009-08-12 2015-12-09 荷兰皇家Kpn电信集团 动态转发第一协议的消息的方法和系统及其控制节点
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
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
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
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 华为技术有限公司 一种多级流表查找方法和装置
US9275168B2 (en) 2013-07-19 2016-03-01 International Business Machines Corporation Hardware projection of fixed and variable length columns of database tables
US9235564B2 (en) 2013-07-19 2016-01-12 International Business Machines Corporation Offloading projection of fixed and variable length database columns
JP6268066B2 (ja) 2013-09-20 2018-01-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America 送信方法、受信方法、送信装置及び受信装置
US10121483B2 (en) 2013-11-27 2018-11-06 Telefonaktiebolaget Lm Ericsson (Publ) Hybrid RTP payload format
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
US9826071B2 (en) 2015-08-26 2017-11-21 Barefoot Networks, Inc. Configuring a switch for extracting packet header fields
US9825862B2 (en) 2015-08-26 2017-11-21 Barefoot Networks, Inc. Packet header field extraction
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
US10063407B1 (en) 2016-02-08 2018-08-28 Barefoot Networks, Inc. Identifying and marking failed egress links in data plane
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 삼성전자 주식회사 스트리밍 서비스를 제공하는 방법 및 장치
US11223520B1 (en) 2017-01-31 2022-01-11 Intel Corporation Remote control plane directing data plane configurator
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
US10601732B1 (en) 2017-07-23 2020-03-24 Barefoot Networks, Inc. Configurable packet processing pipeline for handling non-packet data
US10771387B1 (en) 2017-09-28 2020-09-08 Barefoot Networks, Inc. Multiple packet data container types for a 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
US12218773B2 (en) 2021-03-16 2025-02-04 Zoom Video Communications, Inc. Video conference acceleration
KR102814705B1 (ko) * 2022-11-07 2025-06-25 엑사비스 주식회사 효율적으로 데이터를 저장하는 네트워크 검사 방법 및 이를 수행하는 시스템
CN116016471B (zh) * 2023-01-06 2025-02-18 济南浪潮数据技术有限公司 视频平台的控制方法及相关组件

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
DE112006002677T5 (de) 2008-11-13
US20090147787A1 (en) 2009-06-11
KR20080068691A (ko) 2008-07-23
GB2444675A (en) 2008-06-11
WO2007044563A1 (en) 2007-04-19
KR20080068690A (ko) 2008-07-23
GB0805653D0 (en) 2008-04-30
GB2448799A (en) 2008-10-29
GB0805654D0 (en) 2008-04-30
KR100926007B1 (ko) 2009-11-11
WO2007044562A1 (en) 2007-04-19
JP2009512279A (ja) 2009-03-19
JP2009512280A (ja) 2009-03-19

Similar Documents

Publication Publication Date Title
DE112006002644T5 (de) Mediendatenverarbeitung unter Verwendung von charakteristischen Elementen für Streaming- und Steuerprozesse
DE602004003025T2 (de) Video-/audionetzwerk
DE60110002T2 (de) System zur Übertragung von Streaming-Daten und Zwischenverstärker dafür
DE602004008099T2 (de) Verfahren, system und artikel zur dynamischen echtzeit-stream-aggregation in einem netzwerk
DE60118269T2 (de) Verfahren und Vorrichtung zur Synchronisierung und Übertragung von Echtzeit-Medieninhalt in einem Paketnetz
DE69832247T2 (de) Auf einem verteilten Internet- Protokollen basierte Echtzeit- Multimedia- Datenströmungs- Architektur
DE602004011638T2 (de) Verringern von Pufferanforderungen in einem Nachrichtenübermittlungssystem
DE69925004T2 (de) Kommunikationsverwaltungssystem für computernetzwerkgestützte telefone
DE69812777T2 (de) Verbindung von Ethernetkompatiblen Netzwerken
DE60131890T2 (de) Dynamische Delta-Kopierung für Kabelmodemkopffeldunterdrückung
DE69933281T2 (de) Verfahren und Vorrichtung zur Mediendatenübertragung
DE60222581T2 (de) Datenübertragung
DE60103005T2 (de) Datenstrom in einer peer-to-peer Architektur
DE602005001815T2 (de) Verfahren zur effizienten Mehrfachverbreitung von Inhalten in einem Peer-to-peer Netzwerk
DE112020006664T5 (de) Auslagerung der streaming-protokoll-paket-bildung
US20040240446A1 (en) Routing data
US20040255329A1 (en) Video processing
DE112012002159T5 (de) Kontextsensitive Client-Pufferschwellenwerte
DE112012001770T5 (de) Auf Echtzeitverarbeitungsfähigkeit basierende Qualitätsanpassung
DE60212383T2 (de) Verfahren zur Übertragung von Datenströmen mit Datensegmenten variabler Länge
DE112011101911T5 (de) Fragmentierte Dateistruktur für die Ausgabe von Live-Medien-Streams
DE69937830T2 (de) Vorrichtung und Verfahren zur Komprimierung von Mehrfahrnachrichten-Zieladressen
CN101352012A (zh) 使用不同元件对流进行媒体数据处理以及控制方法
DE102011078021A1 (de) Vorrichtung und Verfahren zum Schalten von Echtzeitmedienströmen
Liao WebCanal: a multicast Web application

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8128 New person/name/address of the agent

Representative=s name: BLUMBACH ZINNGREBE, 64283 DARMSTADT

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee

Effective date: 20110502