Bénéficie de 64 recommandations à propos de 55 messages
Je me permets d' ajouter, bien que je ne l'utilise pas, mais, l'ai essayé (suffit de télécharger), que Vegas Pro n'est pas à un tarif exorbitant mais, moitié prix de ses concurrents comme Premiere Pro par ex. Cependant, pour quelqu'un déja rôdé aux classiques, il faut se faire à son ergonomie ...
Liens commerciaux
Pour profiter des forums du Repaire sans les inserts pub il suffit de s'inscrire gratuitement.
Bénéficie de 0 recommandations à propos de 0 messages
Merci à Agdimage de me confirmer dans mes "conclusions" .
Peux-tu aussi confirmer mon "impression" selon laquelle les images obtenues par rendu M2T (rendu sans la moindre intervention sur le fichier d'origine) , sont plus saturées que les images d'origine M2TS ?? .
As-tu remarqué une différence de vitesse de traitement entre les versions "light" pour un rendu M2T et "pro" pour un rendu AVCHD ? ( pour un même projet évidemment ) .
Bonne journée : je vais te retrouver sur le forum Végas .....
Georges
Bénéficie de 0 recommandations à propos de 0 messages
Bonjour,
Envoyé par guy-jacques
Je me permets d' ajouter, bien que je ne l'utilise pas, mais, l'ai essayé (suffit de télécharger), que Vegas Pro n'est pas à un tarif exorbitant mais, moitié prix de ses concurrents comme Premiere Pro par ex. Cependant, pour quelqu'un déja rôdé aux classiques, il faut se faire à son ergonomie ...
Je ne peux m'empêcher de vous souligner que, pour un prix cinq fois moins élevé, Ulead Studio gère le format AVCHD en natif, en lecture et écriture, ce qui a pour avantage déterminant d'éviter tout transcodage sur les séquences ne faisant l'objet d'aucun effet de montage.
Bénéficie de 10 recommandations à propos de 8 messages
Moi qui n'en suis pas très friand habituellement je me demande si, à ce stade de la discussion, on ne devrait pas faire un petit sondage sur les softs qui montent l'AvcHd cités par Bob art là pour savoir celui qui remporte le plus les suffrages des Repairenautes
Bénéficie de 23 recommandations à propos de 20 messages
Envoyé par fpabernard
Bonjour,
ce qui a pour avantage déterminant d'éviter tout transcodage sur les séquences ne faisant l'objet d'aucun effet de montage.
Bonjour fred,
Tu soulignes là quelque-chose qui, à mes yeux, est fondamental. C'est pour ça qu'il faut être précis sur les mots employés.
En HDV le fait de ne pas réencoder une séquence lorsque celle-ci n'est pas modifiée sur la timeline s'appelle "smart rendering". Il y a alors simple recopie de la séquence.
Est-ce réellement ce que fait ulead pour de l'AVCHD ?
Bénéficie de 64 recommandations à propos de 55 messages
Que ce soit, je pense, en HDV comme en AVCHD, lorsqu'on procède à un élagage sur du "natif", la probabilité de tomber pil-poil sur des début/fin de GOP est faible.
A moins que le logiciel n'en décide par lui-même, un recalcul, au moins local de "GOP raccourcis" est nécessaire au moment (qui peut être longuet) du "rendu"...
Ce que fait un logiciel déterminé… est à explorer, et pourrait faire quelques petites différences ??
Bénéficie de 0 recommandations à propos de 0 messages
Guy-Jacques a raison, mais ce n'est pas nouveau : c'était déjà le cas en DV avec du MPEG2 ou du DivX (par exemple lorsque j'élague des séances TV enregistrées sur un boîtier enregistreur). En pratique, c'est transparent d'un point de vue perf de montage, et en visionnage aussi, sauf peut être après de multiples regénérations, ce que je n'ai pas eu l'occasion de pratiquer.
Bénéficie de 0 recommandations à propos de 0 messages
j'ai fait quelques manips : Je pense que Végas Movie studio platinium recalcule tout à chaque nouveau rendu en M2T . J'ai coupé mon fichier de test en une vingtaine de morceaux que j'ai mélangés . Le temps de rendu est exactement le même que le rendu soit fait de M2T en M2T sans modif , ou après mélange des morceaux . La copie sans recalculs du fichier (365 mégaoctets) ne devrait pas prendre plus de 1 minute (sur le même disque) .
J'ai aussi fait un test sur plusieurs générations : pas de dégradation sensible , avec mon moniteur , au bout de la 5ème génération ( en remélangeant à chaque fois les morceaux pour perturber les GOP's ).
Je vais continuer à faire joujou avant d'attaquer la "production" . Je "post" si je trouve encore des trucs amusants ...
Bonne soirée
Georges
Bénéficie de 64 recommandations à propos de 55 messages
Un petit correctif... pour ceux qui montent en DV et pourraient prendre peur:
c'était déjà le cas en DV avec du MPEG2 ou du DivX
C'est le cas en conversion à partir de DV vers MPEG2 ou MPEG4 [ DivX ou H264 entre autres].
MPEG2 et MPEG4 effectuent une compression "inter-images" où une seule dans un Group Of Picture est décrite de façon "intrinsèque" mais compressée, les autres en sont directement ou indirectement déduites, en principe en ne décrivant que les "vecteurs mouvement".
En HDV, par exemple, un GOP "résume" 12 images... En H264, ça peut être variable, mais on peut me démentir ( ! ).
En DV toutes les images possèdent chacune sa description intrinsèque, bien que "compressée".
Il s'ensuit que les images d'une séquence DV sont indépendantes, une séquence DV peut être arrétée sur n'importe quelle image.
Ce n'est pas le cas des séquences MPEG2 ( HDV ou vidéo SD pour DVD, entre autres) ou des séquences MPEG4 ( DivX, XVid, MP4, H264 dont AVCHD, etc.). Il faut donc stopper une séquence à la fin d' un GOP et pour ça, la procédure... dépend du programmeur... ou il a décidé de stopper sur un "GOP raccourci" pour que ça colle, ou la décision est de volatiliser les images ( moins de 12 = moins d' 1/2 s en 25ips), ou autre tour de passe passe ou le choix à l'utilisateur...
Alors, en encodant du DV en MPEG2 ou MPEG4, c'est selon le "codec" et les possibilités de réglages qu'il offre...
"On" rappelle que la compression du DV est MJPEG (la description numérique de chaque image est individuellement compressée selon la même procédure qu'une photo en JPEG).
Je tiens assez à exprimer de temps à autre que ce n'est pas l'image ( ou la vidéo) qui est compressée mais sa description [ les sténotypistes compressent les discours de conférenciers en temps réél et avec beaucoup moins de signes que l' écriture usuelle... et ils savent relire de façon à restituer le discours dans son intégralité... avec quand même de temps à autre une erreur... ça discute aussi entre eux et elles du meilleur "codec" !].
Pour Georges-J
Il y a deux ans, si je ne me trompe, Jean-Luc ( JLH37) a dirigé quelques complices pour mettre à mal une séquence HDV ( "mouette blanche sur bateau rouge et vert" ). La mise à mal ne consistait pas qu'en une simple recopie mais à effectuer un décalage collectif des pixels des images à chaque génération: en natif, les dégradations sont apparues assez rapidement en "travaillant" avec de bon codecs ou en DVCPRO HD ( moi ) on aboutit à des dégradations bien visibles en 5ème génération...
La procédure et le CR illustré de ces tests doivent toujours figurer dans une discussion de ce forum datant de cette époque.
Bénéficie de 0 recommandations à propos de 0 messages
Le problème soulevé par Guy-Jacques est bien celui où le fichier source utilise une compression à base de GOP (ce qui n'est pas le cas du DV, OK) : dans ce cas le "smart rendering" ne pourra pas être appliqué, pour ce qui est du début et de la fin de la séquence : si la 1ère image du fichier de sortie n'est pas une image clé du fichier d'entrée, il faudra bien la reconstituer dans le fichier de sortie. En fin de séquence, se pose aussi le problème du stoppage de la séquence de GOP, si la dernière image du fichier de sortie n'est pas la dernière image du GOP du fichier d'entrée.
Ai-je été clair ?
Guy-Jacques soulevait ce problème pour le smart-rendering de fichier HDV et l'AVCHD, je disais que ce n'était pas un problème nouveau car il se posait également et depuis longtemps pour le MPEG2 ou le DivX en SD (ou en HD) et que, tant d'un point de vue temps de traitement que qualité finale, tout cela était en pratique imperceptible pour moi, même si en théorie le problème existe effectivement.
Bénéficie de 130 recommandations à propos de 87 messages
Envoyé par fpabernard
Le problème soulevé par Guy-Jacques est bien celui où le fichier source utilise une compression à base de GOP (ce qui n'est pas le cas du DV, OK) : dans ce cas le "smart rendering" ne pourra pas être appliqué, pour ce qui est du début et de la fin de la séquence : si la 1ère image du fichier de sortie n'est pas une image clé du fichier d'entrée, il faudra bien la reconstituer dans le fichier de sortie. En fin de séquence, se pose aussi le problème du stoppage de la séquence de GOP, si la dernière image du fichier de sortie n'est pas la dernière image du GOP du fichier d'entrée.
Pas si sûr que cela.
Il me semble bien que c'est Baloub, justement, qui nous avait montré le contraire avec Magix. Les GOP coupés n'étaient pas reconstitués à la norme de douze images et la lecture n'en était pas affectée, y compris sur la caméra.
Si c'est bien Baloub qui nous avait démontré ceci, je lui laisse la parole puisqu'il participe à la discussion
Bénéficie de 0 recommandations à propos de 0 messages
Pour Guy Jacques .
J'ai été étonné de ne pas voir de grosse dégradation : il faut dire que les séquences sont relativement statiques . Ceci étant , je ne pense pas retravailler un montage 5 ou 6 fois ....
un dérushage , un premier jet en conservant le projet, et un retravail avec un second projet et en général je passe au rendu définitif . On est en train de pinailler !
Bénéficie de 0 recommandations à propos de 0 messages
On est d'accord ! Mon expérience vécue me montre qu'en pratique tout ces problèmes théoriques de GOP en smart-rendering n'ont pas d'incidence pratique.
Bénéficie de 0 recommandations à propos de 0 messages
Bonsoir,
Envoyé par baloub
En HDV le fait de ne pas réencoder une séquence lorsque celle-ci n'est pas modifiée sur la timeline s'appelle "smart rendering". Il y a alors simple recopie de la séquence.
Est-ce réellement ce que fait ulead pour de l'AVCHD ?
Je vous confirme que Ulead fait du smart rendering sur le format AVCHD, en indiquant d'ailleurs clairement les parties réencodées et recopiées à partir de l'original.
Mode linéaire
