Combien de générations en montage virtuel ?

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.

 

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.

 

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 ?

 

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.

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.

 

Oui, la conversion RVB vers YUV 4:2:0 est dégradante, mais elle fait partie du processus de compression finale vers mpeg2

De RVB(4:4:4) à YUV(4:4:4), il n'y a qu'une simple opération mathematique totalement reversible sans pertes

Ca c'est le programmeur qui décide ; au niveau utilisateur je ne pense pas qu'il soit possible d'intervenir.

Par exemple, pour une retouche RVB de l'image, il est beaucoup plus simple pour le programmeur de decompresser en ...RVB.

A+

 

Tout à fait d'accord avec toi. A l'extrème limite (et après un calcul "à la louche") s'il n'y avait que des images I on aurait 25Mb / 25 = 1Mb soit 125 ko par image.
Comme j'aime bien me fixer les idées de visu, j'ai fait quelques compressions d'images 1440x1080 en jpeg pour obtenir 125 ko.
Le résultat est assez variable. Ca passe presque inaperçu sur certaines (notemment là où il y a beaucoup de détails, les artefacts se "mélangeants" aux détails), c'est immonde dès que des dégradés arrivent (ciel).
Il serait interessant de voir dans le cas d'un GOP IBB (globalement 375 ko) la part qui revient au I et celle qui revient aux B.

Tout à fait, et pour avoir longuement observer ces résultats. Dans le cas d'un changement de plan toutes les deux secondes, l'oeil n'a pas le temps de se fixer sur les défauts éventuels.

J'ai le womble, je ferai un essai. Ma version de démo d'ulead a expiré, dommage.

Oui, j'ai répondu à JLH en ce sens. (vegas platinum 6 et HDVSplit)

"bitrate viewer". La version free permet pas mal de choses, mais il faut la version enregistrée pour l'analyse des GOP. (30€) : Bitrate Viewer

 

mathématique ne veut pas dire exacte au même titre que bio ne veut pas dire bon (la digitale est bio ;{) )
je n'ai pas les formules sous la main, mais autant la convertion YUV->RVB n'est pas dégradante autant le contraire l'est (division=approximation).

Oui mais au détriment du rendu...

 

Pour info, j'avais lu un document dédié au Mpeg-2 qui donnait comme 'poids relatif' pour chaque type d'images qlq chose comme (de mémoire) :
- I = 100
- P = 20
- B = 10
Cela dépend bien-sûr du codec utilisé et d'un tas d'autres paramètres, mais c'étaient les 'poids relatifs' constatés habituellement.

Je vais essayer de retrouver le doc pour confirmation...

Koala

PS : merci pour le lien vers l'utilitaire. Il n'a pas d'option pour connaitre la taille en Ko de chaque image (puisqu'il peut en connaitre la structure des GOP et leur offset) ? La photo d'écran de la page du site proposant cet utilitaire, semble donner des ratios de compression image par image (I, P, B) : on doit donc aussi pouvoir en déduire leurs tailles exactes, ce qui permettrait de répondre à d'autres questions dont :
- les P et B contruits par le camescope sont-ils de tailles régulières pour faciliter le calcul du débit constant du HDV, ou sont-ils optimisés entre-eux ? ex : dans un même GOP, un B pourrait être plus gros qu'un autre pour tenir compte d'un mouvement sur les images, et un ou plusieurs autres B seraient plus petits au sein du même GOP pour répondre au débit constant de 25 mb/s.
- cette construction des GOP est-elle très différentes d'une caméra à une autre (ou du moins d'un fabricant à un autre, car je suppose que Sony exploite les mêmes algorithmes de compression sur toutes ses cameras, et de même chez Canon ou JVC) ?

 

