Thread by @_prae_

Défi confinement #SMPTE, lire les quelques 300 documentations techniques et normes du cinéma.

Déjà, ce qu'on peut constater que les premières normes éditées & publiées démarrent en 1996: On commence par la télévision, puis on passe par le Cinéma (70mm, 35mm, 16mm, 8mm), un petit retour sur la télévision puis un gros retour Cinéma numérique. En tout plus de 600 documents.

Dans le monde, on a du 24 images/seconde (cinéma), du 25 (télévision), du 30 (télévision new-gen) et puis on a un à 29.97 bâtard pour la télévision US (NTSC). Pourquoi ? 30/1.001=29.97. Mais pourquoi faire un drop-frame ? Pour la rétrocompatibilité noir et blanc de la TV NTSC !

Dans la norme SMPTE-96M, on te donne un tableau récapitulatif d'un film au format cinéma vers un format télévision 16/9.

Vous voyez dans les films, le petit passage bizarre au démarrage d'un film 35mm: Le début de la première bobine d'un film comporte des éléments informatifs et sont ultra-codifiés et normalisés à l'image près. Et pas le droit de déborder ! (SMPTE-55)

Le truc le plus pété du monde du cinéma 35mm : Pourquoi les bobines font 610 mètres ? C'est vrai, pourquoi le chiffre 610 et pas 600 ou 500 ? Bah, 610 mètres correspondent à 2000 ft (pieds). #ViveLeSystemeMetrique (SMPTE-192)

Il existe plusieurs formats de pellicule: 8mm, 16mm, 35mm, 65mm et 70mm. Et certains permettent même de stocker les formats plus petits dans d'autres formats plus grands. (SMPTE-184)

Je ne pouvais pas éviter la norme SMPTE-268 sur le format DPX, le format d'image Cinéma ! Niveau bit-depth, on peut monter jusqu'à 64 bits ! Et pour la cryptographie, la clef ne peut être que de 32 bits maximum et donc être faible pour certains algorithmes :-/

Les identifiants (UUID ou URN) commencent par 06.0E.2B.34 sont des identifiants SMPTE réservés. smpte-ra.org/class-1314-reg… (SMPTE-298)

Pour compléter à propos du début et fin de bobines 35mm, voici les détails des photogrammes (SMPTE-301)

J'ai mis un peu de temps, mais voila: Enfin terminé la lecture de la norme du format télévision et cinéma MXF. 183 pages.
Attention, désolé par avance: je vais être un peu technique pendant les 3-4 prochains tweets.

Petit préambule: le format MXF est devenu la norme pour la diffusion en télévision et au cinéma et prochainement pour le stockage long-durée d'oeuvres cinématographiques (IMF). C'est donc un format important dans le milieu audiovisuel.

Le format MXF est comme un jeu de LEGO, ce sont des briques qu'on pose l'une après l'autre. Ces briques sont des KLV (Key-Length-Value): La première partie est une clef d'identification, puis la taille de la partie V et enfin, les données. 2/..

Les clefs (16b) débutent toujours par "060e2b34". Les valeurs (les données) sont soient des données structurés (pour avoir des metadatas, soit le contenu brut). Par exemple, pour une image d'un film, le JPEG2000 (non chiffré) est directement placé dans la partie Value.

Chaque image d'un film est ensuite empilé par une succession de LEGO (KLV). Après lecture de ce pavé, j'ai pu écrire un parser MXF qui fonctionne à merveille ! (et qui me servira pour mes futurs travaux).
Fin des tweets techs, je ferai peut-être un papier-résumé pour + d'infos :)

On continue le défi "lecture": Le chiffrement du SDI est basé sur de l'AES-128 pour le chiffrement flux, sa clef AES est chiffrée elle-même en RSA-2048 (RSA_oaep_mgf1p_sha1_2048 pour être précis). Et que la clef change périodiquement afin de sécuriser le flux vidéo. (SMPTE-427)

Et en lisant cette norme, on constate que le protocole d'échange SDI prévoit des évolutions (meilleure crypto par exemple) car quand on lit entre les lignes, on voit qu'ils ont réservés des paramètres et valeurs pour de futurs algorithmes cryptographiques.

