Zenitram a écrit 29455 commentaires

il y a un header toujours au début : "ftyp", indépendant des données vidéo/audio, qui indique le profile du fichier MPEG-4. Indépendant du bloc "moov" qui contient les données d'initialisation (qui peut être après "ftyp", ou à la fin, suivant le besoin) et l'index (très dépendant des données vidéo/audio)

On peut connaitre le "ftyp" (NSNV dans ce cas) sans avoir les données d'initialisation (à cause du plantage de la caméra)

Oui, les gens utiliseront plus facilement MC pour exposer les aspects "pro-libres" (pour le dire vite)

Faut le dire vite, très vite... Car c'est "juste" incompatible avec le libre (clause "non-profit" mise en avant comme positive, c'est le contraire qui est pro-libre = pas de restriction sur le commercial).

Par exemple, le site de Move common est non libre. Faudrait arrêter de faire croire qu'on est "pro-libre" quand l'idée est complètement à l'opposé du libre ("pour tous les usages)

Par contre un truc que je ne comprends pas trop, je pensais qu'ils étaient en train de passer à une base Debian, et la 12 est à nouveau à base Ubuntu ?

Il y a les deux :
Linux Mint 12 (releases fixes)
Linux Mint Debian Edition (rolling release)

Je reproche à PC INpact d'être d'une mauvaise foi absolue avec Google Trend.

As-tu lu l'article?
L'image est reprise d'un autre site (voir la source, donc en fait c'est l'auteur du journal qu'il faut engueuler un peu, la source de l'image n'est pas PC Inpact mais Royal Pingdom), et l'article (de PC Inpact) dit : "La tendance est en tout cas confirmée par Google Trends (...)". Ce n'est pas faux.

Le résultat de Google Trend est différent :

Non, il n'es pas différent : la tendance d'Ubuntu est à la baisse.
Et ton Google Trends n'est pas mieux : Tu as mis "Linux Mint" contre "Ubuntu", et pas "Mint" contre "Ubuntu" (bizarre de l'enlever sur un et pas sur l'autre...), et donc le résultat "absolu" est faussé dans tous les cas. Je dirai que leur comparaison est nettement meilleure que la tienne question "objectivité". En pratique, tu es aussi nul que ceux que tu critiques pour faire des graphs Google Trends sans recul. Le problème est que Mint a une autre signification, donc on peut juste pas comparer.

Et ce n'est pas le sujet : tu craches sur le site, dans un premier temps sans expliquer la raison, et même, tu craches sur le site entier pour un article. Ton opinion est faite, avec présomption de culpabilité. C'est un peu gros. Toi, tu ne fais jamais d'erreurs? (je viens juste de voir dans ton commentaire que tu es aussi nul qu'eux, donc fouette-toi). Tu pourrais juste être moins généraliste dans tes phrases uniques.

J'ai l'impression que c'est comme les sondages : on prend ceux qui nous arrangent pour pouvoir faire un article.

Bah... il y en a bien qui prennent ce qui les arrangent pour faire un commentaire ici.

PS : oui, je sais, même avec "Mint" tout court ça fait la même chose, mais c'est pour te démontrer que tu ne fais pas mieux dans la comparaison que ceux que tu critiques.

Pourquoi moinsser le commentaire de Jarvis?

Parce qu'insulter un autre site sur un soit-disant niveau inférieur (c'est ce qui est sous-entendu par la façon de dire), juste parce qu'on se croit supérieur aux autres (On croirait un noble qui parle du prolétariat "mais vous pouvez pas décemment écouter la moindre parole de ces pouilleux!"), ne mérite pas autre chose, de mon point de vue.

Au contraire, c'est classique pour les particuliers (suffit de regarder le nombre de dossiers de surendettement)

