bonjour voila je me pose une question je possède  des vidéo de famille qui on était converti en mkv pour ne pas perdre trop de qualité  ,ce sont des vidéos  que je n'ai pas l'intention de consulter régulièrement   ,la question est donc si je compresse les vidéo avec une utilitaire comme 7-zip  vais je pouvoir réduire la place prise par ces vidéo ?
cela ne risque pas de détériorer la vidéo a la décompression après?
 
voila j’espère que vous pourrer éclairer ma lanterne!!

 
 
Salut.
 
Malheureusement, les vidéos étant par nature déjà compressées, les compresser à nouveau ne te fera pratiquement rien gagner .....( 1% ou 2%).
 
Bonne continuation.

Peu importe que la vidéo soit compressée ou non, pour 7-zip ce n'est qu'un fichier avec des 0 et des 1, on peut tout compresser avec, il faut juste essayer les réglages de taux de compression. Plus elle est forte, plus ça prend du temps, mais c'est un détail.
 

Non, c'est le principe du zip.

 
 
Et bien testes ! On en reparlera ......

 
Oui mais non. Le taux de compression dépend intrinsèquement du type de données présentes dans ton fichier. Sur un fichier déjà compressé, donc par nature ne disposant pas d'informations redondantes, tu n'obtiendras aucun gain en compressant via un algo de compression sans perte.
 
Si ce n'était pas le cas, cela voudrait dire qu'il est toujours possible de réduire la taille d'un fichier en le compressant, ce qui veut dire que tu pourrais compresser en boucle n'importe quel fichier jusqu'à obtenir un fichier de 1 octet par exemple, définissant une bijection parfaite entre deux ensembles de tailles différentes => c'est mathématiquement impossible.

 
 
+5
 
Au moins un qui réfléchit !    

On est encore vendredi, non ? Donc on peut dire des conneries ? OK, j'y vais...

Jusque là, parfaitement d'accord. Mais tous les algos sont optimisés pour un type de données "espéré" et les algos de type Lempel/Zev/Huffman/... s'attendent à des chaînes de caractères (au sens "bureautique" du terme) donc il est "facile" de faire beaucoup mieux que les *zip sur un tout autre type de données avec un algo optimisé pour cedit type de données. flac par exemple.
 
Il n'est pas interdit de penser qu'on puisse imaginer une nouvelle façon d'appréhender un type de données parfaitement connu et d'en obtenir, sans aucune perte un fichier plus petit. Pour preuve, certaines compressions d'entête ou je ne sais quoi qui font qu'on peut obtenir un mkv plus petit sans aucunement toucher aux contenus des flux (j'anticipe l'objection : oui, moins d'octets mais si peu que cela n'en vaut guère la peine mais ce n'était qu'un exemple).

Baouémainan. Le concept de taille est informatique, exprimé en octets ou en bits tandis que le concept mathématique est la cardinalité. Mais cardinalité de quoi ? Cardinalité de "chaînes de caractères" pour LZH et rien n'empêche d'imaginer (de façon théorique toujours) qu'on prendra tout fichier comme une seule chaîne et qu'on la remplacera par un simple bit donc cardinalité identique et bijection (certes, je compresse mais je ne stocke pas la table d'équivalence, j'ai un thésaurus...   ).
 
Brèfle. Plaisir de troller un peu et de défendre au passage arnuche qui, fondamentalement, n'a pas dit de connerie (et qui est capable de se défendre tout seul, évidemment) : notre OP peut bien passer 300 heures à compresser ses fichiers pour gagner 4 octets, c'est son droit, c'est probablement une pure perte de temps et d'argent mais cela n’abîmera en rien ses fichiers, nos amis qui s'échangent des blurays winrarés le savent bien.
 
Allez, je retourne taffer. Pas fini ma semaine, moi.

 
 
Bon courage pour la fin de semaine.
 
je reprends ce que que tu as écrit:
 
"Il n'est pas interdit de penser qu'on puisse imaginer une nouvelle façon d'appréhender un type de données parfaitement connu et d'en obtenir, sans aucune perte un fichier plus petit. Pour preuve, certaines compressions d'entête ou je ne sais quoi qui font qu'on peut obtenir un mkv plus petit sans aucunement toucher aux contenus des flux (j'anticipe l'objection : oui, moins d'octets mais si peu que cela n'en vaut guère la peine mais ce n'était qu'un exemple)."
 
C'est d'ores et déjà fait puisque le X264 permet de réencoder avec un poids de fichier nettement moins important que le H264 traditionnel.
 
Considérant que les MKV dont parle @ garlok44 sont sans doute en H264, il gagnera 30% environ avec des MKV en X264.
(Handbrake est LE logiciel à recommander).
 
Mais pas question pour un logiciel de compression traditionnel, donc généraliste (WinZip, WinRar, 7zip...) de faire la même chose avant de nombreuses années, en admettant que ce soit possible un jour.

 
 
 Salut,
 
Mes maths sont un poil rouillés, mais j'ai un petit souci avec cette partie. Considérons un fichier de n bits. Il y a donc 2^n possibilités. Tu me garantis qu'on peut toujours obtenir un fichier plus petit.
 
Or la somme des possibilités de fichiers plus petits (somme pour x=1 à x=n-1 de 2^x, on élimine l'hypothèse qu'un fichier fait 0 octets) est égale à 2^(x+1) -2 soit 2^(n) - 2
 
Tu auras donc à minima au moins deux cas pour lesquels ce sera faux, non ?

Je n'ai pas dit en boucle, mais compresser n'importe quel fichier une seule fois en zip (puisque le zip fonctionne un peu différemment des algos de compression audio/vidéo). Là où je partage ton raisonnement, c'est si on voulait re-compresser un zip en zip, ce qui est possible mais à peu près sans intérêt.

