Je voudrais discuter aujourd'hui du sujet de 'retiming vidéo' et demander des infos aux spécialistes du traitement/montage vidéo par logiciels libres. En gros, lorsque l'on souhaite faire des ralentissements dans une séquence vidéo, on a pas 36 possibilités. On peut :
- Soit baisser le nombres de frames affichées par secondes lors de la lecture de la vidéo (passer de 25 fps à 10 fps par exemple). Ca marche bien, si la vidéo originale est déjà relativement lente ou avec un mouvement très continu. Dans le cas contraire d'un mouvement plus rapide, on a l'impression désagréable de regarder une vidéo saccadée.
- Ou alors, garder le taux de frames par seconde identique, mais en ayant soin d'avoir inséré des frames intermédiaires dans la séquence, frames qui interpolent à la fois le mouvement et la couleur des pixels entre les frames originales.
C'est cette deuxième solution qui m'intéresse ici. Bien sûr, c'est plus compliqué car on doit estimer le mouvement de la manière la plus correcte possible pour que l'interpolation finale soit la meilleure possible. Je connais pas mal d'algos pour estimer le mouvement entre deux frames, mais je me posais la question si certains étaient disponibles sous forme de logiciels/bibliothèques libres, et surtout déjà implémentés pour le retiming vidéo ?
J'ai cherché un peu mais j'ai rien trouvé.
Pour ma part, j'ai développé un algo relativement simple d'estimation de déplacement, dispo dans la bibliothèque CImg. Il s'avère que j'ai sorti la version 0.7 de G'MIC aujourd'hui (petit logiciel de traitement d'images en ligne de commande dont j'ai parlé y a pas très longtemps ici même). Cette version permet maintenant d'utiliser l'algo d'estimation de mouvement de façon scriptable, et l'utiliser pour faire du 'morphing' automatique entre deux images par exemple.
Je l'ai utilisé pour essayer de 'retimer' (dans le sens 'ralentir') une vidéo. C'est loin d'être parfait, c'est même plutôt artistique qu'autre chose, mais ca rend pas trop mal sur certains bouts. Et donc, je me demandais si ca pouvait intéresser des vidéastes libres amateurs, et si quelque chose dans le même genre existait déjà (en libre bien sûr).
Vous pouvez voir la vidéo originale ici, et le résultat du retiming ici.
Voilà, merci de faire partager votre savoir faire sur ce sujet !
David.
# Quelques idées...
Posté par Aefron . É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: Quelques idées...
Posté par seginus . Évalué à 6.
[^] # Re: Quelques idées...
Posté par Aefron . É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: Quelques idées...
Posté par Frédéric Heulin . Évalué à 3.
la vidéo originale ici :
[http://vp.video.google.com/videodownload?version=0&secur(...)]
et le résultat du retiming ici :
[http://vp.video.google.com/videodownload?version=0&secur(...)]
[^] # Re: Quelques idées...
Posté par David Tschumperlé (site web personnel) . Évalué à 2.
Alors c'est pas très souvent qu'on en rencontre de telles vidéos, mais est-ce que ce n'est pas censé devenir le futur standard pour la HD ?
David.
[^] # Re: Quelques idées...
Posté par Aefron . É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.
[^] # Re: Quelques idées...
Posté par Ph Husson (site web personnel) . Évalué à 2.
Tien tu m'interesse, j'ai régulierement des vidéos en 1080i à réencoder et je sais jamais comment m'y prendre proprement, du coup je laisse mencoder se demerder (avec un scale=1280:720 pour économiser un peu mon CPU et que le 720 me suffit), mais c'est vrai que le désentrelacement a pas l'air génial (le flux de sortie a bien l'air désentrelacé si j'en crois ma freebox), donc comment faire pour avoir quelque chose de pas trop moche ?
Et y aurait aussi des options pour pouvoir faire du désentrelacement propre, cette fois en temps réel pour le multiposte de Free, par la carte graphique ? (par OpenGL, vu que les geforce8xxx gerent plus que ca quasiement...)
Merci d'avance de nous faire partager ta culture :)
[^] # Re: Quelques idées...
Posté par Aefron . É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 . É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 Ph Husson (site web personnel) . Évalué à 3.
Bon alors je viens de tenter du 576i avec yadif=1,mcdeint=0 sur mon Q6600 à 3Ghz et résultat.... le cpu ('fin un seul core) arrive pas à suivre \o/. Mais le résultat est nettement mieux que sans c'est sur. Par contre je penses que yadif=1 me suffira. (Ah et j'ai essayé mcdeint=1 c'est tout simplement invisionable... bon le =2 et =3 me donne un segfault mais je m'en plaindrais pas)
En ce qui concerne la TNT HD, le lancement devrait se faire en octobre au plus tard, et ce au niveau national de ce que j'ai compris.(Canal+ a déjà annoncé diffuser en HD sur les plages cryptées)
Bon et bien merci pour toutes ces infos
[^] # Re: Quelques idées...
Posté par gc (site web personnel) . Évalué à 2.
Mais c'est dingue ce yadif ! Je désentrelaçais mes vidéos mini DV (50 "demi fps") avec -vf lavcdeint, et c'est le jour et la nuit avec -vf yadif=1, le rendu 50 fps donne une impression saisissante.. et le ralenti à 50% devient en plus tout à fait regardable.. c'est assez dingue.
[^] # Re: Quelques idées...
Posté par Aefron . É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: Quelques idées...
Posté par gc (site web personnel) . Évalué à 2.
http://zarb.org/~gc/deint/view.html
- kerndeint c'est vraiment de la daube :)
- mcdeint=1 ne semble apporter aucune amélioration visuelle sur mon test : qu'en penses-tu ? [mcdeint=2 et mcdeint=3 faisaient un segfault]
- j'utilisais lavcdeint (pp=fd) mais je mettrais quand même yadif=0 devant maintenant
- le linear blend c'est vraiment le minimum syndical, dommage que ce soit le mieux que kino propose pour la visu lors du montage :/
[^] # Re: Quelques idées...
Posté par Aefron . É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: Quelques idées...
Posté par Aefron . É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: Quelques idées...
Posté par gc (site web personnel) . Évalué à 1.
Perso j'enregistre avec un mini DV Sony puis je vais du montage avec Kino, et effectivement dès que je fais des ralentis, ça devient l'horreur parce que Kino fait le ralenti "aveuglément" sur les fields. Ensuite je peux essayer de déinterlacer, c'est immonde. Je ne sais toujours pas vraiment quoi faire à ce propos en fait :/
# NSFW
Posté par Pierre Carrier . Évalué à -1.
# Avidemux
Posté par Moonz . Évalué à 4.
[^] # Re: Avidemux
Posté par niclone (site web personnel) . Évalué à 1.
# Pas si mal
Posté par niclone (site web personnel) . Évalué à 3.
Il est possible de faire une vidéo affichant des vecteurs de mouvements par dessus la vidéo original?
Bon après faudrait rajouter une détection de changement de plan...
[^] # Re: Pas si mal
Posté par Aefron . Évalué à 2.
Cela dit, il faut récupérer le .flv, pour faire ça...
[^] # Re: Pas si mal
Posté par niclone (site web personnel) . Évalué à 3.
# Vachement bien
Posté par mekare . Évalué à 7.
Mais plus sérieusement, voici mes critiques :
- Premier point : C'est super
- Ensuite comme dit plus haut le problème se situe lors des changements de scène ou le morphing est très visible (et très laid). Le top serait une détection de changement de scène afin de de pas créer d'image intermédiaire et de passer directement à la scène suivant.
- Et pour finir les bords sont gérés comme le reste de l'image ce qui donne un effet de bavure mais là je ne sais pas si un tel "défaut" peut être corrigé.
Encore bravo, c'est quand même pas mal du tout, en espérant que mes critiques t'aident un peu.
# Scene Cut
Posté par pepie34 . Évalué à 3.
Ca ma l'air pas mal du tout...
Voici quelques pistes:
1) est-ce qu'on peut pas recupérer des infos des données codées ? je pense notamment à l'estimation de mouvement et à la détection de scene cut ? (les I-frame ?)
2) L'effet de morphing est assez pertubant lorsque tu interpoles lors d'un scene cut. J'ai un peu bossé sur la détection de scene cut au LITIS avec des méthodes à noyaux, j'ai lu aussi pas mal de biblio sur des méthodes basées sur des MLP. Dès que je remets la main sur un article je t'envoie un lien.
3) Si on dispose d'une video encodée en tarkin (analyse en ondelette dans les dimensions 2D image + 1D temps) , comment se comporte une interpolation ondelette simple par rapport à ta méthode?
# Conférence vidéo du collège de France
Posté par liberforce (site web personnel) . Évalué à 2.
http://www.college-de-france.fr/default/EN/all/ger_ber/semin(...)
[^] # Re: Conférence vidéo du collège de France
Posté par David Tschumperlé (site web personnel) . Évalué à 2.
David.
[^] # Re: Conférence vidéo du collège de France
Posté par freejeff . Évalué à 1.
1) Tout d'abord, il faut segmenter l'image pour pour ne pas interpoler les parties fixes.
2) faire une détection de motifs. La plupart des mouvements sont des mouvements de corps rigides, sur une grande zone et des "déformations" sur des petites.
Il convient de traiter les deux différements.
Pour les mouvements de corps rigides des analyse du type intercorrelation sur des zone d'au moins 16 pixel marchera bien, ou une porcédure de tracking fonctionnerait.
Il suffirait ensuite de déplacer les "motifs" d'une image à une autre (le motif de fond de l'image 1 devient le motif de fond de l'image 2 et idem pour le premier plan).
Pour les déformations c'est un peu plus complexe, mais je suis prêt à t'expliquer si tu veux (de plus tu as reçu un mail de ma part ;)).
3) Reste ensuite l'iterpolation locale des niveaux de gris ( on peut utiliser la fonction interp2 de matlab, octave avec des champs de déplacment, sur une image ...).
Voila pour le gros du travail.
[^] # Re: Conférence vidéo du collège de France
Posté par David Tschumperlé (site web personnel) . Évalué à 1.
(ha si en fait).
David.
[^] # Re: Conférence vidéo du collège de France
Posté par David Tschumperlé (site web personnel) . Évalué à 4.
Je ne suis pas sûr que ta méthode marche forcément mieux, d'abord qu'est-ce qui se passe si la video contient des mouvements non rigides (genre vagues, etc..) ?
De même pour le problème ultra-classique des occlusions, tu vas certainement avoir des effects de ghost. Si tu as quelque chose qui tourne, ca m'intéresse pour comparer, mais clairement le problème du retiming n'est pas *simple*, ni même complètement résolu à l'heure actuel. J'avoue que j'ai un peu tiqué quand j'ai lu :
"Je pense que l'on peut faire assez simplement ce genre de chose :".
Si Stéphane Mallat (qui n'est pas connu pour être le dernier des imbéciles) a monté une boite Let It Wave qui s'occupe de ce genre de problèmes, c'est que ce ne sont pas des problèmes faciles. Enfin à ma connaissance, mais je me trompe peut-être.
David.
[^] # Re: Conférence vidéo du collège de France
Posté par freejeff . Évalué à 1.
Les algorithmes sont très simples et je t'en ai parlé dans un mail (xxxx@lmt.ens-cachan.fr)
Il est évident que cela demande du travail, mais ca peut marcher
"si la video contient des mouvements non rigides"
en fait il faut détecter ou l'on va résoudre le flot optique et quelles sont les fonctions de formes que l'on va utiliser pour interpoler le déplacement local (que l'on peut à la louche qualifié de déformation).
Pour l'instant dans mon "travail" je fais l'opération qui veut déterminer les meilleurs champs de déplacements pour une cinématique donnée, la partie interpolation de l'image intervient mais elle n'est la que pour pouvoir itérer (une fois la première valeur du champ de déplacement calculé on interpole l'image avec ce champ puis on recommence).
Donc en effet j'ai des algos (qui ne sont pas de moi ;-)) qui tournent mais il y a un travail d'adaptation conséquent, et je ne suis pas connu pour être une brute en programmation.
La première solution que je propose peut se faire en utilisant localement les algorithmes de résolution du flot optique présent dans opencv .... , ils peuvent aussi être recodés assez simplement dans Cimg.
En ce qui concerne l'utilisation de la norme MPEG-4, évoquée dans un autre post, c'est une idée brillante, mais qui demande de maitriser toutes les clef de ce format, c'est encore plus complexe que ce que je propose, on a déjà bien du mal à faire des opérations sur les images JPEG sont avoir à les décompresser alors allé faire un algorithme spatio-temporel en méthode inverse basé sur le MPEG-4, c'est pas pour demain.
Je suis désolé mais j'étais sur un spot wifi en conf' quand j'ai écris le précédent spot, je voulais juste dure qu'il n'y avait selon moi pas d'entraves théoriques.
[^] # Re: Conférence vidéo du collège de France
Posté par mammique . Évalué à 1.
1) Tout d'abord, il faut segmenter l'image pour pour ne pas interpoler les parties fixes.
2) [...]
3) [...]
Ça ressemble beaucoup à du MPEG-4 ta proposition d'algorithme... Du coup je me demande si ce ne serait pas plus cohérent d'encoder le film en MPEG-4 et d'insérer des trames intermédiaires calculées avec les vecteurs "réels" des images précédente/suivante ? En plus le MPEG-4 de donnera les images clés, donc plus de problème de transition... Je dis une bêtise ? Faut peut-être demander aux mecs du XviD, si faut c'est fastoche pour eux...
[^] # Re: Conférence vidéo du collège de France
Posté par NickNolte . Évalué à 3.
Son concept me fait penser grossièrement à la fonction "Motion Blur" de Blender, basée sur des masques, des vecteurs et au lieu d'un effet de morphing, on applqiue un effet de floue.
En tout cas, avoir un "retimer" dans Blender, Cinelerra voir en "standalone", serait la grande classe!
# Très bon!
Posté par ʭ ☯ . Évalué à 3.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# 50i vers 25p
Posté par pyrollo (site web personnel) . Évalué à 1.
L'interpolation ne sera plus temporelle mais spatiale (reconstitution des demi-images manquantes), ce qui peut donner un très bon résultat.
Ensuite, pour diviser encore par deux, peut être qu'un simple fondu donne un meilleur résultat qu'une interpolation (qui donne pas mal d'artefacts).
Tout ça c'est à condition d'avoir une source en 50i (vidéo) et non 25p ou 24p (cinéma).
[^] # Re: 50i vers 25p
Posté par Aefron . Évalué à 2.
... qui ne permet en outre, si on se limite à ça, que d'utiliser un seul coefficient de ralentissement, soit x1/2...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.