A l'heure actuelle, j'en suis à 319 documentations lues sur les 503 que j'ai en ma possession. Et au fur-et-à-mesure du temps, les papiers sont plus volumineux que les premiers. J'espère ne pas saturer avant la fin tellement il y a beaucoup à lire. #SMPTE #challenge

Je ne fais pas de compte-rendu sur chacun des papiers lus car cela serait trop long et chiant pour tout le monde, je tweete que ce que je trouve important, étonnant ou pertinent pour moi et/ou les gens.

Pour ceux voulant calculer rapidement le nombre de couleurs au total par rapport rapport au bit-depth, je vous ai fait un petit résumé en image rapidos

Suite de la lecture SMPTE, j'avais fait une pause. Auparavant, j'avais lu une grande partie du SMPTE-429 qui porte sur le cinéma numérique: Pictures/Sound Track, MXF JPEG200 Track, TimedText Track (les sous-titres). La partie "Essence Encryption" m'a particulièrement intéressé

Pour le SMPTE-429-6 (Essence Encryption), la norme diffère de ce que j'ai constaté sur un MXF. Dans les tableaux, les données diffèrent: il manque les tailles entre chaque bloc de données (ou alors j'ai loupé une phrase dans ce pavé). Je reviendrai dessus plus en détail + tard.

Et là, j'attaque le SMPTE-429-7 sur les fameuses Composition Playlist (CPL), élément important de tout film cinéma numérique. C'est une version des normes de base n'évoquant pas encore les pistes auxiliaires (AuxData) permettant de jouer du Dolby Atmos ou du DBox (cinéma 4DX)

Si je devais retenir un truc: Chaque AssetType (Picture, Sound, Subtitle, Marker) est dépendant d'un autre (GenericAssetList), j'ai fait un petit résumé en image avec les valeurs et options. Le sous-type récupère tous les attributs de son parent (cf. Id, EditRate, ...)

Niveau "Marker", ce sont des marqueurs permettant d'identifier certains moments clefs du film (tableau 1) et tributaire du type du film (tableau 2).
Et le petit détail marrant: une bobine ne peut pas être de moins d'une seconde.
Fin du SMPTE 429-7 (CPL)

J'ai oublié quelques éléments:
- Le hash est calculé en SHA1 + Base64
- La différence entre IntrinsicDuration et Duration: IntrinsicDuration est la durée totale de l'asset de la bobine, Duration est la portion qu'on souhaite utiliser en projection (en utilisant l'EntryPoint)

Je passe sur SMPTE 429-8 et 429-9 : PackagingList (PKL) & AssetMap des films numériques. Pas grand chose à dire, hormis que j'ai enfin trouvée le passage dans la norme qui dit qu'on peut avoir plusieurs PKL dans un DCP (non référencé dans la 429-8 bizarrement)

On passe la stéréoscopie avec le SMPTE-429-10.
Pas grand chose de neuf, hormis que le MainStereoscopicPicture est une instance PictureTrackFileAssetType (voir tweets précédents)
Et on commence toujours le film, la première frame dans le MXF, est l'image pour l'oeil gauche.

Pour relier avec la suite du fil :

https://twitter.com/_prae_/status/1251664486618017792?s=20

On passe au SMPTE-430-1: KDM (les messages contenant les clefs de déchiffrement des films cinémas). C'est seulement une base de normalisation. Les éléments à retenir sont principalement la structure du CipherValue contenant les métadonnées et les clefs pour le film (AES)

Cette partie est chiffrée avec l'algorithme RSA-2048+OAEP, le tout englobée dans du base64. Chaque clef est identifiée par un type (MDIK, MDAK, ..) que vous retrouverez dans les CPL et les KDM (en 15 ans, jamais compris l'utilité, hormis identifier le type ... qu'on connait déjà)

Petite info pour labos cinéma sur l'Atmos: certains matériels Dolby ne supportent pas d'avoir un KDM sans clef de déchiffrement pour les pistes Atmos. Même si, chiffrer les pistes Atmos, est optionnel (cf. règles de Dolby). Seule solution: faire de l'Atmos chiffré quand même…

Ces parties deviennent + techniques. Dans les 1ères normes SMPTE, on parlait surtout de 16, 35 et 70mm et cela parle (quasi) à tout le monde. Mais avec les dernières normes, je pense que beaucoup vont décrocher car trop technique. N'oubliez pas de mute le thread si pas intéressé.

Quand le cinéma numérique faisait déjà du blockchain avant la hype de 2008. Dès le début du DCI (2006), les journaux d'activité en salle cinéma devaient être parfaitement certifiés: chaque évènement était loggué et avec un peu de crypto, authentifiait l'évènement et son précédent

La norme cinéma SMPTE-431-1 défini les bonnes performances cinématographiques en projection numérique (Luminance, Chrominance et Uniformité). Autant vous dire que pas mal d'exploitants ont du mal à respecter 😋 (sauf s'ils font leurs maintenances correctement avec un calibrateur)

