DE60025128T2

DE60025128T2 - Busschnittstelle für IEEE 1394

Info

Publication number: DE60025128T2
Application number: DE60025128T
Authority: DE
Inventors: Junji Neyagawa-shi Yoshida; Chiyoko Suita-shi Matsumi; Tatsuro Osaka-shi Juri; Masazumi Osaka-shi Yamada
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Corp
Priority date: 1999-10-21
Filing date: 2000-10-20
Publication date: 2006-06-29
Anticipated expiration: 2020-10-21
Also published as: CN1318833A; DE60025128D1; US6937599B1; EP1094637A3; EP1094637A2; KR20010060188A; CN1290025C; EP1094637B1

Description

ALLGEMEINER STAND DER TECHNIK
Gebiet der Erfindung
Die vorliegende Erfindung betrifft Daten einer Datenquelle, die Paketdaten überträgt, eine Vorrichtung und ein Verfahren zum Verarbeiten von Streamdaten, die in einer Aufzeichnungs-/Regenerierungsvorrichtung aufgezeichnet werden sollen, wobei die Streamdaten so ausgelegt werden, dass sie wie eine Datei aussehen, und ein Empfangsverfahren in einer Datensenke auf einem IEEE-1394-Bus.
Stand der Technik
Mit der Verbesserung der LSI-Technologie werden Netzwerke entwickelt, in denen Video-Informationen und Audio-Informationen digitalisiert und gesendet werden. Da Videosignale und Audiosignale in Echtzeit regeneriert werden sollen, sind Netzwerke erforderlich, die eine Echtzeit-Übertragung ermöglichen.
Als ein Netzwerk, das für eine derartige Echtzeit-Übertragung geeignet ist, wird ein als IEEE 1394 bezeichnetes Netzwerk vorgeschlagen. IEEE 1394 ist ein serielles Hochgeschwindigkeits-Bussystem und ist mit synchroner Übertragung kompatibel, wodurch eine Echtzeit-Übertragung von Daten ermöglicht wird.
Derzeit wird IEEE 1394 als eine externe Schnittstelle in digitalen Videorecordern (im Folgenden als DVs bezeichnet) für den privaten Gebrauch sowie vielen digitalen Audio-/Video-Vorrichtungen (im Folgenden als AV-Vorrichtungen bezeichnet) installiert. Hinsichtlich der DVs kann der Betrieb eines DV beispielsweise von einer externen Vorrichtung gesteuert werden, und Daten können zwischen der externen Vorrichtung und dem DV unter Verwendung des IEEE 1394 übertragen werden.
Andererseits gelangt IEEE 1394 auch im Arbeitsplatzrechner (im Folgenden als PC bezeichnet) zu weit verbreiteter Verwendung auf dem Gebiet der PCs auf Grund der Tatsache, dass IEEE 1394 formal für Windows 98 von Microsoft, das seit 1999 praktisch ein Standard-Betriebssystem ist, und andere Betriebssysteme unterstützt worden ist. Des Weiteren wurde eine Zusammenführung von diesen PCs und digitalen Audio-/Videovorrichtungen mit DVs verfolgt.
Zunächst wird als ein erster bisheriger Stand der Technik unter Bezugnahme auf 1 bis 7, 10 und 11 eine Datenquelle beschrieben, die Daten vom PC zum DV sendet.
1 ist ein Beispiel der Datenquelle. In 1 ist 101 ein Datenumwandlungsabschnitt, 102 ist ein Datenpuffer, 103 ist eine Deskriptorliste, 104 ist ein IEEE-1394-Treiber, 105 ist eine IEEE-1394-Schnittstelle, 106 ist ein IEEE-1394-Bus, 107 ist ein FIFO, 108 sind Eingabedaten, 109 ist ein CIP (Common Isochronous Packet), welches zum Beispiel IEC 61883 entspricht, 110 ist ein Deskriptor, 111 ist eine Adresse auf der Deskriptorliste 103, die den Deskriptor 110 speichert, 112 sind Sendebeginn-Befehle, 113 ist eine Sendeende-Anzeige und 114 ist ein isochrones Paket.
2 ist ein Beispiel der Konfiguration der CIP-Daten 109 zum Übertragen von Daten. In 2 sind 201 Paketdaten und 202 ist ein CIP-Header.
3 ist ein Beispiel der Konfiguration der CIP-Daten 109 zum Übertragen von leeren Daten.
4 ist ein Beispiel der Konfiguration des isochronen Pakets. In 4 ist 401 ein isochroner Header, 402 ist eine Header-CRC und 403 ist eine Daten-CRC.
5 ist ein Beispiel der Konfiguration des Datenpuffers 102. In 5 sind 501a, 501b, 501c und 501d Rahmenpufferspeicher, und 502a, 502b, 502c und 502d sind Flags Nicht gesendet. Der Datenpuffer 102 wird hier durch vier Rahmenpufferspeicher konfiguriert.
6 ist ein Beispiel der Konfiguration des Deskriptors 110.
7 ist ein Beispiel der Konfiguration der Deskriptorliste 103. In der Deskriptorliste 103 können vier Deskriptoren gespeichert werden, genauso viele wie die Anzahl der Rahmenpufferspeicher.
10 und 11 sind ein Beispiel der Konfiguration des FIFO 107. In 10 und 11 wurden die Adressen des Deskriptors 110, die sich in der niedrigeren Hierarchie befinden, später im FIFO 107 gespeichert. Jedoch sind in den oben beschriebenen 1 bis 7, 10 und 11 die Eingabedaten 108 DV-Daten, die durch eine Vielzahl von Paketdaten 202 konfiguriert sind. Auch ein Flag Nicht gesendet 502a, ein Flag Nicht gesendet 502b, ein Flag Nicht gesendet 502c und ein Flag Nicht gesendet 502d befinden sich in einem Zustand "Bereits gesendet" oder "Nicht gesendet", und der ursprüngliche Zustand ist "Bereits gesendet".
Abläufe von Datenquellen gemäß dem bisherigen Stand der Technik mit einer Konfiguration wie oben beschrieben werden im Folgenden erläutert.
Nach dem Empfang der Eingangsdaten 108 ruft der Datenumwandlungsabschnitt 101 daraus Paketdaten 201 ab, fügt im Anschluss daran den CIP-Header 202 an und speichert sie im Datenpuffer 102 als die CIP-Daten 109, wie in 2 gezeigt werden. Zu diesem Zeitpunkt werden die CIP-Daten 109 von vornherein in dem Rahmenpufferspeicher 501a gespeichert.
Danach, wenn eine vorgegebene Anzahl von CIPs 109, beispielsweise vierzehn CIPs 109 in dem Rahmenpufferspeicher 501a gespeichert sind, erstellt der Datenumwandlungsabschnitt 101 den Deskriptor 110a, in dem das Verfahren zum Senden der im Rahmenpufferspeicher 501a gespeicherten CIPS 109 beschrieben wird, und speichert ihn in der Deskriptorliste 103, wie in 6 gezeigt. Zu diesem Zeitpunkt werden die in der Deskriptorliste 103 gespeicherten Adressen 111a des Deskriptors 110a zusammen in dem FIFO 107 gespeichert, und zur gleichen Zeit wird das Sende-Flag 502a, das zum Rahmenpufferspeicher 501a gehört, auf "Nicht gesendet" gesetzt.
Hier, wie in 6 gezeigt, werden "die Adressen des Rahmenpufferspeichers 501a", "die Länge der CIP-Daten 109", "die Anzahl von CIPS 109, die in dem Rahmenpuffer speicher 501a gespeichert sind", "Deskriptor-Kennung" und "frühere Informationen" in dem Deskriptor 110a gespeichert. Die "Deskriptor-Kennung" enthält Informationen zum Unterscheiden des Deskriptors 110. Beispielsweise enthält die "Deskriptor-Kennung" des Deskriptors 110a "A", und die "Deskriptor-Kennung" des Deskriptors 110b enthält "B".
Von da an wechselt der Datenumwandlungsabschnitt 101 zyklisch den Rahmenpufferspeicher für die Speicherung in der Reihenfolge von Rahmenpufferspeicher 501b → Rahmenpufferspeicher 501c → Rahmenpufferspeicher 501d → Rahmenpufferspeicher 501a, wobei eine vorgegebene Menge von CIPs 109 in jedem Rahmenpufferspeicher gespeichert wird. Zu diesem Zeitpunkt, wenn das Flag Nicht gesendet 502a des Rahmenpufferspeichers, in dem die CIP-Daten 109 als nächstes gespeichert werden sollen, beispielsweise im Rahmenpufferspeicher 501a, "Nicht gesendet" lautet, führt der Datenumwandlungsabschnitt 101 keine Abläufe für die Speicherung durch, sondern wartet, bis das Flag Nicht gesendet zu "Bereits gesendet" wird.
Des Weiteren, nachdem der Datenumwandlungsabschnitt 101 eine vorgegebene Anzahl von CIPS 109 in dem Rahmenpufferspeicher 501d gespeichert hat, sendet er die Sendebeginn-Befehle 112 an den IEEE-1394-Treiber 104, wenn die Sendebeginn-Befehle 112 noch nicht an den IEEE-1394-Treiber 104 gesendet worden sind. Zu diesem Zeitpunkt wird die Adresse des Deskriptors 110 im FIFO 107 gespeichert, wie in 10 gezeigt.
Als Nächstes, nach dem Empfang der Sendebeginn-Befehle 112 von dem Datenumwandlungsabschnitt 101, verweist der IEEE-1394-Treiber 104 auf die Adressen des Deskriptors 110a, die zu Beginn in den im FIFO 107 gespeicherten Adressen des Deskriptors 110 gespeichert worden sind, und erfasst den Deskriptor 110a aus der Deskriptorliste 103. Anschließend werden die CIPs 109 entsprechend dem in dem Deskriptor 110a beschriebenen Inhalt nacheinander aus dem Rahmenpufferspeicher 501a abgerufen, und das in 4 gezeigte isochrone Paket 114 wird erstellt.
Des Weiteren gibt der IEEE-1394-Treiber 104 das erstellte isochrone Paket 114 an den IEEE-1394-Bus über die IEEE-1394-Schnittstelle 105 aus.
Als Nächstes, nach dem Abrufen der CIPs 109 in Übereinstimmung mit "der Anzahl der CIPs 109", die in dem Deskriptor 110 des Rahmenpufferspeichers 501a beschrieben wird, sendet der IEEE-1394-Treiber 104 die Sendeende-Anzeige 113 an den Datenumwandlungsabschnitt 101 zusammen mit (in diesem Fall) einem "A", das die "Deskriptor-Kennung" des Deskriptors 110a ist.
Wenn der oben beschriebene Prozess beendet ist, dann fragt der IEEE-1394-Treiber 104 den FIFO 107 ab, verweist auf die Adressen des Deskriptors 110b, auf die er sich noch nicht bezogen hat, und verarbeitet den Rahmenpufferspeicher 501b entsprechend dem Deskriptor 110b wie in dem Fall des Rahmenpufferspeichers 501a.
Nach dem Empfang der Sendeende-Anzeige 113 vom IEEE-1394-Treiber 104 ruft der Datenumwandlungsabschnitt 101 aus dem FIFO die Adressen des Deskriptors 110 ab, der sich auf dessen niedrigster Hierarchieschicht befindet, und verwirft sie. Zum Beispiel werden im Fall von 10 die Adressen des Deskriptors 110a abgerufen und verworfen, wie in 11 gezeigt. Zur gleichen Zeit, weil "A", das den Deskriptor 110a als "Deskriptor-Kennung" darstellt, zusammen mit der gesendeten Sendeende-Anzeige 113 zu diesem Zeitpunkt an den Datenumwandlungsabschnitt 101 gesendet wird, schreibt der Datenumwandlungsabschnitt 101 das Flag Nicht gesendet 502a, das dem Rahmenpufferspeicher 501a entspricht, auf "Bereits gesendet" um.
Von da an werden Daten von dem PC zu dem DV gesendet, indem diese Prozesse wiederholt werden.
Wenn des Weiteren in einer Reihe der oben beschriebenen Abläufe ein Unterschied zwischen der Übertragungsgeschwindigkeit der Eingabedaten 108 und der Übertragungsgeschwindigkeit des IEEE-1394-Bus 106 besteht, sollten zeitweise leere Daten gesendet werden, um die Geschwindigkeit anzupassen. Zu diesem Zeitpunkt erstellt der Datenumwandlungsabschnitt 101 wie erforderlich die CIP-Daten 109, die nur durch den CIP-Header 202 konfiguriert werden, wie in 3 gezeigt. In diesem Fall, falls unmittelbar vorhergehende CIP-Daten 109 in dem Rahmenpufferspeicher 501a gespeichert sind, selbst wenn vierzehn CIPs 109 nicht in dem Rahmenpufferspeicher 501a gespeichert sind, wird der Deskriptor 110a für den Rahmenpufferspeicher 501a erstellt und in der Deskriptorliste 103 gespeichert, und das Flag Gesendet 501a wird, wie oben be schrieben, zuerst auf "Nicht gesendet" gesetzt. Dann werden die CIP-Daten 109 für leere Daten in den Rahmenpufferspeicher 501b gespeichert, und der Deskriptor 110b, der das Verfahren zum Senden von CIPs 109 beschreibt, die zusammen in dem Rahmenpufferspeicher 501b gespeichert sind, wird erstellt und in der Deskriptorliste 103 gespeichert. Die folgenden Abläufe werden ausgeführt wie im Fall des Sendens von CIPs zum Übertragen von DV-Daten.
Hier, im Fall von Arbeitsplatzrechnern, (die kurz als PC bezeichnet werden), werden Streamdaten, wie beispielsweise Video- und Audiodaten, herkömmlicherweise als Dateien behandelt. Wenn jedoch Video- und Audiodaten tatsächlich aufgezeichnet werden, werden normalerweise Vorrichtungen wie beispielsweise Videorecorder verwendet, um sie als Streamdaten aufzuzeichnen. Zum Verarbeiten/Bearbeiten der Video- und Audiodaten, die mit dem Videorecorder aufgezeichnet wurden, können spezialisierte Bearbeitungseinrichtungen verwendet werden, doch sind diese teuer, und es ist schwierig, Einrichtungen mit anderen Funktionen als den ursprünglich vorgesehenen zu den Bearbeitungseinrichtungen hinzuzufügen. Es ist daher effektiv, Daten wie beispielsweise Video- und Audiodaten unter Verwendung der PC-Software mit einem PC zu verarbeiten/bearbeiten.
Als Nächstes werden als ein zweiter bisheriger Stand der Technik Verfahren zum Ausführen einer Bearbeitung mit einem PC unter Bezugnahme auf 17 beschrieben.
Obwohl ein PC als Beispiel angegeben wird, können auch andere Einrichtungen als ein PC auf ähnliche Weise verwendet werden. In 17 ist 1 ein PC und 2 ist eine Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung. Obwohl ein DV (digital aufzeichnender Videorecorder) als ein Beispiel für die Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 angegeben ist, kann der Videorecorder analog oder digital aufzeichnen, und die Schnittstelle kann analogen oder digitalen Formaten entsprechen.
Der interne Abschnitt des PC 1 wird durch Hardware, Software im Kernmodus, die ein OS (Operating System/Betriebssystem) ist, und Software im Benutzermodus, die eine Anwendung ist, konfiguriert. 3 ist eine Empfangs- und Datenformatumwandlungs-Software, 4 ist eine Software, die Audio-/Videodaten bearbeitet, (Bearbeitungs-Software kann zum Beispiel integriert sein), 5 ist eine Datenformatrückwandlungs- und Übertra gungs-Software. 6 ist eine Software zum Verwalten von Dateien, und 7 ist eine Aufzeichnungs-/Regenerierungsvorrichtung, die Daten aufzeichnet/erzeugt, die der PC 1 bearbeitet (beispielsweise HDD).
Zuerst werden Daten mit der Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung regeneriert, und der benötigte Teil der Daten, die an den PC 1 ausgegeben werden, wird im PC 1 unter Verwendung der Empfangs- und Datenformatumwandlungs-Software 3, die im PC 1 vorhanden ist, erfasst. Tatsächlich wandelt die Empfangs- und Datenformatumwandlungs-Software 3 die Daten in ein Dateiformat um und schreibt sie auf die Festplatte (HDD) 7. Tatsächlich weist die Empfangs- und Datenformatumwandlungs-Software 3 die Software 6, welche die Datei verwaltet, an, die Datei A zu schreiben, wodurch die durch die Empfangs- und Datenformatumwandlungs-Software 3 umgewandelte Datei auf die Festplatte 7 geschrieben wird. Das Schreiben wird ausgeführt durch:

