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) .
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.
Pour l'étudier en amont.
Tu serais déçu, il n'y a rien que des ULs qui vont bien pour dire que c'est du FFV1.
un nouveau format inconnu encore. (phase d'étude, de compréhension, d'implémentation)
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…
il serait préférable d'ouvrir un peu plus à ce niveau
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.
Non, j'ai interdiction de modifier 100% de la spec DCP, y compris 100% du texte que sur le XML du DCP.
Mais bullshit bordel, on le fait nous ! Même Dolby.
On modifie des DCP, on rajoute des trucs.
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…
Prendre les PDF sur dcimovies.com, tu fais ce que tu veux,
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).
J’ai vu aucune indication de non-liberté dans le SMPTE-377,
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…
Mais bullshit bordel, on le fait nous ! Même Dolby.
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.
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.
On parle de formats, tu me parles de logiciels… Peut-être que tu penses aussi aux brevets, ce n'est pas le sujet.
Ou alors pour toi, cela voudrait donc dire « libre == gratuit » ?
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.
Ou alors corrigez les pages Wikipédia si vous êtes si savants.
Il y a l'officiel (RHL arrêté au profit de RHEL), et la pratique où la plupart des gens considèrent que c'est des problèmes commerciaux plus qu'autre chose et que RHEL est dans la lignée de RHL vu que c'est les mêmes derrière donc qu'on peut prendre comme "date de naissance" de RHEL celle de RHL.
Pour faire un parallèle (pourri peut-être, j'ai que ça en stock la maintenant), une personne qui change son nom lors d'un mariage ne naît pas le jour de son mariage bien que ce soit la première fois que ce nom est utilisé et que quelque chose a changé.
Entre déterrer le terme "GNU/" d'entre les morts (comme M$, je n'en voyais plus passer, et il y a de moins en moins de GNU, au mini en relatif, dans nos ditros) et "oublier" la distro "pour les pros" qui est la plus installée chez les gros, et qui fournit pas mal de contribution sur le noyau et même sur tout l'écosystème, comme certes un peu plus tard mais la distro la plus connue du grand public (ho un filtre pratique sur les années 90), la dépêche n'est pas du tout orientée vers une petite partie seulement de l'écosystème autour de Linux… :-p
Bon, pour les curieux mais fainéants, j'ai fait pour vous un résumé suite à ma curiosité (les connaisseurs me corrigeront :) ) :
- ça parle de Brain Fuck Scheduler, une alternative au scheduler Linux "vanilla" jamais intégré (donc coût de maintenance à chaque version)
- moins d'utilisateurs pour de plus en plus de taf pour synchroniser avec les nouvelles version de Linux = normal d'arrêter. La mort fait partie de la vie.
Edit : toujours réactualiser avant de poster… Nibel a fait mieux que moi.
Jeu en entier mais pas libre. Seul le moteur est libre. Du coup il y a bidouille pour récupérer le reste (téléchargement de chez soit et pas dans ce que fournit le site).
"jeux libre" dans le contenu du journal est donc faux, mais le titre est juste (le titre ne parle pas de libre).
Et pour les gens s’intéressant au libre plutôt que juste au logiciel libre il y a une grande différence entre "jeu libre" et "jeu à moteur libre" (dans l'un on peut modifier le jeu pour ajouter ou améliorer les graphismes, grosse partie d'un jeu, pas l'autre).
donc corrections :)
OpenRA est la version libre (sous licence GPL v3) de
OpenRA est la version à moteur libre (sous licence GPL v3) de
(note : la formulation peut être encore trompeuse, OpenRA ne livrant pas les assets mais proposant de les télécharger, et le site parlant de "The OpenRA game engine" donc OpenRA n'est pas forcément le nom de l'ensemble logiciel+assets mais le nom du logiciel, peut-être dire "OpenRA est un moteur de jeux libre (sous licence GPL v3) pour")
Ces jeux libres sont téléchargeables
Ces jeux à moteur libres sont téléchargeables
(note ; pareil, peut-être plutôt "Ce moteur de jeu libre est téléchargeable… Les assets étant proposé ensuite au téléchargement non libre", bref vous voyez l'idée)
Pour référence, dans le même style il y a Zero-K, version un peu plus proche (assets avec de meilleures licences mais il y a parfois du "NC" et "ND", et de souvenir il n'y a pas vraiment de volonté d'avoir une version libre) de libre "améliorée" de Supreme Commander.
Sans doute pas bien écrit, mais toute personne s’intéressant au sujet et à l'actualité ne peut que penser au délire qu'il y a eu sur un traitement "qui marche, promis même si je fais pas une étude randomisée pour le prouver" basé sur une étude (faut vite le dire) qui excluait les personnes les plus à risque alors forcément le résultat était ce que le professeur dirigeant cette étude voulait. En réalité, le traitement ne faisait rien (ce qui tue… Car pensant que ça marche on perd du temps à ne pas utiliser et motiver les gens pour un truc qui marche, un vaccin par exemple), démontré par plein d'études randomisées lancées sur base de l'annonce que ça marchait. On serait joueur juridique qu'on pourrait parler de mise en danger de la vie d'autrui par ces bidouilles pour se faire remarquer (thunes, thunes, quand on peut ensuite vendre des revues et des livres sur le dos de la crédulité des gens…).
Oui, on ne peut que immédiatement penser à Raoult quand on parle de biais dans les études pour qui suit l'actualité. Faudrait presque en faire un concours pour décerner un "prix Raoult".
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.
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).
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;
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…
Est-ce que tu aurais des MXF avec du FFV1 (mode Frame et mode Clip) accessible quelque part ?
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.
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é.
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é.
[on pourra rétorquer qu'il faut aussi les docs SMPTE, il est vrai, c'est casse-bonbon, même pour moi]
Donc sa phrase est bien plus proche de la vérité que la tienne.
Des artefacts sur un écran cinéma ?
En sachant que le JPEG2000 est wavelet, je comprends pas ce que tu as voulu dire.
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é.
Je le fais depuis mon modeste portable.
Il suffit pour cela de choisir un autre layer de résolution.
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.
le format DCP est très libre.
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.
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…)
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.
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.
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".
Autant on peut trouver des petits trucs à redire sur la forme (on "choquera" toujours des gens, juste jamais les mêmes, si on change un petit truc), autant SUD est abjecte en balançant du "racisme" pour dire de trouver un truc qui plaise à ses adhérant qui veulent être anti sur tout. Il faut être quand même sacrément tordu dans sa "logique" pour arriver à cette conclusion sur la base des affiches fournies (oui, ce sont des affiches, pas pas une thèse sur la laïcité de 100 pages, donc les phrases doivent être courtes pour toucher le public visé, c'est ça la réalité).
Le titre du lien aurait dû être : SUD lance une étrange campagne de dénigrement sur le gouvernement.
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.
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).
Je pense qu'il y a plein de monde dans notre cas.
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.
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.
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)
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)
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.
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 ?
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.
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.
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)
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.
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.
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.
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 ».
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.
En l’espèce, soit dit en passant, cela donne au format ouvert une force supérieure à celle du logiciel libre. Mais bon.
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).
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) ?
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).
est-il possible (voire facile) d’encoder/décoder des données qui ont (parfois beaucoup) plus que trois composantes ?
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.
Non mois c'est l'inverse je me demande comment ce format a pu rencontrer le succès sans normalisation.
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).
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.
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.
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.
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.
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: Et à quand un format cinéma libre? 😉
Posté par Zenitram (site web personnel) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. É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 Zenitram (site web personnel) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. É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 Zenitram (site web personnel) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. É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 Red-Hat ?
Posté par Zenitram (site web personnel) . En réponse à la dépêche Linux 30 ans déjà .... Évalué à 10.
Il y a l'officiel (RHL arrêté au profit de RHEL), et la pratique où la plupart des gens considèrent que c'est des problèmes commerciaux plus qu'autre chose et que RHEL est dans la lignée de RHL vu que c'est les mêmes derrière donc qu'on peut prendre comme "date de naissance" de RHEL celle de RHL.
Pour faire un parallèle (pourri peut-être, j'ai que ça en stock la maintenant), une personne qui change son nom lors d'un mariage ne naît pas le jour de son mariage bien que ce soit la première fois que ce nom est utilisé et que quelque chose a changé.
C'est tout.
# Trollesque
Posté par Zenitram (site web personnel) . En réponse à la dépêche Linux 30 ans déjà .... Évalué à 3.
Entre déterrer le terme "GNU/" d'entre les morts (comme M$, je n'en voyais plus passer, et il y a de moins en moins de GNU, au mini en relatif, dans nos ditros) et "oublier" la distro "pour les pros" qui est la plus installée chez les gros, et qui fournit pas mal de contribution sur le noyau et même sur tout l'écosystème, comme certes un peu plus tard mais la distro la plus connue du grand public (ho un filtre pratique sur les années 90), la dépêche n'est pas du tout orientée vers une petite partie seulement de l'écosystème autour de Linux… :-p
# Résumé
Posté par Zenitram (site web personnel) . En réponse au lien Con Kolivas jette l'éponge après plus de 10 ans de bons et loyaux services. Évalué à 5. Dernière modification le 31 août 2021 à 18:34.
Bon, pour les curieux mais fainéants, j'ai fait pour vous un résumé suite à ma curiosité (les connaisseurs me corrigeront :) ) :
- ça parle de Brain Fuck Scheduler, une alternative au scheduler Linux "vanilla" jamais intégré (donc coût de maintenance à chaque version)
- moins d'utilisateurs pour de plus en plus de taf pour synchroniser avec les nouvelles version de Linux = normal d'arrêter. La mort fait partie de la vie.
Edit : toujours réactualiser avant de poster… Nibel a fait mieux que moi.
[^] # Re: jeu ou moteur?
Posté par Zenitram (site web personnel) . En réponse à la dépêche Jeux de stratégie en temps réel OpenRA. Évalué à 8. Dernière modification le 31 août 2021 à 15:20.
Jeu en entier mais pas libre. Seul le moteur est libre. Du coup il y a bidouille pour récupérer le reste (téléchargement de chez soit et pas dans ce que fournit le site).
"jeux libre" dans le contenu du journal est donc faux, mais le titre est juste (le titre ne parle pas de libre).
Et pour les gens s’intéressant au libre plutôt que juste au logiciel libre il y a une grande différence entre "jeu libre" et "jeu à moteur libre" (dans l'un on peut modifier le jeu pour ajouter ou améliorer les graphismes, grosse partie d'un jeu, pas l'autre).
donc corrections :)
OpenRA est la version à moteur libre (sous licence GPL v3) de
(note : la formulation peut être encore trompeuse, OpenRA ne livrant pas les assets mais proposant de les télécharger, et le site parlant de "The OpenRA game engine" donc OpenRA n'est pas forcément le nom de l'ensemble logiciel+assets mais le nom du logiciel, peut-être dire "OpenRA est un moteur de jeux libre (sous licence GPL v3) pour")
Ces jeux à moteur libres sont téléchargeables
(note ; pareil, peut-être plutôt "Ce moteur de jeu libre est téléchargeable… Les assets étant proposé ensuite au téléchargement non libre", bref vous voyez l'idée)
Pour référence, dans le même style il y a Zero-K, version un peu plus proche (assets avec de meilleures licences mais il y a parfois du "NC" et "ND", et de souvenir il n'y a pas vraiment de volonté d'avoir une version libre) de libre "améliorée" de Supreme Commander.
[^] # Re: Commentaires de l’article, applications à la science actuelle
Posté par Zenitram (site web personnel) . En réponse au lien Les études statistiques sont-elles hors de contrôle ?. Évalué à -2.
Sans doute pas bien écrit, mais toute personne s’intéressant au sujet et à l'actualité ne peut que penser au délire qu'il y a eu sur un traitement "qui marche, promis même si je fais pas une étude randomisée pour le prouver" basé sur une étude (faut vite le dire) qui excluait les personnes les plus à risque alors forcément le résultat était ce que le professeur dirigeant cette étude voulait. En réalité, le traitement ne faisait rien (ce qui tue… Car pensant que ça marche on perd du temps à ne pas utiliser et motiver les gens pour un truc qui marche, un vaccin par exemple), démontré par plein d'études randomisées lancées sur base de l'annonce que ça marchait. On serait joueur juridique qu'on pourrait parler de mise en danger de la vie d'autrui par ces bidouilles pour se faire remarquer (thunes, thunes, quand on peut ensuite vendre des revues et des livres sur le dos de la crédulité des gens…).
Oui, on ne peut que immédiatement penser à Raoult quand on parle de biais dans les études pour qui suit l'actualité. Faudrait presque en faire un concours pour décerner un "prix Raoult".
[^] # Re: Et à quand un format cinéma libre? 😉
Posté par Zenitram (site web personnel) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. É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 Zenitram (site web personnel) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. É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 Zenitram (site web personnel) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. É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".
# Quand tu ne peux pas critiquer en direct, invente...
Posté par Zenitram (site web personnel) . En réponse au lien Le ministère de l’éducation nationale lance une étrange campagne d’affichage sur la "laïcité". Évalué à -10.
Autant on peut trouver des petits trucs à redire sur la forme (on "choquera" toujours des gens, juste jamais les mêmes, si on change un petit truc), autant SUD est abjecte en balançant du "racisme" pour dire de trouver un truc qui plaise à ses adhérant qui veulent être anti sur tout. Il faut être quand même sacrément tordu dans sa "logique" pour arriver à cette conclusion sur la base des affiches fournies (oui, ce sont des affiches, pas pas une thèse sur la laïcité de 100 pages, donc les phrases doivent être courtes pour toucher le public visé, c'est ça la réalité).
Le titre du lien aurait dû être : SUD lance une étrange campagne de dénigrement sur le gouvernement.
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Zenitram (site web personnel) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. É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: Le poids du sans-perte.
Posté par Zenitram (site web personnel) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. É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: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Zenitram (site web personnel) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. É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.
[^] # Re: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Zenitram (site web personnel) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. É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 Zenitram (site web personnel) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. É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: Pourquoi
Posté par Zenitram (site web personnel) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. É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: Imprécision de langage
Posté par Zenitram (site web personnel) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. É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: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Zenitram (site web personnel) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. É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: Pourquoi
Posté par Zenitram (site web personnel) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. É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: Imprécision de langage
Posté par Zenitram (site web personnel) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. É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 Zenitram (site web personnel) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. É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: Performances de compression par rapport à d'autres formats avec*pertes
Posté par Zenitram (site web personnel) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. É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 Zenitram (site web personnel) . En réponse à la dépêche FFV1, un format vidéo sans perte et libre, normalisé à l'IETF. É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.