Ça ne veut rien dire H264 "traditionnel", je rappelle que le x264 est du h264, mais gratuit, tout comme il existe des encodeurs mpeg-1/2 gratuits.
C'est pas toi qui disais ;

?
 

Pour les débutants peut-être, pour ma part je conseillerais plutôt Hybrid ;
http://forum.doom9.org/showthread.php?t=153035

Je viens de le faire avec un fichier en h264 (compression optimale dans Winrar et ce n'est pas le plus efficace des compresseurs) : je passe de 73,8 Mo à 72,4 Mo. Tu disais ?
Bon ok, c'est pas franchement utile mais il y a un petit gain.

J'ai aussi fait le test sur un fichier en Lagarith (compression lossless, débit énorme) : je passe de 24,9 Mo à 24,1 Mo, donc pas beaucoup mieux que le h264 qui est pourtant nettement plus compressé ...

Il disait "les compresser à nouveau ne te fera pratiquement rien gagner .....( 1% ou 2%)". Le gain dans ton cas précis est de 1,89%. Donc ta démonstration lui donne raison.

Pas franchement utile ? Tu veux dire totalement inutile, non ? Surtout qu'en cas de corruption du fichier compressé sur quelques octets, c'est la vidéo entière qui risque d'être foutue.

La disctinction entre lossless et lossy en matière d'encodeurs spécialisés n'a en l'espèce aucune pertinence. Un FLAC se recompresse aussi mal qu'un MP3 avec un encodeur généraliste.

Tu peux me dire où j'ai écrit qu'il y aurait un gros gain en zippant la vidéo ? Mais je ne vais pas me défiler, je pensais bien sûr qu'il y aurait moyen de compresser un peu plus que ça.
 

N'importe quel fichier peut être corrompu et inutilisable, pas seulement les zippés. Et je pense avoir lu quelque part que les fichiers zippés étaient plus fiables pour les transferts.
 

Ça me semble loin d'être évident (bien que j'aie écrit plus haut "peu importe que la vidéo soit compressée ou non", mais c'était pour faire la distinction entre compression vidéo qui analyse l'image et compression type zip qui analyse le fichier), tu peux développer ? Parce que ça ne paraît pas très logique dans la mesure où la compression lossless ne fait que du spatial (dans le cas du huffyuv, lagarith ...) alors que la lossy fait du spatio-temporel, donc avec nettement plus de compression de la redondance temporelle. En même temps mon test montre en effet que ça ne change pas grand chose, étonnamment.

Où ai-je écrit que tu écrivais qu'il y aurait un gros gain ? Ca peut durer longtemps...    Je te fais juste remarquer dans mon post que ton "Tu disais ?" adressé à ClokeStone n'a aucun sens, puisque tu conclus finalement la même chose que lui : 1% à 2% seulement. Donc qu'un "Tu disais ?" sarcastique, tu aurais dû dire : "Effectivement, après test, je me rends compte que tu avais raison".    

Et tu étais bien le seul. Il est évident qu'aucun algo généraliste ne peut améliorer de manière sensible un fichier déjà compressé de manière optimale avec un algo spécialisé.

Ah ? Pourquoi ? Et je te signale que la corruption de fichiers intervient bien plus souvent lors de la dégradation d'un support que lors de transferts.
 
Mais ce n'est même pas la question : mieux vaut un fichier qui gère le support d'erreurs ("error handling", je sais pas trop comment le traduire), donc qui continuera à être lu malgré un passage corrompu qu'un fichier qui refusera complètement d'être décompressé en cas de pépin, et qui sera donc entièrement bon pour la poubelle. En audio lossless et en moindre mal, c'est le problème d'un vieux codec comme Monkey's Audio, par exemple. Pas d'error handling, donc si tu as un problème à 1 minute 27 d'une image CD d'1h12, tu as perdu la quasi-totalité de ton CD. Heureusement, tous les codecs audio lossless modernes gèrent l'error handling (FLAC, ALAC, Wavpack, MPEG-4 ALS/SLS etc.).

C'est parfaitement logique : la différence de base n'est pas dans les algos mais d'abord dans le modèle conceptuel. Le lossless ne supprime aucune info tandis que le lossy part sur un concept perceptuel (auditif et/ou visuel) qui détruit ce qui ne se voit/s'entend pas ou peu. A chacun des deux concepts correspondent des algos différents, mais ils sont optimisés au max dans les deux cas.
 
En lossless audio, il y a belle lurette que la bagarre entre encodeurs sur les taux de compression est finie. Si le FLAC a gagné le marché, ce n'est pas parce que c'est celui qui compresse le plus (il serait même dans le peloton de queue), c'est parce qu'on a atteint dans ce domaine des taux plafond qu'il est à peu près impossible d'améliorer et que la différence entre celui qui compresse le plus et celui qui compresse le moins est insignifiante dans l'univers informatique moderne. Du coup, d'autres critères bien plus importants sont venus remplacer ce fameux taux de compression. Tenter de regagner ne fût-ce que 10% sur de l'audio lossless grâce à un compresseur généraliste est forcément voué à l'échec. Si c'était possible, les compresseurs spécialisés en auraient tenu compte et auraient amélioré leurs algos.    

Ok, merci pour les infos.
 

M'étonnerait que je sois le seul   , ce n'est pas si évident puisque certains fichiers peuvent être beaucoup plus petits une fois zippés (je parle de manière très générale, parmi tous types de fichiers).
 

Ok mais dans le cas d'un transfert, je crois qu'il vaut mieux zipper le fichier pour la correction d'erreur (je pense aux vidéos puisque c'est la question initiale).