1) Befehle zum Öffnen der Datei – sie geben den Namen der Datei an.
2) Schreibbefehle an die geöffnete Datei – sie bezeichnen die Schreibbeginn-Position, die Schreibdatengröße und die Schreibdaten.
3) Befehle zum Schließen der Datei

Danach weist die Software 4, welche die Audio-/Videodaten bearbeitet, die Software 6, welche die Datei verwaltet, an, die Datei A zu lesen und führt die notwendigen Prozesse basierend auf den von der Festplatte 7 gelesenen Daten aus. Normalerweise werden, um das Ergebnis des Prozesses als die neue Datei B auf die Festplatte 7 zu schreiben, Befehle zum Schreiben der Datei B erteilt. Des Weiteren wird das Lesen der Datei A ausgeführt durch:

1) Befehle zum Öffnen der Datei – sie geben den Namen der Datei an.
2) Lesebefehle an die geöffnete Datei – sie bezeichnen die Lesebeginn-Position, die Lesedatengröße und die Lesedaten.
3) Befehle zum Schließen der Datei

Die Datei B, die nach der Verarbeitung durch die Software 4, die Audio-/Videodaten bearbeitet, generiert wird, wird durch die Datenformatrückwandlungs- und Sende-Software 5 in die Streamdaten umgewandelt und wird gleichzeitig in der Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 aufgezeichnet.
Das Dateiformat, das in der Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 aufgezeichnet werden kann, umfasst zum Beispiel ein Datenformat, das in IEC 61834 definiert wird, in dem Video- und Audiodaten, die von dem IEEE-1394-Endgerät des DV (digitale Videokassette) eingegeben/ausgegeben werden, weiter in Echtzeit laufen. (Sofern keine Befehle an die Vorrichtung gesendet werden, beginnt die Regenerierung von Daten in etwa, wenn ein Regenerierungsknopf gedrückt wird, und die Regenerierung von Daten stoppt in etwa, wenn ein Stoppkopf gedrückt wird. Die Aufzeichnung von Daten beginnt in etwa, wenn ein Aufzeichnungsknopf gedrückt wird, und das Aufzeichnen von Daten wird gestoppt, wenn ein Stoppknopf gedrückt wird. Wenn es sich um eine Datei handelt, werden der Anfang und das Ende der Datei genau definiert.)
Dateiformate in Bezug auf Video- und Audiodaten, die gemeinsam verwendet werden, weisen ein Dateiformat auf, das als avi-Format bezeichnet wird. Dieses stellt Informationen über Video- und Audiodaten, (wie beispielsweise Bildfolgefrequenz von Videodaten, Anzahl von Datenübertragungsblöcken, Bildschirmgröße, Art der Videodatenverdichtung, Abtastfrequenz von Audiodaten, Datenübertragungsgeschwindigkeit von Audiodaten, Abtastanzahl von Audiodaten, Anzahl von Audiokanälen) an den Anfang der Datei als Header-Informationen, ordnet dann Audiodaten und Videodaten für jede als Block (Chunk) bezeichnete Einheit an und stellt Informationen, die angeben, wo sich jeder Block in der Daten befindet, (für jeden Block wird ein Indexeintrag (IndexEntry) generiert), als Index-Informationen an das Ende der Datei.
IEC 61883 ist jetzt als ein Protokoll für die Übertragung von Daten von AV-Vorrichtungen, wie beispielsweise DVs, und zum Durchführen der Vorrichtungsteuerung unter Verwendung des oben beschriebenen IEEE 1394 standardisiert.
Als Nächstes wird als ein dritter bisheriger Stand der Technik das Verfahren zum Empfangen von Daten, die vom DV mit dem PC ausgegeben werden, unter Bezugnahme auf 2, 4, 18 bis 24 und 27 bis 30 beschrieben.
18 zeigt den PC und DV, die an den IEEE-1394-Bus angeschlossen sind. In 18 ist 701 ein PC, 702 ist ein DV, 703 ist eine Anwendung, 704 ist ein Treiber für den DV, 705 ist ein IEEE-1394-Treiber, 706 ist eine IEEE-1394-Schnittstelle, 707 ist ein Daten ausgebender Abschnitt, 708 ist ein oPCR[0], 709 ist eine IEEE-1394-Schnittstelle, 710 ist ein IEEE-1394-Bus, 711 sind DV-Daten, 109 ist ein CIP, 714 sind Ablaufbefehle, 715 ist eine Anforderung an den IEEE-1394-Treiber 705, 716 ist eine Antwort auf die Anforderung 715, und 717 sind Registerdaten.
2 zeigt ein Beispiel einer Konfiguration der CIP-Daten 109. In 2 sind 201 Paketdaten und 202 ist ein CIP-Header. In dem CIP-Header 202 werden ein SID-(source node ID/Ursprungsknoten-Kennung) Feld, das die Knotennummer der Daten ausgebenden Vorrichtung angibt, und Informationen, die anzeigen, welche Daten übertragen werden, beschrieben. Die Vorrichtung, die Daten empfängt, kann bestimmen, wer die Sendevorrichtung ist, indem auf das SID-Feld Bezug genommen wird, und wird verwendet, wenn die Verwaltung von Verbindungen für Rundsende-Übertragungen und Punkt-zu-Punkt-Übertragungen, die später beschrieben werden, durchgeführt wird.
4 ist ein Beispiel einer Konfiguration des isochronen Pakets. In 4 ist 401 ein isochroner Header, 402 ist eine Header-CRC und 403 ist eine Daten-CRC. In dem isochronen Header 401 wird der Kanal zum Übertragen von Daten beschrieben.
19 zeigt eine Konfiguration des oPCR. Wie aus 19 ersichtlich wird, werden in dem oPCR ein Rundsende-Verbindungszähler, ein Punkt-zu-Punkt-Verbindungszähler, eine Kanalnummer und Ähnliches beschrieben.
20 zeigt eine Konfiguration des iPCR. Wie aus 20 ersichtlich wird, werden wie im oPCR ein Rundsende-Verbindungszähler, ein Punkt-zu-Punkt-Verbindungszähler, eine Kanalnummer und Ähnliches beschrieben.
21 ist eine konzeptionelle grafische Darstellung, welche die Rundsende-Übertragung in IEC 61883 veranschaulicht. In 21 ist 601 ein Empfänger und 602 ist ein Sender.
22 ist eine konzeptionelle grafische Darstellung, welche die Punkt-zu-Punkt-Übertragung in IEC 61883 veranschaulicht.
23 ist eine konzeptionelle grafische Darstellung, welche den Zustand, dass die Rundsende-Übertragung und die Punkt-zu-Punkt-Übertragung in IEC 61882 gleichzeitig ausgeführt werden, veranschaulicht.
24 zeigt ein Beispiel für die Werte des oPCR[0] des Senders 602 und des iPCR[0] des Empfängers 601. Das heißt, in 24 wird ein Beispiel für die Werte des oPCR[0] des Senders 602 und des iPCR[0] des Empfängers 601 für ursprüngliche Zustände, Zustände von 21 (Zustände zum Durchführen von Rundsende-Übertragung), Zustände von 22 (Zustände zum Durchführen von Punkt-zu-Punkt-Übertragung) und Zustände von 23 (Zustände zum Durchführen von Rundsende-Übertragung und Punkt-zu-Punkt-Übertragung zur gleichen Zeit) gezeigt. Dies wird später beschrieben.
27 bis 30 sind Übergangstabellen, die zeigen, wie die Werte in dem oPCR[0] neu geschrieben werden. Das bcc steht für den Rundsende-Verbindungszähler, und das p2p steht für den Punkt-zu-Punkt-Verbindungszähler.
Zunächst wird das Konzept der Rundsende-Übertragung und der Punkt-zu-Punkt-Übertragung in IEC 61883 erläutert.
In der Rundsende-Übertragung, wie in 21 gezeigt, gibt der Sender 602 nur Daten für zum Beispiel eine Kanalnummer 63 aus (hierin im Folgenden als ch63 bezeichnet) und zwar ohne Berücksichtigung, welche Vorrichtung die ausgegebenen Daten emp fängt. Andererseits nimmt der Empfänger 601 nur die an den ch63 übertragenen Daten auf und muss nicht berücksichtigen, welche Vorrichtung die Daten ausgegeben hat Im Gegensatz dazu wird bei der Punkt-zu-Punkt-Übertragung durch eine klare Definition der sendenden Vorrichtung und der empfangenden Vorrichtung eine Eins-zu-Eins-Datenübertragung zwischen dem Sender 602 und dem Empfänger 601 durchgeführt, wie in 22 gezeigt. Je nach Erfordernis führt die sendende Vorrichtung zum Beispiel eine Vielzahl von Punkt-zu-Punkt-Übertragungen gleichzeitig aus, wodurch eine Eins-zu-Viele-Übertragung ermöglicht wird.
Des Weiteren können die Rundsende-Übertragung und die Punkt-zu-Punkt-Übertragung zur gleichen Zeit durchgeführt werden. Wie beispielsweise in 23 gezeigt, kann der Sender 602 Daten an den ch63 durch Rundsende-Übertragung ausgeben und zur gleichen Zeit eine Eins-zu-Eins-Übertragung zum Empfänger 601 durch Punkt-zu-Punkt-Übertragung ausführen.
Als Nächstes wird erläutert, wie die Rundsendeverbindung und die Punkt-zu-Punkt-Verbindung in IEC 61883 durchgeführt werden.
Der IEC 61883 entsprechende Sender 602 weist das oPCR (output plug control register /Ausgabesteuerregister) als ein Register zum Steuern der Ausgabe auf. In ähnlicher Weise weist der Empfänger 601, der IEC 61993 entspricht, das iPCR (input plug control register/Eingabesteuerregister) als ein Register zum Steuern der Eingabe auf. Die Konfiguration des oPCR wird in 19 dargestellt, und die Konfiguration des iPCR wird in 20 dargestellt. Es kann eine Vielzahl von oPCRs und iPCRs vorhanden sein, und das N-te Register wird als oPCR[N] oder iPCR[N] ausgedrückt. In diesem Fall wird angenommen, dass das nullte Register, das oPCR[0] des Senders 602 und das iPCR[0] des Empfängers 601 verwendet wird.
Zunächst sind für den ursprünglichen Zustand, und zwar für den Zustand, dass keine Verbindung hergestellt ist, wie in den Spalten für den ursprünglichen Zustand von 24 gezeigt, sowohl der bcc als auch der p2p des oPCR[0] gleich 0, und in ähnlicher Weise sind sowohl der bcc als auch der p2p des iPCR[0] gleich 0. Die Kanalnummer enthält 63 als ein Beispiel für den ursprünglichen Wert.
In dem Fall, in dem der Sender 602 eins Ausgabe an einen Kanal durch Rundsende-Übertragung durchführt, wird dem bcc des oPCR[0] 1 zugewiesen. In ähnlicher Weise wird in dem Fall, in dem der Empfänger 601 eine Eingabe durch Rundsende-Übertragung durchführt, dem bcc des iPCR[0] 1 zugewiesen. Das heißt, wenn die Rundsende-Übertragung durchgeführt wird wie in 21 gezeigt, stellt sich jeder Wert für bcc, p2p und Kanalnummer des oPCR[0] des Senders 602 und des iPCR[0] des Empfängers 601 wie in der Spalte von 21 gezeigt in 24 dar. Natürlich müssen die Kanalnummern dieselben sein, damit der Empfänger 601 die Daten empfängt, die der Sender 602 ausgibt. In dem Fall, in dem der Sender 602 die Ausgabe durch Rundsende-Übertragung beendet, wird der bcc des oPCR[0] auf 0 zurückgesetzt. In ähnlicher Weise wird in dem Fall, in dem der Empfänger 601 die Eingabe durch Rundsende-Übertragung beendet, der bcc des iPCR[0] auf 0 zurückgesetzt.
Wenn der Sender 602 und der Empfänger 601 eine Übertragung in einer Punkt-zu-Punkt-Weise durchführen, fügt jede der Vorrichtungen (es kann der Sender 602 oder der Empfänger 601 oder eine dritte Vorrichtung sein) 1 zu dem p2p des oPCR[0] des Senders 602 hinzu und fügt gleichzeitig auch 1 zu dem p2p des iPCR[0] des Empfängers 601 hinzu. Das heißt, wenn eine Punkt-zu-Punkt-Übertragung, wie in 22 gezeigt, durchgeführt wird, stellt sich jeder Wert für bcc, p2p, Kanalnummer des oPCR[0] des Senders 602 und des iPCR[0] des Empfängers 601 wie in der Spalte von 21 gezeigt in 24 dar.
Hier wird die Übertragung so durchgeführt, dass beide Kanalnummern des iPCR[0] des Empfängers 601 und des oPCR[0] des Senders 602 63 lauten, doch kann die Vorrichtung, welche die Punkt-zu-Punkt-Übertragung aufbaut, beide Kanalnummern des iPCR[0] des Empfängers 601 und des oPCR[0] des Senders 602 auf irgendeine von 0 bis 62 ändern, um eine Punkt-zu-Punkt-Übertragung mit einem anderen Kanal durchzuführen, falls erforderlich.
Wenn die Punkt-zu-Punkt-Übertragung zwischen dem Sender 602 und dem Empfänger 601 beendet ist, subtrahiert die Vorrichtung, welche die Punkt-zu-Punkt-Verbindung aufbaut, 1 von dem p2p des oPCR[0] des Senders 602, und subtrahiert gleichzeitig auch 1 von dem p2p des iPCR[0] des Empfängers 601.
In dem Fall, in dem eine Rundsende-Übertragung und eine Punkt-zu-Punkt-Übertragung zur gleichen Zeit durchgeführt werden, können die oben beschriebenen Abläufe in einer ähnlichen Weise ausgeführt werden, wenn jede Verbindung aufgebaut ist. Wenn zum Beispiel der Sender 602 eine Ausgabe an den ch63 in einer Rundsende-Weise durchführt und gleichzeitig Daten an den Empfänger 601 in einer Punkt-zu-Punkt-Weise überträgt, wie in 23 gezeigt, sind die Werte des bcc und p2p des oPCR[0] des Senders 602 beide 1, wie in der Spalte von 23 in 24 gezeigt. Zu diesem Zeitpunkt beträgt der Wert des p2p des iPCR[0] des Empfängers 601 1. Da der Empfänger 601 jedoch einen Empfang nicht unbedingt jeweils in einer Rundsende-Weise durchführt, ist es die Aufgabe des Empfängers 601, zu bestimmen, ob der bcc des iPCR[0] gleich 1 zu setzen ist oder nicht.
Im Übrigen, gleichgültig, ob es sich um Rundsende-Übertragung oder Punkt-zu-Punkt-Übertragung handelt, sollten zwei Ressourcen, d.h. Kanal und Bandbreite, in dem Fall zugewiesen werden, in dem die Übertragung auf dem IEEE-1394-Bus 710 durchgeführt wird. Im Fall von IEC 61883 weist die Vorrichtung, die zuerst irgendeine der Verbindungen in einem Kanal aufbaut, diese Ressourcen zu, und die Vorrichtung, welche die Verbindung als letzte trennt, muss diese Ressourcen freigeben.
Im Folgenden wird erläutert, wie Daten vom DV 702, der ein Sender ist, zum PC 701 übertragen werden.
Zunächst werden die Abläufe des DV 702 erläutert.
Nach dem Empfang von Regenerierungsbeginn-Befehlen weist der DV 702 dem bcc im oPRC[0] 708 1 zu. Der Daten ausgebende Abschnitt 707 beginnt, die DV-Daten 711 an die IEEE-1394-Schnittstelle 709 auszugeben. Die IEEE-1394-Schnittstelle 709 fügt den CIP-Header 202 zu den Paketdaten 201 hinzu, in welche die empfangenen DV-Daten 711 geteilt werden, um die CIP-Daten 109 zu erzeugen, wie in 2 gezeigt, und fügt des Weiteren den isochronen Header 401, die Header-CRC 402 und die Daten-CRC 403 hinzu, um über den IEEE-1394-Bus 710 das isochrone Paket zu erstellen und auszugeben, wie in 4 gezeigt. Der Kanal, der zu diesem Zeitpunkt ausgegeben wird, hängt von dem Wert ab, der in der Kanalnummer des oPRC[0] 708 eingetragen ist. In dem Fall, in dem p2p gleich 0 ist, das heißt, dass keine der Verbindungen direkt bevor der bcc auf 1 gesetzt wurde hergestellt worden ist, weist die IEEE-1394-Schnittstelle 709 den in der Kanalnummer eingetragenen Kanal und eine erforderliche Bandbreite zu, bevor mit der Ausgabe an den IEEE-1394-Bus 710 begonnen wird.
Nach dem Empfang der Regenerierungsstopp-Befehle setzt der DV 702 den bcc im oPRC[0] 708 wieder auf 0 zurück, der Daten ausgebende Abschnitt 707 stoppt die Ausgabe an die IEEE-1394-Schnittstelle 709, und die IEEE-1394-Schnittstelle 709 stoppt die Ausgabe an den IEEE-1394-Bus 710. Zu diesem Zeitpunkt, wenn der bcc und der p2p beide 0 sind, und keine der Verbindungen hergestellt ist, gibt die IEEE-1394-Schnittstelle 709 die Ressource des zugewiesenen Kanals und der zugewiesenen Bandbreite frei.
Als Nächstes werden die Abläufe des PC 701 beschrieben.
Nach dem Empfang der Empfangsbeginn-Befehle als Ablaufbefehle 714 von der Anwendung 703 sendet der Treiber 704 für den DV eine Anforderung, um den Wert des oPCR des DV 702 zu erhalten, als die Anforderung 715 an den IEEE-1394-Treiber 705. Der IEEE-1394-Treiber 705 fordert die IEEE-1394-Schnittstelle 709 auf, die Registerdaten 717 in dem oPCR[0] 708 über die IEEE-1394-Schnittstelle 706 zu senden. Nach dem Empfang einer Sendeanforderung ruft die IEEE-1394-Schnittstelle 709 die Registerdaten 717 aus dem oPCR[0] 708 ab und sendet dieselben an die IEEE-1394-Schnittstelle 706. Der IEEE-1394-Treiber 705 gibt die Registerdaten 717, die von der IEEE-1394-Schnittstelle 706 empfangen wurden, an den Treiber 704 für den DV als die Antwort 716 aus.
Der Treiber 704 für den DV prüft den Inhalt der Registerdaten 717, und wenn der bcc des oPRC[0] 708 gleich 1 ist, oder der p2p 1 oder größer ist, sendet er Befehle als die Anforderung 715, um die Daten, die erhalten wurden, indem der durch Hinzufügen von 1 zu dem Wert des p2p im oPRC[0] 708 erhaltene Wert zu dem p2p des oPRC[0] 708 zu dem IEEE-1394-Treiber 705 zugewiesen wird, als neue Registerdaten 717 in das oPCR[0] 708 zu schreiben. Nach dem Empfangen von Befehlen als die Anforderung 715, die Registerdaten 717 in das oPCR[0] 708 zu schreiben, fordert der IEEE-1394-Treiber 705 die IEEE-1394-Schnittstelle 709 auf, die Registerdaten 717 über die IEEE- 1394-Schnittstelle 706 neu in das oPCR[0] 708 zu schreiben. Nach dem Empfang der Schreibanforderung schreibt die IEEE-1394-Schnittstelle 709 die neuen Registerdaten 717 in das oPCR[0] 708, wenn die neuen Registerdaten 717 ein sinnvoller Wert sind.
Danach sendet der Treiber 704 für den DV an den IEEE-1394-Treiber 705 Befehle als die Anforderung 715, mit dem Empfangen von Daten von dem Wert zu beginnen, der durch die Kanalnummer in dem oPCR[0] 708 angegeben wird, zum Beispiel ch63. Nach dem Empfang der Empfangsbeginn-Befehle als der Anforderung 715 startet der IEEE-1394-Treiber 705 den Empfang des isochronen Pakets, das die Daten von dem ch63 auf dem IEEE-1394-Bus 710 sind, über die IEEE-1394-Schnittstelle 706. Der IEEE-1394-Treiber 705 ruft die CIP-Daten 109 aus dem empfangenen isochronen Paket ab und gibt die CIP-Daten 109 an den Treiber 704 für den DV aus. Der Treiber 704 für den DV ruft die Paketdaten 201 aus den CIP-Daten 109 ab, erstellt die DV-Daten 711 aus den Paketdaten 201 und gibt dieselben an die Anwendung 703 aus.
Der Treiber 704 für den DV prüft auch den Inhalt der Registerdaten 717, und wenn sowohl der bcc als auch der p2p des oPCR[0] 708 0 sind, sendet er Befehle als die Anforderung 715, um die Daten, die durch Zuweisen des Kanals, den andere Vorrichtungen in dem IEEE-1394-Bus 710 nicht verwenden, beispielsweise ch0, zu der Kanalnummer in dem oPCR[0] 708 und Zuweisen des durch Hinzufügen von 1 zu dem Wert des p2p im oPRC[0] 708 erhaltenen Werts zu dem p2p des oPRC[0] 708 zu dem IEEE-1394-Treiber 705 erhalten wurden, als neue Registerdaten 717 in das oPCR[0] 708 zu schreiben. Nach dem Empfangen von Befehlen als die Anforderung 715, die Registerdaten 717 in das oPCR[0] 708 zu schreiben, fordert der IEEE-1394-Treiber 705 die IEEE-1394-Schnittstelle 709 auf, die Registerdaten 717 über die IEEE-1394-Schnittstelle 706 neu in das oPCR[0] 708 zu schreiben. Nach dem Empfang der Schreibanforderung schreibt die IEEE-1394-Schnittstelle 709 die neuen Registerdaten 717 in das oPCR[0] 708, wenn die neuen Registerdaten 717 ein sinnvoller Wert sind. Zur gleichen Zeit weist der Treiber 704 für den DV den ch0 und eine erforderliche Bandbreite zu, die Ressourcen des IEEE-1394-Busses 710 sind, und sendet dann Befehle als die Anforderung 715, mit dem Empfangen von Daten von dem ch0 zu beginnen, an den IEEE-1394-Treiber 705. Nach dem Empfang der Empfangsbeginn-Befehle als der Anforderung 715 beginnt der IEEE-1394-Treiber 705 damit, das isochrone Paket, das Daten aus dem ch0 auf dem IEEE- 1394-Bus 710 sind, über die IEEE-1394-Schnittstelle 706 zu empfangen. In dem Fall, in dem der DV 702 die Daten nicht ausgegeben hat, wartet der IEEE-1394-Treiber 705, bis die Daten ausgegeben werden.
Folgende Abläufe sind denjenigen des Falls ähnlich, in dem der bcc des oPRC[0] 708 gleich 1 ist.
Andererseits sendet der Treiber 704 für den DV, nachdem er die Empfangsstopp-Befehle als die Ablaufbefehle 714 von der Anwendung 703 empfangen hat, Befehle als die Anforderung 715, das Empfangen von Daten von dem IEEE-1394-Bus 710 zu stoppen, an die IEEE-1394-Schnittstelle 706. Nach dem Empfang der Empfangsstopp-Befehle stoppt die IEEE-1394-Schnittstelle 706 den Empfang von Daten von dem IEEE-1394-Bus 710.
Als Nächstes, nach dem Empfang von Empfangsstopp-Befehlen als den Ablaufbefehlen 714 von der Anwendung 703, sendet der Treiber 704 für den DV als die Anforderung 715 eine Anforderung an den IEEE-1394-Treiber 705, den Wert des oPCR[0] 708 von dem DV 702 abzurufen. Der Treiber 704 für den DV sendet Befehle, um die Daten, die erhalten wurden, indem der durch Subtrahieren von 1 von dem Wert des p2p im oPRC[0] 708 erhaltene Wert von dem p2p des oPRC[0] 708 zu dem IEEE-1394-Treiber 705 zugewiesen wird, als neue Registerdaten 717 in das oPCR[0] 708 zu schreiben. Durch Abläufe, die denjenigen ähnlich sind, die oben beschrieben wurden, wird der Wert des oPCR[0] 708 des DV 702 geändert. Wenn der bcc des oPCR[0] 708 gleich 0 ist und der Treiber 704 für den DV die Ressource des IEEE-1304-Busses 710 früher zuweist, dann gibt der Treiber 704 für den DV die Ressource des IEEE-1394-Busses 719 zur gleichen Zeit frei. Zu diesem Zeitpunkt, sofern erforderlich, setzt der Treiber 704 für den DV den Wert der Kanalnummer des oPCR[0] 708 wieder auf den ursprünglichen Wert zurück.
Tabellen dazu, wer den Wert des oPCR[0] 708 des DV 702 und die Ressource des IEEE-1394-Busses 710 zuweist, und wer dieselben freigibt, sind als Beispiel in 27 bis 30 gezeigt.
Insgesamt wird von vier Abläufen ausgegangen, wobei berücksichtigt wird, welcher von Regenerierungsbeginn des DV 702 und Empfangsbeginn des PC 701 früher durchgeführt wird, und welcher von Regenerierungsstopp des DV 702 und Empfangsstopp des PC 701 früher durchgeführt wird.
27 zeigt den Fall, bei dem der Empfangsbeginn des PC 701 und der Regenerierungsstopp des DV 702 früher durchgeführt werden. Wenn der PC 701 mit dem Empfang beginnt, sind der bcc und p2p des oPRC[0] 708 beide 0, weil die Regenerierung des DV 702 noch nicht begonnen hat. Daher ändert der PC 701 die Kanalnummer des oPCR[0] 708 auf ch0 und den p2p auf 1 und weist die Ressource des IEEE-1394-Busses 710 zu. Wenn der DV mit der Regenerierung beginnt, ist die Ressource nicht zugewiesen, und der bcc wird auf 1 geändert, weil der p2p2 bereits 1 ist, das heißt, die Punkt-zu-Punkt-Verbindung bereits aufgebaut ist.
Wenn der DV 702 die Regenerierung stoppt, wird die Ressource nicht freigegeben, und der bcc wird wieder auf 0 gesetzt, weil der p2p immer noch 1 ist, das heißt, die Punkt-zu-Punkt-Verbindung aufgebaut ist.
Wenn der PV 701 den Empfang stoppt, setzt der PC 701 die Kanalnummer des oPCR[0] 708 wieder auf ch63 zurück und setzt gleichzeitig den p2p auf 0 zurück. Zu diesem Zeitpunkt, da der DV 702 nicht regeneriert wird, ist auch der bcc des oPCR[0] 708 0. Daher gibt der PC 701 die Ressource des IEEE-1394-Busses 710 frei.
28 zeigt den Fall, in dem der Empfangsbeginn des PC 701 und der Empfangsstopp des PV 701 früher liegen. Wenn der PC 701 mit dem Empfang beginnt, sind der bcc und der p2p des oPCR[0] 708 beide 0, weil die Regenerierung des DV 702 noch nicht begonnen hat. Daher ändert der PC 701 die Kanalnummer des oPCR[0] 708 auf ch0 und den p2p auf 1 und weist die Ressource des IEEE-1394-Busses 710 zu. Wenn der DV 702 mit der Regenerierung beginnt, ist die Ressource nicht zugewiesen, und der bcc ist auf 1 geändert, weil der p2p bereits 1, das heißt die Punkt-zu-Punkt-Verbindung bereits aufgebaut ist.
Wenn der PC 701 den Empfang stoppt, setzt der PC 701 die Kanalnummer des oPCR[0] 708 wieder auf ch63 zurück und setzt gleichzeitig den p2p auf 0 zurück. Zu diesem Zeitpunkt, da der DV 702 immer noch regeneriert, ist der bcc des oPCR[0] 708 1. Daher gibt der PC 701 die Ressource des IEEE-1394-Busses 710 nicht frei.
Wenn der DV 702 die Regenerierung stoppt, wird der bcc wieder auf 0 gesetzt, aber da der p2p ebenfalls auf 0 gesetzt ist und keine der Verbindungen aufgebaut ist, gibt der DV 702 die Ressource des IEEE-1304-Busses 710 frei.
29 zeigt den Fall, in dem der Regenerierungsbeginn des DV 702 und der Empfangsstopp des PC 701 früher liegen. Wenn der DV 702 die Regenerierung beginnt, weist der DV 702 die Ressource zu und setzt des Weiteren den bcc auf 0, weil der p2p immer noch 0 ist, das heißt, die Punkt-zu-Punkt-Verbindung nicht aufgebaut ist.
Wenn der PC 701 mit dem Empfang beginnt, wurde mit der Regenerierung des DV 702 bereits begonnen, und der bcc des oPCR[0) 708 ist 1. Daher ändert der PC 701 nur den p2p des oPCR[0] 708 auf 1, wobei weder die Kanalnummer geändert noch die Ressource des IEEE-1394-Busses 710 sichergestellt wird.
Wenn der PC 701 den Empfang stoppt, setzt der PC 701 den p2p des oPCR[0] 708 zurück auf 0. Zu diesem Zeitpunkt, da der DV 702 immer noch regeneriert, ist der bcc des oPCR[0] 708 1. Daher wird vom PC 701 nicht angefordert, die Ressource des IEEE-1394-Busses 710 freizugeben.
Wenn der DV 702 die Regenerierung stoppt, wird der bcc wieder auf 0 gesetzt, aber weil der p2p2 ebenfalls bereits auf 0 gesetzt ist und keine der Verbindungen aufgebaut ist, gibt der DV 702 die Ressource des IEEE-1394-Busses 710 frei.
30 zeigt den Fall, in dem der Regenerierungsbeginn des DV 702 und der Empfangsstopp des DV 702 früher liegen. Wenn der DV 702 die Regenerierung beginnt, weist der DV 702 die Ressource zu und setzt des Weiteren den bcc auf 1, weil der p2p immer noch 0 ist, das heißt, die Punkt-zu-Punkt-Verbindung nicht aufgebaut ist.
Wenn der PC 701 mit dem Empfang beginnt, wurde mit der Regenerierung des DV 702 bereits begonnen, und der bcc des oPCR[0] 708 ist 1. Daher ändert der PC 701 nur den p2p des oPCR[0] 708 auf 1, wobei weder die Kanalnummer geändert noch die Ressource des IEEE-1394-Busses 710 sichergestellt wird.
Wenn der DV 702 die Regenerierung stoppt, wird die Ressource nicht freigegeben und der bcc wird wieder auf 0 gesetzt, weil der p2p2 immer noch 1 ist, das heißt, die Punkt-zu-Punkt-Verbindung aufgebaut ist.
Wenn der PC 701 den Empfang stoppt, setzt der PC 701 den p2p des oPCR[0] wieder auf 0. Zu diesem Zeitpunkt, da der DV 702 nicht regeneriert, ist der bcc des oPCR[0] 708 ebenfalls 0. Zu diesem Zeitpunkt muss der PC 701 die Ressource des IEEE-1394-Busses 710 freigeben, aber da der IEEE-1394-Treiber 705 und der Treiber 704 für den DV die Merkmale aufweisen, dass sie keine Ressourcen außer denen freigeben können, die sie sich selbst zugewiesen haben, kann die Ressource nicht freigegeben werden.
Das heißt allgemein, dass Vorrichtungen, die an den IEEE-1394-Bus 110 angeschlossen sind, wie beispielsweise der DV 102, Ressourcen freigeben können, die andere Vorrichtungen zugewiesen haben. Im Gegensatz dazu weist der PC 101, auf dem Windows 98 vorgesehen ist, die Merkmale auf, dass er Ressourcen freigeben kann, die er sich selbst zugewiesen hat, aber keine Ressourcen freigeben kann, die durch andere Vorrichtungen zugewiesen worden sind.
Wie oben beschrieben, weist in IEC 61883 die Vorrichtung, die zuerst irgendeine Verbindung in einem Kanal aufbaut, diese Ressourcen zu, und die Vorrichtung, welche die Verbindung zuletzt getrennt hat, muss diese Ressourcen freigeben. Daher muss der PC 701 die Ressource freigeben, wenn er IEC 61883 entsprechen soll, doch kann die Ressource auf Grund der Merkmale des PC 701 nicht freigegeben werden.
Wenn die Ressource einmal nicht einwandfrei freigegeben wird, kann die Ressource nicht wieder verwendet werden, es sei denn, im IEEE-1394-Bus-1394 710 wird ein Bus-Reset erzeugt.
Abläufe von Datenquellen gemäß dem ersten bisherigen Stand der Technik sind oben beschrieben worden, doch werden in der oben beschriebenen Konfiguration alle Adressen des Deskriptors 110, der in der Deskriptorliste 103 gespeichert ist, im FIFO 107 ge speichert. In diesem Fall, wenn sich die Anzahl von Adressen in dem Deskriptor 110, die im FIFO 107 gespeichert werden sollen, erhöht, dann erhöht sich auch die Menge des Speicherplatzes in dem PC, der von dem IEEE-1394-Treiber 104 verwendet wird.
Wenn sich umgekehrt die Anzahl der Adressen des Deskriptors 110, die im FIFO 107 gespeichert werden sollen, verringert, sich also die Anzahl von Rahmenpufferspeichern in dem Datenpuffer 102 verringert, dann wird ein möglicher Bereich für das Akzeptieren des Jitters der Eingabedaten 108, die in den Datenumwandlungsabschnitt 101 eingegeben werden soll, enger. In diesem Fall, wenn die Eingabedaten 108, die in den Datenumwandlungsabschnitt 101 eingegeben werden sollen, beispielsweise einen gewissen Grad von Verzögerung oder mehr aufweisen, könnte der IEEE-1394-Treiber 104 das isochrone Paket 114 nicht kontinuierlich senden.
Das heißt, bei einer herkömmlichen Datenquelle besteht ein Problem (erstes Problem) dann, dass eine gewisse Ausgleichsbeziehung zwischen der Stabilität des Sendens und der Menge an Speicherplatz, die für den PC erforderlich ist, ausgebildet wird.
Des Weiteren sollten in Verfahren oder Vorrichtungen, die für den zweiten bisherigen Stand der Technik beschrieben wurden, Prozesse durch die Empfangs- und Datenformatumwandlungs-Software 3 und Prozesse durch die Datenformatrückwandlungs- und Sende-Software 5 vor und nach der Software 4, welche die Audio-/Videodaten bearbeitet, weiter ausgeführt werden, was kompliziert ist.
Da es sich jedoch bei den Daten, die durch die Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 bearbeitet werden, um Streamdaten und nicht um ein Dateiformat handelt, (das heißt, sie haben keine Header-Informationen und Index-Informationen), und in dem PC 1 die Software, welche die Audio-/Vdeodaten bearbeitet, zuerst auf die Aufzeichnungsmedien, welche die Festplatte 7 umfasst, sowie auf willkürliche Daten in asynchroner Zeitsteuerung zugreift, hilft der direkte Zugriff auf die Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2, die im Allgemeinen die Aufzeichnung/Regenerierung in Echtzeit durchführt, nicht dabei, die benötigten Daten zu erhalten.
In dem Fall, in dem die Software 4, welche die Audio-/Videodaten bearbeitet, nur Daten bearbeiten möchte, die in der Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 aufgezeichnet sind, und das Ergebnis auf die Festplatte des PC schreiben möchte, und umgekehrt in dem Fall, in dem die Software 4, welche die Audio-/Videodaten bearbeitet, nur die Daten auf der Festplatte des PC bearbeiten und die Ergebnisse in die Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung schreiben möchte, ist es ähnlich kompliziert, und es ist Festplattenkapazität erforderlich.
Des Weiteren ist zum Erfassen einer großen Menge von Audio-/Videodaten (beispielsweise von mehr als 1 GB für Daten von fünf Minuten) auf der Festplatte 7 eine Festplatte von großer Kapazität erforderlich. Wenn Dann auf der Festplatte gesammelt werden können, werden sie zwangsläufig von der Empfangs- und Datenumwandlungs-Software temporär erfasst, doch sollten die Daten bald ersetzt werden, weil die Kapazität der Festplatte rasch erschöpft ist, was sehr kompliziert ist.
Die Technik des bisherigen Stands weist die oben beschriebenen Probleme auf.
Das heißt, das Problem (zweites Problem) besteht dann, dass Verfahren und Vorrichtungen zum Bearbeiten von Video- und Audiodaten, die in der Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung durch die PC-Vorrichtung aufgezeichnet werden, kompliziert sind.
Des Weiteren besteht das Problem (drittes Problem) dann, dass ein Zugriff von der Software zum Bearbeiten von Video- und Audiodaten des PC nicht direkt auf die Video- und Audiodaten erfolgen kann, die in der Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung aufgezeichnet werden.
Des Weiteren besteht das Problem (viertes Problem) dann, dass eine Festplatte von großer Kapazität erforderlich ist, wenn die Video- und Audiodaten des PC bearbeitet werden.
Des Weiteren besteht in der herkömmlichen Konfiguration, die für den dritten bisherigen Stand der Technik beschrieben wurde, das Problem (fünftes Problem) darin, dass die Freigabe von Ressourcen des IEEE-1394-Busses nicht einwandfrei ausgeführt werden kann, und danach die Ressourcen nicht verwendet werden können, wenn Abläufe in der in 30 gezeigten Reihenfolge durchgeführt werden.
EP 0 860 823 A1 beschreibt ein Netzwerksystem mit einem IEEE-1394-Bus, wobei gestattet wird, isochrone Paketdaten von einer Datenquelle zu einer Datensenke unter einer Punkt-zu-Punkt- oder einer Eins-zu-Viele-Verbindung zu senden. Die verschiedenen Datenübertragungsarten werden unter Berücksichtigung dessen erörtert, wie Kopierschutz erhalten werden kann.
KURZDARSTELLUNG DER ERFINDUNG
In Bezug auf das oben beschriebene erste Problem wird durch die vorliegende Erfindung beabsichtigt, eine Datenquelle, ein Medium und eine Informationensammlung bereitzustellen, welche die Menge des für den PC erforderlichen Speicherplatzes reduzieren, wobei die Anzahl der Rahmenpufferspeicher unverändert bleibt.
In Bezug auf das oben beschriebene zweite bis vierte Problem wird durch die vorliegende Erfindung beabsichtigt, eine Datenumwandlungsvorrichtung, eine Hilfsdatendatei-Generierungsvorrichtung, eine Datenrückwandlungsvorrichtung, ein Datenumwandlungsverfahren, ein Hilfsdatendatei-Generierungsverfahren, ein Datenrückwandlungsverfahren, ein Medium und eine Informationensammlung bereitzustellen, die es ermöglichen, von der oben beschriebenen Software aus, die Video- und Audiodaten bearbeitet, in asynchroner Zeitsteuerung einen Zugriff auf willkürliche Daten vorzunehmen, wobei die Notwendigkeit beseitigt wird, sehr komplizierte Prozesse auszuführen, und kein Heraufladen/Herunterladen auf eine Festplatte durchgeführt werden muss, d.h. keine Festplatte mit großer Kapazität erforderlich ist.
In Bezug auf das oben beschriebene fünfte Problem wird durch die vorliegende Erfindung beabsichtigt, ein Empfangsverfahren, ein Medium und eine Informationensammlung bereitzustellen, die es ermöglichen, die Ressource des IEEE-1394-Busses jederzeit einwandfrei freizugeben.
Die Erfindung der vorliegenden Erfindung ist ein Empfangsverfahren, wobei in dem Fall, in dem eine Datensenke, die im Wesentlichen IEC 61883 entspricht, und eine Datenquelle, die IEC 61883 entspricht, an einen IEEE-1394-Bus angeschlossen sind, und in dem Fall, in dem die Datensenke ein Arbeitsplatzrechner mit einer IEEE-1394-Schnitt stelle und einer Vorrichtungs-Steuereinrichtung zum Steuern aller oder eines Teils der Vorrichtungen ist, die mit dem IEEE-1394-Bus verbunden sind, beim Empfangen von Empfangsbeginn-Befehlen die Datensenke feststellt, ob die Datenquelle Ausgabedaten unter Verwendung von Rundsende-Übertragung an den IEEE-1394-Bus ausgibt, und in dem Fall, in dem die Datenquelle die Ausgabedaten unter Verwendung von Rundsende-Übertragung an den IEEE-1394-Bus ausgibt, die Datensenke die Ausgabedaten ohne Aufbau einer Punkt-zu-Punkt-Verbindung mit der Datenquelle empfängt.
Die Erfindung umfasst des Weiteren ein Computerprogramm und ein Speichermedium, welches das Programm enthält.
(Kurze Beschreibung der Zeichnungen)
1 ist eine grafische Darstellung, die eine Datenquelle in der Ausführungsform der vorliegenden Erfindung und dem herkömmlichen Beispiel veranschaulicht.
2 ist eine grafische Darstellung, die ein Beispiel der Konfiguration von CIP-Daten 109 veranschaulicht.
3 ist eine grafische Darstellung, die ein Beispiel der Konfiguration von CIP-Daten 109 veranschaulicht, wenn leere Daten gesendet werden.
4 ist eine grafische Darstellung, die ein Beispiel der Konfiguration eines isochronen Pakets veranschaulicht.
5 ist eine grafische Darstellung, die ein Beispiel der Konfiguration eines Datenpuffers 2 veranschaulicht.
6 ist eine grafische Darstellung, die ein Beispiel der Konfiguration eines Deskriptors 110 veranschaulicht.
7 ist eine grafische Darstellung, die ein Beispiel der Konfiguration einer Deskriptorliste 103 veranschaulicht.
8 ist eine grafische Darstellung, die ein Beispiel der Konfiguration eines FIFO 107 in der Ausführungsform der vorliegenden Erfindung veranschaulicht.
9 ist eine grafische Darstellung, die ein Beispiel der Konfiguration des FIFO 107 in der Ausführungsform der vorliegenden Erfindung veranschaulicht.
10 ist eine grafische Darstellung, die ein Beispiel der Konfiguration des FIFO 107 in der Ausführungsform in dem herkömmlichen Beispiel veranschaulicht.
11 ist eine grafische Darstellung, die ein Beispiel der Konfiguration des FIFO 107 in der Ausführungsform in dem herkömmlichen Beispiel veranschaulicht.
12 ist ein Blockschaltbild zur Veranschaulichung der Datenrückwandlungsvorrichtung der Ausführungsform der vorliegenden Erfindung.
13 ist ein Blockschaltbild zur Veranschaulichung der Hilfsdatendatei-Generierungsvorrichtung der Ausführungsform der vorliegenden Erfindung.
14 ist ein Blockschaltbild zur Veranschaulichung der Datenrückwandlungsvorrichtung der Ausführungsform der vorliegenden Erfindung.
15 ist ein Blockschaltbild zur Veranschaulichung des Hilfsdatendatei-Generierungsmittels 41 zur Unterstützung des Datenrückwandlungsmittels 31 von 14.
16 ist eine erläuternde grafische Darstellung der Implementierung durch ein Programm.
17 ist eine erläuternde grafische Darstellung eines Prozesses zur Bearbeitung von herkömmlichen Streamdaten als einer Datei.
18 ist eine grafische Darstellung der Ausführungsform der vorliegenden Erfindung und der Datenquelle und Datensenke in dem herkömmlichen Beispiel.
19 ist eine grafische Darstellung der Konfiguration des oPCR.
20 ist eine grafische Darstellung der Konfiguration des iPCR.
21 ist eine konzeptionelle Ansicht der Rundsende-Übertragung in IEC 61883.
22 ist eine konzeptionelle Ansicht der Punkt-zu-Punkt-Übertragung in IEC 61883.
23 ist eine konzeptionelle Ansicht, welche den Zustand, dass die Rundsende-Übertragung und die Punkt-zu-Punkt-Übertragung in IEC 61882 gleichzeitig ausgeführt werden, zeigt.
24 ist eine grafische Darstellung, die ein Werte-Beispiel des iPCR[0] eines Senders 602 und eines oPCR[0] eines Empfängers 601 zeigt.
25 ist eine grafische Darstellung, die den Werte-Übergang in dem oPCR[0] 708 veranschaulicht.
26 ist eine grafische Darstellung, die den Werte-Übergang in dem oPCR[0] 708 veranschaulicht.
27 ist eine grafische Darstellung, die den Werte-Übergang in dem oPCR[0] 708 veranschaulicht.
28 ist eine grafische Darstellung, die den Werte-Übergang in dem oPCR[0] 708 veranschaulicht.
29 ist eine grafische Darstellung, die den Werte-Übergang in dem oPCR[0] 708 veranschaulicht.
30 ist eine grafische Darstellung, die den Werte-Übergang in dem oPCR[0] 708 veranschaulicht.

