Quelques réponses aux premières questions sur le HDV

Salut st65,
tu ne me froisses pas, mais une sortie YUV est une sortie en composantes : si tu en doutes, jette un oeil sur le lien que j'ai signalé :

"De cette façon, le passage d'un système de couleur RGB à un système YUV peut être réprésenté au moyen d'une matrice, d'où le nom de « matriçage » donné à cette opération.(...)
Ce système est bidirectionnel, ce qui permet, par l'opération inverse, de retrouver les signaux RGB pour les afficher à l'écran "

Cela fait sans doute partie de l'abondante litterature que tu cites. Et si comme tu le dis les constructeurs sont d'accord sur un standard de connexion, c'est le moins qu'on puisse attendre d'eux, tant mieux !
A+

 

Il y a quand même une différence importante entre RVB et YUV, c'est ce qu'on en fait.
Parler de RVB indique implicitement que les canaux R, V et B soient de même largeur, donc 4.4.4, natif ou reconstitué.
Parler de Y R-Y B-Y, ou par simplification d'usage YUV, bien que U et V soient des appellations de vecteurs, nécessite de préciser le taux d'échantillonnage choisi, 4.2.2, 4.1.1, 4.2.0 ou plus rarement 4.4.4.
Si on avait du RVB en 1.4.1, (V assimilé à la voie luminance) le rendu colorimétrique des détails serait altéré comme l'ont démontré certaines caméras C.MOS de première génération (années 80).

 

merci pour ce joli article tres simple et efficace.

 

J'avoue mon incompréhension, tu as sans doute raison mais pour moi, RVB et YUV sont deux façons de se référer à la même réalité. Y étant la valeur de luminance, tu peux déduire de cette simple équation (il s'agit d'une approximation en ce qui concerne celle que j'ai citée, Y = 0,6V + 0,3R + 0,1 B)) les valeurs des composantes RGB.... La cuisine interne du matériel utilisé n'a rien à voir avec cette réalité mathématique. Peut-être les constructeurs ont ils fait un choix en ce qui concerne le traîtement de chaque couleur. Ce que je sais, c'est que la chrominance est codée sur 24 bits (d'où 16,7 millions et des poussières) et que chaque couleur est codée sur 8 bits.... à égalité.
Je ne vois pas comment "V aurait été assimilé avec la voie luminance" (vidéo88)" puisque cette équation a pour objet de faire dépendre la luminance Y des niveaux respectifs des composantes RVB...
Alors, veux-tu dire qu'à l'enregistrement, en HDV, des choix s'opèrent en fonction de l'utilisation respective de ces signaux ? En diffusion semble-t-il, chaque signal est traîté sur huit bits d'où une reconstitution en 24 bits de la colorimétrie d'un pixel (au passage, aucun écran n'est encore capable de reproduire simultanément 16,7... millions de couleurs - avec leurs deux millions de pixels max- et que cela reste de ce fait tout à fait théorique, d'autant que l'oeil d'un être humain "ordinaire" -hormis les peintres ou autres, et même !- est incapable d'un tel pouvoir de différenciation des nuances.
Cela dit, je veux adresser un message à ceux qui s'inqiètent du taux de contraste de l'Acer : on a bien des noirs profonds, avec de multiples nuances dans les gris/noirs... Et même le son est très bon... (on trouve ce modèle à 1800 euros !!!). Et vu la taille de l'écran (bien que les HP soient détachables), le rendu stéréo est très bon. Sur les programmes TV comme sur les prises de son stéréo M/S avec une caméra équipée d'un micro M/S...

PS: qui peut me renseigner sur un point (ou deux) ?
1) J'aivu, dans la liste des chaînes scannées par l'ACER AT 3705 MGW, deux chaînes : essai HD1 et essai HD2 (tuner TNT). Malheureusement, je n'ai pas d'image ! Ce serait pourtant interressant... s'agit-il d'une manip non accomplie, d'une situation normale, ou d'autre chose ?
2) On peut insérer cette TV dans un réseau, soit en Wifi soit en filaire. Un CD avec un logiciel est fourni, mais il paraît que seul Windows Media Connect 2.0 est capable de transmettre à la TV des DVD en temps réel... N'ayant jamis créé de réseau, je suis un peu dans l'impasse... je constate que mon ordi comme ma TV reconnaissent les signaux WIFI de ma Livebox, mais après ?
Merci d'avance...

 

En fait, il suffit de retenir que RVB est différent de YUV.
Dans la connectique RVB, la fiche verte "V" vaut 100% de la voie verte ; et dans le systeme YUV, la fiche verte "Y" vaut 0,6V + 0,3R + 0,1 B. Déjà tu comprends qu'il n'y a pas compatibilité.

A+

 

Oui, d'accord avec toi, mais les traîtements internes,électroniques, logiciels et/ou matériels, permettent de reconstituer 100 % de la voie verte, 100 % de la voie rouge et 100 % de la voie bleue !!?? Je me trompette ??
Je ne vois donc toujours pas l'obstacle !
Cela dit, il se peut que le codage de chaque couleur par le camescope ne soit pas égal...
En ce qui concerne le moniteur, (hormis les codecs Mpeg qui concenent les médias utilisés), une entrée directe YUV est bien une entrée en composantes où chaque couleur est traîtée à égalité. Le problème que tu soulèves se situe, si j'ai bien compris, en amont...
A+

 

Au final, tous les types de signaux vont reproduire du RVB !

