vidéo-diffusion des savoirs : pour une solution qui lave plus libre

Jean Louis Mas


Marc Chanove


Clément Chapu


Marc Chavot


Maison des Sciences de l'Homme-Alpes

1221 avenue Centrale – Domaine universitaire – Saint-Martin d'Hères


François Bouhet


EUROFIDAI

150 avenue de la chimie – Domaine universitaire – Saint-Martin d'Hères


Résumé

L'objectif principal de la communication est de présenter un retour d'expérience sur l'usage de logiciels libres et l'utilisation des standards pour l'enregistrement et la vidéo-diffusion de manifestations scientifiques.

La MSH-Alpes propose depuis sa création la retransmission en direct des événements se déroulant dans l'amphithéâtre en adéquation avec ses objectifs de diffusion des savoirs.

La première partie de la présentation abordera les différents signaux issus de l'audiovisuel et de l'informatique, les connectiques associées, les codecs et les conteneurs. La seconde partie portera sur les solutions de diffusion existantes en unicast et multicast, et soulignera les solutions les plus pertinentes. La dernière partie examinera les écueils et les limitations rencontrés lors de la mise en production de notre solution. Enfin, nous tenterons de répondre à la question : les solutions libres de vidéo-diffusion sont-elles aujourd'hui suffisamment matures pour concurrencer les produits des leaders actuels du marché ?

Mots clefs

streaming ; VOD ; diffusion en direct ; VideoLAN ; multicast ; IPv6

1Introduction, au commencement...

La MSH-Alpes offre depuis sa création en 1998 des retransmissions en direct des événements se déroulant dans son amphithéâtre en adéquation avec ses objectifs de diffusion des savoirs. Ce service, en constante évolution, permet également l'enregistrement et la diffusion à la demande de ces événements. A l'usage, nous en avons constaté les limites et les restrictions. Avec l'essor du haut débit, la vidéo-diffusion s'est popularisée au travers de solutions propriétaires. Parallèlement, des solutions libres offrant une alternative crédible ont vu le jour : l'utilisation de logiciels libres et de standards garantit la pérennité de l'information et la facilité d'accès aux données sans les contraintes des formats fermés. Notre objectif est d'automatiser les traitements de la chaîne de production audiovisuelle afin de minimiser les interventions humaines.

Dans une première partie, nous présenterons les différents signaux vidéos et les connectiques associées, les codecs et les conteneurs. Nous ferons dans une deuxième partie un inventaire des solutions de diffusion existantes et une évaluation des solutions les plus pertinentes. Enfin, nous décrirons les évolutions apportées à notre architecture.

2Quand l'univers impitoyable de l'audio-visuel rencontre le grand bazar de l'informatique

L'informatique et l'audiovisuel convergent. Dans nos salles multimédia, le numérique complète progressivement l'analogique. Cela entraîne une multitude de connectiques, de signaux et de formats, qui sont non seulement difficiles à appréhender mais encore complexes à relier et à convertir. Nous allons les présenter en nous appuyant sur l'équipement de la MSH-Alpes.

2.1Les connectiques et les signaux vidéos

En préambule, quelques rappels sur les signaux vidéo. La luminance est l'une des composantes d'un signal vidéo, elle définit l'intensité lumineuse. Elle est la composante Y du modèle YUV. La Chrominance, composée de la teinte et de la saturation, définit les informations sur la couleur. Dans le modèle YUV, le U représente la chrominance rouge et le V la chrominance bleue, la chrominance verte est déduite des composantes U et V. En audiovisuel, le format de codage de couleurs utilisé est le RGB (Red, Green, Blue) basé sur les couleurs primaires.

