WORKFLOW

INTRODUCTION

Pour tout travail sur les médias, on se base sur un workflow de production, c’est-à-
dire que l’on part de matières premières et que l’on finit par un produit. L’ensemble
des étapes de production est inspiré par le cahier des charges de la production en
question. Ce dernier impose un mode de travail et organise le schéma global du
travail. MAIS : le cahier des charges ne dit pas COMMENT FAIRE. C’est le workflow
qui traduit le cahier des charges en ETAPES TECHNIQUES. Ex : Pour tous médias
échangés au fil de la production, le workflow va spécifier les caractéristiques.
Le Workflow institue donc plusieurs règles à respecter mais une règle prévaut
toujours : quand on utilise des outils que l’on ne maitrisent pas, on doit toujours faire
un test, que l’on appelle P.O.C. (Proof Of Concept).
Un des corolaire du workflow est la mise sur pied d’un protocole de stockage (car
stocker les données a un impact budgétaire).
Etant donné qu’on aura toujours des contraintes de budget et de temps, il faudra
passer par des étapes spécifiques.

L’objectif général : trouver le workflow le plus économique et qui prend le moins de

temps.

Exemples
- TFE: caméra red prêter et non testé => problème de synchro et donc étape d’ingest
bcp pls longue
- Panique au palais:émission radio qui est trasnformé en long métrage. Ils ont choisis
des 5D donc grand capteur. Le 5D était inutilisable due au codec utilisé pour la
compression lors de l’enregistrement bloquant toute possibilité de synchronisation=>
une semaine d’ingest => 1 mois. Pas sorti à la date espérer
- Place royale: Niveaux de qualités qui varient en permanence car image de youtube.
Problème: aucun questionnement par rapport au mélange d’image de différente
source

1 sur 29
 MEDIA

A. OBJECTIF

Succession d’étape qui vont transformer des médias dans le temps dans le but de
recevoir le média finale
But du workflow : Chemin le plus efficace dans l’ensemble des contraintes

B. DEFINITION

• Essence = format + codec

• Contenu = essence + metadata
• Media = container (essence (format + codec) + metadata) + support
- Format: résolution
- Codec: algorithme de compression
- Metadata: informations sur le fichier
- Support: support physique qui contient le média

NB:

DAR = Display Aspect Ratio = taille de l’écran (rapport de la largeur sur la hauteur de
l’écran), géométrie de l’écran
PAR = Pixel Aspect Ratio = taille pixel (pixel carré ou pas)
SAR = Storage Aspect Ratio = nbr de pixels/nbr de lignes

Calculer un taux de compression: résolution x bit x ech x i/s DIVISE PAR débit
maximum.

1 octet = 8 bits = 1 byte !!!!

2 sur 29
C. PROPRIETE

3 sur 29
FORMAT Définition Images UIT 601 UIT 709 UIT 2020

Résolution Largeur x 576x576 et 1920x1080 3840 x 2160

longueur 960x576 et 1280x720 ( = UHD1)
7680 x 4320
(UHD2)

Display Proportion de 4/3, 16/9, 16/9 16/9

Aspect Ratio l’image 16/9 LB,
(DAR=PARxS 16/9 PB
AR)
Dans SAR:
divisé

Bit Depth Profondeur/ 8, 10 (8), 10 10, 12

quantification
de l’image
2 exposant n,
plus il y a de
bit, plus il y a
de niveaux et
donc de
détails dans
l’image

Color Space Espace colo Y, Cr, Cb Y, Cr, Cb Y, Cr, Cb

(RGB ou Y, Cr,
Cb)

Color échantillonnag 4 :4 :4 4 :4 :4 4 :4 :4
Subsampling e (4:4:4, 4:2:2, 4 :2 :2 4 :2 :2 4 :2 :2
4:1:1, 4:2:0, 4 :1 :1 4 :1 :1 4 :1 :1
4:1:0) 4 :2 :0 4 :2 :0 4 :2 :0
4 :1 :0 4 :1 :0 4 :1 :0

Color couleurs coordonnée Y= 0,2126 R

Primaries primaires de XY=> R,V,B + 0,7152 V
l’espace colo et Bl + 0,0722 B
utilisées Y = 0,3 R +
incluant un 0,59 V +
blanc de réf 0,11 B

Color Transfer Lois de XX Cr = R-Y,

conversion Cb = B-Y
d’échelles de
valeurs

Scan Type Entrelacement, XX I, P, PSF P

type de balaya
(i ou p)

Scan Order Ordre de tram FFT (first FFT FFT

field top)

Frame Rate Fréquence 25 i/s 25i/s, 50i/s 25 i/s, 30 i/s,

d’image 50 i/s, 60 i/s,
100 i/s, 120 i/s

4 sur 29
Uncompresse Débit non 720 x 576 x
d Bit Rate compressé: 10 x 2 x 25 =
résolution x 207,16
ech x bit x i/s Mbits/s
(si en 4:2:2)