le "PSP" ici est juste un "profile", mais ça reste un bête conteneur MPEG-4. Il reste que (j'ai pu avoir le fichier entier) que le header manque (classique crash du logiciel avant de finaliser le fichier), donc il faut un logiciel capable de construire le header. Ce n'est pas trivial, et je n'ai pas connaissance de logiciel existant sachant faire ça (c'est dans ma liste des choses à faire car ce n'est pas la première fois qu'il y a ce genre de crash, mais loin dans la liste...).

Paix à l'âme de la vidéo.

C'est gentil de penser à moi :).

Mais sans le "header" (moov atom), MediaInfo ne pourra pas faire grand chose, même réaction que ffmpeg, la taille des images et l'initialisation du décodeur étant dans le moov atom.

Bref, point de salut même avec MediaInfo, le fichier de notre ami est bien pourri, sans doute "non finalisé" par le caméscope (je ne pense pas que ce soit qu'un bête fichier tronqué, la taille de la partie data étant à "unknown" = temporaire). Après, je peux pas voir le fichier entier, je ne sais pas si c'est mon navigateur ou son serveur (je pencherai quand même pour son serveur), mais à partir de 2 GB ça coupe le téléchargement, donc dur.

--> Poubelle, à part faire un programme exprès pour recréer le header à partir de ce qu'il y a (si il n'y a pas de logiciel qui fait déjà ça, pas sûr que ça vaille le coup de passer des heures de dév dessus...).

Quand même un petit test si il veut essayer un peu, avec un peu de chance : regarder dans le fichier si vers la fin il n'y a pas les lettres "moov" (minuscules) et "trak" (minuscules), dans ce cas il y aurait un espoir qu'il y ai que 4 octets à changer.

Personne n'a dis que WebP était révolutionnaire juste qu'il est bien.

Tu pourrais lire un peu... On a réagit, ce n'est pas dans le vide.
Le lien direct si il faut : https://linuxfr.org/nodes/88383/comments/1294170

Quand on sort un truc en disant c'est révolutionnaire il vaut mieux que ça le soit si on n'accepte pas les critères.

Google n'a pas dit que c'est révolutionnaire, mais Tanguy oui. Donc bon, c'est lui qu'on critique.

et qu'ils n'ont fait qu'un travail d'intégration (on prend un format déjà existant et on y ajout des techno actuelles faites ailleurs).

