Projet de FAQ Les offres des éditeurs en montage HDV : en natif ou intermédiaire?

bonjour pascal,
la phrase originale étant celle ci :

Donc si au final, la compression n'est pas type HDV, l'ajout du codec intermediaire se fera peu sentir. Mais si le support final reste en HDV*, utiliser un codec intermediaire est un peu du gâchis

tu oublie un élément important obligatoire pour le retour sur K7 HDV ou sur support blu-ray : la recompression en MPEG2
Je n'ai jamais mis en cause le codec intermédiare, mais la recompression en MPEG2, obligatoire si on ne travaille pas en natif.

Dans le cas de codec intermédiaire, le schéma est le suivant :

caméra -> codage mpeg2(codage à pertes)-> K7 ->codage intermédiaire (faible pertes)->codage mpeg2(codage à pertes)->vers support final K7 HDV


nous avons bien 2 fois le codage mpeg2 ; celui la meme qui, employé une seule fois à la prise de vue, est déjà fortement critiqué

-------

 

Ok, c'est ça de prendre une discussion en cours (en l'ayant lue en //) ;{)

Ce qui m'interpelle pour l'édition en natif c'est, comment fait-on, dans la mesure où la longueur du gop en HDV est censée être fixe (6 ou 12), pour gérer un simple cut, qui, s'il est mal placé (au milieu d'un gop), est censé générer une reconstruction en cascade des gop suivant...

 

Un GOP peut etre plus court que la normale -> le débit augmente mais un buffer spécial permet d'absorber de petites variations de débit. Donc pas de reconstruction en cascade.

A+
ce qui est connu en HDV :
720/30p ->GOP = 6
1080/50i ->GOP = 12
1080/60i ->GOP = 15

 

Autant, je peux comprendre la notion de GOP variable, autant je n'ai jamais pu trouvé confirmation d'une quelconque tolérance de GOP en HDV ; les GOP que tu cites, st65, sont les seuls 'officiels' : pour moi, un logiciel qui monte en HDV est censé respecter ces définitions de GOP (sans les raccourcir ni les allonger, même d'une seule image).

Mais justement, peut-être que les logiciels qui ne permettent pas d'exporter le montage final sur K7 HDV, ne respectent pas en fait ces définitions, et restent à un niveau seulement compatible Mpeg2, mais pas 100% HDV... d'où aussi quelques soucis avec certains logiciels de lecture Mpeg-2...

koala

 

Bon, je vois que la discussion va bon train...
Je signale juste que le petit première, c'est à dire premiere éléments 2 associé au plug in de mainconcept (mpeg element) permet l'acquisition et le montage en hdv et ne recompresse que les parties modifiées lors de l'export. Le tout pour 150 roros env. Je l'utilise avec ma hc1 sans problèmes mis à part bien sur quelques ralentissements (acceptable) comparé au dv.
Je viens de voir que adobe vient de sortir première element 3 avec support du hdv natif.
Voualà pour pour la faq et pour les "petits" logiciels...
@+

 

Salut Koala.
le mpeg2 est un format au paramétrage complexe, comparé au DV.
Mes cours sur le mpeg2 datant de près de 15 ans, il me semble néanmoins que le "Constant Bit Rate" peut se permettre quelques variations de longueur de GOP, et partant de débit, grace au "VBV buffer". Mais je ne sais comment le HDV (ou plutot l'enregistrement sur bande magnétique) tolère ce dernier.

Donc la question est :
le gop doit il rester constant en HDV ? (tolérance 0%)
-si oui, il y a recalcul de tout le film, car il y a "reconstruction en cascade" de tous les GOPs. Et donc perte de l'interet de travailler en natif.
-si non, le travail en natif peut eviter une recompression du film et donc éviter l'ajout d'une "génération"

Y a t-il un expert mpeg2 dans la salle ?

A+

 

il est a noter :
- que le modèle de Gop étant altérer la reprise ultérieur de ce 'master' dans un logiciel de montage est à proscrire.
- que le montage en natif et utilisable sur des montage relativement simple. En effet, partant du principe qu'un simple cut peut altérer potentiellement 2 gop de suite, On peut facilement imaginer ce que peut donner un montage très dynamique avec des plans très courts.

 

Il n'y a - peut-être - pas que le MPEG(2) et ses GOP en question dans cette cuisine.

Il y a aussi multiplexage de la vidéo et de l' audio et constitution de "paquets" (de chacun 188 octets dont 4 d' entête) et ça, en plus, je crois, à une sauce concoctée par Sony et signée m2t …

Quelle que soit la procédure "natif", "proxy" (décodage initialement réduit à la nécessité d' affichage fluide dans la fenêtre lecture du logiciel) ou "codec" … après un montage ne serait-ce qu'en "cut", un ré-encodage .m2t me parait indispensable avant ré-enregistrement HDV. Le résultat de la procédure que l'on pense ne nécessiter que ce ré-encodage final dépend donc de la qualité du cod(ec) mis en œuvre- et qui l'est pour des logiciels succints.
Je ne suis donc pas étonné que la solution qui comporte un décodage "bien fait" (plus ou moins lourd) du M2T en AVI ou MOV spécifiques, un travail de montage, corrections, effets, etc. sur des "images indépendantes" suivi d'un ré- encodage "de qualité" donne les résultats constatés par JLH37, c'est à dire de meilleure tenue que les autres…

 

Argh ! ça sent le conflit … d' Eugène & rations