FR 2915047 A1 20081017 FR 0702693 A 20070413 1 ARCHITECTURE DE TRANSCODAGE DE FLUX MULTIMEDIA La présente invention concerne un système et un procédé de gestion de flux de données numériques de type multimédia. Elle concerne également un programme d'ordinateur pour mettre en œuvre le procédé ainsi qu'une structure de données. Les serveurs de flux de données numériques de type multimédia dit serveur média, servent à enregistrer des flux d'images, de son ou de vidéo circulant sur un réseau et/ou à diffuser ces fichiers sur le réseau. Le rôle de routage des flux multimédia s'accompagne le plus souvent d'un calcul nécessité par une opération de filtrage ou de transcodage du contenu du flux. Par exemple, il peut être nécessaire de changer le mode de codage du flux avant de le diffuser en modifiant le type de codage, l'échantillonnage ou le débit. Le traitement peut également consister à calculer la puissance d'un signal audio, les coefficients de Goertzel pour la détection des porteuses DTMF, le gain d'un signal, etc. Selon le type d'application exécutée sur le serveur média, un même flux peut être soumis à des traitements différents avant diffusion sur plusieurs canaux différents. Par exemple, un flux vidéo destiné à être diffusé en parallèle sur des ordinateurs reliés par une connexion filaire de type ADSL et des téléphones portables dit 3G, devra être codé avec des taux de compression différents pour tenir compte de la différence de débit existant entre la liaison ADSL et la liaison 3G. Ainsi le serveur média effectue autant de 2 traitement qu'il y a de codage ou de calcul particulier à réaliser. Cela crée une contrainte importante sur le dimensionnement des unités de calcul des serveurs média. En conséquence, ces serveurs sont construits autour d'architecture massivement parallèle utilisant un grand nombre de microprocesseurs. Outre la difficulté de mise au point de telle architecture, ces serveurs ont des coûts de fabrication élevés. Il serait donc souhaitable de pouvoir utiliser des serveurs qui strient capables d'avoir la même capacité en terme de nombre de flux supportés en parallèle tout en étant d'un coût plus réduit, ou qui, pour un même coût, soient capables de traiter plus de flux. Ainsi, pour résoudre ce problème, dans un aspect 15 de l'invention, un système de gestion de flux de données numériques de type multimédia comporte : des moyens d'acquisition d'un flux de données multimédia, des moyens de traitement dudit flux de données adaptés 20 pour réaliser au moins un codage dudit flux de données, - des moyens d'émission dudit flux de données traité. Il est caractérisé en ce qu'il comporte en outre des moyens de stockage des résultats des 25 traitements dudit flux de données adaptés pour qu'un traitement ou une émission ultérieur dudit flux de données utilise au moins partiellement lesdits résultats. Ainsi, cela permet avantageusement de conserver les résultats des calculs déjà réalisés pour les utiliser 30 dans des traitements ultérieurs, économisant ainsi des capacités de traitement en ne réalisant chaque opération qu'une seule fois. Les caractéristiques des flux ainsi que les résultats des traitements sont stockés dans une structure 3 de données permettant avantageusement un accès cohérent et aisé à ces résultats. Une structure de données comporte pour chaque codage du flux, des champs définissant le type de codage, la longueur de trame, la profondeur de codage et la vitesse d'échantillonnage. Ainsi, cette structure de données contient avantageusement les principales caractéristiques de chaque codage réalisé permettant un accès rapide au codage le plus pertinent pour le traitement ultérieur. Les moyens de traitement comportent des moyens d'optimisation pour, avant tout traitement, vérifier le contenu des moyens de stockage de façon à ne calculer que les résultats du traitement non disponibles dans les moyens de stockage en utilisant des données disponibles dans la structure de données permettant de minimiser les calculs à réaliser. Les moyens de traitement sont adaptés pour transférer aux moyens de stockage tous les résultats des 20 traitements effectués. Selon un deuxième aspect de l'invention, un procédé de gestion d'un flux de données numériques de type multimédia comportant les étapes de : allocation d'une structure de données, 25 réception du flux, association audit flux de ladite structure de données adaptée pour contenir au moins les caractéristiques de codage dudit flux, exécution d'au moins un traitement sur ledit flux, 30 stockage du ou des résultats dudit traitement dans ladite structure de données, caractérisé en ce que chaque traitement est adapté pour utiliser des résultats contenues dans la structure des données afin de minimiser la quantité de calcul à réaliser. 4 Selon un mode particulier de réalisation, la structure de données comporte, pour chaque codage du flux, des champs définissant le type de codage, la longueur de trame, la profondeur de codage et la vitesse d'échantillonnage. Dans un troisième aspect de l'invention, un produit programme d'ordinateur comporte des instructions pour la mise en oeuvre du procédé précédent lors de l'exécution sur un ordinateur. Et, dans un quatrième aspect de l'invention, unestructure de données représentative d'un flux de données numériques de type multimédia comporte des champs représentatifs du ou des codages des dites données de telle sorte que les champs mémorisent les résultats des traitements effectués sur le flux de données. Dans un mode particulier de réalisation, lacomporte des champs d'optimisation tels qu'un traitement optimise les calculs à effectuer en fonction des données contenues dans la structure de données. L'invention sera mieux comprise à la lecture de la description qui suit, donnée uniquement à titre d'exemple, et faite en référence aux figures en annexe dans lesquelles : la figure 1 est un schéma synoptique d'un système de 25 traitement de flux multimédia comportant un serveur de gestion de flux de données numériques de type multimédia selon un mode de réalisation de l'invention ; la figure 2 est un ordinogramme d'un procédé de 30 gestion selon un mode de réalisation de l'invention ; et la figure 3 est un schéma d'une structure de données selon un mode de réalisation de l'invention. En référence à la figure 1, un réseau 1 comporte un serveur 2 de gestion de flux de données numériques de type multimédia. Le serveur 2 est connecté à d'autres équipements 3, 4, 5 informatiques et/ou de télécommunication pour 5 recevoir des flux de données de type multimédia, c'est-à-dire des flux de données vidéo, audio ou d'images. Le serveur 2 est également connecté à des équipements 6, 7, 8 informatiques et/ou de télécommunications pour envoyer des flux multimédia. Il est à noter que, très souvent, un même équipement peut être à la fois source et destination d'un flux multimédia. De même, un flux peut provenir, ou être fourni, à une unité de stockage interne au serveur 2. Le réseau 1 est typiquement un réseau de données numériques de type internet et les flux de données sont, par exemple, transportés en utilisant le protocole RTP (Real-Time Transport Protocol - protocole de transport temps réel). Le serveur 2 comporte ainsi des moyens 10 20 d'acquisition d'un flux multimédia ainsi que des moyens 12 d'émission de flux multimédia. Il comporte également des moyens 14 de traitement de données connectés à des moyens 16 de stockage adaptés pour stocker les résultats des calculs 25 effectués par les moyens 14 de traitement sur les flux multimédia. Les moyens 14 de traitement comportent, en particulier, des moyens 18 d'optimisation des traitements à effectuer se basant sur les données stockées dans les 30 moyens 16 de stockage. Le fonctionnement du serveur 2 va maintenant être explicité en référence à la figure 2. Dans une étape préliminaire, le serveur 2 alloue en 20 un espace de stockage dédié à un flux. Cet espace 35 de stockage dédié est constitué d'une zone d'adresses en 6 mémoire vive, d'une zone de stockage sur un support de données de masse de type disque dur ou d'une combinaison des deux. Cet espace de stockage se présente logiquement comme une structure de données appelées par la suite IDC, (Intelligent Data Container - conteneur intelligent de données) schématisée à la figure 3. Un flux F de données multimédia est lu ou reçu, à l'étape 22, par le serveur 2. Ce flux F provient d'un des équipements 3, 4, 5 ou bien d'un autre flux, d'un fichier ou d'un tampon interne au serveur 2. A l'étape 24, le serveur 2 stocke le contenu du flux dans l'IDC avec le codage spécifique, la longueur de trame, la profondeur de codage ainsi que la vitesse d'échantillonnage. Bien que séparée logiquement, les étapes 22 de réception et 24 de stockage sont effectuées en parallèle, dans le sens où les données du flux F sont stockées dans la structure IDC au fur et à mesure de leur réception. L'ordre d'exécution des étapes 20 d'allocation, 22 de réception et 24 de stockage est modifiable en fonction des besoins ou de l'efficacité recherchée. Par exemple, l'allocation peut également avoir lieu lors de la réception d'un flux. En fonction des besoins de traitement à effectuer sur le flux, le serveur 2 applique en 26, un filtre sur l'IDC. Le filtre est une opération sur le contenu destiné à le modifier ou à agir sur une propriété particulière des données du flux tel que, par exemple, une incrustation de média ou l'envoi d'un évènement. Les résultats du filtre sont stockés en 28 dans l'IDC. Dans un mode de réalisation particulier, le filtre se définit sous la forme d'un résultat particulier à obtenir : codage selon telles caractéristiques, puissance du signal, etc. Cette requête est analysée par une sous-structure de l'IDC appelée contexte calculatoire 7 qui, en fonction vies éléments déjà connus ou calculés, définit le mode d'obtention optimal et applique la transformation la plus pertinente. Le contexte calculatoire se présente, par exemple, sous la forme d'une matrice définissant sur un côté les différents résultats possibles et sur l'autre côté les données de départ nécessaires. La cellule de la matrice contient aussi l'algorithme à utiliser pour obtenir un résultat donné à partir d'un type de données déterminé. Certaines modifications effectuées par le filtre peuvent invalider certaines versions ou propriétés du flux déjà contenues dans l'IDC. Le filtre travaille généralement sur un codage YUV pour les images et linéaire pour les autres types de média. En fonction du résultat à atteindre, le filtre commence par analyser en 30 le contenu de l'IDC pour déterminer s'il peut utiliser des résultats contenus dans celui-ci, soit comme résultat intermédiaire, soit comme résultat final. Ainsi, le filtre n'effectue avantageusement que les calculs strictement nécessaires et non déjà disponibles dans l'IDC. De même, il choisit avantageusement, par les 25 données disponibles, celles qui permettent une optimisation des calculs à réaliser. Ceci est particulièrement avantageux quand plusieurs filtres sont appliqués successivement sur le flux de données. En effet, avec l'application de chaque 30 filtre, le contenu de 1'IDC est enrichi de nouveaux résultats, augmentant ainsi la probabilité qu'un filtre ultérieur puisse utiliser des résultats déjà obtenus. Un exemple relativement fréquent porte sur l'utilisation par plusieurs filtres d'un même codage. 35 Celui-ci ayant été effectué une première fois et stocké 8 dans l'IDC, les filtres suivants n'ont pas besoin de coder à nouveau le flux. Il est à noter que le codage initial du flux n'est pas perdu mais stocké lui aussi dans l'IDC, ce qui 5 permet de le réutiliser si nécessaire. Les étapes 26 à 30 sont ainsi effectuées un certain nombre de fois. Puis le flux est envoyé, à l'étape 32, vers une ou plusieurs destinations particulières. Cet envoi consiste à transférer le contenu 10 dans un format particulier à un ou plusieurs des équipements 6, 7, 8 mais peut également consister à écrire le contenu dans un autre flux, un fichier, un tampon, etc. Le flux pouvant être envoyé à plusieurs 15 destinations dans des codages différents, le procédé décrit comporte également une boucle de rétroaction en sortie de l'étape 32 d'émission. On comprend, qu'ainsi, tout flux est transcodé de n'importe quelle source vers n'importe quelle 20 destination compatible (transcodage audio complet, ré-échantillonnage et matrice de requantification, transcodage vidéo complet, changement de taille, d'espace de couleur, etc.) A titre d'exemple, on va décrire les opérations 25 liées à deux flux : un flux d'émission pour envoyer des signaux vocaux sur un réseau IP, et un flux de réception de signaux vocaux. C'est un exemple typique de voix sur IP pouvant 30 être comparé à quelqu'un parlant et écoutant au téléphone. Le flux de réception comporte : - une source sous forme d'un objet RTP. Le contenu est lu du réseau sous un codage en loi U (codage audio 9 basé sur une modulation d'impulsion codée (PCM - Pulse Code Modulation)). Un codage en loi U est échantillonné à 8 kHz sur 8 bits. Le flux entrant est formé de paquets de 20 ms. (L'objet RTP reçoit une trame audio de 160 échantillons toutes les 20 millisecondes) ; un filtre iDTMF pour détecter un signal DTMF intrabande. Le filtre a besoin des coefficients de Goertzel pour chaque fréquence DTMF ainsi que la puissance du signal audio en décibels. Ces données sont calculées par le serveur 2 ; une destination sous forme d'un fichier stocké sur le disque dur du serveur 2. Le fichier contient le contenu média codé en loi 15 A, échantillonné à 8 kHz avec une quantification sur 8 bits. La structure IDC correspondante évolue comme indiqué dans le tableau ci-dessous au fur et à mesure des étapes de traitement du flux. ETAPE DESCRIPTION CONTENU IDC (après l'étape) 1 Allocation IDC et vide association avec le flux 2 Objet RTP charge l'IDC avec les trames audio en loi U provenant du réseau loi U 20ms ~ 8bits 8kHz 3 Le filtrage iDTMF recherche la puissance du signal et les coefficients de Goertzel loi U 20ms 8bits 8kHz linéaire 20ms 16bits 8kHz puissance 20dB Goertzel coef. 4 Stockage des données codées en loi A dans un fichier loi U 20ms 8bits 8kHz linéaire 20ms 16bits 8kHz puissance 20dB Goertzel coef. loi A 20ms 8bits 8kHz 20 10 Il est à noter que, à l'étape 2 du tableau, la trame audio est décodée sous forme d'un codage linéaire à partir du codage en loi U. Ce codage linéaire est stocké dans la structure [DC et sert au calcul de la puissance du signal et des coefficients de Goertzel. Ainsi, lors de l'étape 4 du tableau, le codage en loi A pour le stockage en fichier s'effectue à partir du codage linéaire réalisé à l'étape 3. Le codage linéaire est donc utilisé pour le 10 calcul de la puissance du signal et des coefficients de Goertzel ainsi que pour le codage en loi A. Le flux d'émission comporte, une source sous forme d'un fichier codé en loi A. Ce fichier, stocké sur le disque dur du serveur 2, est 15 différent de celui du flux de réception. Il s'agit, par exemple, d'un message d'accueil ; une destination sous forme d'un objet RTP qui envoie le contenu codé en loi U sur le réseau. La structure de données IDC correspondante se 20 constitue alors selon le tableau suivant. ETAPE DESCRIPTION CONTENU IDC (après l'étape) 1 Allocation IDC et le vide association avec flux 2 Données codées en loi A sont lus d'un [ loi A 20ms 8bits 8kHz fichier 3 Objet RTP envoie U loi A 20ms 8bits 8kHz linéaire 20ms 16bits 8kHz une trame en loi sur le réseau loi U 20ms 8bits 8kHz Il est à noter qu'à l'étape 3, le transcodage en loi U est lié au fait que le fichier d'origine est codé 25 en loi A et non en loi U. Le fichier aurait été codé initialement en loi U, aucun transcodage n'aurait été réalisé à l'étape 3. Ainsi, on a décrit un serveur et un procédé de gestion des flux multimédia adaptés pour optimiser les quantités de calcul effectués sur ces flux. L'invention n'est pas limitée à la description ci-dessus dans le sens où de nombreuses variantes peuvent être réalisées. Par exempLe, la structure de données peut contenir chaque codage des données ou bien contenir seulement un pointeur vers un fichier ou une autre structure de données adapté pour contenir le contenu codé. On comprend également que l'invention peut être mise en oeuvre sous la forme d'un produit programme d'ordinateur mettant en oeuvre le procédé de gestion lorsqu'il est exécuté sur un ordinateur. Mais il peut également être mis en oeuvre sous forme d'une structure matérielle de type FPGA (Field Programmable Gate Arrays -réseau de portes logiques programmables sur le terrain). Cette solution est particulièrement adaptée quand de nombreux flux ayant toujours la même structure et les mêmes types de traitement doivent être gérés. REVENDICATIONS 1. Système de gestion de flux de données numériques de type multimédia comportant : - des moyens (10) d'acquisition d'un flux de données multimédia ; des moyens (14) de traitement dudit flux de données adaptés pour réaliser au moins un codage dudit flux de données, des moyens (12) d'émission dudit flux de données traité, caractérisé en ce qu'il comporte : des moyens (16) de stockage des résultats des traitements dudit flux de données adaptés pour qu'un traitement ou une émission ultérieur dudit flux de données utilise au moins partiellement lesdits résultats. 2. Système selon la revendication 1, caractérisé en ce que les moyens (16) de stockage comportent une structure de données associée audit flux de données multimédia, ladite structure de données comportant les résultats des traitements. 3. Système selon la revendication 2, caractérisé en ce que ladite structure de données comporte pour chaque codage dudit. flux, des champs définissant le type de codage, la longueur de trame, la profondeur de codage et la vitesse d'échantillonnage. 4. Système selon l'une quelconque des revendications 1, 2 ou 3, caractérisé en ce que les moyens de traitement comportent des moyens d'optimisation pour, avant tout traitement, vérifier le contenu des moyens de stockage de façon à ne calculer que les 25 30 13 résultats dudit traitement non disponibles dans les moyens de stockage en utilisant des données disponibles dans la structure de données permettant de minimiser les calculs à réaliser. 5. Système selon la revendication 4, caractérisé en ce que les moyens de traitement sont adaptés pour transférer aux moyens de stockage tous les résultats des traitements effectués. 6. Procédé de gestion d'un flux de données numériques de type multimédia comportant les étapes de : allocation (20) d'une structure de données (IDC), réception (22) du flux, association (24) audit flux de ladite structure de données adaptée pour contenir au moins les caractéristiques de codage dudit flux, exécution (26) d'au moins un traitement sur ledit flux, stockage (28) du ou des résultats dudit traitement dans ladite structure de données, caractérisé en ce que chaque traitement est adapté pour utiliser des résultats contenues dans la structure des données afin de minimiser la quantité de calcul à réaliser. 7. Procédé selon la revendication 6, caractérisé en ce que la structure de données comporte, pour chaque codage du flux, des champs définissant le type de codage, la longueur de trame, la profondeur de codage et la vitesse d'échantillonnage. 8. Produit programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé selon la revendication 6 ou 7 lors de l'exécution sur un ordinateur. 9. Structure de données représentative d'un flux de données numériques de type multimédia caractérisée en ce qu'elle comporte des champs représentatifs du ou des 14 codages desdites données de telle sorte que les champs mémorisent les résultats des traitements effectués sur le flux de données. 10. Structure de données selon la revendication 9, caractérisée en ce qu'elle comporte des champs d'optimisation tels qu'un traitement optimise les calculs à effectuer en fonction des données contenues dans la structure de données.