DE19681223B4

DE19681223B4 - Videotelekonferenzsystem mit digitaler Umcodierung

Info

Publication number: DE19681223B4
Application number: DE19681223T
Authority: DE
Inventors: Mark D. Polomski
Original assignee: Tandberg Telecom AS
Current assignee: Tandberg Telecom AS
Priority date: 1995-01-27
Filing date: 1996-01-16
Publication date: 2008-05-29
Anticipated expiration: 2016-01-17
Also published as: US5600646A; GB2312807B; IL116905A0; GB2312807A8; WO1996023388A1; DE19681223T1; GB9715337D0; AU4698796A; GB2312807A; IL116905A

Abstract

Mehrpunktsteuereinheit zum Empfangen von komprimierten Videosignalen von Terminals in einer Konferenz und zum Übertragen bzw. Senden von ausgewählten komprimierten Videosignalen zu den Terminals, wobei die Mehrpunktsteuereinheit folgendes umfaßt:
Decodiermittel (102) zum Decodieren der komprimierten Videosignale von jeweiligen Terminals zu unkomprimierten Videosignalen auf einem Pixel- bzw. Bildelementgebiet;
einen Zeitmultiplexbus, der die unkomprimierten Videosignale in Zeitkanälen bzw. -schlitzen, welche jeweiligen Terminals zugeordnet sind, empfängt, wobei der Bus ein Parallelpixel- bzw. -bildelementbus (82) ist;
Selektor- bzw. Wählmittel zum Auswählen von unkomprimierten Videosignalen aus einem oder mehreren Zeitkanälen bzw. -schlitzen des Zeitmultiplexbusses; und
Codiermittel (106) zum Codieren der ausgewählten unkomprimierten Videosignale für die Übertragung bzw. das Senden zu jeweiligen Terminals,
worin das Codiermittel (106) Bewegungsverlagerungs- bzw. -verschiebungsvektoren empfängt, die den ausgewählten unkomprimierten Videosignalen zur Bewegungsabschätzung zugeordnet sind.

Description

