FR 2980662 A1 20130329 FR 1158633 A 20110927 Domaine technique de l'invention La présente invention se rapporte au domaine de la distribution de contenu en général et plus particulièrement à la mise à disposition sur un serveur d'un réseau local d'un contenu diffusé. Arrière-plan technologique de l'invention Les réseaux locaux actuels permettent l'interconnexion d'équipements variés tels que, par exemple, des ordinateurs, des dispositifs de stockage de données, des dispositifs de restitutions audio et / ou vidéo, des dispositifs récepteurs de données, des imprimantes, des routeurs, des téléphones fixes ou portables, des assistants personnels et des interfaces de communications. Cette capacité d'interconnexion d'équipements proches et mettant en oeuvre des fonctions parfois complémentaires amène un besoin croissant d'interopérabilité entre des équipements connectés à un même réseau. L'interopérabilité permet à des équipements de communiquer entre eux et de mettre à la disposition d'un utilisateur des fonctionnalités tout en garantissant une simplicité de mise en oeuvre. Par exemple, il est pratique de pouvoir connecter une imprimante à un réseau local et de pouvoir imprimer un document depuis un ordinateur connecté au même réseau sans avoir à configurer au préalable un ensemble de paramètres utiles à l'impression. Pour cela, il existe des standards d'interopérabilité qui, mis en oeuvre, permettent la détection automatique d'équipements après connexion à un réseau et la communication à d'autres équipements de leurs caractéristiques telles que par exemple leur marque, modèle, fonction principale, capacité ou encore des services qui peuvent être mis en oeuvre par leur biais. L'un des standard d'interopérabilité est uPnP (de l'anglais « universal plug and play » qui signifie « branchement et utilisation universelle » en français ; UPnP est défini par un ensemble de documents disponibles à l'adresse http://upnp.org/). UPnP est un standard qui a pour but de permettre à des équipements de se connecter aisément à un réseau local et de simplifier leur mise en oeuvre sur le réseau. Les équipements compatibles avec UPnP permettent notamment le partage de fichiers, la communication et l'échange de données pour des applications utilitaires ou de divertissement. UPnP permet l'interopérabilité des équipements avec une grande facilité pour l'utilisateur en définissant et en publiant les protocoles de commande UPnP qui s'appuient sur les standards de communications usuels des réseaux. UPnP AV est la partie du standard qui traite des aspects audio et vidéo. La version courante de UPnP AV est UPnP AV :4. Avec UPnP, il est possible de voir depuis un ordinateur, par exemple, des fichiers stockés sur un espace de stockage dans un équipement distant et qui vient d'être connecté sur le même réseau local que l'ordinateur, sans avoir à effectuer de configuration de l'un ou l'autre des équipements. De la même façon, il est possible de lancer la restitution d'un contenu audio/vidéo stocké dans un fichier enregistré sur un espace de stockage d'un dispositif distant, tel que, par exemple un disque dur, depuis un dispositif de restitution, tel que par exemple un téléviseur compatible avec le format du contenu, dès lors que les deux équipements ont été connectés à un même réseau local et sans configuration autre. Dans le cas où des fichiers distincts, stockés sur un disque dur, contiennent des composantes distinctes d'un même contenu audiovisuel, par exemple, UPnP permet de synchroniser leurs restitutions respectives sur un ou plusieurs dispositifs de restitution. Le même contenu peut être un programme de télévision et les composantes sont par exemple l'audio et la vidéo ou les vidéos correspondant à deux vues différentes d'une même scène. La synchronisation est possible si les composantes contiennent chacune des informations temporelles liées à leurs restitutions et que les équipements partagent une horloge commune. Le partage d'une horloge commune s'applique aux équipements connectés à un même réseau local. L'horloge commune du réseau local est communément appelée « wall dock » (de l'anglais, et qui signifie « horloge murale »). Des méthodes d'enregistrement de contenu, permettent la restitution de ce contenu à partir d'un ou de plusieurs fichiers stockés sur un serveur local, la restitution étant par exemple spécifiée selon la norme UPnP. En revanche, ces méthodes présentent l'inconvénient de ne pas permettre un accès à du contenu diffusé, tel que par exemple des contenus audiovisuels transmis par la TNT (de Télévision Numérique Terrestre), par le satellite, ou encore la diffusion en multicast sur un réseau large bande. Description générale de l'invention La présente invention permet de résoudre au moins un des inconvénients de l'art antérieur ; en particulier, elle vise à permettre l'enregistrement d'un flux diffusé de données sur un serveur, l'enregistrement étant adapté à une restitution de contenu par exemple selon des normes du type UPnP AV :4. Plus particulièrement l'invention concerne une méthode d'enregistrement d'un contenu dans un fichier sur un serveur. Avantageusement elle comprend les étapes de réception, depuis un canal de diffusion, d'un contenu transmis, le contenu transmis comprenant des estampilles temporelles, les estampilles temporelles indiquant le temps écoulé depuis le début du contenu ; de calcul d'au moins une information temporelle de restitution à partir d'au moins une des estampilles temporelles et d'une horloge de référence, l'horloge de référence étant une référence temporelle d'un réseau local ; d'enregistrement d'au moins une partie du contenu dans un fichier sur le serveur, d'enregistrement d'au moins une information temporelle de restitution. Selon un mode de réalisation de l'invention, la méthode comprend en outre une étape de restitution dont l'instant de début dépend de l'information temporelle de restitution. Selon un mode de réalisation de l'invention, l'étape de restitution ne peut débuter avant une heure définie par l'information temporelle de restitution, le contenu étant indisponible avant heure définie. Selon un mode de réalisation de l'invention, l'étape de restitution débute à une heure définie l'information temporelle de restitution. Selon un mode de réalisation de l'invention, l'étape de restitution comprend une étape de transmission du fichier vers au moins un destinataire à une heure définie par l'information temporelle de restitution. Selon un mode de réalisation de l'invention, l'étape de restitution comprend une étape de transmission du fichier vers au moins un destinataire suite à une réception d'une requête de transmission d'au moins une partie du contenu. Selon un mode de réalisation de l'invention, l'étape de calcul de 25 l'information temporelle de restitution dépend d'une quantité d'espace disponible pour l'enregistrement du contenu. Selon un mode de réalisation de l'invention, l'étape d'enregistrement d'au moins une partie du contenu dans un fichier utilise un 30 fichier tampon selon une méthode de buffer circulaire. Selon un mode de réalisation de l'invention, le fichier de serveur contient la totalité du contenu après sa réception. Selon un mode de réalisation de l'invention, le canal de diffusion est de type bidirectionnel à large bande ; Selon un mode de réalisation de l'invention, le serveur est un serveur de média local compatible avec le standard d'interopérabilité Universal Plug and Play AV. Selon un mode de réalisation de l'invention, l'information temporelle de restitution est inscrite dans un champ d'information d'un service de description de contenu indiquant un paramètre d'heure de début prévue (ScheduledStartTime). Selon un mode de réalisation de l'invention, l'information temporelle de restitution est accessible à un équipement connecté au serveur dans un service de description de contenu. 20 L'invention concerne également un dispositif d'enregistrement d'un contenu dans un fichier. Le dispositif comprend une interface d'entrée pour recevoir un contenu transmis comprenant des estampilles temporelles, les estampilles temporelles indiquant le temps écoulé depuis le début du contenu ; un module de calcul d'au moins une information temporelle de 25 restitution à partir d'au moins une des estampilles temporelles et d'une horloge de référence, l'horloge de référence étant une référence temporelle d'un réseau local ; un module d'enregistrement adapté à enregistrer le contenu transmis dans un fichier et à enregistrer l'information temporelle de restitution. 30 Selon un mode de réalisation de l'invention, le dispositif comprend un module de restitution adapté à restituer le fichier, en fonction de l'information temporelle de restitution. Avantageusement, le dispositif 15 comprend un module d'inscription de la au moins une information temporelle de restitution dans un champ d'information d'un service de description de contenu indiquant un paramètre d'heure de début prévue. Brève description des figures L'invention sera mieux comprise et illustrée au moyen des exemples suivants de réalisation et de mise en oeuvre, nullement limitatifs, en référence aux figures annexées sur lesquelles : - la figure 1 est un schéma de principe d'un réseau local domestique connecté à un réseau étendu par l'intermédiaire d'une passerelle réseau, selon un mode de réalisation de l'invention. - la figure 2 illustre une passerelle réseau comprenant un serveur de média selon un mode de réalisation de l'invention. - La figure 3 illustre le serveur de média de la passerelle réseau selon un mode de réalisation de l'invention. - La figure 4 illustre temporellement la réception d'un contenu diffusé en multicast et le téléchargement d'un fichier en vue d'une restitution synchrone. - La figure 5 est un diagramme illustrant les étapes de la méthode. Sur les figures 1 à 3, les modules représentés sont des unités fonctionnelles, qui peuvent ou non correspondre à des unités physiquement distinguables. Par exemple, ces modules ou certains d'entre eux peuvent être regroupés dans un unique composant, ou constituer des fonctionnalités d'un même logiciel. A contrario, certains modules peuvent éventuellement être composés d'entités physiques séparées. Description d'une forme de réalisation préférée de l'invention Le mode de réalisation se place dans le cadre d'un réseau local domestique connecté à un réseau étendu par l'intermédiaire d'une passerelle réseau (encore appelée Gateway en anglais), mais l'invention n'est pas limitée à cet environnement particulier and peut s'appliquer au sein d'autres environnements. La Figure 1 représente un réseau local domestique 2 connecté à un réseau étendu 3, par l'intermédiaire d'une passerelle réseau 1. Le réseau étendu 3 est bidirectionnel à large bande et communément appelé Internet. Le réseau local domestique est un réseau Ethernet (ISO/IEC 8802-3) selon la mode de réalisation de l'invention bien connu de l'homme du métier et comprenant des connections filaires. Selon un autre mode de réalisation le réseau local contient des connections sans-fil telles que, par exemple, décrites dans les normes de transmission sans fil IEEE802.11. Différents équipements sont connectés au réseau local domestique 2. Ces équipements sont la passerelle réseau 1, un ordinateur personnel 5 ainsi que deux dispositifs de restitution 9 et 4. Les dispositifs de restitution 9 et 4 sont des téléviseurs comprenant chacun une interface de connexion réseau Ethernet pour recevoir un flux numérique transportant un contenu audiovisuel et le restituer sous forme d'affichage d'une vidéo et de son. La passerelle réseau 1 comprend un modem et un routeur permettant la connexion du réseau local domestique 2 à internet et l'accès à internet et aux services connexes tels que la téléphonie, la télévision et la vidéo à la demande pour l'abonné, par ailleurs utilisateur du réseau local 30 domestique 2. Un diffuseur de contenu 7 est également connecté au réseau étendu 3 et permet la diffusion de contenus audiovisuels encodés par l'encodeur 8 sur le réseau étendu 3. La diffusion des contenus audiovisuels est réalisée selon un mode de transmission multicast. Aussi, un dispositif récepteur capable de recevoir un flux de données multicast peut s'abonner à un flux de diffusion multicast transmis par le diffuseur de contenu 7. Un tel dispositif peut être, par exemple, l'ordinateur personnel 5 ou la passerelle réseau 1. Un serveur de contenu 6 est également connecté au réseau local étendu 3. Le serveur de contenu donne l'accès, à travers le réseau étendu 3, à des fichiers de contenu audiovisuels encodés par l'encodeur 8. L'ordinateur personnel 5 connecté au réseau local domestique 2 peut télécharger un fichier et le sauvegarder sur une unité de stockage du réseau local 2. Il est ainsi possible, pour un dispositif connecté au réseau local domestique 2, de recevoir un flux de données multicast transportant un contenu audiovisuel diffusé par le diffuseur de contenu 7 et de télécharger un contenu audiovisuel sous forme de fichier depuis le serveur de contenu 6 aux fins de le sauvegarder sur une unité de stockage connecté au réseau local domestique 2. Les contenus audiovisuels ainsi disponibles sous forme de fichiers et peuvent comprendre des références temporelles communes puisque les contenus ont été encodés par l'encodeur 8, qu'ils soient stockés sur le serveur de contenus 6 ou diffusés par le diffuseur de contenu 7. La figure 2 représente l'architecture globale de la passerelle réseau 1 selon un mode de réalisation de l'invention. La passerelle réseau 1 comprend un modem / routeur 12 pour l'interconnexion du réseau local 2 et du réseau étendu 3. La passerelle 1 comprend en outre un serveur local 13 connecté au réseau local 2. Le serveur local 13 est compatible avec le standard d'interopérabilité UPnP AV :4 et permet le stockage de fichiers et l'accessibilité à ces fichiers depuis des équipements connectés au réseau local domestique 2. Le partage des fichiers contenus sur le serveur local 13 est ainsi rendu possible. L'architecture du système représenté permet la consultation des sites accessibles par internet, représenté par le réseau étendu 3 depuis l'ordinateur personnel 5 connecté au réseau local domestique 2. Il est dès lors possible d'accéder au serveur de contenu 6 connecté au réseau étendu 3 depuis l'ordinateur personnel 5. Ainsi, un utilisateur de l'ordinateur personnel peut effectuer le téléchargement de fichiers disponibles sur le serveur de contenu 6 vers l'ordinateur personnel 5 et la sauvegarde des fichiers ainsi téléchargés sur le serveur local 13 de la passerelle 1. Le serveur local 13 comprend une unité de sauvegarde représentée figure 2 et accessible depuis le réseau local domestique 3. La Figure 3 illustre le serveur local 13 de la passerelle réseau 1. Le serveur local 13 comprend une interface de connexion à un réseau local 131 pour la connexion au réseau local domestique 2. Le serveur local comprend également une unité de calcul 132 connectée à l'interface 131 et une unité de sauvegarde 133 connectée à l'unité de calcul 132. L'interface 131 est de type bidirectionnelle, permettant la réception et l'émission de données vers et depuis l'unité de sauvegarde 133 à travers l'unité de calcul 132. L'ensemble des opérations de gestion, de contrôle et de configurations de l'interface réseau 131, de l'unité de calcul 132 et de l'unité de sauvegarde 133 est réalisé par l'unité de contrôle et de traitement 134 par l'intermédiaire du bus de contrôle 135. L'unité de contrôle et de traitement 134 comprend un microcontrôleur et des mémoires associées (non représentés) qui permettent l'exécution des routines utiles à la mise en oeuvre des fonctions du serveur local 13. L'unité de sauvegarde 133 comprend un disque dur et un contrôleur de disque dur qui peut être configuré par l'unité de contrôle 134. L'unité de contrôle 134 met on oeuvre les services et fonctions spécifiés par le standard d'interopérabilité UPnP AV :4. Le serveur local 13 est compatible avec les spécifications UPnP AV :4 et est vu comme un Media Server tel que défini par les spécificités et l'ensemble des protocoles décrits dans UPnP AV :4. Selon le mode de réalisation de l'invention, une application cliente exécutée par l'ordinateur personnel 5 permet de détecter les flux multicast diffusés par le diffuseur de contenus 7 et de proposer à l'utilisateur le stockage d'un flux multicast par le serveur local 13 sous forme de fichier comprenant un contenu audiovisuel. Le fichier ainsi stocké est disponible pour un dispositif de restitution connecté au réseau local 2. Le standard UPnP AV :4 définit un MediaServer (de l'anglais, et qui signifie serveur de média), un Media Renderer (de l'anglais et qui signifie restituteur de média) et un Control Point (de l'anglais et qui signifie point de contrôle). Selon UPnP, le Control Point communique avec les Media Server selon des protocoles établis qui lui permettent, entre autres, de recenser les fichiers présents sur le Media Server et d'accéder à un descripteur de contenus (CDS, de l'anglais Content Descriptor Service). Selon le standard UPnP AV:4, un équipement implémentant la fonction Control Point UPnP connecté à un réseau local peut donc demander à un équipement implémentant la fonction MediaRenderer UPnP connecté au même réseau local de restituer un contenu audiovisuel depuis un fichier accessible sur le réseau et stocké sur un équipement implémentant la fonction Media Server UPnP. La restitution synchrone de deux contenus audiovisuels selon UPnP est réalisée par une fonction SyncPlay. Le modèle d'interaction UPnP entre les équipements compatibles est tel que le ControlPoint interagit avec le ou les MediaServer et le ou les MediaRenderer concernés par la restitution d'un contenu. Le MediaServer et le MediaRenderer interagissent toutefois directement entre eux selon un protocole dépendant du type de réseau local qui les relie. Le Control Point utilise UPnP pour initialiser et configurer le MediaServer et le MediaRenderer afin que le contenu qui doit être restitué soit transféré d'un équipement vers l'autre. La fonction SyncPlay spécifie au MediaRenderer un temps de présentation intitulé « presentation time » pour la restitution d'un contenu. Ceci implique que le MediaServer et le MediaRenderer partagent une horloge commune comme par exemple l'horloge de référence du réseau local domestique 2. Le partage d'une horloge commune entre plusieurs équipements d'un réseau local est possible grâce, par exemple, au protocole NTP (Network Time Protocol, décrit dans le document RFC1305) pour les réseaux locaux et étendus. NTP est un protocole qui permet de synchroniser, via un réseau, l'horloge de référence d'équipements connectés au réseau. Ce système de synchronisation d'équipements sur une horloge commune est basé sur un principe serveur / client. La transformation d'un flux de données multicast transportant un contenu audiovisuel et comprenant des estampilles temporelles indiquant le temps écoulé depuis le début du contenu à restituer en un fichier de contenu disponibles sur un MediaServer UPnP AV :4 permet donc, selon le mode de réalisation de l'invention, la restitution sur un équipement de restitution connecté au réseau local et qui implémente les fonctions de MediaRenderer telles que décrites dans UPnP AV :4. La transformation du flux de données diffusé en un fichier permet en outre la restitution synchrone avec une autre composante d'un même contenu audiovisuel disponible dans un autre fichier sur un MediaServer 25 UPnP AV :4 du même réseau local. L'exemple de différentes vues d'un même concert, filmées et enregistrées par des caméras différentes, puis encodées par l'encodeur 8 et stockées pour une part sur le serveur de contenus 6 et pour une autre part, 30 comprenant une vue principale du concert, sur un espace de stockage du diffuseur 7 illustre l'un des avantages apportés par la méthode. Le serveur 6 met, par exemple, à disposition un contenu audiovisuel correspondant à une vue montrant uniquement le pianiste pendant toute la durée du concert. Le diffuseur de contenus 7 dispose d'un contenu audiovisuel correspondant à une vue principale qui montrent l'ensemble des musiciens pendant le concert. Lorsque la vue principale est diffusée en multicast, par un opérateur de télévision, sur le réseau étendu 3 et accessible à un récepteur d'un réseau local tel que le réseau local domestique 2, la transformation du flux multicast reçu en un fichier disponible sur un MediaServer UPnP connecté au réseau local domestique 2 permet la restitution synchronisée avec la vue du pianiste si celle-ci a été précédemment téléchargée depuis le serveur de contenu 6 et est disponible sur un serveur MediaServer UPnP AV :4 connecté au réseau local domestique 2. Ceci est possible dès lors que la vue principale diffusée en multicast (et dont le contenu est « poussé » du diffuseur de contenu 7 vers la passerelle réseau 1 après que la passerelle réseau ait demandé l'adhésion au flux multicast) comprend des estampilles temporelles successives indiquant le temps écoulé depuis le début du concert. Selon le mode de réalisation de l'invention, l'application cliente exécutée par l'ordinateur personnel 5 détecte la diffusion des flux multicast diffusés depuis le diffuseur de contenu 7 et affiche sur l'écran de l'ordinateur personnel 5 la liste des flux et des contenus correspondants diffusés. L'utilisateur de l'application cliente peut demander la sauvegarde d'un flux multicast sous forme de fichier du Media Server UPnP AV :4 du serveur local 13. L'unité de contrôle est de traitement 134 reçoit des informations de configuration depuis l'application cliente exécutée par l'ordinateur personnel 5. L'unité de contrôle et de traitement 134 configure l'interface réseau 131 pour la réception et l'enregistrement d'un flux de données multicast par le serveur local 13. La passerelle réseau envoie une requête d'abonnement au flux selon le protocole de routage IGMP (de l'anglais Internet Group Management Protocol qui signifie protocole de gestion de groupes pour internet, défini comme une norme dans la RFC1112) et le flux multicast est alors transmis à l'interface réseau 131 de la passerelle réseau 1. Selon le mode de réalisation de l'invention, le contenu audiovisuel du flux multicast est transmis par paquet selon le protocole de transmission RTP (de Real-Time Transfer Protocol) sur UDP (de User Datagram Protocol) qui sont des protocoles de transmission usuels pour les transmissions de contenus audiovisuels à travers les réseaux étendus et locaux. Les données utiles qui codent le contenu audiovisuel correspondent à un codage selon un protocole de compression de données MPEG (de Motion Picture Expert Group). Des estampilles temporelles, telles que, par exemple, selon la norme ETSI TS 102823 sont également transmises à intervalle régulier dans le flux correspondant au contenu audiovisuel et indiquent le temps écoulé depuis le début du contenu en vue de sa restitution, nommé ici TOc (pour Time Offset current value). L'interface de réseau local 131 reçoit les paquets du flux multicast et effectue un filtrage pour ne transférer à l'unité de calcul 132 que les paquets portant les données utiles (par exemple les composantes audio et vidéo du contenu audiovisuels transmis) et les paquets qui comprennent les estampilles temporelles (TOc). Selon le mode de réalisation de l'invention, l'unité de calcul 132 calcule, selon l'heure de référence du réseau local 2 et une estampille temporelle reçue dans le flux multicast, indiquant la position courante par rapport au début du contenu audiovisuel, une information temporelle de restitution conforme à UPnP AV :4. Cette information temporelle de restitution est une heure de disponibilité pour la restitution qui s'exprime en heures, minutes, secondes et dixièmes de seconde. Cette information temporelle est alors lue par l'unité de contrôle 134 dans un registre de l'unité de calcul 132 et indiqué dans un champs d'information du CDS associé au fichier de sauvegarde qui stocke les données correspondant au contenu audiovisuel sur l'unité de sauvegarde 133 du serveur local 13. - La figure 4 illustre temporellement la réception d'un contenu diffusé en multicast et le téléchargement d'un fichier en vue d'une restitution synchronisée de leurs contenus. Le flux diffusé en multicast correspond à la vue principale du concert de musique transmis depuis le serveur de diffusion 7. La réception et la lecture de la première estampille temporelle TOc associée aux données adjacentes qui codent l'audio et la vidéo correspondantes de cette vue indique que le concert à commencé depuis 11 minutes et 3 secondes. L'heure de référence du réseau local 2 (encore appelée « wall dock », est accessible à l'unité de calcul 132. Elle est transmise à l'unité de calcul selon le protocole NTP par exemple. Au moment de la lecture de la première estampille temporelle détectée dans le flux, l'heure de référence (wall dock) du réseau local domestique est ToD = 9h 04 min 3s. L'unité de calcul 132 du serveur local 13 qui reçoit le flux multicast calcule l'heure de début du contenu (en termes de restitution) par rapport à l'horloge de référence ToD du réseau local domestique 2. Soit ToDO = ToD - TOc ce qui correspond, pour l'exemple décrit à ToDO = 09 h 04 min 03 s - 11 min 03 s ToDO = 08 h 53 min où ToDO est l'heure à laquelle aurait été reçu le début du contenu diffusé référencée par rapport à l'horloge de référence du réseau local 2, To D. Le calcul de ToDO permet de positionner précisément dans le temps, en référence à l'horloge du réseau local domestique 2 (la wall dock), le contenu transmis et qui a été encodée dans un système ne possédant pas d'horloge commune avec le réseau 2. Il est ainsi possible de synchroniser la restitution du contenu avec la restitution d'un ou plusieurs autres contenus présents sur un serveur local du réseau domestique 2 en définissant un instant précis de restitution. L'heure à partir de laquelle une portion de flux multicast reçue peut être restituée, référencée par rapport à l'horloge de référence ToD du réseau local 2 doit cependant tenir compte des délais de traitement liés à la réception, à l'enregistrement, au contrôle et à la lecture et transmission propres à la restitution. Un temps de traitement maximal TBR (acronyme de l'anglais « Time Before Rendering ») est défini pour l'ensemble de ces opérations. La restitution sur un équipement implémentant la fonction MediaRenderer selon UPnP pourra débuter à partir de ToD + TBR. L'instant de début de restitution possible pour le contenu dont la composante est poussée par le serveur de diffusion 7 et reçue par le serveur local 13 de la passerelle 1 est ToDRc = ToD + TBR, référencé par rapport à l'horloge du réseau local 2. Selon le mode de réalisation de l'invention, l'unité de contrôle et de traitement 134, lit les informations ToDRc, TOc et ToDO dans des registres de l'unité de calcul 132 et écrit la valeur de ToDRc dans le champ d'information nommé ScheduleStartTime du service de description de contenu UPnP AV :4 (le CDS) accessible sur l'unité de sauvegarde 133 du serveur local 13. Ce champ d'information à vocation à indiquer l'heure de début prévue de la restitution d'un contenu. Selon un autre mode de réalisation de l'invention, l'unité de contrôle et de traitement 134 lit les informations ToDRc, TOc et ToDO dans des registres de l'unité de calcul 132, calcule et écrit une valeur correspondant à un instant ultérieur à ToDRc dans le champ d'information nommé ScheduleStartTime du service de description de contenu UPnP AV :4 (le CDS) en vue de retarder le début de la restitution selon d'autres critères de synchronisation. 2 9 80662 16 Ainsi la méthode calcule une information temporelle de restitution (telle que par exemple ToDRc) à partir d'au moins une estampille temporelle (telle que TOc) et de l'horloge de référence du réseau domestique 2, l'horloge de référence étant la référence temporelle du réseau local 2. 5 L'information temporelle de restitution, qui peut être ToDRc ou une valeur correspondant à un instant ultérieur est enregistrée dans le champ d'information du service de description de contenu (CDS) indiquant un paramètre d'heure de début prévue (ScheduledStartTime). 10 Si le fichier correspondant à la vue du pianiste, disponible sur le serveur de contenu 6 est téléchargé et stocké sur l'unité de sauvegarde 133 de sorte qu'il soit accessible en lecture à partir de l'heure ToD = 9h10, par exemple, il est possible pour un Control Point UPnP AV :4 de demander la restitution synchronisée des deux vues (la vue principale du concert et la vue 15 auxiliaire du pianiste) en exécutant des commande SyncPlay selon le protocole UPnP AV :4. Le Control Point UPnP AV :4 est, selon un mode de réalisation de l'invention, une application exécutée par l'ordinateur personnel 5. 20 Une première commande SyncPlay indique, par exemple, au dispositif de restitution 9, qui implémente les fonctions MediaRenderer UPnP AV :4, de restituer le contenu du fichier correspondant à la réception du flux multicast et disponible sur le MediaServer UPnP AV :4 du serveur local 13 à partir de l'heure ToDRc = ToD + TBR. La commande SyncPlay indique en 25 paramètre la localisation du fichier sur le réseau, en plus de l'heure précise du début de la restitution et d'un paramètre de référence de position. Une seconde commande SyncPlay indique, par exemple, au dispositif de restitution 4, de restituer le contenu du fichier correspondant à la 30 vue du pianiste, précédemment téléchargée sur le MediaServer UPnP AV :4 du serveur local 13 en indiquant une heure de début de restitution calculée par le contrôle point à partir de l'heure de début calculée de la vue principale et du temps de traitement TBR. Le Control Point UPnP AV :4 indique en outre au dispositif de restitution 4 la localisation du fichier correspondant. Le dispositif de restitution 4, qui implémente les fonctions MediaRenderer UPnPAV :4 adresse une requête de transfert de contenu au MediaServer UPnP AV :4 du serveur local 13. Le MediaServer UPnP AV :4 du serveur local 13 transfère le contenu du fichier au MediaRenderer UPnP AV :4 (le dispositif de restitution 4) qui restitue le contenu de façon synchrone avec l'autre MediaRenderer UPnP AV :4 (le dispositif de restitution 9), les paramètres temporels transmis par les commandes SyncPlay se référant à l'horloge du réseau local domestique 2 et calculés selon le même principe par le Control Point UPnP AV :4. La figure 5 est un diagramme fonctionnel qui illustre la méthode selon un mode de réalisation de l'invention. L'étape S1 est l'étape initiale. Le flux multicast est diffusé par le diffuseur de contenu 7 sur le réseau étendu 3 mais n'est pas routé vers la passerelle réseau 1. A l'étape S2, un utilisateur de l'ordinateur personnel du réseau local domestique 2 commande l'enregistrement du flux multicast sur le serveur local (Media Server UPnP) intégré à la passerelle réseau 1. Une commande est passée depuis l'ordinateur local 5 à la passerelle réseau 1 qui adresse une requête d'abonnement au flux multicast, selon un protocole de routage tel que IGMP par exemple. A l'étape S3, le flux multicast est routé vers la passerelle réseau et reçu par l'interface 131 du serveur local 13. L'unité de calcul est configurée pour détecter la première estampille temporelle comprise dans le flux multicast et indiquant le temps écoulé depuis le début du contenu diffusé (le temps correspond à un temps écoulé en court de restitution). A l'étape S4, l'unité de calcul à détecté et lu une estampille temporelle est calcule la différence de temps entre l'heure courante de référence du réseau domestique local 2 ToD (la « wall clock ») et la valeur indiquée par l'estampille TOc. L'heure ToDO à laquelle aurait été reçu le début du contenu si la passerelle avait été abonnée au flux multicast préalablement au début de la diffusion est donc connue et plus largement il est possible de repérer l'ensemble du contenu diffusé par rapport à l'heure de référence du réseau local domestique 2 (la « wall clock »). On appelle aussi cette heure l'heure de début du contenu. L'unité de calcul actualise en outre un registre de TBR qui indique le temps de traitement complet de données et conditionne le premier instant possible de présentation des données en vue d'une restitution du contenu. A l'étape S5 le contenu audiovisuel est enregistré sur l'espace de stockage de l'unité de sauvegarde 133. L'espace de stockage peut être un disque dur, une mémoire flash, une mémoire vive ou tout autre support permettant l'enregistrement d'un contenu audiovisuel. L'espace de stockage est, selon des variantes, intégré à l'unité de sauvegarde 133 où connectée à l'unité de sauvegarde 133. L'enregistrement du contenu peut être réalisé dans un fichier contenant des données allant du début de la réception (depuis l'abonnement au flux multicast) jusqu'à la fin du contenu, ou jusqu'à la fin de la réception (le désabonnement au flux multicast) Selon un autre mode de réalisation, l'enregistrement peut être fait selon une technique de tampon mémoire circulaire, bien connue de l'homme de l'art, qui permet de limiter l'espace de sauvegarde nécessaire. Le contenu est alors écrit dans un fichier par pointage en écriture dans une mémoire circulaire et la restitution est alors positionnée dans le temps de sorte qu'un pointeur de lecture utile à la restitution suive le pointeur en écriture. A l'étape S6, l'unité de calcul 132 détermine en fonction d'au moins une partie des éléments ToDO, ToD , TOc et TBR un premier instant à partir duquel la restitution du contenu est possible par un dispositif de restitution compatible avec un MediaRenderer tel que décrit dans la norme UPnP. Cet instant, qui peut-être exprimé sous forme horaire, est inscrit dans le champ ScheduleStartTime du descripteur de contenu UPnP qui permet d'indiquer le contenu du serveur local 13 à un dispositif compatible avec la point de contrôle Control Point tel que défini dans UPnP. En d'autres termes, l'heure de début de la restitution du contenu est « forcée » par l'écriture du champ ScheduleStartTime. Le champ ScheduleStartTime est initialement prévu pour indiquer l'heure de début d'un programme dans la norme UPnP. Un Control Point selon UPnP peut lire l'information temporelle de restitution, sous la forme d'une heure de début de restitution, dans le champ ScheduleStartTime du CDS sur le serveur de média. Si le Control Point adresse une commande de restitution synchronisée à un dispositif de restitution de type MediaRenderer au sens UPnP, la méthode comprend une étape de restitution synchronisée dont l'instant de début dépend de l'information temporelle de restitution. Selon un autre mode de réalisation, la valeur ToDRC est calculée en fonctions d'autres critères, temporels ou non. Le calcul de ToDRC à partir de ToD (la wall clock) et TOc (la première estampille temporelle transmise dans le flux et qui indique le temps écoulé depuis le début du contenu), ainsi que du temps de traitement TBR permet de définir le premier instant où la restitution est possible. Il est possible de retarder l'instant de restitution en définissant un début de restitution plus tard selon des critères tels que les droits des abonnés à des services ou des droits à la visualisation en fonction du contenu à restituer, par exemple. Ainsi, en forçant l'heure de restitution, il est possible de rendre indisponible un contenu audiovisuel pour sa restitution avant une heure définie. Selon un autre mode de réalisation, l'heure de début de restitution est calculée en fonction de l'espace disponible sur l'unité de sauvegarde pour l'enregistrement du contenu et considérant que les données doivent pouvoir être stockées sans débordement du fichier et sans discontinuité à la restitution du contenu. Dans le cas de l'utilisation d'un fichier selon la méthode du « buffer circulaire » et considérant une taille de fichier tampon définie, l'instant de début de la restitution a lieu avant que le buffer circulaire n'ait été rempli par les données en provenance du flux multicast, par exemple. La méthode permet de rendre accessible, depuis un serveur de media connecté à un réseau local, un contenu audiovisuel, par exemple, transmis par un canal de diffusion, de la même façon qu'un autre contenu accessible sur le serveur de media et en provenance d'une autre source. Le serveur de media connecté au réseau local est par exemple un serveur de média tel que défini dans la norme UPnP AV. La restitution du contenu transmis et enregistré dans un fichier sur serveur de media est alors possible sur un dispositif de restitution connecté au réseau à partir d'un instant (ou d'une heure) défini selon différents critères. Cela peut être à partir de l'instant de réception des premières données du contenu auquel il faut ajouter le temps de traitement nécessaire entre la réception et la restitution et référencé selon l'horloge du réseau local. Ce peut être également à partir d'une certaine heure. Une astuce de la méthode est l'utilisation d'un champ d'information qui indique à un dispositif de contrôle ou un dispositif de restitution, le moment à partir duquel le contenu peut être restitué. Il est donc possible d'imposer ce moment pour un ou plusieurs dispositifs de restitution. Ce moment (cette heure) peut être retardé en fonction de critères autres, visant à rendre possible ou synchroniser la restitution du contenus conditionnellement. La méthode permet d'imposer une heure avant laquelle la restitution n'est pas possible. Bien entendu l'invention ne se limite pas aux exemples décrits 10 précédemment mais concerne également des variantes. Selon des variantes du mode de réalisation, la restitution synchrone d'un contenu, à partir de l'information temporelle de restitution (par exemple le champ d'information ScheduleStartTime défini dans le 15 standard UPnP) est réalisée par plusieurs dispositifs de restitution. Selon d'autres variantes, la restitution est initiée par des requêtes de contrôle distinctes transmises vers chacun des dispositifs de restitution ou une requête de contrôle transmise à tout ou une partie de l'ensemble des dispositifs de restitution connectés au réseau local domestique (par exemple 20 à des dispositifs appartenant à un même groupe (en fonction de leur type par exemple)). Selon différentes variantes les requêtes sont unicast, multicast ou broadcast. Selon des variantes du mode de réalisation, l'enregistrement 25 prend fin à la fin du contenu audiovisuel transmis ou s'applique à une suite de contenus diffusés séquentiellement. Selon des variantes du mode de réalisation, le serveur de media qui contient le fichier d'enregistrement et le dispositif de restitution pour 30 restituer le contenu sont compris dans un équipement unique ou sont répartis dans plusieurs équipements distincts. Selon des variantes, le fichier est transmis partiellement ou totalement depuis le serveur de media (Media Server) vers un ou plusieurs dispositifs de restitution (MediaRenderer). Selon une variante le dispositif de restitution est compris dans un même équipement que le serveur de media. En particulier, selon une variante, le réseau de diffusion est adapté à la transmission de contenus diffusés selon un mode de diffusion général ou un mode de diffusion ciblé vers un ou plusieurs destinataires. Selon différents mode de réalisation, le contenu comprend des données audio et / ou vidéo et/ou des données interactives. Selon différents modes de réalisation, le serveur de media est un équipement dédié ou est compris dans des dispositifs tels qu'une passerelle réseau, un décodeur / récepteur de télévision, un ordinateur, un téléviseur, un assistant personnel, un terminal mobile. Selon différentes variantes le serveur de média est un appareil dédié ou compris dans un ou plusieurs dispositifs. Selon différentes variantes, les estampilles temporelles sont transmises comme une composante du contenu ou dans des en-têtes de paquets reçus via le canal de diffusion, ou dans le contenu sous une forme qui utilise la technique de tatouage audio ou vidéo encore connu sous le nom de watermarking ou de finger-printing (de l'anglais et qui signifie « empreinte digitale ») Selon différents modes de réalisation, l'horloge de référence du réseau local est transmise depuis un serveur du réseau étendu vers tous les équipements connectés au réseau local domestique. Selon des variantes, le serveur de média est un serveur local ou distant. L'invention s'applique également à tout dispositif connecté à un réseau et comprenant un serveur de fichiers où les fichiers contiennent une ou des composantes audio / vidéo et dont la restitution des composantes est synchronisée par rapport à une horloge de référence du réseau. Plus généralement l'invention s'applique à tout dispositif ou système mettant en oeuvre la méthode décrite ci-dessus, selon ses différentes variantes. REVENDICATIONS1. Méthode d'enregistrement d'un contenu dans un fichier sur un serveur, ladite méthode étant caractérisée en ce qu'elle comprend les étapes de: - Réception (S2, S3), depuis un canal de diffusion, d'un contenu transmis, ledit contenu transmis comprenant des estampilles temporelles, lesdites estampilles temporelles indiquant le temps écoulé depuis le début dudit contenu, - calcul d'au moins une information temporelle de restitution (S4) à partir d'au moins une desdites estampilles temporelles et d'une horloge de référence, ladite horloge de référence étant une référence temporelle d'un réseau local, enregistrement (S5) d'au moins une partie dudit contenu dans un fichier sur ledit serveur, - enregistrement (S6) de ladite au moins une information temporelle de restitution; 2. Méthode selon la revendication 1, caractérisée en ce qu'elle comprend une étape de restitution dont l'instant de début dépend de ladite au moins une information temporelle de restitution ; 3. Méthode selon la revendication 2, caractérisée en ce que l'étape de restitution ne peut débuter avant une heure définie par ladite au moins une information temporelle de restitution, ledit contenu étant indisponible avant ladite heure. 4. Méthode selon l'une quelconque des revendications 2 à 3, caractérisée en ce que l'étape de restitution débute à une heure définie par ladite au moins une information temporelle de restitution ;30 5. Méthode selon l'une quelconque des revendications 2 à 4, caractérisée en ce que l'étape de restitution comprend une étape de transmission dudit fichier vers au moins un destinataire à une heure définie par ladite au moins une information temporelle de restitution ; 6. Méthode selon l'une quelconque des revendications 2 à 5, caractérisée en ce que l'étape de restitution comprend une étape de transmission dudit fichier vers au moins un destinataire suite à une réception d'une requête de transmission d'au moins une partie dudit contenu ; 7. Méthode selon l'une des revendications 1 à 6, caractérisée en ce que l'étape de calcul de ladite au moins une information temporelle de restitution dépend d'une quantité d'espace disponible pour l'enregistrement dudit contenu ; 8. Méthode selon l'une quelconque des revendications 1 à 7, caractérisée en ce que l'étape d'enregistrement d'au moins une partie dudit contenu dans un fichier utilise un fichier tampon selon une méthode de buffer circulaire ; 9. Méthode selon l'une quelconque des revendications 1 à 8, caractérisée en ce que le fichier de serveur contient la totalité dudit contenu après sa réception ; 10. Méthode selon l'une quelconque des revendications 1 à 9, caractérisée en ce que ledit canal de diffusion est de type bidirectionnel à large bande ; 11. Méthode selon l'une quelconque des revendications 1 à 10, caractérisée en ce que ledit serveur est un serveur de média local compatible avec le standard d'interopérabilité Universal Plug and Play AV; 12. Méthode selon l'une quelconque des revendications 1 à 11, caractérisée en ce que ladite au moins une information temporelle derestitution est inscrite dans un champ d'information d'un service de description de contenu indiquant un paramètre d'heure de début prévue. 13. Méthode selon l'une quelconque des revendications 1 à 12, caractérisé en ce que ladite au moins une information temporelle de restitution est accessible à un équipement connecté audit serveur dans un service de description de contenu ; 14. Dispositif d'enregistrement d'un contenu dans un fichier, caractérisé en ce qu'il comprend : - une interface d'entrée (131) pour recevoir un contenu transmis comprenant des estampilles temporelles, lesdites estampilles temporelles indiquant le temps écoulé depuis le début dudit contenu, - un module de calcul (132) d'au moins une information temporelle de restitution à partir d'au moins une desdites estampilles temporelles et d'une horloge de référence, ladite horloge de référence étant une référence temporelle d'un réseau local, - un module d'enregistrement (133) adapté à enregistrer ledit contenu transmis dans un fichier et à enregistrer ladite au moins une information temporelle de restitution; 15. Dispositif selon la revendication 14, caractérisé en ce qu'il comprend un module d'inscription (134) de ladite au moins une information temporelle de restitution dans un champ d'information d'un service de description de contenu indiquant un paramètre d'heure de début prévue.25