Combien de générations en montage virtuel ? - Page 2

gac30 · #31 08/10/2006, 01h13

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

renardm · #32 08/10/2006, 06h41

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

giroudf · #33 08/10/2006, 11h26

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.

guy-jacques · #34 08/10/2006, 11h37

… 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" …

baloub · #35 08/10/2006, 14h30

Bonjour guy-jacques,

je fais un petit test, bien plus simple que celui de Baloub

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...

JLH 37 · #36 08/10/2006, 15h45

Bonjour,

Hé bien tu vois, gac30, ta question que tu qualifiais "pour les NULS" ne semble pas aussi simple qu'il y parait si on lit les quelques interventions précédentes.

Avant de revenir sur les réponses que tu as faites, je souhaiterais préciser ou proposer quelques points.

Pour Philippe Chevrier. En fait non ce n'était pas la phrase que tu cites mais la chaîne de conversion proposée par ST65 où l'on voit apparaître une dégradation dès la premiere génération. Je comprends bien, à priori, ce qu'il veut dire mais cela peut embrouiller les esprits vis à vis du problème posé qui est de mesurer la dégradation des générations successives par rapport à la premiere qui est notre témoin de départ.

Et il va falloir aussi que nous soyons tous d'accord sur les numéros d'ordre de génération car je lis que Giroudf nous propose une "génération 0" ce qui ne va pas nous simplifier la tâche. En fait, j'ai toujours appris que le premier fichier vidéo créé (que ce soit en analogique ou en numérique) portait le nom de premiere génération. Tout comme on parle de matériel de premiere génération. Ceci n'est pas très important en soi mais il faut que l'on se mette d'accord, sinon il va y avoir, non pas un conflit, mais un décalage de générations.

Pour le moment reprenons les réponses de gac30 d'une façon simple et sans rentrer dans les considérations spécifiques du hdv.

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.

Ceci est parfaitement exact et il n'y a rien à ajouter. En ce qui concerne un empilement de plusieurs effets sur la time-line je ne suis pas d'accord avec Giroudf lorsqu'il émet la théorie que ceux-ci vont entrainer plusieurs générations. Même si tu fais un rendu en cours de montage (si le temps réel ne passe plus) et que tu décides d'en rajouter un après, le logiciel va refaire un rendu à partir de tout les effets depuis le départ et refera donc uniquement une deuxième génération, le rendu précédent ne servant à rien.

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 ).

Là, la réponse est plus délicate. Dans ta premiere question tu semblais partir d'un rendu fait systématiquement puis export bande ou export (et authoring) dvd. Dans ce cas, si il y a effet ce sera une troisième génération.

Mais si cela est fait directement d'après la time-line avec encodage et authoring intégrés au logiciel de montage, cela nous renvoit à la question de renardm.
On peut considérer en effet que dans ce cas le logiciel ne va pas servir des fichiers de rendu du format originel mais refaire un rendu directement sur le format de sortie et donc nous serons en deuxième génération. C'est ce qui semble se passer sur Premiere, car lorsque j'encode directement de la time-line, j'obtiens exactement le même temps d'encodage que les effet aient été calculés ou non. Et le logiciel ne fait aucun fichier de rendu si ceux-ci n'ont pas été effectués préalablement. Mais je ne sais pas si tout les logiciels procèdent de la sorte.

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.

Ici pas de problème, c'est exact. Et c'est comme cela que l'on va faire des tests de tenue qualitative en fonction du nombre de générations effectuées.

Revenons au cas particulier du hdv.

Philippe Chevrier et Guy-Jacques soulèvent un point qui ne m'étais pas venu à l'esprit. Il pourrait y avoir une dégradation lors du transfert de la bande vers l'ordinateur. Là, j'avoue que je suis perplexe car on devrait recopier le fichier tel qu'il est informatiquement sans aucune intervention d'un encodage quelconque puisque le logiciel va travailler en natif. Ou alors il ne s'agit plus d'un transfert mais d'une renumérisation du signal.

Là je ne suis plus qualifié pour donner un avis pertinent et vais donc écouter les explications complémentaires des tenants de cette théorie car elle me surprend un peu.

Le test de Baloub est extrèmement intéressant. Il montre sans ambiguité, me semble-t-il, que les exports du logiciel Magix se font effectivement sans aucun recalcul et que l'on se retrouve avec des fichiers dont la taille des GOP est complètement différente aux endroits des points de coupe.