Suite du SMPTE: Je pensais que la "zone sécurisée" dans l'image (vidéo) était une technique qu'on s'échangeait entre techniciens de l'image, mais je m'aperçois qu'elle est défini dans le SMPTE-2046: Elle définit une zone où ne doit placer des informations essentielles

dans l'image et le rendu, cela afin d'éviter que - si la régie finale, les intermédiaires techniques ou l'écran du spectateur ne coupe l'image - l'essentiel de l'information de cette dernière reste compréhensible pour le spectateur.

Dans le SMPTE-2048-1 "Digital Cinematography Production Image Formats FS/709", on y retrouve pas mal d'information sur les systèmes colorimétriques, les FS-Log/Gamut et notamment les règles de conversions BT709 RGB vers XYZ

SMPTE-2065-1.2012: Academy Color Encoding Specification (ACES), le nouveau système de gestion des couleurs pour le cinéma qui va devenir la référence ultime entre le plateau, la postprod, la projection et la préservation.

Résumé: Un espace colorimétrique RGB additif. Les primaires rouges/vertes/bleues entre les valeurs 0.0000 et 1.0000 (16bit), le Color Component est entre -65504.0 et +65504.0. Un workflow de conversion stable. Le ACES intègre tous les ColorSpaces habituels (RGB, DCIP3, REC2020)

Une référence dans l'industrie avalisée par l'Academy of Motion Picture Arts and Sciences (~Oscars), l'industrie cinématographique, les constructeurs de caméra et workflow postprod, etc.
Quelques références pour en savoir plus:
- chrisbrejon.com/cg-cinematogra…
- premiumbeat.com/blog/what-is-a…

J'ai oublié ce lien vers le site de l'Academy of Motion Pictures Arts and Sciences (AMPAS) sur la documentation ACES: oscars.org/science-techno…

SMPTE-2065-4.2013 est intéressant, c'est la description du format de fichier ACES Image Container. Il reprend les bases du format OpenEXR développé par Industrial Light & Magic (ILM) et complété par Disney, Sony Pictures, Pixar, DreamWorks, etc. et intègre ces ajouts spécifiques

Ce format de stockage des images sera utilisé pour la production cinématographique pour permettre de conserver sur toute la chaine de production la qualité de l'image et des metadatas associés.

D'un point de vue technique, chaque couleur est sur 16f bit (j'imaginais plus, en sachant que l'OpenEXR peut aller jusqu'à 32f). Qu'il y a une gestion stéréoscopique (étonnant, il considère que l'image primaire est celui de l'oeil droit :) et au niveau metadatas (..)

il y en a tellement, cela va des classiques données sur l'image du film mais aussi la position de la caméra dans espace tridimensionnel, sa direction visuel, etc. ainsi que des données de la caméra, de la lentille (même ses attributs), du focus, de l'exposition de l'image, etc..

Pour le coup, je n'ai pas encore vu passer ce format, au détriment du DPX, mais je me demande si cela ne va pas être son remplaçant pour les générations à venir dans le monde du cinéma et la postproduction (vu comment cela est défini, c'est envisageable)

Note: vu que j'ai regardé rapidement les titres des autres documentations et que je vais arriver au format IMF (format master pour l'audiovisuel/cinéma, utilisé par pas mal d'acteur déjà comme Netflix & Canal+), je vois déjà la logique du biniou: ACES File Container -> MXF -> IMF