Premièrement, nous allons nous intéresser aux technologies analogiques. Historiquement, le monde audiovisuel grand public utilisait le format composite avec la connectique associée RCA jaune (CINCH). Le signal composite véhicule sur un même câble, les composantes de luminance, de chrominances et de synchronisation. Le signal audio stéréo qui l'accompagne utilise deux câbles RCA rouge et blanc. Comme les différentes composantes sont mélangées, la qualité du signal est médiocre. Trois des caméras de la MSH-Alpes utilisent le format composite. Des signaux vidéo à composantes séparées et de meilleure qualité ont vu le jour, tels que le S-vidéo (Y/C) associé à une prise mini-DIN ou le YCrCb, véhiculé sur 3 câbles à connecteurs RCA distincts. Le câble vert transporte la luminance, les câbles rouge et bleu transportent les chrominances associées, tandis que le Y/C n'utilise qu'un seul câble pour les chrominances. Le VGA (Video Graphics Array) et ses évolutions sont fondées sur des palettes de couleurs. La fiche D-Sub 15 bleue correspondant au VGA reste encore la sortie vidéo la plus courante de nos jours. Elle est présente sur les ordinateurs et vidéo-projecteurs de l'amphithéâtre. Toute l'inter-connexion des équipements vidéo de la MSH-Alpes est câblé en VGA. De plus, pour assurer une bonne transmission des signaux vidéos, nous utilisons des répéteurs.

Deuxièmement, nous allons traiter des technologies numériques. Le DVI (Digital Visual Interface) est une connectique moderne destinée à transporter un signal vidéo numérique permettant de hautes résolutions. Par soucis de rétro-compatibilité, le DVI peut véhiculer un signal vidéo analogique VGA. Le kit de visioconférence auquel est rattaché notre caméra HD utilise une sortie DVI-I. Le HDMI (High-Definition Multimedia Interface) est le successeur numérique des formats analogiques audiovisuels. Il transporte des signaux vidéo, mais aussi audio, tous deux non compressés. Le DVI et le HDMI utilisent le codage TMDS (Transition Minimized Differential Signaling) les rendant de fait compatibles. Le débit des spécifications HDMI 1.0 à 1.2 est de 4,9 Gb/s et de 10,2 Gb/s pour les normes 1.3 et 1.4. Nous utilisons l'entrée HDMI (norme 1.0) de notre carte d'acquisition pour encoder le signal vidéo numérique provenant de la régie vidéo.

2.2Les protocoles

2.2.1Protocoles standards

HTTP

HTTP (HyperText Transfert Protocol) n'est pas un protocole de streaming. Comme il traverse généralement les routeurs, il est utilisé pour encapsuler de nombreux protocoles comme MMS ou RTMP. C'est un protocole sans état.



RTSP [1]

RTSP (Real Time Streaming Protocol) est proche de HTTP et dispose de fonctions de contrôle des flux ; lecture, pause, avance rapide, retour rapide. Unicast ou multicast, c'est un protocole à état.



RTP et RTCP

RTP (Real-time Transport Protocol) est un protocole de transport en temps réel, RTCP (RTP Control Protocol) se charge du contrôle de RTP. Ces deux protocoles sont indépendants des couches réseau et transport. En pratique, ils sont principalement utilisés avec UDP, en unicast et multicast.



2.2.2Protocoles Propriétaires

MMS et MMSH

MMS (Microsoft Media Service) est un flux unicast sur les ports 1755 de TCP ou UDP. Il existe également une version encapsulée, MMSH (Microsoft Media Service over HTTP). Il est toujours utilisé dans Windows Media Services 2008.



RTMP et RTMFP d'Adobe Systems

RTMP (Real-Time Messaging Protocol) est un protocole client-serveur unicast, sur le port 1935 de la couche TCP. Il existe en version encapsulée dans HTTP, ou cryptée, ou encore les deux à la fois. Il est principalement utilisé avec FlashPlayer.

RTMFP (Real-Time Media Flow Protocol) est un proctocole récent, apparu dans les applications FlashPlayer10 et Air 1.5. Il fonctionne sur UDP, en unicast. Le système pair-à-pair entre clients a été ajouté pour diminuer la bande-passante du serveur. Ce protocole supporte la mobilité, c'est-à-dire le changement à la volée d'adresse IP.



RDT

RDT (Real Data Transport) est un protocole développé par Real Networks. Il fonctionne sur la couche UDP et les ports 34445 à 34459. Il en est actuellement à la version 3.

2.3Les codecs et les conteneurs

2.3.1Les codecs

Un codec, issu de la compression de deux mots (Codage-DECodage), est un procédé qui code et décode un flux vidéo ou audio, et le compresse éventuellement, pour le rendre plus facilement « transportable ». L'objectif d'un codec est d'obtenir un bon ratio entre le rendu désiré et la taille du fichier de données. Il existe une multitude de codecs (audio et vidéo) dont les plus utilisés sont :

2.3.2Les conteneurs