Mais que se passe-t-il si l'on fait un réexport caméra. Baloub, aurais-tu la gentillesse de compléter ton test de la manière suivante :

Prendre le fichier contenant les GOP disparates, faire une capture sur la caméra puis réimporté cette capture sur l'ordinateur. Ensuite passer cette capture à l'analyse et nous dire si le fichier a toujours la même structure.

Ne pouvant le faire moi-même car je n'ai pas de logiciel traitant le natif, je t'en remercie d'avance.

Posté par Philippe Chevrier

je pense pas q'un amateur sur son monage de film de vacances pourra remarquer la différence entre l'original et la copie (surtout que n'ayant pas encore de chaine complète ce sera souvent un DVD SD 16/9em qui servira de master pour distribuer a la famille.

Oui, tout à fait d'accord, dans ce cas le montage en natif sera très largement suffisant et je n'irai pas conseiller un éventuel surcoût conséquent pour du montage en codec intermédiaire qui n'apportera quasiment rien en termes qualitatifs sur ce type de production.

st65 · #37 08/10/2006, 20h00

Posté par giroudf

on peut considerer qu'en digital, une generation est le recalcul de l'image.
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.
dans le cas d'une video non ou tres peux compressee, ca n'est pas visible.

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+

st65 · #38 08/10/2006, 20h04

Posté par guy-jacques

… 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…

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+

guy-jacques · #39 08/10/2006, 20h38

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" …

giroudf · #40 08/10/2006, 20h44

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.

baloub · #41 08/10/2006, 21h30

Prendre le fichier contenant les GOP disparates, faire une capture sur la caméra puis réimporté cette capture sur l'ordinateur. Ensuite passer cette capture à l'analyse et nous dire si le fichier a toujours la même structure.

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.

st65 · #42 08/10/2006, 21h37

Posté par giroudf

(...)
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.

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.

Posté par giroudf

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.

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

A+

st65 · #43 08/10/2006, 21h53

Posté par philiippe chevrier

le HDV est codé 1 fois sur la cassette 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% quand on a affire a des algo pour recomposer des images il reste une part d'incertitude

"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+

giroudf · #44 09/10/2006, 00h33

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 ?

st65 · #45 09/10/2006, 01h18

Posté par giroudf

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

philiippe chevrier · #46 09/10/2006, 10h51

TOUS les décodeurs donneront le meme fichier décodé

oui mais pour avoir eu des pépins avec des Aquis HDV prendre Vegas,Edius ou Première ne donne pas le meme taux d'erreur
d'ou ma reflexion.

JLH 37 · #47 09/10/2006, 12h07

Bonjour,

Un grand merci à Baloub pour la suite du test qui nous permet d'observer ce qui se passe concrètement.

Effectivement, après un comparatif en parallèle sur deux écrans, on s'aperçoit que le transfert sur caméra et le retour sur ordinateur ne modifient absolument pas la structure (ou plutôt la déstructure) des GOP.

Et la caméra ne semble pas en souffrir à la lecture.

Mais c'est après qu'il y a problème avec Magix car cela perturbe l'acquisition. Cela peut-être ennuyeux si la bande est conservée en master du montage.

Et ce problème peut poser interrogation sur la réaction d'autres logiciels de montage à qui l'on voudrait faire "avaler" cette bande qui n'est plus à la norme.

Personnellement ce truc m'embêterait un peu si je travaillais en natif et, à tout prendre, je préfèrerais un recalcul complet afin d'être sûr d'avoir un métrage "remis à neuf" dans sa structure et parfaitement à la norme pour éviter toute surprise.

C'est peut-être pour cela que certains logiciels ont fait le choix du recalcul systématique avant export définitif.

Pascal22 · #48 09/10/2006, 12h38

->retour en mpeg2 YUV 4:2:0

je suis d'accord avec giroudf,
je pense que la conversion RVB (4:4:4) vers YUV (4:2:0 ou 4:2:2) doit être considéré comme 1 génération supplémentaire, car c'est une compression du signal, qui interviendra nécessairement avant la compression au format Mpeg2. C'est pourquoi l'utilisation des filtres fonctionnant en directement YUV est à privilégier.

koala_b · #49 09/10/2006, 13h33

Posté par baloub

Bonsoir,

Histoire d'embrouiller ou d'éclaircir les choses (au choix).
Je me suis amusé à faire un petit test sur ces histoires de longueur de GOP et de (non)réencodage.

Pour ça, j'ai utilisé Magix 2007+ qui ne réencode que le nécessaire et bitrate viewer pour l'analyse.

Etape 1 :
- dépose sur la timeline d'un mpv et mpa issu du démux d'un flux HDV
- sélection d'une minute de ces fichiers et export.
- Le fichier exporté est baptisé "original" (seul le tout début et la fin du fichier est réencodé)

Etape 2 :
- Je coupe cet extrait de 1 mn en sequences de 8s et je mélange les séquences en les permutant 2 par 2
si l'origine est 1 2 3 4 5 6 7.. j'obtiens 1 3 2 5 4 7 6...
- export du fichier baptisé sequences 8s

Etape 3
- idem etape 2 mais avec des séquences de 4s

Etape 4
- idem étape 2 mais avec des fichiers de 2s

Dans tous les cas, le smart renderer (non réencodage) s'est déclanché. Pour la sequence 2s le nombre de réencodages était le plus important (logique).

Les résultats (fichiers gif représentant la variation de débit du flux vidéo obtenu et fichier htm donnant la structure des GOP) sont dans les zip joints.

Une constatation : les fichiers obtenus ont tous la même longueur (à l'octet près !): 197 681 060 octets : Le débit moyen du flux multipléxé est donc identique dans tous les cas.

Dans l'analyse des GOP, à chaque fois qu'il y a réencodage, les GOP sont clos ce qui facilite le repérage.

Que peut on déduire de tout ça ?

Un grand merci à baloub, car son test répond à certaines questions restées jusqu'à présent sans réponse (pour moi du moins...).

Des fichiers zip fournis, on peut déduire beaucoup de choses, dont :
- la structure GOP peut varier en HDV en suivant les points de coupe/transitions,
- les GOP modifiés semblent toujours être inférieurs au maximum de 12 (pour le PAL)
- il y a donc plus d'images complètes " I " par seconde qu'en capture caméra (qui enregistre en GOP de 12 'fixes' pour le PAL),
- pour stocker ces "I" supplémentaires sur une bande DV/HDV à débit constant, ces "I" supplémentaires ne peuvent être que d'une qualité dégradée par rapport à une image pleine "I" d'un GOP long de 12 (sinon le volume de data ne tiendrait pas sur la bande : pour rappel les images complètes "I" ont le poids le plus lourd dans un GOP).

Il y a donc forcément une dégradation de la qualité HD dès qu'il y a 'coupe' entre 2 scènes puisque il y a plus de GOP à faire tenir dans le même espace : cette dégradation n'est pas 'globale' et intervient uniquement au point de coupe, ce qui est en terme de visualisation par l'oeil humain le meilleur endroit pour qu'elle soit le moins visible...

Il serait aussi interessant, je pense, de faire le même genre d'exercice (tj en natif) avec d'autres Logiciels que Magix : peut être auront-ils un autre comportement ?

De même, si Magix n'arrive pas à relire sa propre copie à partir d'un backup sur bande DV/HDV, qu'en est-il des autres logiciels : lesquels peuvent relire la bande de Magix ?
baloub, si tu n'as pas d'autres logiciels, tu dois avoir quand même HDVsplit : ça donne quoi en recapture ?

Koala

PS: quel logciel ou utilitaire as-tu utilisé pour extraire les structures de GOP ?

baloub · #50 09/10/2006, 15h23

Posté par JLH 37

Et ce problème peut poser interrogation sur la réaction d'autres logiciels de montage à qui l'on voudrait faire "avaler" cette bande qui n'est plus à la norme.

Je referai un essai d'acquisition avec Vegas platinum 6 et HDVSplit.
Je pense plutôt qu'il s'agit d'une faiblesse de la routine d'acquisition de Magix.
A vérifier.

C'est peut-être pour cela que certains logiciels ont fait le choix du recalcul systématique avant export définitif.

Le problème (s'il y a problème) ne concernerait que le retour sur bande et sa récupération.
Un MPEG avec des GOP de longueurs différentes n'est en rien une anomalie pour la diffusion.