Duration Durée

Stream Size uncompressed taille du flux, poids, 207,16

bit rate x espace sur le Mbits/s x
duration disque de stockage donnée
externe (s)

CODEC Définition

Compression algorithm algorithme de compression (H264, MPEG2,…)

Lossy/Lossless avec ou sans perte

Inter/intra prédiction spatiale/temporelle

Profile @ level détermine les débits maximum et comptabilité du

fichier

GOP type de GOP utilisé

CBR/VBR débit constant/ débit variable

Quantification level niveau de quantification

Bit Rate nbr de bit

Stream size transformation d’un média

5 sur 29
D. ETAPES DE PRODUCTION
1. Etude de cas
Cahier des charges de fabrication.
Magazine de 26’ en deux parties composé de un ou plusieurs reportages et de
plateaux d’annonce.
Les reportages sont soit autoproduits sur base de tournages sur le terrain et
d’images d’archive, soit montés au départ de documentaires achetés en catalogue.
Ils sont illustrés par infographie.
Les plateaux de présentations sont enregistrés en studio en décor virtuel. Des
images extraites des reportages servent d’illustrations insérées dans le décor.
Les plateaux et les reportages font l’objet d’un assemblage global en vue de
constituer le produit à diffuser.
Le magazine est diffusé sur les chaines TV et en VOD sur les plates‐formes
numériques. Des extraits sont en outre mis en ligne sur les sites internet et en
mobile.
Le magazine est archivé sous forme de PAD et de Clean Feed.

6 sur 29
2. Modèle

E. TRANSFORMATION
1. Complexité
Shooting: une piste audio et une piste vidéo synchros
Editing: plusieurs pistes audios et vidéos désynchros
Archive: une piste vidéo et plusieurs pistes audios
Contribution: une piste vidéo et plusieurs pistes audios
Playout: plusieurs qualités: plusieurs pistes audios et vidéos mais synchro entre elles
Consumer:

2.Description
Shooting: label (titre), géolocalisation, sommaire
Editing: label, description, sommaire, textes, droits, musiques, sous-titres
Archive: label, description, sommaire, textes, droits, musiques, sous-titres,
classement, mots-clés, contenu (localisation ?)
Contribution: label, description, sommaire, textes, droits, musiques, contenu
Playout: label, titre
Consumer: titre, EPG (Electronic Program Guide), résumé

7 sur 29
3. Qualité

CONTAINER

A.UTILISATION
1. Transfert de media

Deux modèles scientifiques existent pour décrire une application :

1. OSI : Découpe du modèle en 7 niveaux allant de la simple application à l’état

physique du modèle. Trop complexe pour l’audiovisuel. PAS CONNAITRE.

2. Modèle simplifié : limité à l’ordre suivant « Contenu (Vidéo, audio, data) -> Format
de fichier -> Protocole de transfert (FTP, Client serveur, streaming) -> Réseau [SDI,
FC, Ethernet, IP] -> Physique [Coax, Fibre, Paire] », tout à fait applicable à
l’audiovisuel.

L’usage principal d’un container est de transporter et de donner l’accès aux fichiers
qu’il contient. Il a également un rôle de structuration du média qui permet de faciliter
la compréhension de ce dernier par un logiciel X.

8 sur 29
2. Partage de media

B. CONTAINER UNIVERSEL

C. MXF
CONTAINER OPEN SOURCE mis en place par un groupe d’étude reprenant
différentes institutions universitaires, industriels, professionnels du métiers,…

- Compatibilité sur les logiciels quel est le frein d’un transfert entre différents fichiers.
Ça dépend des plateforme (pc ou mac). Ça doit marcher aussi bien dans les
différents operating système. Ça doit fonctionner pour les différents codecs, formats,
résolutions, essences. Pas de contrainte qu’en à l’exploitation de ce type de fichier
- open source

Par rapport au AAF, le MXF échange des médias FINIS. Mais ils ont les mêmes
caractéristiques de base (caractéristiques d’un container).

1.Objectifs
La différence entre un fichier classique et un container c’est qu’il y a plusieurs
essences qui doit être synchronisées entre elle.

Par rapport à un fichier texte, le fichier de type MXF de moyenne à grande taille
nécessite un mécanisme de synchronisation vu qu’il contient de l’image et du son.

Fichier texte Fichier d’un container (plusieurs essence)

Petite taille : Grande taille, moyenne
=> Transfert rapide => Transfert qui prend du temps
Pas de problème de synchro Problème de synchro ? ESSENTIEL.

On va alors transporter le fichier par petit morceau en alternant de la vidéo et le son

qui lui aie lié pour pouvoir commencer à travailler sur le fichier synhcroniser ainsi que
le visualiser lors du transfert.

2. Caractéristiques d’un container:

• Multi-résolutions
• Partial Restore (Fragmentation de l’enregistrement, transport du fichier par petits
morceaux contenant un peu d’audio et de vidéo tous deux synchrones, schéma).
• Label (Indexaction)
• Prévisualisation (lors du transfert).
• Edit while move
• Agnostique au codec ainsi qu’à l’Operating System (indépendant du codec et du
support).

9 sur 29
3. Package:
Ensemble d’essence qui sont synchros entre elles.

Un container tel que le MXF a en plus de ses caractéristiques de base une notion de
temps présenté via le package qu’est un ensemble de matière synchronisée dans le
temps.

Ce package se découpe en deux parties :

- L’ensemble du fichier qu’est le file package, contenant tant la partie utile que les
données auxiliaires (mires, décomptes, noirs, etc.)
- Le material package, contant uniquement la partie utile.

Ils peuvent soit être confondus, soit être distingués.

Dans le cas où ceux-ci sont distingués, un material package peut-être la somme de
toutes les parties utiles des file packages.

En plus des données audio et vidéo classiques, des métadonnées (à valeurs fixes
pour l’ensemble de la piste, des event datas ou variables) sont également intégrées
au sein du file package.

- DM1 track : valeur différente en fonction du temps (sous titre) changer

- DM2 track : lié à un événement (évent metadata) plan particulier

3. Metadata structurelle
Les métadonnées structurelles organisent les données du package, tandis que les
métadonnées descriptives décrivent le contenu du package.

4. Operational Pattern
a) OPa — Single Package
• OP1a : Un seul Material Package lié à un seul File Package, tout deux de même
durée pour un même média.
• OP2a : Un Material Package pour plusieurs File Packages, le premier définissant
les seconds. Chaque File Package doit-être diffusé entièrement. (Playlist)

10 sur 29
 • OP3a : Un Material Package pour plusieurs File Packages, offrant en plus la
possibilité d’assigner les points In et Out pour chaque FP. (Sorte d’EDL)

b) OPb — Synchronised (Ganged) Packages (offrent la possibilité de diffuser plusieurs

contenus en même temps)
• OP1b : Un Material Package lié à plusieurs File Packages eux-mêmes
accompagnés par différentes données supplémentaires pour un même média.
• OP2b : Idem, mais sur base d’une playlist.
• OP3b : Idem, mais sur base d’une structure EDL.

c) OPc — Choice of (Alternate) Material Package (Offrent la possibilité d’inclure et de choisir

parmi différents Material Packages au sein d’un seul MXF)
• OP1c : Plusieurs Material Packages contenant plusieurs File Packages pour un
média.
• OP2c : Idem, mais sur base d’une playlist par MP.
• OP3c : Idem, mais sur base d’une structure EDL par MP.

d) OPatom : Version à part entière du container ne contenant qu’une seule essence. (Un
fichier par essence)

—> Réexplication plus claire:

OP1 : on montre le fichier du début jusquà la fin. MP = FP (1 seul fichier).

OP1a exemple: diffusion.
OP2: ordre de diffusion des différents file package. Exemple : tourner une séquence.
Rassemblement de tous les fichiers qu’on a tourné comme une playlist. Exemple :
produit sponsorisé. Pub avant docu pub derrière. Élément qui sont isolables et qui
sont diffusés complètement du début jusqu'à la fin. Dans un ordre que l’on veut.
Plusieurs file packages mis à la suite l’un de l’autre.
OP3 : Playlist comme EDL, on peut donner des in et out à l’intérieur des fichiers file
package. Vraie timeline de montage simplifié. Enchainement cut, pas d’effet.

OPa : files package s’enchainent. Se lisent l’un après l’autre.

OPb : on peut synchroniser plusieurs file package entre eux. Exemple d’un chroma
key: background = F1 et présentateur = F2. File package 1 et 2 doivent être
synchros.
Pour OPa et OPb il y a UNE sortie, le spectateur n'a pas le choix entre plusieurs
versions.
OPc : on a le choix: version
français ou anglaise etc.
OP3c exemple: plusieurs ours.

11 sur 29
5. Structure :
a) File Header (en tête) : Explique la structure du fichier
• Header Partition (table des matières).
• Header Metadata
• Index Table
b) File Body (contenu) : Contient les différentes essences
• Essence Container
c) File Footer (pied)
• Footer Partition
• RIP (fin du fichier)
Le contenu des essences est encodé selon une structure KLV : Key (Type de
donnée), Length (Durée des données) Value (Données à proprement parlé)
Toutes les essences de tout MXF sont toujours multiplexées entre elles. Multiplexées
= prendre plusieurs infos et les mettre ensemble. Pour y arriver, 2 choses:
- alterner les différents éléments qui constitue une unité (alterner son, vidéo,…).
- savoir les retrouver (grâce à la partition).