Révélation: dans l'IMF, il y a le support du Karaoke ! Je tombe de haut 😆

Pour compléter: DCP peuvent avoir plusieurs PKL & plusieurs CPL: "AssetMap can contain mappings for more than one package - AM is used to locate the PKL(s) which detail the contents of available package(s). Assets are chosen from the PKL(s) and the selected assets are ingested."

Suite des docs sur l'IMF, j'ai lu SMPTE 2067-20 à 2067-50 qui évoque les "applications" possibles, ex formats d'image acceptés dans l'IMF. Sans être étonnant, nous avons donc du JPEG2000 et MPEG4. Chaque "Application" IMF correspond à une utilisation: Télévision, Cinéma, Archives

On y retrouve une des applications possibles de l'IMF nommée "Cinema Mezzanine" permettant d'avoir des images 16bits (DCP=12) allant jusqu'à 8K ! (son application/utilisation est pour de la préservation cinématographique par exemple). Et bien entendu, une version pour l'ACES 😃

Je me demandais s'il y avait une spécification "App" IMF avec des images non compressées. Effectivement, c'est l'App #1 - probablement défini dans les docs SMPTE ST-2067-1 à 19 [Core]: MXF avec du DPX non compressés. (ils me manquent certains SMPTE-2067 dans ma collection)

Un bon résumé rapide des différentes "Apps" IMF suivant le type d'utilisation (Cinéma/TV). Je découvre aussi que l'App#4 a une "traduction" normée effectuée par la @cstis sous le nom de code CST-RT-021: cst.fr/recommandation…

Les principaux et premiers "utilisateurs" de l'IMF sont Sony Pictures, Disney et Netflix. Mais maintenant, beaucoup plus, comme Fox, Apple, Amazon, etc. En France, j'ai ouïe-dire que Canal+ était un gros pousseur (et déjà utilisateur ?) du format IMF pour leurs contenus.

Concernant App#4/RT021:
- Images jusqu'à 8K
- JPEG2000 Lossless
- Colorspace XYZ
- Codage linéaire 16bits (unsigned)
- CPL simplifié

Petit détail que j'ai oublié, l'IMF App#4 Cinema Mezzanine utilise du JPEG2000 ISO/IEC 15444-1, donc JPEG Reversible Profile, donc Lossless aka "sans aucune perte d'informations dans l'image"

J'ai probablement oublié le groupe France Televisions (@matt_parmentier pourra confirmer ou infirmer)

La suite des docs SMPTE ! on passe au 2067-101 sur l'IMF et ses "Output Profile List" avec des petites options pour définir une sortie d'image provenant d'un film "IMFisé". On y retrouve le scale, crop, pixel-enc, etc.. avec des petites touches d'algorithmes

La SMPTE 2080-3 donne les références d'un environnement de visualisation idéal pour l'evaluation des images HDTV. Il préconise d'attendre 10 min pour que l'oeil s'adapte correctement, ne pas dépasser certains angles et la distance idéal soit de 3 à 3.2 fois la hauteur de l'image.

Et voici le workflow d'un contenu HDR / SDR. En gros [très gros], on fait des validations HDR et SDR du film, puis on fait un master HDR, on lui colle les métadatas HDR & SDR et en distribution, on lit le contenu HDR et on applique les metadatas correspondant à la sortie visuelle

On poursuit avec le SMPTE 2113 : "Colorimetry of P3 Color Spaces" - en gros, l'espace colorimétrique utilisée en projection cinéma. Il y a plusieurs "profiles" de P3 : P3D60, P3D65 et le fameux P3DCI (Digital Cinema). Chaque sont assez proches, leurs différences sont sur le blanc

Dans le SMPTE EG-0432-1-2010 "Digital Source Processing - Color Processing D-Cinema", on y retrouve le workflow complet du labo postprod à la salle de projection

Les specs cinéma définissent que la puissance lumineuse doit être à 14 Foot Lamber (fL), soit 48.0 cd/m2 (à titre de comparaison, EclairColor est à 30 fL). La tolérance est en salle de vérification est de ±3.5 cd/m2 (± 1.00 fL), et en salle de projection ±10.2 cd/m2 (± 3.00 fL)

