[Tuto] Obtenir une vidéo 1080 50p (ou 50i) h264 de qualité

En effet, c'est comprimé... Quelle version de Vegas ?

Je peux faire des tests en 8c 9d 9e et 10a

 

C'est la version 10.0a 64 bits, mais j'ai la lême chose sur la 9 (en 32bits).
Je te met le petit bout de vidéo en téléchargement (~40 Mo). (c'est un m2t coupé avec tsdoctor, d'où le remultiplexage en .ts)

 

Rendu en MPEG2 et AVI non compressé. Pas de changement significatif constaté.

La seule "anomalie" c'est en mettant côte à côte les rendus et l'original avec le projet en mode 32 bit linéaire: ce qui est en AVI n'est pas ajusté et reste conforme à l'original en mode 8 bits. Les autres c'est clairement étendu mais pas dans le sens de ce que vous observez. Je l'avais déjà remarqué avec d'autres trucs sans tester plus loin. Comme c'est un mode de fonctionnement qui est pour moi marginal je ne me suis jamais préoccupé de ca.

Bref:
8 bit: ok
32 bit gamma 2.22: ok


Ton ts à gauche
le rendu mainconcept au milieu
l'AVI à droite


Ma machine est très peu "équipée": pas de pack de codecs, le minimum d'outils dont j'ai besoin et seulement un NLE. Il pourrait il y avoir un codec qui vient semer sa panique au milieu mais cela reste pure supposition de ma part.

 

Je crois que j'ai compris pourquoi on ne voit pas la même chose.
J'ai fait la même manip que toi (tout remettre dans vegas) et ça donne ça :


Dans l'ordre : original ts, recompression m2t, AVI non compressé.
Constatation :
- Pas de différences DANS vegas
- La lecture des fichiers montrent les différences

Les players PC ou hard voient une différence entre :
original / recompressé m2t d'un coté et avi non compressé et avi x264vfw d'autre part.

Redépose des clips sur la timeline, vegas ne montre pas de différences.

Conclusion : bé je sais pas.

 

Les players font leur sauce de conversion d'espace de couleur et pas toujours comme il faut. Exemple x.264 dans de l'AVI, marqué comme YUV (16..235) mais pas converti en 0..255 alors que le même stream dans un fichier mp4 le serait. L'AVI non compressé c'est du RGB, le player ne doit pas faire de conversion puisque on est censé être déjà dans l'intervalle 0..255. Pas de tests exhaustifs là dessus de mon côté mais c'est ce qui explique certaines surprises déjà constatées chez moi.

Sauf demande explicite, Vegas ne fait absolument rien.

En bref, il faut être conscient de ce qu'on lui demande et des conséquences habituelles:
- réduction de dynamique
- clipping
- images délavées
- altération sensible de la chroma

Perso ca me prend un peu la tête et mon dilemme habituel c'est le choix entre montage dans l'espace PC RGB ou studio avec prévisu corrigée.

 

Ça, je veux bien te croire

Il n'y a qu'avec Vegas que j'ai vu apparaître ce genre de problème.
J'ai fait un dernier essai qui me fait dire que vegas fait bien quelque chose sur certaines vidéo à l'insu de notre plein gré
Chargement du même clip dans :
- vegas
- magix
- edius
- corel

Sauvegarde de 2 secondes en AVI avec le codec canopus HQ pour tous les softs.

magix / edius / corel produisent un AVI totalement identique. Celui de vegas présente la réduction 0->255 16->235

Si je remet les 4 avi et l'original dans vegas, la prévisu donne :
- avi magix / avi edius / avi corel : identiques et "nerveux"
- avi vegas / original : identiques et plus fades.

 

Là j'ai une autre lecture: cela veut dire que magix, edius et corel ont fait la conversion 16..235 -> 0..255 avant de refiler le flux au codec alors que Vegas n'a rien fait.

Refais le rendu via Vegas avec le plugin niveaux en mode sRGB -> cRGB sur la prévisu et refais ta comparaison des divers rendus avec zéro conversion sur la prévisu. Je mange mes chaussettes si ce n'est pas ce à quoi je m'attends. (pourvu que ca marche... )

Ton ts que j'ai utilisé en test a des niveaux qui sont largement en dehors des limites valides d'un échantillonage YUV. Pour moi c'est un problème si je dois fournir pour de la diffusion TV, du DVD ou pire un filer youtube et similaires qui va lui même réappliquer systématiquement une nouvelle conversion 16..235 -> 0..255

J'ai une approche assez conservatrice pour éviter la dégradation des images: réduire au maximum tout risque de clipping. On en revient au choix des propriétés d'un projet sous Vegas:
- avoir une conversion RGB studio vers RGB pc qui implique qu'on bosse en 16..235 et qu'on fait confiance aux autres outils censés respecter les standards
- ne rien convertir du tout et décider quoi faire en fonction des sources et de la destination en diffusion

Je reconnais que Vegas n'est pas très "user friendly" de ce côté là et ce n'est pas explicitement décrit dans la documentation mais on a la chance de garder la maitrise de ce qu'il doit faire et à quel moment. Enfin, moi ca me plait maintenant que j'ai compris ce qu'il se passe là dedans et je peux dire que j'y ai passé du temps en lectures et divers tests.

L'idéal serait qu'il ait, au niveau projet, un mode tout automatique qui passe dans la plupart des cas et un mode comparable à l'actuel où la connaissance de ces particularités devient incontournable et profite au monteur.

Ton ts est "vendu" comme de l'YUV REC.709, un simple coup d'oeil sur les scopes montre que le signal est largement en dehors des clous.

 

Peut être, mais alors ça impose de toujours rester "dans" vegas et de se méfier des imports externes (en AVI). De même les exports (toujours en AVI) vers d'autres softs sont à manier avec prudence.

Ça me donne des vidéos identiques mais ça n'est pas une surprise car c'est précisemment le but de la manip décrite sur le site.

Je ne vais pas me prendre la tête plus longtemps avec ça. Il suffit de savoir que la précorrection permet de se tirer d'affaire dans ce cas précis.

De mémoire, c'était filmé avec une HC1 et monté avec vegas (7 je crois).