[Problème] Inversion d'ordre des champs aléatoire avec timestretching video !!

Bonjour,

je suis confronté à un gros problème avec Vegas 9 pro.
J'ai effectué un montage sur la base d'images tournées en 1080i 24 mbps en AVCHD.

J'ai par moments eu besoin d'effectuer du time stretching sur certaines séquences afin d'obtenir des ralentis, ou tout simplement pour recaler l'image au son à cause de la dérive des horloges (enregistrement audio numérique effectué avec une autre bécane, un multipistes, sans liaison de synchro avec la caméra). Il se trouve qu'avec ces ralentis, toutes les 2 ou 3 minutes (alors qu'il n'y a aucune coupure entre chaque passage), l'ordre des champs saute et se met à l'envers (donc saccades)...Puis se remet à l'endroit (plus de saccades), puis se remet à l'envers...Etc.

En somme, je soupçonne Vegas de faire son time stretching en décalant par frame et non pas par double frame, ce qui inverse l'ordre des champs régulièrement sans contrôle !!

J'ai essayé l'option "ajuster média source pour mieux coordonner le projet ou les paramètres de rendu", mais cela n'aide en rien.

Il ne sert à rien d'inverser l'ordre de champ sur le fichier puisque dans ce cas, les saccades interviennent aux endroits ou il n'y en avait pas, et vice-versa.
J'ai pensé à inverser l'ordre de champ aux endroits où ça s'inverse en créant des nouveaux clips, mais visiblement ce n'est pas faisable sur vegas d'intervertir sur des clips d'un même fichier (ou alors je ne sais pas comment faire ! j'ai pourtant cherché partout !) : impossible de changer upper field first ou lower field first sur des clips découpés sur la base d'un même fichier (rush d'une heure subdivisé en clips). On peut inverser ces paramètres PAR FICHIER, bien sûr, mais pas par clip de fichier idoine. Et donc, inverser l'ensemble des clips ne peut pas m'aider à résoudre mon problème...

Que faire ??? Je suis désespéré de faire des renders pour rien (je n'arrive pas à visualiser ce problème sur la fenêtre de prévisualisation pour couronner le tout).
...et en plus c'est urgent...
J'ai besoin d'un avis d'expert Vegas pour me sortir de cette mouize !!

Help !!

 

Salut,

Curieux, ce phénomène qui était connu sur des clips en mode reverse a été corrigé depuis des années...

Je ne suis pas un expert mais pas vraiment n00b non plus. Donc:

1. Sans CRT en prévisu, pour détecter des problèmes d'ordre de champ voir ce post.
2. L'option 'ajuster machin' n'est qu'un crop automatique pour caler sur le PAR du projet ou du rendu.
3. Tu ne pourras pas corriger en inversant l'ordre au niveau clip, comme tu l'as constaté cela agit au niveau média.

Perso, je préfère recaler en agissant sur l'audio en mode élastique pro, c'est bluffant...

Cela dit ca serait bien que tu donnes des infos sur tes rushes et les paramètres de ton projet. Le time strech j'en use et en abuse parfois avec du 50i (LFF ou TFF), du 25p et autres avec tout ce monde mélangé sur la même TL sans avoir jamais eu un seul souci.

 

Pour ma part je ne souhaite pas stretcher le son car c'est de la musique...Si l'oeil n'est pas sensible à un décalage d'1/25ème de seconde de temps en temps pour recaler l'ensemble, l'oreille est bien plus sensible au moindre étirement et même si le mode élastique est effectivement plutôt performant, il ne le sera pas assez pour mon projet !

Les rushes sont composés d'un fichier d'une heure + 5 autres plus courts, tous au format AVCHD 1080i 24 Mbps .
J'ai aussi 2 fichiers qui proviennent d'une caméra au format PAL mais leur usage est anecdotique dans le projet.

Le fichier principalement stretché, c'est celui qui est en AVCHD, il dure une heure, à cause des dérives des horloges son et vidéo. Le fichier est mis en quasi intégralité, il est pour ainsi dire divisé en quelques petites parties au début, ainsi que deux grosses parties ensuite, qui sont stretchées. Ce qui fait que le stretch video s'effectue doucement mais sûrement sur une plage de 30 mn mais avec un coefficient tout petit.

A la prévisualisation ça passe pourtant bien (j'ai fait comme spécifié sur le forum).

Les paramètres des fichiers :

J'ai paramétré sur Vegas Pro 9.0e les fichiers AVCHD en Upper Field First, de même pour les fichiers PAL (après avoir vérifié sur Gspot 2.71a - qui au passage ne me donne les infos de champ que sur les fichiers pal, gspot ne gère pas le avchd visiblement).

Les paramètres du projet :

fréquence d'image 25,000
ordre champs : champ supérieur en premier
rapport L/H pixels : 1,000 (carré)
Format pixel : virgule flottante 32 bits (plage entière) -- ça donne une bien meilleure image notamment niveau profondeur des noirs, ceci dû à l'enregistrement en XV-color), Vegas recommande l'utilisation de ce mode pour les enregistrements XVycc ou 10 bits.
Nota : j'ai essayé en 8 bits, le problème de saccade reste le même.

Gamma composite : 1,000 (linéaire)
Qualité Rendu en res.intégrale : Optimisée
Type de flou de mouvement : Gaussien
Méthode de désentrelacement : Aucune
Ajuster média source pour mieux coordonner le projet ou les paramètres de rendu : coché

Et pour le rendu, j'utilise le codec sony AVC, en mode m2ts,

Format : AVCHD
Débit binaire : élevé
Profil : CABAC
Fréquence d'image : 25
Rapport L/H Pixels : 1,000

Pas la peine de donner les précisions pour l'audio
et pour l'onglet système : format MPEG-2 transport stream (m2ts)

voilà...merci de votre aide...Si vous avez une astuce pour contourner ce bug...

 

Je m'insère dans votre conversation technique pour un détail.
J'ai paramétré sur Vegas Pro 9.0e les fichiers AVCHD en Upper Field First, de même pour les fichiers PAL (après avoir vérifié sur Gspot 2.71a - qui au passage ne me donne les infos de champ que sur les fichiers pal, gspot ne gère pas le avchd visiblement).

Tu as l'air de dire que ton PAL est en SD et non en HD (même si ce n'est qu'une facilité de langage pour ce dernier).
Or en SD c'est généralement Lower Field First.


Tu dois avoir une super oreille de cétacé pour distinguer un mini allongement de l'audio sur 1 heure. Moi je peine pour 100 fois moins. Et encore parce que je le sais et que je veux bien l'y entendre.

 

Donc on peut supposer que l'origine du problème est côté rendu.

GSpot est vieux, trop... Mediainfo peut le compléter avantageusement.

Perso je choisirais une méthode de désentrelacement, c'est encore obscur chez moi mais j'ai constaté des surprises et ce uniquement en fin de process. Je ne prétends pas que ce soit la solution mais ca vaut le coup d'essayer.

Le phénomène est-il reproductible avec un petit bout de ce rush ?

 

Le phénomène est reproductible en rendant juste un petit bout, précisément aux endroits où cela défaille de la même manière sur le rendering total du projet. ce qui signifie que cela vient de vegas...j'ai aussi essayé d'autres types d'encodages mais le problème reste le même.

Je vais essayer avec les méthodes de désentrelacement...Ca me paraît biscornu de devoir désentrelacer pour réentrelacer ensuite à l'encodage (puisqu'on engendre des imprécisions en créant artificiellement des trames paires et impaires "bouche-trou").
Surtout que si il y a inversion des champs, alors au réencodage, je risque par moment de récupérer les bonnes lignes de pixels et par moments celles qui sont interpolées...
Ca ne résoudra pas le problème de fond...
Mais je vais tout de même expérimenter avec cette fonction pour voir, on ne sait jamais...

 

Haha ! J'ai sans doute des oreilles de cétacé...Je suis ingénieur du son de métier, ceci explique cela ! Mais tout de même, par expérience, tout stretch audio (même peu élevé) engendre des légers prééchos ou des sortes d'attaques réverbérées dans le son (selon le pourcentage de stretch, c'est plus ou moins audible) alors qu'en stretchant la vidéo, les artefacts sont bien moins détectables, surtout si l'on doit décaler seulement de 2 ou 3 images sur 1 h !
Pour moi y'a pas photo, la règle est qu'il faut stretcher la vidéo et jamais le son ! (et surtout si c'est de la musique et qu'on se fait chier à faire un enregistrement en 24 pistes et tout un mixage derrière !!). Quelle belle invention, le video stretching ! Les ralentis sont époustouflants car les images intermédiaires sont interpolées sur le rendering, c'est génial ! Et puis pour la dérive synchro audio/vidéo, c'est on ne peut plus transparent...QUAND CA MARCHE BIEN !!!


Pour en revenir à mon problème :

Les vidéos dites "Pal" (simplification de langage, effectivement), sont effectivement en SD (720x576). J'ai bien revérifié sur Gspot, elles sont bien en Top Field First.

J'ai eu une idée...Intuition ? J'ai viré tous les rushes inutiles qui étaient en SD sur la ligne du dessus (piste qui était en mode de non lecture, avec le petit "sens interdit"), ainsi que la piste son correspondante (idem).

J'ai renderé l'ensemble de la vidéo...(sans aucune option de désentrelacement, comme suggéré précédemment) Et là...Miracle...Les soucis ont visiblement disparu !!!

Ce n'était pourtant pas un problème mémoire, j'ai ce qu'il faut, le PC est musclé, et l'indicateur de mémoire ne saturait pas.
Si les fichiers SD avaient été Lower Field First, ça aurait pu expliquer le bug (genre, vegas tiendrait compte de la piste vidéo du dessus (SD) et répercuterait les changements de champs sur la piste vidéo du dessous (montage majoritairement HD, avec 2 rushes SD).
En tout cas, avec cette manip, sur le montage rendu, les rushes SD ne sont pas saccadés (ils sont paramétrés pour être lus Top Field First), tout à l'air OK.
Idem pour la HD.
Je vais essayer de comprendre le pourquoi du comment et je vous le ferai savoir si il y a un lien de cause à effet avec les lignes de montages inutilisées : ça peut toujours servir.
J'ai encore des heures à monter pour les parties suivantes, et les cas vont être similaires, j'aurai donc loisir de tester à nouveau tout cela et vous en dire plus !
Le topic n'est donc pas fermé mais ce sera le cas dès qu'on pourra expliquer le pourquoi du comment ! Si vous avez des commentaires à ce propos, n'hésitez pas (notamment des exemples de cas similaires sont les bienvenus !).

 

Heu ... M'sieur !

J'ai renderé l'ensemble de la vidéo

Le vrai verbe a été mis à l'envers en anglais (ils roulent bien à gauche, non ?). Donc à l'origine (1066) ce n'est pas "render" mais rendre.
Tu peux donc dire j'ai rendu sans te forcer !
Ça fait plus obtus, plus vomi, mais également plus couillu.

D'ailleurs en Grande Breizh c'est aussi toujours centre et non le "center" des expatriés dans l'ouest profond.

 

Merci pour cette petite leçon de français, cher Agdimage !
Pour ma part, il m'arrive d'aimer les anglicismes, et je les assume totalement quand je les utilise, puisqu'ils sont utilisés sciemment. Personnellement, j'utilise le verbe "renderer" car justement je n'aime pas l'expression franco-française officielle qui n'est d'ailleurs elle-même qu'un anglicisme lexical...L'expression "rendre" est au final encore plus impropre en terme de traduction, à mon sens. Comme tu en fais allusion, l'expression "rendre" fait référence, d'une part au champ lexical de la maladie gastrique, et d'autre part, elle induit une confusion avec le fait de "rendre à quelqu'un" son objet (ex: j'ai rendu tel et tel projet). Donc...(hirps...) Désolé, mais pour ma part, je préfère continuer à utiliser l'expression : "J'ai renderé le projet", car même si l'anglicisme est plus proéminent phonétiquement et que l'expression ne veut rien dire pour un français non-spécialiste, elle me parle plus personnellement !

Tu as bien fait de t'exprimer, c'est légitime ! Un homme averti en vaut deux...Mais...Ne sortons-nous pas un peu du sujet de base ?...Le forum repaire.net est un forum avant tout technique...Alors...Restons dans la technique vidéo pour les prochaines réponses, les amis, plutôt que de nous perdre à nouveau dans des propos qui concernent davantage la langue française et qui noient la clarté du topic ! "Yes" ?!


A bientôt pour vos réponses techniques !