Le souci est qu'initialement, les "modérateurs" demandaient "une source secondaire", ce qui a été fait par des contributeurs, puis ils ont demandé "une source secondaire centrée", ce qui a également été fait par de nouveaux contributeurs. Et d'un coup, ils ont demandé "deux sources secondaires centrées" au minimum.
Posté par Prae .
En réponse à la dépêche Des formats d'image.
Évalué à 4.
Dernière modification le 23 juillet 2023 à 17:57.
Hello :)
JPEG2000 avec perte.
là je me demande s'ils n'encodent pas sans perte.
Pour les copies projections, oui, avec perte.
Pour les archives type IMF, c'est sans (réversible).
De mémoire, si un film d'animation simple peut faire une trentaine de GiB, un film cinéma typique (c'est à dire filmé, avec des acteurs) fera une centaine de GiB (et un film 3D peut aller dans les 200 ou 300GiB.
Pour le coup, tu peux doubler les chiffres :-D
Shrek fait autour des 65G
Astérix - Le Secret de la potion magique : ~70G
Demon's Slayer : 68G
Prince d'Egypte : 72G
Pour les films classiques (sans 3D) :
Knives Out : ~250G
No Time To Die (4K / 2D): ~600G
Ad Astra (4K / 2D): ~500G
Avatar 2 : ~800-900G (tout dépend de la version, là, c'est la version 3D 48 fps)
Il faudrait que je fasse des stats sur les poids de maintenant
(voire même des stats sur le poids à travers le temps)
Ici (labo postprod + stockage film très longue période), on utilise du LTO + stockage HDD classique sur serveurs + retour à la pellicule (ça dépend des cas d'usages).
Et je te confirme pour le lossless 35mm, la chimie continuant sur la pellicule, même des années après son print, on peut avoir des dégradations suivant comment cela a été fait à l'origine. Il faut donc veiller au grain. (*krkrkr*désolé)
Le fait d'utiliser "ls" était justifié pour ne donner que le résultat escompté et dans l'ordre établi. Pour optimiser ses sorties, "find" évite de sort sa sortie.
Un exemple avec des documents créés initialement à différentes temporalités :
Pour le même résultat - celui de ne sortir que les fichiers md dans l'ordre - nous avons une commande simple qui donne satisfaction; Et de l'autre, une commande avec quasiment 2x plus d'arguments pour un résultat imparfait et non voulu.
commit cac79f1a1a6f04fc40c6106d86bf123bd4cd5b8d (HEAD -> main, tag: v0.2.1, origin/main, origin/HEAD)
Author: Constantin Catalin Bratu <ccbratu@notariato.it>
Date: Wed Nov 2 22:48:09 2022 +0100
:pencil2: fix command flags in README example
commit b0b8e0e2a7f2d4e5262bfefcb49bb51a9371d16e
Author: jppaled <22444128+jppaled@users.noreply.github.com>
Date: Thu Nov 3 00:01:15 2022 +0100
:bug: remove extra space with Sprintf
commit 7099fb19da3c4bc7801cd75e16b47360b233fe7f
Author: David Delassus <david.jose.delassus@gmail.com>
Date: Wed Nov 2 19:42:19 2022 +0100
:sparkles: serve static files if they are not markdown documents
commit 31c8d17258a68c20e2d9863aff039ce6f99d8bc9 (tag: v0.1.0)
Author: David Delassus <david.jose.delassus@gmail.com>
Date: Wed Nov 2 04:51:23 2022 +0100
:bookmark: v0.1.0
commit 65a362293fa569ad7313d484da7a3c58d76b3c62
Author: David Delassus <david.jose.delassus@gmail.com>
Date: Wed Nov 2 04:43:58 2022 +0100
:tada: create repository
Je vois bien tes derniers commits au niveau des logs et je vois bien tes modifs dans les sources en local. Pour être sûr, j'ai même refais un checkout complet.
C'est étrange si tu as un comportement totalement différent :-/
Rien de folichon, je me place dans mon répertoire avec plein de MD, je lance easymd, sans arguments.
En version shell:
$ cd mongrosrepertoireavecpleindemd/
$ ls *.md
DOC1.md
DOC2.md
DOC3.md
$ ls images/
image1.jpg
image2.jpg
image3.jpg
$ /tmp/easymd/easymd
2022/11/03 15:22:35 Listening on http://0.0.0.0:8000
Je prends un navigateur, je vais sur 0.0.0.0:8000, j'ai bien un listing du répertoire courant, je rajoute /DOC1 et cela m'affiche bien le document, mais sans les images. Et si j'essaye d'afficher les images, j'ai l'erreur interne.
Et c'est tout :-/
PS: un truc qui me vient, il n'y a pas un système de cache de build dans go qui pourrait me faire croire que je build les dernières sources mais en fait pas du tout ? (go clean ne change pas le résultat)
Petit test avec la dernière release, j'ai toujours un souci :(
Par exemple, si j'essaye d'accéder à cette url http://localhost:8000/images/image.jpg
J'ai un "Internal Server Error" "(c)ould not render document: open images/image.jpg/_index.md: not a directory"
Est-ce que c'est possible que "si pas MD alors fichier static" ? plutôt que "c'est dans un répertoire static" ? parce que j'ai donné comme exemple /images/, mais j'ai d'autres répertoires avec différents éléments statiques, et pour le coup, je me dis que c'est plus simple de partir sur un "if mdfile { render }" et le reste, juste en push sur le http handler, non ?
Je me dis que si je suis dans ce cas de figure, d'autres aussi en l'utilisant;
Sinon pour le reste, c'est niquel, je trouve le rendu très proche de ce que j'ai sur d'autres renders markdown et le rendu final en html est plutôt clean.
Quelques petits feedbacks:
- Une petite doc pour build en go (un simple "go build main.go" par exemple) dans le README.md
- La gestion des fichiers "autres" : par exemple, j'ai des images en local, le serveur http ne les délivrent pas, il serait utile d'avoir un truc du genre (pseudocode rapidos ;)
(pseudocode dans Serve())
if *.md:
buffer = RenderPath(file);
else:
buffer = ReadFile(file);
push_http(buffer)
UPDATE: en fait, cela part en erreur interne quand c'est un fichier non MD, et surtout il cherche par défaut un "_index.md", pourquoi pas directement index.md ?
Je lisais le Virus à l'époque. Quand c'est revenu, j'étais content. Quand j'ai lu les nouveaux éditos qui partaient de plus en plus en cacahouète, j'ai commencé à tiquer.
Ce dernier édito de fin de parution n'est qu'une confirmation de ce que je pensais.
Il ne me reste plus qu'à m'excuser, je m'intéresse à linux depuis pas trop longtemps, et je traîne parfois sur ce site. J'ai donc lu quelques discussions sur le covid ici, qui m'ont paru moins féroces qu'ailleurs.
Même si j'essaye de m'en détacher, j'avoue que j'ai le sentiment que cette crise sanitaire me rend un fou peu à peu :)
Bravo… et ta première et seule contribution sera - non pas sur Linux - mais sur des propos antivax, avec un compte créé le jour-même.
Ce journal devrait être supprimé et ton compte cloturé.
Je t'invite à relire les droits accordés dans le PDF.
Si tu crois dans ce que tu dis, je te demande de le prouver : envoie-moi ton document DCP modifié (renomme le si tu as envie, le sujet n'est pas le droit des marques), et j'informe DCP de ce que tu fais. Note : pour ta santé juridique je te déconseille de le faire, mais bon si tu veux démontrer que ce que tu penses est vrai libre à toi te d'engluer avec les avocats de DCP…
C’est marrant, parce que là, tu parles de « modification de document DCP », ce que j’évoque jamais, mais de modification de DCP, de rajout, d’améliorations. (tu es d’ailleurs le seul à vouloir imposer un argumentaire de paille sur la modification de ces documents, alors que j’évoque des drafts et la participation à des groupes pour des RFC et faire évoluer la norme ou proposer sa propre normalisation après feedback de la communauté, ou au pire - sans docs - faire son propre format (fork) ou ajout dans le format DCP mais au risque d’être incompatible)
Mais pas de souci, on va prévenir les avocats du DCP.
Et juste après, on ira contacter le cabinet du WAV et les conseillers juridiques du XML.
On va dire que tu parlais du DCI.
Ils s’en foutent. Pour ainsi dire, et voir le niveau du je-m’en-foutisme, quand un constructeur a menti sciemment durant les procédures de validation DCI de leurs matériels, ils n’ont rien fait.
Et pour les modifications DCP, ils sont déjà au courant (comme l’ensemble de l’industrie).
Mais vas-y si cela te fait plaisir.
C’est pas comme si on appelait cela « de l’innovation ».
DCI, SMPTE et tous les acteurs du marché sont content des innovations, ils poussent même à cela. Tout le monde peut apporter sa pierre à l’édifice. Et quand cela devient assez intéressant, on passe à la partie SMPTE Draft pour officialiser la chose et dire aux autres qu’ils peuvent l’implémenter (ou non, c’est au choix des acteurs d’avoir envie d’utiliser ou non)
Tu veux modifier un DCP pour en faire autre chose ? vas-y, tu peux.
Tu veux distribuer ce DCP modifié à n’importe qui, vas-y aussi, tu peux, personne ne t’en empêche.
Tu en as marre de la normalisation DCP/DCI/SMPTE et tu veux faire ton fork? Pas de souci, écris ta propre doc, tu fais des implémentations à l’intérieur, tu nommes cela ZCP, personne ne t’en empêche.
Pas de chance, le copyright fonctionne à l'inverse : faute d'autoriser, tout est interdit. SMPTE-377 ne donne aucune indication de licence libre, donc c'est non libre. En pratique, les PDF sont maintenant avec ton nom dessus pour te démotiver à diffuser… Pourtant, la base d'un document libre. Tu veux prouver que ce que fait SMPTE est libre? Prendre les docs derrière le paywall et mets-les en libre accès (tout document libre permet ça, sinon ce n'est pas libre, que tu ais payé ou pas l'upstream). Même conseil que pour DCP pour ta santé juridique.
C’est drôle, tu changes aussi de fusil d’épaule;
Depuis le début, tu dis que le MXF est pas libre, je te demande des preuves et je cite même un passage du document SMPTE stipulant que selon eux, il n’y en a pas (SMPTE, c’est surtout des techniciens, pas une armée de juristes)
Et là, non seulement tu me dis que c’est à moi de prouver que le MXF est pas libre (renversement de la charge de la preuve) MAIS en plus, tu en viens à me donner des phrases que j’ai jamais prononcé, comme le fait que les documents du SMPTE sont libres. T’es quand même fort.
Mais bon, on va la faire différemment: donc selon toi, dès que c’est derrière un paywall, cela devient propriétaire ?
Cela voudrait dire que ce dont parle cette documentation derrière ce paypal est propriétaire (et je suis quasiment sûr qu’on a pas le droit de distribuer ce PDF) ? https://www.iso.org/standard/74528.html . Il faudrait prévenir la communauté des développeurs.
Sur le SMPTE, tu as des docs sur le 8mm, 16mm et 35mm, automatiquement, ces formats deviennent propriétaires ? Tu ne peux pas modifier le 35mm pour le faire correspondre à tes besoins ? Tu ne peux pas redistribuer ces modifications pour d’autres ? (plot twist: si)
Allez, imaginons maintenant qu’il n’y ait pas de paywall, les docs SMPTE intègrent une ligne pour interdire la copie de la doc SMPTE (il faut être membre SMPTE). Pas de souci: Si cela ne te va pas, et bien, écris une documentation sur ton blog décrivant précisément le format MXF et place cette documentation en licence libre, personne ne t’y empêchera. (il existe même un bouquin en libre accès et sans avoir besoin d’être membre SMPTE). Tu peux même réécrire entièrement toutes les docs SMPTE avec tes propres mots, tes propres images et tes propres informations.
En aparté, je note que quand on te demande des infos sur le FFV1, par exemple un petit MXF, la première chose que tu fais, c’est de faire le videur de boite de nuit et de filtrer qui à le droit de voir ou non. C’est ton paywall à toi, je comprends.
Au fait, depuis le début, tu nous dis que le format DCP est 0% libre (et au passage le MXF).
Mais … depuis tout à l’heure, tu es pas en train de nous vendre ton projet d’intégrer du FFV1 dans le MXF. Le MXF étant le coeur même d’un DCP. Place ton MXF dans un DCP, tu viens de faire un DCP sans JPEG2000 mais avec du FFV1. Félicitations.
Et avec ce DCP modifié, tu peux maintenant le distribuer, tu peux écrire une doc expliquant tout le processus, tu peux en parler, personne ne te dira quoique ce soit. (cela peut même intéresser des gens du DCI ou de l’ISDCF)
Mais fais attention, il y a probablement déjà la Police du DCP derrière ta porte…
Et enfin, tu vocifères depuis le début que tout ceci n’est pas libre parce que tu n’as pas le droit de modifier un PDF, tu affirmes même que le MXF ne l’est pas, tu n’as pas pu fournir une once de preuve sur cette affirmation, je vais donc te citer des passages de « The MXF Book » par les principaux auteurs du MXF :
« The format should be open, standardized, and compression-format independent. » — History of MXF
« MXF was chosen, largely for its freedom from patents and the associated royalties » — DCI/DCP
A partir de là, on remettra donc en question l'ensemble de tes affirmations péremptoires et (toujours) hautaines.
———
A titre personnel, et parce que cela dure depuis trop longtemps, je vais arrêter de te répondre sur ce thread et j’ignorerais à l’avenir tes messages sur l’ensemble du site - mon employeur ne me paye pas (ou pas assez cher) pour répondre à tes commentaires et j’ai véritablement autre chose à faire dans ma vie que de subir continuellement ton égo surdimensionné et cela depuis pas mal d'années déjà.
Il me semble que les clés de lecture des DCP dans les cinémas permettent de limiter très précisément le nombre de lectures, les dates autorisées, le type de matériel, etc… Dans ce cadre de verrou numérique, je vois pas bien comment ouvrir le format totalement sans péter toute la logique de verrouillage qui va avec.
Les deux ne sont pas antinomiques.
Pour cela, il faut démystifier toute la partie cryptographie du DCP avec ses clés.
Je vais essayer de résumer.
Un DCP est chiffré (s’il l’est, ce n’est pas obligatoire) via un ou plusieurs clés AES (128-CBC) - pour être plus précis, ce sont les fichiers MXF qui sont chiffrés - et pour être encore plus précis, ce ne sont que les layers (KLV) contenant les assets (images, audios, autres) qui le sont (le MXF n’est pas totalement chiffré, seulement les images/audios/autres intégrées dedans). Une ou plusieurs clefs AES peuvent chiffrer un ou plusieurs MXF. (en général, on recommande 1 MXF = 1 clef AES), un DCP peut avoir plusieurs MXF (au moins 2: les images et le son)
Quand il faut distribuer le film en salle, les clés AES ne sont pas distribuées comme cela, elles sont chiffrées via le certificat public du matériel en salle (RSA) puis intégrées dans un ou plusieurs containers cryptographiques (CipherValue) stockées dans un gros fichier XML intégrant des métadatas pour leurs gestions (KDM aka « Key Delivery Message »). Ce sont ces fichiers qui sont envoyés au cinéma.
Jehan a assez bien résumé les raisons et les besoins de ce workflow :
Un DCP, c’est environ entre 70 à 300G (voire plus si on fait de la 3D en 120 FPS en 4DX, etc..), il faut envoyer plusieurs copies aux différentes salles. Si un film doit être envoyé à 500 salles, il faudrait donc chiffrer 500 fois plusieurs gigas: c’est une perte de temps pour le laboratoire. Il suffit de chiffrer une fois le DCP référent (par exemple « STARWARS-3-VF ») et de l’envoyer dans les salles. Puis de chiffrer une petite clef AES 128 bits, 500 fois, avec le certificat de chaque player des différentes salles qui veulent/peuvent diffuser le film, c’est beaucoup plus rapide :)
Je vais aussi démystifier un autre truc de suite : Techniquement, pour déchiffrer un DCP, il suffit simplement des clefs AES. Rien de plus.
Le reste (KDM), c’est du folklore pour la distribution (et surtout pour respecter le workflow de distribution DCI et garantir une certaine sécurité des données même quand ils sont dans les players dans les différentes salles).
A titre de comparaison foireux: c’est comme mettre une clef de maison dans un colis et l’envoyer par la poste. (imagine que le colis soit un coffre dont le seul détenteur de la clef (ou une combinaison) permettant de l’ouvrir est celui qui va réceptionner le colis). C’est la clef de la maison qui permettra d’ouvrir la porte de la maison, pas le colis.
Quand on te dit qu’il faut des clés de lecture avec les dates autorisées, le type de matériel, etc. (pas le nombre de lecture), on doit te parler des KDM. Ce gros fichier XML contient quelques metadatas - dont notamment les informations techniques du film, la date de début et de fin (informatives seulement), les informations cryptographiques RSA, dont le Signer (celui qui a fait ce KDM) et le Recipient (celui va le déchiffrer : le player) et d’autres trucs qui seraient trop long à résumer. Et bien entendu, des containers cryptographiques (CipherValue) qui ne peuvent être déchiffrés que par celui qui détient le certificat privé (le player).
Quand on a déchiffré ces containers cryptographiques (via RSA, donc crypto asymétrique), ils contiennent des metadatas: Un ID, un thumbprint, un autre ID, le type du MXF, l’ID de la clef, les dates début-fin et enfin, la fameuse clef AES sur 128 bits.
A partir de là, tu comprends que si tu fais ton certificat RSA, tu génères un cert public, tu envoies cela pour avoir un DCP chiffré, tu peux déchiffrer la partie CipherValue, tu récupères les clefs AES pour déchiffrer tes MXF et tu peux ignorer les obligations. (aucun labo n’acceptera ton certificat louche :) mais techniquement, il sera valide)
Dans une autre mesure, tu peux aussi faire ton propre DCP : tu génères tes propres clefs AES et tu chiffres tes MXF. Tu as maintenant toute la liberté de la méthode d’envoi et de réception des clefs AES auprès de ton interlocuteur: soit tu es joueur et tu les envoies en clair (mais on sait que c’est pas bien), soit tu demandes à ton interlocuteur son certificat public pour chiffrer un message: tu viens de créer un ersatz de KDM (note que ceci n’est pas le workflow DCI pour la distribution en salle, nous aurons toujours un couple DCP chiffré avec des clefs AES + KDM avec clefs AES chiffrés par un certificat public)
Petit bonus : il existe aussi ce qu’on appelle DKDM, ce sont simplement des KDM - mais avec un autre nom - qui ne sont pas à destination des salles de cinéma, mais des laboratoires ou autres professionnels : Cela permet de s’échanger des clefs AES entre professionnels (par exemple, un labo qui doit générer des KDM mais pour un DCP qu’un autre laboratoire à fait)
Donc dire qu'y a des erreurs, je veux bien, et dans ce cas je veux bien que tu corriges. Mais de là à parler de "n'importe quoi", ben… là aussi je veux bien que tu expliques! 😛
J'avais lu rapidement ton message en réponse à Cg, comme cela, je n'ai pas vu d'erreur, je vais le relire pour voir s'il y a des trucs à ajouter, mais je pense pas, tu as assez bien résumé les causes-conséquences de tels ou tels choix
Je suis content qu'on retombe sur une discussion plus saine et agréable. 👍
On s’intéresse plus aux archives qui utilisent MXF que le cinéma, donc tu ne risques pas d'en entendre parler avant un moment…
Je n'ai pas compris pas ta phrase, Qu'est ce que tu entends par "aux archives qui utilisent MXF" ? Pourtant, dans le cinéma, on utilise du MXF, l'IMF est fait pour cela justement, et on l'utilise pour les échanges entre labos, entre diffuseurs et pour l'archivage
Plus prosaïquement, quel intérêt verrais-tu à avoir ces fichiers illisibles partout actuellement ?
Pour l'étudier en amont. Il est préférable de faire de la veille technologique avant plutôt de se réveiller un jour et en pleine réunion nous demander de supporter un nouveau format inconnu encore. (phase d'étude, de compréhension, d'implémentation)
Après, je peux comprendre ta réticence car par encore stabilisé, mais pour le coup, il serait préférable d'ouvrir un peu plus à ce niveau, même si c'est du draft, pour que les gens puissent l'étudier, le comprendre, faire des retours possibles et le jour J, quand cela est enfin stabilisé, de pouvoir l'implémenter assez rapidement (vu qu'ils connaitront déjà plus ou moins le format).
Je parlais de la partie JPEG2000 pas du format DCP lui-même dont la spec est effectivement ouverte. D'ailleurs je proposais même comme avancée potentielle (donc totalement théorique, en vrai j'y crois pas trop, notamment pour les arguments que tu évoques aussi et avec lesquels je suis globalement d'accord) que FFV1 soit utilisé en remplacement de JPEG2000 à l'intérieur de DCP en tant que conteneur existant.
En fait, tu sais quoi, je serais même d’accord.
Je me fous du JPEG2000 depuis le début, j’aurai tellement aimé que ce soit du DPX ou de l’OpenEXR même, mais bon, après, c’est compliqué.
Ceci dit, l’IMF propose déjà ce principe. Pour ceux qui ne savent pas - je vais résumer à mort :
IMF = DCP pour l’échange entre labo ou archivages.
Donc l’IMF propose que le container « image » ne soit pas forcément du JPEG2000 avec pertes.
Ben non, justement je disais qu'y a pas d'artefacts sur les écrans de cinéma et qu'évidemment on n'en veut pas dans ce contexte. Relis ma phrase et pourquoi je dis ça, donc son sens (qui est bien qu'on ne voit pas d'artefacts). 😉
Au temps pour moi alors :)
Je veux bien savoir le logiciel que tu utilises et la ligne de commande/options pour faire cela et comment on joue sur les "layer de résolution".
Alors, c’est un peu compliqué :)
Moi, j’utilise un outil interne développé par un gars de chez nous, ultra compétent et qui a pondu un lecteur DCP en 1 mois.
Donc, bien évidemment, c’est pas opensource, et c’est même pas distribuable :)
Sinon, il y a d’autres gars qui chez nous qui ont participé à l’implémentation MXF/JPEG200 dans ffmpeg (dans mes souvenirs)
Et j’ai cru comprendre que VLC dernière version (ou version night-build) supporte maintenant la lecture d’un DCP sans bidouille (à confirmer, j’avoue ne pas avoir regarder plus que cela)
Perso les quelques fois où j'ai essayé par curiosité, genre même juste sur des DCPs de bande annonce, ben c'était saccadé à mort
Oui, si tu prends un 2K/4K avec son potentiel max, il vaut mieux avoir un CPU bien costaud (d’où le fait que ce soit via FPGA)
Après, tu peux ne décoder que les autres résolutions, cela reste parfaitement acceptable, même sur un petit portable.
La problématique est donc juste: c'est dommage qu'ils aient choisi JPEG2000 comme format unique.
J’ai eu beaucoup de fois des gens me demandant « mais pourquoi JPEG2000 » ?
Tout simplement, il faut revenir 15 ans en arrière, en 2001, il faut créer un format exploitable en salle, donc avec toutes les contraintes et surtout la base technologique qu’on avait à l’époque: quel est le format qui permettrait de pouvoir avoir des frames assez compressées mais tout en ayant un bon rendu et surtout single-frame (dans le sens où une perte d’image ne provoque pas de problème sur les suivantes).
Ils ont donc produit un court-métrage qui s’appelle « StEm » (voir fiche IMDB), c’est un pur film technique, dans le sens où, y’a une histoire, des acteurs, des décors, des cadres. Mais tout ce qui a été mis à l’image est là pour tester les compressions. Par exemple, faire un focus sur une personne derrière un grillage avec de la pluie et un travelling, tu perds une partie des formats car leurs algos n’aiment pas trop cela.
Le JPEG2000 est - à ma connaissance de l’époque - le seul format qui est sortie vainqueur.
Maintenant, si c’était à refaire (plot twist: StEm2 arrive…), peut-être qu’un autre format aurait gagné, peut-être même FFV1.
Pour avoir travaillé exactement dans cette problématique de relation entre salles et distributeurs, ce n'est pas comme ça que ça fonctionne.
Pour avoir été distributeur et travaillant dans l’un des plus anciens (et gros?) labos et faire depuis des années DCP et envoi: je n’ai jamais dit que c’était comme cela qu’on travaillait :)
J’ai dit que dans le monde du e-cinema (donc pre-2005), c’était comme cela, car dans le monde du e-cinema, chaque exploitant qui voulait se faire une projo « numérique » faisait sa tambouille interne. Et là, c’est pas le distributeur qui va contacter l’exploitant (il peut le faire hein, mais techniquement, c’est pas leur problème), à l’époque, c’était le labo qui se chargeait de demander quel format l’exploitant supportait.
Depuis le DCI/DCP, on a plus ce genre de question, tout le monde parle la même langue.
Mais bon, c’est dans le meilleur des mondes, car si un DCP ne fonctionne pas, l’exploitant va lancer un warning, au pire, il va voir son distributeur, au mieux, il se pointe chez nous et nous demande un SAV sur son matériel :)
Le labo ne contacte pas les salles au cas par cas
Je vais être plus direct: le labo ne contacte presque plus les salles au cas par cas, car on a travaillé en amont pour avoir assez d’informations sur la salle pour savoir si tout se passera bien.
Par exemple, un exploitant nous demande un DCP 4K Atmos, et on voit qu’il a qu’un player DCI 2K et sans matériel Atmos, on va l’appeler pour lui demander s’il y a pas un souci (soit on pas les bonnes infos, soit il a pas compris que cela ne servait à rien de lui envoyer un DCP aussi « énorme » alors qu’il a pas le matériel pour l’exploiter, même s’il pourrait le faire, mais c’est un peu inutile)
Les VPFs, c'était l'activité principale de là où je bossais et justement en tant que regroupement de beaucoup de petites salles (indépendantes, salles art et essai). Donc l'affirmation me paraît un peu péremptoire. 🙂
Je vais faire un peu d’histoire.
Il y a eu les principaux tiers de confiance dès 2005 (je travaillais dans l’un des deux principaux sur le marché FR, je te laisse savoir qui est qui :)
Au début, il y a eu une proposition des tiers pour travailler avec le CNC: les tiers faisaient les plus gros exploitants, le CNC les plus fragiles.
Pour une simple raison: l’argent du CNC devait être utilisé à bon escient, aider les plus précaires que les contrats VPF ne pouvaient gérer (les mono-salles qui ouvrent que les vacances par exemple). Cela avait un autre but : l’argent des distributeurs devaient servir pour les exploitants à passer au numérique. Sauf que pour le CNC, ils ont pas appréciés (pourquoi ? on ne sait pas, enfin, on a une idée, mais bon). Ce qui a fait que le CNC a voulu lancer son propre système de VPF (mais en faisant n’importe quoi), il a donc provoqué plus de problème que d’en résoudre. Ce qui a valu de passer devant l’autorité de la concurrence qui a recadré le CNC. Le CNC ne pouvait donc plus faire de VPF.
D’où mon affirmation un rapide et direct: je parlais surtout du CNC.
Je sais qu’il y a eu des petites structures qui ont mis en place des systèmes de VPF avec des exploitants plus fragiles :)
Le « plus petites salles », c’est pour dire que ceux qui rentraient pas les contrats VPF plus classiques avec les principaux tiers se tournaient assez généralement vers le CNC - mais le CNC n’avait pas le droit de faire du VPF - donc ils ont fait un truc chelou à base de « subventions remboursables mais on ferme les yeux si tu rembourses pas » (attention, cela a peut-être changé depuis mais à l’époque, c’était pas le cas)
J’ai essayé de résumer rapidement 17 ans d’histoire du VPF (en omettant plein de trucs)
que ça a coûté très cher et que ça a mis du temps pour numériser les salles,
Cf. « Le CNC a fait n’importe quoi et - à mon sens - a fait perdre quasi 3 ans d’avance sur la numérisation des salles.
(on peut en parler plus en détail si tu veux)
Donc je suis d'accord. Encore une fois, personne ici a demandé à toucher au DCP en tant que conteneur. J'ai l'impression que tu te cherches des ennemis virtuel du DCP sur lesquels tu pourrais te défouler. 😛
C’est peut-être que j’ai mal compris ton message d’origine :)
Et que pendant pas mal d’années, surtout au début, j’ai vu certaines personnes dans l’opensource dire n’importe quoi. (j’ai repéré un message plus en dessous sur la cryptographie qui est justement dans ce cas :)
Désolé.
Je posais juste une question sur FFV1 dans le contexte du cinéma car je trouvais l'article intéressant.
Si tu veux mon avis tranché dessus: je serais ravi d’avoir autre chose que du JPEG2000 :)
(je l’ai même dit plusieurs fois sur d’autres formats que je trouve mieux, mais c’est plus dans le sens « non destructrice », mais impossible pour des copies séries à distribuer en salle)
Je m'attendais pas à me faire sauter dessus pour oser discuter du sujet.
Format ouvert : Je te défie de me montrer un décodeur DCP basé uniquement sur les specs fournies dans ton lien.
Je vois pas ce que tu veux dire. Les specs ne fournissent pas le code source d’un décodeur DCP, cela n’a pas de sens.
Au mieux, ce que tu as, ce sont des bouts de code pour tels ou telles parties (genre vérif d’un hash crypto, ou de check xml, etc…)
Et la doc DCI formalise pas mal de choses et faire des références sur des normes.
Spoiler : tu n'y arriveras pas, vu que le site que tu pointes ne fournit pas tout, juste 1% des specs (celles qui disent "utilisez MXF et JPEG 2000", sachant que les specs MXF et JPEG 2000 sont derrière un paywall est que tu n'as pas intérêt pour ta santé à les diffuser)
Tu es sérieusement entrain de m’apprendre ce qu’est le SMPTE ? :)
Que les docs SMPTE ne soient pas dispos à tout à chacun, oooh bordel oui, c’est relou.
Mais cela ne veut pas dire que tu peux pas implémenter toi-même, cela ne veut pas dire que tu peux pas lire la documentation, ni même faire ce que tu veux du format indiqué dans le document (après, tu fais ce que tu veux de l’implémentation, c’est ton problème)
Ou alors pour toi, cela voudrait donc dire « libre == gratuit » ?
Format libre : DCP n'est pas libre. la ligne dans les specs "Only DCI has the right and authority to revise or change the material contained in this document, and any revisions by any party other than DCI are unauthorized and prohibited." est 0% compatible avec les 4 libertés.
J’ai déjà donné ma réponse au dessus.
Tout le monde peut participer aux specs DCI et aux normes SMPTE, il suffit d’être dans un groupe de travail et de faire une proposition (style RFC).
pas MXF
What ?
J’ai vu aucune indication de non-liberté dans le SMPTE-377, ni même dans le bouquin de Nick Wells.
Et c'est même écrit en préambule du SMPTE-377 qu'à leur connaissance, il n'y a droit de brevet sur le format MXF.
Et j’ai vu personne avoir de problème pour l’implémentation d’un read/write d’un MXF dans leurs logiciels et encore moins de takedown sur des projets opensources, même connu par tous.
Donc sa phrase est bien plus proche de la vérité que la tienne.
Nop.
JPEG 2000 n'est pas sans perte, donc tu as des artefacts. Moins visible en cinéma car wavelet + débité élevé, ça n'enlève pas leur existence en soit, juste moins prononcé.
Sa phrase laisse supposer qu’on voit ses artefacts comme de vulgaire gros carrés de compression. Donc non.
Non, j'ai interdiction de rediffuser 99% de la spec DCP.
Prendre les PDF sur dcimovies.com, tu fais ce que tu veux, j’ai vu personne avoir de problème avec et cela depuis plus de 15 ans.
Ou alors tu parles des docs SMPTE.
mais bon parser du DCP "seul" me fournit… Absolument rien en contenu audiovisuel.
Tu me feras pas croire que tu sais pas parser du MXF :)
Tu me feras pas croire que tu sais pas comment marche un MXF :)
Et tu me feras jamais croire que après avoir trouvé et récupéré les KLV des images, tu peux pas appliquer une passe openjpeg dessus :)
Et allez, vu qu’une partie semble bloqué sur le JPEG2000: dans les MXF subs, ce sont des PNG, donc on a une succession de KLV facilement lisible par tout à chacun et dont certains sont justes des PNG, tu vas me faire croire que tu n’as absolument rien en contenu audiovisuel ?
(et tu oublies les MXF Audio, le WAV est devenu proprio ?)
Non, j'ai interdiction de modifier 100% de la spec DCP, y compris 100% du texte que sur le XML du DCP.
Mais bullshit bordel, on le fait nous ! Même Dolby.
On modifie des DCP, on rajoute des trucs.
Le seul truc, c’est que tu perds ta « normalisation » DCP, tu peux plus appeler cela DCP (pas au sens juridique), tu es obligé de dire que tu as rajouté des trucs et que si certains outils font des tests d’intégrité très sévères, ils peuvent le refuser (et c’est normal !)
Et si tu veux que tes metadatas ou tes modifs soient prises en compte par l’ensemble du secteur, et bien tu écris une jolie RFC aka SMPTE Draft pour que cela devienne valide pour tous (et encore, t’es même pas obligé, tu peux très bien faire une doc technique classique et la publier, je crois même que Dolby avait fait cela au début pour son format Atmos)
Si t’as envie de faire un DCP à ta sauce, tu le fais, mais après faut pas se plaindre que les outils des copains soient ne l’aime pas, soit le refuse.
C’est comme si tu voulais modifier des trucs dans les headers d’un PNG sans respecter la norme PNG et après râler que les outils n’arrivent plus à ouvrir ton PNG.
A ma connaissance ce n'est pas donné. Faisable pour des gros cinémas, plus difficile pour des petits (ticket d'entrée…), et pour d'autres encore plus petit c'est juste impossible.
Et ?
On va encore avoir cette discussion sur le prix du matériel en salle et donc « il faudrait une norme pour réduire les coûts »
Désolé, mais vous avez 15 de retard, j’ai déjà eu ce genre de discussion ici en plus.
Le cinéma numérique est 0% libre, c'est un fait.
Non, c’est ton fait. Tu peux faire ce que tu veux du format, tu peux même rajouter des types de KLV dans le MXF sans que personne ne vienne te prendre la tête. Mais après, si ce n’est pas dans une doc, ne vient pas chouiner que personne ne supporte tes ajouts.
Le cinéma est un autre monde, un autre budget, et se fout du lossless
Le monde du cinéma est vaste. C’est comme parler d’informatique et n’évoquer que le rôle d’un sysadmin.
Le monde du cinéma ne se fout pas du lossless, quand je suis en tournage, j’ai vu aucun chef opérateur dire « ouais, je m’en fous qu’on est une compression dégueulasse qui va saloper mon boulot ».
Le reste du workflow, que ce soit en tournage, en postproduction ou en archivage, j’ai vu quasi personne de sérieux me dire « je m’en fous de perdre en qualité ».
Le seul moment où ils sont tolérants (et je parle bien de tolérance, pas de je-m’en-foutisme), c’est lors des copies séries pour les envoyer dans les salles de cinéma. Ils acceptent, là, de perdre un peu. Et quand je dis un peu, c’est que cela a été validé par le chef-opérateur en postprod et le réalisateur.
Et pour info, ils avaient cette même tolérance avec le 35mm, d’où le fait que les copies pour les salles de cinéma étaient différentes des tirages pour les festivals.
mais eux ont la thune et utilisent déjà JPEG 2000
C’est quoi ce lien avec « JPEG2000 == thune » Quel est le rapport ?
Tu penses que ça sera moins coûteux de faire une master FFV1 qu’un master JPEG2000 ?
Le JPEG2000 demande pas des coûts supplémentaires, ce qui coûte le plus cher en mastering, c’est le travail dessus: les gens bossant dessus.
Only DCI has the right and authority to revise or change the material contained in this document, and any revisions by any party other than DCI are unauthorized and prohibited.
Bah, ça parait normal que seul le DCI peut valider le document final.
Mais derrière, c'est du même acabit qu'un RFC: on a des groupes de discussions techniques, chacun peut participer, chacun peut apporter sa pierre à l'édifice, mais au final, il faut des normes, des specifications, un tronc commun. Quand on propose des drafts pour le SMPTE, n'importe qui peut le faire (même moi, pour dire), puis il y a une discussion globale avec tout le monde du secteur du cinéma (et on parle surtout de techos dans les discussions, pas de financier). Et à la fin, quand tout le monde a challengé la proposition technique, elle est considéré comme validée et elle part en specs/normes.
Et c'est justement grâce à cela qu'on évite que des sociétés tierces (style Dolby par exemple), imposent leurs propres formats au détriment des specs/normes définies par l'ensemble des gens.
Mais pour les titiller on y travaille. Par le biais des archivistes dans un premier temps, mais ça permet de faire accepter FFV1 dans des logiciels… Donc après les autres peuvent basculer quand ils veulent.
Salut Zenitram,
A l'heure actuelle, je n'ai pas entendu parlé de FFV1 pour l'IMF (je suppose que c'est de cela dont tu parles) dans notre milieu;
A tout hasard, j'ai regardé rapidement ta doc (https://mediaarea.net/ollistd/MXF_FFV1)
Est-ce que tu aurais des MXF avec du FFV1 (mode Frame et mode Clip) accessible quelque part ?
Devant ce titre, c'est laisser supposer que le format DCP est un format propriétaire. Ce qui est le plus éloigné de la vérité. Les spécifications DCI sont disponibles à tous (cf. https://www.dcimovies.com/) [on pourra rétorquer qu'il faut aussi les docs SMPTE, il est vrai, c'est casse-bonbon, même pour moi]
Genre le cinéma (imaginez de vilains artefacts sur votre écran de cinéma géants).
Des artefacts sur un écran cinéma ?
En sachant que le JPEG2000 est wavelet, je comprends pas ce que tu as voulu dire.
(ou alors tu parles des projections MPEG/H264/265 qui sont en dehors du cinéma numérique)
les fichiers sont simplement trop lourds, donc impossible de décompresser en temps réel 24 (ou pire 30) images par seconde.
Je le fais depuis mon modeste portable.
Il suffit pour cela de choisir un autre layer de résolution.
avec (j'imagine) du décodage hardware.
Oui, c'est du FPGA la plupart du temps, une carte dédiée à la décompression JPEG2000 et une autre partie pour la partie cryptographique (ceci dit, j'ai bien vu un player tout faire directement via le CPU directement…)
à quand un format libre pour le cinéma où on remplacerait le JPEG2000 par du FFV1? Ça pourrait même être le même conteneur DCP sauf que les canaux vidéos seraient FFV1. Je pense que la question serait très politique (lobbying du cinéma)
C'est la même question que depuis 15 ans: "mais pourquoi le MXF DCI/DCP gère pas plus de format" (déjà le MXF le fait, on peut mettre d'autres format).
Il existe plusieurs réponses à cela:
Le format DCP se voulait être clair et précis: ne pas reprendre les erreurs du e-cinema (pre-d-cinema, donc avant 2005): celui d'avoir plusieurs formats possibles mais provoquant de multiples noeuds dans le cerveau pour la filière: Un cinéma qui peut gérer du MPEG ne pourra peut-être pas gérer du H264, et inversement (et là, je parle que de deux formats). Les distributeurs devront alors demander à chaque cinéma "quels formats tu supportes ?" en supposant que le projectionniste ou l'exploitant saura y répondre. (ou alors passer le relai au labo qui devra contacter chaque cinéma pour chaque release).
Cela coûte plus cher: supporter plus de format a un coût. Que ce soit en maintenance (les upgrades logiciels/hardwares) mais aussi côté distributeur et laboratoire: Il faudrait donc X versions d'un DCP pour gérer l'ensemble des formats possibles. Cela n'est pas possible ni viable sur la longueur.
Eviter la fuite en avant d'upgrade: C'est le principal reproche qu'on a eu dès 2005-2006: "Ouiiii mais vos truuuuucs, faudra tout le temps faire des mises-à-jour, avec le 35, c'était plus simple". Certes, mais bon, techniquement, un DCP de 2006 marche encode sur un projecteur de maintenant (et normalement un DCP de 2021 [Interop] devrait marcher sur un player DCP/DCI de 2006…)
La question du lobbying est un peu galvauder: les distributeurs/exploitants s'en foutent un peu, les studios aussi; les labos idem. Tout ce qu'on veut c'est avoir un workflow stable sur la durée. Et le but du DCI, c'était de créer un format utilisable par tous et pour tous et sans être emmerdé par une société qui pourrait faire pression (à l'époque, on voulait éviter que Microsoft y fasse main-basse)
VPF pour aider financièrement les petites salles à se numériser
Les plus petites salles n'ont pas eu de VPF (dans le sens classique).
Mais c'est une autre histoire (et celle là est très politique)
Et c'est sûr que c'est toujours plus intéressant d'avoir des formats libres.
En règle général ou pour le cinéma ? (en règle général oui)
Pour le cinéma ? hmmmm; un DCP c'est surtout du XML, de la cryptographie classique et approuvée, du PNG, du WAV/PCM, un gros container tout simpliste (MXF) qu'avec 5-6 lignes de python, tu le parses dans les grandes lignes.
On peut revenir sur le JPEG2000 mais tous les contributeurs qui ont participé et/ou des patents dessus (sur les premières 'Parts') ont clairement annoncé renoncer à faire quoique ce soit dessus - et pour ainsi dire, je vais être même plus radical, s'il n'y avait pas eu du JPEG2000, j'aurais peut-être milité pour du DPX ou OpenEXR directement, (voirement même un encodage direct des pixels RGB ou XYZ en 12 ou 16 bits directement dans les Picture Essence du MXF, donc Lossless), mais bon, la taille des DCP après…
Depuis 2005, j'ai fait des tonnes de DCP avec mon popre code ou avec des outils opensources (et je parle pas des outils de maintenant comme opendcp ou dcpomatic, à l'époque, il n'existait pas). A l'époque, on le faisait à coup de script shell, openssl, imagemagick et OpenJPEG.
Et puis, c'est pas comme si dans les specs DCI et CTP, on voyait pas des morceaux de code source en C pour aider aux implémentations.
Tu me diras "tu parles interopérabilité, pas de format libre", pourtant, le format DCP est très libre. Tous le monde a pu coder des trucs dessus, le réutiliser, en faire ce qu'ils voulaient (même rajouter des trucs dedans sans être inquiété et je parle en connaissance de causes), que ce soit pour des solutions pro(priétaire) comme des solutions opensources. Et de cette expérience assez heureuse, on l'a poussé jusqu'à développer son petit frère l'IMF - avec ses propres extensions et - miracle - la possibilité d'avoir d'autres formats dans les containers MXF (oui, n'avoir que du JPEG2000 non-lossless, c'est pas top pour l'archivage)
Désolé d'être un peu tendu sur la question, c'est juste que le débat "le cinéma numérique, c'est caca car pas libre, je l'entends depuis 2005 avec toujours les mêmes arguments.
[^] # Re: débat ouvert...
Posté par Prae . En réponse au journal On efface la communauté du libre. Évalué à 5.
Sur l'article, il existe une source secondaire centrée et disponible à la lecture, et d'autres non accessibles (publications papiers non retrouvables)
https://fr.wikipedia.org/wiki/L%C3%A9a-Linux#cite_note-6
Le souci est qu'initialement, les "modérateurs" demandaient "une source secondaire", ce qui a été fait par des contributeurs, puis ils ont demandé "une source secondaire centrée", ce qui a également été fait par de nouveaux contributeurs. Et d'un coup, ils ont demandé "deux sources secondaires centrées" au minimum.
# Reiser & Reiser
Posté par Prae . En réponse au journal Bientôt un nouveau système de fichier pour Linux . Évalué à 9.
Pour ceux qui débarquent :
Le créateur de ReiserFS est Hans Reiser (https://en.wikipedia.org/wiki/Hans_Reiser)
J'ai eu un moment de doute sur ce Jean-Marc…
[^] # Re: Vous pratiquez le JPEG2000 sans le savoir
Posté par Prae . En réponse à la dépêche Des formats d'image. Évalué à 4. Dernière modification le 23 juillet 2023 à 17:57.
Hello :)
Pour les copies projections, oui, avec perte.
Pour les archives type IMF, c'est sans (réversible).
Pour le coup, tu peux doubler les chiffres :-D
Shrek fait autour des 65G
Astérix - Le Secret de la potion magique : ~70G
Demon's Slayer : 68G
Prince d'Egypte : 72G
Pour les films classiques (sans 3D) :
Knives Out : ~250G
No Time To Die (4K / 2D): ~600G
Ad Astra (4K / 2D): ~500G
Avatar 2 : ~800-900G (tout dépend de la version, là, c'est la version 3D 48 fps)
Il faudrait que je fasse des stats sur les poids de maintenant
(voire même des stats sur le poids à travers le temps)
[^] # Re: Durable et fiable ?
Posté par Prae . En réponse au lien Qu'est-ce que le stockage sur Linear Tape-Open (LTO). Évalué à 4.
Retour d'expérience:
Ici (labo postprod + stockage film très longue période), on utilise du LTO + stockage HDD classique sur serveurs + retour à la pellicule (ça dépend des cas d'usages).
Et je te confirme pour le lossless 35mm, la chimie continuant sur la pellicule, même des années après son print, on peut avoir des dégradations suivant comment cela a été fait à l'origine. Il faut donc veiller au grain. (*krkrkr*désolé)
# Conférence Kernel Recipes
Posté par Prae . En réponse au lien Tilck - Un petit noyau compatible avec Linux. Évalué à 5.
Pour ceux qui veulent en savoir plus, l'évènement KernelRecipes a eu comme conférencier son auteur afin de parler du développement et des fonctionnalités de son kernel "éducatif", vous retrouvez la vidéo de la conférence ici : https://kernel-recipes.org/en/2022/talks/developing-tilck-a-tiny-linux-compatible-kernel/
[^] # Re: Feedback
Posté par Prae . En réponse au lien Mini serveur HTTP en Go pour le rendu de documents Markdown. Évalué à 1.
Le fait d'utiliser "ls" était justifié pour ne donner que le résultat escompté et dans l'ordre établi. Pour optimiser ses sorties, "find" évite de sort sa sortie.
Un exemple avec des documents créés initialement à différentes temporalités :
Pour le même résultat - celui de ne sortir que les fichiers md dans l'ordre - nous avons une commande simple qui donne satisfaction; Et de l'autre, une commande avec quasiment 2x plus d'arguments pour un résultat imparfait et non voulu.
[^] # Re: Feedback
Posté par Prae . En réponse au lien Mini serveur HTTP en Go pour le rendu de documents Markdown. Évalué à 2.
J'ai essayé de faire un gros
go clean -i -r -cache -testcache -modcache -fuzzcache.j'ai bien la dernière release comprenant le
hasStaticFile():Nouvelle compilation, rien de nouveau, j'ai toujours les images manquantes :/
Je continue la recherche, ça doit être un truc tout idiot en plus.
[^] # Re: Feedback
Posté par Prae . En réponse au lien Mini serveur HTTP en Go pour le rendu de documents Markdown. Évalué à 2.
Je vois bien tes derniers commits au niveau des logs et je vois bien tes modifs dans les sources en local. Pour être sûr, j'ai même refais un checkout complet.
C'est étrange si tu as un comportement totalement différent :-/
[^] # Re: Feedback
Posté par Prae . En réponse au lien Mini serveur HTTP en Go pour le rendu de documents Markdown. Évalué à -3.
Merci Captain Obvious.
Demain, tu nous apprends "tree" et "ls -R" ?
[^] # Re: Feedback
Posté par Prae . En réponse au lien Mini serveur HTTP en Go pour le rendu de documents Markdown. Évalué à 3. Dernière modification le 03 novembre 2022 à 15:28.
Rien de folichon, je me place dans mon répertoire avec plein de MD, je lance easymd, sans arguments.
En version shell:
Je prends un navigateur, je vais sur 0.0.0.0:8000, j'ai bien un listing du répertoire courant, je rajoute /DOC1 et cela m'affiche bien le document, mais sans les images. Et si j'essaye d'afficher les images, j'ai l'erreur interne.
Et c'est tout :-/
PS: un truc qui me vient, il n'y a pas un système de cache de build dans go qui pourrait me faire croire que je build les dernières sources mais en fait pas du tout ? (go clean ne change pas le résultat)
[^] # Re: Feedback
Posté par Prae . En réponse au lien Mini serveur HTTP en Go pour le rendu de documents Markdown. Évalué à 2.
Petit test avec la dernière release, j'ai toujours un souci :(
Par exemple, si j'essaye d'accéder à cette url http://localhost:8000/images/image.jpg
J'ai un
"Internal Server Error" "(c)ould not render document: open images/image.jpg/_index.md: not a directory"J'ai loupé un truc ? :-/
[^] # Re: Feedback
Posté par Prae . En réponse au lien Mini serveur HTTP en Go pour le rendu de documents Markdown. Évalué à 3. Dernière modification le 02 novembre 2022 à 14:52.
Est-ce que c'est possible que "si pas MD alors fichier static" ? plutôt que "c'est dans un répertoire static" ? parce que j'ai donné comme exemple /images/, mais j'ai d'autres répertoires avec différents éléments statiques, et pour le coup, je me dis que c'est plus simple de partir sur un "if mdfile { render }" et le reste, juste en push sur le http handler, non ?
Je me dis que si je suis dans ce cas de figure, d'autres aussi en l'utilisant;
Sinon pour le reste, c'est niquel, je trouve le rendu très proche de ce que j'ai sur d'autres renders markdown et le rendu final en html est plutôt clean.
# Feedback
Posté par Prae . En réponse au lien Mini serveur HTTP en Go pour le rendu de documents Markdown. Évalué à 3. Dernière modification le 02 novembre 2022 à 14:03.
Quelques petits feedbacks:
- Une petite doc pour build en go (un simple "go build main.go" par exemple) dans le README.md
- La gestion des fichiers "autres" : par exemple, j'ai des images en local, le serveur http ne les délivrent pas, il serait utile d'avoir un truc du genre (pseudocode rapidos ;)
UPDATE: en fait, cela part en erreur interne quand c'est un fichier non MD, et surtout il cherche par défaut un "_index.md", pourquoi pas directement index.md ?
# Virage, Ravin.
Posté par Prae . En réponse au journal Le virus bronsonisé. Évalué à 10.
Je lisais le Virus à l'époque. Quand c'est revenu, j'étais content. Quand j'ai lu les nouveaux éditos qui partaient de plus en plus en cacahouète, j'ai commencé à tiquer.
Ce dernier édito de fin de parution n'est qu'une confirmation de ce que je pensais.
# Delete account
Posté par Prae . En réponse au journal Comment je suis devenu un vacciné antivaxx.... Évalué à 5.
Bravo… et ta première et seule contribution sera - non pas sur Linux - mais sur des propos antivax, avec un compte créé le jour-même.
Ce journal devrait être supprimé et ton compte cloturé.
[^] # Re: mélange de genre plausible ?
Posté par Prae . En réponse au journal J'ai regardé the flight attendant. Évalué à 3.
Je vote pour le "osef, ça fait tech même si c'est pas cohérent" :)
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Prae . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. Évalué à -1.
C’est marrant, parce que là, tu parles de « modification de document DCP », ce que j’évoque jamais, mais de modification de DCP, de rajout, d’améliorations. (tu es d’ailleurs le seul à vouloir imposer un argumentaire de paille sur la modification de ces documents, alors que j’évoque des drafts et la participation à des groupes pour des RFC et faire évoluer la norme ou proposer sa propre normalisation après feedback de la communauté, ou au pire - sans docs - faire son propre format (fork) ou ajout dans le format DCP mais au risque d’être incompatible)
Mais pas de souci, on va prévenir les avocats du DCP.
Et juste après, on ira contacter le cabinet du WAV et les conseillers juridiques du XML.
On va dire que tu parlais du DCI.
Ils s’en foutent. Pour ainsi dire, et voir le niveau du je-m’en-foutisme, quand un constructeur a menti sciemment durant les procédures de validation DCI de leurs matériels, ils n’ont rien fait.
Et pour les modifications DCP, ils sont déjà au courant (comme l’ensemble de l’industrie).
Mais vas-y si cela te fait plaisir.
C’est pas comme si on appelait cela « de l’innovation ».
DCI, SMPTE et tous les acteurs du marché sont content des innovations, ils poussent même à cela. Tout le monde peut apporter sa pierre à l’édifice. Et quand cela devient assez intéressant, on passe à la partie SMPTE Draft pour officialiser la chose et dire aux autres qu’ils peuvent l’implémenter (ou non, c’est au choix des acteurs d’avoir envie d’utiliser ou non)
Tu veux modifier un DCP pour en faire autre chose ? vas-y, tu peux.
Tu veux distribuer ce DCP modifié à n’importe qui, vas-y aussi, tu peux, personne ne t’en empêche.
Tu en as marre de la normalisation DCP/DCI/SMPTE et tu veux faire ton fork? Pas de souci, écris ta propre doc, tu fais des implémentations à l’intérieur, tu nommes cela ZCP, personne ne t’en empêche.
C’est drôle, tu changes aussi de fusil d’épaule;
Depuis le début, tu dis que le MXF est pas libre, je te demande des preuves et je cite même un passage du document SMPTE stipulant que selon eux, il n’y en a pas (SMPTE, c’est surtout des techniciens, pas une armée de juristes)
Et là, non seulement tu me dis que c’est à moi de prouver que le MXF est pas libre (renversement de la charge de la preuve) MAIS en plus, tu en viens à me donner des phrases que j’ai jamais prononcé, comme le fait que les documents du SMPTE sont libres. T’es quand même fort.
Mais bon, on va la faire différemment: donc selon toi, dès que c’est derrière un paywall, cela devient propriétaire ?
Cela voudrait dire que ce dont parle cette documentation derrière ce paypal est propriétaire (et je suis quasiment sûr qu’on a pas le droit de distribuer ce PDF) ? https://www.iso.org/standard/74528.html . Il faudrait prévenir la communauté des développeurs.
Sur le SMPTE, tu as des docs sur le 8mm, 16mm et 35mm, automatiquement, ces formats deviennent propriétaires ? Tu ne peux pas modifier le 35mm pour le faire correspondre à tes besoins ? Tu ne peux pas redistribuer ces modifications pour d’autres ? (plot twist: si)
Allez, imaginons maintenant qu’il n’y ait pas de paywall, les docs SMPTE intègrent une ligne pour interdire la copie de la doc SMPTE (il faut être membre SMPTE). Pas de souci: Si cela ne te va pas, et bien, écris une documentation sur ton blog décrivant précisément le format MXF et place cette documentation en licence libre, personne ne t’y empêchera. (il existe même un bouquin en libre accès et sans avoir besoin d’être membre SMPTE). Tu peux même réécrire entièrement toutes les docs SMPTE avec tes propres mots, tes propres images et tes propres informations.
En aparté, je note que quand on te demande des infos sur le FFV1, par exemple un petit MXF, la première chose que tu fais, c’est de faire le videur de boite de nuit et de filtrer qui à le droit de voir ou non. C’est ton paywall à toi, je comprends.
Au fait, depuis le début, tu nous dis que le format DCP est 0% libre (et au passage le MXF).
Mais … depuis tout à l’heure, tu es pas en train de nous vendre ton projet d’intégrer du FFV1 dans le MXF. Le MXF étant le coeur même d’un DCP. Place ton MXF dans un DCP, tu viens de faire un DCP sans JPEG2000 mais avec du FFV1. Félicitations.
Et avec ce DCP modifié, tu peux maintenant le distribuer, tu peux écrire une doc expliquant tout le processus, tu peux en parler, personne ne te dira quoique ce soit. (cela peut même intéresser des gens du DCI ou de l’ISDCF)
Mais fais attention, il y a probablement déjà la Police du DCP derrière ta porte…
Et enfin, tu vocifères depuis le début que tout ceci n’est pas libre parce que tu n’as pas le droit de modifier un PDF, tu affirmes même que le MXF ne l’est pas, tu n’as pas pu fournir une once de preuve sur cette affirmation, je vais donc te citer des passages de « The MXF Book » par les principaux auteurs du MXF :
« The format should be open, standardized, and compression-format independent. » — History of MXF
« MXF was chosen, largely for its freedom from patents and the associated royalties » — DCI/DCP
A partir de là, on remettra donc en question l'ensemble de tes affirmations péremptoires et (toujours) hautaines.
———
A titre personnel, et parce que cela dure depuis trop longtemps, je vais arrêter de te répondre sur ce thread et j’ignorerais à l’avenir tes messages sur l’ensemble du site - mon employeur ne me paye pas (ou pas assez cher) pour répondre à tes commentaires et j’ai véritablement autre chose à faire dans ma vie que de subir continuellement ton égo surdimensionné et cela depuis pas mal d'années déjà.
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Prae . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. Évalué à 6.
Les deux ne sont pas antinomiques.
Pour cela, il faut démystifier toute la partie cryptographie du DCP avec ses clés.
Je vais essayer de résumer.
Un DCP est chiffré (s’il l’est, ce n’est pas obligatoire) via un ou plusieurs clés AES (128-CBC) - pour être plus précis, ce sont les fichiers MXF qui sont chiffrés - et pour être encore plus précis, ce ne sont que les layers (KLV) contenant les assets (images, audios, autres) qui le sont (le MXF n’est pas totalement chiffré, seulement les images/audios/autres intégrées dedans). Une ou plusieurs clefs AES peuvent chiffrer un ou plusieurs MXF. (en général, on recommande 1 MXF = 1 clef AES), un DCP peut avoir plusieurs MXF (au moins 2: les images et le son)
Quand il faut distribuer le film en salle, les clés AES ne sont pas distribuées comme cela, elles sont chiffrées via le certificat public du matériel en salle (RSA) puis intégrées dans un ou plusieurs containers cryptographiques (CipherValue) stockées dans un gros fichier XML intégrant des métadatas pour leurs gestions (KDM aka « Key Delivery Message »). Ce sont ces fichiers qui sont envoyés au cinéma.
Jehan a assez bien résumé les raisons et les besoins de ce workflow :
Un DCP, c’est environ entre 70 à 300G (voire plus si on fait de la 3D en 120 FPS en 4DX, etc..), il faut envoyer plusieurs copies aux différentes salles. Si un film doit être envoyé à 500 salles, il faudrait donc chiffrer 500 fois plusieurs gigas: c’est une perte de temps pour le laboratoire. Il suffit de chiffrer une fois le DCP référent (par exemple « STARWARS-3-VF ») et de l’envoyer dans les salles. Puis de chiffrer une petite clef AES 128 bits, 500 fois, avec le certificat de chaque player des différentes salles qui veulent/peuvent diffuser le film, c’est beaucoup plus rapide :)
Je vais aussi démystifier un autre truc de suite : Techniquement, pour déchiffrer un DCP, il suffit simplement des clefs AES. Rien de plus.
Le reste (KDM), c’est du folklore pour la distribution (et surtout pour respecter le workflow de distribution DCI et garantir une certaine sécurité des données même quand ils sont dans les players dans les différentes salles).
A titre de comparaison foireux: c’est comme mettre une clef de maison dans un colis et l’envoyer par la poste. (imagine que le colis soit un coffre dont le seul détenteur de la clef (ou une combinaison) permettant de l’ouvrir est celui qui va réceptionner le colis). C’est la clef de la maison qui permettra d’ouvrir la porte de la maison, pas le colis.
Quand on te dit qu’il faut des clés de lecture avec les dates autorisées, le type de matériel, etc. (pas le nombre de lecture), on doit te parler des KDM. Ce gros fichier XML contient quelques metadatas - dont notamment les informations techniques du film, la date de début et de fin (informatives seulement), les informations cryptographiques RSA, dont le Signer (celui qui a fait ce KDM) et le Recipient (celui va le déchiffrer : le player) et d’autres trucs qui seraient trop long à résumer. Et bien entendu, des containers cryptographiques (CipherValue) qui ne peuvent être déchiffrés que par celui qui détient le certificat privé (le player).
Quand on a déchiffré ces containers cryptographiques (via RSA, donc crypto asymétrique), ils contiennent des metadatas: Un ID, un thumbprint, un autre ID, le type du MXF, l’ID de la clef, les dates début-fin et enfin, la fameuse clef AES sur 128 bits.
A partir de là, tu comprends que si tu fais ton certificat RSA, tu génères un cert public, tu envoies cela pour avoir un DCP chiffré, tu peux déchiffrer la partie CipherValue, tu récupères les clefs AES pour déchiffrer tes MXF et tu peux ignorer les obligations. (aucun labo n’acceptera ton certificat louche :) mais techniquement, il sera valide)
Dans une autre mesure, tu peux aussi faire ton propre DCP : tu génères tes propres clefs AES et tu chiffres tes MXF. Tu as maintenant toute la liberté de la méthode d’envoi et de réception des clefs AES auprès de ton interlocuteur: soit tu es joueur et tu les envoies en clair (mais on sait que c’est pas bien), soit tu demandes à ton interlocuteur son certificat public pour chiffrer un message: tu viens de créer un ersatz de KDM (note que ceci n’est pas le workflow DCI pour la distribution en salle, nous aurons toujours un couple DCP chiffré avec des clefs AES + KDM avec clefs AES chiffrés par un certificat public)
Petit bonus : il existe aussi ce qu’on appelle DKDM, ce sont simplement des KDM - mais avec un autre nom - qui ne sont pas à destination des salles de cinéma, mais des laboratoires ou autres professionnels : Cela permet de s’échanger des clefs AES entre professionnels (par exemple, un labo qui doit générer des KDM mais pour un DCP qu’un autre laboratoire à fait)
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Prae . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. Évalué à 3.
Ah ah, non, pas du tout, c'est celui de Cg :D
J'avais lu rapidement ton message en réponse à Cg, comme cela, je n'ai pas vu d'erreur, je vais le relire pour voir s'il y a des trucs à ajouter, mais je pense pas, tu as assez bien résumé les causes-conséquences de tels ou tels choix
Idem
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Prae . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. Évalué à 3.
Je n'ai pas compris pas ta phrase, Qu'est ce que tu entends par "aux archives qui utilisent MXF" ? Pourtant, dans le cinéma, on utilise du MXF, l'IMF est fait pour cela justement, et on l'utilise pour les échanges entre labos, entre diffuseurs et pour l'archivage
Pour l'étudier en amont. Il est préférable de faire de la veille technologique avant plutôt de se réveiller un jour et en pleine réunion nous demander de supporter un nouveau format inconnu encore. (phase d'étude, de compréhension, d'implémentation)
Après, je peux comprendre ta réticence car par encore stabilisé, mais pour le coup, il serait préférable d'ouvrir un peu plus à ce niveau, même si c'est du draft, pour que les gens puissent l'étudier, le comprendre, faire des retours possibles et le jour J, quand cela est enfin stabilisé, de pouvoir l'implémenter assez rapidement (vu qu'ils connaitront déjà plus ou moins le format).
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Prae . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. Évalué à 4.
En fait, tu sais quoi, je serais même d’accord.
Je me fous du JPEG2000 depuis le début, j’aurai tellement aimé que ce soit du DPX ou de l’OpenEXR même, mais bon, après, c’est compliqué.
Ceci dit, l’IMF propose déjà ce principe. Pour ceux qui ne savent pas - je vais résumer à mort :
IMF = DCP pour l’échange entre labo ou archivages.
Donc l’IMF propose que le container « image » ne soit pas forcément du JPEG2000 avec pertes.
Au temps pour moi alors :)
Alors, c’est un peu compliqué :)
Moi, j’utilise un outil interne développé par un gars de chez nous, ultra compétent et qui a pondu un lecteur DCP en 1 mois.
Donc, bien évidemment, c’est pas opensource, et c’est même pas distribuable :)
Sinon, il y a d’autres gars qui chez nous qui ont participé à l’implémentation MXF/JPEG200 dans ffmpeg (dans mes souvenirs)
Et j’ai cru comprendre que VLC dernière version (ou version night-build) supporte maintenant la lecture d’un DCP sans bidouille (à confirmer, j’avoue ne pas avoir regarder plus que cela)
Oui, si tu prends un 2K/4K avec son potentiel max, il vaut mieux avoir un CPU bien costaud (d’où le fait que ce soit via FPGA)
Après, tu peux ne décoder que les autres résolutions, cela reste parfaitement acceptable, même sur un petit portable.
J’ai eu beaucoup de fois des gens me demandant « mais pourquoi JPEG2000 » ?
Tout simplement, il faut revenir 15 ans en arrière, en 2001, il faut créer un format exploitable en salle, donc avec toutes les contraintes et surtout la base technologique qu’on avait à l’époque: quel est le format qui permettrait de pouvoir avoir des frames assez compressées mais tout en ayant un bon rendu et surtout single-frame (dans le sens où une perte d’image ne provoque pas de problème sur les suivantes).
Ils ont donc produit un court-métrage qui s’appelle « StEm » (voir fiche IMDB), c’est un pur film technique, dans le sens où, y’a une histoire, des acteurs, des décors, des cadres. Mais tout ce qui a été mis à l’image est là pour tester les compressions. Par exemple, faire un focus sur une personne derrière un grillage avec de la pluie et un travelling, tu perds une partie des formats car leurs algos n’aiment pas trop cela.
Le JPEG2000 est - à ma connaissance de l’époque - le seul format qui est sortie vainqueur.
Maintenant, si c’était à refaire (plot twist: StEm2 arrive…), peut-être qu’un autre format aurait gagné, peut-être même FFV1.
Pour avoir été distributeur et travaillant dans l’un des plus anciens (et gros?) labos et faire depuis des années DCP et envoi: je n’ai jamais dit que c’était comme cela qu’on travaillait :)
J’ai dit que dans le monde du e-cinema (donc pre-2005), c’était comme cela, car dans le monde du e-cinema, chaque exploitant qui voulait se faire une projo « numérique » faisait sa tambouille interne. Et là, c’est pas le distributeur qui va contacter l’exploitant (il peut le faire hein, mais techniquement, c’est pas leur problème), à l’époque, c’était le labo qui se chargeait de demander quel format l’exploitant supportait.
Depuis le DCI/DCP, on a plus ce genre de question, tout le monde parle la même langue.
Mais bon, c’est dans le meilleur des mondes, car si un DCP ne fonctionne pas, l’exploitant va lancer un warning, au pire, il va voir son distributeur, au mieux, il se pointe chez nous et nous demande un SAV sur son matériel :)
Je vais être plus direct: le labo ne contacte presque plus les salles au cas par cas, car on a travaillé en amont pour avoir assez d’informations sur la salle pour savoir si tout se passera bien.
Par exemple, un exploitant nous demande un DCP 4K Atmos, et on voit qu’il a qu’un player DCI 2K et sans matériel Atmos, on va l’appeler pour lui demander s’il y a pas un souci (soit on pas les bonnes infos, soit il a pas compris que cela ne servait à rien de lui envoyer un DCP aussi « énorme » alors qu’il a pas le matériel pour l’exploiter, même s’il pourrait le faire, mais c’est un peu inutile)
Je vais faire un peu d’histoire.
Il y a eu les principaux tiers de confiance dès 2005 (je travaillais dans l’un des deux principaux sur le marché FR, je te laisse savoir qui est qui :)
Au début, il y a eu une proposition des tiers pour travailler avec le CNC: les tiers faisaient les plus gros exploitants, le CNC les plus fragiles.
Pour une simple raison: l’argent du CNC devait être utilisé à bon escient, aider les plus précaires que les contrats VPF ne pouvaient gérer (les mono-salles qui ouvrent que les vacances par exemple). Cela avait un autre but : l’argent des distributeurs devaient servir pour les exploitants à passer au numérique. Sauf que pour le CNC, ils ont pas appréciés (pourquoi ? on ne sait pas, enfin, on a une idée, mais bon). Ce qui a fait que le CNC a voulu lancer son propre système de VPF (mais en faisant n’importe quoi), il a donc provoqué plus de problème que d’en résoudre. Ce qui a valu de passer devant l’autorité de la concurrence qui a recadré le CNC. Le CNC ne pouvait donc plus faire de VPF.
D’où mon affirmation un rapide et direct: je parlais surtout du CNC.
Je sais qu’il y a eu des petites structures qui ont mis en place des systèmes de VPF avec des exploitants plus fragiles :)
Le « plus petites salles », c’est pour dire que ceux qui rentraient pas les contrats VPF plus classiques avec les principaux tiers se tournaient assez généralement vers le CNC - mais le CNC n’avait pas le droit de faire du VPF - donc ils ont fait un truc chelou à base de « subventions remboursables mais on ferme les yeux si tu rembourses pas » (attention, cela a peut-être changé depuis mais à l’époque, c’était pas le cas)
J’ai essayé de résumer rapidement 17 ans d’histoire du VPF (en omettant plein de trucs)
Cf. « Le CNC a fait n’importe quoi et - à mon sens - a fait perdre quasi 3 ans d’avance sur la numérisation des salles.
(on peut en parler plus en détail si tu veux)
C’est peut-être que j’ai mal compris ton message d’origine :)
Et que pendant pas mal d’années, surtout au début, j’ai vu certaines personnes dans l’opensource dire n’importe quoi. (j’ai repéré un message plus en dessous sur la cryptographie qui est justement dans ce cas :)
Désolé.
Si tu veux mon avis tranché dessus: je serais ravi d’avoir autre chose que du JPEG2000 :)
(je l’ai même dit plusieurs fois sur d’autres formats que je trouve mieux, mais c’est plus dans le sens « non destructrice », mais impossible pour des copies séries à distribuer en salle)
Désolé, réaction épidermique :-D
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Prae . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. Évalué à 1.
Je vois pas ce que tu veux dire. Les specs ne fournissent pas le code source d’un décodeur DCP, cela n’a pas de sens.
Au mieux, ce que tu as, ce sont des bouts de code pour tels ou telles parties (genre vérif d’un hash crypto, ou de check xml, etc…)
Et la doc DCI formalise pas mal de choses et faire des références sur des normes.
Tu es sérieusement entrain de m’apprendre ce qu’est le SMPTE ? :)
Que les docs SMPTE ne soient pas dispos à tout à chacun, oooh bordel oui, c’est relou.
Mais cela ne veut pas dire que tu peux pas implémenter toi-même, cela ne veut pas dire que tu peux pas lire la documentation, ni même faire ce que tu veux du format indiqué dans le document (après, tu fais ce que tu veux de l’implémentation, c’est ton problème)
Ou alors pour toi, cela voudrait donc dire « libre == gratuit » ?
J’ai déjà donné ma réponse au dessus.
Tout le monde peut participer aux specs DCI et aux normes SMPTE, il suffit d’être dans un groupe de travail et de faire une proposition (style RFC).
What ?
J’ai vu aucune indication de non-liberté dans le SMPTE-377, ni même dans le bouquin de Nick Wells.
Et c'est même écrit en préambule du SMPTE-377 qu'à leur connaissance, il n'y a droit de brevet sur le format MXF.
Et j’ai vu personne avoir de problème pour l’implémentation d’un read/write d’un MXF dans leurs logiciels et encore moins de takedown sur des projets opensources, même connu par tous.
Nop.
Sa phrase laisse supposer qu’on voit ses artefacts comme de vulgaire gros carrés de compression. Donc non.
Prendre les PDF sur dcimovies.com, tu fais ce que tu veux, j’ai vu personne avoir de problème avec et cela depuis plus de 15 ans.
Ou alors tu parles des docs SMPTE.
Tu me feras pas croire que tu sais pas parser du MXF :)
Tu me feras pas croire que tu sais pas comment marche un MXF :)
Et tu me feras jamais croire que après avoir trouvé et récupéré les KLV des images, tu peux pas appliquer une passe openjpeg dessus :)
Et allez, vu qu’une partie semble bloqué sur le JPEG2000: dans les MXF subs, ce sont des PNG, donc on a une succession de KLV facilement lisible par tout à chacun et dont certains sont justes des PNG, tu vas me faire croire que tu n’as absolument rien en contenu audiovisuel ?
(et tu oublies les MXF Audio, le WAV est devenu proprio ?)
Mais bullshit bordel, on le fait nous ! Même Dolby.
On modifie des DCP, on rajoute des trucs.
Le seul truc, c’est que tu perds ta « normalisation » DCP, tu peux plus appeler cela DCP (pas au sens juridique), tu es obligé de dire que tu as rajouté des trucs et que si certains outils font des tests d’intégrité très sévères, ils peuvent le refuser (et c’est normal !)
Et si tu veux que tes metadatas ou tes modifs soient prises en compte par l’ensemble du secteur, et bien tu écris une jolie RFC aka SMPTE Draft pour que cela devienne valide pour tous (et encore, t’es même pas obligé, tu peux très bien faire une doc technique classique et la publier, je crois même que Dolby avait fait cela au début pour son format Atmos)
Si t’as envie de faire un DCP à ta sauce, tu le fais, mais après faut pas se plaindre que les outils des copains soient ne l’aime pas, soit le refuse.
C’est comme si tu voulais modifier des trucs dans les headers d’un PNG sans respecter la norme PNG et après râler que les outils n’arrivent plus à ouvrir ton PNG.
Et ?
On va encore avoir cette discussion sur le prix du matériel en salle et donc « il faudrait une norme pour réduire les coûts »
Désolé, mais vous avez 15 de retard, j’ai déjà eu ce genre de discussion ici en plus.
Non, c’est ton fait. Tu peux faire ce que tu veux du format, tu peux même rajouter des types de KLV dans le MXF sans que personne ne vienne te prendre la tête. Mais après, si ce n’est pas dans une doc, ne vient pas chouiner que personne ne supporte tes ajouts.
Le monde du cinéma est vaste. C’est comme parler d’informatique et n’évoquer que le rôle d’un sysadmin.
Le monde du cinéma ne se fout pas du lossless, quand je suis en tournage, j’ai vu aucun chef opérateur dire « ouais, je m’en fous qu’on est une compression dégueulasse qui va saloper mon boulot ».
Le reste du workflow, que ce soit en tournage, en postproduction ou en archivage, j’ai vu quasi personne de sérieux me dire « je m’en fous de perdre en qualité ».
Le seul moment où ils sont tolérants (et je parle bien de tolérance, pas de je-m’en-foutisme), c’est lors des copies séries pour les envoyer dans les salles de cinéma. Ils acceptent, là, de perdre un peu. Et quand je dis un peu, c’est que cela a été validé par le chef-opérateur en postprod et le réalisateur.
Et pour info, ils avaient cette même tolérance avec le 35mm, d’où le fait que les copies pour les salles de cinéma étaient différentes des tirages pour les festivals.
C’est quoi ce lien avec « JPEG2000 == thune » Quel est le rapport ?
Tu penses que ça sera moins coûteux de faire une master FFV1 qu’un master JPEG2000 ?
Le JPEG2000 demande pas des coûts supplémentaires, ce qui coûte le plus cher en mastering, c’est le travail dessus: les gens bossant dessus.
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Prae . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. Évalué à 6.
Bah, ça parait normal que seul le DCI peut valider le document final.
Mais derrière, c'est du même acabit qu'un RFC: on a des groupes de discussions techniques, chacun peut participer, chacun peut apporter sa pierre à l'édifice, mais au final, il faut des normes, des specifications, un tronc commun. Quand on propose des drafts pour le SMPTE, n'importe qui peut le faire (même moi, pour dire), puis il y a une discussion globale avec tout le monde du secteur du cinéma (et on parle surtout de techos dans les discussions, pas de financier). Et à la fin, quand tout le monde a challengé la proposition technique, elle est considéré comme validée et elle part en specs/normes.
Et c'est justement grâce à cela qu'on évite que des sociétés tierces (style Dolby par exemple), imposent leurs propres formats au détriment des specs/normes définies par l'ensemble des gens.
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Prae . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. Évalué à 3.
Salut Zenitram,
A l'heure actuelle, je n'ai pas entendu parlé de FFV1 pour l'IMF (je suppose que c'est de cela dont tu parles) dans notre milieu;
A tout hasard, j'ai regardé rapidement ta doc (https://mediaarea.net/ollistd/MXF_FFV1)
Est-ce que tu aurais des MXF avec du FFV1 (mode Frame et mode Clip) accessible quelque part ?
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Prae . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. Évalué à 5.
Devant ce titre, c'est laisser supposer que le format DCP est un format propriétaire. Ce qui est le plus éloigné de la vérité. Les spécifications DCI sont disponibles à tous (cf. https://www.dcimovies.com/) [on pourra rétorquer qu'il faut aussi les docs SMPTE, il est vrai, c'est casse-bonbon, même pour moi]
Des artefacts sur un écran cinéma ?
En sachant que le JPEG2000 est wavelet, je comprends pas ce que tu as voulu dire.
(ou alors tu parles des projections MPEG/H264/265 qui sont en dehors du cinéma numérique)
Je le fais depuis mon modeste portable.
Il suffit pour cela de choisir un autre layer de résolution.
Oui, c'est du FPGA la plupart du temps, une carte dédiée à la décompression JPEG2000 et une autre partie pour la partie cryptographique (ceci dit, j'ai bien vu un player tout faire directement via le CPU directement…)
C'est la même question que depuis 15 ans: "mais pourquoi le MXF DCI/DCP gère pas plus de format" (déjà le MXF le fait, on peut mettre d'autres format).
Il existe plusieurs réponses à cela:
Le format DCP se voulait être clair et précis: ne pas reprendre les erreurs du e-cinema (pre-d-cinema, donc avant 2005): celui d'avoir plusieurs formats possibles mais provoquant de multiples noeuds dans le cerveau pour la filière: Un cinéma qui peut gérer du MPEG ne pourra peut-être pas gérer du H264, et inversement (et là, je parle que de deux formats). Les distributeurs devront alors demander à chaque cinéma "quels formats tu supportes ?" en supposant que le projectionniste ou l'exploitant saura y répondre. (ou alors passer le relai au labo qui devra contacter chaque cinéma pour chaque release).
Cela coûte plus cher: supporter plus de format a un coût. Que ce soit en maintenance (les upgrades logiciels/hardwares) mais aussi côté distributeur et laboratoire: Il faudrait donc X versions d'un DCP pour gérer l'ensemble des formats possibles. Cela n'est pas possible ni viable sur la longueur.
Eviter la fuite en avant d'upgrade: C'est le principal reproche qu'on a eu dès 2005-2006: "Ouiiii mais vos truuuuucs, faudra tout le temps faire des mises-à-jour, avec le 35, c'était plus simple". Certes, mais bon, techniquement, un DCP de 2006 marche encode sur un projecteur de maintenant (et normalement un DCP de 2021 [Interop] devrait marcher sur un player DCP/DCI de 2006…)
La question du lobbying est un peu galvauder: les distributeurs/exploitants s'en foutent un peu, les studios aussi; les labos idem. Tout ce qu'on veut c'est avoir un workflow stable sur la durée. Et le but du DCI, c'était de créer un format utilisable par tous et pour tous et sans être emmerdé par une société qui pourrait faire pression (à l'époque, on voulait éviter que Microsoft y fasse main-basse)
Les plus petites salles n'ont pas eu de VPF (dans le sens classique).
Mais c'est une autre histoire (et celle là est très politique)
En règle général ou pour le cinéma ? (en règle général oui)
Pour le cinéma ? hmmmm; un DCP c'est surtout du XML, de la cryptographie classique et approuvée, du PNG, du WAV/PCM, un gros container tout simpliste (MXF) qu'avec 5-6 lignes de python, tu le parses dans les grandes lignes.
On peut revenir sur le JPEG2000 mais tous les contributeurs qui ont participé et/ou des patents dessus (sur les premières 'Parts') ont clairement annoncé renoncer à faire quoique ce soit dessus - et pour ainsi dire, je vais être même plus radical, s'il n'y avait pas eu du JPEG2000, j'aurais peut-être milité pour du DPX ou OpenEXR directement, (voirement même un encodage direct des pixels RGB ou XYZ en 12 ou 16 bits directement dans les Picture Essence du MXF, donc Lossless), mais bon, la taille des DCP après…
Depuis 2005, j'ai fait des tonnes de DCP avec mon popre code ou avec des outils opensources (et je parle pas des outils de maintenant comme opendcp ou dcpomatic, à l'époque, il n'existait pas). A l'époque, on le faisait à coup de script shell, openssl, imagemagick et OpenJPEG.
Et puis, c'est pas comme si dans les specs DCI et CTP, on voyait pas des morceaux de code source en C pour aider aux implémentations.
Tu me diras "tu parles interopérabilité, pas de format libre", pourtant, le format DCP est très libre. Tous le monde a pu coder des trucs dessus, le réutiliser, en faire ce qu'ils voulaient (même rajouter des trucs dedans sans être inquiété et je parle en connaissance de causes), que ce soit pour des solutions pro(priétaire) comme des solutions opensources. Et de cette expérience assez heureuse, on l'a poussé jusqu'à développer son petit frère l'IMF - avec ses propres extensions et - miracle - la possibilité d'avoir d'autres formats dans les containers MXF (oui, n'avoir que du JPEG2000 non-lossless, c'est pas top pour l'archivage)
Désolé d'être un peu tendu sur la question, c'est juste que le débat "le cinéma numérique, c'est caca car pas libre, je l'entends depuis 2005 avec toujours les mêmes arguments.