Un conteneur est un fichier qui peut contenir un ou plusieurs flux audio et vidéo, compressés à l'aide de codecs ainsi que d'autres types d'informations tels que les sous-titres et des méta-données.

Le choix d'un conteneur est dicté par le type d'information à diffuser (audio, vidéo, sous-titre, chapitrage, …). De même pour les codecs, on trouve plusieurs conteneurs propriétaires ou non :

2.3.2.1Le conteneur MPEG

Le Moving Picture Expert Group, créé en 1998, a développé plusieurs normes.

Nous nous sommes plus particulièrement intéressés à la norme la plus récente : MPEG-4

2.3.2.2MPEG-4

C'est un format en plein essor utilisé notamment pour la Télévision Numérique Terrestre Haute-Définition, la visioconférence, les disques Blu-Ray. Il se compose d'une suite de normes appelées parties (parts) qui peuvent contenir chacune plusieurs profils (profiles) et ainsi que des niveaux (levels).

Le MPEG-4 possède 22 parties, en particulier :

Dans le codec vidéo H264, les profils définissent un ensemble de caractéristiques techniques d'encodage. Le choix du profil est déterminé par l'utilisation auquel on destine la vidéo. Parmi les profils existants, par ordre croissant de qualité, nous avons sélectionné le profil baseline pour ré-encoder nos anciennes vidéos. Le profil main servira à encoder celles réalisées avec notre nouveau système. Le profil high sera utilisé pour enregistrer sur DVD. La définition du codec H264 comprend également différents niveaux. Le niveau 1, d'une définition de 128x96 pixels, est utilisé pour la téléphonie mobile. Le niveau 3.1, 1280x720 pixels pour 30 images/seconde correspond à la définition de notre caméra HD. Le niveau 5.1 de la norme, l'ultra HD, autorise une définition de 4096×2048 pixels.

Le codec audio AAC, historiquement défini dans le MPEG-2 partie 7 a subi de nombreuses évolutions et ajouts de fonctionnalités. Nous utiliserons le codec AAC Low Complexity.

A l'usage, les formats propriétaires tel que Real Media nous rendent captifs des outils de l'éditeur. Par conséquent, nous avons choisi d'utiliser seulement des formats non propriétaires. Cela exclut les formats tels que le WMV, le RM et le FLV. Nous avons choisi les codecs H264 et AAC encapsulés dans le conteneur mp4 pour la diffusion de nos vidéos. Il s'agit d'un compromis entre les qualités techniques des codecs, leur intégration dans les lecteurs multimédias les plus courants et leur relative liberté d'utilisation.

3Inventaire des solutions de diffusion vidéo

L'éventail d'applications proposées pour capturer et diffuser des vidéos est aujourd'hui assez vaste. Nous avons évalué des solutions phares du marché, en distinguant d'une part les solutions de vidéo-diffusion et de VOD proposées et d'autre part la solution de capture vidéo associée, tout en écartant les logiciels tiers qui les intègrent.

3.1Adobe - Flash Media Suite

La gamme Flash Media propose une suite de logiciels destinés à la diffusion. Elle se compose à minima de deux logiciels simples d'utilisation : Flash Media Encoding Server (FMES) et Flash Media Streaming Server (FMSS).

Ce dernier est un serveur de diffusion disponible sous Windows et Linux. Il propose des fonctionnalités particulières telles que le cryptage, la gestion des droits de lecture et de copie, une gestion automatique des débits. Il diffuse les formats F4V (Flash Vidéo avec codec H264), FLV (Flash Video), MPEG-4, et 3GPP sur des protocoles développés par Adobe, par exemple FLV sur RTMP, mais aussi des protocoles plus communs tels que HTTP. Il transmet l'audio grâce aux codecs MP3 et AAC. IPv6 est disponible par l'activation d'une option dans les fichiers de configuration. Le Streaming Server implique l'installation d'un client Flash dans le navigateur.

Flash Media Encoding Server est une application disponible sous Windows destinée au ré-encodage et au montage d'un ensemble de vidéos existantes vers les formats streamés par le serveur de diffusion de la suite Flash Media. Il importe un grand nombre de conteneurs tels que le FLV, le F4V, l'AVI, le WMV, l'ASF, le MPEG et le MOV. Flash Media Live Encoder est un outil complémentaire d'acquisition vidéo téléchargeable gratuitement. Il existe une implémentation open-source de Flash Media Streaming Server : Red5.