1: PC
2: Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung
4: Software, die Audio-/Videodaten bearbeitet
6: Software, die Dateien verwaltet
7: Festplatte
11: Datenumwandlungsmittel
12: Anforderungsanalysemittel
13: Auswahlmittel
21: Hilfsdatendatei-Generierungsmittel
22: Streamdaten-Analysemittel
23: Headerinformationen-Generierungsmittel
24: Indexinformationen-Generierungsmittel
25: Audioinformationen-Generierungsmittel
31: Datenrückwandlungsmittel
32: Anforderungs- und Daten-Analysemittel
33: Erster Puffer
34: Zweiter Puffer
41: Hilfsdatendatei-Generierungsmittel
42: Anforderungs- und Daten-Analysemittel
43: Headerinformationen-Generierungsmittel
44: Indexinformationen-Generierungsmittel
45: Audioinformationen-Generierungsmittel
101: Datenumwandlungsabschnitt
102: Datenpuffer
103: Deskriptorliste
104: IEEE-1394-Treiber
105: IEEE-1394-Schnittstelle
106: IEEE-1394-Bus
107: FIFO
108: Eingabedaten
109: CIP-Daten
110: Deskriptor
111: Adressen, in denen Deskriptoren 110 gespeichert sind
112: Sendebeginn-Befehle
113: Sendeende-Anzeige
114: Isochrones Paket
201: Paketdaten
202: CIP-Header
401: Isochroner Header
402: Header-CRC
403: Daten-CRC
501a, 501b, 501c, 501d: Rahmenpufferspeicher
502a, 502b, 502c, 502d: Flag Nicht gesendet
701: PC
702: DV
703: Anwendung
704: Treiber für den DV
705: IEEE-1394-Treiber
706: IEEE-1394-Schnittstelle
707: Daten ausgebender Abschnitt
708: oPCR[0]
709: IEEE-1394-Schnittstelle
710: IEEE-1394-Bus
711: DV-Daten
712: CIP
714: Ablaufbefehle
715: Anforderung
716: Antwort
717: Registerdaten
601: Empfänger
602: Sender