Un gros morceau, SMPTE définissant Dolby Atmos. A retenir: Actuellement, le DolbyA est soit du 48 kHz, soit du 96 kHz et en 24-bit. Que le support des frames sont 24, 25, 30, 48, 50, 60, 96, 100 et 120 images par second. Si vous voyez une séance Dolby Atmos autre, il y a un souci

SMPTE Dolby Atmos: Le système de positionnement de chaque canal Dolby Atmos est défini avec des coordonnées Euclidiennes dans une plage de 0 à 1. Le son [0, 0, 0] est en avant de la salle, à gauche en bas. [1, 1, 1]: Arrière de la salle de projection, côté droit et en haut.

SMPTE ARRIRAW Image File : Où comment-que-c-est-guaulé-dans-les-rushes-de-camera-ARRI. Les caméras ARRI sont plutôt réputées dans le milieu. ARRI a une véritable expertise dans le domaine du numérique et sont assez ouverts sur les fichiers que leurs caméras produisent.

J'ai été étonné de voir en préambule qu'on peut écrire des logiciels pour interpréter/analyser des rushes ARRI, mais que pour pouvoir en créer, il faut être membre du programme Partner ARRI. A priori, c'est pour éviter de pourrir le format avec des logiciels mal codés.

La structure d'un rush ARRI est assez simple: une série de fichier .ari contenant des données, dont les images. L'entête (header) est de 4096 bits fixe, après, ce sont les données récoltées par le capteur de la caméra (bayer toussa)

Dans l'entête, des données pour chaque secteur, cela va des infos sur l'image, mais aussi colorimétrique, bcp de données caméra (allant du nom de la lentille jusqu'aux coordonnées GPS). J'en ai profité pour écrire un logiciel analysant les rushes ARRI (pas toute les metadatas) :

*qu'on puisse écrire (... à quand l'edit sur twitter...)

Pour compléter ce SMPTE: les données dans les en-têtes sont à positions fixes. La position des données image est variable, mais assez fréquemment, elles se trouvent soit à des offsets classiques (2048, 4096, 8192). J'en ai profité pour écrire un prog (proto) pour gérer les DPX :

Bon à savoir, quand on lit chaque composant RGB en 10-bits, on lit le rouge sur 10-bits, le vert sur 10-bits et le bleu sur 10-bit, puis on lit 2 bits pour le padding pour faire un joli 32-bits tout "rond"

Petit point sur mon défi SMPTE : Au début du confinement, je me suis lancé un défi: Lire toutes ces documentations sur le cinéma. Cela fait un peu près entre 8.000 et 10.000 pages de docs réparties sur plus de 500 papiers. Il me reste qu'une petite 20ène de docs!... Bientôt fini!

Je dois vous avouer que tout lire donne parfois des maux de têtes. L'impression de me faire injecter dans la tête des données en rafale.

SMPTE RDD-44-2017: La définition (rapide) de l'Apple ProRes. Format pas mal utilisé dans les laboratoires de postprod depuis 10-15 ans. Les seuls éléments que je retiens de ce SMPTE est le tableau de correspondance des différents débits, ...

(..) la description rapide des macroblocks et des composants YCbCr (Y pour la luminance, Cb: bleu et Cr: rouge, le vert étant calculé), et que tous les blocs de macroblocks ne sont pas égaux, les derniers blocs sont plus petits, à cause de la subdivision imparfaite de l'image