Le Flash devrait être concurrencée par l'arrivée prochaine de la balise vidéo définie dans HTML 5. Celle-ci dispense du serveur et du client Flash. Flash Media Streaming Server ne gère pas le multicast.

3.2QuickTime Streaming Server (QTSS) et Darwin Streaming Server (DSS)

Darwin Streaming Server [3] est la version open-source du logiciel Quicktime Streaming Server diffusé par Apple. QTSS est livré uniquement dans MacOS X serveur, tandis que DSS est multi-plateforme (Linux, MacOS, Solaris, Windows). Ils diffusent les conteneurs suivants, seulement s'ils sont optimisés (hinting) : QuickTime Movie (MOV), MPEG-4, et le 3GPP. Les fonctionnalités sont nombreuses : diffusion, VOD unicast et multicast, IPv4 et IPv6.

Nous avons testé les versions 5.5.5 et 6.0.3 du Darwin Streaming Server sur une plate-forme Linux Debian stable. La compilation et la configuration sont aisées. Le pilotage de l'application est intégralement réalisée à travers une interface d'administration web. Il est nécessaire d'optimiser (hinting) les flux.

L'optimisation peut se faire à l'aide de QuickTime Pro ou de mp4creator par exemple. Ils sélectionnent automatiquement le type de RTP payload [4] en fonction du contenu de la piste choisie. Nous avons préféré mp4creator, qui, de plus, réorganise les fichiers pour diminuer les accès disques et optimiser les performances du serveur.

Pour faire de la capture vidéo, Apple propose sous MacOSX Quicktime Broadcaster. Il transmet à DSS le flux capturé. Son utilisation est triviale. Cette solution nous semble la plus adaptée à la capture vidéo nomade.

L'utilisation de ces applications est simple, elle a l'avantage d'exploiter des codecs, des conteneurs et des protocoles standards. C'est une alternative open-source intéressante aux produits propriétaires.

3.3RealProducer – Helix server

La société RealNetworks, pionnière dans la diffusion et la vidéo à la demande, propose des solutions multi-plateformes (Linux, Solaris, Windows) payantes ou gratuites, dont certaines sont partiellement open source. Elles s'articulent autour des logiciels Helix DNA Producer (Open source) et Real Producer pour la capture vidéo, puis Helix DNA Server (Open source) et Helix Server pour la diffusion et la vidéo à la demande.

Le Helix Server est décliné en plusieurs versions en fonction du nombre de connexions autorisées : 25, 100 ou illimitées. Seule cette dernière version offre certaines fonctionnalités comme le multicast. Il se configure grâce à une interface web sécurisée d'administration. Le Producer permet via une interface graphique conviviale la capture audio et vidéo. Il effectue la retransmission du flux soit vers internet, soit vers un serveur de diffusion.

Les versions gratuites sont extrêmement restreintes en utilisation, le nombre de flux est limité et sans multicast, les formats d'encodage peu nombreux, tandis que les versions open-source Helix DNA Server et Producer se limitent au Real Media et au mp3. De plus, les codecs de RealNetworks sont propriétaires et nécessitent l'utilisation du client Realplayer. Enfin, le coût de la solution de diffusion et de ses mises à jour dans sa version non limitée est élevé. C'est la solution historiquement utilisée à la MSH-Alpes.

3.4Windows Media Services

A l'instar de ses concurrents, la suite est composée de deux produits, Windows Media Encoder, qui capture les sources audio et vidéo et Windows Media Services. Il s'installe en tant que rôle sur les systèmes d'exploitation Windows Server. Seules les versions Entreprise Server bénéficient de l'intégralité des fonctionnalités du produit, comme le multicast.