12 sur 29
6. Résumé
Le MXF est donc un excellent container de diffusion, mais pas de post-production
parce qu’on ne peut pas revenir en arrière dans la post-production.

Le MXF peut être self-content ou faire référence à d’autres fichiers MXF qui
contiennent les essences. Quand on fait play sur le MXF principal il prend donc l’utile
des autres fichiers.

Voir schéma pour les détails dans pdf prof

D. AAF (Advanced Authoring Format)

1. Objectifs
Né d’un problème de transfert de fichier, l’AAF existe pour permettre l’échange de
sessions de travail en postproduction de manière facilitée tout en conservant
différents éléments :

- Les effets et autres transitions audio ou vidéo.

- La possibilité de modifier le montage.
- La possibilité de faire des allers-retours entre différents logiciels de postproduction.

La flexibilité de l’AAF réside dans la possibilité de choisir les éléments pris en charge
et réellement utiles dans un logiciel X, tout en ne faisant que référence à des
essences externes à celui-ci.

2. Structure

3. Application

13 sur 29
 ESSENCES
A. ESSENCES USUELLES HD
1. Comparaison
Seulement 1940 pixel en horizontal pour le 3 :1 :1

HDCAM:
- Bande magnétique
- Particularité : meilleure qualité proche du non compressé et débit élevé. Pas bcp de
risque d’avoir des artefacts
- Genèse des supports HD
- Seulement 1940 pixel en horizontal pour le 3 :1 :1

HDXDCAM:
- Il y a un gop
- inventé par sony
- très rependu
- format de pad le plus courant
- on le retoruve un peu partou dans la chaine de production

DNxHD:
- simple
- MJPEG un peu particulier, basé sur le MJPEG
- Full résolution
- post-prod
- bonne qualité
- débit élévé

Prores
- codec propriétaire
- proche du mjpeg
- Full résolution
- utilisé pour la postprod
- pas acquisition

AVC-I
- acquisition
- H264 limité à de l’intra
- on utilise que les images I

Le codec qui donne la meilleure qualité :

- HDXDCAM SR
- Codec un peu près la même qualité
- A qualité identique le plus lourd ce sont les codecs MJPEG
- AVC intra avec un codec à H264
- HDXDCAM coût moindre
- Multi générations comment codec résistent. Ils n’ont pas tous la même résistance.
- Tous les codecs listés ont à peu près la même qualité, le débit n’influençant pas
réellement le résultat final en fonction de l’encodage employé.

14 sur 29
E. ARTEFACTS DE COMPRESSION
Les artéfacts au sein de workflows différents proviennent souvent de générations
excessives, de changement de codec en cours de postproduction ou d’un manque
de constance dans les tables de quantifications, qui sont censées rester identiques.

1. Blur rigging

2. Blocking

15 sur 29
3. Causes
Autres causes :
• Changement de codec
• Changement de débit
• Changement de résolution colorimétrique • Changement d’échantillonnage
• Changement de table de quantification
• Etc.

Idéalement, il est toujours mieux de travailler un maximum avec l’essence (codec +

format) native. Sinon, il vaut mieux appliquer une essence dès l’ingest qui sera
utilisée durant toute la post-production.

F. EDITING
1. Essence natif
Quatre situations existent :

a) Codec Intra
- Pour un montage cut, la perte de qualité sera virtuellement nulle même avec un
rendering lors de l’export.
- Pour un montage avec effet de transition (chevauchement), un recalcul (avec
perte de qualité) est nécessaire pour les images subissant la modification.
- Enfin, lors de l’application d’un effet sur l’ensemble de la timeline ou sur un rush de
celle-ci, la totalité ou celui-ci spécifiquement nécessiteront un rendering avec
perte.

b) Codec Inter
- Pour un montage cut, toute coupe impose un nouveau traitement du flux vidéo afin
de recalculer le GOP sur base du Smart Rendering.

16 sur 29
2. Essence mezzanine
Lors de l’import d’essence ayant un codec ne pouvant être édité nativement, il est
nécessaire de passer par une essence mezzanine transcodant l’intégralité des
médias avant editing (obligé même si inconvénient de transcodage et donc de
réduction de qualité).
- Pour un montage cut, il n’y aura pas de retraitement à réaliser.
- Pour toute autre opération de montage ou application d’effet, un processing sera
nécessaire.

Un changement de container
n’apportera pas de perte de
qualité, sauf pour une transition de
AFF vers MXF.

G. GENERATION
1. Définition
Chaque modification de contenu imposant un rendering implique une génération.

17 sur 29
4. Influence du format
Lors de l’application d’un upscaling pour le produit final, il est toujours mieux
d’effectuer celui-ci en amont de la postproduction. Si l’upscaling est effectué en fin de
chaîne, les défauts de compression ainsi que les différentes pertes de qualité
découlant des générations précédentes seront agrandis à l’image.