C'est surtout un n-ieme format, sans concertation. Alors pour l'image, à la limite ça permet d'avoir le niveau de JPEG-2000 (c'est trop rigolo de comparer à JPEG, peur de se comparer au bon format proprio existant?) avec moins de problème de droits (mais j'ai un doute : est-ce que Google s'engage à me défendre si jamais je suis attaqué? Non. Donc j'ai autant de risque sur WebP que sur JPEG-2000). Pour la vidéo, hop un autre conteneur, c'est lourd, on en a déjà suffisamment des conteneurs, ils auraient mis WebP dans du Matroska comme ils font pour WebM que ça aurait été plus simple pour tout le monde.

Tiens, hop, ça nous plait pas, on invente une excuse qui n'a rien à voir avec le sujet pour dire que c'est différent, pas une révolution. Euh... C'est quoi le rapport avec la révolution? C'est une révolution uniquement si la révolution va dans ton sens? On n'a pas la même définition...

Ce n'est pas l'algorithme qui est révolutionnaire, mais plutôt la volonté de le répandre, et les actions concrètes pour cela. D'une façon plus extrême, c'est comme lorsqu'une boîte invente un appareil innovant et intéressant mais ne le commercialise pas — et ne publie pas non plus les plans — : ça ne sert à rien, ça n'apporte rien à la société.

Très fort : Apple ne fait rien de révolutionnaire, mais Google fait de la révolution. J'espère que la prochaine fois que quelqu'un critiquera Apple car il n'a rien fait de révolutionnaire, tu réagiras en disant que la révolution tient dans la façon de l'amener.

D'après ton argument, Google fait quelques révolutions, Apple fait des révolutions permanentes (et eux, ça marche, car pour le moment WebP ne marche pas plus que ça à part chez Google, comme WebM)

Bref, ça me fait bien sourire que les gens (pas que toi, je te rassure) change les arguments suivant ce qui leur plait (pour d'autres raisons), sans accepter d'appliquer les mêmes critères pour tous.

Ok, je n'avais pas compris, je croyais que tu voulais mettre le binaire EXIF dans un champ XMP.

Maintenant, ce n'est pas créé de manière "globale", c'est fait par une seule boite (Adobe), mais si ça peut aider par rapport à EXIF (qui pour mémoire est une grosse merde à coup d'extension proprio non documentées), oui c'est tant mieux.

ie. ne pas avoir seulement 256 niveaux par canal, mais 512 par exemple (c’est aussi un reproche qui est souvent fait à Gimp — du nouveau de ce côté là ?)

Rassurez-moi : GIMP gère les formats 9, 10, 11, 12, ou 16 bits quand même? Je sais pas moi, on dit qu'il est au niveau de Photoshop et que si Photoshop est préféré c'est pas pour des questions techniques, donc je m'attends à ce que le 16 bits (et CYMK) soient gérés. (bon, moi pas amateur de retouche, je n'ai pas fait attention à ça, mais la on parle de gens un peu intéressés par la photo)

Oh l'usine à gaz...

Dans le cas, précité par Zenitram, où la clé privé du serveur a été volée et que l'attaquant utilise un DNS menteur pour faire atterrir example.com sur son serveur au lieu du bon, tu es cuit la même chose

Non, parce que le certificat a été révoqué par le tiers de confiance (celui dans lequel tu n'as pas confiance, rappelle-toi, mais la, ben il est vachement utile) donc le certificat est bien plus protégé et toujours valide. C'est le but du jeu de SSL, entre autre, que ne permet pas ta super solution à base de SSH (qui elle, se fait planter en beauté dans ce scénario).

Les cas problématiques ont été quand le tiers ET le DNS étaient troués (de manière volontaire ou non pour le tiers, mais la il faut "juste" nettoyer les tiers pas de confiance plutôt que de critiquer SSL)

Lapin compris.

C'est normal, c'est faux.
Open source ou libre, pour toi c'est exactement pareil (les mêmes "contraintes"), pour ton gâteau.
La différence est uniquement sur la philosophie du développeur, si il est un activiste du libre ou si il utilise car c'est le meilleur moyen.

Du coup, autant tu sais comment sont fait les gâteaux open source, autant il n'est pas possible de les copier.

C'est pas bientôt fini ces énormes mensonges?
Avec l'open-source, c'est obligatoire de pouvoir copier.
http://opensource.org/docs/osd

Comme le libre, oh miracle.

Que des trucs trop utiles à implémenter pour faire l’équivalent à peine plus poussé de cat img1.webp img2.webp > img.awebp…

C'est grave... Le format a des éléments optionnels. C'est l'interêt d'un bon format, que le décodeur puisse zapper ce qu'il ne supporte pas.
Vous n'avez jamais entendu parler de profiles? plutôt que de faire un format par profile qui suffirait.

Le trois quarts de ces machins est totalement inutile pour les objectifs modestes d’un WebP animé.

Tu peux mettre alors du WebP dans un conteneur connu (au hasard : Matroska, celui de WebM), plutôt que d'en réinventer un.

l’objectif c’est de partir d’un codec WebP pour arriver à du WebP animé, et faire du cherry picking des specs de Matroska + VP8 pour arriver à ça, c’est un peu exagéré.

Pour un besoin, inventons un format. Et après, on va s'étonner que les navigateurs refusent d'implémenter 20 formats qui font la même choses mais un peu différemment".

Vivement le WebPM...

WebM (le format vidéo, pas le conteneur) ne supporte pas les B-Frames.

On recommence : prend le format "video" (bref, pas le conteneur) WebP (donc WebM sans P-Frames), met le dans un conteneur WebM (bref, du matroska), ça sera pas plus dur que du WebP animé.

Je parlais de WebM le conteneur surtout. le conteneur n'est *pas** complexe (c'est du Matroska), donc plutôt que d'utiliser l'existant (WebM auquel on "interdit" les P-Frame), on prend le WebM I-Frame qu'on met dans un autre conteneur (le truc à bidouiller pour mettre plusieurs images dans du WebP).

Bref, au final, c'est rigolo : plutôt que de faire un "profile" WebM interdisant les P-Frames, on invente un autre conteneur. Plus de boulot pour tout le monde, mais c'est pas grave. Après, ils rajouteront l'audio à WebP...

et que ça tient dans 10ko de C.

Je suis intéressé par ton décodeur WebP de 10 Ko de C, comme ça je le mettrai pour décoder WebM (qui réclame pas beaucoup plus, seul la couche conteneur change, ce qui n'est rien)
Et au final, tu auras un WebM (sans support audio, pas grave) de même simplicité que ton décodeur WebP.

C'est con, mais non, ce n'est pas d'un simplicité à pleurer par rapport aux vidéos, c'est quasi-pareil. La complexité, elle est juste dans la tête des gens qui veulent différencier, pas dans la tête des codeurs.

baud123, tu peux corriger ma honteuse erreur s'il te plaît ? ;-)

il est intéressant de disposer de formats appropriés : typiquement, la compression sans pertes, l'alpha et la chronologie arbitraire sont beaucoup plus intéressants pour des animations que pour des vidéos ;

Ça ne change pas qu'on peut avoir le même format, avec quelques bits de différence, plutôt que tout réinventer, différemment.
Par exemple, tout le monde décrie h264 car c'est le méchant bourré de brevet, mais... Il ne change pas de format juste pour un nouveau besoin, il étend le format, optionnellement. Quand ce sera compris, on aura fait un grand pas. Ici, point besoin de créer un nouveau système incompatible, WebM répond déjà au besoin (paraît que c'est le même format de compression non ? Donc, tu fais évoluer l'image dans WebM aussi... Tout le monde y gagne). Ça fait juste du boulot en plus pour le dév'.

les interfaces permettant d'interagir avec des vidéos et avec des animations sont différentes : typiquement, dans une animation on peut vouloir passer à l'image suivante, ce qui n'a pas un grand intérêt pour une vidéo.

Interface utilisateur, rien à voir avec le stockage et la transmission des données.

Si. L'alpha sur les images compressées avec pertes par exemple.

C'est qu'une couche en plus. JPEG-2000 permet un nombre illimité de couches. Juste qu'il n'y avait pas de bosin plus que ça pour que quelqu'un en fasse.

Rien de révolutionnaire, toujours, par contre tu pourrait sortir l'argument "alpha sur les images compressées avec perte, et ce sans brevets", ça serait plus vendeur, mais toujours pas très révolutionnaire (dans le sens où il n'y a absolument rien de nouveau)

Je signalais simplement que le WebP animé n'était sans doute pas du WebM, puisqu'il n'utilise que des I-frames

Changer de nom/format/truc juste pour une option à l'encodage, c'est bourrin. Ben oui, c'est juste une option, comme la largeur, la hauteur, et j'en passe. Pas besoin de tout réinventer. Chez d'autres, on change juste un octet pour préciser le profile, comme ça les décodeurs non P-Frames disent "non". Juste un octet. C'est plus facile que le support d'un nouveau format.

(au passage, merci pour la clarification).

De rien.

et de video pour tout le reste encodé en h264/mpeg2/mpeg4/etc..., qui utilisent le plus souvent des P-frames.

Ca dépend vraiment du domaine. J'ai une tonne de fichiers mpeg2 ou h264 en stock sans aucune P-Frame. Et comme dit avant, le cinéma, l' "Intra only" est la règle.