Hintergrund der Erfindung
Videotelekonferenzsysteme ermöglichen einen gleichzeitigen Austausch von Audio-, Video- und Dateninformation zwischen mehreren bzw. vielen audiovisuellen Terminals. Als Mehrpunktsteuereinheiten (MCUs) bekannte Systeme führen Schaltfunktionen aus, um es drei oder mehr audiovisuellen Terminals zu ermöglichen, in einer Konferenz miteinander verbunden zu sein. Die zentrale Funktion einer MCU ist es, mehrere bzw. viele Videotelekonferenzorte durch Empfangen von Datenübertragungsblöcken aus Digitalsignalen von audiovisuellen Terminals, Verarbeiten der empfangenen Signale und Wiederübertragen der verarbeiteten Signale zu geeigneten audiovisuellen Terminals als Datenübertragungsblöcke aus Digitalsignalen miteinander zu verbinden. Die Digitalsignale können Audio-, Video-, Daten- und Kontroll- bzw. Steuerinformation enthalten. Videosignale von zwei oder mehr audiovisuellen Terminals können räumlich gemischt werden, um ein zusammengesetztes Videosignal für die Betrachtung durch Telekonferenzteilnehmer zu bilden.
Fortschritte in den digitalen Datenübertragungen haben zu der Ausbreitung von digitalen audiovisuellen Terminals mit Codecs geführt, welche Datenkomprimierung verwenden. Der Telekommunikationsstandardierungssektor (TSS) der Internationalen Telekommunikationsunion (International Telecommunication Union) hat eine Reihe von Empfehlungen für das Durchführen von Videotelekonferenzen spezifiziert, die als die H-Reihe (H-Series) bekannt ist. Die H-Reihe umfaßt H.221, das die Datenübertragungsblockstruktur definiert, H.261, das die Videocodierung und -decodierung definiert, H.231, das Mehrpunkt- bzw. -stellensteuereinheiten definiert, und H.320 das audiovisuelle Terminals definiert. Auf Standards basierende Komprimierungsalgorithmen (zum Beispiel H.261) sind dabei, weit verbreitet zu werden. Jedoch gibt es viele Inhaberalgorithmen, für welche bessere Qualitäts- oder Komprimierungsraten beansprucht werden. Es ist daher wünschenswert, Terminals zu verbinden, die inkompatible Komprimierungsalgorithmen haben. Die typische MCU kann mehrere bzw. viele Konferenzen unterstützen, wobei separate Konferenzen unterschiedliche Videokomprimierungsalgorithmen, Audiocodierungsalgorithmen, Übertragungsraten und Protokolle haben können. Da die Hardwarecharakteristika der audiovisuellen Terminals typischerweise unterschiedlich voneinander sind (Übertragungsrate, Komprimierungsalgorithmus, Protokoll oder Auflösung), ist es unglücklicherweise gewöhnlich nicht möglich gewesen, unterschiedliche audiovisuelle Terminals in einer einzigen Konferenz miteinander zu verbinden. Wegen dieser Beschränkungen haben die Teilnehmer der kostenaufwendigen Aufgabe des Installierens von mehreren Arten von Ausrüstung gegenübergestanden, welche unterschiedlichen Komprimierungsalgorithmen oder Übertragungsraten zugeordnet sind.
Es gibt netzwerkbasierende Dienste, die von Austauschträgern angeboten werden, welche ein Umcodieren zwischen unterschiedlichen Komprimierungsalgorithmen von audiovisuellen Terminals in einer Konferenz ermöglichen. Diese bekannten Umcodierungsdienste arbeiten dahingehend, daß erst komprimierte Signale von jedem audiovisuellen Terminal gemäß seinem jeweiligen Komprimierungsalgorithmus decodiert und dann die resultierenden nichtkomprimierten Signale in Analogsignale umgewandelt werden. Zum Beispiel kann das Analogsignal, das von einem Terminal A erzeugt worden ist, der einen Codierungsalgorithmus X hat, mittels eines Algorithmus Y codiert werden, welcher dem Terminal B zugeordnet ist, so daß demgemäß ein Umcodieren zwischen ungleichen Terminals A und B erreicht wird. Ein solches Analogumcodierungsschema kann auch die Anpassung von Übertragungsraten zwischen unterschiedlichen Codecs verwendet werden.
Aus Lukacs, „The Personal Presence System – Hardware Architecture", Proceedings der ACM Multimedia 1994, Seiten 69-76 ist ein Videokonferenzsystem mit einer Mehrpunktsteuereinheit bekannt, bei welchem die verschiedenen Teilnehmer mit parallelen Verkabelungen mit einer zentralen Einheit verbunden sind.
Weitere Konferenzsysteme sind aus der US 5,072,442 , aus Willebeek-LeMair et al. „On Multipoint Control Units for Videoconferencing", Proceedings der 19th Conference an Local Computer Networks, IEEE 1994, Seiten 356-364 und Horn et al, "A Standards-Based Multimedia Conferencing Bridge", AT&T Technical Journal, Januar/Februar 1993, Seiten 41-49 bekannt.
Abriß der Erfindung
Diesbezüglich stellt die Erfindung eine Mehrpunktsteuereinheit nach Anspruch 1 oder 6, eine Videoverarbeitungseinheit nach Anspruch 10, ein Videotelekonferenzsystem nach Anspruch 14 oder 18 und eine Einrichtung nach Anspruch 19 bereit. Die abhängigen Ansprüche definieren jeweils weitere Ausführungsbeispiele.
Ein Nachteil des Analogumcodierens ist die Signalverschlechterung aufgrund mehrfacher Analog-zu-digital-Umwandlungen. Das räumliche Mischen von Videosignalen von audiovisuellen Terminals, die unterschiedliche Übertragungsraten und Auflösungen haben, führt zu einem zusammengesetzten Videosignal mit der niedrigsten gemeinsamen Auflösung. Die vorstehenden Probleme werden gelöst durch ein Videotelekonferenzsystem, das eine Prozessoranordnung bzw. -einrichtung zum Ausführen einer Algorithmusumcodierung und Übertragungsratenanpassung von digitalen Videosignalen von ungleichartigen bzw. unähnlichen audiovisuellen Terminals hat.
Eine Mehrpunktsteuereinheit empfängt komprimierte Videosignale von audiovisuellen Terminals und überträgt ausgewählte komprimierte Videosignale zu den audiovisuellen Terminals. Die MCU umfaßt Decodiermittel zum Decodieren der komprimierten Videosignale von jeweiligen Terminals und einen Zeitmultiplexbus, der decodierte Videosignale in Zeitkanälen bzw. -schlitzen empfängt, die jeweiligen Terminals zugeordnet sind. Die MCU umfaßt Wählmittel zum Auswählen von decodierten Videosignalen aus Zeitschlitzen bzw. -kanälen des Zeitmultiplexbusses zum Codieren durch Codierungsmittel für die Übertragung zu jeweiligen Terminals.
Demgemäß umfaßt das Videotelekonferenzsystem in einer bevor zugten Ausführungsform eine Mehrpunktsteuereinheit (MCU) zum Ermöglichen, daß eine Mehrzahl von audiovisuellen Terminals, welche komprimierte digital Datensignale senden und empfangen, in einer Konferenz miteinander kommunizieren. Die MCU umfaßt eine Videoverarbeitungseinheit (VPU), welche eine Algorithmusumcodierung und Übertragungsratenanpassung zwischen den audiovisuellen Terminals innerhalb einer Konferenz ausführt. Die VPU umfaßt einen Zeitmultiplexpixel- bzw. -bildelementbus, eine Pixel- bzw. Bildelementbussteuereinrichtung und eine Mehrzahl von Prozessoren. Der Pixel- bzw. Bildelementbus hat eine Mehrzahl von Zeitkanälen zum Transportieren von nichtkomprimierten Videosignalen. Jeder Prozessor, der irgendeinem audiovisuellen Terminal in der Konferenz zuteilbar ist, ist an den Pixel- bzw. Bildelementbus angekoppelt und wenigstens einem Zeitkanal zugeordnet.
In einem Empfangsmodus empfängt und decodiert jeder Prozessor komprimierte Videosignale von seinem zugeordneten audiovisuellen Terminal. Die unkomprimierten Videosignale werden dann wahlweise auf eine wünschenswerte Auflösung skaliert bzw. normiert bzw. maßstäblich geändert und in wenigstens einen Zeitkanal, der dem Prozessor zugeordnet ist, eingegeben.
In einem Übertragungs- bzw. Sendemodus empfängt jeder Prozessor unkomprimierte Videosignale von irgendeinem Zeitkanal, der irgendeinem Prozessor in der gleichen Konferenz zugeordnet ist. Die unkomprimierten Videosignale werden wahlweise auf eine wünschenswerte Auflösung skaliert bzw. normiert bzw. maßstäblich geändert und dann zur Übertragung zu dem audiovisuellen Terminal, der dem Prozessor zugeordnet ist, codiert.
Der Pixel- bzw. Bildelementbus stellt eine Stelle der Flexibilität für das Erreichen einer Algorithmusumcodierung und Übertragungsratenanpassung zur Verfügung. Durch Decodieren von komprimierten Videosignalen und Plazieren der unkomprimierten Videosignale in Zeitkanälen auf dem Pixel- bzw. Bildelementbus werden die unkomprimierten Videosignale unabhängig von ihren jeweiligen Quellen-Terminalkomprimierungsalgorithmen gemacht und sind demgemäß für das Codieren gemäß irgendeinem Empfangs-Terminalkomprimierungsalgorithmus verfügbar. Demgemäß kann die Decodierung und Codierung in jedem Prozessor einen Komprimierungsalgorithmus umfassen, der jenem seines jeweiligen zugeordnet audiovisuellen Terminals entspricht bzw. damit übereinstimmt, und die Komprimierungsalgorithmen der Prozessoren in der Konferenz können unterschiedlich sein. Dieser Aspekt der Erfindung ermöglicht eine Algorithmusumcodierung zwischen audiovisuellen Terminals.
Gemäß einem anderen Aspekt der vorliegenden Erfindung kann jeder der audiovisuellen Terminals in einer Konferenz mit einer unterschiedlichen Übertragungsrate arbeiten. Jeder Prozessor decodiert komprimierte Videosignale mit einer Datenrate, die seinem zugeordneten audiovisuellen Terminal entspricht bzw. damit übereinstimmt. Die unkomprimierten Videosignale werden in Zeitkanälen des Pixel- bzw. Bildelementbusses plaziert und sind für das Codieren mit unterschiedlichen Datenraten verfügbar, die jeweiligen empfangenden audiovisuellen Terminals entsprechen bzw. damit übereinstimmen. Da die Videosignale auf dem Pixel- bzw. Bildelementbus unkomprimierte Datenübertragungsblöcke von Videodaten sind, beeinträchtigt der Verlust von Videodatenblöcken bei langsamer Wiedergewinnung durch einen Prozessor niedriger Rate einerseits oder die Wiederholung von Videodatenblöcken bei schneller Wiedergewinnung durch einen Prozessor hoher Rate andererseits nicht die Deutlichkeit bzw. Verständlichkeit der Videosignale, die für jeweilige empfangende Terminals codiert sind. Demgemäß empfängt jeder Terminal Videosignale mit der besten Bildauflösung für seine zugeordnete Datenübertragungsrate.
In einem anderen Aspekt der vorliegenden Erfindung wird ein kontinuierliche Präsenz ermöglicht, wobei Videosignale von mehreren bzw. vielen Konferenzorten räumlich gemischt werden, um ein zusammengesetztes Signal zu bilden. Demgemäß umfaßt jeder Prozessor weiter Mittel zum räumlichen Mischen einer Mehrzahl von unkomprimierten Videosignalen. Unkomprimierte Videosignale aus mehreren Zeitkanälen, die mehreren audiovisuellen Terminals zugeordnet sind, werden dem Pixel- bzw. Bildelementbus entnommen, codiert und zu einem zusammengesetzten Videosignal für die Übertragung zu einem jeweiligen zugeordneten audiovisuellen Terminal verfliest. Das Codieren des zusammengesetzten Videosignals geschieht mit der Datenrate, welche dem jeweiligen zugeordneten audiovisuellen Terminal angepaßt ist bzw. damit übereinstimmt. Demgemäß erreichen die Systeme selbst bei räumlichem Mischen das gleichzeitige Betrachten der Teilnehmer mit den höchstmöglichen Datenraten der jeweiligen audiovisuellen Terminals in der Konferenz.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird der Teil an Zeit, welcher zum Wiedercodieren eines Videostroms aufgrund von Bewegungsverlagerungssuche erforderlich ist, reduziert, und zwar entweder durch Wiederverwendung der Verlagerungsinformation von dem eintreffenden komprimierten Videostrom für die Bewegungskompensation in dem Codierer oder als ein Startparameter für weitere Verfeinerungen auf dem Bewegungsverlagerungsgebiet.
Die obigen und andere Merkmale der Erfindung, die verschiedene neuartige Details des Aufbaus und der Kombinationen von Teilen umfassen, werden nun spezieller unter Bezugnahme auf die beigefügten Zeichnungen beschrieben und in den Ansprüchen herausgestellt. Es versteht sich, daß das spezielle Videotelekonferenzsystem, welches die Erfindung verkörpert, als Veranschaulichung und nicht als eine Beschränkung der Erfindung gezeigt ist. Die Prinzipien und Merkmale dieser Erfindung können in veränderten und zahlreichen Ausführungsformen angewandt werden, ohne den Bereich der Erfindung zu verlassen.
Kurze Beschreibung der Zeichnungen
1 veranschaulicht schematisch ein Videotelekonferenzsystem, das mehrere bzw. viele audiovisuelle Terminals hat, die durch eine Anzahl von Netzwerken mit einer MCU verbunden sind.
2 ist ein Blockschaltbild einer MCU-Konfiguration.
3 ist ein Blockschaltbild einer Brückenverarbeitungseinheit der MCU-Konfiguration der 2.
4 ist ein Blockschaltbild einer Datenverarbeitungseinheit der MCU-Konfiguration der 2.
5 ist ein schematisches Blockschaltbild einer Ausführungsform einer VPU.
6 ist ein Blockschaltbild einer MCU-Konfiguration, welches den Datenfluß für Anwendungen kontinuierlicher Präsenz und kontinuierlicher Ratenanpassung veranschaulicht.
7 ist ein Blockschaltbild, welches das Bildverfliesen in einer Anwendung kontinuierlicher Präsenz veranschaulicht.
8 ist ein Blockschaltbild, das die Ratenanpassung unter Verwendung der Pixel- bzw. Bildelementbusanordnung bzw. -einrichtung veranschaulicht.
9 ist ein Blockschaltbild einer MCU-Konfiguration, welche den Datenfluß für eine Algorithmusanpassungsanwendung veranschaulicht.
10 ist ein Blockschaltbild, welches die Algorithmusanpassung unter Verwendung der Pixel- bzw. Bildelementbusanordnung bzw. -einrichtung veranschaulicht.
11A und 11B sind schematische Blockschaltbilder einer bevorzugten Ausführungsform der VPU.
12 ist ein funktionelles Blockschaltbild eines Videokomprimierungsprozessors (VCP).
13 ist ein schematisches Blockschaltbild einer Zeitmultiplex(TDM)-Busschaltanordnung der VPU der 12.
14 ist eine Veranschaulichung eines wählbaren interessierenden Bereichs innerhalb einer Pixel- bzw. Bildelementfläche.
15 ist ein schematisches Blockschaltbild der Steuersignal-Schnittstellen der Pixel- bzw. Bildelementbussteuereinrichtung der VPU der 12.
16 ist ein schematisches Blockschaltbild der Steuerlogik der Pixel- bzw. Bildelementbussteuereinrichtung der 15.
17 ist ein schematisches Blockschaltbild der VCP-Ausgangssteueranordnung bzw. -einrichtung.
18 ist ein Zeitsteuerungsdiagramm der Ausgangssteuersignale für die Anordnung bzw. Einrichtung der 17.
19 ist ein Ablaufdiagramm der Ausgangsunterbrechungshantiererroutine.
20 ist ein schematisches Blockschaltbild der VCP-Eingangssteueranordnung bzw. -einrichtung.
21 ist ein Zeitsteuerungsdiagramm der Eingangssteuersignale für die Anordnung bzw. Einrichtung der 20.
22 ist ein Ablaufdiagramm der Eingangsunterbrechungshantiererroutine für Umcodierungsanwendungen.
23 ist ein Ablaufdiagramm der Eingangsunterbrecherhantiererroutine für Anwendungen kontinuierlicher Präsenz.
24 ist ein Ablaufdiagramm des Hauptprogramms für den Codec-Betrieb in den VCPs.
25 ist ein Blockschaltbild, welches die Wiederverwendung von Bewegungskompensationsinformation durch einen Codierer veranschaulicht.
Detaillierte Beschreibung der Erfindung
Es sei auf 1 Bezug genommen, worin ein Videotelekonferenzsystem gezeigt ist, in dem audiovisuelle Terminals A, B mit einer MCU 10 durch eine Anzahl von Verbindungsnetzwerken 12 verbunden sind, wobei jedes Netzwerk eine spezielle Art von Zugangsschnittstelle 14 zu der MCU 10 hat, zum Beispiel V.35/RS-449 für private Netzwerke, PRI für ISDN-Netzwerke und T1-Zugang für geschaltete 56-Netzwerke. Die eine Konferenz besteht aus mit einer Datenrate arbeitenden audiovisuellen Terminals A, die durch ihre jeweiligen Verbindungsnetzwerke mit der MCU 10 verbunden sind, während eine andere Konferenz gleichartig bzw. ähnlich konfigurierte audiovisuelle Terminals B umfaßt, die mit einer anderen Datenrate arbeiten.
2 veranschaulicht die MCU 10 installiert in einem auf einem Verarbeitungsrechner 80386 oder 80486 basierenden PC. Es gibt vier Hauptkomponenten in der MCU 10: wenigstens eine Netzwerkschnittstelleneinheit (NIU) 20, wenigstens eine Brückenverarbeitungseinheit (BPU) 22, eine Verarbeitungsrechner-Verarbeitungseinheit (HPU) 24 und wenigstens eine Videoverarbeitungseinheit (VPU) 26. Außerdem unterstützt die MCU 10 eine wahlweise Datenverarbeitungseinheit (DPU) 28. Jede dieser Komponenten ist eine Digitaleinrichtung zum Verarbeiten von Digitaldaten. Zusätzlich zu einem Verarbeitungsrechner-Industriestandardarchitektur(ISA)-Bus 32 umfaßt die MCU 10 einen Netzwerkbus 34 und einen BPU-Bus 36. Der Netzwerkbus 34 erfüllt das Multi-Vendor-Integrationsprotokoll (MVIP), während der BPU-Bus 36 ein Abkömmling der MVIP-Spezifikation ist. Externe audiovisuelle Terminals oder Codecs 38 verbinden mit der MCU 10, um Konferenzen zu bilden.
Der MCU-Betrieb wird nun bei einem Hochniveau mit Bezug auf 2 beschrieben. Jeder Codec 38, typischerweise ein H.320 audiovisueller Terminal, verbindet mit dem MCU 10 durch ein Kommunikationsnetzwerk. Unsynchronisierte Digitaldaten-Datenübertragungsblöcke bzw. -rahmen von jedem Codec 38 werden auf dem Netzwerkbus 34 durch NIUs 20 verfügbar gemacht. Die BPUs 22 verarbeiten die unsynchronisierten Datenübertragungsblöcke bzw. Datenrahmen von dem Netzwerkbus 34, um Datenübertragungsblöcke bzw. Datenrahmen zu erzeugen, die in einem Oktettrahmen ausgerichtet sind, welche anderen BPUs 22 auf dem BPU-Bus 36 verfügbar gemacht werden. Die BPUs 22 fragen außerdem Audioinformation aus den Datenübertragungsblöcken ab. Die Audioinformation wird zu PCM-Daten decodiert und auf dem BPU-Bus 36 zum Mischen mit Audio von anderen Codecs 38 durch jeweilige BPUs 22 in einer Konferenz verfügbar gemacht. Die BPUs 22 kombinieren komprimierte Videoinformation und gemischte codierte Audioinformation zu Datenübertragungsblöcken, welche zur Übertragung zu jeweiligen Codec 38 auf dem Netzwerkbus 34 plaziert werden. Die wahlweise DPU 28 führt Verarbeitungsfunktionen ähnlich bzw. gleichartig den BPUs 22 aus, um audiovisuelle Terminals zu unterstützen, die PCS-(Intel)-Codecs haben.
In einer Standardkonferenz führen die BPUs 22 ein Videoschalten bzw. -umschalten innerhalb einer Konferenz aus durch Auswählen von Videodaten-Datenübertragungsblöcken bzw. -rahmen aus Zeitkanälen auf dem BPU-Bus 36 und Leiten der Datenübertragungsblöcke bzw. -rahmen zu jeweiligen Codecs 38 in der Konferenz. Eine spezielle BPU 22 wählt die geeigneten Videodaten-Datenübertragungsblöcke bzw. -rahmen basierend auf einem MCU-Konferenzauswahlprozeß aus. Typischerweise basiert der Auswahlprozeß auf einem Vergleich der Stimmenniveaus der Konferenzorte. Der lauteste Konferenzort wird als die gegenwärtige Rundfunkstation festgelegt, die von allen anderen Konferenzorten gesehen werden soll, während die gegenwärtige Rundfunkstation typischerweise einen anderen Ort sieht. In alternativen Konferenzauswahlprozessen wählt ein MCU-Operateur oder ein spezieller audiovisueller Terminal, der in einem Vorsitz kontroll- bzw. -steuermodus arbeitet, einen Ort als die gegenwärtige Rundfunkstation.
In Fällen, in denen die audiovisuellen Terminals mit unterschiedlichen Übertragungsraten oder mit unterschiedlichen Komprimierungsalgorithmen arbeiten oder zu einem gemeinsamen Bild gemischt werden sollen, werden die Videodaten weiter durch die VPUs 26 verarbeitet, bevor sie durch die BPUs zurückkehren. Wie unten im Detail erörtert wird, fragen die VPUs 26 komprimierte Videoinformation aus den ausgerichteten Datenübertragungsblöcken bzw. Datenrahmen auf den BPU-Bus 36 ab. Die komprimierte Videoinformation wird decodiert und auf einem Pixel- bzw. Bildelementbus plaziert, der für jede VPU 26 lokal ist. Die decodierte Videoinformation auf dem Pixel- bzw. Bildelementbus wird zum Codieren in der VPU 26 für Anwendung des Algorithmusumcodierens, des räumlichen Mischens und der Übertragungsratenanpassung verfügbar gemacht. Die codierte Videoinformation wird dann auf dem BPU-Bus 36 zur weiteren Verarbeitung durch die BPUs 22, wie in der Standardkonferenzanordnung bzw. -einrichtung, plaziert. Das gemischte kodierte Audio kann im Speicher verzögert werden, um die Zeit zu kompensieren, die für das Verarbeiten der Videoinformation in der VPU 26 gebraucht worden ist.
Der MVIP-befolgende Netzwerkbus 34 umfaßt acht voll-duplex, serielle Zeitmultiplex-125μs-Datenströme, welche dem Mitel ST-BUS (Serial Telecom) allgemeine Einrichtungsspezifikation (Generic Device Specification) angehören. Jeder Datenstrom arbeitet mit 2 Mbit/s und ist in 32 separate Zeitkanäle unterteilt. Die Gesamtkapazität des Busses ist daher 256 Zeitkanäle, wobei jeder Zeitkanal eine Kapazität von 64 Kbit/s hat. Zusätzlich dazu, daß sie in Zeitmultiplex innerhalb eines Datenstroms sind, sind die digitalen Daten im Raummuliplex über die Datenströme. Auf diese Weise kann ein Datenübertragungsblock bzw. -rahmen aus digitalen Daten von einem Kommunikationsnetzwerk über irgendeinen der 256 Zeitkanäle für Intra-MCU-Kommunikationen im Multiplex übertragen werden.
Der MVIP-abgeleitete BPU-Bus 36 ist ein TDM-Serienbus, der fähig ist, sechzehn Ströme zu handhaben. In einer Ausführungsform arbeitet jeder Strom mit 2 Mit/s und hat 32 Zeitkanäle, jeder Zeitkanal mit 64 Kbit/s für eine Gesamtheit von 322 Mbit/s-Übertragungsrate. In einer anderen Ausführungsform, die mit 4 Mit/s arbeitet, gibt es 64 Zeitkanäle in jedem Strom, und zwar für eine Gesamtheit von 64 Mbit/s.
Der HPU 24 stellt eine Management-Schnittstelle zu einer Arbeitsstation (nicht gezeigt) für MCU-Operationen zur Verfügung. Durch die HPU 24 kann eine Bedienungsperson den Betrieb der anderen Komponenten steuern und managen. Die HPU 24 steuert den Aufbau bzw. die Organisation und die Versorgung bzw. Etablierung von Konferenzen und führt Überwachungs- und Aufrechterhaltungs- bzw. Wartungsfunktionen aus.
Jede NIU 20 verbindet die MCU 10 mit einem speziellen Kommunikationsnetzwerk zu einem speziellen Codex 38 durch einen geeigneten Schnittstellenport bzw. -anschluß. Die NIU 20 bildet formatiert digitalen Datenrahmen bzw. Datenübertragungsblöcke, die zwischen der MCU 10 und den Codecs 38 laufen, zur Übertragung innerhalb der MCU 10 und über die verschiedenen Kommunikationsnetzwerke. Da die MCU viele Codec-Verbindungen gleichzeitig unterstützt, begünstigen die Tarife gewöhnlich die Nutzung von Multiplex-Hochgeschwindigkeitsschnittstellen. Die üblichste Art der NIU 20 unterstützt eine einzige T1- oder ISDN-Primärratenschnittstelle, über welche der Netzwerkservice (zum Beispiel ein Kommunikationsträger) im Zeitmultiplex eine Anzahl von individuellen Codec-Verbindungen erstellt hat. Die MCU 10 kann außerdem NIUs aufweisen, welche Schnittstellenports bzw. -anschlüsse haben, die nur eine einzelne Codec-Verbindungen unterstützen. Die Datenübertragungsblock- bzw. Rahmenstruktur für die Daten, die zwischen der MCU 10 und den Codecs 38 ausgetauscht werden, ist in TSS Rec. H.221 definiert. Jede NIU 20 reformatiert die Digitaldatenbilder bzw. -datenübertragungsblöcke von der hereinkommenden Leitung zu einem internen MCU-Format, das unabhängig von den individuellen Codec-Schnittstellen zu dem Kommunikationsnetzwerk ist. Die Daten, die reformatiert worden sind, werden dann im Multiplex auf die Netzwerkbuskanäle zur Übertragung zu den BPUs 22 gegeben.
Die TSS-Empfehlungen der H-Serien spezifizieren, daß die Videodaten zwischen Codecs geschaltet bzw. umgeschaltet werden sollen, aber sie spezifizieren nicht, wie eine MCU die Schaltfunktion ausführt. Die in 2 gezeigte MCU 10 führt das Videoschalten als Zeit- und Raummultiplex-Vorgang anstelle eines Analogsignalauswahlschaltens aus. Die BPUs 22 handhaben das Videoschalten innerhalb von Konferenzen durch Auswählen und Leiten von Digitaldaten in Zeit- und Raummultiplex.
Jede BPU 22 kann vier Codecs (audiovisuelle Terminals) unterstützen, und mehrere bzw. viele BPUs können durch den BPU-Bus 36 verbunden sein. Für jede Codec-Verbindung führt die BPU 22 ein Demultiplexen der Digitaldatenrahmen bzw. -datenübertragungsblöcke von dem Netzwerkbus 34 aus, mischt die digitalen Audiodaten und führt ein Multiplexen neuer Digitaldatenrahmen bzw. -datenübertragungsblöcke auf den Netzwerkbus 34 aus, und zwar aus den gemischten digital Audio- und den geeigneten digitalen Video- und Konferenzdaten.
Eine detailliertes Blockschaltbild der BPU 22 ist in 3 veranschaulicht. Die BPU 22 ist in vier Abteilungen (A, B, C, D) segmentiert, wobei jede Abteilung ein Paar Digitalsignalprozessoren (DSP) 40, 42 hat, die einem speziellen Codec zuteilbar sind. Jede BPU-Abteilung (A, B, C, D) enthält einen ersten DSP (DSP1) 40 und einen zweiten DSP (DSP2) 42. Im allgemeinen überträgt und analysiert der DSP1 Daten zu und von dem Netzwerkbus 34 und managt einen Puffer für diese Daten im SRAM-Speicher 46, der zwischen DSP1 40 und DSP2 42 gemeinsam benutzt wird. Im allgemeinen verarbeitet der DSP2 42 Daten, die durch den DSP1 40 vorverarbeitet worden sind, und hält Inter-BPU-Kommunikationen über den BPU-Bus 36 aufrecht.
Jede BPU 22 hat auch einen DSP, der als ein Steuerprozessor (CP) 44 funktioniert, welcher eine Liste von Abteilungsassoziationen bzw. -verbindungen aufrechterhält. Da die Datenströme auf dem Netzwerkbus 34 und dem BPU-Bus 36 in Zeit- und Raum-Multiplex sind, betätigt der CP 44 einen Zeitmultiplexer (TDM), der einen Netzwerkschalter 48 und einen BPU-Schalter 50 hat, um ausgewählte Digitaldatenrahmen bzw. -datenübertragungsblöcke von den Datenkanälen zu der korrekten BPU-Abteilung zu leiten. Der TDM kann durch einen Mitel MT8980D-Digitalschalter verwirklicht sein. Der CP 44 unterstützt einen 32-Bit-CP-Bus 47 zu den DSPs 40, 42 in den vier Abteilung (A, B, C, D). Außerdem unterstützt der CP 44 einen 8-Bit-Bus 49 zu dem Netzwerkschalter 48 und dem BPU-Schalter 50. Der CP 44 bildet eine Schnittstelle zu TDM-Datenströmen durch den seriellen Multiplexer 51. Die BPU-Konfigurationsinformation kann im EEROM 53 gespeichert sein.
Die BPU 22 hat ein HPU-Schnittstelle 41, welche es der HPU 24 (2) ermöglicht, Speicherzugriff eines CP-SRAM-Speichers 43 und Eingangs-/Ausgangs-Zugriff durchzuführen, um den CP 44 zu steuern. Der Adressendecodierblock 45 unterstützt den HPU-Eingangs-/Ausgangs-Zugriff zu der BPU 22 unter Verwendung von programmierbaren Dip-Schaltern, welche durch Systemkonfiguration gewählt werden.
Grob gesprochen führt die DPU 28 zwei Funktionen aus:

1) Protokollhandhabung der T.120-Stapel für Mehrschichtprotokoll(MLP)-Konferenzanwendungen und
2) Protokollhandhabung, Videoüberbrückung und Audioverarbeitung für PCS-(Intel)-Codec-Anwendungen. Der MLP ist in den H-Serien-Empfehlungen H.200/AV.270 definiert und wird nicht weiter erörtert.

Jede DPU 28 kann vier Codecs (audiovisuelle Terminals) unterstützen, und mehrere DPUs können durch den DPU-Bus 36 verbunden sein, ähnlich jenem, der für die BPUs 22 benutzt wird. Ein detailliertes Blockschaltbild der DPU 28 ist in 4 veranschaulicht. Die DPU 28 ist in vier Abteilungen (A, B, C, D) segmentiert, wobei jede Abteilung einen Digitalsignalprozessor (DSP) 340 hat, der einem speziellen Codec zuteilbar ist. Diese DSPs 340a-d führen die Funktionen des Audiodecodierens, Audiomischens und Audiocodierens durch. Jeder DSP 340 hat einen gewidmeten Speicher 346.
Jede DPU 27 umfaßt außerdem einen DSP für Steuerungs- und Paketverarbeitungsfunktionen, eine Paketprozessor (PKP) 344. Ein Systemspeicher 353 ist dem PKP 344 gewidmet. Der PKP 344 steuert einen Netzwerkbusschalter 348 und einen BPU-Busschalter 350, um ausgewählte Pakete von dem Netzwerkbus 34 bzw. dem BPU-Bus 36 zu der korrekten DPU-Abteilung (A, B, C, D) zu leiten. Der Netzwerkbusschalter 348 kann durch zwei Mitel MT8980 Digitalschalter verwirklicht ist, und zwar je ein Schalter für Übertragen und Empfangen. Der BPU-Busschalter 350 kann durch Mitel MT8986AP Digitalschalter verwirklicht sein. Zusätzlich verbinden Multiplexer 356 die Ausgänge des Netzwerkbusschalters 348 und des BPU-Busschalters 350 mit den DSPs 340, dem PKP 344 und zwei HDLC-Steuereinrichtungen 354 und 355.
Es gibt zwei 32-Kanal-HDLC-Kommunikationssteuereinrichtungen 354 und 355, die Zugriff zu Daten auf dem Netzwerkbus 34 durch den Netzwerkbusschalter 348 haben. Die HDLC-Steuereinrichtungen 354 und 355 können durch Siemens "München" PEB20320-Einrichtungen verwirklicht sein. Ein Paketsteuerspeicher 343 bedient die beiden HDLC-Steuereinrichtungen 354 und 355 mit Steuer- und Konfigurationsinformation.
Der PKP 344 unterstützt einen 32-Bit-Bus 347 zum Steuern und Laden der DSPs 340a-d und der HDLC-Steuereinrichtungen 354, 355. Außerdem unterstützt der PKP 344 einen 8-Bit-Bus 349, um den Netzwerkbusschalter 348 und den BPU-Busschalter 350 zu steuern.
Die DPU 28 hat eine HPU-Schnittstelle 341, welche es der HPU 24 (2) ermöglicht, eine Programmherunterladung in den Systemspeicher 353 und Eingangs-/Ausgangszugriff auszuführen, um den PKP 344 über den ISA-Bus 32 zu steuern.
Es wird nun der Datenfluß die DPU 28 beschrieben. Datenpakete, welche durch einen übertragenden audiovisuellen Terminal HDLC-codiert worden sind, werden über eine NIU 20 empfangen und auf dem Netzwerkbus 34 plaziert. Eine HDLC-Steuereinrichtung 354, 355 empfängt die Datenpakete von dem Netzwerkbus 34 und entfernt HDLC-Rahmensynchronisations- bzw. -erkennungs- und Stopfbits. Die HDLC-Steuereinrichtung 354, 355 plaziert dann das Paket in dem angemessenen DSP-Speicher 346a-d über einen DMA-Prozeß. Die HDLC-Steuereinrichtungen 354, 355 werden durch den PKP 344 unter Verwendung von Konfigurationsinformation, die in den Paketsteuerspeicher 343 geladen ist, programmiert. Der PKP 344 programmiert die Zuordnung der seriellen Eingangszeitkanäle, die von der HDLC-Steuereinrichtung 354, 355 empfangen worden sind, zu dem entsprechenden DSP-Speicher-346a-d-Speicherort. Wenn eine Unterbrechung bzw. ein Interrupt von den HDLC-Steuereinrichtungen 354, 355, die bzw. der den Empfangen eines Datenpakets angibt, empfangen wird, kommuniziert der PKP 344 mit dem angemessenen DSP 340a-d dahingehend, daß ein neues Datenpaket nun in dem jeweiligen DSP-Speicher 346a-d ist.
Die DSPs 340 bestimmen, ob die Pakete im Speicher Audio- oder Videopakete sind. Videodaten werden direkt auf dem BPU-Bus 36 plaziert. Audiodaten werden erst zu PCM-Daten decodiert, bevor sie auf dem BPU-Bus 36 plaziert werden.
Videodaten von einer anderen Videoquelle (audiovisueller Terminal) werden von dem BPU-Bus 36 durch einen DSP 340 empfangen, der dem audiovisuellen Terminal zugeordnet ist, welcher den Empfang solcher Videodaten erwartet. Das Anfangsetikett für diese Videodaten wird mit der geeigneten Adressen- und Zeitstempelinformation modifiziert. Audio-PCM-Datenströme, die auf dem BPU-Bus 36 verfügbar sind, werden an einem bis vier Orten zu einem einzigen Audiostrom gemischt und codiert. Die codierten Audiodaten werden im angemessenen DSP-Speicher 346a-d mit angemessener Anfangsetikettinformation plaziert.
Wenn Audio- oder Videodatenpakete für die Übertragung auf den Netzwerkbus 34 bereit sind, unterbricht der DSP 340 den PKP 344, um anzuzeigen, daß ein Paket für die Übertragung verfügbar ist. Der PKP 344 konfiguriert die HDLC-Steuereinrichtung 354, 355 angemessen, um das Paket aus dem DSP-Speicher 346 über einen DMA-Prozeß zu nehmen und HDLC-Rahmensynchronisations- bzw. -erkennungs- und Stopfbits hinzuzufügen. Das HDLC-codierte Datenpaket wird dann in dem angemessenen Zeitkanal auf dem Netzwerkbus 34 plaziert.
Nachdem die Komponenten (BPU, DPU, NIU, HPU) der MCU 10, welche die grundsätzlichen Konferenzüberbrückungsfunktionen ermöglichen, beschrieben worden sind, mag es nützlich sein, zunächst auf einem hohen Niveau die Flexibilität zu verstehen, die durch die VPU-Ausführungsform der vorliegenden Erfindung zur Verfügung gestellt wird. 5 ist ein funktionelles Blockschaltbild der VPU 26. In einer bevorzugten Ausführungsform kann komprimierte Videoinformation von bis zu fünf audiovisuellen Terminals, die in der gleichen Konferenz sind, zu einer speziellen VPU 26 über den BPU-Bus 36 geleitet werden. Die VPU 26 umfaßt fünf Videokomprimierungsprozessoren (VCP0-VPC4), von denen jeder ein Videodecodierer/-codierer-Paar 102-i, 106-i und Pixel- bzw. Bildelementnormierungs- bzw. -skalierungsblöcke 104-i, 108-i hat.
Ein Videodecodierer- und -codierer-Paar 102-i, 106-i ist dem komprimierten Videoinformationsstrom zuteilbar, der jedem speziellen audiovisuellen Terminal in der Konferenz zugeordnet ist. Jeder Videodecodierer 102-i decodiert die komprimierte Videoinformation unter Verwendung des Algorithmus, der dem Codieralgorithmus seines zugeordneten audiovisuellen Terminals entspricht. Als Teil des Videodecodierers 102-i kann die Ver arbeitung zum Bestimmen der Rahmensynchronisation bzw. -erkennung, Pakete und Kontrollsummen inbegriffen sein, welches Teil des Übertragungsprotokolls sein kann. Es sollte bemerkt werden, daß ein prozessorcodierter Videostrom mehreren audiovisuellen Terminals zugeteilt sein kann (zum Beispiel in einer Anwendung kontinuierlicher Präsenz, die mehr als fünf audiovisuelle Terminals in der Konferenz hat). Außerdem kann ein Decodierer/Codierer-Paar 102-i, 106-i zwischen zuteilbaren audiovisuellen Terminals innerhalb einer Konferenz umschalten.
Die decodierte Videoinformation, oder die Pixel- bzw. Bildelemente, werden dann maßstäblich vergrößert oder verkleinert (wenn notwendig), und zwar durch einen Pixel- bzw. Bildelementskalierungs- bzw. -normierungsblock 104-i, um die Pixel- bzw. Bildelementauflösungserfordernissen von anderen audiovisuellen Terminals in der Konferenz zu entsprechen, welche die maßstäblich geänderten Pixel- bzw. Bildelemente codieren werden. Zum Beispiel kann ein Schreibtischsystem mit einer Auflösung von 256×240 codieren, während ein H.320-Terminal eine Pixel- bzw. Bildelementauflösung von 352×288 für ein übliches Zwischenformat-(CIF)-Bild erfordern würde.
Die maßstäblich geänderten bzw. normierten Pixel- bzw. Bildelemente werden dann irgendeinem anderen Videocodierer 106-j auf einem gemeinsam benutzten Pixel- bzw. Bildelementbus 82 verfügbar gemacht. Jedem Codierer 106-j wird ein erster Betrag an Zeit (ein Zeitkanal bzw. -schlitz) ermöglicht, um Pixel- bzw. Bildelemente auf den Pixel- bzw. Bildelementbus 82 auszugeben, wodurch effektiv ein Zeitmultiplexbus erzeugt wird. Jeder Codierer 106-j kann irgendeines der Bilder, die auf dem Pixel- bzw. Bildelementbuszeitkanälen verfügbar sind, für Wiedercodieren und/oder räumliches Mischens abfragen. Ein anderer Pixel- bzw. Bildelementnormierungs- bzw. -skalierungsblock 108-j ist zwischen den Pixelbus 82 und den Codierer 106-j zum Einstellen der Pixel- bzw. Bildelementauflösung des probegenommenen Bilds, wenn benötigt, gekoppelt.
Die Kombination des Decodierens, Codierens, skalieren bzw. maßstäblichen Änderns bzw. Normierens und gemeinsamen Benutzens des Pixel- bzw. Bildelementbusses auf dem digitalen Gebiet stellt ein besonders flexibles und effizientes Mittel für die Algorithmusumcodierung und die Übertragungsratenanpassung zur Verfügung.
Die folgenden Beispiele veranschaulichen den Datenfluß innerhalb der MCU für Anwendungen kontinuierlicher Präsenz (räumliches Mischen), Algorithmusumcodierung und Übertragungsratenanpassung der vorliegenden Erfindung.
Es wird nun eine Anwendung kontinuierlicher Präsenz unter Bezugnahme auf die 6 und 7 beschrieben. Es ist zu beachten, daß der ISA-Bus 32 (2) nicht gezeigt ist. In 6 kommen Daten von audiovisuellen Terminals 38 über ein Kommunikationsnetzwerk bei jeweiligen NIUs 20 an. Fünf audiovisuelle Terminals 38 (A, B, C, D, E) sind in der Konferenz verbunden und können zum Beispiel H.320-Terminals sein. Die audiovisuellen Terminals A und B sind nach der Darstellung mit einer speziellen NIU 20 verbunden, welche mehrfache Codec-Verbindungen unterstützt (zum Beispiel eine T1-Schnittstelle). Die anderen audiovisuellen Terminals C, D und E verbinden zu NIUs 20, die nur eine einzige Codec-Verbindung unterstützen (zum Beispiel eine ISDN-Schnittstelle). Jeder audiovisuelle Terminal 38 plaziert ein oder mehr Oktetts von digitalen Daten auf dem Netzwerkbus 34 als unsynchronisierte H.221-gerahmte Daten. Die Daten sind unsynchronisiert, da die Bitausrichtung bzw. -aufreihung nicht notwendigerweise an einer Oktett-Grenze beginnt. Außerdem, welches Oktett innerhalb des 80-Oktett-H.221-Datenübertragungsblocks bzw. -rahmens ist, ist noch nicht bekannt. Die BPUs 22 bestimmen dann die H.221-Rahmung bzw. -Datenübertragungsblockbildung, richten die Oktetts aus und bestimmen die H.221-Oktettnummer. Diese ausgerichteten Daten werden allen anderen Einheiten auf dem BPU-Bus 36 verfügbar gemacht.
Die BPUs 22 fragen außerdem Audioinformation aus den H.221-Rahmen bzw. -Datenblöcken ab und decodieren die Audioinformation in 16-Bit-PCM-Daten. Die decodierten Audiodaten werden zum Mischen mit Audiodaten von anderen audiovisuellen Terminals auf dem BPU-Bus 36 verfügbar gemacht.
Ausgerichtete H.221-Rahmen bzw. -Datenblöcke werden durch die VPU 26 zum Verarbeiten durch Codier/Decodier-Elemente, die Videokomprimierungsprozessoren (VCPs) genannt werden, empfangen. Die VPU 26 hat fünf VCPs (5), welche in diesem Beispiel jeweils den audiovisuellen Terminals 38 (A, B, C, D, E) zugeteilt sind. Ein VCP 60-e auf bzw. in der VPU 26, welche dem audiovisuellen Terminal 38 (E) zugeteilt ist, ist funktionell in 7 veranschaulicht. Komprimierte Videoinformation (H.261) wird aus den H.221-Rahmen bzw. -Datenübertragungsblöcken abgefragt und durch die VCP 60-e als Bild X decodiert. Das Decodierer-Videobild X wird auf dem Pixel- bzw. Bildelementbus 82 plaziert. 7 zeigt den Pixel- bzw. Bildelementbus 82 mit decodierten Videodatenübertragungsblöcken von jedem audiovisuellen Terminal 38 (A-E), die in aufeinanderfolgenden Zeitkanälen (0-4) lokalisiert sind. Der dem Terminal E zugeteilte VCP 60-e empfängt die decodierten Videodatenübertragungsblöcke von den Terminals A, B, C und D, welche dann zu einem einzigen zusammengesetzten Bild I verfliest (räumlich gemischt) werden. Das verflieste Bild I wird dann als H.261-Video innerhalb der H.221-Rahmung bzw. -Datenübertragungsblockbildung codiert und auf dem BPU-Bus 36 (6) für BPU-Verarbeitung, wie oben beschrieben, plaziert.
In einer Übertragungsratenanpassungsanwendung ist der Datenfluß durch die NIUs 20 und BPUs 22 zu der VPU 26 gleichartig jenem der Anwendung für kontinuierliche Präsenz. Es sei wieder auf 6 Bezug genommen, wonach die audiovisuellen Terminals 38 zu Zwecken dieses Beispiels H.320-Terminals sind, die mit unterschiedlichen Netzwerkdatenraten arbeiten. Zum Beispiel können die Terminals A, B und C mit 2B-(ISDN)-Netzwerkraten arbeiten, während die Terminals D und E mit T1-Netzwerkraten arbeiten können.
Wie bei der Anwendung für kontinuierliche Präsenz empfängt die VPU 26 H.221-Datenübertragungsblöcke von dem BPU-Bus 36. Es sei auf 8 Bezug genommen, wonach ein VCP 60-c Videoinformation (H.261) von den H.221-Datenübertragungsblöcken, die dem audiovisuellen Terminal 38 (C) mit der 2B-Rate zugeordnet sind, abfragt und decodiert. Das decodierte Videobild Y wird auf dem Pixel- bzw. Bildelementbus 82 plaziert. Entsprechend entnimmt und decodiert der VCP 60-d Videoinformation aus H.221-Datenübertragungsblöcken, die dem audiovisuellen Terminal 38 (D) mit der T1-Rate zugeordnet sind. Das decodierte Bild Z wird auch auf dem Pixel- bzw. Bildelementbus 82 in dem Zeitkanal plaziert, welcher dem VCP 60-d zugeordnet ist. Da der Pixel- bzw. Bildelementbus 82 decodierte digitale Videobilder bzw. -datenübertragungsblöcke hat, die allen fünf der VCP-Prozessoren verfügbar sind, können die Videobilder bzw. -datenübertragungsblöcke gleichzeitig durch unterschiedliche VCPs mit unterschiedlichen Raten wiedercodiert werden, um Mehrfachratenbetrieb in einer einzigen Konferenz zu ermöglichen. In diesem speziellen Beispiel wird das decodierte Bild Y vom Terminal C von dem Pixel- bzw. Bildelementbus 82 durch den VCP 60-d eingegeben und als Bild Y' zur Übertragung mit der T1-Rate wiedercodiert. Entsprechend wird das decodierte Bild Z vom Terminal D von dem Pixel- bzw. Bildelementbus 82 durch den VCP 60-c eingegeben und als Bild Z' mit einer unterschiedlichen Rate (2B) wiedercodiert.
Die Ratenanpassung der vorliegenden Erfindung, durch welche der Pixel- bzw. Bildelementbus decodierte Videobilder bzw. -datenübertragungsblöcke allen VCPs zur Wiedercodierung mit unterschiedlichen Raten verfügbar macht, vermeidet es, daß Terminals unterschiedlicher Rate mit der Rate des Terminals niedrigster Rate betrieben werden müssen. Dieses ist möglich, weil die Videobilder bzw. -datenübertragungsblöcke auf dem Pixel- bzw. Bildelementbus unkomprimiert sind. Die unkomprimier ten Videobilder bzw. -datenübertragungsblöcke, die von einem VCP, der einem Terminal niedriger (zum Beispiel 2B-Rate) zugeordnet ist, auf dem Pixel- bzw. Bildelementbus plaziert werden, werden von dem Bus durch einen VCP entnommen (abgefragt), der einem Terminal hoher Rate (zum Beispiel T1) zugeordnet ist. Einige Videobilder bzw. -datenübertragungsblöcke von dem Terminal niedriger Rate werden relativ zu dem Abfragen hoher Rate, das dem Terminal hoher Rate zugeordnet ist, auf dem Bus wiederholt. In entsprechender Weise werden unkomprimierte Videobilder bzw. -datenübertragungsblöcke von dem Terminal hoher Rate durch den VCP, der dem Terminal niedriger Rate zugeordnet ist, von dem Bus abgefragt. Einige Videobilder bzw. -datenübertragungsblöcke von dem Terminal hoher Rate werden relativ zu dem Abfragen niedriger Rate, das dem Terminal niedriger Rate zugeordnet ist, vermißt bzw. übersprungen. Da die Videobilder bzw. -datenübertragungsblöcke unkomprimiert sind, empfängt jedoch jeder Terminal noch ein verständliches bzw. deutliches Videosignal mit einer Bildauflösung, die der niedrigeren Auflösung des Quellen-/Empfangsterminal-Paars entspricht.
Ein Beispiel des Algorithmusumcodierens wird nun unter Bezugnahme auf die 9 und 10 beschrieben. In diesem Beispiel sind Terminals, welche unterschiedliche Videokomprimierungsalgorithmen verwenden, in der gleichen Konferenz verbunden. Speziell ist es, Bezug nehmend auf 9, so, daß der audiovisuelle Terminal 38 (A) ein PCS(Intel)-Terminal sein kann, während er Terminal 38 (B) ein H.320-Terminal sein kann. Die H.221-Bilder bzw. -Datenübertragungsblöcke vom Terminal 38 (B) fließen durch den NIU 20 und die BPUs 22 zur VPU 26, ähnlich den vorher beschriebenen Anwendungen.
Ein VCP 60-b entnimmt und decodiert komprimierte Videoinformation (H.261) aus H.221-Bildern bzw. -Datenübertragungsblöcken, die dem audiovisuellen Terminal 38 (B) zugeordnet sind, wie in 10 gezeigt ist. Das decodierte Bild J kann möglicherweise maßstäblich geändert bzw. normiert werden und wird dann auf dem Pixel- bzw. Bildelementbus 82 in dem zugeteilten Zeitkanal plaziert. In diesem Beispiel würde jedes decodierte H.320-Bild von 352×288 (CIF) oder 176×144 (QCIF) maßstäblich geändert bzw. normiert werden, um den jeweiligen PCS-Standardbildgrößen von 320×240 und 160×120 zu entsprechen. Allgemein bietet die Skalierung sowohl der Eingangsgröße als auch der Ausgangsgröße zu bzw. von dem Pixel- bzw. Bildelementbus eine Flexibilität und würde für das Umcodieren des Bilds J für einen anderen Konferenzterminal unter Verwendung eines unterschiedlichen Komprimierungsalgorithmus in der gleichen Konferenz unterschiedlich sein. Das decodierte Bild J ist verfügbar, um durch den VCP 60-a für das Wiedercodieren unter Verwendung des PCS-Videokomprimierungsalgorithmus eingegeben zu werden. Das codierte Bild J' hat Anfangsetikettinformation, die zu demselben hinzugefügt worden ist, um PCS-Videopakete zu erzeugen. Es sei wieder auf 9 Bezug genommen, wonach diese Pakete auf den BPU-Bus 36 übertragen und von einer DPU 28 empfangen werden.
Die PCS-Pakete werden durch die DPU 28 HDLC-codiert und zu dem Netzwerkbus 34 übertragen. PCM-Audioinformationen von beiden Terminals (H.320 und PCS) werden in der DPU 28 gemischt, in PCS-Audiopaketen plaziert, HDLC-codiert und auf dem Netzwerkbus 34 plaziert. Von dem Netzwerkbus 34 sendet die NIU 20 die PCS-Pakete zum Terminal 38 (A).
Es sei wieder auf 9 Bezug genommen, wonach der Datenfluß von dem audiovisuellen Terminal 38 (A) zur VPU 26 insofern unterschiedlich ist, als PCS-Pakete durch die DPU 28 anstelle der BPU 22 geleitet werden. In anderen Algorithmusumcodierungsbeispielen kann der Datenfluß derart sein, daß Videobilder bzw. -datenübertragungsblöcke durch nur BPUs 22 eher als durch DPUs 28 geschaltet werden, was von dem speziellen Komprimierungsalgorithmus abhängt. In diesem Beispiel empfängt die DPU 28 die PCS-Pakete von dem Netzwerkbus 34 und entfernt die HDLC-Codierung. Die DPU 28 decodiert dann Audiopakete zu PCM-Daten. Schließlich plaziert die DPU 28 die PCM-Daten und Videopakete auf dem BPU-Bus 36.
Ein VCP 60-a entnimmt und decodiert PCS-komprimierte Videopakete, die dem Terminal 38 (A) zugeordnet sind, wie in 10 gezeigt ist. Das decodierte Bild K wird dann auf dem Pixel- bzw. Bildelementbus 82 in dem zugeordneten Zeitkanal O plaziert. Der VCP 60-b gibt das Bild K vom Pixel- bzw. Bildelementbus 82 für die Wiedercodierung unter Verwendung des H.261-Videokomprimierungsalgorithmus ein. Das codierte Bild K' wird dann mit der H.221-Struktur gerahmt bzw. mit einer Rahmensynchronisation bzw. -erkennung versehen und auf dem BPU-Bus 36 plaziert, um durch die BPU 22 und die NIU 20 zum Terminal 38 (B) geleitet zu werden.
Es sollte vermerkt werden, daß die Algorithmen oder Terminalarten andere als jene sein können, welche in dem vorherigen Beispiel gezeigt worden sind, und das mehr als zwei Algorithmen in einer Konferenz mit mehreren Parteien umcodiert werden können. Außerdem sind Kombinationen der oben beschriebenen drei Beispiele möglich. Zum Beispiel könnte eine Konferenz kontinuierlicher Präsenz mit räumlichem Mischen zwischen Terminals gebildet werden, die ungleiche Videokomprimierungsalgorithmen mit unterschiedlichen Übertragungsraten benutzen. Jedes Verfliesen des räumlich gemischten Videos würde die bestverfügbare Bildauflösung haben.
Es wird nun im Detail unter Bezugnahme auf 11 eine spezielle Ausführung der VPU 26 beschrieben. Die VPU 26 weist mehrere Videokomprimierungsprozessoren (VCPs) 60 auf, um Algorithmusumcodierung und Übertragungsratenanpassung vorzusehen. Ein Eigentümer-16-Bit-Parallel-Pixel- bzw. Bildelementbus 82 ermöglicht es, decodierte Videobilder bzw. -datenübertragungsblöcke zwischen den VCPs 60 gemeinsam zu benutzen. Der Pixel- bzw. Bildelementbus 82 ermöglicht ein räumliches Mischen in Anwendungen kontinuierlicher Präsenz, oder ein Wiedercodieren von Bildern für Videoumcodierungsanwendungen. Der Betrieb des Pixel- bzw. Bildelementbusses 82 wird unten beschrieben.
Die Gesamtsteuerung der Videoprozessoren und die Verbindung mit den Videoprozessoren wird durch einen Steuer-DPS (VPU-CP) 62, einen systemintegrierten DSP-Prozessor, gehandhabt. Der VPU-CP 62 kann durch den Texas Instruments TMS320C31 DSP verwirklicht sein. Der VPU-CP 62 hat Verantwortlichkeit für die Steuerung eines TDM-Busschalters 70, der VCP-Programmherunterladung, und der Verbindung zwischen der HPU 24 und den VCPs 60. Außerdem speichert der VPU-CP 62 Konfigurationsinformation im seriellen EEROM 63.
Ein CP-Bus 72 ist der externe Speicherbus des Steuerprozessors DSP (VPU-CP) 62. Die meisten der Steuerregister, Speicher und Schnittstellen sind auf diesen Bus speicherübertragen, einschließlich dem VPU-CP-SRAM-Speicher 74, der TDM-Busschaltersteuerung und dem VCP-Verarbeitungsrechneranschlußregistern. Der VPU-CP 62 ist der Vorgabeanker des Busses. Die HPU 24 hat auch Zugang zu dem gesamten Adressenbereich des Steuerbusses durch eine Kombination des ISA-gemeinsam-benutzten-Speicherfensters und eines CP-Busbankregisters 76. Die ISA-Decodier- und -Steuerlogik 78 auf der VPU-Verarbeitungsrechnerschnittstelle vermittelt die VPU-CP 62 weg von dem CP-Bus 72 für jeden HPU-Zugriff.
Der CP-Bus 72 ist geteilt, um die SRAM-Zugangsaktivität höherer Geschwindigkeit des VPU-CP 62 und die Register- und Peripheriekomponenten niedrigerer Geschwindigkeit zu isolieren. Die VCPs 60 und Steuerregister werden demgemäß auf etwas lokalisiert, was als ein PK-Bus 80 bezeichnet wird.
Die Verbindung mit jedem VCP 60 erfolgt durch eine Verarbeitungsrechneranschlußschnittstelle auf dem CP-Bus 72. Jeder VCP 60 hat einen eigenen privaten SRAM-Programmspeicher 64 und DRAM-Bild- bzw. -Übertragungsblockspeicher 66. Eine serielle CHI-Schnittstelle 68 von jedem VCP verbindet mit dem BPU-Bus 36 über den TDM-Busschalter 70. Es können ein bis fünf VCPs auf einer VPU-Karte populiert sein, und zwar abhängig von der erforderlichen Verarbeitung für eine gegebene Anwendung.
Eine Verbindungsschnittstelle zu der VPU 26 wird durch den MVIP-abgeleiteten seriellen TDM-Bus, den BPU-Bus 36, vorgesehen. Der BPU-Bus 36 ermöglicht es der VPU 26, schnittstellenmäßig zu den BPUs 22 zu gelangen, welche H.221-Format-Audio/Video/Daten zu der VPU 26 liefern, und zu den DPUs 28, welche Datenkonferenz- und Audiodecodierfunktionen vorsehen.
Der ISA-Bus 32 ist primär für die Steuerung gedacht; es werden typischerweise keine Daten zu der VPU 26 über den ISA-Bus übertragen. VPU-CP-Bootprogramme werden von der HPU 24 (2) über den ISA-Bus 32 heruntergeladen. Durch den ISA-Bus 32 kann auf den gesamten 16-Megawort-Speicherraum des CP-Busses 72 zugegriffen werden. Die HPU-Schnittstelle ist eine ISA-Adapter-Schnittstelle. Die VPU 26 benutzt sowohl Eingangs-/Ausgangs-aufgenommenes als auch speicheraufgenommenes Adressieren. Interrupt- bzw. Unterbrechungsforderungen von der VPU-CP 62 oder den VCPs 60 an die HPU 24 werden durch die IRQ-Logik 65 gesteuert.
Die VPU 26 umfaßt fünf identische Videokomprimierungsuntersysteme, oder VCPs 60, welche eine Videokomprimierung, -dekomprimierung und Pixel- bzw. Bildelementmischung ausführen. Die VCPs 60 sind programmierbar, was es der VPU 26 ermöglicht, verschiedene Komprimierungsalgorithmen auszuführen.
Die VCPs 60 basieren auf der Integrierten-Informationstechnologie-VCP-Einrichtung. Diese Einrichtungen sind in hohem Maße integrierte Einzelchip-programmierbare-Videocodecprozessoren. Jeder VCP 60 zusammen mit externem DRAM-Bild- bzw. -Datenübertragungsblockspeicher 66 und SRAM-Programmspeicher 64 bildet einen vollständigen Codec. Eine mehrfache Komprimierungsalgorithmusunterstützung ist durch die Fähigkeit vorgesehen, algorithmusspezifische Programme herunterzuladen bzw. heruntergeladene algorithmusspezifische Programme zu haben (zum Beispiel H.261, MJPEG und MPEG). Eigentümerkomprimierungsalgo rithmen können auch an die VCP-Einrichtungen angeschlossen bzw. in die VCP-Einrichtungen eingegeben werden.
Jede VCP 60 ist ein eigenständiger Codec, wie in 12 gezeigt ist. Es sollte bemerkt werden, daß, obwohl die VCPs in der beschriebenen speziellen Ausführungsform als vollständige Codecs konfiguriert sind, andere Ausführungsformen VCPs haben können, die als separate Codierer und Decodierer konfiguriert sind. Intern umfassen die funktionellen Hauptblöcke einen RISC-Steuerprozessor (RISCIIT) 150, einen Vision- bzw. Bildprozessor (VP5) 152, einen Huffman-Codec 154, einen H.221/BCH-Codec 156 und externe Schnittstellen. Die externen Schnittstellen umfassen eine TDM-Busschnittstelle 158, eine SRAM-Schnittstelle 160, eine DRAM-Schnittstelle 162, einen Verarbeitungsrechneranschluß bzw. -port 164 und eine Pixel- bzw. Bildelementschnittstelle 166.
Der programmierbare RISCIIT 150 wartet den Verarbeitungsrechneranschluß bzw. -port 164, die TDM-Schnittstelle 158 und die Pixel- bzw. Bildelementschnittstelle 166 und steuert den H.221-/BCH 156, den Huffman-Codec 154 und andere periphere Komponenten, die intern für den VCP sind. Der VP5 152 führt die Komprimierungsprimitiven aus und wird von dem RISCIIT 150 gesteuert. Hinsichtlich detaillierter Informationen siehe das IIT-VCP-vorläufige-Datenblatt und die VCP-externe-Bezugsspezifikation.
Das Programmherunterladen und die Steuerung wird durch eine Verarbeitungsrechneranschluß- bzw. -portschnittstelle auf jedem VCP 60 vorgesehen. Diese Verarbeitungsrechneranschluß- bzw. -portschnittstelle ist auf den CP-Bus 72 speicheraufgenommen, so daß es entweder dem VPU-CP 62 oder der HPU 24 ermöglicht wird, auf die VPCs 60 zuzugreifen.
Jeder VCP 60 ist mit einem privaten DRAM-Speicher 66 für Videodatenpufferung konfiguriert. Das SRAM-Speicher 64 wird für den RISCIIT-Programmspeicher und die Pufferung für die seriel len Anschlüsse bzw. Ports, den H.221/261-Codec 156 und den Huffmann-Codec 154 verwendet.