5. Influence du codec
Toute réduction de codec doit obligatoirement se faire en fin de chaîne pour éviter
toute dégradation inutile.

18 sur 29
6. Scénario

7. Règles

SUPPORT

A. TYPES
Le support de stockage est l’endroit où les données audio, vidéo encapsulées seront
stockées après captation. Sans celui-ci, le fichier n’a pas d’existence
physique.Jusqu’il y a quelques années, les supports de stockages étaient
exclusivement dédiés aux médias vidéos.

19 sur 29
- Médias non-linéaires
* Disques optiques à haute densité (Blu-Ray, Professional Disc, etc.)
* Cartes mémoires (SxS, Compact Flash, etc.)
* Disques durs (Classique, SSD, SAS)

- Médias linéaires
* Bandes magnétiques (LTO)
* Cassettes

B. SECURISATION TECHNIQUE

1. RAID 0
• Informations dispatchées sur plusieurs disques, mais sans sécurisation.
• Avantage: vitesse beaucoup plus grande (pas de doublons etc..)
• Inconvénient: sécurité quasi nulle (un disque crash, toutes les données peuvent
être perdues)
• = une unité de stockage sur lequel on met toute la matière (informations différentes
sur chaque disque).

2. RAID 1
• Informations dupliquées sur deux disques en parallèle.
• Avantage: backup disponible si l’un des deux disques crash.
• Inconvénient: coût plus élevé
• Inconvénient: espace moins important (2To en RAID1 = 1To utile) car 1 disque
rempli = 2 disques remplis • - Vitesse moins élevée (copie de 2 x la même
matière
• 2stockages en miroir: un stockage main et un back up. Pas accessible séparément
• Si un crash, le serveur peut continuer à fonctionner, car chaque disque possède
son propre contrôleur.

3. RAID 5
• Informations sécurisées par l’ajout d’un bit de parité sur chaque disque.
+ Ajout d’un bit de parité (information complémentaire permettant de détecter une
erreur de bit) sur chaque disque permettant de sécuriser à un plus haut niveau les
différentes données.
• Grâce à cette valeur, il est possible de récupérer les données présentes sur un
disque crashé à partir d’un des autres disques du RAID.
+ Vitesses plus élevées qu’en RAID0 ?
+/- Compromis entre RAID0 et RAID1, soit entre vitesse (RAID0) et sécurité
(RAID1).
- 25% de coût en plus par rapport à un RAID0.
- Le système n’est plus utilisable tant que le disque défaillant n’est pas remplacé.
- Au maximum une perte de disque est acceptée. S’il y a plus qu’un seul disque
perdu, la récupération des données n’est pas possible.
- Vitesse limitée au maximum physique de chaque disque.
- Bits de parités répartis différents disques de la grappe:
améliore l’accès aux données, aussi bien en lecture qu’en
écriture.

20 sur 29
- Plus intéressant, résiste mieux aux pannes d’un disque, mieux performance et
fiabilité.

4. RAID 6
• Informations sécurisées par l’ajout de plusieurs bits de parité sur chaque disque.
+ Même principe que le RAID5, avec l’avantage de pouvoir perdre jusqu’à 2 disques
maximum.
- Vitesse limitée au maximum physique de chaque disque.

NB (pour tous les RAID): DRP (Disaster Recovery Plan) : sécurité: 40km de distance
au minimum sont nécessaires entre deux localisations de chaque back-up.

C. SECURISATION OPERATIONNELLE

D. OPERATING SYSTEM

E. DIMENSIONNEMENT DU SUPPORT

APPLICATIONS

Digital cinema / Digital intermidate

Production News RTL-Tvi

21 sur 29
Production News Télé Bruxelles
Production multi caméras (captation spectacle)

A. STUDIO A L’EQUIPE
Toute la chaîne de post-production se déroule au même endroit (au studio).
Pour quelque film que ce soit, un workflow technique qui déterminera tout le flux de
postproduction ainsi que son intégrité générale, financière et organisationnelle.

1) Support d’enregistrement de l’image (pellicule ou numérique)

Le premier élément à prendre en compte lors du choix du style d’image est le format
de cadrage.
Slide 148 prof: formats
Suite au choix du format de cadrage, on choisit si numérique ou pellicule, et si on
choisit pellicule: quel type de pellicule (2 perfs, 3 perfs, 4 perfs..)
Il y a deux manières d’enregistrer les formats: anamorphique (Scope ou SD) ou
sphérique.
Numérique: le format impose la définition/résolution de l’image.
2) Conversion pour le montage
Workflow: passage du shooting au montage.
Développement numérique:
- Film lab
- téléciné (numérisation de la pellicule)
- référence image
- labroll
- tc
- cinema tools

• Cinema digital intermediate:

On part de la pellicule et on revient à la pellicule
Matière arrive qui va suivre 2 chemins:
1) télécinéma: numérisation complète de la matière, pas excellente qualité
(stockage réduit, outils simples de montages,..), post-production sur des proxys
(basse résolution). Important de garder une trace parfaite entre les bobines et les
proxys, savoir quel fichier vidéo correspond à quelle endroit de la pellicule (=
fichier flex), cohérence entre les deux côtés —> utile car après montage on doit
retrouver le bout de la pellicule qui correspond au proxy utilisé dans le montage,
qu’on numérisera par la suite.
EDL: comment on va matérialiser le montage. Fichier texte descriptif de ce qu’on a.
(Normalement plus besoin avec MXF mais vieille habitude).
DPX = image par image non compressé. Fichier = 1 image.
2) Numérisation des bobines seulement utiles (plus cher, en meilleure qualité).
Le téléciné sert juste à être moins couteux pour faire le montage.
On applique l’EDL aux différentes images DPX (numérisation des bonnes bobines).
Database permet de garder la cohérence entre ce qu’on modifie et la bobine —>
matérialisation du fichier flex.

Ensuite, après la conformation, étalonnage avec application des lut (demander à

Lola lut).

22 sur 29
Kinescopale: repasser en pellicule (recorder).
Gather = rassembler. Togather : rassembler tous les médias pour le média final.
Rendering et effets spéciaux va et viens.

LUT: Table de conversion. En 3D les valeurs des primaires sont liées.

Lois colo: SD et HD TIV.
En fonction de ce qui sortira pour la diffusion on appliquera tel ou tel lut.
En 3D: chaque triplet de valeur donne un triplet de primaires alors qu’en 1D, le rouge
vaudra toujours la même chose peu importe les valeurs des vert et bleu
(indépendance).

SCHÉMA BLOC WORKFLOW (refaire)

- Qu’est ce que c’est DCP
- Support quel genre ?
- Camroll ?
- Labroll ?
- Export Pull list
- Film out put, film recorder
- Quelle est la différence entre EDL et Export Pull list

B. Production News RTL-Tvi

Enregistrement basé sur du HD-XDCAM (SxS) encapsulé en MXF incluant deux

versions du flux : une version HD (XDCAM 50 Mbps) et une version proxy (H.264
@1,5Mbps)

Un proxy est un composant logiciel informatique qui joue le rôle d'intermédiaire en se

plaçant entre deux hôtes pour faciliter ou surveiller leurs échanges. Du OPc parce
que permet d’avoir plusieurs version de package.

Deux systèmes de stockages sont disponibles (High res et Low res) + Datables

1. Le serveur High Res s’occupe de la gestion des natifs, réalisée après import des
proxies
2. Serveur Low Res s’occupe de la gestion des version H.264 (proxy). Est ce que
vous utilisé seulement l’essence H.264 ??? Directement disponible dans les 30
sec de l’exécution (grâce au container). Les editings se réalisent quasi toujours sur
base des Low Res. Divisé en deux parties :

a) Offline de stockage: pas disponible directement (high res, archives).

b) Online de stockage: disponible directement (low res).

3. DataBase permettant la "conformation" des médias LowRes avec les HighRes sur
base de l'EDL créé en arrière-plan sur le logiciel de montage maison. L’EDL effectue
la conformation (qui n’existe pas en tant que telle) en temps réel (incluant opération
de transcodage, upscalling,…) grâce de la database effectuant la sélection des natifs
nécessaires. Le tout se faisant en temps réel, le rendering n’est pas nécessaire ou

23 sur 29
n’est pas pris en charge. Si des High Res ne sont pas disponible on utilise les low
Res

LTO : Linear tape – open technique de stockage sur bande magnétique au format
ouvert.

ENEX : les médias provenant des fournisseurs externes type ENEX sont toujours
convertis afin de correspondre aux formats utilisés IN-HOUSE.

1. 1. XDCAMCamcorder
1.1. Deux flux sous MXF (HD et LowQ H264)
1.2. Rush LowQ + Rush Natif + Référence DataBase
1.3. Archivage et référencement de tous les médias
1.4. Editing Low Res suivi d’un EDL pointant vers les références des natifs
1.5. Restore des natifs sur base de l’EDL
1.6. Playout sur base des natifs lus et enchaînés en temps réel.
1.7. Purge/Nettoyage réalisé 1 fois par nuit permettant de consolider les
médias utilisés
(avec poignées en IN et OUT - toujours sur base de l’EDL) et de supprimer le
reste. Un archiviste dédié a toujours un droit d’ajouter des portions de média
supplémentaire à archiver.
1.8. Pour les archives à long terme, l’intégralité du média est toujours archivée
et indexée avec une description complète.

