FR2863437A1 - Procede et systeme de stockage et/ou restitution d'au moins un flux audio video isochrone dans/depuis un dispositif de stockage comprenant au moins une unite de stockage asynchrone - Google Patents

Procede et systeme de stockage et/ou restitution d'au moins un flux audio video isochrone dans/depuis un dispositif de stockage comprenant au moins une unite de stockage asynchrone Download PDF

Info

Publication number
FR2863437A1
FR2863437A1 FR0314274A FR0314274A FR2863437A1 FR 2863437 A1 FR2863437 A1 FR 2863437A1 FR 0314274 A FR0314274 A FR 0314274A FR 0314274 A FR0314274 A FR 0314274A FR 2863437 A1 FR2863437 A1 FR 2863437A1
Authority
FR
France
Prior art keywords
control module
isochronous
storage
blocks
audio video
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0314274A
Other languages
English (en)
Other versions
FR2863437B1 (fr
Inventor
Jean Paul Accarie
Emmanuel Raguet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Europa NV
Original Assignee
Canon Europa NV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Europa NV filed Critical Canon Europa NV
Priority to FR0314274A priority Critical patent/FR2863437B1/fr
Publication of FR2863437A1 publication Critical patent/FR2863437A1/fr
Application granted granted Critical
Publication of FR2863437B1 publication Critical patent/FR2863437B1/fr
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40117—Interconnection of audio or video/imaging devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/407—Bus networks with decentralised control
    • H04L12/413—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection (CSMA-CD)
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/426—Internal components of the client ; Characteristics thereof
    • H04N21/42661—Internal components of the client ; Characteristics thereof for reading from or writing on a magnetic storage medium, e.g. hard disk drive
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/432—Content retrieval operation from a local storage medium, e.g. hard-disk
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4334—Recording operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4363—Adapting the video or multiplex stream to a specific local network, e.g. a IEEE 1394 or Bluetooth® network

Abstract

L'invention concerne des procédés de stockage et restitution d'au moins un flux audio vidéo isochrone, par un dispositif de stockage comprenant un module de contrôle relié, via un premier réseau de communication, à au moins une unité de stockage de données présentant un mode de transfert asynchrone, chaque flux audio vidéo isochrone comprenant des paquets isochrones. Le procédé de stockage est tel que, pour chaque flux audio vidéo isochrone, le module de contrôle effectue les étapes suivantes : regroupement des paquets isochrones du flux audio vidéo isochrone dans des premiers blocs de données ; transmission des premiers blocs de données à ladite au moins une unité de stockage, selon ledit mode de transfert asynchrone, de façon que ladite au moins une unité de stockage stocke les premiers blocs de données. Le procédé de restitution est tel que, pour chaque flux audio vidéo isochrone, le module de contrôle effectue les étapes suivantes : il commande ladite au moins une unité de stockage afin qu'elle lise des seconds blocs de données et les lui transmette, selon ledit mode de transfert asynchrone ; il retrouve des premiers blocs de données à partir des seconds blocs de données reçus ; il retrouve des paquets isochrones à partir des premiers blocs de données retrouvés ; il reconstruit le flux audio vidéo isochrone avec les paquets isochrones retrouvés.

Description

Procédé et système de stockage et/ou restitution d'au moins un flux audio
vidéo isochrone dans/depuis un dispositif de stockage comprenant au moins une unité de stockage asynchrone.
Le domaine de l'invention est celui des réseaux de communication permettant 5 l'interconnexion d'une pluralité d'appareils et notamment, mais non exclusivement, les réseaux audiovisuels domestiques permettant d'interconnecter des équipements audio et/ou vidéo, de type analogique et/ou numérique, afin qu'ils échangent des signaux audiovisuels.
Les appareils (aussi appelés terminaux) précités appartiennent par exemple à la liste d'appareils suivante, qui n'est pas exhaustive: récepteurs de télévision (par satellite, par voie hertzienne, par câble, xDSL, ...), téléviseurs, magnétoscopes, scanners, caméras numériques, appareils photo numériques, lecteurs DVD, ordinateurs, assistants numériques personnels (PDA), imprimantes, etc. Plus précisément, l'invention concerne un procédé de stockage d'au moins un flux audio vidéo isochrone au sein d'un réseau de communication, ainsi qu'un procédé correspondant de restitution d'au moins un flux audio vidéo isochrone préalablement stocké.
Dans le cadre de la présente invention, on suppose que les flux ne sont pas stockés dans les appareils (terminaux) eux-mêmes, mais dans des unités de stockage de 20 données.
Typiquement, chaque unité de stockage est un disque dur. Il est clair cependant que la présente invention s'applique aussi avec des unités de stockage plus complexes, pouvant comprendre chacune plusieurs disques durs et des moyens de contrôle de ces derniers.
L'invention s'applique notamment, mais non exclusivement, dans le cas où les unités de stockage sont connectées à un bus IEEE 1394. On rappelle que la norme IEEE 1394 est décrite dans les documents de référence suivants: IEEE Std 1394-1995, Standard for High Performance Serial Bus et IEEE Std 1394a-2000, Standard for High Performance Serial Bus (Supplement) .
Dans le monde IEEE 1394 , on peut aujourd'hui trouver deux types de disques durs (HDD, pour Hard Disk Drives ) externes: des disques durs audio vidéo, conformes au protocole AV/C. Le protocole AV/C est décrit dans les documents de référence suivants: AV/C Digital Interface Command Set General Specification Version 4.1 2001012 et AV/C Disc Subunit Hard Disk Drive Device Type (#2001023) . Les disques durs AV/C sont dédiés essentiellement au stockage et à la restitution de flux audio vidéo ( storage & playback en anglais) selon un (ou parfois plusieurs) format(s) audio vidéo déterminé(s) (par exemple MPEG2). Ils possèdent les caractéristiques principales suivantes: un mode de transfert isochrone, pour le transfert de flux audio vidéo, et un mode de transfert asynchrone, pour le transfert de commandes AV/C (ces deux modes de transfert sont ceux définis dans la norme IEEE 1394) ; un nombre limité de flux pouvant être traités simultanément (par exemple un flux entrant (stockage) et un flux sortant (restitution), cette limite peut se concrétiser par la présence d'uniquement deux registres décrits dans la standard IEC 61883 et appelés iPCR/oPCR (Input/Output Plug Control Register)) au niveau des disques durs AV/C; des disques durs conformes au protocole SBP-2. Le protocole SBP-2 est décrit dans le document de référence suivant: Serial Bus Protocol 2 (SBP-2) (working draft, revision 3, March 21, 1998) . Les disques durs SBP-2 sont dédiés essentiellement à l'extension des capacités de stockage d'un ordinateur personnel (PC). Ils possèdent les caractéristiques principales suivantes: un mode de transfert asynchrone (celui défini dans la norme IEEE 1394) ; une relation initiateur/cible (agissant comme une cible ( target ), un disque dur SBP-2 effectue des opérations de lecture/écriture selon des requêtes d'un initiateur ( initiator )) ; un formatage avec un format de système de fichier spécifique (par exemple FAT-32, ext2, NTFS,...) qui souvent dépend des systèmes d'exploitation des ordinateurs personnels (PC).
La technique actuelle de stockage et de restitution d'un flux audio vidéo est 30 basée sur l'utilisation de disques durs AV/C. En effet, ceux-ci sont adaptés à cette utilisation du fait que, contrairement aux disques durs SBP-2, ils présentent un mode de transfert isochrone.
On présente maintenant brièvement, à travers deux exemples et en relation avec les figures lA et 1B, cette technique actuelle de stockage et de restitution d'un flux 5 audio vidéo.
Dans l'exemple de la figure 1A, le réseau de communication est un bus IEEE 1394, référencé 1, auquel sont connectés deux terminaux IEEE 1394 (par exemple des téléviseurs numériques, de types source et destinataire à la fois), référencés A et B, et deux disques durs AV/C, référencés Dl et D2.
Dans l'exemple de la figure 1B, le réseau de communication est de type hétérogène. Il comprend un réseau fédérateur, référencé 2, auquel sont reliés une pluralité de bus IEEE 1394, référencés 31 à 33. Le réseau fédérateur 2 comprend une unité centrale de commutation 4 à laquelle sont reliées, chacun par un lien distinct 5, à 53, trois noeuds 61 à 63. Les trois bus numériques IEEE 1394, 31 à 33 sont reliés au réseau fédérateur 2, chacun par un des noeuds. Des terminaux IEEE 1394 (par exemple des téléviseurs numériques, de types source et destinataire à la fois), référencés A et B, sont connectés aux bus référencés 31 et 32 respectivement. Deux disques durs AV/C, référencés Dl et D2, sont connectés au bus référencé 33. La capacité physique de chacun des disques durs Dl et D2 à gérer des flux simultanés est définie d'une part par le débit global maximal qu'il peut traiter (par exemple 50 Mbit/s) et d'autre part par le nombre maximal de flux simultanés qu'il peut traiter (par exemple deux flux simultanés, un en entrée et un en sortie).
On suppose, à titre d'exemple illustratif, que le terminal A effectue un double traitement avec décalage temporel ( time-shifting en anglais). En d'autres termes, en tant que terminal source, il génère un premier flux qui est stocké par le disque Dl, et en tant que terminal destinataire, ce premier flux lui est restitué par le disque Dl, sous la forme d'un second flux lu avec un décalage temporel par rapport à l'écriture du premier flux.
Si on suppose que ce double traitement avec décalage temporel utilise la totalité 30 ou une partie substantielle du débit global maximal que peut traiter le disque Dl, alors le terminal B ne peut pas accéder au disque Dl pour lire ou écrire un autre flux. Le terminal B ne peut utiliser que le disque D2.
Dans l'exemple ci-dessus, le débit global maximal du disque Dl est atteint par deux flux. Il est clair que, d'une façon générale, une situation de blocage peut aussi se 5 produire du fait que le débit global maximal d'un disque est atteint par un ou plusieurs flux.
Il existe par ailleurs un protocole SBP-3 en cours de définition. Il est décrit dans le document de référence suivant: Serial Bus Protocol 3 (SBP-3) (working draft, revision 4, May 9, 2003) . Il vise à étendre le protocole SBP-2, afin de fournir une fonctionnalité de transfert isochrone. Il prévoit un fonctionnement en deux phases successives: dans une première phase, l'initiateur ( initiator ) utilise le mode de transfert asynchrone pour demander un transfert à la cible ( target ) ; dans une deuxième phase, la cible ( target ) demande à l'initiateur ( initiator ) de transmettre les données sur un canal donné, en utilisant un mode de transfert isochrone.
Toutefois, une technique basée sur le protocole SBP-3 ne constitue pas une solution de remplacement optimale à la technique actuelle (discutée ci-dessus) basée sur l'utilisation de disques durs AV/C. En effet, une première contrainte est que l'initiateur et la cible doivent être conformes au protocole SBP-3, qui par définition est plus contraignant que le protocole SBP-2 qu'il vise à étendre. Une autre contrainte est que le protocole SBP-3 n'est pas adapté à un contexte multi-utilisateur, dans lequel une pluralité de flux audio vidéo doivent être traités simultanément. En effet, le standard SPB-3 spécifie des équipements limités à l'usage d'un seul canal pour les flux ( singlechannel streams ), soit en entrée ( input ), soit en sortie ( output ), mais pas les deux simultanément.
L'invention a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique.
Plus précisément, l'un des objectifs de la présente invention est de fournir une technique de stockage et restitution d'au moins un flux audio vidéo isochrone au sein d'un réseau de communication, cette technique permettant l'utilisation d'unités de stockage asynchrones existantes (notamment, mais non exclusivement, des disques durs SBP-2).
L'invention a également pour objectif de fournir une telle technique qui soit indépendante du format des flux audio vidéo isochrones (DV, MPEG2 TS,
.)...DTD: Un autre objectif de l'invention est de fournir une telle technique qui ne nécessite aucune adaptation des terminaux source et des terminaux destinataires.
Encore un autre objectif de l'invention est de fournir une telle technique qui permette un accès multi-utilisateur à des unités de stockage (lecture et/ou écriture d'une pluralité de flux simultanés).
Un objectif complémentaire de l'invention est de fournir une telle technique qui soit simple à mettre en oeuvre et peu coûteuse.
Ces différents objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints selon l'invention à l'aide d'un procédé de stockage d'au moins un flux audio vidéo isochrone dans un dispositif de stockage comprenant un module de contrôle relié, via un premier réseau de communication, à au moins une unité de stockage de données présentant un mode de transfert asynchrone, chaque flux audio vidéo isochrone comprenant des paquets isochrones. Selon l'invention, pour chaque flux audio vidéo isochrone, le module de contrôle effectue les étapes suivantes: regroupement des paquets isochrones du flux audio vidéo isochrone dans des premiers blocs de données; - transmission des premiers blocs de données à ladite au moins une unité de 20 stockage, selon ledit mode de transfert asynchrone, de façon que ladite au moins une unité de stockage stocke les premiers blocs de données.
Le principe général de l'invention consiste donc à convertir un flux audio vidéo isochrone en au moins un flux de données asynchrone (grâce au regroupement des paquets isochrones en premiers blocs de données possédant une structure particulière), et à transmettre ce flux de données asynchrone, selon un mode de transfert asynchrone, vers au moins une unité de stockage asynchrone où il est stocké. En d'autres termes, contrairement au protocole SBP-3, la technique de l'invention n'utilise pas un mode de transfert isochrone jusqu'aux unités de stockage.
L'invention étant mise en oeuvre dans le dispositif de stockage, elle ne nécessite 30 aucune modification des terminaux source et destinataires existants. En effet, le dispositif de stockage est vu comme une unité de stockage par les terminaux source et les terminaux destinataires.
Les unités de stockage comprises dans le dispositif de stockage peuvent être classiques ou légèrement modifiées de façon à pouvoir gérer un nombre suffisant de flux 5 simultanés.
Il est à noter que les premiers blocs selon l'invention n'ont pas tous la même taille. En effet, la partie utile de chaque premier bloc (c'est-àdire la partie qui contient la séquence de paquets isochrones) possède une taille qui est fonction du nombre et de la taille des paquets isochrones contenus dans cette partie utile. Sauf hasard, la taille de la partie utile de chaque premier bloc n'est donc pas égale à la taille maximale prédéterminée (elle ne fait que s'en approcher plus ou moins).
De façon avantageuse, le dispositif de stockage comprend une pluralité d'unités de stockage de données présentant un mode de transfert asynchrone, et les premiers blocs de données, résultant du regroupement de paquets isochrones compris dans un ou plusieurs flux audio vidéo isochrones, sont répartis entre ladite pluralité d'unités de stockage.
De cette façon, dans le cas d'un stockage simultané de plusieurs flux dans le dispositif de stockage, on optimise la répartition de la charge de chacune des unités de stockage.
Par ailleurs, l'invention permet d'obtenir un système de stockage pouvant être mis en oeuvre de façon graduée: l'ajout d'unités de stockage permet d'augmenter les capacités de stockage du dispositif de stockage, ainsi que le nombre de flux simultanés que celui-ci peut traiter.
L'invention concerne également un procédé de restitution d'au moins un flux audio vidéo isochrone préalablement stocké dans un dispositif de stockage comprenant un module de contrôle relié, via un premier réseau de communication, à au moins une unité de stockage de données présentant un mode de transfert asynchrone, chaque flux audio vidéo isochrone comprenant des paquets isochrones, le stockage préalable étant tel que ladite au moins une unité de stockage stocke des premiers blocs de données regroupant des paquets isochrones du flux audio vidéo isochrone. Selon l'invention, pour chaque flux audio vidéo isochrone, le module de contrôle effectue les étapes suivantes: il commande ladite au moins une unité de stockage afin qu'elle lise des seconds blocs de données et les lui transmette, selon ledit mode de transfert asynchrone; - il retrouve des premiers blocs de données à partir des seconds blocs de données reçus; il retrouve des paquets isochrones à partir des premiers blocs de données retrouvés; il reconstruit le flux audio vidéo isochrone avec les paquets isochrones retrouvés.
Il est important de noter que la taille des seconds blocs de données est généralement différente de celle des premiers blocs de données. Ceci apporte une flexibilité permettant d'optimiser la gestion des mémoires des éléments compris dans le dispositif de stockage (module de contrôle et unité(s) de stockage).
L'invention concerne aussi un module de contrôle compris dans un dispositif de stockage d'au moins un flux audio vidéo isochrone, le module étant destiné à être relié, au sein du dispositif de stockage et via un premier réseau de communication, à au moins une unité de stockage de données présentant un mode de transfert asynchrone, chaque flux audio vidéo isochrone comprenant des paquets isochrones.
Selon l'invention, afin de permettre une opération de stockage, le module de 20 contrôle comprend: des moyens de regroupement des paquets isochrones de chaque flux audio vidéo isochrone dans des premiers blocs de données; des moyens de transmission des premiers blocs de données à ladite au moins une unité de stockage, selon ledit mode de transfert asynchrone, de façon que ladite au moins une unité de stockage stocke les premiers blocs de données.
Selon l'invention, afin de permettre une opération de restitution, le module de contrôle comprend: des moyens de commande de ladite au moins une unité de stockage afin que, pour chaque flux audio vidéo isochrone à restituer, elle lise des seconds blocs de 30 données et les lui transmette, selon ledit mode de transfert asynchrone; des moyens permettant de retrouver des premiers blocs de données à partir des seconds blocs de données reçus; des moyens permettant de retrouver des paquets isochrones à partir des premiers blocs de données retrouvés; - des moyens de reconstruction du flux audio vidéo isochrone avec les paquets isochrones retrouvés.
D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante d'un mode de réalisation préférentiel de l'invention, donné à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels: les figures lA et 1B présentent deux exemples de réseau audiovisuel domestique permettant d'illustrer la technique actuelle de stockage et de restitution d'un flux audio vidéo isochrone au sein d'un tel réseau; - les figures 2A et 2B présentent deux exemples de réseau audiovisuel domestique permettant d'illustrer la technique selon l'invention de stockage et de restitution 15 d'un flux audio vidéo isochrone au sein d'un tel réseau; la figure 3A présente un schéma bloc fonctionnel d'un mode de réalisation du module de contrôle apparaissant dans le premier exemple de réseau de la figure 2A - la figure 3B présente un schéma bloc fonctionnel d'un mode de réalisation du 20 module de contrôle apparaissant dans le second exemple de réseau de la figure 2B; la figure 4 illustre le protocole SBP-2 de base, exécuté entre un initiateur ( initiator ) et une cible ( target ) ; la figure 5 illustre un mode de réalisation d'une structure de données utilisée dans la présente invention comme structure de premiers blocs de données; - la figure 6 représente un algorithme d'initialisation, exécuté par le module de contrôle dans un mode de réalisation particulier du procédé selon l'invention de stockage et/ou restitution d'au moins un flux audio vidéo isochrone; - la figure 7 représente un algorithme d'établissement de connexion, exécuté par le module de contrôle au cours d'une opération de stockage de flux audio vidéo isochrone selon l'invention; la figure 8 représente un algorithme de regroupement de paquets isochrones (détail d'une des étapes apparaissant sur la figure 7) ; la figure 9 représente un algorithme de stockage d'un premier bloc de données dans un disque dur SBP-2 (détail d'une des étapes apparaissant sur la figure 8) ; la figure 10 représente un algorithme de génération et d'envoi de paquets isochrones, exécuté par le module de contrôle au cours d'une opération de restitution de flux audio vidéo isochrone selon l'invention; - la figure 11 représente un algorithme de lecture et d'envoi de seconds blocs de données par un disque dur SBP-2 (détail d'une des étapes apparaissant sur la 10 figure 10) ; - la figure 12 illustre la gestion de flux de données dans le cas d'opérations mufti-flux dans un mode de réalisation particulier du procédé selon l'invention de stockage et restitution de flux audio vidéo; - la figure 13 représente un algorithme de gestion d'une pluralités de disques durs 15 SBP-2 au cours d'opérations de stockage dans un mode de réalisation particulier du procédé selon l'invention de stockage de flux audio vidéo; - la figure 14 présente un schéma bloc fonctionnel d'un mode de réalisation du module de contrôle apparaissant dans le premier exemple de réseau de la figure 2A et illustrant la mise en oeuvre d'un dispositif de stockage de type AV/C obtenu à partir de disque(s) SBP-2.
On suppose que chaque flux audio vidéo isochrone que l'on cherche à stocker ou à restituer est du type comprenant des paquets isochrones conformes à un protocole de transport réseau tel qu'à chaque cycle de traitement est associé un paquet isochrone. Dans la suite de la description, on se place dans le cas où chaque unité de stockage de données est un disque dur conforme à la norme SBP-2 (SBP-2 HDD).
On présente maintenant, en relation avec la figure 2A, un premier exemple de réseau audiovisuel domestique permettant d'illustrer la technique selon l'invention de stockage et de restitution d'un flux audio vidéo isochrone au sein d'un tel réseau.
De même que dans l'exemple de la figure 1A, deux terminaux IEEE 1394 (par exemple des téléviseurs numériques), référencés A et B, sont connectés à un bus IEEE 1394 (appelé ci-après second bus), référencé 21.
Selon l'invention, un dispositif de stockage 27 est également connecté au second bus 21. Il comprend un module de contrôle 28 relié à une pluralité de disques SBP-2, référencés Dl,... Dn, via un autre bus IEEE 1394 (appelé ci-après premier bus), référencé 29. Le module de contrôle 28 assure également la fonction de noeud (ou pont) homogène car c'est lui qui est relié au second bus 21. Sur le premier bus 29, le mode de transfert asynchrone IEEE 1394 est utilisé pour communiquer avec les disques SBP-2 (c'est-à-dire transférer des données vers/depuis ces disques et contrôler ces disques).
On présente maintenant, en relation avec la figure 2B, un second exemple de réseau audiovisuel domestique permettant d'illustrer la technique selon l'invention de stockage et de restitution d'un flux audio vidéo isochrone au sein d'un tel réseau.
De même que dans l'exemple de la figure 2A, deux terminaux IEEE 1394 (par exemple des téléviseurs numériques), référencés A et B, sont connectés à un réseau de communication hétérogène. Ce dernier comprend un réseau fédérateur, référencé 22, auquel sont reliés une pluralité de bus IEEE 1394, référencés 231 et 232. Le réseau fédérateur 22 comprend une unité centrale de commutation 24 à laquelle sont reliées, chacun par un lien distinct 25, et 252, deux noeuds 26, et 262. Deux bus numériques IEEE 1394, 231 et 232 sont reliés au réseau fédérateur 22, chacun par un des noeuds 261 et 262. Les terminaux A et B sont connectés aux bus référencés 23, et 232 respectivement.
Selon l'invention, un dispositif de stockage 270 est également connecté au réseau de communication hétérogène, en étant relié à l'unité centrale de commutation 24 par un lien 253. Il comprend un module de contrôle 280 relié à une pluralité de disques SBP-2 Dl,... Dn, via un bus IEEE 1394 référencé 290. Le module de contrôle 280 assure également la fonction de noeud (ou pont) hétérogène car c'est lui qui est relié à l'unité centrale de commutation 24.
On présente maintenant, en relation avec la figure 3A, un mode de réalisation particulier du module de contrôle 28 apparaissant dans le premier exemple de réseau de la figure 2A.
Le module de contrôle 28 comprend: un premier bloc d'interface IEEE 1394, référencé 31, entre le module de 30 contrôle 28 et le premier bus 29; un second bloc d'interface IEEE 1394, référencé 32, entre le module de contrôle 28 et le second bus 21; un module d'adaptation (formant pont), référencé 33, relié aux premier et second blocs d'interface 31, 32, et gérant: * lors d'une opération de stockage: des opérations de conversion d'(au moins) un flux audio vidéo isochrone, transmis selon un mode de transfert isochrone, en (au moins) un flux asynchrone, transmis selon un mode de transfert asynchrone; lors d'une opération de restitution: des opérations de conversion 10 inverse; - un microcontrôleur 34 en charge du contrôle des opérations de stockage ou restitution.
On présente maintenant, en relation avec la figure 3B, un mode de réalisation particulier du module de contrôle 280 apparaissant dans le second exemple de réseau de 15 la figure 2B.
De même que dans le cas de la figure 3A, le module de contrôle 280 comprend un premier bloc d'interface, un second bloc d'interface, un module d'adaptation et un microcontrôleur, référencés ici 310, 320, 330 et 340 respectivement. Ce mode de réalisation se distingue de celui de la figure 3A uniquement en ce que le second bloc d'interface 320 assure une interface entre le module de contrôle 28 et le lien (par exemple implémentant une technologie propriétaire) 253 par l'intermédiaire duquel celui-ci est relié à l'unité centrale de commutation 24.
On décrit en détail par la suite les algorithmes exécutés par le module de contrôle 28, 280.
On rappelle maintenant, en relation avec la figure 4, le protocole SBP-2 de base, exécuté entre un initiateur SBP-2 ( initiator ) et une cible SBP-2 ( target ).
Après une phase de découverte de dispositif ( IEEE 1394 configuration ROM browsing ), l'initiateur connaît l'existence de cible(s), d'entrée d'unité logique ( Logical Unit entry ), d'entrée de numéro d'unité logique ( Logical Unit Number entry ), d'adresse de registre d'agent de gestion ( Management Agent register address ), etc. L'unité logique est par exemple un modèle d'équipement (par exemple un disque, un CDROM, une imprimante,...). Une cible comprend au moins une unité logique pouvant être adressée avec un numéro zéro d'unité logique ( LUN zero ). Des unités logiques supplémentaires peuvent être ajoutées, qui peuvent être adressées avec leurs numéros d'unité logique.
Etape 41: avant d'utiliser les services d'une cible, l'initiateur doit envoyer une requête de connexion ( login request ), dans laquelle il peut préciser si le numéro d'unité logique de la cible ( target's LUN ) peut être utilisé de façon exclusive ou non (c'est-à-dire si un accès multiple est autorisé ou non).
Etape 42: la réponse de connexion ( login response ) contient l'adresse de registre d'agent de bloc de commande ( Command Block Agent register address devant être utilisée pour les requêtes de services à envoyer à la cible pour ledit numéro d'unité logique.
Etape 43: l'initiateur construit des requêtes de services, afin que la cible effectue des actions (transfert de mémoire entre l'initiateur luimême ou un autre dispositif et le dispositif cible). Ces requêtes de services sont exprimées au moyen de blocs de requêtes d'opérations, appelés ci-après blocs ORB ( Operation Request Blocks ). L'initiateur alloue des blocs ORB correspondant aux transferts de mémoire devant être effectués par la cible, puis envoie la requête de service basée sur ces blocs ORB à la cible (registre CBA).
Etape 44: la cible traite les blocs ORB reçus et répond à la requête en initiant des transactions de lecture ou écriture IEEE 1394.
Etape 45: quand la requête de service a été traitée, la cible retourne un état à 1' initiateur.
On présente maintenant, en relation avec la figure 5, un mode de réalisation d'une structure de données utilisée dans la présente invention comme structure de premiers blocs de données. L'utilisation des premiers blocs de données possédant cette structure est discutée en détail dans la suite de la description.
La structure de chaque premier bloc de données comprend: un premier champ ( block identifier ) contenant un identifiant dudit 30 premier bloc au sein d'une séquence de premiers blocs. Il permet de réordonner les premiers blocs de données si nécessaire; un deuxième champ ( total size S ) contenant la longueur totale de la partie utile dudit premier bloc (taille mémoire, en octets, de la prochaine séquence de paquets isochrones) ; un troisième champ ( Isoch packets number ) contenant le nombre de paquet isochrones contenus dans la partie utile dudit premier bloc; un quatrième champ ( Isoch packets sequence ), correspondant à la partie utile dudit premier bloc et contenant une séquence de paquets isochrones (par exemple sous la forme d'une table de paquets isochrones et d'un pointeur mémoire associé).
On présente maintenant, en relation avec la figure 6, un algorithme d'initialisation, exécuté par le module de contrôle dans un mode de réalisation particulier du procédé selon l'invention de stockage et/ou restitution d'au moins un flux audio vidéo isochrone.
Suite à une réinitialisation du premier bus IEEE 1394 ( bus reset ) (référencé 29 ou 290 sur les figures 2A et 2B) compris dans le dispositif de stockage (27, 270), ou simplement quand le module de contrôle (28, 280) est prêt pour l'initialisation du mécanisme de stockage, le module de contrôle recueille des informations auprès des disques SBP-2 (D1,... Dn).
Tout d'abord (étape 61), le module de contrôle obtient des informations 20 générales relatives aux disques 1394 SBP-2, comme par exemple: - le débit (ou la vitesse) IEEE1394 maximal, obtenu à partir de paquets particuliers SelfID packets (voir norme IEEE 1394) ; - la taille maximale de paquet asynchrone, obtenue à partir de la mémoire de configuration 1394 ConfigROM (voir la norme ISO/IEC 13213:1994, Control and Status Register (CSR) Architecture for Microcomputer Buses ) ; - etc. Puis (étape 62), il obtient, à partir de la mémoire de configuration, des informations spécifiques aux dispositifs SBP-2 que constituent les disques SBP-2 30 (Dl,... Dn), comme par exemple: - l'adresse de registre d'agent de gestion ( Management Agent register address ) des cibles, utilisée par la suite pour envoyer des requêtes selon le protocole SBP-2; l'entrée de numéro d'unité logique ( Logical Unit Number entry ), qui 5 indique quel modèle de gestion de tâche est utilisé et le numéro d'unité logique (utilisé par la suite dans les transactions SBP-2) ; - etc. Enfin (étape 63), le module de contrôle utilise les informations obtenues pour initialiser des variables internes, et notamment: une valeur de taille mémoire maximale (appelée ci-après maxS ) pour les échanges avec les disques SBP-2 (D1,.
Dn)...DTD: On présente maintenant, en relation avec la figure 7, un algorithme d'établissement de connexion, exécuté par le module de contrôle au cours d'une opération de stockage de flux audio vidéo isochrone selon l'invention.
Cet algorithme est exécuté quand une connexion de flux doit être établie entre un terminal source (par exemple le terminal A, dans le cas de la figure 2A ou 2B) et le dispositif de stockage selon l'invention (27, 270), afin de stocker un flux audio vidéo sur le(s) disque(s) SBP-2 (D1,... Dn) compris dans ce dispositif de stockage.
Au sein du dispositif de stockage, il convient alors d'établir une connexion de flux entre le module de contrôle et le(s) disque(s) SBP-2 (D1,... Dn).
Avant d'utiliser un disque SBP-2 comme une cible SBP-2, le module de contrôle (qui agit comme initiateur SBP-2) envoie une requête de connexion ( login request ) à la cible SBP-2 (étape 71). Il est nécessaire de préciser la valeur de numéro d'unité logique (LUN) dans le cas où il peut y avoir plusieurs LUNs.
Puis, on détermine si la requête de connexion est acceptée (étape 72). Dans la négative, la cible SBP-2 ne peut pas être utilisée et on interrompt l'établissement de la connexion de flux (entre le terminal source et le dispositif de stockage) (étape 73). Dans l'affirmative, l'adresse de registre CBA (registre d'agent de bloc de commande) est retournée et l'établissement de la connexion de flux (entre le terminal source et le dispositif de stockage) peut être finalisée (étape 74). L'adresse de registre CBA sera utilisée ultérieurement pour envoyer à la cible SBP-2 des requêtes de services basées sur des blocs ORB.
Quand l'établissement de la connexion de flux a été réalisé correctement (condition de l'étape 75) (par exemple un contrôleur a mis à jour un registre dédié, compris dans le module de contrôle, la valeur du canal isochrone à écouter), la réception et le traitement (regroupement) de paquets isochrones peut commencer (étape 76). Ce regroupement des paquets isochrones est décrit en détail ci-dessous, en relation avec la figure 8.
On présente maintenant, en relation avec la figure 8, un algorithme de regroupement de paquets isochrones (détail de l'étape 76 de la figure 7), exécuté par le module de contrôle.
L'idée de base est de remplir des premiers blocs de données avec les paquets isochrones reçus par le module de contrôle. Les premiers blocs possèdent par exemple la structure particulière ( data structure ) décrite ci-dessus en relation avec la figure 5. Quand un premier bloc est plein, il est transmis à un disque SBP-2 (Dl,... Dn), selon un mode de transfert asynchrone, et stocké dans ce disque SBP-2. On utilise pour cela, conformément au protocole SBP-2, une requête de service basée sur des blocs ORB ( ORB service request ).
On suppose que pendant l'étape d'initialisation (voir figure 6), on alloue de la mémoire correspondant à une (ou plusieurs) structure(s) d'un premier bloc de données. Dans une variante, on alloue de la mémoire correspondant à plusieurs fois la structure d'un premier bloc de données, de façon à traiter simultanément plusieurs premiers blocs ou bien à optimiser la gestion de la mémoire en évitant allocation mémoire et libération mémoire successives.
Tout d'abord (étape 81), on obtient (ou on instancie s'il n'est pas déjà alloué) un premier bloc libre possédant la structure particulière ( data structure ) précitée, ainsi qu'un identifiant de bloc ( block identifier ) qui le cas échéant pourra être utilisé pour réordonner les blocs lors de leur traitements.
Puis (étape 82), on détermine si le paquet isochrone reçu peut être contenu dans la partie utile du premier bloc courant, de taille maximale déterminée maxS. En d'autres termes, on détermine si l'ajout de ce paquet isochrone à la séquence de paquets isochrones déjà contenus dans la partie utile du premier bloc courant n'implique pas que l'on aboutit à une séquence résultante de taille S supérieure à la taille maximale autorisée maxS.
Dans l'affirmative, le paquet isochrone reçu est ajouté à la séquence courante de paquets isochrones, dans la partie utile du premier bloc courant (étape 83) : la taille S de la séquence courante de paquets isochrones est augmentée de la taille du paquet isochrone reçu; - le nombre de paquets isochrones de la séquence courante est incrémenté d'une unité ; la séquence de paquets isochrones permet de mémoriser le début du nouveau paquet isochrone reçu (la mémoire peut être organisée sous la forme d'une table, d'une chaîne liée, une mémorisation contiguë, etc.).
Dans la négative, le premier bloc courant est considéré comme plein et le stockage du premier bloc courant dans un disque SBP-2 peut commencer (étape 84) et on revient à l'étape 81 (obtention d'un nouveau premier bloc, pour continuer le traitement des paquets isochrones reçus). Le stockage d'un premier bloc est décrit en détail ci-dessous, en relation avec la figure 9.
On présente maintenant, en relation avec la figure 9, un algorithme de stockage d'un premier bloc de données dans un disque dur SBP-2 (détail de l'étape 84 de la figure 8), exécuté par le module de contrôle.
Après qu'un premier bloc a été rempli (voir ci-dessus), il doit être stocké dans un disque dur SBP-2. Le module de contrôle (en tant qu'initiateur SBP-2) construit un bloc ORB (bloc de requêtes d'opérations, Operation Request Blocks ) et envoie une requête de service basée sur ce bloc ORB à la cible SBP-2 (disque SBP-2) (étape 91). La cible SBP-2 est responsable de l'exécution du transfert de mémoire demandé.
Quand un état de service est reçu (oui à la condition de l'étape 92) avant l'expiration d'une temporisation (non à la condition de l'étape 93) et est positif (oui à la condition de l'étape 94), alors le premier bloc est libéré pour un nouvel usage ultérieur (étape 95). Dans le cas d'un état négatif (transfert non exécuté correctement) (non à la condition de l'étape 94), un traitement adéquat est effectué (par exemple, une nouvelle tentative est effectuée ou, si le problème est grave, l'opération de stockage est définitivement arrêtée, ...) (étape 96) et le premier bloc est libéré pour un nouvel usage ultérieur (étape 95). Dans le cas de l'expiration de la temporisation (oui à la condition de l'étape 93), un traitement adéquat est effectué (par exemple une nouvelle tentative peut être effectuée) (étape 97) . Mais si l'expiration de la temporisation peut avoir un impact sur les performances du système (par exemple des contraintes de mémoire), il peut être décidé de stopper le transfert (étape 95).
On présente maintenant, en relation avec la figure 10, un algorithme de génération et d'envoi de paquets isochrones, exécuté par le module de contrôle au cours d'une opération de restitution de flux audio vidéo isochrone selon l'invention.
L'algorithme d'établissement de connexion, décrit ci-dessus dans le cas d'une opération de stockage, en relation avec la figure 7, doit aussi être exécuté dans le cas d'une opération de restitution. En d'autres termes, l'algorithme d'établissement de connexion est aussi exécuté quand une connexion de flux doit être établie entre le dispositif de stockage selon l'invention (27, 270) et un terminal destinataire (par exemple le terminal A, dans le cas de la figure 2A ou 2B), afin de transmettre au terminal destinataire un flux audio vidéo préalablement stocké sur le(s) disque(s) SBP-2 (D1,... Dn) compris dans le dispositif de stockage. De même que dans le cas d'une opération de stockage, il convient alors d'établir une connexion de flux entre le module de contrôle et le(s) disque(s) SBP-2 (D1,... Dn), au sein du dispositif de stockage.
Dans le cas d'une opération de restitution, l'algorithme d'établissement de connexion (non représenté) se distingue de celui décrit de la figure 7 (cas d'une opération de stockage) uniquement en ce que l'étape 76 est remplacée par une étape selon laquelle le traitement (reconstruction) et l'envoi de paquets isochrones peut commencer. On notera que cette étape est effectuée quand l'établissement de la connexion de flux a été réalisé correctement (condition de l'étape 75) (par exemple un contrôleur peut écrire dans un registre dédié, compris dans le module de contrôle, la valeur du canal isochrone sur lequel émettre).
C'est précisément cette reconstruction des paquets isochrones par le module de contrôle que l'on décrit maintenant en relation avec la figure 10.
Avant de commencer l'envoi de paquets isochrones à partir d'une mémoire de 30 travail, on s'assure que cette dernière contient suffisamment de paquets isochrones (c'est-à-dire de premiers blocs contenant ces paquets isochrones), de façon que le module de contrôle puisse envoyer un paquet isochrone à chaque cycle de traitement (de 125 js). La mémoire de travail ( working buffer memory ) est utilisée comme une mémoire cache dont la taille doit être adaptée en fonction de différents paramètres tels que le retard introduit par le temps nécessaire pour retrouver le contenu d'un disque SBP-2). Le nombre minimal requis de premiers blocs dans la mémoire de travail est fixé
à N dans la suite de la description.
La première étape 101 consiste donc à vérifier que la mémoire de travail contient au moins N premiers blocs de données (contenant eux-mêmes des paquets isochrones).
Si cette condition n'est pas vérifiée, on lance la lecture de la mémoire d'(au moins) un disque SBP-2 (étape 102, décrite en détail ci-après en relation avec la figure 11).
Si cette condition est vérifiée, on retrouve l'un des premiers blocs contenus dans la mémoire de travail (étape 103).
Tant que ce premier bloc n'est pas vide (réponse négative à la question de l'étape 104) (c'est-à-dire tant que tous les paquets isochrones qu'il contient n'ont pas été envoyés par le module de contrôle au terminal destinataire), on retrouve un paquet isochrone contenu dans le premier bloc et on le prépare avant l'envoi (étape 105). Ce traitement est effectué dans le même ordre que lors de l'opération de stockage. La préparation d'un paquet isochrone avant son envoi consiste par exemple à adapter, si nécessaire, l'information d'horodatage qu'il contient. Lors de l'événement de début de cycle suivant (condition de l'étape 106), le paquet isochrone est envoyé par le module de contrôle vers le terminal destinataire (étape 107).
Quand le premier bloc courant est vide (réponse positive à la question de l'étape 104), on revient à l'étape 101 On présente maintenant, en relation avec la figure 11, un algorithme de lecture et d'envoi de seconds blocs de données par un disque dur SBP-2 (détail de l'étape 102 de la figure 10), exécuté par le module de contrôle.
Comme décrit précédemment, il convient de retrouver des premiers blocs (qui eux-mêmes contiennent des paquets isochrones) dans une mémoire de travail (ou mémoire cache) du module de contrôle et cette mémoire de travail doit contenir suffisamment de premiers blocs (pour éviter une situation dans laquelle le module de contrôle n'a plus de paquets isochrones à envoyer au terminal destinataire). Par conséquent, la mémoire de travail doit être remplie régulièrement (par exemple quand elle contient moins de N premiers blocs). Pour cela, le module de contrôle demande à un disque SBP-2 de lui envoyer des seconds blocs de données, dont la taille peut différer de celle des premiers blocs de données.
Pour effectuer cette demande, le module de contrôle (en tant qu'initiateur SBP-2) construit un bloc ORB (bloc de requêtes d'opérations, Operation Request Blocks ) et envoie une requête de service basée sur ce bloc ORB à la cible SBP-2 (disque SBP-2) (étape 111). La cible SBP-2 est responsable de l'exécution du transfert de mémoire demandé.
Quand un état de service est reçu (oui à la condition de l'étape 112) avant l'expiration d'une temporisation (non à la condition de l'étape 113) et est positif (oui à la condition de l'étape 114), alors cela signifie que le transfert de mémoire (envoi d'un second bloc de données, du disque SBP-2 vers le module de contrôle) a été effectué correctement. Dans le cas d'un état négatif (transfert non exécuté correctement) (non à la condition de l'étape 114), un traitement adéquat est effectué (par exemple, une nouvelle tentative est effectuée ou, si le problème est grave, l'opération de restitution est définitivement arrêtée, ...) (étape 116). Dans le cas de l'expiration de la temporisation (oui à la condition de l'étape 113), un traitement adéquat est effectué (par exemple une nouvelle tentative peut être effectuée) (étape 117). Mais si l'expiration de la temporisation peut avoir un impact sur les performances du système (par exemple des contraintes de mémoire), il peut être décidé de stopper le transfert.
On présente maintenant, en relation avec la figure 12, la gestion de flux de données dans le cas d'opérations multi-flux dans un mode de réalisation particulier du 25 procédé selon l'invention de stockage et restitution de flux audio vidéo.
Par opérations multi-flux effectuées par le dispositif de stockage selon l'invention, on entend le fait qu'au moins deux flux sont traités simultanément par le module de contrôle compris dans le dispositif de stockage selon l'invention. Il est à noter que multi-flux peut être synonyme de multi-utilisateur, mais un même utilisateur peut aussi être amené à demander l'établissement de plusieurs flux, par exemple dans le cas d'un double traitement avec décalage temporel ( time-shifting ).
Voici une liste non exhaustive d'exemples d'opérations multi-flux: stockage d'un flux et restitution d'un flux (cas du time-shifting ) ; stockage d'un flux et restitution de plusieurs flux; - stockage de plusieurs flux, dans différentes zones de stockage du dispositif de stockage (comprises dans un ou plusieurs disque(s) SBP-2) ; - restitution de plusieurs flux, depuis différentes zones de stockage du dispositif de stockage (comprises dans un ou plusieurs disque(s) SBP-2) ; stockage de plusieurs flux, dans différentes zones de stockage du dispositif de stockage, et restitution de plusieurs flux, depuis différentes zones de stockage du dispositif de stockage; etc. Chacune des opérations de stockage ou restitution (décrites en détail ci-dessus) est effectuée autant de fois que nécessaire par le module de contrôle.
Ainsi, dans l'exemple de la figure 12, le module de contrôle effectue deux 15 opérations de stockage et deux opérations de restitutions.
On notera que dans cet exemple, la taille des seconds blocs de données (lus dans le(s) disque(s) SBP-2 et transmis vers le module de contrôle, lors de l'opération de restitution) est inférieure à la taille des premiers blocs de données (générés par le module de contrôle et transmis vers le(s) disque(s) SBP-2, lors de l'opération de stockage). Les seconds blocs sont représentés en pointillés.
La flexibilité éventuelle de la taille des premiers blocs et/ou de celle des seconds blocs permet d'optimiser l'utilisation des capacités des disques SBP-2. Typiquement, la taille des premiers blocs (maxS) peut légèrement varier en fonction de la taille des paquets isochrones (qui varie) et du nombre de paquets isochrones contenus dans un premier bloc.
On présente maintenant, en relation avec la figure 13, un algorithme de gestion d'une pluralités de disques durs SBP-2 au cours d'opérations de stockage dans un mode de réalisation particulier du procédé selon l'invention de stockage de flux audio vidéo.
Comme illustré sur les figures 2A et 2B, plusieurs disques SBP-2 peuvent être connectés et gérés par un même module de contrôle.
Il peut être judicieux de distribuer (par exemple de manière cyclique) les requêtes de services SBP-2 entre les différents disques SBP-2 (cibles SBP-2, de façon à réduire la charge de travail de chaque disque à un moment donné. Ceci est particulièrement intéressant dans le cas d'opérations multi-flux (voir discussion ci- dessus).
Dans l'exemple de la figure 13, le module de contrôle gère des disques SBP-2 de manière cyclique.
Après la phase de requête de connexion (login), effectuée pour chaque disque SBP-2, le module de contrôle est capable d'envoyer des requêtes de service basées sur des blocs ORB ( ORB service request ) à chacun des disques (en utilisant son adresse de registre CBA). Dans la séquence de disques à utiliser pour le flux à stocker, le premier disque est sélectionné (initialisation de la variable disque_courant ). (étape 131) On suppose en effet que les disques ont préalablement été triés (par exemple de 0 à N-1) selon une séquence qui est préférentiellement la même pour les opérations de stockage et de restitution d'un même flux. On peut modifier la séquence de disques pour chaque flux à stocker, de façon à ne pas solliciter le même disque simultanément pour deux flux. Par exemple, dans le cas où il y a deux flux à stocker simultanément, la séquence de disques pour le premier flux est 1, 2,... , N-1 et la séquence de disques pour le second flux est 2,... , N-1, 1.
Quand des premiers blocs de données sont prêts à être stockés (condition de l'étape 132), le module de contrôle envoie une requête de service basée sur un bloc ORB au disque sélectionné, de façon que ce dernier stocke un premier bloc de données (étape 133).
Puis, le disque suivant de la séquence de disques est utilisé pour stocker le premier bloc suivant, etc. (incrémentation de la variable disque_courant (étape 134) et retour à l'étape 132).
Un mécanisme inverse est utilisé lors de l'opération de restitution. On utilise alors préférentiellement la même séquence de disques que pour l'opération de stockage, de façon à éviter une étape de remise en ordre des premiers blocs (à partir de leur identifiant de séquence).
On présente maintenant, en relation avec la figure 14, un schéma bloc fonctionnel d'un mode de réalisation du module de contrôle apparaissant dans le premier exemple de réseau de la figure 2A et illustrant la mise en oeuvre d'un dispositif de stockage de type AV/C obtenu à partir de disque(s) SBP-2.
De même que dans le cas de la figure 3A, le module de contrôle 528 comprend un premier bloc d'interface, un second bloc d'interface, un module d'adaptation et un microcontrôleur, référencés ici 531, 532, 533 et 534 respectivement. On rappelle que sur le premier bus 529 (bus IEEE 1394), le mode de transfert asynchrone IEEE 1394 est utilisé pour communiquer avec les disques SBP-2.
Selon l'invention, le module de contrôle 534 comprend un sous-module 500 permettant d'émuler une interface de commande pour le dispositif de stockage conforme à un protocole de commande comme par exemple le protocole AV/C. Ainsi, à partir de tout autre périphérique IEEE 1394 connecté sur le second bus 521 (bus IEEE 1394), le dispositif de stockage comprenant les disques SBP-2 est finalement vu comme une unité de stockage AVIC, et donc des commandes AVIC peuvent lui être envoyées.
Pour ce faire, il est nécessaire de mettre en oeuvre au niveau du module de contrôle une interface de contrôle ainsi qu'une mémoire de configuration ( configuration ROM en anglais, selon le standard P1212 Draft 2.0, June 13, 2001 Draft Standard for a Control and Status Registers (CSR) Architecture for microcomputer buses ) qui soient conformes aux protocoles IEC 61883 et AV/C.
Le sous-module 500 est responsable de la mise en place de la mémoire de configuration ( configuration ROM ) pour le dispositif de stockage (initialisation, mise à jour en fonction des disques SBP-2 selon leur nombre et propriétés respectives,...) et du traitement des requêtes relatives aux accès à la mémoire de configuration. Par exemple, des entrées Instance Directory et Unit Directory sont créées dans la mémoire de configuration afin notamment de décrire la fonction (par exemple une unité de stockage ) et le type d'interface de contrôle (par exemple un protocole de commande de type AVIC ). Le sous-module 500 est également responsable de la mise en oeuvre des protocoles IEC 61883 et AV/C. Ainsi, le sous-module 500 implémente le nombre nécessaire de registre IEC 61883 afin de refléter les capacités du dispositif de stockage: par exemple deux registres iPCRs ( input Plug Control Registers ) et trois registres oPCRs ( output Plug Control Registers ) sont utilisés avec un disque SBP-2, ou bien quatre registres iPCRs et cinq registres oPCRs sont utilisés avec deux disques SBP-2, etc. Les capacités du dispositif de stockage peuvent être reflétées aussi par les formats des flux audio vidéo isochrones (MPEG2, DV, ...) qui peuvent être acceptés par ce dispositif de stockage.
Etant donné que le dispositif de stockage est vu comme un dispositif conforme au protocole AV/C, des commandes AV/C peuvent lui être transmises à partir d'un périphérique distant. Ces commandes permettent par exemple d'obtenir des informations sur les capacités du dispositif de stockage citées plus haut (formats audio vidéo acceptés, nombre de connexions ( plugs ), ...), d'établir des connexions, etc. Le sous- module 500 est également responsable de la gestion et de la mise à jour des capacités du dispositif de stockage. Ainsi ce sous-module peut changer dynamiquement le nombre de connexions ( plugs ) disponibles et les formats acceptables selon les connexions en cours. Par exemple, si le nombre de flux au format MPEG2 établis vers le dispositif de stockage (correspondant donc à l'utilisation d'un certain nombre de connexions ( plugs ) d'entrées au format MPEG2) fait que la bande passante disponible au niveau du bus IEEE 1394 interne au dispositif de stockage n'est plus suffisante pour le transport d'un flux supplémentaire de type par exemple DV, le sous-module supprime toutes les connexions ( plugs ) d'entrée ou de sortie correspondant au format DV. Ainsi, il n'est pas possible d'enregistrer ou de restituer un flux audio vidéo selon ce format vers/du dispositif de stockage.

Claims (62)

REVENDICATIONS
1. Procédé de stockage d'au moins un flux audio vidéo isochrone dans un dispositif de stockage (27; 270) comprenant un module de contrôle (28; 280) relié, via un premier réseau de communication (29; 290), à au moins une unité de stockage de données (D1,... Dn) présentant un mode de transfert asynchrone, chaque flux audio vidéo isochrone comprenant des paquets isochrones, caractérisé en ce que, pour chaque flux audio vidéo isochrone, le module de contrôle effectue les étapes suivantes: regroupement des paquets isochrones du flux audio vidéo isochrone dans des premiers blocs de données; - transmission des premiers blocs de données à ladite au moins une unité de stockage, selon ledit mode de transfert asynchrone, de façon que ladite au moins une unité de stockage stocke les premiers blocs de données.
2. Procédé de stockage selon la revendication 1, caractérisé en ce qu'il comprend en outre une étape de modification dynamique de la taille des premiers blocs, de façon à optimiser l'utilisation d'au moins une ressource.
3. Procédé de stockage selon la revendication 2, caractérisé en ce que ladite au moins une ressource optimisée est la capacité de ladite au moins une unité de stockage de données.
4. Procédé de stockage selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'étape de regroupement des paquets isochrones comprend les étapes suivantes: (a) on obtient un premier bloc de données libre, dit premier bloc courant; (b) pour chacun des paquets isochrones reçus successivement par le module de contrôle, on détermine s'il peut être ajouté à une séquence courante de paquets isochrones contenue dans une partie utile du premier bloc courant, ladite partie utile possédant une taille maximale prédéterminée (maxS) : * dans l'affirmative, le paquet isochrone reçu est inséré dans la partie utile du premier bloc courant, puis on effectue à nouveau l'étape (b) pour traiter le paquet isochrone reçu suivant; dans la négative, le premier bloc courant est considéré comme plein et on effectue à nouveau les étapes (a) et (b) pour remplir le premier bloc de données suivant.
5. Procédé de stockage selon la revendication 4 et l'une quelconque des revendications 2 et 3, caractérisé en ce que l'étape de modification dynamique de la taille des premiers blocs comprend une étape de modification de ladite taille maximale prédéterminée (maxS) de la partie utile des premiers blocs de données.
6. Procédé de stockage selon l'une quelconque des revendications 1 à 5, caractérisé en ce que chaque flux audio vidéo isochrone est transmis par un terminal source relié au dispositif de stockage via au moins un second réseau de communication (21).
7. Procédé de stockage selon la revendication 6, caractérisé en ce que les premier et second réseaux de communication (21, 29) sont des bus IEEE 1394, et en ce que le module de contrôle (28) constitue un pont homogène entre les premier et second réseaux de communication.
8. Procédé de stockage selon la revendication 6, caractérisé en ce que le second réseau de communication (22) est un réseau fédérateur auquel le terminal source est relié via un troisième réseau de communication (23i), en ce que les premier et troisième réseaux de communication sont des bus IEEE 1394, et en ce que le module de contrôle (280) constitue un pont hétérogène entre les premier et second réseaux de communication.
9. Procédé de stockage selon l'une quelconque des revendications 1 à 8, caractérisé en ce que le dispositif de stockage comprend une pluralité d'unités de stockage de données présentant un mode de transfert asynchrone, et en ce que les premiers blocs de données, résultant du regroupement de paquets isochrones compris dans un ou plusieurs flux audio vidéo isochrones, sont répartis entre ladite pluralité d'unités de stockage.
10. Procédé de stockage selon la revendication 9, caractérisé en ce que, pour un flux audio vidéo isochrone donné, les premiers blocs de données sont répartis parmi la pluralité d'unités de stockage selon une séquence prédéterminée d'unités de stockage.
11. Procédé de stockage selon la revendication 10, caractérisé en ce que, dans le cas où plusieurs flux audio vidéo isochrones sont stockés simultanément, on utilise une séquence d'unités de stockage distincte pour chacun des flux à stocker, de façon à ne pas solliciter une même unité de stockage simultanément pour plusieurs flux à stocker.
12. Procédé de restitution d'au moins un flux audio vidéo isochrone préalablement stocké dans un dispositif de stockage (27; 270) comprenant un module de contrôle (28; 280) relié, via un premier réseau de communication (29; 290), à au moins une unité de stockage de données (D1,... Dn) présentant un mode de transfert asynchrone, chaque flux audio vidéo isochrone comprenant des paquets isochrones, le stockage préalable étant tel que ladite au moins une unité de stockage stocke des premiers blocs de données regroupant des paquets isochrones du flux audio vidéo isochrone, caractérisé en ce que, pour chaque flux audio vidéo isochrone, le module de contrôle effectue les étapes suivantes: - il commande ladite au moins une unité de stockage afin qu'elle lise des seconds blocs de données et les lui transmette, selon ledit mode de transfert asynchrone; il retrouve des premiers blocs de données à partir des seconds blocs de données reçus; il retrouve des paquets isochrones à partir des premiers blocs de données retrouvés; il reconstruit le flux audio vidéo isochrone avec les paquets isochrones retrouvés.
13. Procédé de restitution selon la revendication 12, caractérisé en ce qu'il comprend en outre une étape de modification dynamique de la taille des seconds blocs, de façon à optimiser l'utilisation d'au moins une ressource.
14. Procédé de restitution selon la revendication 13, caractérisé en ce que ladite au moins une ressource optimisée est la capacité de ladite au moins une unité de stockage de données 15. Procédé de restitution selon l'une quelconque des revendications 12 à 14, caractérisé en ce que le module de contrôle met les premiers blocs retrouvés dans une mémoire temporaire de travail, et en ce que, si le nombre de premiers blocs contenus dans la mémoire temporaire de travail est inférieur à un nombre prédéterminé de premiers blocs, alors le module de contrôle commande ladite au moins une unité de stockage afin qu'elle lise des seconds blocs de données et les lui transmette, selon ledit mode de transfert asynchrone.
16. Procédé de restitution selon l'une quelconque des revendications 12 à 15, caractérisé en ce que chaque flux audio vidéo isochrone restitué est transmis à un terminal destinataire relié au dispositif de stockage via au moins un second réseau de communication.
17. Procédé de restitution selon la revendication 16, caractérisé en ce que les premier et second réseaux de communication sont des bus IEEE 1394, et en ce que le module de contrôle constitue un pont homogène entre les premier et second réseaux de communication.
18. Procédé de restitution selon la revendication 16, caractérisé en ce que le second réseau de communication est un réseau fédérateur auquel le terminal destinataire est relié via un troisième réseau de communication, en ce que les premier et troisième réseaux de communication sont des bus IEEE 1394, et en ce que le module de contrôle constitue un pont hétérogène entre les premier et second réseaux de communication.
19. Procédé de restitution selon l'une quelconque des revendications 12 à 18, caractérisé en ce que le dispositif de stockage comprend une pluralité d'unités de stockage de données présentant un mode de transfert asynchrone, et en ce que les seconds blocs de données sont lus dans ladite pluralité d'unités de stockage.
20. Procédé de restitution selon la revendication 19, caractérisé en ce que, pour un flux audio vidéo isochrone donné, les seconds blocs de données sont lus dans ladite pluralité d'unités de stockage selon une séquence prédéterminée d'unités de stockage.
21. Procédé de restitution selon la revendication 20, caractérisé en ce que la séquence selon laquelle les unités de stockage sont utilisées en lecture, pour restituer un flux audio vidéo isochrone donné, est la même que celle selon laquelle les unités de stockage ont préalablement été utilisées en écriture, pour stocker ledit flux audio vidéo isochrone donné.
22. Procédé de restitution selon l'une quelconque des revendications 20 et 21, caractérisé en ce que, dans le cas où plusieurs flux audio vidéo isochrones sont restitués simultanément, on utilise une séquence d'unités de stockage distincte pour chacun des flux à restituer, de façon à ne pas solliciter une même unité de stockage simultanément pour plusieurs flux à restituer.
23. Procédé de stockage selon l'une quelconque des revendications 1 à 11 et/ou de restitution selon l'une quelconque des revendications 12 à 22, caractérisé en ce que le module de contrôle effectue une étape d'émulation d'une interface de commande pour le dispositif de stockage conforme à un protocole de commande prédéterminé, de façon que le dispositif de stockage soit vu par d'autres appareils comme un dispositif conforme audit protocole de commande.
24. Procédé de stockage et/ou restitution selon la revendication 23, caractérisé en ce que l'étape d'émulation est mise en oeuvre avec une mémoire de configuration et/ou une interface de contrôle.
25. Procédé de stockage et/ou restitution selon la revendication 24, caractérisé en ce que l'étape d'émulation comprend une étape de présentation d'au moins certaines capacités du dispositif de stockage à travers la mémoire de configuration et/ou l'interface de contrôle.
26. Procédé de stockage et/ou restitution selon la revendication 25, caractérisé en ce que les capacités du dispositif de stockage présentées appartiennent au groupe comprenant: un nombre de flux audio vidéo isochrones pouvant être gérés simultanément par le dispositif de stockage; - des formats de flux audio vidéo isochrones gérés par le dispositif de stockage.
27. Procédé de stockage et/ou restitution selon l'une quelconque des revendications 23 à 26, caractérisé en ce que le protocole de commande prédéterminé est le protocole AV/C.
28. Procédé de stockage selon l'une quelconque des revendications 1 à 11 et/ou de restitution selon l'une quelconque des revendications 12 à 22, caractérisé en ce que 25 ladite au moins une unité de stockage est conforme au protocole SBP-2.
29. Procédé de stockage selon l'une quelconque des revendications 1 à 11 et/ou de restitution selon l'une quelconque des revendications 12 à 22, caractérisé en ce que le premier réseau de communication est un bus IEEE 1394, et en ce que le mode de transfert asynchrone est conforme au protocole défini dans la norme SBP-2, le module de contrôle agissant comme un initiateur ( initiator ) et ladite au moins une unité de stockage comme une cible ( target ).
30. Procédé de stockage selon l'une quelconque des revendications 1 à 11 et/ou restitution selon l'une quelconque des revendications 12 à 22, caractérisé en ce que chacun des premiers blocs de données possède une première structure comprenant: - un premier champ contenant un identifiant dudit premier bloc au sein d'une séquence de premiers blocs; - un deuxième champ contenant la longueur totale de la partie utile dudit premier bloc; - un troisième champ contenant le nombre de paquet isochrones contenus dans la partie utile dudit premier bloc; un quatrième champ correspondant à la partie utile dudit premier bloc et contenant une séquence de paquets isochrones.
31. Procédé de stockage selon l'une quelconque des revendications 1 à 11 et/ou de restitution selon l'une quelconque des revendications 12 à 22, caractérisé en ce qu'au moins certaines des unités de stockage sont des disques durs présentant un mode de 15 transfert asynchrone.
32. Module de contrôle (28; 280) compris dans un dispositif (27; 270) de stockage d'au moins un flux audio vidéo isochrone, le module étant destiné à être relié, au sein du dispositif de stockage et via un premier réseau de communication (29; 290), à au moins une unité de stockage de données (D1,... Dn) présentant un mode de transfert asynchrone, chaque flux audio vidéo isochrone comprenant des paquets isochrones, caractérisé en ce que le module de contrôle comprend: - des moyens de regroupement des paquets isochrones de chaque flux audio vidéo isochrone dans des premiers blocs de données; des moyens de transmission des premiers blocs de données à ladite au moins une unité de stockage, selon ledit mode de transfert asynchrone, de façon que ladite au moins une unité de stockage stocke les premiers blocs de données.
33. Module de contrôle selon la revendication 32, caractérisé en ce que les moyens de regroupement des paquets isochrones comprennent des moyens de remplissage de chaque premier bloc avec des paquets isochrones successifs, tant que la taille d'une séquence de paquets isochrones contenue dans une partie utile du premier bloc ne devient pas supérieure à une taille maximale prédéterminée (maxS). 10
34. Module de contrôle selon l'une quelconque des revendications 32 et 33, caractérisé en ce qu'il comprend en outre des moyens de modification dynamique de la taille des premiers blocs, de façon à optimiser l'utilisation d'au moins une ressource.
35. Module de contrôle selon la revendication 34, caractérisé en ce que ladite au moins une ressource optimisée est la capacité de ladite au moins une unité de stockage de données.
36. Module de contrôle selon la revendication 33 et l'une quelconque des revendications 34 et 35, caractérisé en ce que les moyens de modification dynamique de la taille des premiers blocs comprennent des moyens de modification de ladite taille maximale prédéterminée (maxS) de la partie utile des premiers blocs de données.
37. Module de contrôle selon l'une quelconque des revendications 34 à 36, caractérisé en ce que chaque flux audio vidéo isochrone est transmis par un terminal source relié au dispositif de stockage via au moins un second réseau de communication.
38. Module de contrôle selon la revendication 37, caractérisé en ce que les premier et second réseaux de communication sont des bus IEEE 1394, et en ce que le module de contrôle constitue un pont homogène entre les premier et second réseaux de communication.
39. Module de contrôle selon la revendication 37, caractérisé en ce que le second réseau de communication est un réseau fédérateur auquel le terminal source est relié via un troisième réseau de communication, en ce que les premier et troisième réseaux de communication sont des bus IEEE 1394, et en ce que le module de contrôle constitue un pont hétérogène entre les premier et second réseaux de communication.
40. Module de contrôle selon l'une quelconque des revendications 32 à 39, le dispositif de stockage comprenant une pluralité d'unités de stockage de données présentant un mode de transfert asynchrone, caractérisé en ce que le module de contrôle comprend des moyens de répartition des premiers blocs de données, résultant du regroupement de paquets isochrones compris dans un ou plusieurs flux audio vidéo isochrones, entre ladite pluralité d'unités de stockage.
41. Module de contrôle selon la revendication 40, caractérisé en ce que les moyens de répartition sont tels que, pour un flux audio vidéo isochrone donné, les premiers blocs de données sont répartis parmi la pluralité d'unités de stockage selon une séquence prédéterminée d'unités de stockage.
42. Module de contrôle selon la revendication 41, caractérisé en ce que, dans le cas où plusieurs flux audio vidéo isochrones sont stockés simultanément, les moyens de répartition utilisent une séquence d'unités de stockage distincte pour chacun des flux à stocker, de façon à ne pas solliciter une même unité de stockage simultanément pour plusieurs flux à stocker.
43. Module de contrôle (28; 280) compris dans un dispositif (27; 270) de stockage d'au moins un flux audio vidéo isochrone, le module étant destiné à être relié, au sein du dispositif de stockage et via un premier réseau de communication (29; 290), à au moins une unité de stockage de données présentant un mode de transfert asynchrone, chaque flux audio vidéo isochrone comprenant des paquets isochrones, caractérisé en ce qu'il comprend: des moyens de commande de ladite au moins une unité de stockage afin que, pour chaque flux audio vidéo isochrone à restituer, elle lise des seconds blocs de données et les lui transmette, selon ledit mode de transfert asynchrone; des moyens permettant de retrouver des premiers blocs de données à partir des seconds blocs de données reçus; - des moyens permettant de retrouver des paquets isochrones à partir des premiers 20 blocs de données retrouvés; - des moyens de reconstruction du flux audio vidéo isochrone avec les paquets isochrones retrouvés.
46. Module de contrôle selon la revendication 43, caractérisé en ce qu'il comprend en outre des moyens de modification dynamique de la taille des seconds blocs, de façon 25 à optimiser l'utilisation d'au moins une ressource.
47. Module de contrôle selon la revendication 44, caractérisé en ce que ladite au moins une ressource optimisée est la capacité de ladite au moins une unité de stockage de données.
48. Module de contrôle selon l'une quelconque des revendications 43 à 45, caractérisé en ce qu'il comprend: - une mémoire temporaire de travail dans laquelle sont mis les premiers blocs retrouvés; - des moyens de détection de ce que le nombre de premiers blocs contenus dans la mémoire temporaire de travail est inférieur à un nombre prédéterminé de premiers blocs; - des moyens, activés en cas de détection positive par les moyens de détection, de commande de ladite au moins une unité de stockage afin qu'elle lise des seconds blocs de données et les lui transmette, selon ledit mode de transfert asynchrone.
47. Module de contrôle selon l'une quelconque des revendications 43 à 46, caractérisé en ce que chaque flux audio vidéo isochrone restitué est transmis à un terminal destinataire relié au dispositif de stockage via au moins un second réseau de communication.
48. Module de contrôle selon la revendication 47, caractérisé en ce que les premier et second réseaux de communication sont des bus IEEE 1394, et en ce que le module de contrôle constitue un pont homogène entre les premier et second réseaux de communication.
49. Module de contrôle selon la revendication 47, caractérisé en ce que le second réseau de communication est un réseau fédérateur auquel le terminal source est relié via un troisième réseau de communication, en ce que les premier et troisième réseaux de communication sont des bus IEEE 1394, et en ce que le module de contrôle constitue un pont hétérogène entre les premier et second réseaux de communication.
50. Module de contrôle selon l'une quelconque des revendications 43 à 49, le dispositif de stockage comprenant une pluralité d'unités de stockage de données présentant un mode de transfert asynchrone, caractérisé en ce que les seconds blocs de données sont lus dans ladite pluralité d'unités de stockage.
51. Module de contrôle selon la revendication 50, caractérisé en ce qu'il comprend des moyens de commande de lecture tels que, pour un flux audio vidéo isochrone donné, les seconds blocs de données sont lus dans ladite pluralité d'unités de stockage selon une séquence prédéterminée d'unités de stockage.
52. Module de contrôle selon la revendication 51, caractérisé en ce que les moyens de commande de lecture sont tels que la séquence selon laquelle les unités de stockage sont utilisées en lecture, pour restituer un flux audio vidéo isochrone donné, est la même que celle selon laquelle les unités de stockage ont préalablement été utilisées en écriture, pour stocker ledit flux audio vidéo isochrone donné.
53. Module de contrôle selon l'une quelconque des revendications 50 et 51, caractérisé en ce que les moyens de commande de lecture sont tels que, dans le cas où plusieurs flux audio vidéo isochrones sont restitués simultanément, les moyens de commande de lecture utilisent une séquence d'unités de stockage distincte pour chacun des flux à restituer, de façon à ne pas solliciter une même unité de stockage simultanément pour plusieurs flux à restituer.
54. Module de contrôle selon l'une quelconque des revendications 32 à 42 et/ou l'une quelconque des revendications 43 à 53, caractérisé en ce qu'il comprend des moyens d'émulation d'une interface de commande pour le dispositif de stockage conforme à un protocole de commande prédéterminé, de façon que le dispositif de stockage soit vu par d'autres appareils comme un dispositif conforme audit protocole de commande.
55. Module de contrôle selon la revendication 54, caractérisé en ce que les moyens d'émulation comprennent une mémoire de configuration et/ou une interface de contrôle.
56. Module de contrôle selon l'une quelconque des revendications 54 et 55, caractérisé en ce que les moyens d'émulation comprennent des moyens de présentation d'au moins certaines capacités du dispositif de stockage, à travers la mémoire de configuration et/ou l'interface de contrôle.
57. Module de contrôle selon la revendication 56, caractérisé en ce que les capacités du dispositif de stockage présentées par les moyens de présentation appartiennent au groupe comprenant: un nombre de flux audio vidéo isochrones pouvant être gérés simultanément par le dispositif de stockage; des formats de flux audio vidéo isochrones gérés par le dispositif de stockage.
58. Module de contrôle selon l'une quelconque des revendications 54 à 57, caractérisé en ce que le protocole de commande prédéterminé est le protocole AV/C.
59. Module de contrôle selon l'une quelconque des revendications 32 à 42 et/ou l'une quelconque des revendications 43 à 53, caractérisé en ce que ladite au moins une unité de stockage est conforme au protocole SBP-2.
60. Module de contrôle selon l'une quelconque des revendications 32 à 42 et/ou l'une quelconque des revendications 43 à 53, caractérisé en ce que le premier réseau de communication est un bus IEEE 1394, et en ce que le mode de transfert asynchrone est conforme au protocole défini dans la norme SBP-2, le module de contrôle agissant comme un initiateur ( initiator ) et ladite au moins une unité de stockage comme une cible ( target ).
61. Module de contrôle selon l'une quelconque des revendications 32 à 42 et/ou l'une quelconque des revendications 43 à 53, caractérisé en ce que chacun des premiers blocs de données possède une première structure comprenant: - un premier champ contenant un identifiant dudit premier bloc au sein d'une séquence de premiers blocs; - un deuxième champ contenant la longueur totale de la partie utile dudit premier bloc; - un troisième champ contenant le nombre de paquet isochrones contenus dans la partie utile dudit premier bloc; - un quatrième champ correspondant à la partie utile dudit premier bloc et contenant une séquence de paquets isochrones.
62. Module de contrôle selon l'une quelconque des revendications 32 à 42 et/ou l'une quelconque des revendications 43 à 53, caractérisé en ce qu'au moins certaines des unités de stockage sont des disques durs présentant un mode de transfert asynchrone.
63. Programme d'ordinateur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes du procédé selon l'une quelconque des revendications 1 à 31, lorsque ledit programme est exécuté sur un ordinateur.
FR0314274A 2003-12-04 2003-12-04 Procede et systeme de stockage et/ou restitution d'au moins un flux audio video isochrone dans/depuis un dispositif de stockage comprenant au moins une unite de stockage asynchrone Expired - Fee Related FR2863437B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0314274A FR2863437B1 (fr) 2003-12-04 2003-12-04 Procede et systeme de stockage et/ou restitution d'au moins un flux audio video isochrone dans/depuis un dispositif de stockage comprenant au moins une unite de stockage asynchrone

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0314274A FR2863437B1 (fr) 2003-12-04 2003-12-04 Procede et systeme de stockage et/ou restitution d'au moins un flux audio video isochrone dans/depuis un dispositif de stockage comprenant au moins une unite de stockage asynchrone

Publications (2)

Publication Number Publication Date
FR2863437A1 true FR2863437A1 (fr) 2005-06-10
FR2863437B1 FR2863437B1 (fr) 2008-10-31

Family

ID=34586319

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0314274A Expired - Fee Related FR2863437B1 (fr) 2003-12-04 2003-12-04 Procede et systeme de stockage et/ou restitution d'au moins un flux audio video isochrone dans/depuis un dispositif de stockage comprenant au moins une unite de stockage asynchrone

Country Status (1)

Country Link
FR (1) FR2863437B1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0695062A2 (fr) * 1994-07-25 1996-01-31 Microsoft Corporation Procédé et système pour combiner des données de plusieurs serveurs
FR2831745A1 (fr) * 2001-10-31 2003-05-02 Canon Kk Procede d'etablissement d'une connexion de flux de donnees isochrone impliquant la traversee d'un reseau commute, noeuds d'entree et de sortie correspondants
US20030154246A1 (en) * 2001-12-18 2003-08-14 Ville Ollikainen Server for storing files

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0695062A2 (fr) * 1994-07-25 1996-01-31 Microsoft Corporation Procédé et système pour combiner des données de plusieurs serveurs
FR2831745A1 (fr) * 2001-10-31 2003-05-02 Canon Kk Procede d'etablissement d'une connexion de flux de donnees isochrone impliquant la traversee d'un reseau commute, noeuds d'entree et de sortie correspondants
US20030154246A1 (en) * 2001-12-18 2003-08-14 Ville Ollikainen Server for storing files

Also Published As

Publication number Publication date
FR2863437B1 (fr) 2008-10-31

Similar Documents

Publication Publication Date Title
FR2804812A1 (fr) Procede et dispositif de communication entre un premier et un deuxieme reseau
EP2230612A1 (fr) Génération de recommandations pour un serveur de contenus
FR2824434A1 (fr) Procede de diffusion d'un paquet de donnees au sein d'un reseau commute, base sur un calcul optimise de l'arbre de recouvrement
FR2884943A1 (fr) Procede de gestion de commande au sein d'un reseau de communication, dispositif de controle, produit programme d'ordinateur et moyen de stockage correspondants
WO2008081121A2 (fr) Procede et dispositif de communication
FR2980662A1 (fr) Methode d'enregistrement d'un contenu dans un fichier sur un serveur et dispositif correspondant
FR2911744A1 (fr) Procede de gestion de l'acces a au moins un contenu et/ou au moins un service, produit programme d'ordinateur, moyen de stockage et dispositif d'acces correspondants
FR2863437A1 (fr) Procede et systeme de stockage et/ou restitution d'au moins un flux audio video isochrone dans/depuis un dispositif de stockage comprenant au moins une unite de stockage asynchrone
WO1999056435A1 (fr) Procede de gestion d'objets dans un reseau de communication et dispositif de mise en oeuvre
EP0792071B1 (fr) Dispositif de décodage de signaux de type MPEG2
FR2848056A1 (fr) Procedes d'insertion et de traitement d'informations pour la synchronisation d'un noeud destinataire a un flux de donnees traversant un reseau de base d'un reseau heterogene, et noeuds correspondants
FR2816146A1 (fr) Procede et dispositif de gestion d'un reseau de communication
FR2863438A1 (fr) Procede et systeme de stockage et/ou restitution d'au moins un flux de donnees audio video isochrones dans/depuis un dispositif de stockage distribue
FR2827995A1 (fr) Procede et dispositif de gestion de memoire
EP2577915B1 (fr) Partage d'informations de contexte de restitution entre dispositifs de pilotage
FR2828357A1 (fr) Procede de traitement de signaux de telecommande au sein d'un reseau audiovisuel domestique, signal, dispositifs et programme d'ordinateur correspondants
EP3235255A1 (fr) Dispositif et procede de gestion des priorites pour le telechargement de contenus multimedia
FR2879780A1 (fr) Procede de restriction de l'acces a au moins un contenu, produit programme d'ordinateur et dispositif recepteur correspondants
FR2863436A1 (fr) Procede et systeme de stockage et/ou de restitution d'un flux de donnees audio video au sein d'un reseau de communication heterogene
FR2802740A1 (fr) Procede et dispositif de communication entre deux noeuds d'interconnexion connectes a deux bus de communication
EP4297409A1 (fr) Procédé de gestion de la lecture d'un contenu multimédia.
FR2828355A1 (fr) Procede d'apprentissage de signaux de telecommande au sein d'un reseau audiovisuel domestique, signal, dispositifs et programme d'ordinateur correspondants
FR2906097A1 (fr) Procedes d'echange de donnees securises, produit programme d'ordinateur, moyen de stockage et dispositifs correspondants.
FR2868653A1 (fr) Procede et systeme de gestion du stockage de contenus dans un reseau en fonction de profils d'utilisateurs et d'unites de stockage
FR2823041A1 (fr) Procede, application, dispositifs et modules de gestion de paquets de donnees dans un noeud de communication

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 13

PLFP Fee payment

Year of fee payment: 14

PLFP Fee payment

Year of fee payment: 15

PLFP Fee payment

Year of fee payment: 17

PLFP Fee payment

Year of fee payment: 18

PLFP Fee payment

Year of fee payment: 19

ST Notification of lapse

Effective date: 20230808