Combien de générations en montage virtuel ?

Merci à JLH37
Je crois comprendre que:
Premier cas.
En dv _ capture _ montage en cut sans effets _ puis rendu et export sur bande = 1ere génération.
Mais si j'applique des effets sur mon montage, puis export sur bande, cela sera considéré 2me génération à cause des effets qui modifient la structure des images.

Deusième cas.
Si export du même montage vers dvd avec effets ou sans effets cela est considéré second génération dû à la compression mpeg2 ( modification de la structure de l'image ).

Troisième cas.
Si je réintroduit sur la TL le montage précédemment exporté sur bande et que je le modifie, à l'export il sera considéré deusième génération et autant de fois x modif appliquées.

J'entrevois virtuellement le mécanisme de la dégradation des images numériques car il n'y a pas de perte de l'information mais nouvelles informations qui modifie l'image.( je le comprends comme ça..)

Pour le hdv effectivement la modification du gop me semble plus facile a comprendre après tes explications.

Merci encore
gac30

 

si on supprime tous les fichiers de prévisualisation avant l'export ne se retrouve ton pas avec une seule génération a part celle du camescope et de la transformation du film pour le dvd

 

c'est pas dit que ca marche, mais c'est au moins la certitude que le programme n'utilisera pas d'autre fichiers que les sources.

 

Problème ardu …

… car déja, les termes sont quelque peu flous et en partiiculier cette notion de "génération".
Déja, la "première", personnellement, j'aurais tendance à considérer que c'est l'enregistrement sur bande dont … quelqu'un sait-il comment il est constitué ?

Je crois savoir que le camescope transmet du MPEG 2 TRANSPORT STREAM par ieee1394 …
Ce MPEG-TS est découpé en "paquets" de 188 octets dont 184 sont de "l'information numérique" qui multiplexe Vidéo et Audio, les 4 autres constituent une "entête" significative pour la transmission, mais n'entre pas dans les GOP de vidéo. Selon moi, (je n'écris pas "moi" par prétention mais par précaution : je peux peux être dans l' erreur) il faut déja un décodage pour réconstituer les GOP vidéo et audio avant de les travailler en "natif". [Baloub a déja signalé et effectué le dé mu-xage…]
Je ne suis donc pas certain qu'un transfert sur bande d'une séquence "native" sur la Time-Line ne demande pas un ré-encodage de type MPEG2-TS dont l'enregistrement serait déja une seconde génération… qui, théoriquement, ne devrait pas être altérée si ce "dec-cod" est correctement effectué et si les"bornes" de la séquence correspondent à des GOP…
Comme je peux capturer et installer du "natif" sur la TimeLine, dès que le portable me revient, je fais un petit test, bien plus simple que celui de Baloub pour voir si, avant export d'une séquence non modifiée, il y a "rendu" …

 

Bonjour guy-jacques,

En fait le test que j'ai fait est très simple :

Simuler des montages cut plus ou moins "nerveux" (séquences de 8s, 4s puis 2s) et voir ce qu'il se passe au niveau des GOP avec un logiciel qui ne réencode pas systématiquement.

Même avec des séquences de 2s, une bonne partie du flux d'origine n'est pas réencoder. On approche toutefois des limites du système.

Ajout : Je viens de faire un test avec des sequences de 1s : Le smart renderer ne s'est pas enclanché et le fichier a été totalement réencodé. Ca parait d'ailleurs assez normal.
J'ai obtenu des GOP réguliers de 12 images. Curieusement ils sont tous clos. Peut être une particularité de l'encodeur (mainconcept) ou un mauvais paramétrage...

 

Bonjour Giroudf
"si dans ton programme d'edition tu appliques une correction de couleur et un effet, on pourrait considerer que tu fait deux generations puisque l'image est calculee deux fois."
Ceci ne s'applique pas ni à Premiere, ni à Final Cut.

Tous les calculs et effets sont appliqués à l'image décompressée en YUV ou RVB dans la mémoire vive (RAM).
Donc 1 seule décompression, et 1 seule recompression, quels que soient le nombre d'effets.

Ce qui est difficile, c'est de determiner l'ORDRE d'application des effets (du moins de Premiere 3.0 jusquà 6.5, après je ne sais pas)

A+

 

Non, G-J, il n'y a pas réencodage, mais encapsulage dans un "conteneur". Exactement comme en DV.

La copie par IEEE1394 s'apparente à un transfert de fichier...

A+

 

Je m'interroge … mais, "transfert" me semble "simple"…

Je pense exact aussi qu'un fichier DV n'est pas aussi simple qu'un flux de données numériques ne décrivant que les images l'une après l' autre et qu'en outre, il y a "encapsulage", d'ailleurs selon MOV ou AVI avec ou non audio séparé…

L'encapsulage existe aussi pour les fichiers HDV, il y en a des différents traitant le MPEG 2 -TS dont M2T …
Ce qui je précise encore, je pense, rend un peu plus complexe ce "natif", c'est cette transmission par paquets où alternent (j'en ignore le rythme) des données audio et des données vidéo chacun précédé d'une entête …
Il me parait donc nécessaire de retrouver les GOP (et l'audio) démuxé depuis ces paquets … et ensuite de reconstituer les paquets pour un fichier nouveau où effectivement, si non intervention, les données numériques vidéo ou audio devraient être les mêmes.
Cependant, je crois que ça demande "lecture" et "réécriture" … "actives" …

 

a ST65
citation:
Tous les calculs et effets sont appliqués à l'image décompressée en YUV ou RVB dans la mémoire vive (RAM).
Donc 1 seule décompression, et 1 seule recompression, quels que soient le nombre d'effets.
-------------------------------------
Je dirais que c'est ok pour du DV, quand chaque image peut etre isolee separement en memoire. on met l'image en memoire et on applique l'effet dessus.
Je serais moins affirmatif quand il s'agit d'un format GOP.
Pour avoir l'image, il faut demonter le GOP. Et il faut le remonter ensuite.
Et tous les effets ne s'appliquent pas forcement au GOP entier.
Parx expl une correction couleur qui s'applique sur tout le GOP, mais un titre ou un transition qui n'utilise que la moitie du GOP.
En plus il faut etre certain que la representation de l'image en memoire est sans compression (ce dont je doute).
Si on travaille en memoire avec un format pixel/RGB, ca doit etre ok.
Si on travaille avec un format YUV, il y a de grande chance pour que le programme rencode entre chaque effet un format YUV.
Je dis ca parce qu'il me semble que peu de soft savent appliquer des effets correctements, a la maniere de shake, qui pre-calculais la somme des effets pour n'appliquer que le stricte necessaire.
Par exemple avec shake si tu appliques 2 effets qui s'anullent, shake ne fait aucun calcul.

 

Bon, je viens de faire le test et ça m'a posé quelques problèmes...

J'ai mis sur la timeline tout les fichiers à la queue leu leu (original, sequence 8s etc...). J'y ai même ajouté le séquence 1s qui avait été complètement réencodé.
Au total 5 fichiers de 1mn, soit 5 mn.
J'ai ajouté, au début de chaque fichier, un panneau indiquant le nom du fichier d'origine. Durée 2s en superposition.

Export de ce fichier (réencodage pendant 2s, puis smart renderer à chaque minute), puis transfert sur la caméra dans la foulée.

En regardant ensuite la bande sur le VP, il me manque environs 4s au début. (j'ai utilisé une bande neuve). Sinon tout le reste est correcte. Pas de saccades ou autre macroblocs.

Je fais alors un transfert sur le PC avec Magix et là, surprise, il me manque 35s sur la durée totale. Je passe sur les divers essais que j'ai fait mais la conclusion est assez rigolote : c'est la routine d'acquisition de Magix qui n'apprécie pas les GOP trop variables et les vire. Un comble.
J'ai refait une acquisition avec capdvhs et là aucun problème. Si on excepte les secondes manquantes du débuts, la structure des GOP est la même entre le fichier envoyé à la caméra et le fichier réimporté sur PC depuis la caméra.

Les deux zip ci-dessous :
- rendu envoyé à la caméra : gop_envoye_cam.zip
- réimport sur PC : gop_provenance_cam.zip

Conclusions :
- Magix va devoir revoir sa routine d'acquisition
- Les GOP non conforme en taille ne semble pas perturber le camescope.

 

Meme pour une seule image traitée, il faut decompresser intégralement le "group of picture" soit 12 images chez nous.
C'est aussi pour cela que le traitement demande une puissance monstre coté processeur et une bonne quantité de RAM.
Chaque image HDV etant 4 fois celle du DV, cela donne (4*12) 48 fois plus de données à traiter qu'en DV, pour une image.

YUV ou RVB ne sont pas compressés ou encodés. C'est juste une conversion "d'espace colorimétrique"

A+

 

"mais chaque soft va le décoder a sa manière car il y a interpretation des GOP (group of pictures) peut etre meme que 3 aquisitions du meme rush sur la meme machine ne seront pas identiques a 100% "

C'est, bien sur, totalement faux !

Le décodage ne laisse aucune place à la fantaisie ou l'interpretation. C'est une routine mathématique complexe, mais fixée par avance. Pour un meme fichier mpeg2, TOUS les décodeurs donneront le meme fichier décodé !
Il ne faut pas confondre "décodage" et "affichage". Les lecteurs de DVD ont des fonctions d'amélioration de l'affichage qui n'ont rien à voir avec le décodage.


A+

 

citation:
YUV ou RVB ne sont pas compressés ou encodés. C'est juste une conversion "d'espace colorimétrique"


Je crois que si. En dehors de l'espace couleur, il doit y avoir une difference de traitement.
Un pixel RVB a ses propres valeurs, un pixel YUV n'existe en fait que dans le bloc 4:2:0 dans lequel il est compresse. ca doit surement faire une difference.
Sinon quel avantage d'acheter un codec intermediaire (4:2:2 par expl) , si finalement le programme ne voit pas la difference et qu'il travaillerait avec une reso full 4:4:4 en pixel discret quelque soit l'origine de l'image ?

 

Tu fais une grosse confusion entre les calculs en RAM et codec intermédiaire !

pour du HDV traité en natif, le schéma doit etre le suivant :

mpeg2 natif, YUV 4:2:0 -> decompression en RAM en YUV 4:2:0 si l'effet peut travailler dans ce format, sinon decompression en RVB donc equiv à 4:4:4->application du ou des effets ->retour en mpeg2 YUV 4:2:0

Et pour du HDV avec codec intermédiaire, le schéma est le suivant :

mpeg2 natif, YUV 4:2:0 -> decompression ->recompression codec intermédiaire 4:2:2 -> decompression en RAM en YUV 4:2:2 si l'effet peut travailler dans ce format, sinon decompression en RVB donc equiv à 4:4:4->application du ou des effets ->recompression codec intermédiaire 4:2:2->recompression finale en mpeg2 YUV 4:2:0 pour retour sur bande


légende :
en NOIR, travail sur fichier (disque dur)
en ROUGE, travail en RAM

ouala