2. Flux
2.1. Encodage en temps réel des deux types de résolutions
2.2. Rush LowQ + Rush Natif + Référence DataBase
2.3. Archivage et référencement de tous les médias
2.4. Editing Low Res suivi d’un EDL pointant vers les références des natifs
2.5. Restore des natifs sur base de l’EDL
2.6. Playout sur base des natifs lus et enchaînés en temps réel.
2.7. Purge/Nettoyage réalisé 1 fois par nuit permettant de consolider les
médias utilisés
(avec poignées en IN et OUT - toujours sur base de l’EDL) et de supprimer le
reste. Un archiviste dédié a toujours un droit d’ajouter des portions de média
supplémentaire à archiver.
2.8. Pour les archives à long terme, l’intégralité du média est toujours archivée
et indexée avec une description complète.

3. MédiasExternes
3.1. Transferts en Natifs
3.2. Création Rush LowQ + transfert et/ou transcodage Rush Natif +
Référence DataBase
3.3. Archivage et référencement de tous les médias
3.4. Editing Low Res suivi d’un EDL pointant vers les références des natifs
3.5. Restore des natifs sur base de l’EDL
3.6. Playout sur base des natifs lus et enchaînés en temps réel.
3.7. Purge/Nettoyage réalisé 1 fois par nuit permettant de consolider les
médias utilisés

24 sur 29
 (avec poignées en IN et OUT - toujours sur base de l’EDL) et de supprimer le
reste. Un archiviste dédié a toujours un droit d’ajouter des portions de média
supplémentaire à archiver.
3.8. Pour les archives à long terme, l’intégralité du média est toujours archivée
et indexée avec une description complète.

4. Archives
4.1. Référencées et tagées
4.2. Archivage et référencement de tous les médias
4.3. Editing Low Res suivi d’un EDL pointant vers les références des natifs
4.4. Restore des natifs sur base de l’EDL
4.5. Playout sur base des natifs lus et enchaînés en temps réel.
4.6. Purge/Nettoyage réalisée 1 fois par nuit permettant de consolider les
médias
utilisés (avec poignées en IN et OUT - toujours sur base de l’EDL) et de
supprimer le reste. Un archiviste dédié a toujours un droit d’ajouter des
portions de média supplémentaire à archiver.
4.7. Pour les archives à long terme, l’intégralité du média est toujours archivée
et indexée avec une description complète.

C. Production News Télé Bruxelles

1. Télé Bruxelles : présentation
- Chaîne︎ régionale ︎bruxelloise︎ francophone
- 50︎ personnes︎ employées
- Télé︎Bruxelles ︎produit︎ et ︎diffuse ︎des ︎programmes︎ axés︎ sur ︎l’actualité︎ socio
politique︎ culturelle et︎ sportive.
- Disponible︎ sur ︎le︎câble,︎ Proximus TV︎ et la ︎TNT (télévision numérique terrestre).
- Diffusion ︎24/7︎ (Multi diffusion︎ quotidienne︎ 2︎heures)
- Production:︎
*14︎heures︎ de ︎productions︎ hebdomadaire.
*474︎heures︎ de︎ productions ︎propres︎ en︎ 2014
*291︎heures ︎de︎ co︎production ︎en ︎2014
~︎62%︎des︎ programmes︎ diffusés

2. Le news
Les ︎contenus ︎d’information ︎sont︎ produits ︎par ︎la︎ rédaction︎ de︎Télé︎Bruxelles.
︎Sous︎ la︎ direction︎ du ︎directeur︎ de ︎l’information ︎la︎ rédaction ︎est ︎composée:
- Un ︎rédacteur ︎en ︎chef
- 14︎journalistes
- 5 Cameraman

Deux︎ JT︎ quotidiens ︎en ︎direct

- 12h30︎(~︎12min)
- 18h00︎(~︎22min)

Chaque︎ JT︎ est︎ composé

- une ︎présentation ︎en︎ studio

25 sur 29
- 2︎ duplex ︎par ︎édition
- entre ︎8︎ et︎ 12 ︎sujets︎ d’information ︎par ︎édition

Dispositif︎ de ︎production ︎quotidien ︎des ︎JT

• 5︎ équipes ︎de ︎tournage︎ (équipe︎=︎couple︎ journaliste/cameraman)
• 1︎Réalisateur
• 2︎Rédacteurs ︎en ︎Chef
• 1︎ingénieur ︎du ︎son
• 2︎ monteurs
• 1︎opérateur︎ caméra︎ studio
• 1︎opérateur︎ VTR (création des playlitsts du JT)
• 1︎infographiste
• 1︎Opérateur︎ Régie ︎Finale︎(ORF)
• 1︎technicien︎ en ︎support
• 1︎script
• 1︎présentateur/présentatrice

3. L’infrastructure technique
a) Acquisition
Caméra ︎ENG (équipe de tournage) :︎Panasonic︎AJ︎HPX︎2100
Support︎ d’enregistrement:︎P2
Définition:︎ Standard︎720︎x︎576
Compression ︎Vidéo: ︎DVCPro 25 (codec ou essence) ???
Compression ︎Audio:︎ PCM︎48khz︎24︎bits
Encapsulation (container):︎ MXF︎OpAtom => OPatom : Version à part entière du
container ne contenant qu’une seule essence. (Un fichier par essence).