SMPTE RDD-47: IMF ISXD: Une extension pour le format IMF (futur format pour toute l'industrie cinéma/TV/préservation), pas vraiment compris à quoi cela servait... ni même si cela sera utilisé réellement...

Les sous-titres DCP:
- Le DCP Interop a des sous-titres XML non-chiffrés
- Le DCP SMPTE apporte le support des sous-titres MXF-XML et la possibilité de les chiffrer mais ne l'impose pas
- Le DCP SMPTE 2.1B impose un chiffrement des sous-titres si autres pistes chiffrées

Passage au SMPTE RDD-52-2020: Le DCP Bv2.1, c'est la dernière spécification pour les films numériques cinéma, quelques évolutions (non-exhaustives): Les sous-titres ne doivent pas dépasser 256kB. L'ensemble des contenus pour les subs (XML, PNG, Font) ne doivent pas dépasser 115MB

L'AnnotationText dans la CPL qui sera présenté aux différentes intervenants de la chaîne de distribution du film était avant optionnel (DCP SMPTE v1), maintenant il est devenu obligatoire et en plus il doit être égal au ContentTitleText. On se demande alors pourquoi ce doublon

J'ai bien une idée: peut-être que le ContentTitle va devenir (v3?) plus structuré et non plus un texte lambda essayant de respecter une convention pas vraiment normalisée à la base (Digital Cinema Naming Convention). Ainsi, on se fera plus chier à l'analyser pour la postprod

Autre nouveauté, le Hash de chaque élément du film (Picture, Sound, ...) devient maintenant obligatoire ! Et si une piste est chiffrée (encrypted), toutes les autres pistes (peu importe le type: Picture, Audio, Subtitle, AuxData) doivent être aussi chiffrées !

Dans les autres nouveautés, une piste pour le langage des signes. Les films pourront intégrer une piste spécifique. Il sera au format WebM VP9, d'une résolution de 480x640...

Complément ce SMPTE DCP 2.1B avec la taille des frames selon que ce soit du 2K ou du 4K.

Suite avec SMPTE RP-428-4:2010 sur le D-Cinema Distribution Master - Audio File Format and Delivery Constraints, aka DCDM Audio (pour les connaisseurs). On voit que les pistes audio sont extrêmement normalisées pour leur version master que ce soit au niveau contenu comme nommage.

SMPTE.RP.0428-6-2009 - DCDM - Digital Leader : Sous ce nom barbare se cache simplement le début et fin d'un film pour la partie numérique (déjà vu dans ce thread pour la partie 35mm). Cette norme détaille chaque frame de début et de fin.

Le début doit être de 8 secondes, soit 192 frames en 24 img/s, le compteur doit commencer à partir de 8 et la petite aiguille doit faire 15° par image pour faire un beau 360°. Le background n'est pas figé, on peut faire un peu ce qu'on veut il faut juste respecter certaines infos

Au niveau des bandes de couleurs ou de gris qu'on voit dans la charte, ce ne sont pas des couleurs/gris aléatoires, elles sont codifiées pour permettre d'identifier un problème colorimétrique à l'oeil ou via des capteurs spécifiques (avec un spectro, c'est mieux ;)

Et enfin, la fin respecte aussi une certaine codification, elle doit durer 4 secondes (soit 96 frames pour du 24 img/s). J'ai passé vite car il y a aussi les "sync pop", le fameux bip (1000 Hz)

SMPTE 430 : Les certificats numériques utilisés par les lecteurs films numériques (DCP). Ces certs servent à authentifier le matériel & chiffrer les clefs pour les KDMs. Vous avez deux clefs: une publique (donné au laboratoire) et une privée, qui ne sort jamais (normalement ;)

Sans grande originalité: c'est du x509v3, avec une structure certs : la racine (géré par le constructeur, exemple Dolby / Doremi), l'intermédiaire (idem) et la "leaf": le certificat du player en salle cinéma. Certains champs sont obligatoires et doivent respecter une nomenclature

SMPTE-2073: Je découvre le format VC5, qui est le nom de code pour le CineForm, qui est un format pour la post-production de film. Selon la page Wikipedia, ce format a été utilisé sur des films comme Slumdog Millionaire & Need For Speed.

Il se base sur un format d'image wavelet non-destructeur - comme le JPEG2000 utilisé dans le DCP (film numérique) et IMF (~format d'archivage et d'échange de film) - et le format a été placé en opensource par GoPro (détenteur du codec après un rachat).

Voila, c'est la fin des lectures des docs SMPTE. Entre 7000-9000 pages, parfois assez obscures, intéressantes (presque ;). Vous pouvez lire le thread pour avoir un résumé rapide des différentes docs. Je n'ai pas écrit sur certaines car pas forcément intéressantes pour le "public"