L'installation et la prise en main sont simples. À l'usage, Windows Media Services est facile et intuitif, les fonctionnalités de sécurité sont intéressantes (limitation de la bande passante, gestion des droits d'accès). Les protocoles possibles sont RTSP, HTTP et IPv6. Les seules contraintes sont les formats disponibles très réduits et majoritairement limités à ceux de Microsoft, tels que wmv, wma, mp3 et le conteneur asf.

3.5VLC

VideoLAN [5] est un logiciel open-source multi-plateforme de lecture, d'encodage, d'acquisition, de diffusion en direct et à la demande. Il lit la plupart des formats, à l'exception notable de Real Media, partiellement lu. Il implémente les protocoles standards de diffusion [6] ainsi que le multicast et IPv6. En plus de l'interface graphique, il est paramétrable via la ligne de commande, une interface web ou telnet. VLC est « le couteau suisse » du multimédia. Nous avons choisi VLC pour remplacer à terme la solution existante.

4Architecture matérielle et logicielle

L'environnement audio-visuel influe de manière significative sur la qualité de la diffusion. L'architecture actuelle est le fruit d'un travail réalisé depuis deux ans en collaboration entre l'équipe informatique et le responsable audiovisuel de la MSH-Alpes.

L'éclairage, élément essentiel pour les prises de vues, assurées par 4 caméras, a été repensé. La puissance lumineuse a été augmentée afin de favoriser l'éclairage indirect. La double vidéo-projection accroît la modularité de l'amphithéâtre.

Notre objectif est de disposer d'une régie qui minimise l'intervention humaine. Celle-ci s'articule d'une part, autour d'un multi-fenêtreur, qui joue le role d'une régie vidéo, mixant en direct jusqu'à quatre sources (caméras, ordinateur de l'orateur, système de visio-conférence), et d'autre part, grâce à un automate pilotable localement et à distance qui commande via RS-232 les équipements de l'amphithéâtre.

Seule la partie informatique n'a pas encore été revue. Actuellement, les régies audio et vidéo, respectivement la table de mixage audio et le multi-fenêtreur, envoient les flux au serveur Real Producer. Celui-ci les encode au format Real Media. Le document est enregistré localement et transmis au serveur de diffusion Helix Server. Cet ensemble de solutions est actuellement en production.



Figure -1 Architecture de l'amphithéâtre

4.1Limites et évolutions

Nous sommes aujourd'hui tributaires du câblage mis en place à la MSH-Alpes. Celui ci a été historiquement réalisé en VGA. Lors de futures installations, nous privilégierons le DVI.

L'évolution de la partie informatique est nécessaire. En effet, la version de notre Helix Server est obsolète, limitée à vingt-cinq flux unicast IPv4. Le flux, diffusé en Real Media, oblige le client à installer Realplayer. De plus, peu de logiciels proposent le montage vidéo de ce format.

Dans l'éventail des solutions testées, nous voulions retenir un produit qui répondait aux critères suivants : diffusion en mp4, prise en charge du multicast et de l'IPv6, support de l'application sur plateforme Linux. Le respect de ces critères nous a orienté vers VLC.

4.2Solutions techniques retenues

4.2.1Architecture

Le signal vidéo transite du multi-fenêtreur vers la carte d'acquisition BlackMagic Intensity Pro [7] dans un câble DVI-HDMI, tandis que le signal audio provenant de la table de mixage arrive à la carte son. Notre ancienne solution utilisait un boîtier intermédiaire convertissant le signal VGA en Firewire. Les signaux sont mixés et convertis par le serveur d'acquisition, le flux obtenu est envoyé vers le serveur de diffusion. L'acquisition et l'encodage des signaux induisent un important trafic de données et une forte charge de calcul. De fait, il nous est apparu important dans notre architecture de séparer les fonctions d'acquisition de celles de diffusion.

4.2.2Matériel

Nous avons choisi la carte d'acquisition Blackmagic Intensity Pro pour son rapport fonctionnalité/prix attractif. Cette carte Haute Définition possède une entrée et une sortie HDMI 1.0. Les pilotes sont disponibles pour Mac OS X et Windows, ceux pour Linux étaient annoncés dès le début de nos tests.

Nous avons mis en place un serveur d'acquisition sous Linux Debian intégrant la carte Blackmagic. Nous avons testé les pilotes en version béta fournis dans le kit de développement pour Linux sorti en juillet 2009. La carte fonctionne sous Linux, et pour l'exploiter VLC utilise Vidéo for Linux (V4L2), une couche abstraite entre les logiciels d'acquisition vidéo et les périphériques vidéo. Néanmoins, Vidéo for Linux ne supporte pas encore cette carte, l'utilisation du triptyque (BlackMagic, Linux, VLC) est prématurée. Les pilotes officiels sont désormais disponibles depuis septembre 2009.