b) Post-production
Edition︎virtuelle:︎FinalCut Pro7
Gestion︎ et ︎partage ︎des︎ projets: ︎MXFserver
Stockage: ︎IBM (International Business Machines)
Encodage:︎ Rhozet
Outils:︎ L’application︎ Workflow

c) Régie de production
Mélangeur︎ vidéo:︎ Thomson︎Xten DD35
Habillage:︎ Pixel︎Power︎Clarity
Diffusion: ︎Omneon MediaGrid
Contribution︎IP︎3/4G: ︎Mobile︎Viewpoint

4. Schéma fonctionnel JT

Schéma: 1er schéma: deux serveurs (un pour la post-prod et un pour la diffusion)
Cartes mémoires pour pouvoir monter sur les ordis

2ème schéma: On va d’un support de stockage particulier (une carte P2) à un

serveur de stockage MXF.

26 sur 29
FTP = serveur où on peut

Nodal: Local TV où se concentre et où sont distribués tous les signaux sources.!

9. Conclusion
• Partage,︎accessibilité︎et︎publication
• Gestion︎des︎assets
• Archivage
• Gestion︎des︎conduites

Partage, accessibilité et publication old style (nécessité d’interpeler les personnes

ayant les informations)
Gestion des assets (Absence de MAM pour les stations de montage)
Archivage (effectué manuellement)
Gestion des conduites

Télé Bruxelles ne repose donc pas sur une infrastructure news, mais bien sur un
type de workflow bien mieux adapté à des productions télés et/ou ciné.

10. Work in progress

• 08/2015:︎Intégration︎Dalet News︎Suite
• 08/2016:︎Production︎HD

• 08/2015 : Intégration Dalet News Suite • 08/2016 : Production HD

----

• Beaucoup de codecs
• Encore diffusion en SD
• Beaucoup de postes encore présents • Une multitude d’opérations manuelles
• P2 / DVCPRO / SD / MXF ATOM (toutes les essences sont séparées)
• Stockage en QT sur serveur avec conversion de container (MXF vers QT)
• Edit sur FCP7
• Stockage supplémentaire LTO via IBM (HSM)
• Pour récupérer archive : MAM -> ID -> HSM -> Sélection bande LTO-4 • Omneon
Server (DiFR)
• Encodage en // en H.264 pour web --
CMS : Content Management System
NRCS : News Room Computer System (Outil prenant en charge la gestion de tous le
contenu de la rédaction)

27 sur 29
D. Production multi caméras (captation spectacle)
• Programme de 65 minutes
• 3 jours de tournage monocam
• 1 jour d’installation multicam
• 2 spectacles sur 1 jour
• 1 équipe Multicam 6 caméras
• Caméras fixes

28 sur 29
Choix des codecs
• Caméra monocam fournie par RTL-TVI
• Volonté de travailler avec des caméras à grand capteur type FS100
• Montage à RTL sur Media Composer
• Format de diffusion imposé

Monocaméra
ENG sur base d’une C100 tournant avec des Compact Flash en XDCAM HD.

Multicam
Flux classique :

• Différentes caméras avec car de captation reliées à des CCU (caméra contrôle unit)
• Enregistrement en XDCAM HD sur PGM (format de fichier graphique utilisé pour
les échanges) + en divergé sur un serveur en DNxHD.

Flux employé dans le cadre de ce projet :

• 6x FS700 tournant en AVCHD sur cartes SD
• Une Arri Amira mise sur une TowerCam et enregistrée via un PiX
• Le choix de cette caméra fut décidé sur base du type de monture (PL) ainsi
que sur la possibilité de contrôler l’objectif à distance
Enregistrement sur un Sound Device PiX via HD-SDI en DNxHD avec stockage sur
SSD
Le tout envoyé sur une table mélangeur et est enregistré en backup sur PGM
(XDCAM HD) et sur un système HyperDesk Blackmagic sur SSD (DNxHD).

En plus de cette installation, un Canon 5D fut placé en bas de scène

Enregistrement réalisé sur CF en MPEG-4 converti ensuite en post en DNxHD.

Codecs
• XDCAM HD (Monocam)
• DNxHD (Multicam)

Filling
Tous les médias en XDCAM HD et DNxHD sont intégrés au sein de Media Composer
directement sans conversion.

Montage
Le montage se base sur un système Interplay permettant le travail collaboratif sur
un même projet.
Le mixage se réalise quant à lui sur ProTools.

Postproduction et diffusion
La diffusion finale se réalisera en XDCAM HD.

LSM = Live Slow Motion

MAM : Media Asset Managemen

29 sur 29