Bon, juste pour dire, au cas où ça servirait à quelqu'un qui chercherait comment faire via gogole, ce qui merde avec le dumpstream de MPlayer, ce sont des pistes DVD que je souhaite retailler (avec "-ss")...
... le problème, c'est que le PTS (indicateur du temps dans les vob) est remis à zéro à chaque chapitre... rendant impossible la navigation via "-ss" (ça ne marche pas non plus avec un fichier opendml)... et que je considère l'option "-sb" (découpe en fonction du nombre d'octets) comme radicalement chiante...
...et comme dumpstream n'est pas capable de découper les chapitres dans un titre, c'est la loose... du coup, c'est pour ça que je fais à la mimine via tccat... sauf que tccat ne dumpe pas les vobsub (ce qui _peut_ être gênant, mais dont, pour le coup, sur ces DVD, je me fous), comme le fait le dumpstream de MPlayer, qui n'est pas foireux comme j'ai écrit au-dessus, mais au contraire, presque trop fidèle (mea culpa : par contre, les éditeurs de DVD qui font du PTS reset, gare à eux si j'en chope un, un de ces jours... j'avais entendu parler que ça existait sur les DVD, mais je n'en avais encore jamais vu... jusqu'à ce que je réalise que j'en avais en fait en voulant retailler au début des chapitres)...
Bon, ce qui m'aurait arrangé, c'est que le dumpstream de MPlayer soit capable de découper les chapitres dans un titre... mais à l'heure actuelle, c'est impossible. Voilà, en espérant que ça serve à quelqu'un un de ces quatre...
Addendum : cela dit, il est pour le moins cocasse de ne pas avoir de plugin proprio 64 bits, lors-même que les processeurs uniquement capables de faire du 32 bits sont vraiment limités au niveau puissance pour lire du flash, fût-ce seulement en "embedded"...
... raison de plus pour ne même pas prendre la peine de faire un effort pour supporter ce format foireux.
Bah, en fait, il y a une "feature cachée" dans Debian, pour l'anti-flash ;)
Quand tu demandes des partitions séparées pour tout (/boot, /, /usr, /var, /tmp, /home, swap), sur une distro 64 bits (sur laquelle tu peux quand même installer le blob userland), en faisant venir les libs 32 bits, à l'installation de cet ignoble machin, tu finis vite par remplir le tout petit / par défaut... ce qui peux vite te mettre dans le caca...
... ce qui a au moins le mérite de pointer du doigt le fait que devoir rajouter autant de choses pour avoir un support mixte 32/64 bits, pour une cochonnerie comme flash (seule raison qui m'y poussait), ça n'en vaut vraiment pas la peine.
Par contre, les plugins libres, j'ai encore de gros problèmes, avec... je n'ai pas utilisé swfdec depuis un moment, mais gnash a réussi à faire freezer le clickodrome sur ma Sid, avec un quad-core (Q6600), l'autre jour... j'ai in-extremis réussi à reprendre la main en passant en tty (la souris ne fonctionnait plus, tellement tout était lent... pour tout dire, même les tty étaient lents comme la mort)...
Du coup, vu que j'ai mis le partitionnement séparé par défaut sur la seule machine où j'installais flash de temps en temps (ma workstation, sur laquelle je fais des trucs plus intenses que sensibles), et bien, maintenant je m'abstiens, et ça me va très bien... surtout vu les conneries qu'on trouve en flash (pubs, jackasseries, polémiques-alakon, ...) : je peux aisément m'en passer...
... au pire, si je veux mâter du flash proprio, j'ai toujours une Wii proprio, avec son Opera proprio, équipé d'un plugin flash proprio... les cochonneries ensemble, c'est plus sain :D
Sinon, si ça t'intéresse, il y a un test statique (dommage, car c'est toujours mieux en voyant une suite d'images) sur guru.multimedia [1]
Pour le mcdeint, il segfaulte aussi chez moi avec le 2 et le 3... par contre, je le mets toujours, en "mcdeint=0" (soit "-vf crop=w:h:x:y,yadif=1,mcdeint=0,harddup"), car j'ai pu remarquer que certains contenus pauvrement entrelacés (DVD du commerce... arf...) présentaient moins d'artefacts avec lui. Je ne me rappelle plus de pourquoi je n'utilise pas le mcdeint=1, par contre (mais je crois que c'est parce que je ne voyais pas d'amélioration flagrante pour une grosse pénalité de vitesse)...
En fait, ces artefacts se traduisent par des "points blancs" qui apparaissent en certains endroits de l'image (surtout visibles sur les contours des animes avec "crayonné" épais, comme Futurama ou les Simpson).
mcdeint ne les élimine pas toujours complètement, mais j'ai pu remarquer à plusieurs occasions qu'il les atténuait considérablement... donc, je l'utilise...
En outre, mcdeint me pénalise surtout sur la première passe de mes transcodages, durant lesquels x264 charge moins le processeur, car j'utilise l'option turbo qui désactive plein de choses gourmandes comme le gros trellis & cie, sans pénaliser la qualité finale... mais pour la deuxième passe, les options que j'utilise avec x264 sont tellement intenses que, de toute façon...
Et puis bon, c'est la machine qui travaille, pas moi :p ... ce qui me fait d'ailleurs penser qu'il faut que je reprenne mes scripts d'automatisation pour abandonner le rip avec mplayer et son dumpstream foireux sauf le "dumpvosub", excellent quant à lui, et pourtant taggé comme du code beta... ce que j'ai du mal à saisir), qui merde avec mes DVD de Strip-Tease (l'émission France 3-RTBF, hein...), pour lui préférer tccat, avec lequel je n'ai aucun souci... par contre, pour le transcodage, MEncoder roxorise !
Ce n'est peut-être pas la FSF qui a lancé le projet, mais Stallman (président de la fondation... même s'il n'engage pas forcément la fondation dans tout ce qu'il dit) y est tout sauf étranger.
Leur site est toujours down, mais sur la page wikipedia [1], il y est fait allusion à la dérivation de cette distro du projet gnubuntu, lui-même faisant suite à une discussion entre Stallman et Shuttleworth...
Et puis, le projet, elle le soutient... ça fait une occasion d'avoir une distro qui respecte vraiment ses positions...
Quant à Shuttleworth, après tout le trollage sur le mépris du libre par sa distro, y accoler le nom de son simili-fork lui fait une bonne pub rédemptrice...
N'en reste pas moins que, à titre purement personnel, je considère bien plus les phares du libres comme étant OpenBSD et Debian... et les voir considérées comme non libres (bon, encore, pour Debian, avec "non-free", dans lequel il y a d'ailleurs la doc d'emacs [ahemmm]... mais pour OpenBSD ?!?!?! Le apt de gnewsense aurait-il des anti-corps-anti-libres qui l'immuniserait contre les vilains paquets, contrairement aux ports BSDiens [dérision, je précise... au cas où] ?), alors qu'est mis en avant ce machin, qui relève plus du troll pour se faire mousser que d'autre chose, oui, ça me fait mal au cul... enfin, ça participe surtout à ce que la FSF, je ne lui accorde qu'une crédibilité et une honnêteté intellectuelle de plus en plus limitées (je ne me prononcerai même pas sur ce que je pense de canonical).
gnewsense, même si elle a au moins le bon goût de pointer du doigt des choses dérangeantes (comme la non liberté de certains trucs dans glx), sur le fond, je vois ça comme un trollo-buzz-marketing, non dénué de mépris... comme ubuntu, quoi...
Et si quelqu'un se met à créer un dépôt non-free pour cette distro, un peu à la manière de Debian-multimedia, pour qui se fait ailleurs (oui, ce serait con... mais qu'est-ce qui l'empêche) ?
... et encore... certains dépôts, comme celui de slimdevices.com, pour installer le SqueezeCenter des SqueezeBox, fonctionnent sur tout ce qui se base sur les deb... et pourtant, il y a des tas de trucs non libres dedans (les firmwares des boxes, des polices, ...)... les dépôts non libres pour lesquels tu dis qu'il n'y a aucun moyen, bah, ils existent déjà, que ça plaise ou pas ; et j'imagine qu'ils marchent aussi sur cette distro.
Lorsqu'on arrive sur la page de téléchargement du SqueezeCenter [http://wiki.slimdevices.com/index.php/DebianPackage], on peut lire "This package also should work with most Debian-based Linux distributions" ("Ce paquet devrait aussi fonctionner avec la plupart des distributions basées sur Debian")... si on rajoute ce dépôt sur gnewsense, ça ne va pas transformer le paquet en quelque chose de libre pour autant...
... la seule chose que je vois pour contrer ça, ce serait de modifier aptitude/dpkg pour n'accepter que ce qui est signé par eux... ce qui serait assez dommage, entre autres pour ceux qui se font aussi leurs propres paquets, notamment de trucs libres.
> Il serait grand temps que Debian remette en question sa politique de release
Comme la sortie d'un noyau EtchAndAHalf ? ... plus récent que celui de base, pour ceux qui auraient besoin d'un support de matériel plus récent (faut avouer que le 2.6.18 ne peut pas prendre en charge moult contrôleurs qu'on trouve maintenant sur les mobos)... peut-être tardif, mais au moins, c'est vivant : la preuve, ça évolue dans le bon sens...
... n'en reste pas moins qu'ils ne t'ont pas attendu pour ça.
Bon, ça n'empêche pas de critiquer constructivement, hein : personnellement, j'aimerais bien voir TOUT ce qui apporte du nouveau support matériel dans AndAHalf (backends CUPS, SANE, lcdproc, drivers X.org, ...), pour ceux qui veulent ou en ont besoin. Maintenant, je ne suis pas non plus pressé, ni obsessivement exigeant, au point de faire un caca nerveux.
> Je serais quand même curieux d'avoir une idée du nombre de gens qui n'utilisent que stable/main, sans backports, dépots non-officiels, ou non-free
Personnellement, des Debian, j'en ai des stables, des testings et des Sid... plusieurs dizaines, @home, entre autres grâce à la magie des conteneurs...
Je n'utilise "non-free" nulle part (à part sur une seule des machines, de temps en temps, pour voir du flash, que j'installe au besoin... m'enfin, ça fait des mois que je ne l'ai pas remis, et ça ne me coûte en rien... vraiment en rien... ras-le-derche, de cette saloperie de flash : vraiment)...
... et qu'ai-je comme dépôts tiers, sinon ?
- Debian-multimedia, sur les machines "desktop", et sur un conteneur VServer avec MythTV ;
- slimdevices.com, pour le Squeezecenter qui pilote mon radio-réveil, lui aussi dans un conteneur VServer ;
- openvz.org, pour la machine sur laquelle je teste OpenVZ... mais plus pour longtemps, vu qu'un kernel binaire le supportant vient de rejoindre Lenny ;
Sorti de ça, tous mes autres serveurs (quelques dizaines) sont en Debian stable... avec uniquement des dépôts officiels ; et c'est bien parce que je n'ai rien besoin d'autre, et que c'est stable (!=fiable... mais c'est très fiable aussi) pendant longtemps.
Si Debian se mettait à faire des upgrades foireux tous les 6 mois, crois-le bien : je serais embêté.
En attendant, si certains trouvent l'herbe plus verte ailleurs, tant mieux pour eux... je suis allé voir par curiosité il y a quelques mois, et je suis revenu au pas de course ; notamment parce que c'est au fond la distro que je préfère, mais aussi parce qu'elle fonctionne très bien (je pourrais troller sur PackageKit qui a mis trois jours avant d'exploser dans la Fedora que j'ai testée, ou sur d'autres distros... mais sur le fond, je m'en fous pas mal).
apt le fais aussi, maintenant, avec l'autoremove... mais aptitude est la manière de faire qui est recommandée officiellement : il me semble que c'est entre autres, non seulement parce qu'il gère mieux les dépendances qu'apt (algo différent), mais aussi parce qu'il ne partage pas la même base de données de dépendances qu'apt (mais je ne suis pas plus sûr que ça)...
... quant aux bidule-bin & cie, si tu es allé les chercher à la main après l'installation d'un paquet, c'est qu'ils n'en dépendent pas et/ou que tu as désactivé les "recommends" (pas du luxe sur un serveur... pas vraiment utile sur une workstation), et ils ne seront alors pas marqués comme automatiquement installés, et ne seront donc a priori pas désinstallés quand tu désinstalles bidule...
... quand tu fais un "aptitude search", la ligne commence par des lettres : "i" si le paquet est installé, à côté d'un "A", s'il a été installé automatiquement (dépendance, recommandation, ...)...
S'il n'y a pas le "A", il faudra a priori les désinstaller manuellement... Des fois, c'est douteux, comme les l10n et autres, mais là, c'est du ressort du choix des mainteneurs plutôt que d'autre chose...
> Je ne comprends pas comment des basses ne peuvent pas être reproduite correctement sur un CD.
La dynamique d'un CD, c'est limité... surtout dans le cas d'une musique complexe comme le metal. Il faut donc bien faire des choix, et souvent, les basses se retrouvent downmixées. Et dans certains cas, c'est un peu à l'extrême, comme dans celui de Cannibal Corpse : avec eux, en concert, rien à voir avec les CD.
> Et coté chaine hifi, tu as de quoi bien descendre dans les basses ?
Un Q200E de chez Rel, en caisson de basses, ça t'ira ?
Non, de ce côté-là, je t'assure qu'il n'y a pas de souci ;)
Le problème de leurs CD c'est vraiment un gros down-mixage de la basse (comme relativement souvent dans le metal, malheureusement... les CD a aussi ses limites, et ce genre de zique les met en évidence)...
... on l'entend, hein (j'ai beau avoir fait quelques répets de Death sans bouchons, ça va, je n'ai presque rien perdu, comme j'ai pu le vérifier à la médecine du travail... même si ça a sifflé quelques fois)... mais ça pourrait être bien mieux.
Par rapport à quand je les ai vus (notamment à Madrid... dans... une salle de cours de Flamenco, dans laquelle ont lieu la plupart des concerts metal de cette ville), ça change tout... en live, leur son est vraiment orgiaque (encore plus qu'en CD) !
> Les musiciens mettent fort car ils sont devenus sourds ?
Les musiciens, ils entendent et écoutent surtout le son des retours qui sont braqués sur eux...
... avec une batterie qui te gueule juste à côté dans les oreilles, oreilles que ceux qui ne sont pas complètement dingues protègent donc avec des bouchons, de toute façon, sans retours, le son ultra-fort vers le public, tu ne l'entends pas bien, sur scène, hein,...
Par contre, personnellement, quand les réglages sont bien faits, dans un lieu à l'acoustique décente, ce qui est très rare (ça ne me viendrait pas à l'idée d'aller écouter un concert dans un stade, qu'il soit couvert ou pas), j'apprécie du bon gros son (avec des bouchons d'oreilles, faits pour moi sur moulage)... surtout sur de la grosse tuerie à la Cannibal Corpse qui te fait bouger les tripes (ça change des CD, d'entendre leurs basses bien mixées)...
En anglais ou en français, utiliser "stable" à la place de "fiable" (ou de "reliable"), c'est de toute façon un abus de langage.
"Stable", ça veut dire que ça ne bouge plus ; mais c'est relatif à une utilisation particulière. Et dire que quelque chose de "fiable" est "stable" juste parce que ça ne se casse pas la gueule au premier coup de vent...
Par exemple, je considère les OS redmondiens comme relativement "stables" (enfin, la base)... de là à dire que je les qualifierais de "fiables"...
Le bleeding-edge sous Gentoo, ça a subit un sacré recul, ces dernières années, hein...
X.org (tout, sauf la base, en ce qui me concerne) voit encore sa version 7.3 tilde-archée... tout comme Firefox 3...
... et m'est avis que c'est tout sauf un mal, vu les problèmes qu'ont pu engendrer les dé-tilde-archage hâtifs dans cette, n'en reste pas moins, fantastique distro. A la limite, le point fort dans ce cas, c'est d'être fait pour proposer plusieurs versions des applis de manière concurrente (même si on n'en installe qu'une seule à la fois)...
... un peu comme les backports Debian, ou le apt-pinning (dont il faut parfois accepter les conséquences néfastes) en somme.
Maintenant, ça me paraît davantage être quelque chose qui intéresse les utilisateurs "avancés" plutôt que le grand public... ma mère utilise une Debian stable, et honnêtement, firefox 1.5, 2.0 ou 3.0, elle s'en fout complètement ; elle n'a même pas conscience qu'il peut y avoir des différences.
Avoir la dernière version pour pouvoir dire "t'as vu, j'ai la dernière version", je ne vois pas bien où ça mène... ni à quoi ça sert ; oui, firefox 3.0 et Gimp 2.4 sont un peu mieux que les versions précédentes... de là à dire qu'il y a un monde qui les sépare, je n'irais franchement pas jusque là : firefox 3 est toujours lent et très mal intégré sous X.org (seule et unique appli qui ne prend pas en compte mon dpi peu commun, fonctionnement bizarre du presse papier avec le bouton du milieu, intégration exécrable aux thèmes gtk, ...), et il manque toujours les dossiers de calques et les fonctions d'impression pro à Gimp 2.4... dont acte.
A la limite, ce que je préfèrerais, c'est que tout (et quand je dis "tout", je pense vraiment à "TOUT") ce qui concerne le support du matériel soit mis à jour plus souvent, de manière globale... comme lcdproc dans Debian, qui n'a pas été mis à jour depuis la sortie d'Etch, fut-ce en backport, et qui ne l'est toujours pas dans Lenny (même si la page QA laisse un poil d'espoir en laissant penser que l'exception de non-freeze de ce paquet va permettre de le voir upgradé dans la prochaine Stable)...
Voire à ne pas confondre non plus "stable", "fiable", "fonctionnel" et "récent"... les régressions, c'est monnaie courrante ; prenons X.org pour exemple... X.org 7.3 (en attendant que le 7.4 sorte enfin... si jamais...) est peut-être plus récent et plus fiable que les précédents quant à la gestion du multi-écran, mais il est indubitablement moins fonctionnel sur ce point ; avec le 7.1, on pouvait faire du multi-GPU, même si c'était au prix du manque d'accélération 3D... Avec cette version qui est encore celle de l'actuelle Debian stable (ie stabilisée, ie figée à une version qui n'est pas forcément la dernière en date : ni plus, ni moins), je n'ai aucun problème à avoir 3 écrans avec une accélération 2D libre...
Alors, laquelle est la mieux ? Et bien ça dépend, justement...
Ce qui est bien, au fond, c'est d'avoir le choix. Debian stable ne satisfait plus l'auteur du journal ? Pourquoi ne pas utiliser une Lenny, par exemple, en ce cas ? A défaut d'être "stable" (ie, ses paquets ne sont pas figés, ni plus, ni moins), elle se révèle globalement très fiable depuis la sortie même de Etch (le seul gros problème dont je me souvienne, hors problèmes de sécu, plus longs à corriger que dans les autres Debian, c'est un paquet de grub qui a été merdeux pendant quelques heures)...
Même si je ne serais pas du tout contre un poil de granularité en plus, avec des backports plus fournis, la diversité des distros fait que, de la granularité, justement, il y en a déjà pas mal.
Les exigences de compatibilité dépendent aussi du modèle de box...
... j'ai eu le malheur de tâter de la sagem chez un pote (achetez français, qu'ils disaient : j'ten foutrai !)...
Ayant eu quelques revers avec l'interface de configuration sous acides de cette ignominie, j'ai à un moment décidé de lui demander de revenir à ses réglages par défaut... gravissime erreur : quand on fait ça, elle se met en attente d'un flashage via tftp...
... qui nécessite le CD, pour aller au plus direct, et donc, un OS proprio (j'ai vaguement cherché un truc qui ressemblait à un firmware sur la galette, mais je n'ai pas trouvé)... le plus frustrant étant que cette box est selon toute vraissemblance sous Linux (à voir le nom des interfaces réseaux, dans l'interface de config sous acides suscitée)... il y a quand même des grands coups de barre à mine qui se perdent.
D'autant plus que si on n'a pas la livebox, les hotliners t'envoient facilement bouler quand tu (le DSLAM, bien souvent : en trois ans chez eux, la carte du vieux local PTT a cramé deux fois) as un problème, et qu'ils te demandent de faire des trucs sur leur bousin...
... du coup, j'en ai une, même si je lui préfère de loin un modem qui ne fait que modem, et qui me permet de gagner 10-15ms de ping...
... le pourquoi du comment je suis chez Orange, par contre, ça remonte au filtrage de frein.fr, qui m'empêchait de faire jusqu'au https (la connexion mourrait au bout de quelques paquets), en plein à un moment où je devais soumettre un article pour un congrès ; j'habite à la campagne (~2000 habitants, à 30 bornes du premier truc qui ressemble à une ville), mais je ne suis pourtant qu'à 200m d'un joli DSLAM ADSL2+...
... du coup, j'ai profité du passage en ADSL2+ du bestiau pour changer de FAI : c'est plus cher, mais je ne le regrette pas... chacun son truc.
Addendum : on peut peut-être faire du désentrelacement matériel avec des GPU à blobs, mais j'ai le (bon ou mauvais, selon les avis) goût d'être très intègre (d'aucuns n'hésitent pas à dire intégriste... moi non plus, d'ailleurs)...
... mon GPU le plus puissant est donc une Radeon X800XL... à drivers libres...
J'attends impatiemment le successeur de Xv, par Intel (je ne me souviens plus du nom), qui permettrait de gérer la décompression (entre autres) des MPEG4-AVC (par exemple, H.264), via le GPU, et librement... mais faute de grives...
Alors, pour le désentrelacement propre... comme l'explique très bien 100fps.com, si tu gardes le même taux de "frames/second" (en ce cas, "frames", c'est pour "images", par opposition à "field", qui est une demi-image dans une video entrelacée), tu cours au devant de gros problèmes de fluidité, typiquement sur les mouvements de translation ("travelings")...
... tu peux tortiller le truc dans tous les sens, si le moindre truc bouge à l'écran, c'est inéluctable : strictement.
Maintenant, en temps réel, ça bouffe des tonnes de resources : mon HTPC est un E4500 (soit un "petit" dual-core, ce qui est déjà relativement cornu), et pour faire propre, j'utilise un désentrelacement avec yadif ("yet-another-de-interlacing-filter") à doublement de taux d'images, ce qui, avec le scaling, et un léger débruitage 3d (hqdn3d de ffmpeg) sur mon full-hd, me bouffe, en direct, au bas mot 70% d'un core (MythTV, pas plus que ffmpeg, ne gère le multi-threading sur le désentrelacement, à mon grand dam), pour du 576i... par contre, très peu de gens (si ce n'est ceux qui ont passé des centaines d'heures à apprendre à le faire... mais nous ne sommes pas tant que ça à nous être transformés en monstres mutants...) sont capables de faire la différence avec du 720p dans ces conditions, à 2,50m de mon 42", sur des sources sans trop de "blocking" (artefacts sous formes de gros carrés, dans les flux MPEG)...
... pour du 1080i, en direct, avec ma config, c'est mort : en temps réel, je suis limité au désentrelaçage à fondu basique (de toute façon, je ne reçois pas encore la TNT HD-ready... à compter que mes cartes TNT soient capables de gérer ça, ce dont je ne sais encore rien, même si au fond, elles ne font rien de plus que dumper un flux MPEG, même pas indexé... et puis bon, la HD-ready, face à du SD proprement traité, quitte à m'attirer les foudres des kikoolols des spécifications techniques : bof - très honnêtement, si on parle de post-traitement propre au transcodage, ce dont je parle, ne regardant que très peu le broadcast en direct)...
Après, si tu veux faire au plus propre, après enregistrement, ie si tu ne veux pas mettre à la poubelle la moitié des infos (temporelles, au moins) de ta video, pas le choix : il faut doubler le framerate... soit au moins un "-vf yadif=1" (ou yadif=3, m'enfin, c'est moins joli... et de toute façon, un minimum intense aussi, donc ...)...
Et si tu veux vraiment faire du très propre, rien n'empêche de lui coller un désentrelaçage avec compensation des mouvements (une sorte d'interpolation avancée des vecteurs de mouvements), via mcdeint (par exemple, "-vf yadif=1,mcdeint=0,harddup ... le harddup, c'est pour éviter les désynchros du son... et ne pas oublier non plus de lui spécifier un doublement des fps avec "-fps 50 -ofps 50", pour du 25 images par seconde, sans quoi, la video ira deux fois moins vite que la normale... ah oui : et si tu "croppes", il faut le faire avant, a contrario de l'inverse-telecine, où il faut le faire après)...
... mais là, avec mcedint, gros warning : il ne faut pas être pressé... vraiment pas... vraiment-vraiment pas... d'une, ni yadif, ni mcdeint ne sont multi-threadés : c'est donc très lent (et au final, c'est une bonne occasion de booster les options de x264 ou du codec que tu utilises, pour charger le proc, d'autant plus si tu as un multi-core)... pour info, quand je parle de plus de 12h pour transcoder 2h de video, c'est avec du 576i, sur un Q6600 (je transcode mon DVD PAL de "Brazil", à fins d'archivages, là : j'ai lancé le bouzin à 17h, et dans une heure, il me finit la première passe - oui, j'abuse comme un porc sur les profils H.264... mais ce qui me bouffe le plus, et de loin, c'est le "mcdeint")... "voilà, quoi", comme on dit...
En fait, j'ai évoqué le désentrelacement pour faire une analogie avec les "ghost frames" (je n'avais pas encore vu tes videos, jusqu'à ce que Frédéric balance les liens en MPEG4-AVC, ce que, ça, je peux lire sur ma station de travail, vu que c'est sa raison d'être aussi puissante, avec Octave ;) )...
Evidemment, si tu changes la base de temps d'une video progressive, et que tu le fais en négligeant le problème des changements de scènes et en faisant juste un "blending" (ie "fondu"... j'anglicise car c'est la langue la plus courante dans laquelle on va trouver des infos sur ce genre de pratiques... et que le nom des différents filtres permettant ce genre de choses en découle aussi), tu vas tomber sur des ghost frames également (dans la problématique qui concerne directement ce journal... même si ce que tu fais est plus de "l'artistique" temporel qu'autre chose, comme tu le soulignes)...
Maintenant, j'entrevois deux cas où il peut être utile de "retimer" du progressif (outre le ralenti volontaire, pour voir un détail qui nous échappe, comme les moults easter-eggs de Futurama - ça en devient maladif, mais à chaque fois que je vois une foule dans cet animé, je finis par mater la scène au ralenti pour chercher le "#9 guy", même s'il n'apparaît que très peu :p ) :
- le diffuseur ne sait faire qu'un seul taux d'images par secondes (beurk... et re-beurk... mais tellement courant... et vu que la large majorité des gens se contrefout de la qualité, on n'est pas près de voir des diffuseurs à très haut taux d'images ET à prix abordable, pour chercher du dénominateur commun... donc, là, je crains que ce soit un peu sans issue, sauf à accélérer/ralentir purement et simplement) ;
- la video n'est pas exclusivement progressive, mais un mélange de progressif/telecine (pffff... les DVD de South Park en NTSC, sur les saisons "récentes", par exemple... auquel cas, c'est soft-telecine via MEncoder => telecinage propre des parties progressives, puis, détélécinage) ou progressif/entrelacé ;
Mais bon, c'est 'achement spécifique, comme cas... et si tu commences à gérer le "retiming" des sources non-progressives, là, c'est une autre paire de manches, je le crains.
En fait, tant qu'on en reste à du progressif, je pense comme Mekare que l'idéal serait d'introduire de la détection de changement de plan, pour éviter les "morphings" qu'on voit sur tes videos... par contre, ça se complique si tu dois garder une synchro audio-video.
En tout cas, c'est super cool de voir des gens bosser sur ça, parce que je ne connais pas de choses qui permettent de faire du ralenti vraiment propre, avec calcul d'images intermédiaires, en libre.
[^] # Re: Quelques idées...
Posté par Aefron . En réponse au journal 'Retiming' vidéo et logiciels libres. Évalué à 2.
... le problème, c'est que le PTS (indicateur du temps dans les vob) est remis à zéro à chaque chapitre... rendant impossible la navigation via "-ss" (ça ne marche pas non plus avec un fichier opendml)... et que je considère l'option "-sb" (découpe en fonction du nombre d'octets) comme radicalement chiante...
...et comme dumpstream n'est pas capable de découper les chapitres dans un titre, c'est la loose... du coup, c'est pour ça que je fais à la mimine via tccat... sauf que tccat ne dumpe pas les vobsub (ce qui _peut_ être gênant, mais dont, pour le coup, sur ces DVD, je me fous), comme le fait le dumpstream de MPlayer, qui n'est pas foireux comme j'ai écrit au-dessus, mais au contraire, presque trop fidèle (mea culpa : par contre, les éditeurs de DVD qui font du PTS reset, gare à eux si j'en chope un, un de ces jours... j'avais entendu parler que ça existait sur les DVD, mais je n'en avais encore jamais vu... jusqu'à ce que je réalise que j'en avais en fait en voulant retailler au début des chapitres)...
Bon, ce qui m'aurait arrangé, c'est que le dumpstream de MPlayer soit capable de découper les chapitres dans un titre... mais à l'heure actuelle, c'est impossible. Voilà, en espérant que ça serve à quelqu'un un de ces quatre...
[^] # Re: RC bugs
Posté par Aefron . En réponse au journal « Squeeze », le petit nom de la future Debian. Évalué à 2.
... raison de plus pour ne même pas prendre la peine de faire un effort pour supporter ce format foireux.
[^] # Re: RC bugs
Posté par Aefron . En réponse au journal « Squeeze », le petit nom de la future Debian. Évalué à 4.
Quand tu demandes des partitions séparées pour tout (/boot, /, /usr, /var, /tmp, /home, swap), sur une distro 64 bits (sur laquelle tu peux quand même installer le blob userland), en faisant venir les libs 32 bits, à l'installation de cet ignoble machin, tu finis vite par remplir le tout petit / par défaut... ce qui peux vite te mettre dans le caca...
... ce qui a au moins le mérite de pointer du doigt le fait que devoir rajouter autant de choses pour avoir un support mixte 32/64 bits, pour une cochonnerie comme flash (seule raison qui m'y poussait), ça n'en vaut vraiment pas la peine.
Par contre, les plugins libres, j'ai encore de gros problèmes, avec... je n'ai pas utilisé swfdec depuis un moment, mais gnash a réussi à faire freezer le clickodrome sur ma Sid, avec un quad-core (Q6600), l'autre jour... j'ai in-extremis réussi à reprendre la main en passant en tty (la souris ne fonctionnait plus, tellement tout était lent... pour tout dire, même les tty étaient lents comme la mort)...
Du coup, vu que j'ai mis le partitionnement séparé par défaut sur la seule machine où j'installais flash de temps en temps (ma workstation, sur laquelle je fais des trucs plus intenses que sensibles), et bien, maintenant je m'abstiens, et ça me va très bien... surtout vu les conneries qu'on trouve en flash (pubs, jackasseries, polémiques-alakon, ...) : je peux aisément m'en passer...
... au pire, si je veux mâter du flash proprio, j'ai toujours une Wii proprio, avec son Opera proprio, équipé d'un plugin flash proprio... les cochonneries ensemble, c'est plus sain :D
[^] # Re: Quelques idées...
Posté par Aefron . En réponse au journal 'Retiming' vidéo et logiciels libres. Évalué à 2.
Sinon, si ça t'intéresse, il y a un test statique (dommage, car c'est toujours mieux en voyant une suite d'images) sur guru.multimedia [1]
Pour le mcdeint, il segfaulte aussi chez moi avec le 2 et le 3... par contre, je le mets toujours, en "mcdeint=0" (soit "-vf crop=w:h:x:y,yadif=1,mcdeint=0,harddup"), car j'ai pu remarquer que certains contenus pauvrement entrelacés (DVD du commerce... arf...) présentaient moins d'artefacts avec lui. Je ne me rappelle plus de pourquoi je n'utilise pas le mcdeint=1, par contre (mais je crois que c'est parce que je ne voyais pas d'amélioration flagrante pour une grosse pénalité de vitesse)...
En fait, ces artefacts se traduisent par des "points blancs" qui apparaissent en certains endroits de l'image (surtout visibles sur les contours des animes avec "crayonné" épais, comme Futurama ou les Simpson).
mcdeint ne les élimine pas toujours complètement, mais j'ai pu remarquer à plusieurs occasions qu'il les atténuait considérablement... donc, je l'utilise...
En outre, mcdeint me pénalise surtout sur la première passe de mes transcodages, durant lesquels x264 charge moins le processeur, car j'utilise l'option turbo qui désactive plein de choses gourmandes comme le gros trellis & cie, sans pénaliser la qualité finale... mais pour la deuxième passe, les options que j'utilise avec x264 sont tellement intenses que, de toute façon...
Et puis bon, c'est la machine qui travaille, pas moi :p ... ce qui me fait d'ailleurs penser qu'il faut que je reprenne mes scripts d'automatisation pour abandonner le rip avec mplayer et son dumpstream foireux sauf le "dumpvosub", excellent quant à lui, et pourtant taggé comme du code beta... ce que j'ai du mal à saisir), qui merde avec mes DVD de Strip-Tease (l'émission France 3-RTBF, hein...), pour lui préférer tccat, avec lequel je n'ai aucun souci... par contre, pour le transcodage, MEncoder roxorise !
http://guru.multimedia.cx/deinterlacing-filters/
[^] # Re: Je risque peut-être de lancer un troll velu mais...
Posté par Aefron . En réponse à la dépêche gNewSense 2.1. Évalué à 2.
... moins compliqué, certes, mais tout aussi faisable avec gnewsense, dans l'absolu...
[^] # Re: Je risque peut-être de lancer un troll velu mais...
Posté par Aefron . En réponse à la dépêche gNewSense 2.1. Évalué à 2.
Leur site est toujours down, mais sur la page wikipedia [1], il y est fait allusion à la dérivation de cette distro du projet gnubuntu, lui-même faisant suite à une discussion entre Stallman et Shuttleworth...
Et puis, le projet, elle le soutient... ça fait une occasion d'avoir une distro qui respecte vraiment ses positions...
Quant à Shuttleworth, après tout le trollage sur le mépris du libre par sa distro, y accoler le nom de son simili-fork lui fait une bonne pub rédemptrice...
N'en reste pas moins que, à titre purement personnel, je considère bien plus les phares du libres comme étant OpenBSD et Debian... et les voir considérées comme non libres (bon, encore, pour Debian, avec "non-free", dans lequel il y a d'ailleurs la doc d'emacs [ahemmm]... mais pour OpenBSD ?!?!?! Le apt de gnewsense aurait-il des anti-corps-anti-libres qui l'immuniserait contre les vilains paquets, contrairement aux ports BSDiens [dérision, je précise... au cas où] ?), alors qu'est mis en avant ce machin, qui relève plus du troll pour se faire mousser que d'autre chose, oui, ça me fait mal au cul... enfin, ça participe surtout à ce que la FSF, je ne lui accorde qu'une crédibilité et une honnêteté intellectuelle de plus en plus limitées (je ne me prononcerai même pas sur ce que je pense de canonical).
gnewsense, même si elle a au moins le bon goût de pointer du doigt des choses dérangeantes (comme la non liberté de certains trucs dans glx), sur le fond, je vois ça comme un trollo-buzz-marketing, non dénué de mépris... comme ubuntu, quoi...
[1] http://fr.wikipedia.org/wiki/Gnewsense#Ubuntu_et_Richard_Sta(...)
[^] # Re: Je risque peut-être de lancer un troll velu mais...
Posté par Aefron . En réponse à la dépêche gNewSense 2.1. Évalué à 2.
... et encore... certains dépôts, comme celui de slimdevices.com, pour installer le SqueezeCenter des SqueezeBox, fonctionnent sur tout ce qui se base sur les deb... et pourtant, il y a des tas de trucs non libres dedans (les firmwares des boxes, des polices, ...)... les dépôts non libres pour lesquels tu dis qu'il n'y a aucun moyen, bah, ils existent déjà, que ça plaise ou pas ; et j'imagine qu'ils marchent aussi sur cette distro.
Lorsqu'on arrive sur la page de téléchargement du SqueezeCenter [http://wiki.slimdevices.com/index.php/DebianPackage], on peut lire "This package also should work with most Debian-based Linux distributions" ("Ce paquet devrait aussi fonctionner avec la plupart des distributions basées sur Debian")... si on rajoute ce dépôt sur gnewsense, ça ne va pas transformer le paquet en quelque chose de libre pour autant...
... la seule chose que je vois pour contrer ça, ce serait de modifier aptitude/dpkg pour n'accepter que ce qui est signé par eux... ce qui serait assez dommage, entre autres pour ceux qui se font aussi leurs propres paquets, notamment de trucs libres.
[^] # Re: RC bugs
Posté par Aefron . En réponse au journal « Squeeze », le petit nom de la future Debian. Évalué à 8.
Comme la sortie d'un noyau EtchAndAHalf ? ... plus récent que celui de base, pour ceux qui auraient besoin d'un support de matériel plus récent (faut avouer que le 2.6.18 ne peut pas prendre en charge moult contrôleurs qu'on trouve maintenant sur les mobos)... peut-être tardif, mais au moins, c'est vivant : la preuve, ça évolue dans le bon sens...
... n'en reste pas moins qu'ils ne t'ont pas attendu pour ça.
Bon, ça n'empêche pas de critiquer constructivement, hein : personnellement, j'aimerais bien voir TOUT ce qui apporte du nouveau support matériel dans AndAHalf (backends CUPS, SANE, lcdproc, drivers X.org, ...), pour ceux qui veulent ou en ont besoin. Maintenant, je ne suis pas non plus pressé, ni obsessivement exigeant, au point de faire un caca nerveux.
> Je serais quand même curieux d'avoir une idée du nombre de gens qui n'utilisent que stable/main, sans backports, dépots non-officiels, ou non-free
Personnellement, des Debian, j'en ai des stables, des testings et des Sid... plusieurs dizaines, @home, entre autres grâce à la magie des conteneurs...
Je n'utilise "non-free" nulle part (à part sur une seule des machines, de temps en temps, pour voir du flash, que j'installe au besoin... m'enfin, ça fait des mois que je ne l'ai pas remis, et ça ne me coûte en rien... vraiment en rien... ras-le-derche, de cette saloperie de flash : vraiment)...
... et qu'ai-je comme dépôts tiers, sinon ?
- Debian-multimedia, sur les machines "desktop", et sur un conteneur VServer avec MythTV ;
- slimdevices.com, pour le Squeezecenter qui pilote mon radio-réveil, lui aussi dans un conteneur VServer ;
- openvz.org, pour la machine sur laquelle je teste OpenVZ... mais plus pour longtemps, vu qu'un kernel binaire le supportant vient de rejoindre Lenny ;
Sorti de ça, tous mes autres serveurs (quelques dizaines) sont en Debian stable... avec uniquement des dépôts officiels ; et c'est bien parce que je n'ai rien besoin d'autre, et que c'est stable (!=fiable... mais c'est très fiable aussi) pendant longtemps.
Si Debian se mettait à faire des upgrades foireux tous les 6 mois, crois-le bien : je serais embêté.
En attendant, si certains trouvent l'herbe plus verte ailleurs, tant mieux pour eux... je suis allé voir par curiosité il y a quelques mois, et je suis revenu au pas de course ; notamment parce que c'est au fond la distro que je préfère, mais aussi parce qu'elle fonctionne très bien (je pourrais troller sur PackageKit qui a mis trois jours avant d'exploser dans la Fedora que j'ai testée, ou sur d'autres distros... mais sur le fond, je m'en fous pas mal).
Et que Debian vive encore longtemps !
[^] # Re: RC bugs
Posté par Aefron . En réponse au journal « Squeeze », le petit nom de la future Debian. Évalué à 2.
Comme un kernel binaire compilé avec le support d'OpenVZ (rentré ce weekend dans Lenny, ce qui va moult me simplifier la vie)...
... ou avec un peu de bol, un lcdproc en 0.5.x, vu qu'il n'y a pas eu de mise à jour à une nouvelle version depuis au moins Sarge (incluse... arf...).
[^] # Re: Aptitude
Posté par Aefron . En réponse au journal Préparation de la formation Debian GNU/Linux Lenny. Évalué à 2.
... quant aux bidule-bin & cie, si tu es allé les chercher à la main après l'installation d'un paquet, c'est qu'ils n'en dépendent pas et/ou que tu as désactivé les "recommends" (pas du luxe sur un serveur... pas vraiment utile sur une workstation), et ils ne seront alors pas marqués comme automatiquement installés, et ne seront donc a priori pas désinstallés quand tu désinstalles bidule...
... quand tu fais un "aptitude search", la ligne commence par des lettres : "i" si le paquet est installé, à côté d'un "A", s'il a été installé automatiquement (dépendance, recommandation, ...)...
S'il n'y a pas le "A", il faudra a priori les désinstaller manuellement... Des fois, c'est douteux, comme les l10n et autres, mais là, c'est du ressort du choix des mainteneurs plutôt que d'autre chose...
[^] # Re: Quelques idées...
Posté par Aefron . En réponse au journal 'Retiming' vidéo et logiciels libres. Évalué à 2.
Si tu regardes attentivement chacun de tes champs ("fields"), tu verras bien qu'ils ne représentent pas exactement la même image...
[^] # Re: Whaouh !
Posté par Aefron . En réponse au journal [HS] tout ça pour ça : le concert de Madonna à Nice. Évalué à 2.
La dynamique d'un CD, c'est limité... surtout dans le cas d'une musique complexe comme le metal. Il faut donc bien faire des choix, et souvent, les basses se retrouvent downmixées. Et dans certains cas, c'est un peu à l'extrême, comme dans celui de Cannibal Corpse : avec eux, en concert, rien à voir avec les CD.
> Et coté chaine hifi, tu as de quoi bien descendre dans les basses ?
Un Q200E de chez Rel, en caisson de basses, ça t'ira ?
[^] # Re: Whaouh !
Posté par Aefron . En réponse au journal [HS] tout ça pour ça : le concert de Madonna à Nice. Évalué à 1.
Le problème de leurs CD c'est vraiment un gros down-mixage de la basse (comme relativement souvent dans le metal, malheureusement... les CD a aussi ses limites, et ce genre de zique les met en évidence)...
... on l'entend, hein (j'ai beau avoir fait quelques répets de Death sans bouchons, ça va, je n'ai presque rien perdu, comme j'ai pu le vérifier à la médecine du travail... même si ça a sifflé quelques fois)... mais ça pourrait être bien mieux.
Par rapport à quand je les ai vus (notamment à Madrid... dans... une salle de cours de Flamenco, dans laquelle ont lieu la plupart des concerts metal de cette ville), ça change tout... en live, leur son est vraiment orgiaque (encore plus qu'en CD) !
[^] # Re: Whaouh !
Posté par Aefron . En réponse au journal [HS] tout ça pour ça : le concert de Madonna à Nice. Évalué à 1.
Les musiciens, ils entendent et écoutent surtout le son des retours qui sont braqués sur eux...
... avec une batterie qui te gueule juste à côté dans les oreilles, oreilles que ceux qui ne sont pas complètement dingues protègent donc avec des bouchons, de toute façon, sans retours, le son ultra-fort vers le public, tu ne l'entends pas bien, sur scène, hein,...
Par contre, personnellement, quand les réglages sont bien faits, dans un lieu à l'acoustique décente, ce qui est très rare (ça ne me viendrait pas à l'idée d'aller écouter un concert dans un stade, qu'il soit couvert ou pas), j'apprécie du bon gros son (avec des bouchons d'oreilles, faits pour moi sur moulage)... surtout sur de la grosse tuerie à la Cannibal Corpse qui te fait bouger les tripes (ça change des CD, d'entendre leurs basses bien mixées)...
[^] # Re: En même temps...
Posté par Aefron . En réponse au journal La France c'est bien, l'Amérique c'est nul. Évalué à 8.
[^] # Re: J'adore
Posté par Aefron . En réponse au journal Google arrête le partenariat avec forestle.org. Évalué à 8.
Pour qu'on atteigne (enfin) un seuil critique de gens qui veulent qu'on supprime la pub ?
Oui, je --->[]
[^] # Re: lenny ou sid
Posté par Aefron . En réponse à la dépêche Debian Lenny is a Live !. Évalué à 10.
"Stable", ça veut dire que ça ne bouge plus ; mais c'est relatif à une utilisation particulière. Et dire que quelque chose de "fiable" est "stable" juste parce que ça ne se casse pas la gueule au premier coup de vent...
Par exemple, je considère les OS redmondiens comme relativement "stables" (enfin, la base)... de là à dire que je les qualifierais de "fiables"...
[^] # Re: Gentoo ? Arch ?
Posté par Aefron . En réponse au journal [Troll du vendredi] Mettre au même niveau la base des distributions stables en regard des logiciels utilisateurs est-il vraiment une bonne chose ?. Évalué à 5.
X.org (tout, sauf la base, en ce qui me concerne) voit encore sa version 7.3 tilde-archée... tout comme Firefox 3...
... et m'est avis que c'est tout sauf un mal, vu les problèmes qu'ont pu engendrer les dé-tilde-archage hâtifs dans cette, n'en reste pas moins, fantastique distro. A la limite, le point fort dans ce cas, c'est d'être fait pour proposer plusieurs versions des applis de manière concurrente (même si on n'en installe qu'une seule à la fois)...
... un peu comme les backports Debian, ou le apt-pinning (dont il faut parfois accepter les conséquences néfastes) en somme.
Maintenant, ça me paraît davantage être quelque chose qui intéresse les utilisateurs "avancés" plutôt que le grand public... ma mère utilise une Debian stable, et honnêtement, firefox 1.5, 2.0 ou 3.0, elle s'en fout complètement ; elle n'a même pas conscience qu'il peut y avoir des différences.
Avoir la dernière version pour pouvoir dire "t'as vu, j'ai la dernière version", je ne vois pas bien où ça mène... ni à quoi ça sert ; oui, firefox 3.0 et Gimp 2.4 sont un peu mieux que les versions précédentes... de là à dire qu'il y a un monde qui les sépare, je n'irais franchement pas jusque là : firefox 3 est toujours lent et très mal intégré sous X.org (seule et unique appli qui ne prend pas en compte mon dpi peu commun, fonctionnement bizarre du presse papier avec le bouton du milieu, intégration exécrable aux thèmes gtk, ...), et il manque toujours les dossiers de calques et les fonctions d'impression pro à Gimp 2.4... dont acte.
A la limite, ce que je préfèrerais, c'est que tout (et quand je dis "tout", je pense vraiment à "TOUT") ce qui concerne le support du matériel soit mis à jour plus souvent, de manière globale... comme lcdproc dans Debian, qui n'a pas été mis à jour depuis la sortie d'Etch, fut-ce en backport, et qui ne l'est toujours pas dans Lenny (même si la page QA laisse un poil d'espoir en laissant penser que l'exception de non-freeze de ce paquet va permettre de le voir upgradé dans la prochaine Stable)...
Voire à ne pas confondre non plus "stable", "fiable", "fonctionnel" et "récent"... les régressions, c'est monnaie courrante ; prenons X.org pour exemple... X.org 7.3 (en attendant que le 7.4 sorte enfin... si jamais...) est peut-être plus récent et plus fiable que les précédents quant à la gestion du multi-écran, mais il est indubitablement moins fonctionnel sur ce point ; avec le 7.1, on pouvait faire du multi-GPU, même si c'était au prix du manque d'accélération 3D... Avec cette version qui est encore celle de l'actuelle Debian stable (ie stabilisée, ie figée à une version qui n'est pas forcément la dernière en date : ni plus, ni moins), je n'ai aucun problème à avoir 3 écrans avec une accélération 2D libre...
Alors, laquelle est la mieux ? Et bien ça dépend, justement...
Ce qui est bien, au fond, c'est d'avoir le choix. Debian stable ne satisfait plus l'auteur du journal ? Pourquoi ne pas utiliser une Lenny, par exemple, en ce cas ? A défaut d'être "stable" (ie, ses paquets ne sont pas figés, ni plus, ni moins), elle se révèle globalement très fiable depuis la sortie même de Etch (le seul gros problème dont je me souvienne, hors problèmes de sécu, plus longs à corriger que dans les autres Debian, c'est un paquet de grub qui a été merdeux pendant quelques heures)...
Même si je ne serais pas du tout contre un poil de granularité en plus, avec des backports plus fournis, la diversité des distros fait que, de la granularité, justement, il y en a déjà pas mal.
[^] # Re: une livebox ?
Posté par Aefron . En réponse au journal Matériel "pas compatible Linux" mais qui fonctionne quand même.. Évalué à 5.
... j'ai eu le malheur de tâter de la sagem chez un pote (achetez français, qu'ils disaient : j'ten foutrai !)...
Ayant eu quelques revers avec l'interface de configuration sous acides de cette ignominie, j'ai à un moment décidé de lui demander de revenir à ses réglages par défaut... gravissime erreur : quand on fait ça, elle se met en attente d'un flashage via tftp...
... qui nécessite le CD, pour aller au plus direct, et donc, un OS proprio (j'ai vaguement cherché un truc qui ressemblait à un firmware sur la galette, mais je n'ai pas trouvé)... le plus frustrant étant que cette box est selon toute vraissemblance sous Linux (à voir le nom des interfaces réseaux, dans l'interface de config sous acides suscitée)... il y a quand même des grands coups de barre à mine qui se perdent.
[^] # Re: une livebox ?
Posté par Aefron . En réponse au journal Matériel "pas compatible Linux" mais qui fonctionne quand même.. Évalué à 2.
... du coup, j'en ai une, même si je lui préfère de loin un modem qui ne fait que modem, et qui me permet de gagner 10-15ms de ping...
... le pourquoi du comment je suis chez Orange, par contre, ça remonte au filtrage de frein.fr, qui m'empêchait de faire jusqu'au https (la connexion mourrait au bout de quelques paquets), en plein à un moment où je devais soumettre un article pour un congrès ; j'habite à la campagne (~2000 habitants, à 30 bornes du premier truc qui ressemble à une ville), mais je ne suis pourtant qu'à 200m d'un joli DSLAM ADSL2+...
... du coup, j'ai profité du passage en ADSL2+ du bestiau pour changer de FAI : c'est plus cher, mais je ne le regrette pas... chacun son truc.
[^] # Re: 50i vers 25p
Posté par Aefron . En réponse au journal 'Retiming' vidéo et logiciels libres. Évalué à 2.
... qui ne permet en outre, si on se limite à ça, que d'utiliser un seul coefficient de ralentissement, soit x1/2...
[^] # Re: Re : Bureaux
Posté par Aefron . En réponse au journal Les window managers c'était mieux à vent !. Évalué à 4.
Mais non ! C'est l'autre, qui a l'air bête, en ce cas :)
[^] # Re: Quelques idées...
Posté par Aefron . En réponse au journal 'Retiming' vidéo et logiciels libres. Évalué à 2.
... mon GPU le plus puissant est donc une Radeon X800XL... à drivers libres...
J'attends impatiemment le successeur de Xv, par Intel (je ne me souviens plus du nom), qui permettrait de gérer la décompression (entre autres) des MPEG4-AVC (par exemple, H.264), via le GPU, et librement... mais faute de grives...
[^] # Re: Quelques idées...
Posté par Aefron . En réponse au journal 'Retiming' vidéo et logiciels libres. Évalué à 6.
... tu peux tortiller le truc dans tous les sens, si le moindre truc bouge à l'écran, c'est inéluctable : strictement.
Maintenant, en temps réel, ça bouffe des tonnes de resources : mon HTPC est un E4500 (soit un "petit" dual-core, ce qui est déjà relativement cornu), et pour faire propre, j'utilise un désentrelacement avec yadif ("yet-another-de-interlacing-filter") à doublement de taux d'images, ce qui, avec le scaling, et un léger débruitage 3d (hqdn3d de ffmpeg) sur mon full-hd, me bouffe, en direct, au bas mot 70% d'un core (MythTV, pas plus que ffmpeg, ne gère le multi-threading sur le désentrelacement, à mon grand dam), pour du 576i... par contre, très peu de gens (si ce n'est ceux qui ont passé des centaines d'heures à apprendre à le faire... mais nous ne sommes pas tant que ça à nous être transformés en monstres mutants...) sont capables de faire la différence avec du 720p dans ces conditions, à 2,50m de mon 42", sur des sources sans trop de "blocking" (artefacts sous formes de gros carrés, dans les flux MPEG)...
... pour du 1080i, en direct, avec ma config, c'est mort : en temps réel, je suis limité au désentrelaçage à fondu basique (de toute façon, je ne reçois pas encore la TNT HD-ready... à compter que mes cartes TNT soient capables de gérer ça, ce dont je ne sais encore rien, même si au fond, elles ne font rien de plus que dumper un flux MPEG, même pas indexé... et puis bon, la HD-ready, face à du SD proprement traité, quitte à m'attirer les foudres des kikoolols des spécifications techniques : bof - très honnêtement, si on parle de post-traitement propre au transcodage, ce dont je parle, ne regardant que très peu le broadcast en direct)...
Après, si tu veux faire au plus propre, après enregistrement, ie si tu ne veux pas mettre à la poubelle la moitié des infos (temporelles, au moins) de ta video, pas le choix : il faut doubler le framerate... soit au moins un "-vf yadif=1" (ou yadif=3, m'enfin, c'est moins joli... et de toute façon, un minimum intense aussi, donc ...)...
Et si tu veux vraiment faire du très propre, rien n'empêche de lui coller un désentrelaçage avec compensation des mouvements (une sorte d'interpolation avancée des vecteurs de mouvements), via mcdeint (par exemple, "-vf yadif=1,mcdeint=0,harddup ... le harddup, c'est pour éviter les désynchros du son... et ne pas oublier non plus de lui spécifier un doublement des fps avec "-fps 50 -ofps 50", pour du 25 images par seconde, sans quoi, la video ira deux fois moins vite que la normale... ah oui : et si tu "croppes", il faut le faire avant, a contrario de l'inverse-telecine, où il faut le faire après)...
... mais là, avec mcedint, gros warning : il ne faut pas être pressé... vraiment pas... vraiment-vraiment pas... d'une, ni yadif, ni mcdeint ne sont multi-threadés : c'est donc très lent (et au final, c'est une bonne occasion de booster les options de x264 ou du codec que tu utilises, pour charger le proc, d'autant plus si tu as un multi-core)... pour info, quand je parle de plus de 12h pour transcoder 2h de video, c'est avec du 576i, sur un Q6600 (je transcode mon DVD PAL de "Brazil", à fins d'archivages, là : j'ai lancé le bouzin à 17h, et dans une heure, il me finit la première passe - oui, j'abuse comme un porc sur les profils H.264... mais ce qui me bouffe le plus, et de loin, c'est le "mcdeint")... "voilà, quoi", comme on dit...
[^] # Re: Quelques idées...
Posté par Aefron . En réponse au journal 'Retiming' vidéo et logiciels libres. Évalué à 2.
Evidemment, si tu changes la base de temps d'une video progressive, et que tu le fais en négligeant le problème des changements de scènes et en faisant juste un "blending" (ie "fondu"... j'anglicise car c'est la langue la plus courante dans laquelle on va trouver des infos sur ce genre de pratiques... et que le nom des différents filtres permettant ce genre de choses en découle aussi), tu vas tomber sur des ghost frames également (dans la problématique qui concerne directement ce journal... même si ce que tu fais est plus de "l'artistique" temporel qu'autre chose, comme tu le soulignes)...
Maintenant, j'entrevois deux cas où il peut être utile de "retimer" du progressif (outre le ralenti volontaire, pour voir un détail qui nous échappe, comme les moults easter-eggs de Futurama - ça en devient maladif, mais à chaque fois que je vois une foule dans cet animé, je finis par mater la scène au ralenti pour chercher le "#9 guy", même s'il n'apparaît que très peu :p ) :
- le diffuseur ne sait faire qu'un seul taux d'images par secondes (beurk... et re-beurk... mais tellement courant... et vu que la large majorité des gens se contrefout de la qualité, on n'est pas près de voir des diffuseurs à très haut taux d'images ET à prix abordable, pour chercher du dénominateur commun... donc, là, je crains que ce soit un peu sans issue, sauf à accélérer/ralentir purement et simplement) ;
- la video n'est pas exclusivement progressive, mais un mélange de progressif/telecine (pffff... les DVD de South Park en NTSC, sur les saisons "récentes", par exemple... auquel cas, c'est soft-telecine via MEncoder => telecinage propre des parties progressives, puis, détélécinage) ou progressif/entrelacé ;
Mais bon, c'est 'achement spécifique, comme cas... et si tu commences à gérer le "retiming" des sources non-progressives, là, c'est une autre paire de manches, je le crains.
En fait, tant qu'on en reste à du progressif, je pense comme Mekare que l'idéal serait d'introduire de la détection de changement de plan, pour éviter les "morphings" qu'on voit sur tes videos... par contre, ça se complique si tu dois garder une synchro audio-video.
En tout cas, c'est super cool de voir des gens bosser sur ça, parce que je ne connais pas de choses qui permettent de faire du ralenti vraiment propre, avec calcul d'images intermédiaires, en libre.