Es sei wieder auf 11 Bezug genommen, wonach die Steuerung und die Programmherunterladung zu den VCPs durch einen Verarbeitungsrechneranschluß- bzw. -port 61 auf jedem VCP-Prozessor erfolgt. Dieser Anschluß bzw. Port hat sechs Register. Die Bezeichnung Verarbeitungsrechner in diesem Abschnitt bezieht sich auf den VPU-CP 62 (nicht die HPU), welcher als der Verarbeitungsrechner zu den bzw. für die VCP-Prozessoren dient. Eine Liste der Verarbeitungsrechneranschluß- bzw. -portregister ist in der folgenden Tabelle gezeigt:

Adresse	Typ	Name	Bemerkungen
VCP-Basis + 0	R/W	hostdmaport	DMA-komprimierte Daten ein/aus
VCP-Basis + 1	R/W	hostvcxport	Standard-VCXI-Befehlsschnittstelle
VCP-Basis + 2	R/W	hostdbgport	Debug-Anschluß bzw. -Port
VCP-Basis + 3	R/W	hostctl	Unterbrechungs- und DMA-Steuerung
VCP-Basis + 4	R/W	hostmask	Unterbrechungsmaske
VCP-Basis + 5	R	hostirqstat	Unterbrechungsstatus

Jeder VCP 60 hat einen TDM-Anschluß bzw. -Port 69, welcher durch den TDM-Busschalter 70 mit dem BPU-Bus 36 verbunden ist. Der TDM-Busschalter 70 kann mit Mitel 8986-Digitalschaltern verwirklicht sein. Der TDM-Anschluß bzw. -Port 69 hat eine minimale Versetzung zwischen dem Bild- bzw. Datenübertragungsblock-Synchronisierimpuls und dem ersten Bit der Zeitkanal-Null (des VCP's). Auf der VPU 26 sind TDM-Daten mit dem Bild- bzw. Datenübertragungsblock-Synchronisierimpuls ausgerichtet, und zwar per der MVIP-Spezifikation. Der VCP-TDM-Anschluß bzw. -Port 69 benötigt demgemäß einen Versetzungsabgleich mit dem ersten Datenbit in einem Zeitkanal. Dieses hat die Wirkung, daß die Zeitkanalnumerierung, welche durch den VCP gesehen wird, eins weniger (Modulo 64) als die Zeitkanalnumerierung ist, welche durch die Mitel-Schalter gesehen wird. Zum Beispiel entspricht die VCP-Zeitkanal Null der Mitel-Zeitkanal Eins.
Die VCPs 60 und der VPU-CP 62 können über serielle Leitungen 80 mit dem BPU-Bus 36, der Busteile 36a und 36b hat, durch den TDM-Busschalter 70 verbinden, welcher eine Verbindung von bis zu irgendwelchen 32 der gesamten 512 Zeitkanäle auf dem BPU-Bus im Falle von 2-Mbit/s-Betrieb oder 64 der gesamten 1024 Zeitkanäle in dem Falle von 4-Mbit/s-Betrieb ermöglicht. Ein Blockschaltbild des BPU-Busses 36 und des TDM-Busschalters 70 sind in 13 gezeigt. Der TDM-Busschalter 70 sieht acht Stromverbindungen zu dem BPU-Bus 36 vor. Da es nur acht Ströme (Signalleitungen) gibt, welche verbunden werden können, verbinden die Multiplexer 71a und 71b diese acht Ströme von dem TDM-Busschalter 70 in Gruppen von vier bis acht von sechzehn möglichen Strömen auf dem BPU-Bus 36, welche als Busteile 36a und 36b gezeigt sind.
Bei einer 4-MHz-Bitrate sind die MT8986-Schalter als eine Acht-ein-mal-vier-aus-Kreuzungsstelle konfiguriert. Um eine Acht-mal-acht-vollständige Duplex-Kreuzungsstelle auszuführen, erfordert das vier MT8986-Schalter: zwei Schalter 70a, 70b für Sendedaten, und zwei Schalter 70c, 70d für empfangene Daten.
Es sei erneut auf 11 Bezug genommen, wonach der Pixel- bzw. Bildelementbus 82 dazu benutzt wird, es vielen VCPs 60 zu ermöglichen, decodierte Pixel- bzw. Bildelementdaten gemeinsam zu benutzen. Jeder VCP in Aufeinanderfolge hat seine Ausgangssteuersignale betrieben bzw. in Betrieb, wodurch bewirkt wird, daß der spezielle VCP Daten auf den Pixel- bzw. Bildelementbus 82 ausgibt. Außerdem treibt die Pixel- bzw. Bildelementbussteuereinrichtung 84 die Steuersignale zu dem Pixel- bzw. Bildelementeingang von jedem VCP 60, wodurch bewirkt wird, daß der VCP 60 Daten nur eingibt, wenn er programmiert ist. Die Eingangsdaten sind dann zur Verarbeitung durch die Prozessorprogrammierung der Video-Schnittstellen-DMA-Steuereinrichtungen, die für den VCP 60 intern sind, verfügbar.
Der Pixel- bzw. Bildelementbus 82 verbindet die Pixel- bzw. Bildelementausgänge der vielen VCPs 60 mit den Pixel- bzw. Bildelementeingängen der VCPs 60 durch ein Zeitmultiplexschema. Jeder VCP 60 ist während gleicher Zeitbeträge auf den Pixel- bzw. Bildelementbus befähigt. Die Zeit, in der jeder VCP 60 ausgeben kann, ist in horizontalen und vertikalen Zählregistern, hcnt und vcnt, programmiert, welche eine festes Rechteck für das Ausgeben von Pixel bzw. Bildelementen auf den Pixel- bzw. Bildelementbus 82 definieren. Der feste rechteckige Bereich wird durch die Pixel- bzw. Bildelementbussteuereinrichtung 84 definiert und braucht nur groß genug zu sein, um den Dimensionen des größten Bilds, das auf dem Pixel- bzw. Bildelementbus 82 bedient wird, zu entsprechen. Zum Beispiel kann es erforderlich sein, daß der feste rechteckige Bereich 600×300 ist, worin die Anzahl der Pixel bzw. Bildelemente pro Zeile (npix) 600 beträgt und die Anzahl der Zeilen (nlines) 300 ist.
Jeder VCP 60 ist fähig, Pixel- bzw. Bildelemente von einem interessierenden Bereich innerhalb des npix-mal-nlines-Rechtecks, wie in 4 gezeigt, auszugeben oder zu empfangen. Da der VCP 60 über die Größe und den Ort seines Pixel- bzw. Bildelementausgangs innerhalb des Rahmens, der durch die npix- und nlines-Werte definiert ist, Kontrolle bzw. Steuerung hat, braucht der VCP 60 nicht das gesamte 600×300-Bild in dem vorigen Beispiel zu "füllen". Der VCP könnte innerhalb der 600×300-Ausgangsabtastung zum Beispiel ein CIF (252×288)-Rechteck R oder a QCIF (176-144)-Rechteck R' ausgeben. Andere interessierende Bereiche können auch definiert werden, zum Beispiel PCS-Bildgrößen (320×240 und 160×120).
Die in jedem VCP 60 programmierten Zeitsteuerungsparameter müssen jenen entsprechen, welche in die Pixel- bzw. Bildele mentbussteuereinrichtungs-84-hcnt-und-vcnt-Register programmiert sind. Die VCP-Pixel- bzw. -Bildelementschnittstelle braucht wenigstens 13 Pixel bzw. Bildelemente des horizontalen Austastungsbereichs und 4 Zeilen des vertikalen Austastungsbereichs. Demgemäß wird die aktive Pixel- bzw. Bildelementausgabe immer gegenüber der oberen rechten Ecke versetzt sein.
Jeder VCP 60 wird für nlines-Zeilen, jede aus npix-Pixel bzw. -Bildelementen befähigt. In der näher beschriebenen speziellen Ausführungsform ist der Zählwert, welcher in die Steuerregister hcnt und vcnt programmiert ist, auf ein Vielfaches von vier Pixeln bzw. Bildelementen und vier Zeilen beschränkt. Die Formel für die Zeilenlänge und die Bildhöhe ist: npix = 1028 – (hcnt·4) nlines = 516 (vcnt·4)
Oder, in Größen der Anzahl von Pixeln bzw. Bildelementen und Zeilen, welche das feste Rechteck definieren:
worin '~' die bitweise Inversion ist.
Jeder VCP 60 seinerseits gibt auf den Pixel- bzw. Bildelementbus 82 aus, und dann wird der Zyklus wiederholt. Demgemäß ist die Einzelbild- bzw. Datenübertragungsblockrate

Die folgende Tabelle hat optimale Parametereinstellungen für verschiedene Einzelbild- bzw. Datenübertragungsblockrate bei Takt-(2×pixelclk)-Raten von 33330, 28322 und 27000 MHz. Es kann notwendig sein, die Pixel- bzw. Bildelementtaktrate zu vermindern, um die Beschränkungen der Filteranzapflänge gegen den Prozessortakt und die Pixel- bzw. Bildelementtaktrate zu erfüllen.

Bild- bzw. Einzelbildrate¹ (Hz)	2×pixelclk Takt (MHz)	npix	nlines	hcnt	vcnt
30 15 10 7,5	33,330 33,330 33,330 33,330	372 556 860 904	300 400 388 492	0×A4 0×76 0×2A 0×1F	0×36 0×1D 0×20 0×06
30 15 10 7,5	28,322 28,322 28,322 28,322	368 372 716 756	292² 508 396 500	0×A5 0×A4 0×4E 0×44	0×38 0×02 0×1E 0×04
30 15 10 7,5	27,000 27,000 27,000 27,000	368 556 656 892	292³ 324 412 404	0×A5 0×76 0×5D 0×22	0×38 0×30 0×1A 0×1C

¹ Gegebene nominelle Einzelbild- bzw. Datenübertregungsblockrate. Gewünschte Einzelbild- bzw. Datenübertragungsblockrate ist (30000/1001)/n, n = 1, 2, 3, 4.
² 292 ist die minimale Höhe aufgrund der Synchronisationslängenerfordernisse. Dieses führt zu einer Einzelbild- bzw. Datenübertragungsblockrate von 26,3 Hz.
³ 292 ist die minimale Höhe aufgrund der Synchronisationslängenerfordernisse. Dieses führt zu einer Einzelbild- bzw. Datenübertragungsblockrate von 25,1 Hz.

Es wird nun der Betrieb des Pixel- bzw. Bildelementbusses 82 im Detail beschrieben. Wie oben bemerkt, umfassen die VCPs 60 Videoeingangs- und -ausgangsabschnitte zum Empfangen und Senden von Pixeln bzw. Bildelementen von und zu dem Pixel- bzw. Bildelementbus 82. Die Pixel- bzw. Bildelementbussteuereinrichtung 84 liefert Steuersignale zu den Videoeingangs- und -ausgangsabschnitten der VCPs 60, um eine Verbindung mit dem Pixel- bzw. Bildelementbus 82 freizugeben. Die bevorzugte Ausführungsform des Pixel- bzw. Bildelementbusses 82 sieht fünf Zeitkanäle vor, in die jeder VCP 60 in Aufeinanderfolge Videopixel bzw. -bildelemente ausgibt. Irgendeiner der anderen VCPs 60 kann gleichzeitig Pixel- bzw. Bildelemente für die Komprimierungsverarbeitung eingeben. Jeder der Zeitkanäle wird durch das Vorhandensein eines vertikalen Synchronisationssignals begrenzt. Innerhalb des Zeitkanals sind horizontale Synchronisationssignale programmiert, um horizontale Abtastintervalle für die VCPs 60 vorzusehen. Die Pixel- bzw. Bildelementbussteuereinrichtung 84 kann typischerweise so programmiert sein, daß sie vertikale Synchronisationen mit einer Rate liefert, welche das fünffache der nominellen Einzelbild- bzw. Datenübertragungsblockrate ist, zum Beispiel VSYNC-Läufe mit 150 Hz derart, daß alle fünf VCP 60 aktiv sind, jeder mit einer 30Hz-Rate.
Die Pixel- bzw. Bildelementbussteuereinrichtung 84, die mit einer gebietsprogrammierbaren Toranordnung (FPGA) verwirklicht werden kann, hat drei Arten von Signalen: Mikroprozessor-Schnittstellensignale, Videoeingangssteuer- und Videoausgangssteuersignale, wie in dem Blockschaltbild der 15 gezeigt ist. Die Mikroprozessorsteuersignale ermöglichen es dem VPU-CP 62, die Parameter der Pixel- bzw. Bildelementbussteuereinrichtung 84 ein- bzw. aufzustellen. Zum Beispiel können die internen hcnt- und vcnt-Register, welche jeweils die horizontale Länge und vertikale Länge halten, durch Auswählen der geeigneten Adresse programmiert werden, welche die Chipauswahl (CS) und das Pulsen des Schreibstrobes (WR) ermöglicht. Die internen Register können zurückgelesen werden durch Auswählen der geeigneten Adresse, Freigeben der Chipauswahl (CS) und Pulsen des Lesestrobes (OE).
Die Videoeingangssteuersignale der Pixel- bzw. Bildelementbussteuereinrichtung 84 umfassen die QUALCLK-, HSYNC-, VSYNC- und ODDCAM-[0-4]-Signale. Das QUALCLK- oder Pixel- bzw. Bildelementtaktkennzeichnersignal läuft mit der Pixel- bzw. Bildelementrate, welche einhalb der 2×-Pixel- bzw. -Bildelementtakteingänge zu den VCPs 60 ist. Dieses Signal wird dazu benutzt, die 2×-Pixel- bzw. -Bildelementtakte zu den VCPs 60 torzusteuern, d.h. wenn dieses Signalbild wahr ist, ist der 2×-Takteingang gültig. Dieses Signal ist allen VCP-Videoeingangsabschnitten gemeinsam und läuft kontinuierlich.
Das HSYNC-Signal oder horizontale Synchronisationssignal gibt den Beginn einer Abtastzeile an den VCP-Videoeingangsabschnitt an. Dieses Signal ist unter allen VCP-Videoeingangsabschnitten gemeinsam. Das VSYNC-Signal oder vertikale Synchronisationssignal gibt den Start einer Bildabtastung den VCP-Videoeingangsabschnitten an. Dieses Signal ist auch unter allen VCP-Videoeingangsabschnitten gemeinsam.
Die ODDCAM [0-4]- oder Ungerade/gerade-Indikator-Signale werden individuell an jede VCP geliefert, um den VCP-Videoeingangsabschnitt zu befähigen, nur Daten von den anderen VCPs einzugeben und nicht von sich selbst.
Die Steuersignale zu den Videoausgangsabschnitten sind HSYNC-, VSYNC-, CLKQUAL [0-4]- und BUSENABLE [0-4]-Signale. Die HSYNC- und VSYNC-Signale sind die gleichen Signale, wie sie durch die Eingangsabschnitte verwendet werden. Die CLKQUAL [0-4]- oder Pixel- bzw. -Bildelementtaktkennzeichnersignale sind individuell für jede VCP 60, wobei sie bewirken, daß jeder VCP-Videoausgangsabschnitt nur während seines jeweiligen Pixel- bzw. Bildelementbuszeitkanals aktiv ist.
Da die VCP-Pixel- bzw. -Bildelementausgangsabschnitte immer treibend sind, werden Drei-Zustands-Ausgangsisolationspuffer 67 (17) verwendet, um die VCP-Videopixel- bzw. -Bildelementausgänge von dem Pixel- bzw. Bildelementbus 82 zu isolie ren. Während jedes VCP-Pixel- bzw. -Bildelementausgangszeitkanals gibt das BUSENABLE-Signal an den VCP 60 nur jenen VCP auf den Pixel- bzw. Bildelementbus 82 frei. Demgemäß gibt das BUSENABLE-Signal den Ausgang von jedem Ausgangsisolationspuffer 67 auf den Pixel- bzw. Bildelementbus 82 frei.
Das schematische Diagramm der Pixel- bzw. Bildelementbussteuereinrichtungs-Steuerlogik ist in 16 gezeigt. Um das Diagramm zu vereinfachen, sind die Microprozessor-Schnittstellensignale, welche dazu benutzt werden, Zählwerte zu laden, nicht gezeigt. Der VCP-Eingangs- und -Ausgangsabschnitt arbeitet normalerweise mit einem Takteingang, welcher das zweifache der Pixel- bzw. Bildelementrate ist. Dieses Taktsignal, 2×PIXELCLK, wird sowohl an die VCPs 60 als auch an die Pixel- bzw. Bildelementbussteuereinrichtung 84 durch einen externen Taktoszillator geliefert. Das 2×PIXELCLK wird mittels des Teilerblocks 120 durch zwei geteilt, um die Quelle für die Taktkennzeichnersignale QUALCLK und CLKQUAL [0-4] vorzusehen. Der QUALCLK-Ausgang des Teilerblocks 120 sieht die Taktquelle für den Horizontalpixel- bzw. -bildelementzähler HCNT 122 vor. Der HCNT 122 ist für die gewünschte Zeilenlänge programmiert und zählt einmal für jede Pixel- bzw. Bildelementzeit. Der Terminalzählausgang (TC) des HCNT 122 liefert das Horizontalsynchronisationssignal an alle VCP-Videoeingangs- und -ausgangsabschnitte. HSYNC wird auch als der Takteingang zu dem Vertikalzeilenzähler VCNT 124 verwendet; demgemäß zählt der Vertikalzeilenzähler einmal für jede vollständige Zeile von Pixeln bzw. Bildelementen. Der Vertikalzeilenzähler VCNT 124 ist für die gewünschte Anzahl von Zeilen programmiert und zählt einmal für jede Abtastzeile. Der Terminalzählwert (TC) des Vertikalzeilenzählers wird als das Vertikalsynchronisationssignal VSYNC an jeden der VCP-Videoeingangs und -ausgangsabschnitte benutzt. VSYNC liefert außerdem den Takteingang zum Schlitz- bzw. Kanalzähler 126.
Der Schlitz- bzw. Kanalzähler 126 hat fünf Ausgänge, ZEITSCHLITZ = 0 bis ZEITSCHLITZ = 4. Jeder Ausgang ist in Aufeinander folge auf jeden Eingangstaktimpuls von VSYNC wahr. Diese Ausgänge werden dazu benutzt, das Pixel- bzw. Bildelementtaktkennzeichnersignal QUALCLK zu jeder VCP torzusteuern, wenn jene VCP in ihrem aktien Zeitkanal bzw. -schlitz ist. Demgemäß sind die Signale CLKQUAL [0-4] je eines auf einmal in Aufeinanderfolge aktiv. Die Signale ZEITSCHLITZ = 0 bis ZEITSCHLITZ = 4 werden extern als BUSENABLE 0 bis BUSENABLE 4 vorgesehen, um die Videoausgangsisolationspuffer 67 (17) zu dem Pixel- bzw. Bildelementbus 82 freizugeben. Entsprechend sind die ZEITSCHLITZ-Signale extern als ODDCAM [0-4] vorgesehen.
Es wird nun der Betrieb des VCP-Ausgangsabschnitts beschrieben. Die 17 ist ein Blockschaltbild, welches die Verbindung der Ausgangssteuersignale von der Pixel- bzw. Bildelementbussteuereinrichtung 84 zu den VCPs 60 miteinander zeigt. 18 ist ein Zeitsteuerungsdiagramm, das die Beziehung zwischen den Steuersignalen veranschaulicht. Wie aus dem Zeitsteuerdiagramm ersichtlich ist, ist jedes der CLKQUAL [0-4]-Signale nur während seines jeweiligen VCP-Videoausgangszeitkanals bzw. -schlitzes auf dem Pixel- bzw. Bildelementbus 82 aktiv. Wenn sie aktiv sind, laufen diese Signale mit einer Pixel- bzw. Bildelementrate, welche die Hälfte des 2×PIXELCLK-Ausgangssignals ist.
Bei jeder VCP 60 ist deren Videoausgangsabschnitt so programmiert, daß eine Unterbrechung am Beginn ihres aktiven Ausgangszeitkanals bzw. -schlitzes, jedoch vor dem aktiven Pixel- bzw. Bildelementbereich in jenem Zeitkanal bzw. -schlitz, bewirkt wird. Ein Ablaufdiagramm des Videoausgangsunterbrechungshantierers ist in 19 gezeigt. Nachdem eine Videoausgangsunterbrechung in dem Programmschritt 200 empfangen worden ist, bestimmt das Programm als nächstes, ob ein neuer Puffer von decodierten Daten im Schritt 202 verfügbar ist. Wenn neue Daten verfügbar sind, stellt das Programm die DMA-Zeiger auf, um Pixel- bzw. Bildelementdaten von den neu decodierten Daten im Schritt 204 zu ziehen. Wenn kein vollständiger Puffer von neuen decodierten Daten verfügbar ist, wird der DMA-Zeiger so eingestellt, daß die alten Pixel- bzw. Bildelementdaten im Schritt 206 wieder gezeigt werden. Der Schritt 204 gibt an, daß ein Doppelpufferungsschema derart verwendet wird, daß der Videodecodierer nicht den gleichen Puffer füllt, welcher gerade gezeigt wird.
Es wird nun der Betrieb des Videoeingangsabschnitts beschrieben. 20 zeigt die Verbindung der Eingangssteuersignale von der Pixel- bzw. Bildelementbussteuereinrichtung 84 zu den VCPs 60 miteinander. In 21 gibt das Zeitsteuerungsdiagramm die Beziehung zwischen den Videoeingangssteuersignalen an. Wenn ein spezielles ODDCAM-Signal auf einer logischen Null ist, ist seine zugeordnete VCP in ihrem eigenen Zeitkanal bzw. -schlitz des Pixel- bzw. Bildelementbusses aktiv, d.h. jene VCP würde Daten auf den Pixel- bzw. Bildelementbus 82 ausgeben. Wenn das Signal eine logische Eins ist, gibt einer der anderen VCPs Daten auf den Pixel- bzw. Bildelementbus 82 aus. Durch Programmieren des VCP-Videoeingangsabschnitts darauf, daß nur eingegeben wird, wenn ODDCAM = 1, wird dann der VCP nur Daten von anderen Einrichtungen und nicht von sich selbst eingeben.
Der Videoeingangsabschnitt des VCP 60 ist zum Vorsehen einer Unterbrechnung an dem Ende von jeder Abtastung programmiert. Der Betrieb des Unterbrechungshantierers für Umcodierungsanwendungen ist in dem Programmablaufdiagramm der 22 gezeigt. Wenn eine Unterbrechung im Schritt 210 empfangen wird, wird das ODDCAM-Signal 212 nachgeprüft, um zu bestimmen, ob der gegenwärtige Zeitkanal bzw. -schlitz der Zeitkanal bzw. -schlitz der speziellen VCP ist. Der Schlitz- bzw. Kanalzähler wird bei 214 auf Null zurückgestellt, wenn ODDCAM Null ist, was angibt, daß der gegenwärtige Zeitkanal bzw. -schlitz zu dem VCP gehört. Andernfalls wird der Schlitz- bzw. Kanalzähler 216 um Eins erhöht. Als nächstes kontrolliert der Hantierer bei 218, um zu sehen, ob ein leerer Puffer verfügbar ist. Wenn es einen leeren Puffer gibt, gleitet der Hantierer im Schritt 220 zu dem neuen Puffer über. Die Eingangs-DMA wird dann ein gestellt, um die in dem Puffer befindlichen Pixel- bzw. Bildelementdaten im Schritt 220 in den Speicher zu tun. Schließlich wird der Schlitz- bzw. Kanalzähler bei 224 überprüft, um zu bestimmen, ob der nächste Zeitkanal bzw. -schlitz der gewünschte Zeitkanal bzw. -schlitz ist, welcher erfaßt bzw. festgehalten werden soll. Die gewünschte Zeitkanal- bzw. -schlitzbestimmung wird in den VCP 60 programmiert. Demgemäß ist der VCP 60 so programmiert, daß er eine Selektor- bzw. Wählerfunktion ausführt, um unter den möglichen Eingangszeitkanälen bzw. -schlitzen zu wählen. Wenn der nächste Zeitkanal bzw. -schlitz der gewünschte Zeitkanal bzw. -schlitz ist, dann wird die DMA bei 226 freigegeben und wird bei der nächsten vertikalen Synchronisation aktiv werden, wobei sie die Pixeldaten aus dem nächsten Puffer erfaßt bzw. festhält.
Für Anwendungen der kontinuierlichen Präsenz oder räumliches Mischen arbeitet der Videounterbrechungshantierer gleichartig, ausgenommen, daß es notwendig ist, die Eingangs-DMA einzustellen, um Pixel- bzw. Bildelementdaten in unterschiedliche Bereiche des Speichers zu tun, um ein räumliches Mischen der Bilder zu erreichen, die während der anderen VCP-Zeitkanäle bzw. -schlitze eingegeben werden. Dieser Unterbrechungshantierer ist in dem Programmablaufdiagramm der 23 gezeigt.
Wenn eine Unterbrechung im Schritt 230 empfangen wird, wird das ODDCAM-Signal bei 232 überprüft, um zu bestimmen, ob der gegenwärtige Zeitkanal bzw. -schlitz der spezielle Zeitkanal bzw. -schlitz des VCP ist. Der Schlitz- bzw. Kanalzähler wird bei 234 auf Null zurückgestellt, wenn ODDCAM Null ist, was angibt, daß der gegenwärtige Zeitkanal bzw. -schlitz der Zeitkanal bzw. -schlitz des speziellen VCP ist. Als nächstes kontrolliert der Hantierer bei 236, um zu sehen, ob ein leerer Puffer verfügbar ist. Wenn ein leerer Puffer verfügbar ist, gleitet der Hantierer bei 238 zu dem neuen Puffer über. Die Eingangs-DMA wird dann eingestellt, um den Pufferinhalt bei 240 in den Speicher zu tun. Wenn ODDCAM nicht Null ist, wird der Schlitz- bzw. Kanalzähler stattdessen bei 242 um Eins er höht. Die Eingangs-DMA wird außerdem eingestellt, um Pufferinhalte in den Speicher in einem Bereich, der auf dem Schlitz- bzw. Kanalzählerwert basiert, bei 244 zu tun.
Die Hauptprogrammarbeit in jedem VCP 60 fährt eine Videocodecschleife, wie in dem Programmablaufdiagramm der 24 gezeigt ist. Es werden Flaggen dazu benutzt, um mit dem Unterbrechungshantierer-Routinen (oben beschrieben) zu kommunizieren, um anzuzeigen, ob ein decodierter Puffer erzeugt worden ist oder ob ein Puffer bereit ist, codiert zu werden.
Wenn im Schritt 250 genügend komprimierte Videodaten in dem Eingangs-FIFO vorhanden sind, dann beginnt die Dekomprimierung im Schritt 252. Dieses geschieht weiter durch die Schleife 254, bis ein vollständiges Einzelbild bzw. ein vollständiger Datenübertragungsblock decodiert ist. Wenn das Einzelbild bzw. der Datenübertragungsblock decodiert ist, wird bei 256 eine Flagge gesetzt, um dem Ausgangsvideounterbrechungshantierer anzuzeigen, daß der decodierte Puffer bereit ist. Wenn nicht genügend Daten in dem Eingangs-FIFO waren, dann wird die Codierroutine im Schritt 258 aufgerufen.
Die Codier-FIFO wird bei 258 überprüft, um zu sehen, ob genügend Raum für den codierten Videostrom vorhanden ist. Wenn das der Fall ist, wird der erfaßte bzw. festgehaltene Pixel- bzw. Bildelementdatenpuffer bei 260 komprimiert, die Codierpufferflagge wird bei 262 wieder gesetzt, und dann kehrt der Programmfluß zum Beginn der Schleife zurück. Wenn nicht genügend Raum in dem Codier-FIFO für komprimierte Daten vorhanden ist, dann geht das Programm ohne Codieren eines neuen Einzelbilds bzw. Datenübertragungsblocks zum Beginn der Schleife.
Nachdem eine Ausführungsform des digitalen Umcodierens der vorliegenden Erfindung beschrieben worden ist, wird nun der Aspekt der Erfindung, welcher die Berechnungszeit für den Codiervorgang beim Videoumcodieren der auf Bewegungskompensation basierenden Algorithmen beschrieben.
Einer der Nachteile des Umcodierens für das Abhalten von Konferenzen ist die schädliche Wirkung auf den natürlichen Konversationsfluß aufgrund der Totalsystemverzögerungen. Ein signifikanter Teil der Codierzeit zum Ausführen von auf Bewegungskompensation basierenden Videokomprimierungsalgorithmen wird veranlaßt durch den Bewegungsverlagerungs- bzw. -verschiebungssuchvorgang. Es ist wünschenswert, die Zeit, die für den Bewegungsverlagerungs- bzw. -verschiebungssuchvorgang notwendig ist, zu reduzieren.
Die Bewegungskompensation ist eine Technik, die oft in Videokomprimierungsalgorithmen, wie H.261, MPEG und Indeo, benutzt wird. Diese Technik wird dazu benutzt, den Betrag an Information zu vermindern, der dazu benötigt wird, Bilder in einer Videoaufeinanderfolge darzustellen, und zwar durch Ausnutzung der Tatsache, daß der Inhalt von aufeinanderfolgenden Einzelbildern in einer Videoaufeinanderfolge signifikante Bereiche von gleichartigem Inhalt hat, welche räumlich zwischen aufeinanderfolgenden Einzelbildern übertragen werden können. Eine Abschätzung des nächsten Einzelbilds wird unter Benutzung der Information in dem vorherigen Einzelbild oder Einzelbildern zusammen mit Verlagerungs- bzw. Verschiebungsinformation erzeugt.
Typischerweise wird jedes Bild-Einzelbild bzw. jeder Bild-Datenübertragungsblock als Blöcke aus Pixeln bzw. Bildelementen codiert, wie 8×8, 16×16 etc. Für jeden dieser Blöcke gibt ein Verlagerungs- bzw. Verschiebungsvektor einen entsprechenden Block in dem vorherigen Einzelbild- bzw. Datenübertragungsblock an, welcher räumlich übertragen werden kann, um eine Abschätzung des gegenwärtigen Blocks von Pixeln bzw. Bildelementen zu bilden. Die Verlagerungs- bzw. Verschiebungsinformation wird gewöhnlich als ein Feld von Vektoren dargestellt, von denen jeder eine horizontale und vertikale Verlagerung bzw. Verschiebung hat.
Ein Bewegungsabschätzungsverfahren wird dazu benutzt, um das Vektorfeld von Verlagerungs- bzw. Verschiebungsabschätzungen zu erzeugen, und zwar basierend auf Pixeln bzw. Bildelementen in dem gegenwärtigen und vorherigen Einzelbild oder Einzelbildern. Die Bewegungsabschätzung könnte unter Verwendung von irgendeiner der bekannten Verfahren ausgeführt werden, wie Musteranpassungs-, Bildelementrekursiv- oder Transformierungsgebietstechniken.
Eine typische Bewegungsabschätzungstechnik, die benutzt wird, ist die Musteranpassung. In diesem Verfahren wird jeder interessierende Block in dem gegenwärtigen Einzelbild mit Blöcken in dem vorherigen Einzelbild oder den vorherigen Einzelbildern verglichen. Es wird ein Differenzmaß bzw. eine Differenzmetrik der Pixel bzw. Bildelemente in dem Block von dem gegenwärtigen Einzelbild gegenüber dem Block in dem vorherigen Einzelbild berechnet. Dieses wird über einen gewissen beschränkten Bereich von Verlagerungen bzw. Verschiebungen (zum Beispiel einem Bereich von 15 Pixeln bzw. Bildelementen horizontal mal 15 Pixeln bzw. Bildelementen vertikal) in dem vorherigen Einzelbild versucht, und die Verlagerung bzw. Verschiebung, welche den niedrigsten Differenzwert hatte, wird als die Verlagerungsabschätzung benutzt. Das Differenzmaß- bzw. -metrikverfahren könnte die Summe von Absolutwerten der Differenzen zwischen Pixeln bzw. Bildelementen sein, oder die Summe der quadrierten Differenzen. Der Blockanpassungssuchvorgang wird typischerweise über das volle Bild ausgeführt, wobei alle von den möglichen Blöcken innerhalb der Verlagerungs- bzw. Verschiebungsbereichsgrenzen verglichen werden.
Im allgemeinen und wie weiter unten beschrieben ist, wird die von einem Decodierer als Teil eines normalen Decodiervorgangs empfangene Bewegungsinformation nach geeignetem Filtern und Skalieren sowie Aufzeichnen, wenn nötig, zu einem Codierer geschickt.
Diese Bewegungsvektoren können in einigen Fällen direkt von dem Codierer benutzt werden, was es dem Codierer ermöglicht, den Bewegungsabschätzungsschritt zu überspringen, wodurch die Berechnungen signifikant reduziert werden. Die Vektorfelder könnten in Fällen direkt benutzt werden, in denen die Blockgrößen des decodierten Bilds und codierten Bilds die gleichen sind, wie bei einer Ratenanpassungsanwendung für H.320-Terminals.
Das Bewegungsvektorfeld könnte auch als ein Ausgangsparameter für weitere Verlagerungs- bzw. Verschiebungsabschätzung benutzt werden. Der fortgesetzte Verlagerungs- bzw. Verschiebungssuchvorgang könnte dann über einen beschränkteren Bereich erfolgen, so daß demgemäß die Berechnungen reduziert würden. Zum Beispiel kann in H.261 die Verlagerung bzw. Verschiebung über einen Bereich von +/–15 Pixeln bzw. Bildelementen reichen. Durch Beginnen des Suchvorgangs bei der Verlagerung bzw. Verschiebung, die durch den entsprechenden Vektor von dem Decodierer gegeben wird, könnte der Suchbereich nun auf +/–3 Pixel bzw. Bildelemente beschränkt werden, so daß die Bewegungsabschätzungssuchvorgangsberechnungen um 96 % vermindert werden.
In anderen Fällen würden es die Bewegungsvektoren von dem Decodierer benötigen, verarbeitet zu werden, bevor sie von dem Codierer verwendet werden. Zum Beispiel bei einer Videoalgorithmusumcodierung von einem Algorithmus (Algorithmus H) unter Verwendung einer räumlichen Auflösung von 352×288 Pixeln bzw. Bildelementen zu einem anderen (Algorithmus I) unter Verwendung von 320×240 Pixeln bzw. Bildelementen ist eine 1,1:1 Pixelskalierung horizontal und eine 1,2:1 Pixelskalierung vertikal erforderlich. Wenn die beiden Algorithmen die gleichen Pixel- bzw. Bildelementblockgrößen benutzen, dann würden die Vektorfelder mit den gleichen Faktoren wie die Bildelement- bzw. Pixelbilder skaliert (dezimiert).
Wenn die beiden Algorithmen ungleiche Blockgrößen verwenden, würden die Vektorfelder mit anderen Faktoren als die Bildelement- bzw. Pixelbilder skaliert werden. Wenn in dem obigen Beispiel der Algorithmus H 16×16 Blöcke für die Bewegungskompensation benutzt, und der Algorithmus I 8×8 Blöcke für die Bewegungskompensation benutzt, dann würde der Algorithmus H ein 22×18 Eintrittsvektorfeld benutzen, während der Algorithmus I ein 40×36 Eintrittsvektorfeld benutzen würde. In diesem Falle würde es das 22×18 Vektorfeld von dem Decodierer benötigen, auf 40×36 interpoliert zu werden, bevor es von dem Codierer verwendet wird.
Als ein weiteres Beispiel sei angegeben, daß der Algorithmus H eine Einzelpixel- bzw. -bildelementgenauigkeit für die Verlagerungs- bzw. Verschiebungsabschätzung verwenden könnte, während der Algorithmus I die halbe Pixel- bzw. Bildelementverlagerungs- bzw. -verschiebungsabschätzungen benutzen könnte, in welchem Falle es notwendig wäre, daß das einzelne Pixel- bzw. Bildelementformat auf eine fraktionelle Darstellung bzw. Bruchteildarstellung umgesetzt wird.
Ein anderes Beispiel verwendet die Vektorfelder von den Decodierern in einer Anwendung kontinuierlicher Präsenz wieder. In der kontinuierlichen Präsenz werden viele Bilder skaliert und zu einem einzigen Bild verfliest, dann wieder codiert. Es sei das einfache Beispiel von kontinuierlicher Präsenz mit einer Mischung von vier Bildern betrachtet, die um die Hälfte horizontal und vertikal skaliert, zu einem einzigen (volle Größe) Bild verfliest und wiedercodiert werden. Die Vektorfelder würden auch um die Hälfte horizontal und vertikal skaliert, in der gleichen Reihenfolge wie die entsprechenden Pixel- bzw. Bildelementdatenblöcke zu einem einzigen Vektorfeld verfliest und dann durch den Codierer wiederverwendet werden.
Wiederum könnten die skalierten Vektorfelder direkt verwendet werden, oder als ein Ausgangsparameter für weitere Abschätzung über einen verminderten Suchbereich, wodurch die Berechnungen für die Bewegungsabschätzung des Codierers signifikant reduziert werden. Diese Techniken sind auf Algorithmen anwendbar, welche andere Bewegungsabschätzungstechniken als die Blockanpassung verwenden mögen, solange die Vektorfelder auf das von dem Codierer verwendete Format verarbeitet werden.
25 ist ein Blockschaltbild, welches die Wiederverwendung von Bewegungskompensationsinformation durch einen Codierer veranschaulicht. Ein typischer auf Bewegungskompensation basierender Videodecodierer 400 und -codierer 410 sind gezeigt. In dem Decodierer 400 wird restliche (Differenz)-Information einem Restdecodierer 402 präsentiert, um decodierte Reste bzw. Resdiuen zu erzeugen. Die Verlagerungs- bzw. Verschiebungsvektoren, die dem Bewegungskompensationsblock 404 dargeboten werden, werden zusammen mit einem vorher decodierten Einzelbild bzw. Datenübertragungsblock oder vorher decodierten Einzelbildern bzw. Datenübertragungsblöcken 406 benutzt, um eine Abschätzung bzw. Bewertung des gegenwärtigen Einzelbilds bzw. Datenübertragungsblocks zu bestimmen. Diese abgeschätzte bzw. bewertete gegenwärtige Einzelbild- bzw. Datenübertragungsblockinformation wird bei 408 mit den decodierten Resten bzw. Residuen zur Bildung eines dekomprimierten Bilds kombiniert.
In dem typischen Decodierer 410 ist das gegenwärtige Einzelbild bzw. der gegenwärtige Datenübertragungsblock 412 eine neue Bild-Einzelbild- bzw. Bild-Datenübertragungsblock-Eingabe in den Codierer. Das gegenwärtige Einzelbild bzw. der gegenwärtige Datenübertragungsblock 412 und ein vorheriges Einzelbild bzw. ein vorheriger Datenübertragungsblock oder Einzelbilder bzw. Datenübertragungsblöcke 416 werden dazu benutzt, eine Abschätzung der Bewegungsverlagerung bzw. -verschiebung zwischen Bildern auszuführen. Die Verlagerungs- bzw. Verschiebungsinformation 430 wird durch die Bewegungskompensation 432 zum Erzeugen einer Abschätzung 438 des gegenwärtigen Einzelbilds bzw. Datenübertragungsblocks unter Verwendung des decodierten vorherigen Einzelbilds bzw. Datenübertragungsblocks 424 benutzt. Die Differenz (Rest bzw. Residuum) gegenüber dem gegenwärtigen Einzelbild bzw. Datenübertragungsblock und dessen Abschätzung wird bei 426 berechnet und durch den Restcodierer bzw. Residualcodierer 428 codiert (gewöhnlich mit einem verlustbehafteten Verfahren, die diskrete Cosinustransformation und Quantisierung). Das decodierte vorherige Einzelbild bzw. der decodierte vorherige Datenübertragungsblock 424 wird durch Decodieren des Rests bzw. Residuums bei 436 und Summieren mit den abgeschätzten Pixeln bzw. Bildelementen bei 434 berechnet.
Gemäß der vorliegenden Erfindung wird die Videoumcodierung zwischen dem Decodierer 400 und dem Codierer 410 dadurch verbessert, daß Gebrauch von den Verlagerungs- bzw. Verschiebungsvektoren vom Decodierer in dem Codierprozeß gemacht wird. Speziell werden Verlagerungs- bzw. Verschiebungsvektoren durch den Codierer 410 von dem Decodierer 400 über einen Weg 409 empfangen. Die Verlagerungs- bzw. Verschiebungsvektoren werden in den Bewegungsabschätzungsblock 414 des Codierers 410 geleitet, um entweder direkt oder als ein Ausgangsparameter für eine weitere Verlagerungs- bzw. Verschiebungsabschätzung in dem Codierprozeß benutzt zu werden. Ein Pixel- bzw. Bildelementskalierungsblock 420 sieht eine Pixel- bzw. Bildelementskalierung zwischen Algorithmen vor, die unterschiedliche räumliche Auflösungen haben. Ein Bewegungsvektorskalierungsblock 422 sieht ein Skalieren oder Wiederformatieren der Verlagerungs- bzw. Verschiebungsvektoren zwischen Algorithmen vor, welche ungleiche Pixel- bzw. Bildelementblockgrößen oder Bildformate haben.
Es ist zu beachten, daß die hier beschriebene Umcodierung auf dem Pixel- bzw. Bildelementgebiet ausgeführt wird. Durch Ausführen der Umcodierung auf dem Pixel- bzw. Bildelementgebiet kann ein weiterer bzw. umfangreicherer Bereich von Komprimierungsalgorithmen angepaßt werden, einschließlich Algorithmen, die nicht auf Transformationstechniken basieren. Jedoch kann das Umcodierung auch auf dem Transformationsgebiet in solchen Fällen ausgeführt werden, in denen die Algorithmen auf Transformation basieren.
In Begriffen der früher beschriebenen Videoumcodierungsausführungsform können der Videodecodierer 400 und der Videocodierer 410 ein separater Decodierer 102-i bzw. Codierer 106-j sein (5).
Das bei 408 in 25 erzeugte dekomprimierte Bild kann auf dem Pixel- bzw. Bildelementbus 82 (5) plaziert werden, um eingegeben und durch den Codierer 410 codiert zu werden. Die Verlagerungs- bzw. Verschiebungsvektoren können vom Decodierer 400 zum Codierer 410 über einen Bus, wie den PK-Bus 80 (11) geschickt werden.
Äquivalente
Obwohl dieser Erfindung speziell unter Bezugnahme auf bevorzugte Ausführungsformen derselben gezeigt und beschrieben worden ist, versteht es sich für den Fachmann, daß verschiedene Änderungen in der Form und in den Details darin ausgeführt werden können, ohne den Geist und Bereich der Erfindung, wie sie durch die beigefügten Ansprüche definiert ist, zu verlassen. Zum Beispiel können die neuartigen Funktionen des VCP, obwohl sie zu einem großen Ausmaß unter Verwendung von programmierbaren Spezialzweckvideoeinrichtungen ausgeführt sind, durch Ausführungsformen ausgeführt werden, die vollständig in nichtprogrammierbarer Hardware verwirklicht sind, welche speziell auf die offenbarten Funktionen ausgelegt ist, wie sie auch vollständig in einem programmierten Allgemeinzweckcomputer ausgeführt sein können. Jedoch ermangelt nichtprogrammierbare Hardware der Flexibilität, und programmierte Allgemeinzweckhardware ermangelt der Geschwindigkeit.

Claims

Mehrpunktsteuereinheit zum Empfangen von komprimierten Videosignalen von Terminals in einer Konferenz und zum Übertragen bzw. Senden von ausgewählten komprimierten Videosignalen zu den Terminals, wobei die Mehrpunktsteuereinheit folgendes umfaßt: Decodiermittel (102) zum Decodieren der komprimierten Videosignale von jeweiligen Terminals zu unkomprimierten Videosignalen auf einem Pixel- bzw. Bildelementgebiet; einen Zeitmultiplexbus, der die unkomprimierten Videosignale in Zeitkanälen bzw. -schlitzen, welche jeweiligen Terminals zugeordnet sind, empfängt, wobei der Bus ein Parallelpixel- bzw. -bildelementbus (82) ist; Selektor- bzw. Wählmittel zum Auswählen von unkomprimierten Videosignalen aus einem oder mehreren Zeitkanälen bzw. -schlitzen des Zeitmultiplexbusses; und Codiermittel (106) zum Codieren der ausgewählten unkomprimierten Videosignale für die Übertragung bzw. das Senden zu jeweiligen Terminals, worin das Codiermittel (106) Bewegungsverlagerungs- bzw. -verschiebungsvektoren empfängt, die den ausgewählten unkomprimierten Videosignalen zur Bewegungsabschätzung zugeordnet sind.
Mehrpunktsteuereinheit des Anspruchs 1, worin die Decodier- und Codiermittel (102, 106) unterschiedliche Komprimierungsalgorithmen aufweisen, welche Komprimierungsalgorithmen von jeweiligen Terminals entsprechen bzw. mit Komprimierungsalgorithmen von jeweiligen Terminals übereinstimmen.
Mehrpunktsteuereinheit des Anspruchs 1, worin die Decodier- und Codiermittel (102, 106) mit Datenraten arbeiten, die jeweiligen Terminals entsprechen bzw. mit jeweiligen Terminals übereinstimmen, derart, daß Terminals, die unterschiedliche Datenraten haben, in der Konferenz miteinander verkehren können.
Mehrpunktsteuereinheit des Anspruchs 1, worin das Codiermittel (106) ausgewählte unkomprimierte Videosignale aus einer Mehrzahl von Zeitkanälen bzw. -schlitzen zum Bilden von zusammengesetzten codierten Videosignalen codiert.
Mehrpunktsteuereinheit des Anspruchs 1, weiter umfassend Skalierungs- bzw. Normierungsmittel (104, 108) zum Skalieren bzw. maßstäblichen Ändern bzw. Normieren von unkomprimierten Videosignalen auf eine wünschenswerte Auflösung.
Mehrpunktsteuereinheit zum Empfangen von komprimierten Videosignalen von Terminals in einer Konferenz und zum Übertragen bzw. Senden von ausgewählten komprimierten Videosignalen zu den Terminals, wobei die Mehrpunktsteuereinheit folgendes umfaßt: einen ersten Zeitmultiplexbus (36), der Zeitkanäle bzw. -schlitze zum Transportieren von komprimierten Videosignalen und Audiosignalen hat; wenigstens einen Brückenprozessor (22), der an den ersten Zeitmultiplexbus (36) zum Platzieren von komprimierten Videosignalen und Audiosignalen von jeweiligen Terminals in Zeitkanälen bzw. -schlitzen des ersten Zeitmultiplexbusses (36) angekoppelt ist; Decodiermittel (102) zum Decodieren von komprimierten Videosignalen, die aus Zeitkanälen bzw. -schlitzen des ersten Zeitmultiplexbusses (36) empfangen worden sind; einen zweiten Zeitmultiplexbus (82), der decodierte Videosignale in Zeitkanälen bzw. -schlitzen, welche jeweiligen Terminals zugeordnet sind, empfängt; Selektor- bzw. Wählmittel zum Auswählen von decodierten Videosignalen aus einem oder mehreren Zeitkanälen bzw. -schlitzen des zweiten Zeitmultiplexbusses (82); und Codiermittel (106) zum Codieren der ausgewählten decodierten Videosignale und zum Aufbringen der codierten Videosignale auf den ersten Zeitmultiplexbus (36); wobei wenigstens ein Brückenprozessor (22) die ausgewählten codierten Videosignale und Audiosignale von dem ersten Zeitmultiplexbus (36) zur Übertragung bzw. zum Senden zu jeweiligen Terminals empfängt.
Mehrpunktsteuereinheit des Anspruchs 6, weiter umfassend Skalierungs- bzw. Normierungsmittel (104) zum Skalieren bzw. maßstäblichen Ändern bzw. Normieren von decodierten Videosignalen auf eine wünschenswerte Auflösung, worin der zweite Zeitmultiplexbus (82) skalierte bzw. maßstäblich geänderte bzw. normierte decodierte Videosignale empfängt, und worin das Codiermittel (106) die ausgewählten skalierten bzw. maßstäblich geänderten bzw. normierten decodierten Videosignale aus einer Mehrzahl von Zeitkanälen bzw. -schlitzen zum Bilden von zusammengesetzten codierten Videosignalen codiert, wobei die Decodier- und Codiermittel (102, 106) unterschiedliche Komprimierungsalgorithmen aufweisen, welche Komprimierungsalgorithmen von jeweiligen Terminals entsprechen bzw. mit Komprimierungsalgorithmen von jeweiligen Terminals übereinstimmen, und wobei die Decodier- und Codiermittel (102, 106) bei Datenraten arbeiten, die jeweiligen Terminals entsprechen bzw. mit jeweiligen Terminals übereinstimmen, derart, daß Terminals, welche unterschiedliche Datenraten haben, in der Konferenz miteinander verkehren können.
Mehrpunktsteuereinheit des Anspruchs 6, worin von wenigstens einem Brückenprozessor (22) empfangene Audiosignale um einen genügenden Betrag zum Kompensieren der Codierung und Decodierung von Videosignalen verzögert werden.
Mehrpunktsteuereinheit des Anspruchs 6, worin das Codiermittel (106) Bewegungsverlagerungs- bzw. -verschiebungsvektoren empfängt, die den ausgewählten decodierten Videosignalen zur Bewegungsabschätzung zugeordnet sind.
Videoverarbeitungseinheit in oder an einer Mehrpunktsteuereinheit in einem Videotelekonferenzsystem, in welchem eine Mehrzahl von audiovisuellen Terminals, die zum Senden und Empfangen von komprimierten digitalen Videosignalen betreibbar sind, miteinander durch die Mehrpunktsteuereinheit kommunizieren, umfassend: einen Pixel- bzw. Bildelementbus (82), der eine Mehrzahl von Zeitkanälen bzw. -schlitzen zum Transportieren von unkomprimierten digitalen Videosignalen hat; eine Pixel- bzw. Bildelementbussteuereinrichtung (84) zum Steuern des Zugangs zu dem Pixel- bzw. Bildelementbus (82); und eine Mehrzahl von Prozessoren (60), wobei jeder Prozessor (60) an den Pixel- bzw. Bildelementbus (82) angekoppelt und wenigstens einem Zeitkanal bzw. -schlitz zugeordnet ist; wobei jeder Prozessor (60) einem jeweiligen audiovisuellen Terminal, das an der Konferenz teilnimmt, zuteilbar ist; wobei jeder Prozessor (60) folgendes umfaßt: Mittel zum Empfangen von ersten komprimierten digitalen Videosignalen von einem audiovisuellen Terminal, das dem Prozessor zugeteilt ist; Mittel zum Decodieren (102) der ersten komprimierten digitalen Videosignale zu ersten unkomprimierten digitalen Videosignalen; Mittel zum Skalieren bzw. maßstäblichen Ändern bzw. Normieren (104) der ersten unkomprimierten digitalen Videosignale auf eine wünschenswerte Auflösung; Mittel zum Einführen der skalierten bzw. maßstäblich geänderten bzw. normierten ersten unkomprimierten digitalen Videosignale in den wenigstens einen zugeordneten Zeitkanal bzw. -schlitz auf dem Pixel- bzw. Bildelementbus (82), wenn ein Ausgangssteuersignal von der Pixel- bzw. Bildelementbussteuereinrichtung (84) empfangen wird; Mittel zum Empfangen von zweiten unkomprimierten digitalen Videosignalen aus irgendeinem Zeitkanal bzw. -schlitz, der irgendeinem Prozessor (60) zugeordnet ist, wenn ein Eingangssteuersignal von der Pixel- bzw. Bildelementbussteuereinrichtung (84) empfangen wird; Mittel zum Skalieren bzw. maßstäblichen Ändern bzw. Normieren (108) der zweiten unkomprimierten digitalen Videosignale auf eine wünschenswerte Auflösung; Mittel zum Codieren (106) der skalierten bzw. maßstäblich geänderten bzw. normierten zweiten unkomprimierten digitalen Videosignale zu zweiten komprimierten digitalen Videosignalen; und Mittel zum Übertragen bzw. Senden der zweiten komprimierten digitalen Videosignale zu dem audiovisuellen Terminal, das dem Prozessor zugeteilt ist.
Videoverarbeitungseinheit des Anspruchs 10, worin die Decodiermittel (102) und die Codiermittel (106) von jedem Prozessor (60) einen Codieralgorithmus umfassen, wobei der Codieralgorithmus für einen jeweiligen Prozessor (60) einem Terminalcodieralgorithmus für ein jeweiliges zugeteiltes audiovisuelles Terminal entspricht bzw. mit einem Terminal codieralgorithmus für ein jeweiliges zugeteiltes audiovisuelles Terminal übereinstimmt und sich fakultativ von den Codieralgorithmen von anderen Prozessoren (60) in der Konferenz unterscheidet, derart, daß die Konferenz audiovisuelle Terminals umfaßt, die fakultativ unterschiedliche Terminalcodieralgorithmen haben.
Videoverarbeitungseinheit des Anspruchs 10, worin ein jeweiliges zugeteiltes audiovisuelles Terminal komprimierte digitale Videosignale mit einer Übertragungsrate sendet und empfängt, die sich fakultativ von der Übertragungsrate von anderen audiovisuellen Terminals in der Konferenz unterscheidet.
Videoverarbeitungseinheit des Anspruchs 10, worin ein jeweiliger Prozessor (60) weiter Mittel zum räumlichen Mischen einer Mehrzahl von zweiten unkomprimierten digitalen Videosignalen, die von dem Pixel- bzw. Bildelementbus (82) empfangen worden sind, zum Bilden eines zusammengesetzten unkomprimierten digitalen Videosignals für das Codieren und die Übertragung bzw. das Senden durch das Codier- (106) und Übertragungs- bzw. Sendemittel des jeweiligen Prozessors umfaßt.
Videotelekonferenzsystem, umfassend: eine Mehrzahl von audiovisuellen Terminals, wobei jedes audiovisuelle Terminal zum Senden und Empfangen von komprimierten digitalen Videosignalen betreibbar ist; und eine Mehrpunktsteuereinheit (10) zum Ermöglichen, daß audiovisuelle Terminals in einer Konferenz miteinander kommunizieren, welche eine Videoverarbeitungseinheit (26) hat, wobei die Videoverarbeitungseinheit folgendes umfaßt: einen Pixel- bzw. Bildelementbus (82), der eine Mehrzahl von Zeitkanälen bzw. -schlitzen für das Transportieren von unkomprimierten digitalen Videosignalen hat; eine Pixel- bzw. Bildelementbussteuereinrichtung (84) zum Steuern des Zugangs zu dem Pixel- bzw. Bildelementbus (82); und eine Mehrzahl von Prozessoren (60), wobei jeder Prozessor (60) an den Pixel- bzw. Bildelementbus (82) angekoppelt und wenigstens einem Zeitkanal bzw. -schlitz zugeordnet ist; wobei jeder Prozessor (60) einem jeweiligen audiovisuellen Terminal, das an der Konferenz teilnimmt, zuteilbar ist; wobei jeder Prozessor folgendes umfaßt: Mittel zum Empfangen von ersten komprimierten digitalen Videosignalen von einem audiovisuellen Terminal, das dem Prozessor zugeteilt ist; Mittel zum Decodieren (102) der ersten komprimierten digitalen Videosignale zu ersten unkomprimierten digitalen Videosignalen; Mittel zum Skalieren bzw. maßstäblichen Ändern bzw. Normieren (104) der ersten unkomprimierten digitalen Videosignale auf eine wünschenswerte Auflösung; Mittel zum Einführen der skalierten bzw. maßstäblich geänderten bzw. normierten ersten unkomprimierten digitalen Videosignale in den wenigstens einen zugeordneten Zeitkanal bzw. -schlitz auf dem Pixel- bzw. Bildelementbus (82), wenn ein Ausgangssteuersignal von der Pixel- bzw. Bildelementbussteuereinrichtung (84) empfangen wird; Mittel zum Empfangen von zweiten unkomprimierten digitalen Videosignalen aus irgendeinem Zeitkanal bzw. -schlitz, der irgendeinem Prozessor (60) zugeordnet ist, wenn ein Eingangssteuersignal von der Pixel- bzw. Bildelementbussteuereinrichtung (84) empfangen wird; Mittel zum Skalieren bzw. maßstäblichen Ändern bzw. Normieren (108) der zweiten unkomprimierten digitalen Videosignale auf eine wünschenswerte Auflösung; Mittel zum Codieren (106) der skalierten bzw. maßstäblich geänderten bzw. normierten zweiten unkomprimierten digitalen Videosignale zu zweiten komprimierten digitalen Videosignalen; und Mittel zum Übertragen bzw. Senden der zweiten komprimierten digitalen Videosignale zu dem audiovisuellen Terminal, welches dem Prozessor zugeteilt ist.
Videotelekonferenzsystem des Anspruchs 14, worin die Decodiermittel (102) und die Codiermittel (106) von jedem Prozessor einen Codieralgorithmus umfassen, wobei der Codieralgorithmus für einen jeweiligen Prozessor (60) einem Terminalcodieralgorithmus für ein jeweiliges zugeteiltes audiovisuelles Terminal entspricht bzw. mit einem Terminalcodieralgorithmus für ein jeweiliges zugeteiltes audiovisuelles Terminal übereinstimmt und sich fakultativ von den Codieralgorithmen von anderen Prozessoren (60) in der Konferenz unterscheidet, derart, daß die Konferenz audiovisuelle Terminals umfaßt, die fakultativ unterschiedliche Terminalcodieralgorithmen haben.
Videotelekonferenzsystem des Anspruchs 14, worin ein jeweiliges zugeteiltes audiovisuelles Terminal komprimierte digitale Videosignale mit einer Übertragungsrate sendet und empfängt, die sich fakultativ von der Übertragungsrate von anderen audiovisuellen Terminals in der Konferenz unterscheidet.
Videotelekonferenzsystem des Anspruchs 14, worin ein jeweiliger Prozessor (60) weiter Mittel zum räumlichen Mischen einer Mehrzahl von zweiten unkomprimierten digitalen Videosignalen, die von dem Pixel- bzw. Bildelementbus (82) empfangen worden sind, zum Bilden eines zusammengesetzten unkomprimierten digitalen Videosignals für das Codieren und die Übertragung bzw. das Senden durch das Codier- (106) und Übertragungs- bzw. Sendemittel des jeweiligen Prozessors umfaßt.
Videote1ekonferenzsystem, umfassend: eine Mehrzahl von audiovisuellen Terminals (38), wobei jedes audiovisuelle Terminal zum Senden und Empfangen von komprimierten digitalen Datensignalen, die ein Zeilenbild- bzw. -rahmenformat haben, betreibbar ist; und eine Mehrpunktsteuereinheit (MCU, 10) zum Ermöglichen, daß audiovisuelle Terminals in einer Konferenz miteinander kommunizieren, umfassend: (a) einen Netzwerkschnittstellenbus (34) zum Transportieren von komprimierten digitalen Datensignalen, die ein internes MCU-Bild- bzw. -Rahmenformat haben; (b) wenigstens eine Netzwerkschnittstelleneinheit (20), die an wenigstens ein jeweiliges audiovisuelles Terminal und an den Netzwerkschnittstellenbus (34) angekoppelt ist, zum Umformatieren von komprimierten digitalen Datensignalen in dem Zeilenbild- bzw. -Rahmenformat zu dem internen MCU-Bild- bzw. -Rahmenformat, zum Multiplexen auf den Netzwerkschnittstellenbus (34) und zum Umformatieren von komprimierten digitalen Datensignalen in dem internen MCU-Bild- bzw. -Rahmenformat zu dem Zeilenbild- bzw. -rahmenformat für das Übertragen bzw. Senden zu dem jeweiligen audiovisuellen Terminal; (c) einen Zwischenprozessorbus (36), der Zeitkanäle bzw. -schlitze zum Transportieren von komprimierten digitalen Videosignalen und komprimierten digitalen Audiosignalen hat; (d) wenigstens eine Brückenverarbeitungseinheit (22), die an den Netzwerkschnittstellenbus (34) und an den Zwischenprozessorbus (36) angekoppelt ist, und komprimierte digitale Datensignale von dem Netzwerkschnittstellenbus demultiplext, wobei die wenigstens eine Brückenverarbeitungseinheit digitale Signalverarbeitungsabteilungen (40, 42) aufweist, wobei jede Abteilung einem jeweiligen audiovisuellen Terminal, das an der Konferenz teilnimmt, zuteilbar ist, wobei jede Abteilung komprimierte Audiosignale von ihrem jewei1ige Terminal decodiert und die decodierten Audiosignale in Zeitkanäle bzw. -schlitze auf dem Zwischenprozessorbus (36) platziert, wobei jede Abteilung komprimierte Videosignale von ihrem jeweiligen Terminal in Zeitkanälen bzw. -schlitzen auf dem Zwischenprozessorbus platziert, wobei jede Abteilung (40, 42) komprimierte Videosignale und wenigstens ein Audiosignal aus geeigneten Zeitkanälen bzw. -schlitzen auf dem Zwischenprozessorbus auswählt, wobei jede Abteilung die ausgewählten Audiosignale komprimiert, wobei die wenigstens eine Brückenverarbeitungseinheit (22) die ausgewählten komprimierten Audiosignale und Videosignale zum Platzieren auf dem Netzwerkschnittstellenbus (34) multiplext; und (e) eine Videoverarbeitungseinheit (26), wobei die Videoverarbeitungseinheit folgendes umfaßt: einen Pixel- bzw. Bildelementbus (82), der eine Mehrzahl von Zeitkanälen bzw. -schlitzen zum Transportieren von unkomprimierten digitalen Videosignalen hat; eine Pixel- bzw. Bildelementbussteuereinrichtung (84) zum Steuern des Zugangs zu dem Pixel- bzw. Bildelementbus (82); und eine Mehrzahl von Prozessoren (60), wobei jeder Prozessor an den Pixel- bzw. Bildelementbus (82) angekoppelt und wenigstens einem Zeitkanal bzw. -schlitz zugeordnet ist; wobei jeder Prozessor (60) einem jeweiligen audiovisuellen Terminal, das an der Konferenz teilnimmt, zuteilbar ist; wobei jeder Prozessor (60) folgendes umfaßt: Mittel, um von dem Zwischenprozessorbus (36) erste komprimierte digitale Videosignale von einem audiovisuellen Terminal, das dem Prozessor (60) zugeteilt ist, zu empfangen; Mittel zum Decodieren (102) der ersten komprimierten digitalen Videosignale zu ersten unkomprimierten digitalen Videosignalen; Mittel zum Skalieren bzw. maßstäblichen Ändern bzw. Normieren (104) der ersten unkomprimierten digitalen Videosignale auf eine wünschenswerte Auflösung; Mittel zum Einführen der skalierten bzw. maßstäblich geänderten bzw. normierten ersten unkomprimierten digitalen Videosignale in den wenigstens einen zugeordneten Zeitkanal bzw. -schlitz auf dem Pixel- bzw. Bildelementbus (82), wenn ein Ausgangssteuersignal von der Pixel- bzw. Bildelementbussteuereinrichtung (84) empfangen wird; Mittel zum Empfangen von zweiten unkomprimierten digitalen Videosignalen aus irgendeinem Zeitkanal bzw. -schlitz, der irgendeinem Prozessor (60) zugeordnet ist, wenn ein Eingangssteuersignal von der Pixel- bzw. Bildelementbussteuereinrichtung (84) empfangen wird; Mittel zum fakultativen Skalieren bzw. maßstäblichen Ändern bzw. Normieren (108) der zweiten unkomprimierten digitalen Videosignale auf eine wünschenswerte Auflösung; Mittel zum Codieren (106) der zweiten unkomprimierten digitalen Videosignale zu zweiten komprimierten digitalen Videosignalen; und Mittel, um zu dem Zwischenprozessorbus (36) die zweiten komprimierten digitalen Videosignale zu dem audiovisuellen Terminal, das dem Prozessor (60) zugeteilt ist, zu übertragen bzw. zu senden.
Einrichtung zum Wiederverwenden von Bewegungsverlagerungs- bzw. -verschiebungsvektoren, die innerhalb von komprimierten Videosignalen lokalisiert sind, in einer Mehrpunktsteuereinheit, durch welche eine Mehrzahl von audiovisuellen Terminals, die zum Senden und Empfangen der komprimierten Videosignale betreibbar sind, miteinander verkehren, umfassend: einen Decodierer (400) zum Decodieren der komprimierten Videosignale von jeweiligen Terminals zu unkomprimierten Videosignalen auf einem Pixel- bzw. Bildelementgebiet; einen Zeitmultiplexbus (82) zum Empfangen der unkomprimierten Videosignale in Zeitkanälen bzw. -schlitzen, die jeweiligen Terminals zugeordnet sind; Selektor- bzw. Wählmittel zum Auswählen von unkomprimierten Videosignalen aus einem oder mehreren Zeitkanälen bzw. -schlitzen des Zeitmultiplexbusses; und einen Codierer (410) zum Codieren der ausgewählten unkomprimierten Videosignale für die Übertragung bzw. das Senden zu jeweiligen Terminals, wobei der Codierer Bewegungsverlagerungs- bzw. -verschiebungsvektoren, die den komprimierten Videosignalen für eine Bewegungsabschätzung zugeordnet sind, von dem Decodierer (400) empfängt.
Einrichtung nach Anspruch 19, weiter umfassend einen Skalierer bzw. Normierer (420) zum Skalieren bzw. maßstäblichen Ändern bzw. Normieren der Bewegungsverlagerungs- bzw. -verschiebungsvektoren vor dem Codieren.
Einrichtung nach Anspruch 19, worin die Bewegungsverlagerungs- bzw. -verschiebungsvektoren direkt durch den Codierer (410) benutzt werden.
Einrichtung nach Anspruch 19, worin die Bewegungsverlagerungs- bzw. -verschiebungsvektoren Startparameter für eine weitere Bewegungsabschätzung sind.