Mais tu ne peux brancher du Y/C sur du RVB, ni du YUV sur RVB, ni du CVBS (composite) sur RVB !
Le traitement interne est différent en YUV, RVB, Y/C, ou CVBS. Et si un connecteur est prévu pour recevoir un signal Y = 0,6V + 0,3R + 0,1 B, si tu envoie un signal 100% vert, cela ne va pas fonctionner correctement !
Regarde STP dans le glossaire, il y a un très bon schema de guy-jacques, si je ne me trompe, à ce sujet.

 

OK, compris, on est d'accord... Donc, c'est bien en amont (modes de compression) qu'ont lieu les pertes d'infos ?
Et sais-tu quelque chose sur ces "chaînes" d'essai HD1 et HD2 dont je n'obtiens pas l'image ? CErtains d'entre vous y ont-ils accès ?
Merci

PS : un autre lien sur les spécification de l'Acer 3705 MGW (qui précise notamment sa capacité à gérer des formats comme le 1080p) :
TVs

 

Merci Jean-Luc pour ce beau travail
et désolé d'arriver si tardivement.

Désolé aussi si la réponse est dans les 6 pages .... pas tout lu

Tu dis à un moment

Comme je vais poursuivre mes tests avec Vegas 7 et le tout nouveau Connect HD 3.3, et avec une Sony A1E ; à quels paramètres songeais-tu dans l'encodage Mpeg 2 pour parvenir à de meilleurs résultats qu'avec du DV (en downconversion, cela va de soi ...).
Vu que connect HD n'est quà 199$, je m'en vais tester la bête et voir vraiment si on gagne à produire des DVDs avec du DV downconverti et du HDV cineform, ou HDV natif...

 

attention vous confondez luma et luminance, c'est pas la meme chose.
dans un signal yuv, c'est de la luma, pas de la luminance.
dans un signal Y/C par contre c'est bien la luminance.

 

Luma n'est que le diminutif de luminance .
Les "Y" de YUV et Y/C sont bien les memes signaux !

Branche les sur un moniteur et tu obtiendras la meme image noir et blanc.

La seule différence entre le Y de YUV et le Y de Y/C est un leger retard necessaire pour "attendre", dans la caméra, le codage de UV en C.
Les lignes à retard de quelques centaines de nanosecondes utilisées pour ce travail sont très connues car utilisées autrefois pour un certain décodeur "pirate"...


A+

 

non justement c'est pas la meme chose.
la luminance c'est le signal en luminance pure, pas de calcul et c'est effectivement une image n/b.
la luma, ca y ressemble furieusement, ca donne aussi une image n/b mais les niveaux sont pas ceux de la luminance.
d'ailleur pour un puriste luma s'ecrit Y' et luminance Y

Wiki:
Because of the difference between luma and luminance, luma does not exactly represent the luminance in an image. As a result, errors in chroma can affect luminance. Luma alone does not perfectly represent luminance; accurate luminance requires both accurate luma and chroma. Hence, errors in chroma "bleed" into the luminance of an image.

Due to the widespread usage of chroma subsampling, 'errors' in chroma typically occur when it is lowered in resolution/bandwidth. This lowered bandwidth, coupled with high frequency chroma components, can cause visible errors in luminance. An example of a high frequency chroma component would be the line between the green and magenta bars of the SMPTE color bars test pattern. Error in luminance can be seen as a dark band that occurs in this area

 

Merci JLH pour ces infos.

L'encodeur mainconcept de Vegas est assez performant à ce que l'on dit et semble donner satisfaction (il est un peu amélioré pour Vegas ...). Néanmoins j'ai remarqué des légères saccades lors de fondus au noir par exemple :(

++++

En ce qui concerne Connect HD 3.3 avec Vegas, j'ai déjà un peu testé. Voici mes quelques remarques à chaud ... à affiner bien évidemment.

L'acquisition des rushs se fait via le programme HDLink en indépendant de Vegas.

La première bonne nouvelle c'est que le fichier acquis ne fait que 2 fois le poids du HDV natif (.m2t) et non 3 fois comme tu l'as indiqué. C'est déjà ça de gagné ! Malheureusement je ne sais pas combien ferait un fichier avec codec intermédiaire Cineform sans Connect HD (car Cineform est d'office livré avec Vegas). Il faudra que je désinstalle Connect HD ...

Mais franchement, j'ai un PIV Northwood 3.2C o/c à 3.6 Ghz et j'arrive à monter les fichiers natifs sans trop de problèmes. Avec Cineform, certes c'est un peu plus fluide, mais pour le moment je n'en vois pas trop l'intérêt. Sauf à vérifier ce que tu dis à savoir qu'un encodage Mpeg 2 est meilleur à partir d'un codec intermédiaire... Ce que je peux concevoir.

Sinon, en rendu, donc en première génération de rendu (avec Cineform),
- à partir d'un rush HDV natif c'est presque 2 fois plus rapide qu'à partir d'un rush Cineform,
- mais à l'arrivée, le poids du rendu avec un rush HDV natif est de 10% supérieur à celui d'un rush Cineform !
Ce qui est surprenant, c'est qu'en en rendu temporaire sur la time line de Vegas, le rush Cineform est lu sans calcul alors que le rush HDV natif nécessite un calcul (... ?!?). Mais en rendu .avi, ce dernier est presque 2 fois plus rapide (comme indiqué ci-dessus) ?!?

Moralité : à approfondir