Notre choix s'est finalement porté sur un serveur d'acquisition sous Windows 2008 Server. Nous nous sommes heurtés à une carte vidéo limitée sur les serveurs (8 Mo de mémoire) impliquant l'ajout d'une carte vidéo performante supplémentaire pour faire fonctionner correctement la BlackMagic. Tout comme Linux s'appuie sur le V4L2, Windows utilise DShow, compatible avec cette carte, permettant de l'utiliser avec tous les logiciels qui intègrent cette API, ce qui est le cas des solutions que nous avons testées. De plus, le choix de Windows correspondait davantage aux attentes du responsable audiovisuel.

Enfin, VLC sous Linux Debian sert de serveur de diffusion en direct et de vidéo à la demande.

4.2.3VLC ? II sait tout faire... sauf le café!

Le signal Haute Définition envoyé par l'une de nos caméras entre dans la carte BlackMagic en 720p (1280x720 pixels en balayage progressif). Puis, la paire DShow-VLC transmet et encode les flux capturés à l'aide de ffmpeg pour le codec audio AAC et de x264 pour le codec vidéo h264 en sélectionnant le profil main. Ces options sont définies en ligne de commande. Le flux est ensuite encapsulé dans le conteneur mp4. Bien que l'encodeur x264 sache exploiter les multi-processeurs, l'encodage en HD est extrêmement gourmand en ressources. L'ajout d'une carte d'encodage pourrait diminuer la charge de calcul, c'est une voie que nous allons explorer. Le flux est d'une part diffusé en unicast UDP vers le serveur de diffusion, et d'autre part, enregistré sur disque, dans l'attente du montage vidéo.

Le responsable audio-visuel réalise manuellement le montage à partir des captures stockées sur disques. Il dépose les fichiers finalisés sur un espace dédié. Le choix du conteneur mp4 et des codecs h264 et AAC offre une large palette de logiciels de montage vidéo.

Dans le serveur Linux Debian, une instance de VLC est démarrée pour gérer à la fois la diffusion en direct et les vidéos à la demande. Nous avons choisi de piloter VLC par l'interface telnet, à l'aide de scripts, ce que ne permettent pas les interfaces graphiques.

Lors de la diffusion en direct, le serveur relaie le flux reçu du serveur de capture.

La liste de lecture des vidéos à la demande est mise à jour par un script. Celui-ci fait l'inventaire des fichiers finalisés. À partir de cet inventaire, il construit l'URI de diffusion par exemple rtsp://videos.msh-alpes.fr/jres2009/vlc et génère le code HTML5 contenant la balise <video> à insérer dans une page web.

Les vidéos diffusées sont insérées dans une image de fond statique (mosaïque sous VLC). Il est possible de mixer les sources vidéos dans VLC, néanmoins, comme nous disposons d'un multi-fenêtreur plus flexible d'utilisation et pilotable depuis la régie vidéo, nous n'utilisons pas cette fonctionnalité.

Les vidéos de la MSH-Alpes sont diffusées en unicast IPv4 et IPv6, la diffusion en direct est également accessible en multicast IPv4.

5Conclusion

Les solutions libres de vidéo-diffusion sont-elles sont suffisamment matures pour concurrencer les produits leaders du marché ?

Les produits des grand éditeurs offrent des solutions clefs en main, faciles d'installation et d'utilisation. Ils sont adaptés aux besoins de la majorité des utilisateurs, mais leur format souvent propriétaire et leur prix élevé ne nous semblent pas adaptés aux besoins spécifiques de notre communauté. A contrario, les solutions libres VLC et Darwin Streaming Server, moins faciles d'accès offrent davantage de liberté dans les formats diffusés et de vastes possibilités techniques. Elles sont portées par des communautés actives. Leur point fort est l'évolutivité.

6Bibliographie

[1] Groupe Interuniversitaire Grenoblois pour le Multicast http://gigm.grenet.fr

[2] MPEG4 http://en.wikipedia.org/wiki/Mpeg4

[3] Darwin Streaming Server http://static.macosforge.org/dss/downloads/

[4] RFC 3016 http://tools.ietf.org/html/rfc3016

[5] VideoLAN http://www.videolan.org/

[6] VideoLAN Streaming features list http://www.videolan.org/streaming-features.html

[7] Blackmagic Design : Software Downloads http://www.blackmagic-design.com/support/software



8 JRES décembre 2009