Si l'anglais ne te rebute pas, je te recommande l'excellent http://www.100fps.com/ , au sujet de l'entrelacement, telecinage et cie.
Tu y trouveras notamment des exemples de "ghost frames", quand est faite une interpolation entre deux images faisant partie de deux plans différents...
... et le sacro-saint sacrement du désentrelacement selon lequel, je traduis à-la-rache :
"A cause du mélange temporel (1 image=temps1+temps2), il est impossible de :
1) désentrelacer une image
ET 2) conserver 25 images/seconde
ET 3) conserver la qualité originelle (=toute l'information d'une image)
au moins un de ces points devant être omis, sauf lorsqu'il n'y a pas de mouvement"
... chose que quiconque transcode du contenu entrelacé devrait apprendre...
Et qui permet de comprendre beaucoup de choses sur le "retiming"...
Tu peux afficher les vecteurs de mouvements avec SMPlayer : dans le menu => Options => Visualiser vecteurs motions ... j'imagine que ça se fait aussi avec MPlayer, du coup (par contre, aucune idée de l'option idoine)...
Cela dit, il faut récupérer le .flv, pour faire ça...
Je n'ai pas encore pu zieuter tes videos (pas de flash sur cette machine... et étant en plein milieu du transcodage d'un film, pas question d'en mettre tout de suite - pas touche aux paquets pendant un truc qui dure plus de 12 heures), mais, généralement, ce qui me saoule le plus avec le changement de base temporelle, ce sont les "ghost frames" (ou images fantômes)...
Si l'image que tu insères se situe à un changement de scène, bonjour la casse... c'est d'ailleurs l'une des raisons qui font que je fais mes désentrelacements en utilisant la base temporelle des champs (fields, ie demi-images, typiquement décalées de 20ms, sur une video PAL à 25 images/seconde), plutôt qu'en divisant la résolution temporelle par deux (ce que font les transcodeurs crados, en général)...
En outre, selon la source de la video, même si elle ne semble que peu saccader, l'insertion d'images peut empirer la situation... je pense typiquement aux contenus télécinés (insertion de frames pour passer de 24000/1001 à 30000/1001, en NTSC) : de base, ils saccadent forcément, mais selon les scènes, on peut plus ou moins s'en rendre compte... mais en insérant des images intermédiaires, rien ne garantit forcément qu'on va améliorer les choses...
> le format vidéo utilisé par Flash est complètement proprio, sans aucune doc.
Sans doute, mais le principal souci, c'est le conteneur flash...
... les .flv, pas de souci, pour les lire avec Mplayer (brevets le protégeant, ou pas)...
Par contre, ces saloperies de flash qui obligent à avoir les libs 32 bits sur les OS 64 bits et qui font s'affoler mon Pentium-m 1,7GHz (pour ainsi dire à fond... et en embedded, même pas en plein écran), c'est encore la grosse loose, pour les lire - j'ai réessayé gnash l'autre jour sur ma Sid 64 bits : après avoir ouvert quelques pages qui contenaient du flash, j'ai réussi à m'en sortir en passant en tty et en faisant un bon gros killall, faute de ne serait-ce que pouvoir utiliser la souris tellement le système devenait lent...
... faut dire, c'est léger-léger, comme machine, un Q6600... bon, j'ai au moins trouvé quelque chose qui arrive à le mettre à genoux... m'enfin...
... bon, d'accord : c'est aussi parce que, vu qu'ils ne sauraient s'imaginer comme autre chose que des collocs, il serait intolérable qu'en échange de la bouffe et cie, ils soient incapables de m'amuser. Non, mais...
> La seule solution viable pour se protéger des accès physiques à la machine est de chiffrer les partitions.
Et encore... ça ne te protège pas forcément d'un leurre...
... mettons que tu ne te trimballes pas le /boot sur toi (par exemple, sur une clé USB), mais qu'il est sur la machine, en clair, prêt à se faire tirer comme un lapin... et que ton initrd te demande un mot de passe pour débloquer les partitions autres que /boot...
Maintenant, imaginons qu'une personne mal intentionnée avec un accès physique à la machine ait remplacé ton disque dur (qu'elle a emporté avec elle) par un autre contenant un initrd de même apparence, qui va te demander un mot de passe de la même manière, mais sera configurée pour dumper le mot de passe dans un fichier ou sur le réseau, et te dire que, pas de bol, quel qu'il soit, le mot de passe est bon, mais que les partitions chiffrées sont corrompues...
... et paf... ton disque est entre les mains de quelqu'un d'autre, et le mot de passe pour le débloquer aussi, si le fichier a été dumpé sur le réseau (en mettant ce qu'il faut dans l'initrd aussi)... ou au pire, pendant que tu es parti sur une autre machine télécharger une distro ou choper tes sauvegardes pour réinstaller, le margoulin n'a qu'à passer récupérer le passe dumpé localement...
Alors, OK, on pourrait imaginer booter sur un autre OS, sur support externe, et vérifier le hash du /boot local avant de faire quoi que ce soit (m'enfin, à ce compte, autant mettre dès le départ le /boot sur un périph externe)...
Mais la parano, c'est sans fin (parce que bon, après, qu'est-ce qui empêche de se méfier du matériel lui-même, outre ce qui est installé dessus ?)... et à un certain stade, protéger physiquement la machine (portes et fenêtres, voire aération, que même les pompiers ou le GIGN auraient du mal à ouvrir, pas de réseau, isolation électromagnétique, hordes barbares de mercenaires pour te protéger, ...), c'est peut-être encore ce qu'il y a de plus "direct". La sécurité, notamment en informatique, c'est une notion relative, pas absolue.
Pour le stockage de données, je dirais personnellement "bougre que oui" (/me est tout joyeux des deux disques de 1To qu'il vient de recevoir ce matin, grâce à une promo LDLC sur les Seagate en version boîte... ça va lui redonner un air de jeunesse, au bon vieil Athlon XP-m 2500+)...
... pour les binaires, par contre, non, c'est très large... même en mettant chaque service dans un conteneur (une sorte de super-chroot, qui fait que la base du système est répliquée dans chaque "machine"), il y a de quoi en mettre des tonnes...
... à la limite, ce qui risque de prendre de la place, ce sont les logs, les éventuels caches, et basta. Le reste, c'est peanuts.
En comptant tout (un petit "du -h"), mon plus gros conteneur, c'est MythTV (~1Gio), et le plus petit, le serveur à SSHFS (~300Mio)... ça fait de la très grosse marge, 60Gio... et ce sont des install de Debian pour lesquelles je n'ai rien fait de particulier afin qu'elles soient légères en place. Il y a moyen de grave gagner en optimisant.
En tout cas, on (en cours d'auto-école, aussi bien verbalement que dans le support que j'avais gratté à un pote) m'en a fait mention en 1996 (en fait...), en France... ce qui fait que ça fait plus de dix ans que j'en ai un avec moi en voiture...
... bon, après... si on était censés ne pas ignorer toutes les lois, règlements, et cie (qu'on m'ait dit ou non des conneries pendant le code), les femmes n'auraient pas le droit de "s'habiller en hommes" (si ce verbiage avait un sens)...
En tout cas, c'est le souvenir que j'en ai... je me rappelle très bien être allé en acheter un avec mon père (permis accompagné), après avoir appris que ça faisait partie de la panoplie qu'il fallait avoir avec soi, comme les loupiottes de rechange...
... bon, maintenant, ce n'est pas parce que c'était censé être la loi que c'était appliqué...
... regarde la loi Evin... pas neuf... et pourtant, ça n'empêche pas de faire du doublon...
A supposer qu'il arrive que le filtre d'aération soit nettoyé/changé de temps en temps...
... ou que le coupable d'une attaque fécale grave n'ait pas laissé des bouts de sa vidange au fond du chiotte...
C'est triste à dire, mais je connais des gens qui ont des chiottes tellement sales qu'ils ne les nettoient que toutes les quelques années... à l'acide ou à la soude, forcément... du coup, comme leurs gogues puent la mort (enfin, la macro-mort... au niveau microscopique, ça doit grouiller ferme), ils vaporisent des trucs qui sentent la fleur...
... et n'ayant aucune envie de nettoyer leurs trônes à leur place, même si j'ai horreur des odeurs florales, je prends sincèrement ça comme un moindre mal... il m'est d'ailleurs arrivé chez l'un d'eux de vaporiser de son pschit' directement en entrant dans ses "toilettes", faute de quoi, j'eu été contraint de rapprocher ma tête de la cuvette pour y vomir tripes et boyaux...
Je frémis encore rien qu'à penser au dévidoir de mon correspondant d'Albion, au collège, dans lequel l'absence de brosse à chiotte m'a pour le moins laissé perplexe...
Si tu dois t'arrêter au bord d'une route dangereuse, tu es de toute façon dans la merde... il m'est arrivé aux vacances de fin d'année de 2007 d'avoir mon coffre de bagnole qui s'est ouvert sur l'A13...
... vu que je venais de dépasser la sortie pour les Mureaux (et moi qui venait d'hésiter à m'arrêter pour passer voir un pote, et que je m'étais dit que, de toute façon, je le verrais quelques jours plus tard, à Rouen, où il devait passer...), soit j'attendais la prochaine aire, soit au moins quinze-vingt bornes, ou alors je m'arrêtais dans une montée/descente, mais de toute façon, à un endroit où il y avait du virage (il n'y a à peu près que ça dans le coin)...
Etant donnée la circulation qu'il y a sur cette route de psychopates en furie, j'ai choisi de ne pas laisser l'entropie croître jusqu'à ce que mon coffre se déverse sur la voie, et de m'arrêter le plus vite possible pour fermer cette saloperie de coffre... donc, dans une descente, avec du virage, sur la minuscule bande d'arrêt d'urgence (enfin, en tout cas, quand des camions passent à côté de toi à 150km/h, elle fait 'achement petite, la bande)...
J'ai réglé mon problème (du givre avait fait que je n'avais pas fait attention en partant de Versailles à ce que mon coffre était mal fermé... mea putana culpa) en quelques secondes, et zou...
Bon, j'avais un triangle (d'ailleurs, faudra m'expliquer en quoi c'est nouveau qu'il faut en avoir un : j'ai passé mon code en 1995, et je suis sûr que c'est à cette époque que j'ai appris qu'il était obligatoire d'en avoir un ; le truc avec des bandes jaunes était juste recommandé, par contre, avant les directives européennes), mais franchement, dans mon cas (je ne généralise pas : je relativise), de toute façon, la chose la plus sûre était de faire au plus vite, en faisant preuve d'une attention maximale...
... et au fond, c'est ça, qu'on devrait obliger les gens à prendre sur eux : de l'attention maximale... à la limite, avec des bandes jaunes réfléchissantes collées dessus, voire un masque d'halloween, ou une plume dans les fesses, pour ceux qui aiment... m'enfin...
Si je ne me trompe pas, il me semble que Legrand fait déjà de la domotique, X10, au moins, il me semble...
... bon, maintenant, X10, c'est quand même assez foireux... par exemple, ça ne passe pas les disjoncteurs différentiels et choses du genre... du coup, pas d'accès aux salles d'eau, ni à l'éclairage principal, dans les logements récents, à moins de mettre des coupleurs sur le tableau électrique... sans compter un fonctionnement des plus erratiques, pour ce que j'en ai vu chez un pote qui a acheté quelques modules... par contre, ça marche sous Linusque.
Dommage, car j'aimerais bien au moins gérer l'éclairage du salon, automatiquement, en fonction du media que j'y passe (TV => pas mal de lumière ; Film => peu de lumière ; Zique => entre-deux)... ou, soyons fous, gérer le chauffage, en prenant en compte des infos venant de stations météo, pour optimiser... ou encore, gérer l'arrosage des plantes... ou même, braquer une webcam sur les plaques de cuisson et le four pour voir où la pitance en est, et les arrêter/booster au besoin, pendant que je déguste ma Chimay dans le salon...
Faire des stats sur la conso électricité/eau/gaz serait aussi moult top... je crois que EDF&cie mène des expérimentations avec une box, et Poweo en propose une (avec abonnement) à connecter au net, qui va envoyer les stats sur leur site, d'où on pourra les consulter.
Sinon, apparemment la mode serait plutôt au bus KNX, mais il faut tirer des câbles, il me semble...
Bon, autrement, serveur "domotique", pour ce qui est des media, j'ai déjà depuis quelques années, avec MythTV (pour le salon, le bureau, et le laptop) et SlimServer (pour le radio-réveil), plus un MPD, sur le HTPC du salon (même si je m'en sers peu), et ça roxe. Il y a aussi d'autres mignonneries (fichiers, imprimantes, scanner, P2P, mail, jabber...), le tout sur deux machines, chaque service dans son conteneur (VServer et OpenVZ... je compte passer la première machine sur OpenVZ aussi - en plus, c'est cool : Sid propose maintenant un 2.6.26 avec OpenVZ intégré ; ça fleure bon pour l'avenir)...
... maintenant, un truc où ce sont les machines clientes qui vont aller trifouiller les serveurs, pourquoi pas, mais sans moi... je suis bien trop parano, et j'aime bien trop mettre les mains dans le camboui pour ça.
En fait, mon but secret serait de transformer mon habitat en PC géant, dont je serais le principal bug :) Hein ? Arf, damnaide... ce n'est plus un secret, maintenant...
Ca bouffe sensiblement plus au décodage, mais il faut relativiser...
Plus ça va, plus les résolutions auxquelles on affiche vont aller vers le 1080p (au moins)... et on n'est pas près d'avoir du progressif pour la plupart des broadcast, ce qui fait qu'il faut aussi désentrelacer...
Sur ma TV Full-HD, scaler un MPEG II sans désentrelacer bouffe dans les 10% d'un core de mon E4500... un petit coup de yadif 2x pour désentrelacer et que ça ait une bonne gueule, et paf : 60-75% d'un des cores...
A côté, scaler un H.264 en 576p, ça me bouffe entre 20 et 30% d'un des cores... et pas besoin de désentrelacer...
Pour ce qui est de scaler du 720p ou d'afficher du 1080p, là, il faut commencer à utiliser les deux cores pour du H.264 (et pas qu'un peu, pour le 1080p... pas encore tombé sur du 1080i qu'il faudrait en plus désentrelacer), certes...
Mais, au final, si on archive pour regarder sur le PC du salon, principal périphérique du bel écran, de toute façon, le facteur limitant au niveau de la puissance, ça me paraît plus être les résolutions croissantes auxquelles on affiche, et les traitements qui y sont liés, plutôt que le codec en lui-même...
Ma méthode est un peu différente, et pour une raison particulière : je me sers de scripts pour faire de l'encodage massivement séquentiel, d'autant de choses que j'ai besoin, et à base de petits fichiers de confs individuels, ce qu'aucune GUI ne me permet :
- rip (avec démuxage et sélection, soit des chapitres, soit d'un temps de départ et/ou d'une durée, les deux rentrant un tantinet en conflit),
- puis transcodage,
- puis multiplexage (dans du mkv, pour avoir des vobsubs et gérer proprement l'aspect ratio),
- et enfin, éventuelle mise bout à bout des fichiers mkv (appending... gare ! : tous les lecteurs ne sont pas égaux devant ça - il vaut mieux avoir le même nombre de pistes et les mêmes index de langues, sans quoi, certaines [totem... pitit-pitit-pitit] pètent un plomb)...
Du coup, je lance le script, je reste devant le temps qu'il ait tout ripé (ça peut être long, pour quelques saisons d'animes... saloperie de protection css - globalement, sur mon Q6600, qui ne tourne qu'à 80% lors de la deuxième passe, faute à yadif non multithreadé, et moins à la première, encore plus faute à yadif, vu que j'active l'option "turbo" sur le x264 sur cette passe, car ça ne change presque rien à la qualité, mais divise bien le temps de la première passe par 5, le simple rip des DVD me prend bien 20-25% du temps total), puis, je le laisse faire tout seul tout le reste.
Alors, comme je prends génériquement en compte un éventuel découpage temporel de la video (par exemple, pour virer les pub sur les rips MPEG de la TNT, ou les petits clips sur les DVD de Strip-Tease, pas du tout calés sur les chapitres - NB : gaffe avec "-ss" et "-endpos" ; il ne faut les utiliser qu'aux limites d'une frame ; et attention à "-endpos", qui est la durée de la video, et pas la position de fin, si on a défini un début avec "-ss"), je ne peux pas me servir de -dumpvideo et -dumpaudio (par contre, vobsubout marche très bien avec la découpe - avec eux, puisque je n'ai pas envie de me taper de l'OCR sur des saisons d'animes [hors de question], le problème, c'est mkvmerge, qui a le comportement idiot de les multiplexer par défaut, même quand on fait juste de l'appending, en les compressant avec zlib, ce qui n'est pas supporté par, notamment, mythvideo, le lecteur de mythtv - ce qui est très chiant, d'autant plus que pour réparer ces conneries, il faut se taper la rectification piste par piste)...
... du coup, je copie la video non transcodée avec la première piste son dans un conteneur avi, et toutes les pistes audios non transcodées qui m'intéressent, chacune dans son conteneur avi séparé, sans la video.
Pour le rip/démultiplexage, plus explicitement, pour la video :
Après, je transcode la video en gardant toujours la première piste audio (que je ne veux même pas forcément), pour qu'il ne se perde pas (j'utilise toujours au moins un "-vf softsktip,harddup", avec les éventuels filtres de désentrelacement/inversion télécine, et le cropping) ; je garde généralement la piste audio telle quelle, n'y ayant pas tant que ça à gagner de ce côté, puisque c'est déjà compressé - à la limite, si je voulais vraiment gagner de la place, je prendrais plutôt la piste 2 canaux AC3, plutôt que la 5 canaux... mais sinon, vu la taille du reste, je ne suis vraiment pas à quelques dizaines de Mio près (en H.264, je transcode avec un bitrate de référence de 2800kbps, et des bits par unité de diagonale constants, relativement à une video de 1024x576@25fps, une fois l'aspect ratio appliqué et le cropping effectué, soit grosso merdo la moitié de la taille de la video d'un DVD lambda pour du 16:9 anamorphique... ça fait gros, mais pour faire la différence avec le DVD, surtout avec deux passes et des options un peu bourrines, faut vraiment se lever tôt)...
Enfin, je multiplexe le tout (dont aussi les chapitres, que je chope avec dvdxchap, et que je charcute à-la-hard pour prendre en compte les décalages temporels s'ils ont été spécifiés), en demandant à n'avoir que la video sur le fichier .video, et itout pour le reste... et ça marche : je n'ai jamais eu de grossier décalage audio/video (il y en a toujours un peu, les chunks audio à 48kHz ne correspondant jamais à la durée des chunks video à 24/25/30000:1001fps, mais mencoder supprime/duplique des frames au besoin, pour éviter les désynchro énormes - pour voir le mini décalage au fur et à mesure des opérations, zieute sur le petit "A-V" qui a la bougeotte, à droite de la ligne qui donne le temps et les fps, dans MEncoder et MPlayer, et qui n'est pas censé dépasser la durée de deux frames video... on peux trouver plus d'explications, et notamment l'impérieux conseil de ne pas traiter la video après lui avoir fait un "-of rawvideo", dans la doc de MPlayer/MEncoder, que j'ai donnée en lien au-dessus, beaucoup plus complète que la page de manuelle, déjà vertement touffue)...
En bref, pour conclure, oui, l'archivage propre, c'est plutôt compliqué...
Le problème, c'est de savoir ce que tu appelles un bon résultat...
Ca varie déjà pas mal d'une personne à l'autre... là où beaucoup vont se satisfaire d'un transcodage avec un faible bitrate sur du MPEG4-ASF, d'autres rechigneront à transformer un MPEG-II avec moins que du MPEG4-AVC, à la moitié du bitrate d'origine, et avec une pelleté d'options qui ralentissent de beaucoup le transcodage...
Le bitrate à choisir va aussi dépendre de la résolution de la video : pour l'estimer, certains vont raisonner en bits par pixels, d'autres en bits par unité de la diagonale, ...
Tout va aussi dépendre des codecs d'origine : ce sont quoi, les codecs, dans ta video, à la base ?
Sans parler du scaling, pour fixer une bonne fois pour toutes l'aspect ratio (beurk), qu'il n'est pas possible de rentrer dans tous les conteneurs (le problème étant qu'une video scalée au transcodage, puis rescalée à l'affichage en plein écran, rendra forcément moins bien que si tout le scaling est fait à la lecture)...
Bon, si ça vient d'un appareil numérique, gageons que la video doit être progressive, donc, tu n'auras probablement pas à désentrelacer (pourquoi yadif n'est-il pas multithreadé, ô monde cruel ?) ou faire de l'inversion de telecine...
Bref, c'est tout sauf simple... surtout si tu cherches à optimiser dans le but d'archiver... Si tu veux vraiment en apprendre plus, j'insiste, mais la doc de MPlayer/MEncoder est géniale ( http://www.mplayerhq.hu/DOCS/HTML/en/index.html ), spécifiquement la section 14, et les diverses sections sur chaque codec.
> Je n'aime pas trop faire le traitement audio et vidéo chacun de leur côté, on se retrouve parfois avec des soucis de désynchro.
Virer la video d'un conteneur (typiquement MPEG ou avi), ça ne craint pas... en ne gardant que le son dans le conteneur d'origine, on garde même l'éventuel offset que le son peut avoir (par contre, si on met le son dans un conteneur qui n'est pas fait pour la video [typiquement, un dump de la piste son], pour multiplexer de nouveau plus tard, oui, là, on risque des ennuis)... Heureusement, d'ailleurs, pour faire des mkv avec plusieurs pistes audio.
... par contre, il est capital (surtout avec des codecs modernes comme MPEG4-AVc) de conserver une piste son dans le même conteneur que la video à transcoder, quitte à la copier sans y toucher, et à la virer/remplacer plus tard, au multiplexage... sans quoi, la video risque de ne plus savoir quand supprimer/ajouter des frames, puisqu'elle n'aura plus de moyen de savoir de combien elle se désynchronise du son.
> Je ne vois pas en quoi il serait moins bon que transcode sur ce plan
D'autant que mencoder dispose souvent de quelques coudées d'avance sur transcode, en matière de fonctions supportées...
... par exemple, la dernière fois que j'avais essayé transcode (ça remonte quand même), il ne supportait pas le H.264 en 2 passes...
Sinon, le transcodage est un art... et un art, ça s'apprend... Evidemment, la doc de MPlayer/MEncoder est une référence en la matière, mais on peut quand même déjà commencer par lire les pages de manuel (parce que là, tes exemples, ils sentent le copier-coller aveugle à plein nez)...
... ce qui permet par exemple d'expliquer pourquoi si on ne spécifie un codec que pour la vidéo avec "-y", on perd le son...
Ou de se dire que si on utilise cette cochonnerie de lavc, sans spécifier de lavcopts, c'est peut-être parce qu'on utilise des réglages par défaut qu'on perd ostensiblement en qualité...
> Je ne parle même pas des opérations avant ça comme le débarquement à Dieppe.
En même temps, celle-là, elle n'est pas des plus glorieuses...
Le massacre organisé, qui n'avait pas vraiment d'autre but que de faire avaler aux Soviétiques, qui commençaient à sérieusement perler du front (roooh, si on ne peut plus déconner, surtout sur les choses graves), que la création d'un autre à l'ouest, ce n'était pas possible, c'est quand même hard-à-la-South Park... Jubilee mes fesses : opération "planquez vous derrière les canadiens", oui...
... bon, ça ne retire rien à ceux qui ont eu le courage de faire cette opération... mais ils se sont sacrément fait prendre pour des cons, sur ce coup.
Pour pas trop mal connaître les plages de débarquements, aussi bien celles de 1942 que celles de 1944 (pour être originaire des unes, et avoir eu une grand-mère qui habitait à moins d'un kilomètre de ce qui fut Omaha Beach), quand on compare les deux sites (je rappelle qu'à Dieppe, c'est du gros galet - les chars adorent, il paraît... sans compter qu'elle monte dru, cette plage... qui donne par ailleurs sur un vaste champ dégagé, sans couvert), j'ai du mal à voir ceux qui ont envoyé des hommes là-bas, juste par ruse confinant à la traîtrise envers son allié, soit notamment l'état major, comme autre chose que des criminels...
... entre morts et prisonniers, même pas la moitié des Canadiens ne s'en sont sortis, ce jour-là... ~5000 Canadiens, sur ~6000 soldats, dans l'opération...
[^] # Re: Quelques idées...
Posté par Aefron . En réponse au journal 'Retiming' vidéo et logiciels libres. Évalué à 5.
Tu y trouveras notamment des exemples de "ghost frames", quand est faite une interpolation entre deux images faisant partie de deux plans différents...
... et le sacro-saint sacrement du désentrelacement selon lequel, je traduis à-la-rache :
"A cause du mélange temporel (1 image=temps1+temps2), il est impossible de :
1) désentrelacer une image
ET 2) conserver 25 images/seconde
ET 3) conserver la qualité originelle (=toute l'information d'une image)
au moins un de ces points devant être omis, sauf lorsqu'il n'y a pas de mouvement"
... chose que quiconque transcode du contenu entrelacé devrait apprendre...
Et qui permet de comprendre beaucoup de choses sur le "retiming"...
[^] # Re: Pas si mal
Posté par Aefron . En réponse au journal 'Retiming' vidéo et logiciels libres. Évalué à 2.
Cela dit, il faut récupérer le .flv, pour faire ça...
# Quelques idées...
Posté par Aefron . En réponse au journal 'Retiming' vidéo et logiciels libres. Évalué à 10.
Si l'image que tu insères se situe à un changement de scène, bonjour la casse... c'est d'ailleurs l'une des raisons qui font que je fais mes désentrelacements en utilisant la base temporelle des champs (fields, ie demi-images, typiquement décalées de 20ms, sur une video PAL à 25 images/seconde), plutôt qu'en divisant la résolution temporelle par deux (ce que font les transcodeurs crados, en général)...
En outre, selon la source de la video, même si elle ne semble que peu saccader, l'insertion d'images peut empirer la situation... je pense typiquement aux contenus télécinés (insertion de frames pour passer de 24000/1001 à 30000/1001, en NTSC) : de base, ils saccadent forcément, mais selon les scènes, on peut plus ou moins s'en rendre compte... mais en insérant des images intermédiaires, rien ne garantit forcément qu'on va améliorer les choses...
[^] # Re: La prochaine fois
Posté par Aefron . En réponse au journal Les (més) aventures d'un web spectateur sur France 5. Évalué à 5.
Sans doute, mais le principal souci, c'est le conteneur flash...
... les .flv, pas de souci, pour les lire avec Mplayer (brevets le protégeant, ou pas)...
Par contre, ces saloperies de flash qui obligent à avoir les libs 32 bits sur les OS 64 bits et qui font s'affoler mon Pentium-m 1,7GHz (pour ainsi dire à fond... et en embedded, même pas en plein écran), c'est encore la grosse loose, pour les lire - j'ai réessayé gnash l'autre jour sur ma Sid 64 bits : après avoir ouvert quelques pages qui contenaient du flash, j'ai réussi à m'en sortir en passant en tty et en faisant un bon gros killall, faute de ne serait-ce que pouvoir utiliser la souris tellement le système devenait lent...
... faut dire, c'est léger-léger, comme machine, un Q6600... bon, j'ai au moins trouvé quelque chose qui arrive à le mettre à genoux... m'enfin...
[^] # Re: La véritable raison...
Posté par Aefron . En réponse au journal Adieu les écrans normaux. Évalué à 1.
Oui, je ----->[]
[^] # Re: Pas vraiment
Posté par Aefron . En réponse au journal Ubuntu pas très sécurisée.... Évalué à 4.
C'est pour ça que je les dresse au combat !
... bon, d'accord : c'est aussi parce que, vu qu'ils ne sauraient s'imaginer comme autre chose que des collocs, il serait intolérable qu'en échange de la bouffe et cie, ils soient incapables de m'amuser. Non, mais...
[^] # Re: Pas vraiment
Posté par Aefron . En réponse au journal Ubuntu pas très sécurisée.... Évalué à 9.
Et encore... ça ne te protège pas forcément d'un leurre...
... mettons que tu ne te trimballes pas le /boot sur toi (par exemple, sur une clé USB), mais qu'il est sur la machine, en clair, prêt à se faire tirer comme un lapin... et que ton initrd te demande un mot de passe pour débloquer les partitions autres que /boot...
Maintenant, imaginons qu'une personne mal intentionnée avec un accès physique à la machine ait remplacé ton disque dur (qu'elle a emporté avec elle) par un autre contenant un initrd de même apparence, qui va te demander un mot de passe de la même manière, mais sera configurée pour dumper le mot de passe dans un fichier ou sur le réseau, et te dire que, pas de bol, quel qu'il soit, le mot de passe est bon, mais que les partitions chiffrées sont corrompues...
... et paf... ton disque est entre les mains de quelqu'un d'autre, et le mot de passe pour le débloquer aussi, si le fichier a été dumpé sur le réseau (en mettant ce qu'il faut dans l'initrd aussi)... ou au pire, pendant que tu es parti sur une autre machine télécharger une distro ou choper tes sauvegardes pour réinstaller, le margoulin n'a qu'à passer récupérer le passe dumpé localement...
Alors, OK, on pourrait imaginer booter sur un autre OS, sur support externe, et vérifier le hash du /boot local avant de faire quoi que ce soit (m'enfin, à ce compte, autant mettre dès le départ le /boot sur un périph externe)...
Mais la parano, c'est sans fin (parce que bon, après, qu'est-ce qui empêche de se méfier du matériel lui-même, outre ce qui est installé dessus ?)... et à un certain stade, protéger physiquement la machine (portes et fenêtres, voire aération, que même les pompiers ou le GIGN auraient du mal à ouvrir, pas de réseau, isolation électromagnétique, hordes barbares de mercenaires pour te protéger, ...), c'est peut-être encore ce qu'il y a de plus "direct". La sécurité, notamment en informatique, c'est une notion relative, pas absolue.
[^] # Re: Les titres c'est nul
Posté par Aefron . En réponse au journal Comment je contribue moi aussi au Libre. Évalué à 4.
[^] # Re: Utilisations possibles de Nestor
Posté par Aefron . En réponse au journal Nestor, serveur domestique. Évalué à 2.
... pour les binaires, par contre, non, c'est très large... même en mettant chaque service dans un conteneur (une sorte de super-chroot, qui fait que la base du système est répliquée dans chaque "machine"), il y a de quoi en mettre des tonnes...
... à la limite, ce qui risque de prendre de la place, ce sont les logs, les éventuels caches, et basta. Le reste, c'est peanuts.
En comptant tout (un petit "du -h"), mon plus gros conteneur, c'est MythTV (~1Gio), et le plus petit, le serveur à SSHFS (~300Mio)... ça fait de la très grosse marge, 60Gio... et ce sont des install de Debian pour lesquelles je n'ai rien fait de particulier afin qu'elles soient légères en place. Il y a moyen de grave gagner en optimisant.
[^] # Re: Vendre, encaisser, etc
Posté par Aefron . En réponse au journal Attention aux fausses offres "+XX gratuit" chez Auchan. Évalué à 3.
... bon, après... si on était censés ne pas ignorer toutes les lois, règlements, et cie (qu'on m'ait dit ou non des conneries pendant le code), les femmes n'auraient pas le droit de "s'habiller en hommes" (si ce verbiage avait un sens)...
[^] # Re: Vendre, encaisser, etc
Posté par Aefron . En réponse au journal Attention aux fausses offres "+XX gratuit" chez Auchan. Évalué à 2.
... bon, maintenant, ce n'est pas parce que c'était censé être la loi que c'était appliqué...
... regarde la loi Evin... pas neuf... et pourtant, ça n'empêche pas de faire du doublon...
[^] # Re: Mais euh !!
Posté par Aefron . En réponse au journal Attention aux fausses offres "+XX gratuit" chez Auchan. Évalué à 6.
... ou que le coupable d'une attaque fécale grave n'ait pas laissé des bouts de sa vidange au fond du chiotte...
C'est triste à dire, mais je connais des gens qui ont des chiottes tellement sales qu'ils ne les nettoient que toutes les quelques années... à l'acide ou à la soude, forcément... du coup, comme leurs gogues puent la mort (enfin, la macro-mort... au niveau microscopique, ça doit grouiller ferme), ils vaporisent des trucs qui sentent la fleur...
... et n'ayant aucune envie de nettoyer leurs trônes à leur place, même si j'ai horreur des odeurs florales, je prends sincèrement ça comme un moindre mal... il m'est d'ailleurs arrivé chez l'un d'eux de vaporiser de son pschit' directement en entrant dans ses "toilettes", faute de quoi, j'eu été contraint de rapprocher ma tête de la cuvette pour y vomir tripes et boyaux...
Je frémis encore rien qu'à penser au dévidoir de mon correspondant d'Albion, au collège, dans lequel l'absence de brosse à chiotte m'a pour le moins laissé perplexe...
[^] # Re: Vendre, encaisser, etc
Posté par Aefron . En réponse au journal Attention aux fausses offres "+XX gratuit" chez Auchan. Évalué à 4.
... vu que je venais de dépasser la sortie pour les Mureaux (et moi qui venait d'hésiter à m'arrêter pour passer voir un pote, et que je m'étais dit que, de toute façon, je le verrais quelques jours plus tard, à Rouen, où il devait passer...), soit j'attendais la prochaine aire, soit au moins quinze-vingt bornes, ou alors je m'arrêtais dans une montée/descente, mais de toute façon, à un endroit où il y avait du virage (il n'y a à peu près que ça dans le coin)...
Etant donnée la circulation qu'il y a sur cette route de psychopates en furie, j'ai choisi de ne pas laisser l'entropie croître jusqu'à ce que mon coffre se déverse sur la voie, et de m'arrêter le plus vite possible pour fermer cette saloperie de coffre... donc, dans une descente, avec du virage, sur la minuscule bande d'arrêt d'urgence (enfin, en tout cas, quand des camions passent à côté de toi à 150km/h, elle fait 'achement petite, la bande)...
J'ai réglé mon problème (du givre avait fait que je n'avais pas fait attention en partant de Versailles à ce que mon coffre était mal fermé... mea putana culpa) en quelques secondes, et zou...
Bon, j'avais un triangle (d'ailleurs, faudra m'expliquer en quoi c'est nouveau qu'il faut en avoir un : j'ai passé mon code en 1995, et je suis sûr que c'est à cette époque que j'ai appris qu'il était obligatoire d'en avoir un ; le truc avec des bandes jaunes était juste recommandé, par contre, avant les directives européennes), mais franchement, dans mon cas (je ne généralise pas : je relativise), de toute façon, la chose la plus sûre était de faire au plus vite, en faisant preuve d'une attention maximale...
... et au fond, c'est ça, qu'on devrait obliger les gens à prendre sur eux : de l'attention maximale... à la limite, avec des bandes jaunes réfléchissantes collées dessus, voire un masque d'halloween, ou une plume dans les fesses, pour ceux qui aiment... m'enfin...
[^] # Re: Achat
Posté par Aefron . En réponse au journal AMD Catalyst 8.8. Évalué à 5.
Pour faire du tri-écran avec deux GPU ?
... hein ? Comment ? Ca ne marche plus depuis RandR 1.2 ? ... arf... bon, tant pis... plus qu'à attendre X.org 7.5 ou 7.6... :(
[^] # Re: Contre-exemple
Posté par Aefron . En réponse au journal Attention aux fausses offres "+XX gratuit" chez Auchan. Évalué à 6.
Euh... strictement rien à voir : http://fr.wikipedia.org/wiki/Roms ...
... rah... ces gadjé... ;)
[^] # Re: Domogik
Posté par Aefron . En réponse au journal Nestor, serveur domestique. Évalué à 3.
... bon, maintenant, X10, c'est quand même assez foireux... par exemple, ça ne passe pas les disjoncteurs différentiels et choses du genre... du coup, pas d'accès aux salles d'eau, ni à l'éclairage principal, dans les logements récents, à moins de mettre des coupleurs sur le tableau électrique... sans compter un fonctionnement des plus erratiques, pour ce que j'en ai vu chez un pote qui a acheté quelques modules... par contre, ça marche sous Linusque.
Dommage, car j'aimerais bien au moins gérer l'éclairage du salon, automatiquement, en fonction du media que j'y passe (TV => pas mal de lumière ; Film => peu de lumière ; Zique => entre-deux)... ou, soyons fous, gérer le chauffage, en prenant en compte des infos venant de stations météo, pour optimiser... ou encore, gérer l'arrosage des plantes... ou même, braquer une webcam sur les plaques de cuisson et le four pour voir où la pitance en est, et les arrêter/booster au besoin, pendant que je déguste ma Chimay dans le salon...
Faire des stats sur la conso électricité/eau/gaz serait aussi moult top... je crois que EDF&cie mène des expérimentations avec une box, et Poweo en propose une (avec abonnement) à connecter au net, qui va envoyer les stats sur leur site, d'où on pourra les consulter.
Sinon, apparemment la mode serait plutôt au bus KNX, mais il faut tirer des câbles, il me semble...
Bon, autrement, serveur "domotique", pour ce qui est des media, j'ai déjà depuis quelques années, avec MythTV (pour le salon, le bureau, et le laptop) et SlimServer (pour le radio-réveil), plus un MPD, sur le HTPC du salon (même si je m'en sers peu), et ça roxe. Il y a aussi d'autres mignonneries (fichiers, imprimantes, scanner, P2P, mail, jabber...), le tout sur deux machines, chaque service dans son conteneur (VServer et OpenVZ... je compte passer la première machine sur OpenVZ aussi - en plus, c'est cool : Sid propose maintenant un 2.6.26 avec OpenVZ intégré ; ça fleure bon pour l'avenir)...
... maintenant, un truc où ce sont les machines clientes qui vont aller trifouiller les serveurs, pourquoi pas, mais sans moi... je suis bien trop parano, et j'aime bien trop mettre les mains dans le camboui pour ça.
En fait, mon but secret serait de transformer mon habitat en PC géant, dont je serais le principal bug :) Hein ? Arf, damnaide... ce n'est plus un secret, maintenant...
[^] # Re: x264
Posté par Aefron . En réponse au journal Quelle est la meilleure méthode pour compresser des fichiers AVI .... Évalué à 3.
Plus ça va, plus les résolutions auxquelles on affiche vont aller vers le 1080p (au moins)... et on n'est pas près d'avoir du progressif pour la plupart des broadcast, ce qui fait qu'il faut aussi désentrelacer...
Sur ma TV Full-HD, scaler un MPEG II sans désentrelacer bouffe dans les 10% d'un core de mon E4500... un petit coup de yadif 2x pour désentrelacer et que ça ait une bonne gueule, et paf : 60-75% d'un des cores...
A côté, scaler un H.264 en 576p, ça me bouffe entre 20 et 30% d'un des cores... et pas besoin de désentrelacer...
Pour ce qui est de scaler du 720p ou d'afficher du 1080p, là, il faut commencer à utiliser les deux cores pour du H.264 (et pas qu'un peu, pour le 1080p... pas encore tombé sur du 1080i qu'il faudrait en plus désentrelacer), certes...
Mais, au final, si on archive pour regarder sur le PC du salon, principal périphérique du bel écran, de toute façon, le facteur limitant au niveau de la puissance, ça me paraît plus être les résolutions croissantes auxquelles on affiche, et les traitements qui y sont liés, plutôt que le codec en lui-même...
[^] # Re: Si si, avec uniquement transcode ou mencoder c'est faisable.
Posté par Aefron . En réponse au journal Quelle est la meilleure méthode pour compresser des fichiers AVI .... Évalué à 2.
[^] # Re: Si si, avec uniquement transcode ou mencoder c'est faisable.
Posté par Aefron . En réponse au journal Quelle est la meilleure méthode pour compresser des fichiers AVI .... Évalué à 6.
- rip (avec démuxage et sélection, soit des chapitres, soit d'un temps de départ et/ou d'une durée, les deux rentrant un tantinet en conflit),
- puis transcodage,
- puis multiplexage (dans du mkv, pour avoir des vobsubs et gérer proprement l'aspect ratio),
- et enfin, éventuelle mise bout à bout des fichiers mkv (appending... gare ! : tous les lecteurs ne sont pas égaux devant ça - il vaut mieux avoir le même nombre de pistes et les mêmes index de langues, sans quoi, certaines [totem... pitit-pitit-pitit] pètent un plomb)...
Du coup, je lance le script, je reste devant le temps qu'il ait tout ripé (ça peut être long, pour quelques saisons d'animes... saloperie de protection css - globalement, sur mon Q6600, qui ne tourne qu'à 80% lors de la deuxième passe, faute à yadif non multithreadé, et moins à la première, encore plus faute à yadif, vu que j'active l'option "turbo" sur le x264 sur cette passe, car ça ne change presque rien à la qualité, mais divise bien le temps de la première passe par 5, le simple rip des DVD me prend bien 20-25% du temps total), puis, je le laisse faire tout seul tout le reste.
Alors, comme je prends génériquement en compte un éventuel découpage temporel de la video (par exemple, pour virer les pub sur les rips MPEG de la TNT, ou les petits clips sur les DVD de Strip-Tease, pas du tout calés sur les chapitres - NB : gaffe avec "-ss" et "-endpos" ; il ne faut les utiliser qu'aux limites d'une frame ; et attention à "-endpos", qui est la durée de la video, et pas la position de fin, si on a défini un début avec "-ss"), je ne peux pas me servir de -dumpvideo et -dumpaudio (par contre, vobsubout marche très bien avec la découpe - avec eux, puisque je n'ai pas envie de me taper de l'OCR sur des saisons d'animes [hors de question], le problème, c'est mkvmerge, qui a le comportement idiot de les multiplexer par défaut, même quand on fait juste de l'appending, en les compressant avec zlib, ce qui n'est pas supporté par, notamment, mythvideo, le lecteur de mythtv - ce qui est très chiant, d'autant plus que pour réparer ces conneries, il faut se taper la rectification piste par piste)...
... du coup, je copie la video non transcodée avec la première piste son dans un conteneur avi, et toutes les pistes audios non transcodées qui m'intéressent, chacune dans son conteneur avi séparé, sans la video.
Pour le rip/démultiplexage, plus explicitement, pour la video :
mencoder dvd://${TITLES} ${CHAPTERS_PARAM} ${START_POS_PARAM} ${DURATION_PARAM} -oac copy -ovc copy -o "${TO_ENCODE_FILES}/${NAME}.video"
et pour l'audio :
mencoder dvd://${TITLES} ${CHAPTERS_PARAM} ${START_POS_PARAM} ${DURATION_PARAM} -aid "${AID}" -oac copy -ovc frameno -o "${TO_ENCODE_FILES}/${NAME}.${AID}.audio"
Après, je transcode la video en gardant toujours la première piste audio (que je ne veux même pas forcément), pour qu'il ne se perde pas (j'utilise toujours au moins un "-vf softsktip,harddup", avec les éventuels filtres de désentrelacement/inversion télécine, et le cropping) ; je garde généralement la piste audio telle quelle, n'y ayant pas tant que ça à gagner de ce côté, puisque c'est déjà compressé - à la limite, si je voulais vraiment gagner de la place, je prendrais plutôt la piste 2 canaux AC3, plutôt que la 5 canaux... mais sinon, vu la taille du reste, je ne suis vraiment pas à quelques dizaines de Mio près (en H.264, je transcode avec un bitrate de référence de 2800kbps, et des bits par unité de diagonale constants, relativement à une video de 1024x576@25fps, une fois l'aspect ratio appliqué et le cropping effectué, soit grosso merdo la moitié de la taille de la video d'un DVD lambda pour du 16:9 anamorphique... ça fait gros, mais pour faire la différence avec le DVD, surtout avec deux passes et des options un peu bourrines, faut vraiment se lever tôt)...
Enfin, je multiplexe le tout (dont aussi les chapitres, que je chope avec dvdxchap, et que je charcute à-la-hard pour prendre en compte les décalages temporels s'ils ont été spécifiés), en demandant à n'avoir que la video sur le fichier .video, et itout pour le reste... et ça marche : je n'ai jamais eu de grossier décalage audio/video (il y en a toujours un peu, les chunks audio à 48kHz ne correspondant jamais à la durée des chunks video à 24/25/30000:1001fps, mais mencoder supprime/duplique des frames au besoin, pour éviter les désynchro énormes - pour voir le mini décalage au fur et à mesure des opérations, zieute sur le petit "A-V" qui a la bougeotte, à droite de la ligne qui donne le temps et les fps, dans MEncoder et MPlayer, et qui n'est pas censé dépasser la durée de deux frames video... on peux trouver plus d'explications, et notamment l'impérieux conseil de ne pas traiter la video après lui avoir fait un "-of rawvideo", dans la doc de MPlayer/MEncoder, que j'ai donnée en lien au-dessus, beaucoup plus complète que la page de manuelle, déjà vertement touffue)...
En bref, pour conclure, oui, l'archivage propre, c'est plutôt compliqué...
[^] # Re: Réponses
Posté par Aefron . En réponse au journal Quelle est la meilleure méthode pour compresser des fichiers AVI .... Évalué à 4.
Ca varie déjà pas mal d'une personne à l'autre... là où beaucoup vont se satisfaire d'un transcodage avec un faible bitrate sur du MPEG4-ASF, d'autres rechigneront à transformer un MPEG-II avec moins que du MPEG4-AVC, à la moitié du bitrate d'origine, et avec une pelleté d'options qui ralentissent de beaucoup le transcodage...
Le bitrate à choisir va aussi dépendre de la résolution de la video : pour l'estimer, certains vont raisonner en bits par pixels, d'autres en bits par unité de la diagonale, ...
Tout va aussi dépendre des codecs d'origine : ce sont quoi, les codecs, dans ta video, à la base ?
Sans parler du scaling, pour fixer une bonne fois pour toutes l'aspect ratio (beurk), qu'il n'est pas possible de rentrer dans tous les conteneurs (le problème étant qu'une video scalée au transcodage, puis rescalée à l'affichage en plein écran, rendra forcément moins bien que si tout le scaling est fait à la lecture)...
Bon, si ça vient d'un appareil numérique, gageons que la video doit être progressive, donc, tu n'auras probablement pas à désentrelacer (pourquoi yadif n'est-il pas multithreadé, ô monde cruel ?) ou faire de l'inversion de telecine...
Bref, c'est tout sauf simple... surtout si tu cherches à optimiser dans le but d'archiver... Si tu veux vraiment en apprendre plus, j'insiste, mais la doc de MPlayer/MEncoder est géniale ( http://www.mplayerhq.hu/DOCS/HTML/en/index.html ), spécifiquement la section 14, et les diverses sections sur chaque codec.
[^] # Re: Si si, avec uniquement transcode ou mencoder c'est faisable.
Posté par Aefron . En réponse au journal Quelle est la meilleure méthode pour compresser des fichiers AVI .... Évalué à 6.
Virer la video d'un conteneur (typiquement MPEG ou avi), ça ne craint pas... en ne gardant que le son dans le conteneur d'origine, on garde même l'éventuel offset que le son peut avoir (par contre, si on met le son dans un conteneur qui n'est pas fait pour la video [typiquement, un dump de la piste son], pour multiplexer de nouveau plus tard, oui, là, on risque des ennuis)... Heureusement, d'ailleurs, pour faire des mkv avec plusieurs pistes audio.
... par contre, il est capital (surtout avec des codecs modernes comme MPEG4-AVc) de conserver une piste son dans le même conteneur que la video à transcoder, quitte à la copier sans y toucher, et à la virer/remplacer plus tard, au multiplexage... sans quoi, la video risque de ne plus savoir quand supprimer/ajouter des frames, puisqu'elle n'aura plus de moyen de savoir de combien elle se désynchronise du son.
[^] # Re: Réponses
Posté par Aefron . En réponse au journal Quelle est la meilleure méthode pour compresser des fichiers AVI .... Évalué à 5.
D'autant que mencoder dispose souvent de quelques coudées d'avance sur transcode, en matière de fonctions supportées...
... par exemple, la dernière fois que j'avais essayé transcode (ça remonte quand même), il ne supportait pas le H.264 en 2 passes...
Sinon, le transcodage est un art... et un art, ça s'apprend... Evidemment, la doc de MPlayer/MEncoder est une référence en la matière, mais on peut quand même déjà commencer par lire les pages de manuel (parce que là, tes exemples, ils sentent le copier-coller aveugle à plein nez)...
... ce qui permet par exemple d'expliquer pourquoi si on ne spécifie un codec que pour la vidéo avec "-y", on perd le son...
Ou de se dire que si on utilise cette cochonnerie de lavc, sans spécifier de lavcopts, c'est peut-être parce qu'on utilise des réglages par défaut qu'on perd ostensiblement en qualité...
[^] # Re: Debian on the FreeRunner -- now official
Posté par Aefron . En réponse au journal Debian day !. Évalué à 2.
... ce qui fait qu'il y a de très grandes chances qu'ils respectent les DFSG... et donc, qu'ils finissent par rejoindre Debian...
... enfin, j'ose espérer.
[^] # Re: Debian on the FreeRunner -- now official
Posté par Aefron . En réponse au journal Debian day !. Évalué à 3.
[^] # Re: Les bonnes raisons
Posté par Aefron . En réponse au journal [HS] Les russes se foutent de nous ?. Évalué à 6.
En même temps, celle-là, elle n'est pas des plus glorieuses...
Le massacre organisé, qui n'avait pas vraiment d'autre but que de faire avaler aux Soviétiques, qui commençaient à sérieusement perler du front (roooh, si on ne peut plus déconner, surtout sur les choses graves), que la création d'un autre à l'ouest, ce n'était pas possible, c'est quand même hard-à-la-South Park... Jubilee mes fesses : opération "planquez vous derrière les canadiens", oui...
... bon, ça ne retire rien à ceux qui ont eu le courage de faire cette opération... mais ils se sont sacrément fait prendre pour des cons, sur ce coup.
Pour pas trop mal connaître les plages de débarquements, aussi bien celles de 1942 que celles de 1944 (pour être originaire des unes, et avoir eu une grand-mère qui habitait à moins d'un kilomètre de ce qui fut Omaha Beach), quand on compare les deux sites (je rappelle qu'à Dieppe, c'est du gros galet - les chars adorent, il paraît... sans compter qu'elle monte dru, cette plage... qui donne par ailleurs sur un vaste champ dégagé, sans couvert), j'ai du mal à voir ceux qui ont envoyé des hommes là-bas, juste par ruse confinant à la traîtrise envers son allié, soit notamment l'état major, comme autre chose que des criminels...
... entre morts et prisonniers, même pas la moitié des Canadiens ne s'en sont sortis, ce jour-là... ~5000 Canadiens, sur ~6000 soldats, dans l'opération...