Si la compression vidéo sans perte est moins tendance que celle avec perte, elle reste utile dans certains domaines (par exemple l’archivage, que ce soit pour son stockage ou sa transmission, qu’il concerne des enregistrements de procès importants pour l’histoire ou le dernier blockbuster à la mode).
L’Internet Engineering Task Force (IETF) avait déjà normalisé des formats de compression avec perte (Opus, pour l'audio), mais pas encore de format sans perte : c'est à présent chose faite, cette fois-ci en matière de vidéo, avec la normalisation de FFV1 sous le doux nom de RFC 9043.
Sommaire
- Un format de compression intra-image, sans perte, à la spécification libre et normalisée
- Les usages
- Un peu d'histoire
- Pourquoi normaliser ?
- La suite
Un format de compression intra-image, sans perte, à la spécification libre et normalisée
FFV1 (« FF video codec 1 ») est un format vidéo sans perte, qui existe depuis 2003 sans avoir été normalisé… jusqu'à aujourd'hui, avec la publication de la RFC 9043. Cette RFC décrit les versions 0, 1 et 3 de ce format (ce n'est pas une faute de frappe, la version 2 a été abandonnée en cours de route au profit de la version 3). Elle est une RFC informelle car elle décrit l’existant (puisque le décodeur de référence a été écrit longtemps avant la spécification).
On parle de codec intra-image (ou intra-frame) pour signifier que la compression intervient en analysant les similitudes au sein de chacune des images prises isolément (par opposition aux codecs inter-frames qui analysent les similitudes au sein d'images successives).
FFV1 prend en charge les images en niveau de gris, YUV ou RGB, avec ou sans canal alpha (transparence), sans limitation du nombre de bits par composante (en pratique 8 à 16 bits par composante sont utilisés), de n’importe quelle taille (il n’y a pas de notion de « profil » de performance, donc il faut prévoir la machine en conséquence : ne comptez pas faire de la 4K en temps réel avec une machine de bureau même si l'encodage et le décodage restent nettement plus léger que pour du JPEG 2000 tout en compressant légèrement mieux).
FFV1 est volontairement basé sur des techniques ayant plus de 20 ans pour ne pas risquer la moindre menace des chasseurs de brevets. Pour avoir un format ouvert et offrir ce qui est nécessaire pour le garder, tous les auteurs ont pris un engagement formel (voir les règles de l'IETF en la matière).
Les usages
FFV1 fonctionne sur la majorité des outils libres (merci FFmpeg) et contient des fonctionnalités comme le découpage en pavés pour faciliter le multi-threading, ou le contrôle d’erreurs de transmission (CRC) pour vérifier que le contenu n’est pas corrompu pendant le stockage ou la transmission.
Un exemple d’usage de FFV1 peut être vu dans le projet RAWcooked, qui compresse des DPX, TIFF, EXR, WAV non compressés en Matroska-FFV1-FLAC tout en permettant une réversibilité vers les fichiers d’origine au bit près si besoin, ce qui est très important pour certaines institutions qui ont des engagements légaux à restituer exactement les fichiers qu’on leur a demandé d’archiver. C'est comme un ZIP, mais plus performant autant en vitesse qu’en taux de compression tout en étant directement lisible par exemple par VLC.
Un peu d'histoire
FFV1 a été créé par Michael Niedermayer en 2003 comme une expérience pour avoir un format vidéo sans perte et libre dans FFmpeg (dont il a été le mainteneur entre 2004 et 2015).
- La version 0 ne gérait que du 8 bits par composante.
- La version 1 a ajouté la gestion de profondeur de couleur de plus de 8 bits et, en théorie, de moins de 8 bits également.
- La version 2 a été abandonnée au profit de la version 3, pour ajouter un principe de version mineure.
- La version 3 ajoute la gestion de plusieurs « pavés » par image, chaque « pavé » étant indépendant afin de permettre le décodage multi-thread, ainsi que le contrôle d’erreurs de transmission (CRC) afin de vérifier l'intégrité du flux.
La version 3 et la prise en charge en pratique du 16 bits par composante (la spécification le permettait déjà, mais il n'y avait pas d'encodeur ni de décodeur) ont été financées principalement par des organisations nationales d'archivage qui n'ont pas voulu payer pour une boîte noire non libre et non évolutive, en préférant financer, pour moins cher, un développeur pour intégrer leurs demandes dans FFV1 (lequel n'était pas adapté au multi-thread alors que les processeurs multi-cœurs se répandaient). Et puis, ça a profité à d'autres organismes d'archivage en mutualisant les coûts… Utile, le libre ! ;-)
Ces organismes d'archivage ont ensuite convaincu l'Union Européenne du besoin d'un format libre pour leur activité. L'UE a commencé à financer une suite de tests de conformité ainsi que l'écriture d'une spécification, en collaboration avec un organisme de normalisation (qui dit archivage dit besoin de pérennité) dans le cadre du projet PREFORMA. MediaArea a été choisi pour faire ces développements (c'est ici que l'auteur de cette dépêche a commencé à s'impliquer dans le processus).
C'est alors que MediaArea a milité pour convaincre les représentants de l'Union Européenne de passer par l'IETF, plus ouverte que l'ISO – tant sur la spécification que sur le mode de développement. Historiquement et comme son nom l'indique, l'IETF a pour cible de travail les normes d'Internet. Son objet s'est élargi comme en témoignent la normalisation du format audio avec perte Opus en 2010-2018 et sa tentative de normalisation d'un codec vidéo avec perte en 2012-2020. Et l'IETF a accepté notre demande ! En nous apportant son soutien technique et humain : merci à eux pour cette aventure.
Les contraintes administratives étant ce qu'elles sont, le projet PREFORMA s'est arrêté à une date fixe (fin 2017), avant la normalisation — les joies des projets avec des institutions qui ont des budgets très bornés dans le temps. Cependant, MediaArea ainsi que des contributeurs volontaires ont continué le travail jusqu'à la normalisation.
Pourquoi normaliser ?
Vous pouvez vous demander pourquoi passer du temps à normaliser. Il s’avère que l’absence de norme est un argument contre l’usage de formats libres dans beaucoup d’institutions, face à MJPEG 2000 ou H.264 en mode sans perte, tous deux non libres mais normalisés. C’est donc une excuse en moins pour les institutions de ne pas choisir du libre. C'est aussi pour l'équipe qui a travaillé sur le format une preuve de maturité de FFV1 et une confirmation de qualité grâce à la relecture par les pairs.
Le travail de normalisation a en plus permis de détecter des problèmes dans l'implémentation de référence, avec pour résultat parfois de corriger FFmpeg et parfois de documenter les problèmes qu'on ne peut corriger sans casser la prise en charge des flux déjà créés (ces problèmes pourront être supprimés dans la prochaine version de la spécification). Enfin, on a pu clarifier certaines parties du format afin d'avoir un meilleur support à long terme de celui-ci.
Le passage par l'IETF n'a pas été de tout repos (vous pouvez voir le long historique du brouillon de RFC FFV1), ses procédures étant complexes (sans être inutilement compliquées : c'est légitimement complexe vu que c'est prévu pour du long terme et qu'il y a une cohérence à avoir entre les RFC), avec des surprises le long de la route genre la mise en ballotage (tout vert aujourd'hui mais ça ne l'était pas au début) ou cette bévue avec la dépendance bloquante à Matroska alors que ce format n'est pas encore normalisé, vue seulement dans la dernière ligne droite avant d'avoir notre numéro, mais nous avons été très bien accompagnés avec toujours une explication constructive sur les refus de passer à l'étape suivante. Au final on peut remercier l'IETF pour son soutien.
Bien que la version 3 soit aujourd'hui la plus utilisée, la RFC contient aussi la documentation des versions 0 et 1, utilisées par le passé et même aujourd'hui : lorsqu'on a par exemple du 8 bits, il n'est pas toujours utile de faire passer par la version 3, incompatible avec les anciennes versions de FFmpeg. Et puis, le temps à consacrer à la rédaction était bien faible vu les petites différences.
En termes d’implémentation, il existe actuellement un seul encodeur (FFmpeg) mais plusieurs décodeurs :
- FFmpeg (forcément), licence libre gauche d'auteur LGPL2+,
- MediaConch, licence libre permissive BSD-2-Clause (après un passage temporaire par du GPL3/MPL2), comme vérificateur de conformité qui inclut la conformité FFV1,
- go-ffv1 licence libre permissive ISC, comme une implémentation en Go fait pour le fun mais aussi pour tester une implémentation directement à partir de la spécification),
La suite
Le groupe IETF dédié, Codec Encoding for LossLess Archiving and Realtime transmission (CELLAR), ne compte pas en rester là et la normalisation de Matroska (pour la partie conteneur) puis de FLAC (pour de l’audio sans perte) est en cours, tout en travaillant à améliorer encore FFV1 dans une prochaine version. IETF oblige, les travaux sont ouverts à tous : vous pouvez les suivre et y participer sur la liste de diffusion de CELLAR ou sur le GitHub de CELLAR (exception faite de la partie FFV1 qui est encore sur le GitHub de FFmpeg).
La prochaine version devrait contenir un nettoyage de la spécification précédente (la RFC est informelle, elle décrit l'existant, y compris les bugs), une gestion des matrices Bayer, la possibilité de stocker une version non encodée (parfois la version encodée est plus grosse que le source), et d'autres améliorations suivant la motivation des développeurs. Les idées sont décrites dans le document ffv1-v4-goals.
Pour l’anecdote, Matroska et FLAC sont maintenant explicitement sous le chapeautage de l’IETF et leurs dépôts de développement transférés au groupe CELLAR, mais pour FFV1 ce n’est pas encore le cas.
Un encodeur/décodeur indépendant pour FFV1 avec accélération CPU (AVX-2/AVX-512) et GPU (CUDA) est en cours de développement par MediaArea, sous licence libre mais sans doute pas en diffusion publique dans un premier temps.
Licence du document : CC-By v2.0
PS : l’auteur de cette dépêche va avoir son orgueil encore plus gonflé, étant donné qu’il vient d’avoir son nom dans une RFC :).
Aller plus loin
- RFC 9043 (150 clics)
- Liste des institutions qui utilisent FFV1, sur la Wikipédia en anglais (74 clics)
- Tout savoir sur FFV1 et les codecs à fin d'archivage, sur Österreichische Mediathek (57 clics)
- Histoire de FFV1 par Peter Bubestinger (diaporama 2015) (33 clics)
- Paramètres d'encodage en FFV1 avec FFmpeg (95 clics)
# Archivage
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
C'est effectivement super bien pour l'archivage long terme. Ce qui est dommage sur ces questions d'archivage, c'est que par exemple les revues scientifiques acceptent du PDF non A, souvent les dernières versions alors que justement, les formats dédiés pour l'Archivage devraient être systématiquement utilisés !
Donc on verra ce qu'il en est. Longue vie à ce format !
# Performances de compression par rapport à d'autres formats avec*pertes
Posté par lapineige (site web personnel) . Évalué à 3.
Bonjour,
Par curiosité, a-t-on des comparatifs de performances de compression (taux de compression, vitesse de compression/décompression) avec des formats avec pertes ?
L'usage n'est certes pas le même et le comparatif probablement pas vraiment à l'avantage de ce format, mais je suis curieux de voir si la différence est vraiment marquée.
Aussi, pour un format basé sur des technologies vielles de 20 ans et une compression intra-frame uniquement, il a l'air étonnamment performant face au h.264 lossless !
Merci
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Zenitram (site web personnel) . Évalué à 10.
Sans perte : on a fait une comparaison avec des encodeurs JPEG-2000 libres, pour résumer on gagne un peu (2%) à caractéristiques identiques (pas de slices) en taux de compression et 3x plus rapide. Sachant que JPEG-2000 a des soucis (plus ou moins théoriques) de brevets et bien plus complexe. On n'a pas testé le H.264 Lossless (pas intéressant pour sponsors du fait des brevets) mais il faut clairement qu'on fasse de la comparaison pour connaitre quand les gens ne sont pas intéressés par la problématique de brevets, surtout qu'il parait qu'en plus des brevets H.264 Lossless rame quand même pas mal donc on aurait un avantage affiché de FFV1.
Avec perte : vu que tu choisis le taux de compression que tu veux, impossible de comparer cette partie mais en gros tu ne joues pas du tout dans la même la cours (penser ~400 Mbps pour du HDTV Lossless contre ~20 Mbps pour un flux de qualité acceptable, soit ratio de 20), et bon en perf c'est super optimisé (AVX-512 etc) même en logiciel pur (ne parlons pas des cartes graphiques qui ont en matériel), et bon rien qu'en gestion des buffers à copier faut pas imaginer des perfs comparables (avec FFMpeg/x264 tu peux faire de la HDTV tranquille avec un bon CPU alors que limite temps réel avec FFV1). Mais les usages sont bien différents, donc on ne regarde pas plus que ça et on ne s'y interesse pas vraiment, c'est peut-être un faute et il faudra bien un jour jouer à du comparatif de chaque possibilité pour au moins avoir une idée de l'impact. Dans la liste des choses à faire…
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par arnaudus . Évalué à 10.
Euh… C'est peut-être complètement naïf, mais par rapport à une compression non-spécialisée (style zip ou rar), quel gain d'efficacité peut-on espérer?
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Zenitram (site web personnel) . Évalué à 10.
La question est loin d'être idiote vu que certains font avec ça… Mais vraiment, non.
Exemple de bench (résumé : ZIP largement moins bien en compression et largement plus lent, LZMA mieux que ZIP mais toujours largement moins bien que FFV1 en compression et encore plus lent).
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par THE_ALF_ . Évalué à 5. Dernière modification le 25 août 2021 à 10:25.
Est-ce que cela pourrait être intéressant pour la compression de données scientifique ça?
Je pense notamment à la compression de donnée dans des formats de type hdf5. On peut se retrouver avec des gros blocs de données de dimension variable, et si ce n'est pas trop random ou bruité, on doit pouvoir se retrouver avec quelque chose de proche de données vidéos.
Ce type de compressions vidéo a-t-il été envisagé pour compresser des données (hdf5 fait du classique, de type gzip)? Serait-ce adapté (il faut pouvoir compresser, mais surtout décompresser rapidement, et pouvoir accéder rapidement à des données à un endroit particulier).
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Zenitram (site web personnel) . Évalué à 9. Dernière modification le 25 août 2021 à 13:40.
Sans test, impossible à dire. A première vue, tant que les données ont un lien spatial, ça devrait le faire. FFV1 se fout un peu du type de données fournies car se focalise sur les liens spatiaux.
Maintenant, il faut qu'une entité y trouve un intérêt pour s'engager à sponsoriser (oui, il ne faut pas se cacher le fait que pas mal de choses avancent quand il y a un financement) un peu si une étude préliminaire montrent que ces données sont plus compressibles avec FFV1 que l'actuel.
A noter que FFV1 et son écosystème a eu des financements car certains ont "bêtement" calculé que diviser la taille de stockage par 2 valait largement le coup par rapport au coût de développement des logiciels (on parle de Po de données).
Si une entité est intéressée, me contacter avec un jeu de données.
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par jyes . Évalué à 5.
Si je comprends bien ta prose, il est aisé d’encoder des données de n’importe quel type donc ça pourrait s’adapter à des données scientifiques pour compresser des données usuellement sauvées en HDF5. Il reste quelques points qui méritent d’être éclaircis pour ça (j’avoue ne pas avoir lu la spec) :
- existe-t-il des encodeurs/décodeurs qui peuvent travailler avec un nombre de bits quelconque (ou à défaut de vraiment quelconque qui peuvent manger du 64 bits par composante) ?
- est-il possible (voire facile) d’encoder/décoder des données qui ont (parfois beaucoup) plus que trois composantes ?
Ce sont les deux limites que j’anticipe pour convertir un format de stockage de vidéo en un format de stockage de données tabulées générique. Sinon, effectivement, l’idée soumise par THE_ALF_ pourrait avoir un gros potentiel.
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Zenitram (site web personnel) . Évalué à 10.
La spec est "illimitée" la dessus mais en pratique passé 10 bit c'est pas très optimisé au niveau du "prefect" (il se base sur un int de 32 bits divisé par 3 domaines donc 10 bits pratiques, à l'époque des débuts de FFV1 les machines 64 bits n'étaient pas partout) car… En pratique passé 10 bit d'un capteur, c'est pas mal du bruit random… On pourrait changer la chose si il y a un intérêt.
Pour le logiciel, les seuls connus s'arrêtent à 31 (RGB) ou 32 (YUV) bits mais pourraient se prendre un +32 facilement (pour mon logiciel c'est un typedef uint32_t qui passe en uint64_t) et si il faut il y a des libs pour du 128 bits ou pas. Pas implémenté mais ne fait pas peur à part sur l'espoir de compresser tant que ça du fait que la réalité montre des capteurs qui ne mesurent pas tant que ça.
A noter que (tient, un exemple sur le ouvert vs libre) j'ai un fork (pas accepté tel quel dans le standard) de FFV1 qui supporte des float à la place de int, car pour la vidéo du moins on considère que plutôt que d'avoir des int de 64 bits on fait des floats de 16 ou 32 bits (pas moi qui le dit, hein, demander à ILM qui a créé EXR et utilise pas mal les floats), la plage de précision suffit (on s'en fout un peu du nanomètre quand on mesure un truc dans le parsec).
Actuellement c'est max 4 (canal alpha).
Le standard limite à 4, mais la prochaine version pourrait avoir illimité. On est intéressés pour la v4, c'est surtout se mettre d'accord sur comment annoncer le nombre, rien de compliqué mais actuellement surtout un manque de motivation faute de sponsor intéressé.
Globalement, ce dont tu parles n'est pas la mais pas difficile à implémenter pour la v4 (ou en fork si refusé par le standard), on est clairement ouverts à ce type d'usage, si tu penses que ça peut valoir le coup pour une entité, faut qu'on parle ;-).
Globalement, l'algo est assez générique et peut s'adapter facilement, reste à trouver des cas d'usage qui rendent viable le dev.
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par jyes . Évalué à 5.
Merci pour toutes ces réponses !
Je suis sûr que ça vaut le coup, quant à valoir le coût, l’entité que je vois susceptible d’être la plus intéressée est la recherche publique et elle a bien peu de deniers à partager : tu risques d’être déçu par nos éventuelles discussions. Néanmoins, parler ne coûte rien et les chercheurs y passent leur temps :-)
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Zenitram (site web personnel) . Évalué à 9. Dernière modification le 25 août 2021 à 16:00.
Ha, ça je connais, il y en a des entités qui préfèrent payer 1 Million pour du stockage plutôt que 0.5 Million + 0.01 Million de dev :-p.
On se bât contre ce gâchis (pas pour les vendeurs de stockage, certes :) ), mais on sait bien que les lignes budgétaires sont différentes… Pour ça, on imagine faire une offre "boite noire" de stockage (et on optimise le stockage pour vendre moins cher). Mais ça reste un rêve pour le moment.
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
Je vois chez nous, on a des milliers d'image ou de film. Pour les traitements, on les transforme en fichier PNG (noir et blanc) 16 bits ou en fichier NetCDF.
Si on avait un seul fichier avec toutes ses images et une API simple pour aller taper dedans en accès direct (telle image…), ce serait réellement intéressant en science. Je pense qu'il y a plein de monde dans notre cas.
On fait parfois de la 3D avec deux ou trois caméras synchronisés. Le multi-flux vidéo pourrait (conditionnel) être intéressant aussi.
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Zenitram (site web personnel) . Évalué à 9.
Je ne vois pas ce qui manque dans un ZIP (non compressé du coup) pour répondre à ton besoin.
Si c'est un film, ben… On pourrait bien ajouter PNG à Matroska si il y avait un besoin, pour que ce soit lisible.
Et sinon, faire du transcodage de tes PNG en Matroska/MKV et c'est bon.
tu diviserais peut-être ton stockage par 4 (plus sérieusement, par expérience sur le 16-bit on ne gagnera quand même pas beaucoup, le 16-bit c'est quand même 4-6 bits de "random" avec les capteurs qui ne sont pas si performants, et le random se compresse mal).
Ce n'est pas en restant dans les suppositions qu'on avancera. Que ceux qui ont des milliers de fichier PNG me contacte si ils veulent réduire fortement leur stockage à peu de frais.
RAWcooked gère le multi-pistes vidéo à partir de différent répertoires contenant des TIFF ou DPX ou EXR (non compressé).
Le problème souvent est que les gens se plaignent mais ne vont pas plus loin. Et si on allait un peu plus loin si il y a un vrai besoin derrière et surtout une envie de changer? Le coût pour adapter (si besoin) est largement inférieur au coût gagné par stockage, le tout est une question de volonté de changer… Chiche? ;-)
C'est ce que font les archives pour lesquelles je travaille, on a adapté (leur engagement est de rendre les DPX à l'octet près? Et ben on stocke les headers DPX quelque part, na, et on compresse quand même, avec possibilité de revenir aux DPX à l'octet près quand besoin; fait car des gens ont voulu bouger en premier et maintenant d'autres suivent)
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Aris Adamantiadis (site web personnel) . Évalué à 8.
Je dois dire que l'intérêt scientifique m'a sauté aux yeux en lisant la dépêche. En astro amateur (et je suppose que les pros ont le même soucis), je suis confronté à l'enregistrement de vidéos de caméras haute vitesse en lossless pour pouvoir faire le traitement numérique derrière. Si on ne passe pas par de l'encodage (par ex h264), l'autre choix est de passer par du SER qui est une sorte de Bitmap extrêmement coûteux. Un algo comme FFV1 serait super efficace, vu que la plupart du temps ces vidéos sont juste des milliers de photos du même objet avec du bruit, des perturbations atmosphérique et du noir tout autour.
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par bayo . Évalué à 3.
Hors sujet, mais petite précision que le HDF5 supporte un ensemble non fini de filtres de compression https://support.hdfgroup.org/HDF5/doc/H5.user/Filters.html.
Je pense pas qu'on puisse résumer ça a du GZIP bête et méchant. On y trouve par exemple de la compression type image. Ou spécialisée pour les flottants.
C'est loin d’être parfait mais assez souple pour y ajouter ses propres filtres. Il ne me semble pas qu'il existe actuellement de filtres type vidéo, mais ça doit être relativement facile de faire rentrer du FFV1 ou ce qu'on veut.
Ensuite, en général c'est la manière dont on "chunk" le dataset qui va jouer sur la compression et/ou la vitesse d'accès a la donnée (selon le cas d'usage qu'on vise).
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par aerogus (site web personnel) . Évalué à 2.
Je me suis posé aussi cette question de l'efficacité des codecs audiovisuels par rapport à des compressions génériques. Le constat était sans appel, en faveur des codecs spécialisés, en tout cas mes tests du format audio flac. Un fichier wav linéaire gagnait péniblement 1% en zip/gzip alors que le flac gagnait près du tiers, sans perte bien sur.
Mon billet de blog: https://aerogus.net/posts/flac-format-audio-vraiment-sans-perte/
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Uther Lightbringer . Évalué à 5.
Si les brevets sont rédhibitoires, une comparaison avec l'AV1 pourrait être intéressante.
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Zenitram (site web personnel) . Évalué à 10.
A l'époque de mes tests AV1 n'existait pas (oui ça fait un moment que je n'ai pas fait de comparaison), et clairement il faudrait faire une petite comparaison de nos jours pour voir ce qu'il en est.
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Rappelons qu'il n'y a pas de brevet logiciel en Europe ;-)
Question : les brevets (américains) sur le H264 ne sont pas encore tombés ? La première version de la norme a été approuvée en mai 2003 (wikipédia), donc les brevets dessus doivent avoir au moins un an ou deux de plus ?
Certes, il y a une norme suivante en 2012. Mais bon, c'était principalement pour dire que les concepts de base doivent être dans le domaine public dès maintenant ou d'ici peu.
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par claudex . Évalué à 5.
Je pense que c'est le niveau de comparaison qu'il manque pour comprendre pourquoi un benchmark est inutile. Et la question, c'est pour l'archiviste avec de faible contrainte (genre quelque qui archive ses vidéos de vacance par exemple), qui se dit que la perte n'est pas forcément un problème mais quel serait le coût du sans perte.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Zenitram (site web personnel) . Évalué à 9.
En grande maille (fait à l’arrache de tête) :
- Compression comme à la TV : /200 à /100
- Compression comme au ciné : /10 à /8
- Compression "visuellement sans perte" : /5 à /4
- Compression sans perte : /3 à /2
Le sans perte a un coût, c'est un choix à faire suivant ses priorités. Je connais des archives qui font du "visuellement sans perte" et d'autres qui trouvent inacceptable de perdre le moindre bit, comme d'autres qui font du "TV" faute de thune pour le stockage.
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par lapineige (site web personnel) . Évalué à 3.
Effectivement, j'ai manqué de précision.
L'intérêt pour moi était effectivement de comparer entre du "visuellement sans perte" et du vrai sans perte, si c'était vraiment très différent ou non.
@Zenitram:
Merci des ordres de grandeurs, c'est suffisant pour se faire une idée :)
L'autre partie de ma question était sur les performances de décodage et encodages, j'ai ma réponse aussi, et donc ça n'a rien à voir ^
Une question de compréhension : si on compresse sans perte une vidéo déjà avec pertes, on va y perdre en stockage ? (comme quand on passe en FLAC un MP3, ce qui n'a du coup pas d'intérêt)
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Zenitram (site web personnel) . Évalué à 6.
La compression sans perte tentera tant bien que mal de garder les artefacts de la compression avec perte, en appliquant un algo prévues pour des données "naturelles" sur des données "artificielles" (destruction d'information pour optimiser la compression d'un certain compresseur), le meilleur moyen de gâcher de la place pour aucun gain. A ne jamais faire.
Mais… Comme il y a toujours une exception à la règle, en fait c'est parfois fait pour des raisons légitimes :-p.
La seule raison que je connaisse pour faire ça est quand on veut quitter un format proprio (genre on a qu'un binaire qui fonctionne sous WinXP i386) et qu'on doit choisir entre maintenir pour les mille prochaines années un machine virtuelle pour WinXP i386 (à long terme c'est un sacré challenge), faire de l’ingénierie inverse (faut de grosses compétences et c'est long), ou payer un peu plus de stockage.
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par claudex . Évalué à 3.
Sans aller dans un exemple aussi extrême. Est-ce que simplement se dire qu'on ne veut qu'un format d'archivage pour éviter les blagues quand on veut récupérer les données. Et donc, on transcode un format d'archivage avec perte vers un sans perte pour garder une cohérence.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Zenitram (site web personnel) . Évalué à 4.
Disons que prendre un truc comme h.264 bien établi et documenté, multiplier par 20 le coût de stockage par le passage à son format pivot unique, sans aucun gain de qualité ni de maintenance à long terme, je connais personne qui est allé jusqu'à cette extrême de choix.
Surtout en sachant que le format pivot unique ne sera pas unique quelques années plus tard car un autre format sera plus mieux bien.
Bref, je ne vois pas l'intérêt en pratique.
# Bravo
Posté par Philippe F (site web personnel) . Évalué à 10.
Bravo pour la persévérance, d'avoir continuer à pousser la normalisation sans financement (si j'ai bien saisi). Tout ça pour la gloire et le logiciel libre, chapeau!
[^] # Re: Bravo
Posté par Zenitram (site web personnel) . Évalué à 10.
Disons que c'est de l'investissement sur le long terme :).
En effet, on a eu des financements pour le début du projet, mais qui étaient limités dans le temps et le temps d'un financement limité dans le temps n'est pas vraiment compatible avec le temps de la standardisation. Néanmoins, on s'était gardé un petit budget dans ce financement pour ça, et surtout ce premier financement nous a ouvert des portes sur d'autres sponsors pour d'autres projets ayant besoin de FFV1 standardisé, donc on peut dire qu'il y a un peu de financement indirect, et de l'espoir sur de futurs projets sponsorisé (parce que les gens ont un peu marre de payer un rein pour avoir plus de perfs avec JPEG-2000… On compte bien prendre un peu de ce gâteau, et pour ça on avait besoin de normalisation pour dire que ce n'est pas un petit truc dans son coin).
# Et à quand un format cinéma libre? 😉
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Le JPEG2000 (ou les formats sans perte en règle général) n'est pas que pour l'archivage, mais aussi pour ces cas où on veut de la très haute qualité. Genre le cinéma (imaginez de vilains artefacts sur votre écran de cinéma géants). À l'heure actuelle, le format numérique cinéma (ce qui a remplacé les bobines de film donc) est le DCP.
Techniquement le DCP est un format super simple: la vidéo est en JPEG2000, l'audio en PCM (il peut y avoir plusieurs versions vidéo/audio dans le même DCP, typiquement pour le ratio d'écran du cinéma, flat ou scope, bien que c'est souvent fourni en DCPs séparés; il peut aussi y avoir des versions 3D, etc. De même pour l'audio, il peut y avoir plusieurs pistes), voire des fichiers additionnels, par exemple pour les sous-titres… et des fichiers XML qui organisent le tout (en gros les métadonnées qui disent quoi est quoi).
Bien sûr, les fichiers sont énormes et comme le dit Zenitram dans sa dépêche, faut pas s'attendre à pouvoir regarder un film en DCP sur sa machine de bureau. C'est techniquement possible, mais les fichiers sont simplement trop lourds, donc impossible de décompresser en temps réel 24 (ou pire 30) images par seconde. Les projecteurs de cinéma de nos jours sont des machines dédiées surpuissantes (et super-chères) avec (j'imagine) du décodage hardware. En gros, je dirais qu'un long métrage fait en moyenne 100 GiB, j'ai vu ça monter à 200 GiB pour des films 3D et descendre dans les 30GiB pour des dessins animés (j'ai travaillé un peu dans le milieu du transfert de DCP).
Alors ma question: à 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) et bien sûr de savoir si le matériel investi par les salles peut être mis à profit pour aussi lire du FFV1 en temps réel (le but n'est pas de renouveler le matériel alors qu'il a fallu ~10 ans à avoir toutes les salles de France équipées, avec tout un système de redistribution des frais appelé VPF pour aider financièrement les petites salles à se numériser). Mais ça serait tout de même intéressant, non?
Parce que personnellement, moi quand on me parle de JPEG2000, c'est au domaine du cinéma que je pense avant tout, puisque c'est l'un des rares bastions où ce format a réussi à se faire sa place (apparemment aussi dans l'archivage d'après la dépêche? Je savais pas pour ce cas). Et c'est sûr que c'est toujours plus intéressant d'avoir des formats libres.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Zenitram (site web personnel) . Évalué à 10.
Tu parles de Cinema, donc pas de Lossless (le DCP fait du JPEG-2000 Lossy), qui n'est pas du domaine de FFV1.
Il reste le JPEG 2000 utilisé en Lossless dans le cadre de la conservation long terme.
Ce n'est pas gagné pour leur faire changer d'avis, surtout que les gens ont les moyens donc la matos de décodage ne leur fait pas peur. 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.
Oui, changer qu'un truc à la fois.
Oui, ils ont soit du dédié soit des GPU avec du logiciel sur GPU. Comme mis dans la dépêche, on compte bien les titiller aussi la dessus.
PS HS: j'en profite pour voir des -1 sur des commentaires pendant ma lecture, amusant de voir des commentaires moinssé alors qu'ils répondent directement et seulement à la question sans une once de troll, on pourrait presque croire à une cabale :-D.
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 24 août 2021 à 22:17.
PS : Je n'ai que plussoyé ; faut croire que tout le monde ne fonctionne pas pseudo…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Tit . Évalué à 7. Dernière modification le 25 août 2021 à 09:54.
cabale : entente secrète de plusieurs personnes dirigé contre (qqn, qqch.)
un problème des cabales est que "plusieurs personnes" font que "secret" le reste rarement.
Cette cabale-ci est particulièrment ingénieuse et pernicieuse : elle n'est composée que d'une personne (il n'y a eu qu'un seul moins un sur chaque commentaire)… tremble Zenitram !
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Dr BG (site web personnel) . Évalué à 10.
Une autre possibilité est que la fan hardcore de Zenitram ne trouve le ton habituel des commentaires qu'il apprécie tant.
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Maclag . Évalué à 3.
Je note que tu t'es pris le -1 aussi.
La piste se resserre donc sur vos ennemis communs. Ou pas. Mais peut-être quand même.
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Prae . É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 Zenitram (site web personnel) . Évalué à 4.
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…
On ne souhaite pas diffuser de fichiers pour le moment du fait que :
- Les UL MXF qu'on a temporairement ne sont pas des versions définitives (maintenant qu'on a la spec diffusée on va avancer sur le sujet avec notre partenaire chez SMPTE)
- Le fichiers ne sont pas encore lisibles ailleurs que dans des POC de logiciels
- Je suis en retard sur l’implémentation même dans FFmpeg, il faut que je m'y remette, et je sais que je vais affronter du monde pas content (du libre dans du non libre, vade retro satanas).
Mais envoie moi un mail si ça t’intéresse, quand on se sentira prêt on partagera les fichiers.
Plus prosaïquement, quel intérêt verrais-tu à avoir ces fichiers illisibles partout actuellement? et question technique, peu d’intérêt, c'est juste remplacer JPEG 2000 par FFV1 dans le conteneur.
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Prae . É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 Zenitram (site web personnel) . Évalué à 3. Dernière modification le 01 septembre 2021 à 14:50.
Le ciné, en diffusion, utilise du MXF avec JPEG 2000 avec perte et n'a pas vraiment d’intérêt pour de sans perte, du moins à ma connaissance. Les archives utilisent MXF avec JPEG 2000 sans perte et surtout ont une culture de formats sans brevets (ou sans risque de brevet pour JPEG 2000) et de specs libres (voir mes autres commentaires sur l'ajout de "libre" à "ouvert") qui les rend plus sensibles à ce qu'on propose.
Tu serais déçu, il n'y a rien que des ULs qui vont bien pour dire que c'est du FFV1.
Le format est loin d'être inconnu, juste dispo dans AVI, MOV, MKV depuis 10+ ans, ce qui permet largement son étude et implémenter à qui le souhaite. Certes pas directement intégrable si l'outil ne gère que MXF comme conteneur…
FFV1 dans MXF est vraiment pour dire qu'on existe, on n'est pas à quelques mois près pour les implémentations car on sait que ça prendra des années (ou jamais). C'est une demande annexe à la standardisation et c'est encore tôt.
On m'a filé des MXF/FFV1 d'un logiciel proprio (eux sont prêt :-p, ils ont de clients qui poussent à tester pour la curiosité) mais avec de mauvaises ULs + pas le droit de diffuser, et pour FFmpeg, je suis à la bourre, je diffuserai le patch et les fichiers sur ffmpeg-devel quand ce sera prêt.
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par legranblon (site web personnel) . Évalué à 3.
Au vu de l'importance de ces ULs, je vois d'ici venir un fait récurrent et semble-t-il problématique : il manque UL dans un coin …
… désolé.
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Prae . É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.
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par claudex . Évalué à 7.
et
Ça me semble ouvert mais pas très libre.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Prae . É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 Zenitram (site web personnel) . Évalué à 10. Dernière modification le 28 août 2021 à 12:55.
Séparons : format ouvert et format libre
Format ouvert : Je te défie de me montrer un décodeur DCP basé uniquement sur les specs fournies dans ton lien.
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)
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.
DCP est à peine ouvert (le XML du DCP est ouvert, pas MXF ni JPEG 2000), est dire que DCP est libre même en pensant que aux XML est le plus éloigné de la vérité.
Donc sa phrase est bien plus proche de la vérité que la tienne.
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é.
Oui, donc suffit juste de ne pas décompresser, ce n'est pas un argument.
Alors oui les "layers" ont l'avantage que tu n'es pas obligé de tout décompresser pour avoir un truc visible, mais la réalité est que pour avoir du JPEG 2000 4K DCP en temps réel il faut une carte graphique et du code proprio dédié (à ma connaissance il n'existe pas de décompresseur JPEG 2000 GPU libre , je suis preneur de lien si c'est le cas).
Note : pas mieux pour FFV1 pour le moment, mais on y travaille, en pratique avec du code libre FFV1 est plus rapide à ma connaissance.
Non, j'ai interdiction de rediffuser 99% de la spec DCP. Oui, je sais, je prend les liens dans la spec DCP (SMPTE et ISO), mais bon parser du DCP "seul" me fournit… Absolument rien en contenu audiovisuel.
Non, j'ai interdiction de modifier 100% de la spec DCP, y compris 100% du texte que sur le XML du DCP.
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.
Ils sont toujours d’actualité, on n'y peut rien. Si tu veux parler de libre, il te faut :
- Convaincre DCP de changer la ligne sur "tu change un bit de la spec tu auras un procès au cul" en par exemple "CC-BY-SA".
- Convaincre ISO et SMPTE de libérer (libérer c'est pas que gratuit, c'est droit de modifier et rediffuser aussi) leurs specs citées par DCP.
Le cinéma numérique est 0% libre, c'est un fait. (pour le "caca" je te laisse juge du non libre, perso je ne crache pas sur le 0% libre, c'est juste pas libre).
Ce qui ne l’empêche pas d'être utilisable par des logiciels libres, mais ce n'est pas le sujet car l'auteur auquel tu réponds parle du format et non des outils.
Arrête d'être tendu sur le sujet, accepte le fait que le cinéma numérique n'est pas libre du tout. Ce n'est pas un mal, juste un fait. Si tu penses que le cinéma numérique est libre, tu n'as pas compris ce qu'est un format libre (non, le fait d'avoir des outils libre pour utiliser ne rend pas un format libre, ça n'a rien à voir).
J'ai déjà expliqué à Ysabeau la différence entre "format ouvert" (DCP l'est à peine car se base sur des formats non ouverts) et "format libre", je t'invite à lire mes réponses à ce sujet pour comprendre la différence.
Je ne me prononce pas sur le cinéma en soit, juste répondu factuellement à ton commentaire. Le cinéma est un autre monde, un autre budget, et se fout du lossless (c'est comme le "broadcast", ça va être diffusé puis jeté à la poubelle, des pertes de compression sont acceptables), FFV1 pourrait être utile ici que quand c'est du JPEG 2000 Lossless qui est utilisé (stockage chez les ayant droit) mais eux ont la thune et utilisent déjà JPEG 2000, ça ne sera pas notre cible à nous qui nous intéressons aux "sans beaucoup de thune".
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Prae . É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 Zenitram (site web personnel) . Évalué à 6. Dernière modification le 01 septembre 2021 à 13:56.
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…
Je veux changer une ligne, et rediffuser la version modifiée (on ne parle pas du nom, le droit des marques est autre chose).
Pas de chance, je n'ai pas le droit, cf le texte de la licence. et pourtant, c'est nécessaire pour un format libre.
Tu confonds les outils libre manipulant un format et le format. A ce niveau, on pourrait aussi dire que H.265 est libre (non, il ne l'est pas même si Ffmpeg libre le gère).
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.
Note : je rajouter une couche sur SMPTE-377: "However, attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. SMPTE shall not be held responsible for identifying any or all such patent rights." Ils ne se mouillent pas…
Est-ce que Dolby peut me refiler le spec DCP ou MXF modifiées? Non, car Dolby n'a pas ce droit, même en payant ses droits SMPTE.
Jamais vu Dolby diffuser des docs à l'origine de SMPTE. Quand ils sont chez ETSI (accès gratuit), c'est "the content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI" donc non libre.
On parle de formats, tu me parles de logiciels… Peut-être que tu penses aussi aux brevets, ce n'est pas le sujet.
C'est insultant. Je n'ai jamais parlé de gratuit, j'ai parlé de libre.
Libre = 4 libertés. Dont celle de modifier et rediffuser ses modifs. Interdit avec DCP ou MXF ou JPEG 2000. Si je devais payer pour avoir les specs DCP en libre, pourquoi pas, ça resterait libre. Mais DCP ne vend pas de version libre de sa spec, et en gratuit c'est non libre.
Ce n'est pas fait pour rien que de ne pas faire de spec libre, c'est un choix, mais c'est non libre.
A partir de cette erreur, en confondant du "Non modifiable" avec du libre, en confondant ce que tu peux faire avec des logiciel et la licence d'une spec, en confondant licence d'une spec et les brevets, toute ta réaction tombe, je t'invite à relire plus posément les commentaires, pour comprendre c'est qu'est le libre, en attendant je ne peux qu'ignorer tout le reste de tes réactions.
Demande-toi pourquoi les specs n'ont pas explicitement une licence libre si ça ne fait aucune différence en pratique.
Ca ne te plaît peut-être pas, mais DCP reste dans les faits 0% libre. Encore une fois, rien de mal, c'est un choix stratégique de ne pas faire de libre, mais perso je préfère des specs libres.
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Prae . É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 Zenitram (site web personnel) . Évalué à 4.
Parlons sémantique :
- https://en.wikipedia.org/wiki/Open_format tu peux voir que les anglophones acceptent que ce soit derrière un paywall ("an open format may require a fee to access").
- https://fr.wikipedia.org/wiki/Format_ouvert, qui se base sur la loi française ne l'acceptent pas ("spécifications techniques sont publiques et sans restriction d'accès").
DCP se base sur des "open formats" (anglophone) mais pas sur des "standard ouverts" (loi française).
La notion anglophone te plaît et t'amène à refuser de comprendre que d'autres peuvent préférer la notion française voire de specs qu'on peut modifier à la place de devoir tout ré-écrire.
Ce n'est pas mon égo, c'est juste le tient qui refuse d'accepter que d'autres trouvent des formats préférés sans assez de libertés, comme d'autres prennent pour de fous les amateurs de logiciels libre car le faire d'être gratuit suffit.
Je n'y peux rien, c'est la loi qui dit que c'est à toi de faire, pas moi (la loi est explicite : par défaut ce n'est pas libre, et seul une mention que c'est libre permet de dire que c'est libre).
Tu refuses de lire mes messages car sinon tu aurais déjà compris que le paywall ne change rien à la liberté ou pas, c'est hors sujet. C'est lassant et insultant.
A noter que le paywall empêche la dénomination "standard ouvert" suivant la loi française, le paywall change complètement l'acceptation de "standard ouvert" suivant la loi française (tous les formats SMPTE sont éliminés). Je n'y peux rien, c'est la loi française.
Note : en réalité, pas tout SMPTE… SMPTE RD 48 est un standard ouvert, en plus d'être libre (CC BY-SA 4.0), voulu par leurs auteurs (oui, je les connais, on a les mêmes idées sur la libertés des standards). Tu pourrais le récupérer derrière le paywall SMPTE que ça resterait libre.
Hors sujet, pour ne pas parler du sujet. Le libre n'impose pas de t’obéir.
Toujours pas, vu que ta liste n'est rien voir avec le libre, plutôt avec le gratuit d'implémentation. On ne parle pas du tout de la même chose.
Je ne te force pas. A la base Jehan et moi parlions de format libre, tu es arrivé avec tes grands sabots "mais DCP c'est libre" en parlant d'être tendu dessus, on te répond que ben non et on t'explique pourquoi, tu refuses de comprendre pourquoi, soit. Ça ne changera pas la réalité : DCP n'est pas libre, encore moins MXF (et cette affirmation n'est en rien incompatible avec ce qui te plaît, c'est à dire sans brevet à payer).
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Jean Roc Morreale . Évalué à 3.
Implémentation JPEG2000 avec accélération GPU (fork openjpeg 2) :
https://github.com/GrokImageCompression/grok
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Zenitram (site web personnel) . Évalué à 1.
Je ne trouve pas d'info sur la partie GPU, la partie compilation ne parle que de compilos pour CPU, et les gains par rapport à OpenJPEG semblent faibles (pas de l'ordre de grandeur d'un GPU, et OpenJPEG est super lent à la base) .
Ou vois-tu des perfs sur GPU?
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par claudex . Évalué à 2.
Il y a plusieurs include lié à cuda dans le code.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 01 septembre 2021 à 17:03.
C'est un peu frustrant des liens sans vraiment être sûr de ce qu'on avance, juste sur base de include…
Est-ce que "Grok Pro (my GPU-enabled version of Grok)" est toujours d'actualité? Gain en perf par rapport à version CPU?
Quelqu'un a-t-il testé ou vu fonctionner avant de répondre?
Perso je considère que ça n'existe toujours pas tant que quelqu'un ne montre pas un truc qui marche avec des benchs pour montrer que ce n'est pas juste pour le fun mais pas de gain (par exemple cuj2k est libre et support GPU mais leurs propres tests montrent que pas mieux que CPU, et d'autres tests montrent que c'est 10x moins performant qu'un autre compresseur en GPU).
Note : pour FFV1, on s'est concentré sur l'état de l'art en libre et avec les fonctionnalités souhaitées, notre prochaine étape est clairement de bencher FFV1 par rapport à JPEG 2000 et faire une version CUDA pour voir ce que ça vaut… On est en retard la dessus, je ne te contredirai pas si tu penses que je demande un truc que je ne fournis pas encore pour FFV1.
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Jehan (site web personnel, Mastodon) . Évalué à 7.
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.
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). 😉
Ensuite je supposais que ça utilisait du JPEG2000 sans perte. Zenitram m'a démenti en me disant que c'était en fait avec perte (ce que je n'avais jamais pensé à vérifier à l'époque où je travaillais avec des DCPs tous les jours. Mais je travaillais pas à lire le format même, juste à transférer des fichiers, donc j'ai des excuses! 😛). Donc a priori, si c'est compressé avec perte, j'imagine que si, on peut avoir des artefacts (donc en fait je me trompais), et ce, quel que soit le mode de compression. Un "artefact de compression", ça veut juste dire une déformation quelconque des données dûe à la compression avec perte. Il y en a forcément, par définition (s'il n'y en avait absolument aucune, ça veut dire qu'on arrive à obtenir exactement l'image originelle, donc ce serait du sans perte. CQFD). Ensuite les artefacts peuvent prendre diverses formes, et peut-être que les algorithmes wavelet font des artefacts moins horribles que d'autres. Mais ça reste des artefacts par définition.
Ceci-dit, les labos vont faire évidemment des compressions légères pour garder une haute qualité donc je suppose que cela assure une qualité suffisante (artefacts suffisamment légers pour ne pas être remarqués) pour ne pas avoir de mauvaises surprises.
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".
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 (genre je parle pas de quelques frame-drop par ci par là, mais vraiment absolument irregardable). Ensuite j'ai pas insisté.
Ceci dit ce que dit Zenitram reste très vrai: dire qu'il suffit de ne pas tout lire reste un peu une sorte de réponse à côté de la plaque sur le fait que si on veut lire le fichier dans la situation idéale, ce n'est à l'heure actuelle pas possible sur une machine de bureau (ce qui n'est pas une critique de JPEG2000 ou de DCP; travailler sur des fichiers de grande taille est tout simplement une problématique récurrente de quiconque travaille sur l'image, ce qui pour le coup est notre boulot principal; et justement ta proposition d'utiliser de plus faibles résolutions est le contournement habituel, dans les étapes de création/édition, on appelle cela des proxys en général).
Ça m'intéresse tout de même bien de connaître ton astuce de "layer de résolution" pour lire des DCPs sur des machines de bureau, ça a l'air très intéressant en contournement du problème! 🤗
Ce n'était pas du tout ma question. Je comprends tout à fait la volonté d'imposer un format unique. C'est comme lorsque XMPP avait été standardisé, UTF-8 fut imposé comme unique codage des caractères (alors que XML avait l'option pour accepter n'importe quel codage), parce que pourquoi vouloir créer des problèmes inutiles?
Ben là c'est pareil, je trouve cela tout à fait logique de choisir un format vidéo unique et de s'y tenir.
La problématique est donc juste: c'est dommage qu'ils aient choisi JPEG2000 comme format unique. Si on parle de proposer un autre format (que ce soit FFV1 ou un autre!), on parle pas d'accepter n'importe quel format, mais juste qu'un format libre, c'est quand même mieux.
Pour avoir travaillé exactement dans cette problématique de relation entre salles et distributeurs, ce n'est pas comme ça que ça fonctionne. S'il y a besoin de plusieurs versions, le labo aura simplement préparé plusieurs DCPs dès le début et enverra tout sans se prendre la tête. Voire il peut faire un unique DCP avec plusieurs CPLs ("Composition Playlists", en gros les métadata qui listent les fichiers à utiliser pour chaque version) mais dans les faits, beaucoup de labos aiment bien juste faire des DCPs séparés (je pense qu'ils se disent que c'est plus simple car certaines salles ne voient qu'un seul DCP et pensent qu'il n'y a pas la version qu'ils souhaitent alors qu'il y a simplement plusieurs versions dans le même DCP; bon et dans le cas théorique cité de multi-format, si c'est la vidéo qui change, ce serait de toutes façons mieux d'avoir 2 DCPs de taille raisonnable qu'un seul énorme, dans le cas où la salle télécharge plutôt que de recevoir un disque dur).
Le labo ne contacte pas les salles au cas par cas (enfin pour la clé si, mais pas pour leur demander des détails sur leur infrastructure!), il envoie tout (que ce soit directement avec un disque dur par la poste, ou bien par des services de transfert intermédiaire) et se fait pas chier.
Pour le reste, je suis totalement d'accord. Mais comme j'ai dit, c'était pas mon propos. 😛
Je sais pas ce que tu appelles "le sens classique", faudrait expliquer. Parce que des petites salles qui ont eu des VPFs (dans un sens pas classique alors?), y en a eu. 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. 🙂
Ensuite c'était pas du tout mon rayon, donc tu sais peut-être des choses que je connais pas (le fameux "sens classique"; peut-être que nos salles n'étaient pas si petites?) et si tu le dis, ok (surtout que j'ai jamais dit le contraire non plus). Mais bon, le sens de ma phrase, c'était vraiment juste que ça a coûté très cher et que ça a mis du temps pour numériser les salles, c'est tout. Et que donc le matériel doit être préservé. Je suppose que tu trouves pas à redire à cela?
En dehors de ce point, je suis pas expert en VPF et ça m'intéresse pas plus que cela.
Je sais pas pourquoi tu t'acharnes sur le DCP. Comme dit plus haut, j'en ai pas parlé… enfin si, pour illustrer le sujet principal juste, et justement en disant moi aussi:
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. 😛
Sincèrement je vois pas où tu lis que j'ai dit ça. Quelqu'un annonce un format concurrent du JPEG2000. Ça me fait penser au cinéma (car c'est le seul endroit où j'avais vu du JPEG2000), donc je fais la remarque et pose des questions pour en savoir plus. Je trouve juste que c'est une discussion/un sujet intéressant.
Nulle part je ne pose de débat sur le cinéma numérique. D'ailleurs je me demande bien de quels arguments tu parles. Comme je n'ai pas posé de tel débat, il n'y avait pas d'arguments non plus.
Si tu parles du fait que j'ai dit que le JPEG2000 n'est pas libre, ben c'est juste un fait. Les specs ne sont pas publiques, les obtenir coûte cher, il y a des brevets et d'après Wikipedia, les organisations participatrices ont accepté de ne pas les faire jouer, mais uniquement pour la première partie "core coding system", sur un total de 16 parties du standard. Sans compter les brevets sous-marins possibles par des organismes tiers.
Ce n'était pas cependant un jugement de valeur, juste un fait. Mon but n'était pas de rentrer dans une discussion sur JPEG2000 (ou DCP) vs. le reste du monde. Je posais juste une question sur FFV1 dans le contexte du cinéma car je trouvais l'article intéressant.
Désolé donc si ça t'a énervé, ce n'était pas le but. Je suis juste là pour parler de FFV1 pas de JPEG2000. C'était histoire d'avoir une discussion intéressante, du papotage de techos sur un forum quoi (et j'ai même appris des trucs en un seul échange, donc ce fut positif!). Hors ceci, je ne crois pas que le format vidéo de référence changera (mais j'adorerais être détrompé: Zenitram, on compte sur toi! 😉), et je ne fais pas à ce jour de démarche ou de lobbying en ce sens. C'était juste histoire de bavarder. Je m'attendais pas à me faire sauter dessus pour oser discuter du sujet. Néanmoins je t'en veux pas. On voit que tu es à fond dans ton sujet, même si on n'est pas d'accord sur l'avantage des formats libres:
Oui pour moi dans tous les cas: en règle général notamment, ce qui inclut bien le cinéma (et tous les domaines d'ailleurs). Mais j'en fais pas une maladie. Pas de problème. Heureux d'avoir pu échanger sur le sujet tout de même. 🙂
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 29 août 2021 à 07:34.
Il me semble qu'un artefact est une distorsion visible et qu'il est tout à fait possible de faire une compression avec perte sans artefacts. Il suffit juste que les pertes (donc les distorsions) ne soient pas visibles. Évidemment ça dépend de la finalité du fichier, mais si c'est pour être observé par des humains le fait de retirer tout un spectre que l'on ne peut appréhender ou de simplifier des couleurs qu'on ne peux pas distinguer entre elles (bien sur c'est plus complexe que les dégradés) permet de détruire des données sans pour autant créer d'artefacts.
C'est grâce à ça que la sténographie existe. On modifie un fichier sans ajouter d'artefacts.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Jehan (site web personnel, Mastodon) . Évalué à 9.
Oui bien entendu. Et cela se détermine par le niveau de compression. C'est cela qui va permettre un faible taux d'artefacts, ou alors des artefacts plus subtils (en comprimant peu tout simplement).
Si tu le comprimes à peine, oui. C'est là qu'on va parler de "visuellement sans perte". Attention, par définition, "visuellement sans perte", il y a quand même eu de la perte, donc en fait il y a des artefacts mais qui ont été jugés si subtils qu'on va supposer que personne ne peut les remarquer (ce qui, même là, ne veut pas dire que ce n'est pas gênant pour certains. Je viens de trouver ce papier qui semble étudier les artefacts du JPEG et du JPEG2000 — chapitre 3 pour ce dernier — dans le cadre d'images satellite de haute qualité où ces artefacts sont problématiques, même lorsque les artefacts sont à peine visibles à l'œil car on comprime peu!).
Mais hormis cela (qui s'applique à tout algorithme de compression), bien sûr que n'importe quel algorithme avec perte peut avoir des artefacts. C'est juste logique: si quelqu'un arrive à comprimer avec perte toute image en divisant la taille par 100 et n'a absolument aucune distorsion tout en gardant une qualité où on ne distingue pas de l'original, je sais pas moi, faut lui donner un prix Nobel!
C'est simple: tu retires très peu de données, tu t'en sors à bon compte et personne ne remarque rien (mais tu changes peu la taille du fichier); tu retires beaucoup (et obtiens un petit fichier), bien sûr qu'on le remarquera! Quel que soit l'algorithme!
Là dans le cas qui nous intéresse, c'est sûr que si on compares du JPEG2000 pour du cinéma (avec perte mais une compression limitée pour garder une bonne qualité) et une image quelconque en JPEG faite pour le web comprimée à fond les ballons pour optimiser la bande passante et gagner des points sur l'algorithme de Google (qui privilégie les petites images apparemment), bien sûr tu vas te dire "regarde le JPEG2000, y a pas d'artefacts", mais là on a surtout comparé des cas d'usage différents, plus que des formats.
Enfin bon, c'est juste du bon sens. Pourquoi on se ferait encore chier avec des algos sans perte si on avait trouvé l'algo magique avec perte qui permet de compresser autant qu'on veut, en jetant toutes les données qu'on veut tout en n'ayant aucune "distorsion visible"!
Je n'ai pas étudié le format JPEG2000 en particulier, de toutes façons, je n'ai pas accès à la spec. Mais si ça marche en "wavelet" dans le sens où je connais dans l'imagerie numérique traditionnelle, alors je m'imagine qu'un des principaux types d'artefact sera déjà de rendre l'image plus flou. Mais en fait y a plus de types d'artefacts.
En effet plutôt que de faire des suppositions, faisons une simple recherche "wavelet decompression artifact". Parmi les premiers résultats, je trouve ça: http://www.stat.columbia.edu/~jakulin/jpeg/artifacts.htm
Allez quelques exemples d'artefacts, comparant JPEG2000, original et JPEG:
Etc. Si on me dit que les distorsions sont pas "visibles", alors je sais pas ce qui peut l'être! 🤣 Je propose de cliquer sur le lien qui donne d'autres exemples (ceux-ci sont déjà des copies d'écran de cet article).
Si c'était si facile que des "il suffit" (gras de moi dans ta citation) ou que de dire "simplifions les couleurs qu'on ne distingue pas"… on se demande pourquoi on fait encore de la recherche sur le sujet! 😛
Enfin bon, sans rancune, mais là tu es en train de parler de magie, pas de réalité. 😉
On attend ton algorithme de compression avec perte qui ne rajoute jamais d'artefacts! 😛
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Prae . É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 Jehan (site web personnel, Mastodon) . Évalué à 8. Dernière modification le 01 septembre 2021 à 16:47.
C'est sûrement de mon message que tu parles, si tu parles du message sur le fonctionnement des clés. Ensuite je n'ai pas travaillé précisément et techniquement sur ce sujet (je m'y suis juste intéressé, ai posé des questions et ai lu parce que je travaillais avec des DCPs, donc je voulais savoir comment fonctionnaient les clés bien entendu car je me demandais moi aussi à l'époque comment le problème des copies illicites avait pu être géré), donc je suis certain qu'il y a des imprécisions, voire des erreurs (et serais heureux d'avoir les corrections si tel est le cas). Mais je suis à peu près sûr que l'idée conceptuelle de base est juste (une unique clé pour déchiffrer le contenu du DCP, elle-même chiffrée spécifiquement pour la machine de l'exploitant). Quand j'ai écrit mon message, je l'ai d'ailleurs pas fait entièrement de tête, j'ai aussi fait quelques recherches web (comme je le fais souvent pour pas non plus dire trop de trucs faux, même si cela reste juste une discussion informelle donc je me permets les approximations) pour valider mes souvenirs et toutes les docs et articles que j'ai trouvé confirmaient cette logique pour expliquer les KDM.
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! 😛
Ou alors tu parlais du commentaire de quelqu'un d'autre, mais il me semble que c'était le seul qui aborde un sujet un peu cryptographique.
Ok. Perso j'ai pas plus d'avis que ça sur le format idéal techniquement et j'ai aucune bille nulle part. Je pose juste des questions par intérêt et pour suivre l'évolution des formats (et les possibles futurs changements de standard qui pourraient survenir… ou non!). On va dire qu'en tant que dév de GIMP, c'est normal de se tenir un peu informé sur les formats d'image (et de préférer les formats libres si possible!). 🙂
Pas de prob. Ça arrive. Je suis content qu'on retombe sur une discussion plus saine et agréable. 👍
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Prae . É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 cg . Évalué à 2.
(Je suis pas un spécialiste, je vais peut-être écrire une imbécilité.)
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.
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Zenitram (site web personnel) . Évalué à 5.
Il y a une différence entre ce qu'on veut et ce qu'on peut. En l’occurrence, le DRM est part par design, ce qui n’empêche aucunement de faire le reste en libre. Voir Firefox, qui gère les DRM (ça fait hurler les intégristes du libre qui ne veulent pas comprendre qu'il vaut mieux lâcher sur un truc que mourir complètement faute d'utilité pour les gens) mais fait tout le reste en libre (le DRM pas libre n'est pas une excuse pour ne pas permettre un Firefox sans DRM d'être 100% libre).
C'est une question de volonté, la volonté pour DCP est de ne surtout pas faire de libre (la spec est explicite : pas touche à l'ensemble de la spec, pas que ce qu'on ne peut pas faire autrement).
C'est un choix qui se défend (volonté de ne pas avoir de dérivés, comme la FSF fait pour le texte de la licence GPL, la GPL est une licence libre mais elle-même, son texte, n'est pas du tout libre), mais ce choix a la conséquence que ce n'est pas libre (rien de mal en soit, juste que d'autres souhaitent du libre et peuvent décider de faire un concurrent libre au moins sur tout sauf DRM).
A noter que pour FFV le fait que ce soit libre est bien, mais il y a aussi le fait qu'on peut ajouter des supports de fonctionnalité assez facilement (bon, il faut parfois faire plus qu'un petit PR et montrer que ça vaut le coup, je me casse les dents dessus en ce moment, mais je sais que j'y arriverai plus facilement qu'avec JPEG 2000).
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Je vais répondre, de mémoire.
Oui. En fait, plus que le type de matériel, c'est même précisément la machine exacte de la salle qui est ciblée par la clé. C'est possible car les projecteurs ont des clés publique/privée uniques au niveau du hardware même.
Un DCP chiffré l'est en fait avec une unique clé (c'est donc un chiffrement symétrique). C'est cette même clé qui est utilisée par toutes les salles. Pourquoi pas avec la clé publique du projecteur (puisque je viens d'expliquer que chaque machine de projection en a une)? Parce qu'imaginez l'horreur et le travail additionnel/temps perdu/coût (je rappelle qu'on parle de films qui font des dizaines ou centaines de GiB, c'est pas un petit fichier qu'on chiffre en 2 secondes) si on devait re-chiffrer le même film pour chaque salle qui l'ajoute dans son planning. Donc on le chiffre une seule fois.
L'idée des clés envoyées est de faire un double chiffrement: on n'envoie pas la clé finale mais on la chiffre elle-même avec la clé publique du projecteur (là c'est rapide, c'est un petit fichier). Donc quand on donne cette clé doublement chiffrée au projecteur, il peut la déchiffrer avec sa propre clé privée, récupérer la clé du DCP, et finalement déchiffrer le film lui-même avec cette clé. C'est donc un double chiffrement symétrique (film lui-même) et asymétrique (la clé symétrique avec la clé publique unique de la machine).
Je suppose que le risque principal est si on arrivait à s'emparer de la clé symétrique (qui permettrait de relire le DCP à loisir, sans aucune limitation de temps ou de machine), et cela est sûrement limité en faisant toute cette étape au niveau hardware, comme une boîte noire, de sorte que la clé symétrique n'est jamais visible au niveau logiciel sur les machines contrôlées par les projectionnistes (les ordinateurs de la salle de projection). De même la clé privée d'un projecteur n'est pas accessible par quiconque (ça reste un secret de la boîte noire). Je pense que ça se fait avec des certifications de machine, de sorte que les distributeurs ne créent pas de clés pour n'importe quelle clé publique, mais uniquement pour celles qui font partie de listes de machines certifiés pour protéger le secret du déchiffrement et de la clé privée. C'est à dire que je peux pas juste donner une clé publique que j'ai créée moi-même (donc j'ai aussi la clé privée) et leur demander de m'envoyer un KDM (le nom de la clé chiffrée pour ma propre clé hardware) pour ensuite récupérer la clé symétrique. Un distributeur/labo doit d'abord vérifier que c'est une clé de confiance dans une liste.
Notons que je n'ai pas travaillé sur ce sujet précis, donc il est possible qu'il y ait de petites erreurs ou imprécisions dans mon explication technique. J'ai juste travaillé à la problématique du transfert de DCP pas des clés. Néanmoins malgré de possibles petites erreurs, ce devrait être globalement le fonctionnement de ces fameux KDMs et leur modèle de sécurité tel que je l'ai compris.
Tel que je le vois, tout repose au final sur cette boîte noire à l'intérieur du matériel de projection, qui promet aucune fuite de la clé déchiffré du KDM ni de la clé privée du hardware. Si l'une de ces 2 promesses est rompue, alors on peut déchiffrer à loisir un film à partir du KDM obtenu légalement, puis faire des copies non-chiffrées, etc. C'est le maillon faible. Mais comme ça dépend de gens dont c'est le métier (des salles de cinémas) sur du matériel qui coûte une fortune, peu probablement prendrait des risques à se faire blacklister par les distributeurs. C'est pas du matériel que des particuliers ont (et même si c'était le cas, un distributeur n'enverrait pas un KDM pour ce matériel à un particulier). Donc c'est aussi basé sur la confiance.
C'est pour cela que ça marche plutôt bien. Une telle logique ne pourrait pas marcher aussi bien pour une diffusion grand publique (même avec des lecteurs hardware certifiés, il y aura toujours des petits malins pour les démonter, en se fichant des garanties, et arriver à lire les infos directement sur la partie boîte noire du hardware, permettant ainsi d'obtenir les clés de tous les films achetés). Mais dans le petit monde du cinéma, ça m'a l'air d'une logique relativement sûre (en comparant risques et gains).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par cg . Évalué à 1.
Merci a vous deux !
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Prae . É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 cg . Évalué à 4.
Merci pour tous ces détails ! Je tente de résumer les trois réponses :
les contenus et containers en eux-mêmes pourraient parfaitement utiliser des formats libres ou normalisés.
La partie chiffrement est tout à fait classique, et le bridage par date et autres fonctionnalités rigolotes ne se font que parce que le projecteur le veut bien (bridage logiciel), autrement dit parce que c'est un écosystème fermé.
cet écosystème est robuste en raison du prix et des modalités d'accès au matériel d'une part, de la difficulté d'obtenir un fichier DCP, et de la facilité de griller/exclure une clé compromise (et donc le projecteur associé).
# Bortz \o/
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 7.
Stéphane en parle et cite même l'incubateur d'excellence comme référence : https://www.bortzmeyer.org/9043.html
# Imprécision de langage
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 25 août 2021 à 13:53.
En fait, il ne s'agit pas d'un format libre (ce qui ne veut pas dire grand chose pour tout dire en l'espèce et encore moins au regard des fameuses quatre libertés) mais d'un format ouvert. Notion qui est très précisément définie notamment dans le droit européen et donc, par contrecoup (ou forcément), dans le droit français et celui des États-membre.
Parce que, justement, ce qui caractérise un standard ou format ouvert, c'est qu'on ne le modifie pas comme on veut chacun dans son coin. Sinon, ça n'aurait pas d'intérêt.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Imprécision de langage
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 25 août 2021 à 14:04.
On est donc d'accord : tu confirmes bien que FFV1 est un format libre.
Car l'idée est bien que tu es libre (4 libertés) de forker et modifier si ça te chante, et que tu garde un format commun que parce que tu le veux et pas parce que la licence dit "gratos mais on te fais un procès si tu forkes".
En bonus c'est un format ouvert, mais les droits dessus vont bien plus loin que ça.
On le modifie bien comme on veut chacun dans son coin si on en a envie, et contrairement à ton préjugé ça a un intérêt (per ex si les autres ne veulent pas dans la spec "upstream") et c'est pour ça qu'on l'aime.
[^] # Re: Imprécision de langage
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 25 août 2021 à 14:20.
Non on n'est pas d'accord, c'est un standard, si on le modifie, ce n'est plus un standard et ça perd tout son intérêt. C'est comme si chacun dans son coin allait modifier le système international parce que comme ça ça rend mieux. Si on suit votre raisonnement, cela voudrait qu'on aurait des mètres de tailles différentes quasiment au gré de son humeur.
Comment peut-on garder toute espèce d'interopérabilité si on modifie un standard dans son coin parce qu'on en a envie ? Au contraire, plus on le respecte mieux c'est. D'ailleurs, si on le modifie, ce n'est plus un standard, c'est, je sais pas quoi.
Bref, en l'espèce le mot libre ne s'applique pas, pas plus que les licences libres. C'est même carrément au-dessus en fait puisque, si on veut garder l'interopérabilité, on doit suivre les préconisations du format et donc le logiciel, libre ou pas, doit s'assujettir à la norme. Un logiciel libre qui ne suivrait pas un format ouvert ne vaudrait pas beaucoup plus qu'un logiciel privateur et moins qu'un logiciel privateur qui respecte scrupuleusement un format ouvert.
Alors que dans la licence on est dans le pur domaine contractuel (donc de gré à gré), dans la notion de format ouvert, on passe à la dimension supérieure qui est celle de la législation (donc plus universelle) et avec une sécurité juridique bien plus forte.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Imprécision de langage
Posté par barmic 🦦 . Évalué à 4.
Tu entends quoi par modifier ? Je peux créer un format qui s'appuie sur ce standard. Ça ne modifie pas pour autant le standard et ça peut casser l’interopérabilité, mais tout le monde n'en a pas besoin ou alors ça permet d'expérimenter autour du standard.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Imprécision de langage
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 25 août 2021 à 14:33.
Relis tranquillement ma réponse car tu manques complètement le sujet.
FFV1 est un standard ouvert (ce dont tu parles) et tu parles du standard FFV1 quand tu veux de l'interopérabilité.
FFV1 est un standard libre (c'est en plus, plus de droits) et tu peux le modifier si tu as envie pour tes besoins sans qu'on t’embête à coup de procès. Ça ne sera plus interopérable, oui, mais ça n’empêche pas d'être libre et tu peux forker/modifier/diffuser tes modifs, vraiment. Prend la spec, modifie la, diffuse tes modifs de spec, fait-toi plaisir. Des standards disent "ouais, c'est gratuit si tu fais comme on veut, tu modifies un caractère de la spec et tu auras un procès au cul", pas nous. On râlera juste si tu l'appelles FFV1 sans prévenir que ce n'est pas la spec IETF.
La spec est vraiment libre et non juste ouverte, tu as bien les 4 libertés, ça ne te plait peut-être pas car tu voudrais interdire des modifs "pour le bien commun" (à débattre…), mais ce n'est pas notre façon de faire : tu ne forkes pas parce que tu souhaites être dans le groupe pour l'interopérabilité, pas parce qu'on te force la main à être avec nous.
Mais ce sujet n'est pas nouveau, et dans le logiciel c'est dans le style bataille copyleft vs copyfree, ou Firefox avec le nom Firefox ou Iceweasel car modifié (mais Firefox reste libre), etc.
[^] # Re: Imprécision de langage
Posté par Renault (site web personnel) . Évalué à 10.
La version modifiée ne sera plus un standard normalisé, mais il peut devenir un standard de fait ou être rétrocompatible avec le standard qu'il a modifié.
Bah, non.
Exemple con, je suis un éditeur de logiciel industriel pour envoyer une caméra sur Mars. Mais le protocole pour échanger des images avec la Terre est pas mal, mais avec les contraintes spatiales on voudrait bien modifier quelques aspects pour réduire la vitesse de transfert ou fiabiliser la transmission. Modifier le standard permet d'éviter de réinventer toute la roue tout en étant capable d'apporter des changements que le standard normalisé n'acceptera pas.
Cela peut paraître bizarre, mais en vrai en informatique c'est assez courant. Prenons le langage C par exemple, c'est un standard normalisé (en plusieurs versions). Mais de nombreux logiciels utilisent des ajouts fournis par GCC ou CLang. Pourquoi ? Car cela simplifie l'écriture de logiciels, ou permet des choses que le standard ne permet pas de manière stricto sensu, etc. Le noyau Linux ne compile qu'avec GCC de manière globale à ce jour (le support de CLang est incomplet pour l'ensemble des plateformes). Et personne ne remet en cause ces spécificités, car elles sont considérées comme essentielles.
Cela peut aussi permettre de faire facilement des expériences autour du standard pour éventuellement l'améliorer après.
Bref, ça a un intérêt qu'un standard soit libre.
[^] # Re: Imprécision de langage
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Ce qu'elle dit c'est justement que si le noyau Linux était écrit en C normalisé, n'importe quel compilateur respectant ce standard ferait l'affaire. Là c'est écrit pour GCC, tout comme les gens de petit mou écrivent pour leur compilo maison. Dans les deux cas on perd l'interopérabilité que permet la norme.
Ceci dit je suis d'accord qu'on peut être ouvert (par une normalisation) et pourtant pas libre, et que les deux notions sont orthogonales (c'est ça qui ne paraît pas évident pour tout le monde.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Imprécision de langage
Posté par barmic 🦦 . Évalué à 10.
Aller titiller Z en lui disant « ton truc il est pas libre », joli exercice.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Imprécision de langage
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 3.
J’ai pas dit « il n’est pas libre », j’ai écrit que le terme adéquat et défini dans les dispositifs législatifs est « ouvert ». Pas pareil. Du fait de la définition de ce qu’est un standard ouvert, c’est une norme qui doit être librement accessible, mais sûrement pas un truc modifiable à merci par n’importe qui.
En l’espèce, soit dit en passant, cela donne au format ouvert une force supérieure à celle du logiciel libre. Mais bon.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Imprécision de langage
Posté par barmic 🦦 . Évalué à 2.
À pardon j'avais mal lu :)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Imprécision de langage
Posté par Zenitram (site web personnel) . Évalué à 8. Dernière modification le 25 août 2021 à 15:45.
L'un n'empêche pas l'autre.
FFV1 est libre ET ouvert.
Le titre dit bien la chose : c'est libre, et une version de FFV1 est normalisée et donc en format ouvert.
Tu opposes 2 choses orthogonales, on peut être libre et jamais normalisé, comme être non libre et normalisé ouvert, nous on propose libre et normalisé ouvert.
C'est ta vision des choses, mais absolument pas la mienne. Cette phrase n'est pas du tout universelle, elle dépend pas mal des gens, 2 stratégies, que le meilleur gagne.
Mais j'avoue être surpris d'avoir une préférence pour le logiciel non libre ici (car cette phrase peut s'appliquer au logiciel, où on interdirait des versions non upstream "pour le bien du projet", il faut proposer upstream et fork interdit, on a déjà vu des projets logiciel avoir ce genre de philosophie plus dans le style "ND" avec patch accepté, en sachant que c'est incompatible avec le libre).
A noter qu'à ma connaissance il y a très peu de fork de FFV1 (2 petits en incluant le mien, et j'espère ramener ces 2 forks à la maison avec le standard ouvert FFV1 version 4).
[^] # Re: Imprécision de langage
Posté par barmic 🦦 . Évalué à 4.
C'est pas comme si c'était le cas d'OpenDocument…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Pourquoi
Posté par barmic 🦦 . Évalué à 5.
Non mois c'est l'inverse je me demande comment ce format a pu rencontrer le succès sans normalisation.
Il sert à l'archivage de longue durée j'imagine (si non je ne vois pas pourquoi ré-encoder autant garder le format d'origine) et ça n'a d'intérêt que si ton nouveau format a une meilleure pérennité que le format d'origine. Et je vois pas ce qui pouvait convaincre qu'un format plutôt récent et avec un usage disons limité était plus pérenne que h264 par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pourquoi
Posté par Zenitram (site web personnel) . Évalué à 9.
Pas idiot :).
Parce que comme c'est Lossless, ça n'empêche pas de passer à autre chose si besoin (rappelons que les LTO doivent être relue et passée sur une autre LTO tous les 15-20 ans, donc on peut profiter pour changer de format au passage sans grand surcoût), et on met le code source de FFmpeg dans le stockage. La garantie FFmpeg suffisait à certains (usage en avance) et pas à d'autres (donc on normalise), et c'est aussi l’œuf et la poule, il fallait bien un pour commencer. Les premiers étaient bien conscients qu'il fallait réduire le risque même minimal et ont donc participé à la normalisation.
Ha oui, et aussi parce que les vendeurs JPEG 2000 te font vendre un rein pour que tu puisses avoir pareil, et que les premiers utilisateurs de FFV1 préféraient le "risque" FFmpeg (stadard de facto quand même) à vendre leur rein. (en pratique ils pouvaient stocker 2x plus de contenu, ça leur donnait envie avec un risque minimal quand même).
[^] # Re: Pourquoi
Posté par barmic 🦦 . Évalué à 4.
C'est quoi une LTO ?
Et je comprend pour le reste.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pourquoi
Posté par Zenitram (site web personnel) . Évalué à 10.
Du stockage lent mais pas cher :-p.
Linear Tape-Open.
Pour donner une idée de gain de coût et les inconvénients, tu peux comparer Amazon S3 et Amazon Glacier.
[^] # Re: Pourquoi
Posté par claudex . Évalué à 6.
Pour compresser. Les sources existantes peuvent être dans un format numérique non (ou très faiblement) compressé (voir l'exemple cité plus haut de Po de données). Voire dans un format analogique.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Le poids du sans-perte.
Posté par Thomas Debesse (site web personnel) . Évalué à 7.
Cette normalisation est une bonne nouvelle, et avoir ce format est aussi une bonne chose pour commencer.
Après il est vrai que ça dépend des moyens. Les services d’archives avec lesquels j’ai l’habitude de travailler n’ont pas toujours de gros moyens et une compression avec perte traditionnelle apparaît alors comme infiniment meilleure que de ne pas numériser les supports originaux du tout. =)
D’autant plus que parfois les artefacts des usuelles compressions vidéo avec pertes semblent ridicules à côté des défauts des supports et formats originaux. Alors oui, ajouter des artefacts à des artefacts n’est jamais bon, mais dans certains cas ce qui piquera les yeux seront les imperfections des formats originaux quoiqu’il arrive.
Par contre c’est un point de vue spécifique à la question de la numérisation, celui qui veut archiver une vidéo produite numériquement n’opérera qu’une conversion d’un format sans perte vers un autre format sans perte (en supposant qu’il possède donc déjà un environnement de production dimensionné pour ça) ou conservera le format avec perte original (en supposant qu’il ne soit pas trop exotique).
Le sans-perte en image et en son est déjà parfaitement utilisable et je ne vois pas d’excuse pour ne pas faire du sans-perte, mais en vidéo le sans-perte a encore un coût non-négligeable.
Par contre en parlant de sans perte intra-frame, j’imagine que ça rend possible la déduplication au niveau bloc dans l’éventualité où plusieurs fichiers possèdent des parties communes. Prenons par exemple une série télévisée, tous les épisodes incluent des parties similaires (générique et autre écran titre, notamment). Bon je ne vois pas trop ça s’appliquer à de la sauvegarde sur bande, et ne serait-ce que pour de l’archivage il faut être prudent avec la déduplication (puisqu’en corrompant une fois la donnée dédupliquée on affecte tous les fichiers associés, prévoir donc une redondance), mais pour un environnement de production ou de consultation/diffusion travaillant en sans-perte, la compression intra-frame peut se révéler intéressante.
Les systèmes de fichiers btrfs (avec un outil de déduplication offline) et outils de sauvegarde comme borg peuvent économiser de la place quand plusieurs fichiers ont des parties identiques : pour reprendre l’exemple d’une série télévisée, quand le monteur aura produit l’épisode 2 et que la tâche de sauvegarde parcourra le dossier des prêt-à-diffuser de la série, quand borg lira l’épisode 2 il reconnaîtra que toutes les blocs appartenant aux frames du générique sont déjà connues (car sauvegardées avec l’épisode 1) et ne s’occupera que de ce qui est alors inconnu. Idem quand une mini-série est transformée en long métrage avec seulement comme frames inconnues quelques transitions entre ce qui était des épisodes séparés, ou quelques scènes originales ou plans originaux ajoutés pour améliorer la cohérence du tout a posteriori, dans ce cas l’interframe peut se révéler avantageux.
Existe-t-il un format d’image fixe pouvant embarquer une frame de FFV1 sans modification, de manière à ce qu’une frame extraite puisse être dédupliquées avec la frame du flux vidéo au niveau système de fichier ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Le poids du sans-perte.
Posté par Zenitram (site web personnel) . Évalué à 8.
Cette partie est généralement gérée par le conteneur (par exemple Matroska), il y a des experts en la matière pour gérer ton exemple.
Pas à ma connaissance. Mes sponsors sont plus à vouloir quitter le monde du un fichier par image car ils en ont un peu marre de 100 000 fichiers par contenu.
En théorie rien n’empêcherait de mettre un identifiant dédié dans par exemple TIFF, c'est juste pas fait faut d’intérêt par les sponsors.
Pour info il y avait une tentative FLIF "inspiré" (au départ il prenait pas mal tout :) ) de FFV1 mais son auteur semble être allé du côté obscur de la force (chez JPEG pour travailler sur JPEG XL. Maintenant qu'on a documenté l'existant, il faut de notre côté qu'on compare tous ces formats sur le taux de compression et vitesse pour savoir où on en est entre nos début il y a 10+ ans et les formats sortis entre temps.
[^] # Re: Le poids du sans-perte.
Posté par Thomas Debesse (site web personnel) . Évalué à 9.
Ah oui c’est vrai qu’avec matroska on peut aussi concaténer des pistes vidéos, et puis en intra-frame peut-être qu’on doit pouvoir avoir des parties déduplicables entre deux images clés identiques.
Oui je suis FLIF, enfin maintenant FUIF, avec attention puisque j’ai un intérêt pour les formats d’image en général et les formats d’image sans perte en général, que ce soit pour pour les besoins de ceux avec qui je travaille (archivage) ou pour mes propres besoins (photographie, jeu vidéo) qui apportent leur propres problématiques : archivage mais aussi versionnage (ce qui implique d’avoir accès aux anciennes versions aussi facilement que les versions actuelles), et les contraintes d’efficacité de (dé)compression en terme de fidélité, de temps et d’énergie. Un format comme le WebP lossless est intéressant comparé au PNG 8 bit (et il commence à être bien pris en charge), mais ça reste du 8 bit, et pour la photo, produire un WebP lossless 8-bit n’est pas sans perte en fait puisque ce n’est « sans-perte » qu’après avoir déjà perdu de la précision. Les appareils photos produisent souvent des fichiers permettant de travailler en 10, 12 ou 14-bit et les logiciels comme Darktable gèrent ça très bien, donc même un WebP 8-bit “sans-perte” perd beaucoup.
Ce qui me gène beaucoup avec le PNG c’est (mais ce n’est pas à toi que je vais l’apprendre =D) :
J’ai eu à débugger la prise en charge de PNG dans un logiciel et en me souvenant qu’IE6 ne gérait pas non-plus complètement le PNG j’ai commencé à ressentir de la compassion pour les développeurs d’Internet Explorer. :'(
C’est dommage que FLIF s’éloigne de FFV1 mais en même temps le fait qu’on puisse convertir du JPEG en FUIF sans ajouter de dégradation existante est très vendeur… Et c’est très alléchant de pouvoir ajouter une canal alpha à un JPG sans recompresser (avec perte) la partie RGB.
Par contre vu tous les cas d’usage que FUIF est capable de gérer, il va falloir une bibliothèque faisant beaucoup d’abstraction pour le commun des mortels… Par exemple pour ceux qui ne font que visualiser des images, une façon simple d’obtenir un équivalent RGBA 8-bit sans à voir à gérer soi-même les diverses variantes du format et les transformations éventuelles serait très pratique. Pour l’outil précité (NetRadiant) c’est tout ce dont j’aurai besoin,
rgba = load(file);, peu importe si la précision est perdue ou si au contraire la précision est inutilement élevée.Une problématique qui est peut-être nouvelle, c’est l‘efficacité à dédupliquer qui peut se révéler plus importante que l’efficacité à compresser. Un format .odt est un zip, et le format zip compresse chaque fichier indépendamment, ce qui est moins efficace qu’une archive « flat » qui compresserait l’ensemble de tous les fichiers concaténés, sauf que si on ne modifie qu’un seul fichier du zip, un logiciel de versionnage doit pouvoir dédupliquer tout ce qui n’a pas changé.
Faudra que j’en parle à Jehan tiens, si Gimp veut être dans le futur il faudra que les futurs .xcf visent la déduplication plutôt que la compression, en compressant chaque calque séparément par exemple, de manière à ce que modifier un seul calque ne fasse qu’un delta de la taille de calque dans un dépôt versionné. On peut même pousser le vice à compresser chaque canal séparément, car dans certains usages, les canaux RGBA peuvent en fait coder des données indépendantes, et on peut imaginer ne vouloir éditer que la rugosité d’un seul calque, et voir tout le reste dédupliqué dans le stockage du gestionnaire de version. =)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Le poids du sans-perte.
Posté par Stéphane Ascoët (site web personnel) . Évalué à 4.
Je trouve que le passage en numérique rend les défauts originellement présents bien moins acceptables que lors d'une lecture directe depuis le support initial. Et des artefacts actuellement négligeables peuvent poser de gros problèmes au fil de l'évolution des usages, des transferts de formats… ces questions sont traitées dans l'article qui compare les différents codecs et formats capsules (lié dans l'article).
Sinon, c'est marrant, j'ai lu cet article juste après avoir vu "Archivage audiovisuel : dans la jungle des formats de fichiers. Conférence de Reto Kromer (5 juillet 2019)" ! J'ai assisté sur place à d'autres conférences qui parlent de tout ce dont vous débattez au sujet du DCP notamment. Si elles sont en ligne, c'est par ici, peut-être en faisant varier les critères. Il y a de quoi y passer sa vie avec tout ce choix de pépites… et j'ai encore moins le temps de mettre à jour mes récits en bas de http://sascoet.mutu.fdn.fr/monalbum/cinema/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.