à Pascal,
Le passage de RGB à "YUV" (ou YCbCr ou YPbPr) est appelé "matriçage" car il résulte d' un "calcul matriciel".
Mais, contrairement à cette appellation matheuse, ce calcul est, comme le déclare st65, "simple" car arithmétique (ce qui n'est pas le cas des "compressions": Fourrier et wavelet = calcul intégral) et "sans perte": ça fait belle lurette que les calculateurs en virgule flottante remplacent les "divisions" par des multiplications et avec la précision que le programmeur désire.
En outre les coefficients de ces "changements de base" ont été donnés au glossaire du Repaire par vsb et commenté par .., vsb, "jemoimême" et Jean Passe :

http://www.repaire.net/forums/glossaire/96146-ycbcr.html
http://www.repaire.net/forums/glossaire/96145-ypbpr.html
http://www.repaire.net/forums/glossaire/96143-yuv.html
http://www.repaire.net/forums/glossaire/21116-chrominance-luminance-composite-yc.html

 

Ben ....Oui .!!!

Salut TLM & Pascal22

Ce que j'avais, à l'époque du choix du premier système de montage, cru comprendre, d'ou l'achat à un (sus) dénommé Pascal d'une Storm2 et d'un logiciel StormEdit.
Ce StormEdit étant à cette date ( Edius 4 ) le seul capable d'interfacer totalement avec Xplode Pro 4 ..et que j’utilise à nouveau pour générer de belles transitions exclues de l’univers ( actuel ?) d'Edius V4

En en ce qui concerne les générations, je ne pense pas qu'il faille intégrer la phase de compression mpeg destructrice.

la vue d'un jpeg de jpeg de jpeg est suffisamment édifiante.

"pour moi" on demeure dans le même montage ou l'on pratique des re-calculs de rendu d'effets et de transitions "n" fois " ( c'est dans ce domaine que le YUV 4.2.2. du Codec intermédiaire Canopus montrait sa supériorité )

Et si l'on remonte sur une K7 Dv puis à nouveau on capture cette K7 ..c'est une génération de plus .


Bertrand

 

Bonjour Bertrand
Dans le vrai montage natif du DV, les parties non retouchées sont parfaitement identiques à l'original.
Chaque image peut etre considérée comme un JPG que tu recopie SANS le décompresser/recompresser.
Et une image JPG, tu peux la copier autant de fois que tu veux sans pertes !

A+

 

J'ai fait le test avec le womble : ça semble encore plus "torturé" qu'avec magix. le Womble
n'a pas de fonction d'export vers caméra donc je ne peux tester (sauf à utiliser Magix en intermédiaire). En lecture, via un boitier tvix, le résultat semble très bon.
fichier : gop_seq_2s_womble.zip

Voilà qui est fait aussi :
Essai avec HDVSplit et Vegas platinum 6 en plus de CapDVHS : les trois fichiers sont identique du point de vue structure des GOP.
Ca confirme pour moi qu'il s'agit bien d'un bug (ou d'une gestion trop strict du flux attendu) par la routine d'acquisition de Magix.
fichiers :
HDVSplit : gop_provenance_cam_hdvsplit.zip
Vegas : gop_provenance_cam_vegas.zip

Je vais essayer de signaler ça au support technique de Magix, car ça peut être ennuyeux pour quelqu'un qui fait du retour sur bande. Il risque de se retrouver avec de petites pétouilles ici ou là dont il ne comprendra pas l'origine (d'autant plus que le contenu de la bande est bon).

 

Débat intéressant, désollé si je fais de la redite (pas encor' tout lu) mais entre Prospect HD et rien, il y a aspect HD qui permet quand même une dizaine de générations... un bon compromis à 500 dollars. Le GOP ? Pas GLOP !!!
Tous leurs produits et explications :
CineForm Inc
Bonne chance, à ++++++++++++ de générations !

 

Merci encore pour tes tests baloub (tu as du temps libre en ce moment ou quoi ?...)

Caraibe se plaignait que Womble ne générait pas tj des fichiers lisibles par d'autres logiciels... Est-ce que le CBR HDV est respecté ?

Super, cela prouve que le HDV, cela peut être autre chose que seulement du GOP à 12 images... Et c'est rassurant de voir que les calculs d'un logiciel comme Magix (qui fait du HDV natif pour pas cher) soient reconnus.

Autre réflexion : les fichiers d'info extraits de ton utilitaire 'Bitrate viewer' donnent des taux allant d'environ 22mb/s à environ 28mb/s (voire même plus que 29mb/s dans un des exemples !), ce qui est normal, les images I, P, B n'ayant pas le même poids. Mais question subsidiaire : pour être conforme au débit constant de 25mb/s en HDV, cette moyenne de 25mb/s doit être tenue tous les combien d'images ?
Avant tes tests de montage, j'aurais dit "toutes les 12 images, soit 1 GOP" ; mais maintenant, la réponse est moins évidente...
Ne pourrait-on pas d'ailleurs imaginer une caméra qui dès l'enregistrement génére un fichier HDV avec des GOP de tailles différentes pour essayer de mettre plus d'images I ou P là ou il y a plus de mouvements dans la scéne filmée, et des I et P de poids plus faibles juste avant et juste après pour compenser et revenir au débit constant de 25mb/s ? (cela donnerait du VBR très localisé en qlq sorte...).

Je ne cherche pas la petite bête, mais de questions en réponses, je pense qu'on cerne mieux le format HDV, et indirectement ses avantages et ses inconvénients. J'espère ne pas ennuyer trop les lecteurs du forum... (ça ne peut pas être pire que 'RVB, YUV et YCbCr'... merci à Guy-jacques d'avoir rappelé ici les liens vers le glossaire, on est sauvé)

Koala