BEVORZUGTE AUSFÜHRUNGSFORMEN DER ERFINDUNG
Ausführungsformen der vorliegenden Erfindung werden im Folgenden unter Bezugnahme auf die Zeichnungen beschrieben.
(Erste Ausführungsform)
Zunächst wird eine erste Ausführungsform unter Bezugnahme auf 1 bis 9 beschrieben.
Eine Konfiguration der Datenquelle in dieser Ausführungsform ist dem ersten bisherigen Stand der Technik ähnlich, Eingabedaten 108 sind DV-Daten, die durch eine Vielzahl von Paketdaten 202 konfiguriert werden, und CIP-Daten 109 entsprechen IEC 61883.
8 und 9 zeigen ein Beispiel eines FIFO 107 einer Datenquelle gemäß dieser Ausführungsform. In 8 und 9 wurden die Adressen eines Deskriptors 110, die sich in der unteren Hierarchie des FIFO 107 befinden, später in dem FIFO 107 gespeichert. Auch ein Flag Nicht gesendet 502a, ein Flag Nicht gesendet 502b, ein Flag Nicht gesendet 502c und ein Flag Nicht gesendet 502d befinden sich in einem Zustand "Bereits gesendet" oder "Nicht gesendet", und der ursprüngliches Zustand ist "Bereits gesendet".
Abläufe der Datenquelle gemäß der Ausführungsform der vorliegenden Erfindung mit der oben beschriebenen Konfiguration werden im Folgenden beschrieben.
Nach dem Empfang der Eingangsdaten 108 ruft ein Datenumwandlungsabschnitt daraus Paketdaten 201 ab, fügt im Anschluss daran CIP-Header 202 an und speichert dieselben in einem Datenpuffer 102 als die CIP-Daten 109. Zu diesem Zeitpunkt werden die CIP-Daten 109 zuerst in dem Rahmenpufferspeicher 501a gespeichert.
Danach, wenn eine vorgegebene Anzahl von CIPs, beispielsweise vierzehn CIPs 109 in dem Rahmenpufferspeicher 501a gespeichert sind, erstellt der Datenumwandlungsabschnitt 101 den Deskriptor 110a, in dem ein Verfahren zum Senden der im Rahmenpufferspeicher 501a gespeicherten CIPS 109 beschrieben wird, und speichert ihn in der Deskriptorliste 103, wie in 6 gezeigt. Zu diesem Zeitpunkt werden die in der Deskriptorliste 103 gespeicherten Adressen 111a des Deskriptors 110a zusammen in dem FIFO 107 gespeichert, und zur gleichen Zeit wird das Sende-Flag 502a, das zum Rahmenpufferspeicher 501a gehört, auf "Nicht gesendet" gesetzt.
Von da an wechselt der Datenumwandlungsabschnitt 101 den Rahmenpufferspeicher für die Speicherung in der Reihenfolge von Rahmenpufferspeicher 501b → Rahmenpufferspeicher 501c → Rahmenpufferspeicher 501d → Rahmenpufferspeicher 501a, wobei eine vorgegebene Menge von CIPs 109 in jedem Rahmenpufferspeicher gespeichert wird. Zu diesem Zeitpunkt, wenn das Flag Nicht gesendet 502a des Rahmenpufferspeichers, in dem die CIP-Daten 109 als nächstes gespeichert werden sollen, beispielsweise im Rahmenpufferspeicher 501a, "Nicht gesendet" lautet, wartet der Datenumwandlungsabschnitt 101, bis das Flag Nicht gesendet auf "Bereits gesendet" gesetzt wird, ohne Abläufe für die Speicherung durchzuführen. Die Abläufe bis jetzt sind herkömmlichen Beispielen ähnlich.
In dieser Ausführungsform wird in dem oben beschriebenen Zustand in dem Fall, in dem eine vorgegebene Anzahl von Adressen bereits in dem FIFO 107 gespeichert ist, der Deskriptor 110, wenn er neu erstellt wird, in der Deskriptorliste 103 gespeichert, doch die Adressen 111, die dieser Deskriptorliste 103 entsprechen, werden nicht sofort in dem FIFO 107 gespeichert. Beispielsweise wird in einem in 10 gezeigten Beispiel, weil die Adresse 111a und die Adresse 111b bereits gespeichert sind, dann der Deskriptor 110c erstellt und wird in der Deskriptorliste 103 gespeichert, doch die gespeicherte Adresse 111c des Deskriptors 110c wird nicht in dem FIFO 107 gespeichert.
Des Weiteren, nachdem der Datenumwandlungsabschnitt 101 eine vorgegebene Anzahl von CIPS 109 in dem Rahmenpufferspeicher 501d gespeichert hat, sendet er die Sendebeginn-Befehle 112 an den IEEE-1394-Treiber 104, wenn die Sendebeginn-Befehle 112 noch nicht an den IEEE-1394-Treiber 104 gesendet worden sind.
Des Weiteren ruft der Datenumwandlungsabschnitt 101 nach dem Empfang der Sendeende-Anzeige 113 vom IEEE-1394-Treiber 104 aus dem FIFO 107 die Adresse 111a des Deskriptors 110a ab und verwirft dieselbe, worauf die Speicherung der Adresse 111c in der Deskriptorliste 103 folgt, die nicht in dem FIFO 107 gespeichert ist, wie in 9 gezeigt, wenn sich der FIFO 107 in dem in 8 gezeigten Zustand befindet, nämlich dass beispielsweise nur zwei Adressen gespeichert werden können. Zur gleichen Zeit, weil "A", das den Deskriptor 110a als "Deskriptor-Kennung" darstellt, zusammen mit der gesendeten Sendeende-Anzeige 113 zu diesem Zeitpunkt an den Datenumwandlungsabschnitt 101 gesendet wird, schreibt der Datenumwandlungsabschnitt 101 das Flag Nicht gesendet 502a, das dem Rahmenpufferspeicher 501a entspricht, auf "Bereits gesendet" um.
Von da an werden Daten durch Wiederholen dieser Prozesse vom PC an den DV gesendet.
Auf diese Weise ist gemäß der Datenquelle gemäß der Ausführungsform der vorliegenden Erfindung die Anzahl von Rahmenpufferspeichern in dem Datenpuffer 102 und die Anzahl der Deskriptoren 110, die in der Deskriptorliste 103 gespeichert werden können, die gleiche wie im Fall des ersten bisherigen Stands der Technik, und sie beträgt vier, doch die Anzahl der gespeicherten Adressen 111 des im FIFO 107 gespeicherten Deskriptors 110 ist zwei, wodurch es ermöglich wird, die vom IEEE-1394-Treiber 104 benötigte Menge des Speichers des Arbeitsplatzrechners zu reduzieren.
Des Weiteren, obwohl die Anzahl der Rahmenpufferspeicher und die Anzahl der Deskriptoren 110, die in der Deskriptorliste 103 gespeichert werden können, jeweils mit vier angegeben ist, kann jede Anzahl von 3 oder größer angenommen werden.
Des Weiteren, obwohl die Anzahl der gespeicherten Adressen 111 des im FIFO 107 gespeicherten Deskriptors 110 mit zwei angegeben worden ist, kann jede Anzahl von 1 oder größer und kleiner als die Anzahl der Deskriptoren 110, die in der Deskriptorliste 103 gespeichert werden können, angenommen werden.
Des Weiteren wurde eine Erläuterung angegeben, welche die Anzahl von Adressen, die verworfen werden sollen, nachdem Sendepakete als jeweils eines gesendet werden, beschreibt, doch kann sie auf M (fester oder variabler Betrag) gesetzt werden.
Des Weiteren wurde die Konfiguration des Deskriptors 110 als diejenige beschrieben, die in 6 gezeigt ist, doch so lange die Elemente des Deskriptors 110 wenigstens diejenigen umfassen, die in 6 gezeigt sind, kann jede Konfiguration angenommen werden, und die Anordnung ist nicht notwendigerweise die gleiche wie diejenige, die in 6 gezeigt ist.
Des Weiteren, obwohl beschrieben wurde, dass, nachdem der Datenumwandlungsabschnitt 101 eine vorgegebene Anzahl von CIPs 109 in dem Rahmenpufferspeicher 510d speichert, er die Sendebeginn-Startbefehle 112 an den IEEE-1394-Treiber 104 sendet, wenn die Sendebeginn-Startbefehle 112 noch nicht an den IEEE-1394-Treiber 104 gesendet worden sind, kann der Zeitpunkt, zu dem der Datenumwandlungsabschnitt 101 die Sendebeginn-Startbefehle 112 an den IEEE-1394-Treiber 104 sendet, irgendein anderer Zeitpunkt als dieser sein.
Des Weiteren sind die Eingabedaten 108 als DV-Daten beschrieben worden, die durch eine Vielzahl von Paketdaten 201 konfiguriert werden, aber sie können andere Arten von Daten sein, die durch eine Vielzahl von Paketdaten konfiguriert werden.
Des Weiteren ist beschrieben worden, dass die Datenquelle Daten zu dem IEEE-1394-Bus unter Verwendung des IEEE-1394-Treibers 104 und der IEEE-1394-Schnittstelle sendet, doch können auch andere Schnittstellen und Treiber verwendet werden.
Des Weiteren sind die CIP-Daten 109 als diejenigen beschrieben worden, die IEC 61883 entsprechen, doch können sie als andere Datenpakete beschrieben werden.
Des Weiteren entspricht das Datenumwandlungsmittel der vorliegenden Erfindung dem Umwandlungsabschnitt 101 dieser Ausführungsform, und das Datensendemittel der vorliegenden Erfindung entspricht dem IEEE-1394-Treiber 104 dieser Ausführungsform.
(Zweite Ausführungsform)
Im Folgenden wird eine zweite Ausführungsform beschrieben.
12 ist ein Blockschaltbild zur Erläuterung der Datenumwandlungsvorrichtung der Ausführungsform der vorliegenden Erfindung, und das in 12 gezeigte Datenumwandlungsmittel 11 ist die Datenumwandlungsvorrichtung dieser Ausführungsform. In 12 ist 12 das Anforderungs-Analysemittel, und 13 ist das Auswahlmittel.
Zunächst, nachdem eine Anforderung zum Lesen von Daten (eine Position am Anfang einer Datei und die Größe der zu lesenden Daten) von der Software 4, die Audio-/Vi deodaten bearbeitet, über die Software 6 zum Verwalten von Dateien empfangen worden ist, analysiert das Anforderungs-Analysemittel 12, welcher Abschnitt von Videodaten, Audiodaten, Header-Informationen und Index-Informationen angefordert wird, basierend auf den Header-Informationen und Index-Informationen, die als eine Datei auf der Festplatte 7 angelegt sind. Des Weiteren, wenn Videodaten angefordert werden, steuert das Anforderungs-Analysemittel 12 die Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 so, dass ein angeforderter Abschnitt von Videodaten erhalten werden kann.
Das Auswahlmittel 13 gibt die Header-Informationen und die Index-Informationen auf der Festplatte 7 basierend auf der Analyse durch das Anforderungs-Analysemittel 12 aus, wenn die Header-Informationen und die Index-Informationen angefordert werden, und gibt einen angeforderten Abschnitt der Videodaten aus, die von der Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 erhalten werden, wenn Videodaten angefordert werden. Abhängig von dem Inhalt der Anforderung können diese Daten kombiniert werden. Für die Audiodaten, wenn ein eine Audiodatendatei auf der Festplatte 7 angelegt ist, können deren Daten verwendet werden, und wenn sie nicht angelegt ist, wird die Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 so gesteuert, dass ein angeforderter Abschnitt der Audiodaten erhalten werden kann, um die Audiodaten wie in dem Fall der Videodaten zu erhalten.
Auf diese Weise wandelt das Auswahlmittel 13 die Daten, die von der Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 erhalten werden, in die Datensequenz um, die von der Software 4, welche Audio-/Videodaten bearbeitet, verarbeitet werden kann, und gibt dieselben aus auf der Basis des Ergebnisses der Analyse durch das Anforderungs-Analysemittel 12.
Das Datenumwandlungsmittel 11 der oben beschriebenen Konfiguration ermöglicht es der Software 4, welche Audio-/Videodaten bearbeitet, sogar auf Streamdaten zuzugreifen, die in der Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 aufgezeichnet sind, ohne eine Festplatte mit großer Kapazität zu verwenden, indem die Daten als eine Datei betrachtet werden, und ohne komplizierte Abläufe auszuführen.
Des Weiteren, obwohl beschrieben worden ist, dass die Header-Informationen und Index-Informationen sich auf der Festplatte 7 befinden, sind sie nicht notwendigerweise auf der Festplatte 7, sondern können auch auf einem Speicher angelegt sein, um Hochgeschwindigkeitsabläufe sicherzustellen.
13 ist ein Blockschaltbild zur Erläuterung einer Hilfsdatendatei-Generierungsvorrichtung der Ausführungsform der vorliegenden Erfindung, und das Hilfsdatendatei-Generierungsmittel 21, das in 13 gezeigt ist, ist die Hilfsdatendatei-Generierungsvorrichtung dieser Ausführungsform. In 13 ist 22 das Streamdaten-Analysemittel, 23 ist ein Headerinformationen-Generierungsmittel, 24 ist ein Indexinformationen-Generierungsmittel und 25 ist ein Audioinformationen-Generierungsmittel.
Für die Datenumwandlungsvorrichtung dieser Ausführungsform, die unter Bezugnahme auf 12 beschrieben wurde, ist beschrieben worden, dass die Header-Informationen und Index-Informationen (und Audiodaten, die fehlen können), welche Hilfsdaten sind, von vornherein auf der Festplatte 7 als eine Datei vorhanden sind, und Mittel zum Generieren der Informationen werden erläutert.
Das Streamdaten-Analysemittel 22 extrahiert die Header-Informationen aus den Streamdaten, die von der Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 regeneriert wurden, und das Headerinformationen-Generierungsmittel 23 generiert eine Sequenz in Übereinstimmung mit dem Format der Header-Informationen der Datei mit einem Format, das von der Software 4, welche Audio-/Videodaten bearbeitet, verarbeitet werden kann, und schreibt die Sequenz als eine Datei auf die Festplatte 7.
Des Weiteren untersucht das Streamdaten-Analysemittel 22 unter der Annahme, dass die Videodaten und Audiodaten aus den Streamdaten, die von der Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 regeneriert worden sind, in eine Einheit von einem oder mehreren Datenübertragungsblöcken aufgeteilt worden sind ab dem Datenübertragungsblock, der dem Anfang der Datei entspricht, bis zu dem Datenübertragungsblock, der dem Ende der Datei entspricht, die Größe der Daten jedes Blocks und generiert Index-Informationen, und das Indexinformationen-Generierungsmittel 24 generiert eine Datensequenz in Übereinstimmung mit dem Format der Index-Informationen der Datei mit einem Format, das von der Software 4, weiche Audio-/Videodaten bearbei tet, verarbeitet werden kann, und schreibt die Sequenz als eine Datei auf die Festplatte 7.
Das Hilfsdatendatei-Generierungsmittel 21 der oben beschriebenen Konfiguration ermöglicht es, die Header-Informationen und Index-Informationen zu generieren, für die keine Daten (Videodaten) von der Streamdaten-Aufzeichnungs-/Regenerierugsvorrichtung 2 regeneriert worden sind, die aber benötigt werden, um die Daten wie eine Datei aussehen zu lassen.
Des Weiteren kann das Streamdaten-Analysemittel 22 Audiodaten aus den Daten extrahieren, die durch die Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 regeneriert worden sind, und das Audioinformationen-Generierungsmittel 25 kann die Audiodaten in eine Sequenz von Audiodaten in Übereinstimmung mit einem Format umwandeln, das von der Software 4, welche Audio-/Videodaten bearbeitet, verarbeitet werden kann, und die Sequenz als eine Datei auf die Festplatte 7 schreiben. Da die Audiodaten eine größere Kapazität aufweisen als die Header-Informationen und Index-Informationen, können sie in Dateien von einem oder mehreren Datenübertragungsblöcken als Einheit aufgeteilt werden, statt als eine Datei betrachtet zu werden.
14 ist ein Blockschaltbild zur Erläuterung der Datenrückwandlungsvorrichtung der Ausführungsform der vorliegenden Erfindung, wobei das Datenrückwandlungsmittel 31, das in 14 gezeigt ist, die Datenrückwandlungsvorrichtung dieser Ausführungsform ist. In 14 ist 32 das Anforderungs- und Daten-Analysemittel, 33 ist ein erster Puffer und 34 ist ein zweiter Puffer. Das Datenrückwandlungsmittel 31 ist ein Mittel, das Daten, die durch die Software 4, welche Audio-/Videodaten bearbeitet, verarbeitet wurden, in Streamdaten umwandelt, um die Daten in einem Aufzeichnungsmedium der Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 aufzuzeichnen Zunächst, nachdem eine Anforderung zum Schreiben von Daten (eine Position am Anfang der Datei und die Größe der zu schreibenden Daten) von der Software 4, die Audio-/Videodaten bearbeitet, über die Software 6 zum Verwalten von Dateien empfangen worden ist, analysiert das Anforderugs- und Daten-Analysemittel 32, um welchen Abschnitt von Videodaten, Audiodaten, Header-Informationen und Index-Informationen es sich handelt. Das Anforderungs- und Daten-Analysemittel 32 schreibt die Daten in den ersten Puffer 33, wenn es sich um Audiodaten handelt, und schreibt die Daten in den zweiten Puffer 34, wenn es sich um Videodaten handelt.
Das Anforderungs- und Analysemittel 32 überwacht im Voraus die Menge von Daten, die in den zweiten Puffer 34 geschrieben werden sollen, und wenn eine vorgegebene Menge von Daten angesammelt ist, kombiniert sie das Anforderungs- und Daten-Analysemittel 32 mit dem Teil der Audiodaten, die in dem ersten Puffer 33 angesammelt wurden und den Videodaten in dem zweiten Puffer 34 entsprechen, und sendet sie zum Aufzeichnen an die Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2.
Das Datenrückwandlungsmittel 31 der oben beschriebenen Konfiguration ermöglicht es, asynchron geschriebene Daten in der Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 als Streamdaten in Echtzeit in einem Dateiformat von der Software 4, welche Audio-/Videodaten bearbeitet, aufzuzeichnen.
Des Weiteren wird hier in dem Fall, in dem Audio-/Videodaten in einem Dateiformat geschrieben werden, eine Steuerung auf Videodaten-Basis durchgeführt, da Audiodaten im Allgemeinen vor den Videodaten geschrieben werden, doch können ähnliche Auswirkungen mit einer Konfiguration erzielt werden, in der die Steuerung auf einer Audiodaten-Basis durchgeführt wird.
In dem Fall einer Datei, die auf einem DV-(digitale Videokassette) Format basiert, in dem Audiodaten in einen Teil von Videodaten eingefügt werden, und in einem avi-Dateiformat wird dieser Teil von Audiodaten ignoriert. Wenn daher Daten tatsächlich zu der Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 gesendet und aufgezeichnet werden, können die Audiodaten, für die von der Software 4, welche die Audio-/Videodaten bearbeitet, angeordnet worden ist, sie zu schreiben, exakt aufgezeichnet werden, indem sie die Audiodaten des ersten Puffers 33 über die Audiodaten in den Videodaten des zweiten Puffers 34 überschreiben.
15 ist ein Blockschaltbild, welches das Hilfsdatendatei-Generierungsmittel 41 der Ausführungsform der vorliegenden Erfindung zeigt, 42 ist das Anforderungs- und Daten-Analysemittel, 43 ist das Headerinformationen-Generierungsmittel, 44 ist das Indexinformationen-Generierungsmittel und 45 ist das Audioinformationen-Generierungsmittel.
In der oben beschriebenen Ausführungsform, die unter Bezugnahme auf 14 erläutert worden ist, können die Videodaten und Audiodaten in der Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 aufgezeichnet werden, doch wenn die Software 4, welche die Audio-/Videodaten bearbeitet, die gleiche Datei nochmals lesen möchte, muss das in 12 gezeigte Datenumwandlungsmittel 11 die Datei generieren, wie bei der zweiten Ausführungsform erläutert, wenn die Header-Informationen und Index-Informationen (und Audiodaten, die fehlen können), von vornherein auf der Festplatte 7 als eine Datei vorhanden sind.
Wenn das Hilfsdatendatei-Generierungsmittel 41 die Header-Informationen und Index-Informationen (und Audiodaten) als eine Datei generiert vor den Daten, für die angeordnet wird, sie zu schreiben, wenn die Software 4, welche die Audio-/Videodaten bearbeitet, die Daten in der Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 aufzeichnet, könnte der Aufwand, sie in einer Weise zu generieren, die bei der zweiten Ausführungsform beschrieben worden ist, weggelassen werden, was im Folgenden erklärt wird.
Der Teil der Daten, die als Header-Informationen in der Analyse durch das Anforderungs- und Daten-Analysemittel 42 ermittelt werden, wird durch das Headerinformationen-Generierungsmittel 43 direkt auf die Festplatte 7 geschrieben. Für eine Datei im avi-Format kann er als Header-Informationen betrachtet werden, wenn eine Position am Anfang der Datei (= OFFSET) 0 ist in der Anforderung von der Software 4, welche die Audio-/Videodaten über die Software 6 zum Verwalten der Datei bearbeitet, weil die Header-Informationen am Anfang der Datei positioniert sind. Da das Format der Header-Informationen des Weiteren eine Struktur annimmt, in welche der Block, der den Inhalt angibt, die Datengröße und tatsächliche Daten nacheinander geschrieben werden, kann die Größe der Header-Informationen leicht erfasst werden.
Der Teil der Daten, die als Index-Informationen in der Analyse durch das Anforderungs- und Daten-Analysemittel 42 ermittelt werden, wird durch das Indexinformationen-Generierungsmittel 44 direkt auf die Festplatte 7 geschrieben. Für die Datei im avi-Format kann die Position am Anfang des Index berechnet werden, weil Größeninformationen über den gesamten Datenabschnitt, (dieser Teil kann in den Header-Informationen ent halten sein), am Anfang der Audio-/Videodaten nach den Header-Informationen aufgezeichnet wird. Da die Größeninformationen über den Indexeintrag in den Anfangsabschnitt des Index geschrieben werden, und die Größeninformationen der gesamten Datei in den Anfang des Headers geschrieben werden, kann die Größe der Index-Informationen leicht erfasst werden.
Zu diesem Zeitpunkt kann die Konfiguration für einfache Prozesse modifiziert werden, wenn der Indexeintrag aus der Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 ausgelesen wird. Wenn die Dateigröße und die Größe des Indexeintrags auf Grund der Modifizierung geändert werden, ist es erforderlich, gleichzeitig die entsprechenden Informationen der Header-Informationen und Index-Informationen zu aktualisieren.
Das Hilfsdatendatei-Generierungsmittel 41 der oben beschriebenen Konfiguration ermöglicht es, die Header-Informationen und Index-Informationen zu generieren, die erforderlich sind, um die Streamdaten, die von der Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 regeneriert werden, wie eine Datei aussehen zu lassen.
Des Weiteren kann das Anforderungs- und Daten-Analysemittel 42 die Audiodaten aus der Software 4, welche Audio-/Videodaten bearbeitet, extrahieren und die Audiodaten als Datei in einem Format auf die Festplatte 7 schreiben, das von der Software 4, welche die Audio-/Videodaten bearbeitet, verarbeitet werden kann. Da die Audiodaten eine größere Kapazität aufweisen als die Header-Informationen und Index-Informationen, können sie in Dateien mit einem oder mehreren Datenübertragungsblöcken als Einheit aufgeteilt werden statt als eine Datei betrachtet zu werden. Da eine Block-Kennung zum Identifizieren von Audiodaten und Videodaten für jeden Block und die Block-Größeninformationen ebenfalls zu dem Datenabschnitt hinzugefügt werden, lassen sich die Audiodaten leicht erfassen.
Danach wurden in der oben beschriebenen Ausführungsform das Datenumwandlungsmittel 11, das Hilfsdatendatei-Generierungsmittel 21, das Datenrückwandlungsmittel 31 und das Hilfsdatendatei-Generierungsmittel 41 als in dem PC 1 enthalten beschrrieben, (wobei andere Ausrüstungen als Arbeitsplatzrechner mit ähnlichen Funktionen ebenfalls eingesetzt werden können), doch kann die vorliegende Erfindung leicht durch andere unabhängige Systeme implementiert werden, indem mit einem Programm die Funktio nen, die das Datenumwandlungsmittel 11, das Hilfsdatendatei-Generierungsmittel 21, das Datenrückwandlungsmittel 31 und das Hilfsdatendatei-Generierungsmittel 41 aufweisen, ausgeführt werden, und diese Funktionen in Aufzeichnungsmedien, wie beispielsweise Disketten, aufgezeichnet und transportiert werden. 16 beschreibt den Fall, in dem diese Funktionen unter Verwendung einer Diskette transportiert werden.
16(a) zeigt ein Beispiel eines physikalischen Formats der Diskette, die der Hauptkörper eines Aufzeichnungsmediums ist. Spuren sind wie konzentrische Kreis vom äußeren Umfang zum inneren Umfang hin ausgebildet und in Winkelrichtung in sechzehn Sektoren aufteilt. Ein Programm wird entsprechend den Bereichen aufgezeichnet, die auf diese Weise zugewiesen werden.
16(b) veranschaulicht ein Gehäuse, das diese Diskette aufnimmt. Von links werden jeweils eine Vorderansicht der Diskette, ihre Schnittansicht und die Diskette gezeigt. Indem die Diskette auf diese Weise in das Gehäuse aufgenommen wird, kann die Diskette völlig vor Staub und Einwirkungen von außen geschützt und transportiert werden.
16(c) veranschaulicht die Durchführung einer Aufzeichnung/Regenerierung des Programms auf der Diskette. Wie in der Figur gezeigt, kann durch Anschließen eines Diskettenlaufwerks an ein Computersystem die Aufzeichnung/Regenerierung des Programms auf der Diskette durchgeführt werden. Die Diskette wird in das Diskettenlaufwerk über einen Einfuhrschlitz eingeführt und daraus entnommen. Im Fall einer Aufzeichnung zeichnet das Computersystem das Programm auf der Diskette unter Verwendung des Diskettenlaufwerks auf. Im Fall einer Regenerierung liest das Diskettenlaufwerk das Programm aus der Diskette aus und überträgt das Programm zum Computersystem.
Des Weiteren wurde in dieser Ausführungsform eine Erläuterung zur Verwendung der Diskette als ein Aufzeichnungsmedium gegeben, aber eine ähnliche Leistung kann auch unter Verwendung einer Bildplatte erzielt werden. Des Weiteren ist das Aufzeichnungsmedium nicht auf diese Platten beschränkt, sondern es können Medien, die ein Programm aufzeichnen können, wie beispielsweise Halbleiterspeicherkarten und ROM-Kassetten auf eine ähnliche Art implementiert werden.
Wie oben beschrieben, wird eine Lese-Anforderung von der Software 4, welche die Audio-/Videodaten bearbeitet, über die Software 6 zum Verwalten der Datei basierend auf den von vornherein angelegten Header-Informationen und Index-Informationen analysiert, und die Daten, die durch Einfügen der Header-Informationen und Index-Informationen in Streamdaten erhalten werden, werden als Lesedaten zurückgegeben, wodurch es der Software 4, welche die Audio-/Videodaten bearbeitet, gestattet wird, sogar auf die Streamdaten zuzugreifen, die in der Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung als eine Datei aufgezeichnet sind.
Des Weiteren wird ermöglicht, die Header-Informationen und Index-Informationen, die benötigt werden, um die Daten wie eine Datei aussehen zu lassen, aus den Daten, die durch die Streamdaten-Aufzeichnungs-/Regenerierungsvorrichtung 2 regeneriert wurden, oder den Daten, die eine Schreib-Anforderung von der Software 6 zum Verwalten der Datei begleiten, zu generieren und die Informationen auf der Festplatte 7 als eine Datei anzulegen.
Des Weiteren wird ermöglicht, die Daten, die asynchron in einem Dateiformat geschrieben wurden, in Echtzeit als Streamdaten aufzuzeichnen, indem Audio-/Videodaten aus den Daten extrahiert werden, welche die Schreib-Anforderung von der Software 4, welche die Audio-/Videodaten bearbeitet, über die Software 6 zum Verwalten der Datei begleiten, und die Audio-/Videodaten in einem Stapel zu übertragen, wenn eine vorgegebene Menge angesammelt worden ist.
(Dritte Ausführungsform)
Im Folgenden wird eine dritte Ausführungsform unter Bezugnahme auf 18 bis 20 und 25 bis 28 beschrieben.
Die Konfiguration und Abläufe des DV 702 sind denjenigen des dritten bisherigen Stands der Technik ähnlich, und die Konfiguration des PC 701 ist derjenigen des dritten bisherigen Stands der Technik ähnlich.
Des Weiteren ist der DSV 702 dieser Ausführungsform ein Beispiel der Datenquelle der vorliegenden Erfindung, der PC 701 dieser Ausführungsform ist ein Beispiel des Ar beitsplatzrechners der vorliegenden Erfindung, der Treiber 704 für den DV, der IEEE-1394-Treiber 705 dieser Ausführungsform sind ein Beispiel für Vorrichtungs-Steuereinrichtungen der vorliegenden Erfindung.
Die Abläufe des PC 701 werden beschrieben.
Nach dem Empfang der Empfangsbeginn-Befehle als Ablaufbefehle 714 von der Anwendung 703 sendet der Treiber 704 für den DV zunächst eine Anforderung, um den Wert des oPCR[0] 708 des DV 702 zu erhalten, als die Anforderung 715 an den IEEE-1394-Treiber 705. Der IEEE-1394-Treiber 705 fordert die IEEE-1394-Schnittstelle 709 auf, die Registerdaten 717 in dem oPCR[0] 708 über die IEEE-1394-Schnittstelle 706 zu senden. Nach dem Empfang der Sendeanforderung ruft die IEEE-1394-Schnittstelle 709 die Registerdaten 717 aus dem oPCR[0] 708 ab und sendet dieselben an die IEEE-1394-Schnittstelle 706. Der IEEE-1394-Treiber 705 gibt die Registerdaten 717, die von der IEEE-1394-Schnittstelle 706 empfangen wurden, an den Treiber 704 für den DV als die Antwort 716 aus.
Der Treiber 704 für den DV prüft den Inhalt der Registerdaten 717, und wenn der bcc des oPRC[0] 708 gleich 1 ist, baut er die Punkt-zu-Punkt-Verbindung zum DV 702 nicht auf, das heißt, er sendet eine Anforderung als die Anforderung 715, mit dem Empfang von Daten direkt ab dem Wert zu beginnen, der durch die Kanalnummer in dem oPCR[0] 708 angegeben wird, beispielsweise ch63, an den IEEE-1394-Treiber 705. Nach dem Empfang der Empfangsbeginn-Befehle als der Anforderung 715 beginnt der IEEE-1394-Treiber 705 mit dem Empfangen der isochronen Pakete, die Daten aus dem ch63 auf dem IEEE-1394-Bus sind, über die IEEE-1394-Schnittstelle 706.
Abläufe von da an sind denjenigen des dritten bisherigen Stands der Technik ähnlich.
Abläufe in dem Fall, in dem der bcc des oPCR[0] 708 gleich 0 ist, sind denjenigen des dritten bisherigen Stands der Technik ähnlich.
Andererseits sendet der Treiber 704 für den DV, nachdem er die Empfangsstopp-Befehle als die Ablaufbefehle 714 von der Anwendung 703 empfangen hat, zunächst Befehle als die Anforderung 715, das Empfangen von Daten von dem IEEE-1394-Bus 710 zu stoppen, an die IEEE-1394-Schnittstelle 706. Nach dem Empfang der Empfangsstopp-Befehle stoppt die IEEE-1394-Schnittstelle 706 den Empfang von Daten von dem IEEE-1394-Bus 710.
Als Nächstes, wenn bei Empfangsbeginn 1 zu dem p2p in dem oPCR[0] 708 hinzugefügt wird, um die Punkt-zu-Punkt-Verbindung aufzubauen, sendet der Treiber 704 für den DV als die Anforderung 715 eine Anforderung an den IEEE-1394-Treiber 705, um den Wert des oPCR[0] 708 von dem DV 702 zu erhalten. Danach sendet der Treiber 704 für den DV Befehle, um die Daten, die erhalten wurden, indem der durch Subtrahieren von 1 von dem Wert des p2p im oPRC[0] 708 erhaltene Wert von dem p2p des oPRC[0] 708 zu dem IEEE-1394-Treiber 705 zugewiesen wird, als neue Registerdaten 717 in das oPCR[0] 708 zu schreiben. Durch Abläufe, die denjenigen ähnlich sind, die oben beschrieben wurden, wird der Wert des oPCR[0] 708 des DV 702 geändert. Wenn der bcc des oPCR[0] 708 gleich 0 ist und der Treiber 704 für den DV die Ressource des IEEE-1304-Busses 710 früher zuweist, dann gibt der Treiber 704 für den DV die Ressource des IEEE-1394-Busses 719 zur gleichen Zeit frei. Danach, sofern erforderlich, setzt der Treiber 704 für den DV den Wert der Kanalnummer des oPCR[0] 708 auf den ursprunglichen Wert zurück.
Wenn die Punkt-zu-Punkt-Verbindung zum DV 702 bei Empfangsbeginn nicht aufgebaut wird, tut der Treiber 704 für den DV nichts und beendet den Prozess.
Für die oben beschriebenen Abläufe sind Tabellen, welche die Werte des oPCR[0] 708 des DV 702 beschreiben und dazu, wer die Ressource des IEEE-1394-Busses 710 zuweist, und wer dieselben freigibt, als Beispiel in 25 bis 28 gezeigt.
Wie im Fall des dritten bisherigen Stands der Technik sind insgesamt vier Abläufe möglich, wobei berücksichtigt wird, welcher von Regenerierungsbeginn des DV 702 und Empfangsbeginn des PC 701 früher durchgeführt wurde, und welcher von Regenerierungsstopp des DV 702 und Empfangsstopp des PC 701 früher durchgeführt wurde.
25 zeigt den Fall, in dem der Regenerierungsbeginn des DV 702 und der Empfangsstopp des PC 701 früher durchgeführt werden. Wenn der DV 702 die Regenerie rung beginnt, weist der DV 702 die Ressource zu, weil der p2p immer noch 0 ist, das heißt, die Punkt-zu-Punkt-Verbindung nicht aufgebaut ist.
Wenn der PC 701 mit dem Empfang beginnt, wurde mit der Regenerierung des DV 702 bereits begonnen, und der bcc des oPCR[0] 708 ist 1. Daher ändert der PC 701 die Kanalnummer und den Wert des p2p2 nicht und weist die Ressource des IEEE-1394-Busses 710 nicht zu. Das heißt, die Punkt-zu-Punkt-Verbindung ist nicht aufgebaut und nur die Rundsende-Übertragung wird verwendet.
Wenn der PC 701 den Empfang stoppt, ist der bcc des oPCR[0] 708 1, weil der DV 702 immer noch die Regenerierung durchführt. Daher muss der PC 701 die Ressource des IEEE-1394-Busses 710 nicht freigeben.
Wenn der DV 702 die Regenerierung stoppt, wird der bcc auf 0 zurückgesetzt, aber da der p2p ebenfalls 0 bleibt und keine der Verbindungen aufgebaut ist, gibt der DV 702 die Ressource des IEEE-1304-Busses 710 frei.
26 zeigt den Fall, in dem der Regenerierungsbeginn des DV 702 und der Empfangsstopp des PC 701 früher durchgeführt werden. Wenn der DV 702 die Regenerierung beginnt, weist der DV 702 die Ressource zu, weil der p2p immer noch 0 ist und die Punkt-zu-Punkt-Verbindung nicht aufgebaut ist.
Wenn der PC 701 mit dem Empfang beginnt, wurde mit der Regenerierung des DV 702 bereits begonnen, und der bcc des oPCR[0] 708 ist 1. Daher ändert der PC 701 nur den p2p des oPCR[0] 708 auf 1, wobei weder die Kanalnummer geändert noch die Ressource des IEEE-1394-Busses 710 sichergestellt wird.
Wenn der DV 702 die Regenerierung stoppt, gibt der DV 702 die Ressource des IEEE-1394-Busses 710 frei, weil auch der p2p 0 ist, das heißt, die Punkt-zu-Punkt-Verbindung noch nicht aufgebaut ist.
Wenn der PC 701 mit dem Empfang beginnt, gibt der DV 702 die Ressource des IEEE-1394-Busses bereits frei, und daher kann der PC 701 den Empfang einfach stoppen.
Abläufe in dem Fall, in dem der Empfangsbeginn früher durchgeführt wird, sind denjenigen des dritten bisherigen Stands der Technik ähnlich, die in 27 und 28 gezeigt sind.
Daher wird selbst in dem Fall, in dem der PC 701 mit seinem Merkmal, Ressourcen freigeben zu können, die er sich selbst zugewiesen hat, aber keine Ressourcen freigeben zu können, die durch andere Vorrichtungen zugewiesen worden sind, die Ressource des IEEE-1394-Busses in jedem Fall richtig zugewiesen und freigegeben, ohne Berücksichtigung der Reihenfolge des Beginns/Stopps des Empfangs des PC 701 und des Beginns/Stopps der Regenerierung des DV 702.
Des Weiteren wurde der Wert der Kanalnummer, die in das oPCR[0] 708 des DV 708 als ein ursprünglicher Zustand geschrieben wurde, mit ch63 beschrieben, doch kann jede ganze Zahl von 0 bis 63 angenommen werden.
Des Weiteren ist beschrieben worden, dass der Wert der Kanalnummer des oPCR[0] 708 des DV 702 auf ch0 gesetzt wird, wenn die Punkt-zu-Punkt-Verbindung zum DV 702 durch den PC 701 aufgebaut ist, doch kann jede ganze Zahl von 0 bis 63 angenommen werden, so lange der Kanal nicht bereits durch eine andere Vorrichtung zugewiesen worden ist.
Des Weiteren wurde beschrieben, dass der PC 701 und der DV 702 an den IEEE-1394-Bus 701 angeschlossen werden, doch können andere IEEE-1394-Vorrichtungen angeschlossen werden.
Des Weiteren wurde beschrieben, dass der p2p2 des oPCR[0] 708 des DV 702 als ein ursprünglicher Zustand 0 ist, das heißt, dass der DV 702 nicht mit einer Punkt-zu-Punkt-Verbindung mit einer anderen Vorrichtung ausgelegt ist, doch kann der DV 702 als ein ursprünglicher Zustand mit einer Punkt-zu-Punkt-Verbindung mit einer anderen Vorrichtung ausgelegt sein.
Auch in dieser Ausführungsform wurden Abläufe des PC 701 erläutert, doch wenn eine Vorrichtung, welche die Ressource freigeben kann, die durch eine andere Vorrichtung als den PC 701 zugewiesen worden ist, d.h. eine andere Vorrichtung Daten von dem DV 702 empfängt, kann die Vorrichtung wie in dem Fall des PC 701 dieser Ausführungsform arbeiten, oder die Vorrichtung kann wie in dem Fall des für den bisherigen Stand der Technik beschriebenen PC 701 arbeiten.
Des Weiteren gehört ein Medium, das ein Programm und/oder Daten trägt, um alle oder einen Teil der Funktionen von allen oder einem Teil der Mittel der Datenquelle, der Umwandlungsvorrichtung, der Hilfsdatendatei-Generierungsvorrichtung oder der Datenrückwandlungs-Vorrichtung der vorliegenden Erfindung durch den Rechner ausführen zu lassen, dadurch gekennzeichnet, dass das Medium durch den Rechner verarbeitet werden kann, ebenfalls zu der vorliegenden Erfindung.
Des Weiteren gehört eine Informationensammlung, dadurch gekennzeichnet, dass die Informationensammlung ein Programm und/oder Daten ist, um alle oder einen Teil der Funktionen von allen oder einem Teil der Mittel der Datenquelle, der Umwandlungsvorrichtung, der Hilfsdatendatei-Generierungsvorrichtung oder der Datenrückwandlungs-Vorrichtung der vorliegenden Erfindung durch den Rechner ausführen zu lassen, ebenfalls zu der vorliegenden Erfindung.
Des Weiteren gehört ein Medium, das ein Programm und/oder Daten trägt, um alle oder einen Teil der Abläufe von allen oder einem Teil der Schritte des Datenumwandlungsverfahrens, des Hilfsdatendatei-Generierungsverfahrens, des Datenrückwandlungsverfahrens oder des Empfangsverfahrens der vorliegenden Erfindung durch den Rechner ausführen zu lassen, dadurch gekennzeichnet, dass das Medium durch den Rechner verarbeitet werden kann, ebenfalls zu der vorliegenden Erfindung.
Eine Informationensammlung, dadurch gekennzeichnet, dass die Informationensammlung ein Programm und/oder Daten ist, um alle oder einen Teil der Abläufe von allen oder einem Teil der Schritte des Datenumwandlungsverfahrens, des Hilfsdatendatei-Generierungsverfahrens, des Datenrückwandlungsverfahrens oder des Empfangsverfahrens der vorliegenden Erfindung durch den Rechner ausführen zu lassen, gehört ebenfalls zu der vorliegenden Erfindung.
Des Weiteren ist die vorliegende Erfindung ein Medium, das ein Programm und/oder Daten trägt, um alle oder einen Teil der Funktionen von allen oder einem Teil der Mittel der Datenquelle, der Datenumwandlungsvorrichtung, der Hilfsdatendatei-Generierungsvorrichtung oder der Datenrückwandlungs-Vorrichtung der vorliegenden Erfindung durch den Rechner ausführen zu lassen, wobei das oben beschriebene Programm und/oder die Daten, die gelesen werden können und von dem Rechner gelesen worden sind, mit dem oben beschriebenen Rechner zusammenarbeiten, um die oben beschriebenen Funktionen auszuführen.
Des Weiteren ist die vorliegende Erfindung ein Medium, das ein Programm und/oder Daten trägt, um alle oder einen Teil der Abläufe von allen oder einem Teil der Schritte des Datenumwandlungsverfahrens, des Hilfsdatendatei-Generierungsverfahrens, des Datenrückwandlungsverfahrens oder des Empfangsverfahrens der vorliegenden Erfindung durch den Rechner ausführen zu lassen, wobei das oben beschriebene Programm und/oder die Daten, die gelesen werden können und von dem Rechner gelesen worden sind, mit dem oben beschriebenen Rechner zusammenarbeiten, um die oben beschriebenen Abläufe auszuführen.
Die vorliegende Erfindung ist eine Informationensammlung, die ein Programm und/oder Daten ist, um alle oder einen Teil der Funktionen von allen oder einem Teil der Mittel der Datenquelle, der Datenumwandlungsvorrichtung, der Hilfsdatendatei-Generierungsvorrichtung oder der Datenrückwandlungs-Vorrichtung der vorliegenden Erfindung durch den Rechner ausführen zu lassen, wobei das oben beschriebene Programm und/oder die Daten, die gelesen werden können und von dem Rechner gelesen worden sind, mit dem oben beschriebenen Rechner zusammenarbeiten, um die oben beschriebenen Funktionen auszuführen.
Die vorliegende Erfindung ist eine Informationensammlung, die ein Programm und/oder Daten ist, um alle oder einen Teil der Abläufe von allen oder einem Teil der Schritte des Datenumwandlungsverfahrens, des Hilfsdatendatei-Generierungsverfahrens, des Datenrückwandlungsverfahrens oder des Empfangsverfahrens der vorliegenden Erfindung durch den Rechner ausführen zu lassen, wobei das oben beschriebene Programm und/oder die Daten, die gelesen werden können und von dem Rechner gelesen worden sind, mit dem oben beschriebenen Rechner zusammenarbeiten, um die oben beschriebenen Abläufe auszuführen.
Des Weiteren enthalten die Daten der vorliegenden Erfindung Datenstruktur, Datenformat, Datentyp und Ähnliches.
Des Weiteren umfasst das Medium der vorliegenden Erfindung Aufzeichnungsmedien wie beispielsweise ROM, Übertragungsmedien wie beispielsweise Internet und Übertragungsmedien wie beispielsweise Licht, Funk, Schallwellen und Ähnliches.
Des Weiteren umfasst das Trägermedium der vorliegenden Erfindung beispielsweise Aufzeichnungsmedien, die ein Programm und/oder Daten aufzeichnen, und Übertragungsmedien, die ein Programm und/oder Daten übertragen.
Des Weiteren umfasst das "kann durch den Rechner verarbeitet werden" gemäß der vorliegenden Erfindung das "kann durch den Rechner gelesen werden" in dem Fall von Aufzeichnungsmedien, wie beispielsweise ROM, und "ein Programm und/oder Daten, die gesendet werden sollen, können als das Ergebnis einer Übertragung durch den Rechner behandelt werden", beispielsweise im Fall von Übertragungsmedien.
Des Weiteren umfasst die Informationensammlung der vorliegenden Erfindung Software, wie beispielsweise Programme und/oder Daten.
Des Weiteren, wie oben beschrieben, kann die Konfiguration der vorliegenden Erfindung entweder durch Software oder Hardware implementiert werden.
Ersichtlich aus dem, was oben beschrieben worden ist, kann die vorliegende Erfindung eine Datenquelle, ein Medium und eine Informationensammlung bereitstellen, die es ermöglichen, die Speichermenge des Arbeitsplatzrechners, die von dem IEEE-1394-Treiber verwendet wird, zu reduzieren, selbst wenn die gleiche Anzahl von Rahmenpufferspeichern verwendet wird, indem die Anzahl von Adressen, die im FIFO gespeichert werden sollen, reduziert wird.
Die vorliegende Erfindung kann des Weiteren eine Datenumwandlungsvorrichtung, eine Hilfsdatendatei-Generierungsvorrichtung, eine Datenrückwandlungsvorrichtung, ein Datenumwandlungsverfahren, ein Hilfsdatendatei-Generierungsverfahren, ein Datenrückwandlungsverfahren, ein Medium und eine Informationensammlung, die keine Festplatte mit einer großen Kapazität benötigen, weil es möglich ist, einen direkten Zugriff von der Software, welche die Audio-/Videodaten bearbeitet, in willkürlicher asynchroner Zeitsteuerung direkt auf willkürliche Daten vorzunehmen, bereitstellen, und es ist nicht notwendig, sehr komplizierte Prozesse durchzuführen und Daten auf die Festplatte hochzuladen oder davon herunterzuladen.
Des Weiteren kann die vorliegende Erfindung ein Empfangsverfahren, ein Medium und eine Informationensammlung bereitstellen, die es der Datensenke ermöglichen, einen Empfang unter Verwendung einer Rundsende-Übertragung statt des Aufbaus der Punkt-zu-Punkt-Verbindung in dem Fall durchzuführen, indem die Datenquelle bereits eine Rundsende-Übertragung durchführt, wodurch es möglich wird, die Ressource des IEEE 1394 am Ende der Datenübertragung immer richtig freizugeben.

Claims

Empfangsverfahren, wobei in dem Fall, in dem eine Datensenke, die IEC-61883 entspricht, und eine Datenquelle, die IEC 61883 entspricht, mit einem IEEE-1394-Bus verbunden sind, und in dem Fall, in dem die Datensenke ein Personal Computer mit einer IEEE-1394-Schnittstelle und einer Vorrichtungs-Steuereinrichtung ist, die alle oder einen Teil der Vorrichtungen steuert, die mit dem IEEE-1394-Bus verbunden sind, beim Empfangen von Befehlen zum Beginn des Empfangs die Datensenke feststellt, ob die Datenquelle Ausgabedaten unter Verwendung von Rundsende-Übertragung an den IEEE-1394-Bus ausgibt, und in dem Fall, in dem die Datenquelle die Ausgabedaten unter Verwendung von Rundsende-Übertragung an den IEEE-1394-Bus ausgibt, die Datensenke die Ausgabedaten ohne Herstellung einer Punkt-zu-Punkt-Verbindung mit der Datenquelle empfängt.
Empfangsverfahren nach Anspruch 1, wobei die Datenquelle ein Ausgabe-Steuerregister aufweist, das Ausgabe-Steuerregister ein Flag, das anzeigt, ob Rundsende-Übertragung durchgeführt wird, und eine Kanalnummer enthält, die anzeigt, an welchen Kanal die Ausgabedaten ausgegeben werden, und in dem Fall, in dem die Datensenke der Personal Computer ist, die Datensenke durch Lesen des Flags feststellt, ob die Datenquelle die Ausgabedaten unter Verwendung von Rundsende-Übertragung an den IEEE-1394-Bus ausgibt, und in dem Fall, in dem die Datenquelle die Ausgabedaten unter Verwendung von Rundsende-Übertragung an den IEEE-1394-Bus ausgibt, die Datenquelle die Ausgabedaten von dem Kanal empfängt, für den die Kanalnummer beschrieben ist, ohne die Kanalnummer zu ändern.
Empfangsverfahren nach Anspruch 1, wobei die Datenquelle ein Ausgabe-Steuerregister aufweist, das Ausgabe-Steuerregister ein Flag, das anzeigt, ob Rundsende-Übertragung durchgeführt wird, und eine Kanalnummer enthält, die anzeigt, an welchen Kanal die Ausgabedaten ausgegeben werden, und in dem Fall, dem die Datensenke der Personal Computer ist, die Datensenke durch Lesen des Flags feststellt, ob die Datenquelle die Ausgabedaten unter Verwendung von Rundsende-Übertragung an den IEEE-1394-Bus ausgibt, und die Datensenke die Kanalnummer auf einen willkürlichen Wert N (N ist eine Ganzzahl zwischen 0 und 63) ändert und dann die Ausgabedaten von einem Kanalempfängt, dessen Kanalnummer N ist.
Empfangsverfahren nach Anspruch 2 oder 3, wobei in dem Fall, in dem die Datenquelle die Ausgabedaten nicht an den IEEE-1394-Bus ausgibt, in dem Fall, in dem die Datensenke der Personal Computer ist, nachdem die Datensenke eine Punkt-zu-Punkt-Verbindung mit der Datenquelle hergestellt hat, die Datenquelle beginnt, die Ausgabedaten an den IEEE-1394-Bus auszugeben und gleichzeitig die Datensenke die Ausgabedaten empfängt.
Empfangsverfahren nach einem der Ansprüche 2 bis 4, wobei eine zweite Datensenke, die IEC-61883 entspricht, mit dem IEEE-1394-Bus verbunden ist, und in dem Fall, in dem die Datenquelle die Ausgabedaten an den IEEE-1394-Bus unter der Bedingung ausgibt, dass die Datenquelle eine Punkt-zu-Punkt-Verbindung mit der zweiten Datensenke hergestellt hat oder herstellt und ohne Verwendung von Rundsende-Übertragung ausgibt, und in dem Fall, in dem die Datensenke der Personal Computer ist, die Datensenke eine Punkt-zu-Punkt-Verbindung mit der Datenquelle herstellt und die Ausgabedaten empfängt.
Empfangsverfahren nach einem der Ansprüche 1 bis 5, wobei die Datenquelle ein digitaler Video-Recorder zum Einsatz in einem Haushalt ist.
Empfangsverfahren nach einem der Ansprüche 1 bis 5, wobei die Datenquelle eine Set-Top-Box ist, die MPEG-Daten ausgibt.
Computer-Programm und Datensammlung zum Ausführen der Verfahrensschritte nach einem der Ansprüche 1 bis 7 in einer Datenverarbeitungsvorrichtung.
Computerlesbares Medium, das das Computer-Programm und die Datensammlung nach Anspruch 8 speichert.