A quoi sert vraiment le HDMI 1.3 pour les codecs audio HD ?

» 04 Aoû 2007 14:49

MarcMAME a écrit:
corsario a écrit:Attention : j'ai écris "l'inutilité du HDMI 1.3 pour l'audio HD".
Jusqu'à preuve du contraire (je me cultive... ) je maintiens pour le moment que la fonction Lipsync de cette norme apporte un plus indéniable sur le maintien de la synchro audio/video tout au long de la chaine de traitement, ce qui est impossible à faire d'une manière automatique actuellement.
D'autre part, j'estime qu'il faut voir le HDMI 1.3 comme l'age mûr de cette norme, un peu comme si les versions précédentes étaient des pré-version.
On s'aperçoit d'ailleurs à l'usage que les version antérieurs (1.0 à 1.2) pose souvent des problèmes et de nombreux bugs d'utilisation sont présents.
Pour ma part, je n'acheterais plus aujourd'hui un appareil qui ne soit pas conforme à la norme 1.3.

Hélas cette norme ne te garanti rien en ce qui concerne l'audio HD : ce qu'il faut c'est que ton ampli traite le PCM en 7.1 et le PCM stéréo et 5.1 jusqu'au 192kHz. Et ça ce n'est pas une étiquette, ça n'a aucun rapport avec la connection HDMI 1.3 et il faut chercher au fin fond des modes d'emploi, c'est pénible...

Et sinon c'est pas HDMI 1.3, c'est HDMI 1.3a :mdr:

Tu feras quoi quand sortira le HDMI 1.3b ou le HDMI 1.4 ?

Je pense qu'il faut faire ton deuil d'une norme HDMI ultime :mdr:

Et pour le lip synch je n'en n'ai pas parlé (et je n'ai pas lu en détails vos échanges), donc là je botte en touche. Et je me cultive aussi :wink:

» 04 Aoû 2007 14:53

WhyHey a écrit:Cependant, je maintiens que "sink" dans la norme veut dir "récepteur", il suffit de lire le schéma 3.1 pour le comprendre.
Donc les délais de latence qui transittent via EDID sont ceux du récepteur. Pas du diffuseur.

c'est le diffuseur qui maintient au mieux la synchronisation en fonction des infos que le récepteur lui fournit sur ses délais de latence audio et video, appliquant alors un délai afin de compenser la différence entre audio et video dans le flux qu'il transmet au récepteur.

Tu te trompes.
On distingue 3 types d'appareils :
- Sink désigne un appareil disposant d'une entrée HDMI, quelqu'il soit : un diffuseur par exemple
- Source désigne un appareil disposant d'une sortie HDMI, quelqu'il soit : un lecteur par exemple
- Repeater désigne un appareil disposant d'au moins une entrée et au moins une sortie HDMI, quelqu'il soit : un préampli HDMI par exemple.

voir Page 5

(HDMI) Source A device with an HDMI output.
(HDMI) Sink A device with an HDMI input.
(HDMI) Repeater A device with one or more HDMI inputs and one or more HDMI outputs.
Repeater devices shall simultaneously behave as both an HDMI Sink and an HDMI Source.

Section 8.9.1 page 128 EDID Latency Info :

HDMI Sinks and Repeaters may declare audio and video latency information in the EDID, allowing an HDMI Source or Repeater to determine how best to maintain synchronization
between the rendered audio and video.

C'est donc bien le diffuseur qui déclare sa latence au préampli qui appliquera le delay nécessaire à l'audio.

Many TVs internally compensate for their own video processing latency by adding a delay to the audio stream that corresponds to the video latency. In this case, the EDID-indicated audio and video latencies will be equal.

Lorsque l'on écoute l'audio à travers le diffuseur (enceintes intégrées) et que celui ci applique lui même le delay necessaire, il indique via l'EDID au lecteur que sa latence est nulle et que le lecteur n'a donc pas besoin de compenser.

L'explication continue pour traiter de nombreux cas de figures. Ce qu'il faut comprendre, c'est que d'une manière générale, l'info EDID transite dans le sens inverse des flux audio/vidéo et remonte la chaine depuis le diffuseur, jusqu'à la source. :wink:

» 04 Aoû 2007 15:01

MarcMAME a écrit:Section 8.9.1 page 128 EDID Latency Info :
HDMI Sinks and Repeaters may declare audio and video latency information in the EDID, allowing an HDMI Source or Repeater to determine how best to maintain synchronization
between the rendered audio and video.
C'est donc bien le diffuseur qui déclare sa latence au préampli qui appliquera le delay nécessaire à l'audio.

je suis d'accord avec tes défintions et avec ta phrase si dessus. qui n'est en rien en contracdiction avec ce que je dis:

c'est Sink et Repeteur qui déclare à Source ou repeteur, dans notre contexte,
ça donne VP déclare à AVR et
AVR déclare au lecteur: c'est de cette connexion dont je parle.
évidemment tu parles de l'autre ...

ensuite il a confusion dans nos propos parce que j'ai lu "diffuseur" dans tes post comme le lien diffuseur-recepteur et non comme diffuseur = VP, ce qui inverse tout.

in fine, nous sommes donc paraitement d'accord sur ce premier point.

MarcMAME a écrit: l'info EDID transite dans le sens inverse des flux audio/vidéo et remonte la chaine depuis le diffuseur, jusqu'à la source.

absolument, maintenant que les quiproquos sont éclaircis on peut poursuivre.

» 04 Aoû 2007 15:16

corsario a écrit:Hélas cette norme ne te garanti rien en ce qui concerne l'audio HD : ce qu'il faut c'est que ton ampli traite le PCM en 7.1 et le PCM stéréo et 5.1 jusqu'au 192kHz. Et ça ce n'est pas une étiquette, ça n'a aucun rapport avec la connection HDMI 1.3 et il faut chercher au fin fond des modes d'emploi, c'est pénible...

Tu confonds 2 choses : ce que dicte une norme et les possibilités offertes par un appareil donné.
Si j'achète un ampli 2 canaux HDMI 1.3, il me parait évident que je n'aurais pas plus que de la stéréo mais je bénéficierais quand même des specs de la norme.
La norme me garanti un respect des specifications mais ne me garanti en rien la manière dont les sources sont restituées, c'est ce qui fera la toute la différence entres les appareils, leurs fonctionnalités et bien évidemment leur prix !

Et sinon c'est pas HDMI 1.3, c'est HDMI 1.3a
Tu feras quoi quand sortira le HDMI 1.3b ou le HDMI 1.4 ?
Je pense qu'il faut faire ton deuil d'une norme HDMI ultime

Je n'ai pas dis ultime mais mature ce qui est très différent... L'évolution de cette norme c'est succedé au rythme d'une nouvelle version tous les 6 mois environ depuis la 1.2 jusqu'à la 1.3a datant de Novembre 2006. Depuis 9 mois, rien n'a changé et il me semble qu'il n'est pas prévu de nouvelles évolutions majeures de sitot. J'en déduis qu'on est arrivé à la maturité de cette norme et qu'on peut donc se fier à cette version même si elle évoluera inévitablement dans un futur plus lointain.

Et pour le lip synch je n'en n'ai pas parlé (et je n'ai pas lu en détails vos échanges), donc là je botte en touche. Et je me cultive aussi

C'est pour moi le gros interet de cette norme concernant l'audio, c'est donc important d'en parler puisque qu'elle remet en question l'interet ou non du 1.3 pour l'audio HD...

» 04 Aoû 2007 15:20

MarcMAME a écrit:
Et pour le lip synch je n'en n'ai pas parlé (et je n'ai pas lu en détails vos échanges), donc là je botte en touche. Et je me cultive aussi
C'est pour moi le gros interet de cette norme concernant l'audio, c'est donc important d'en parler puisque qu'elle remet en question l'interet ou non du 1.3 pour l'audio HD...

pour moi le gros interet (en audio) c'est le bitstream du flux natif, comme quoi, on voit vraiment chacun midi à sa porte ...
et le gros inconvénient c'est le jitter

» 04 Aoû 2007 15:29

WhyHey a écrit:in fine, nous sommes donc paraitement d'accord sur ce premier point.

Puisque nous sommes d'accord, tu comprends donc l'interet de cette fonction qui n'est donc pas inutile, loin de là, puisque c'était ta première remarque qui a généré ma réaction ?

WhyHey a écrit:un AVR Hdmi possède en interne le décalage qu'il générera entre audio et video, dans ce cas , il donne comme valeur EDID de latence la même valeur pour l'audio et la vidéo, réduisant à néant l'intérèt de cette nouveauté.

Quant au coté optionnel de la chose, je n'ai encore rien lu de tel et très franchement, si c'est le cas ça perdrait tout interet.
En tout état de cause, ce qui n'est pas optionnel, c'est la déclaration de latence dans l'EDID. Donc même si un élément n'apporte aucune correction de delay alors qu'il en génère, il transmettra cette info au maillon précédent qui se chargera de le faire pour lui et ainsi de suite jusqu'au lecteur qui finalement prendra tous les delay en charge si personne après lui ne s'en est chargé. :wink:

» 04 Aoû 2007 15:32

WhyHey a écrit:pour moi le gros interet (en audio) c'est le bitstream du flux natif, comme quoi, on voit vraiment chacun midi à sa porte ...
et le gros inconvénient c'est le jitter

En fait, c'est surtout le jitter qui te pose problème parce que si ce n'était pas le cas, qu'est ce que ça change de décoder dans le lecteur plutot qu'en externe ??? :wink:

» 04 Aoû 2007 15:42

on va y aller doucement pour que je puisse suivre .
une remarque à la fois sinon je suis perdu (un peu monotache en mode discussion serrée), désolé.

MarcMAME a écrit:
WhyHey a écrit:in fine, nous sommes donc paraitement d'accord sur ce premier point.
Puisque nous sommes d'accord, tu comprends donc l'interet de cette fonction qui n'est donc pas inutile, loin de là, puisque c'était ta première remarque qui a généré ma réaction ?

j'ai précisé que c'était inutile entre Lecteur et AVR (ampli audio video receiver), je maintiens, c'est même écrit dans la norme, tu peux maitenant sité, comme je l'ai fait, le passage qui le dis.

Entre VP et AVR, il y a un intérêt SI l'AVR fait toute la chaine son, chez moi ce n'est pas le cas, puisque entre l'AVR et les enceintes il y a 2 ou 3 composants, l'AVR est donc incapable de connaitre la latence audio (il ne connait que la sienne et celles de ceux qui sont connecté en Hdmi, ce qui n'est pas le cas des 2 composants qui sont des composants puremment hifi (pré_ampli crescendo et amplisherbourn et ampli divatech pour le SW) doncconnecté à partir des sorties pré-out de l'AVR.
chez moi (et les nombreux qui ne font pas tout faire à leur intégré en son), c'est dnc aussi inutile entre VP et AVR.

OK ?

si oui, on passe à l'autre remarque.

» 04 Aoû 2007 15:55

MarcMAME a écrit:Quant au coté optionnel de la chose, je n'ai encore rien lu de tel et très franchement, si c'est le cas ça perdrait tout interet.
En tout état de cause, ce qui n'est pas optionnel, c'est la déclaration de latence dans l'EDID. Donc même si un élément n'apporte aucune correction de delay alors qu'il en génère, il transmettra cette info au maillon précédent qui se chargera de le faire pour lui et ainsi de suite jusqu'au lecteur qui finalement prendra tous les delay en charge si personne après lui ne s'en est chargé.

alors sur ce point, ce qui est très instructif dans les normes ce sont les termes utilisés, c'est très clinique comme lecture, mais c'est essentiel pour bien saisir la subtile différence entre "obligatoire " et "facultatif".

comme tu le lis il est écrit:
"HDMI sinks and repeaters MAY declare ... in the EDID ..."

que signifie "MAY" ??
c'est expliqué au 2.1 et donc ... ?
un mot clef qui indique la flexiblité d'un choix "with no implied preference" que je traduis par:
"sans obligation d'implémentation", c'est le "may" anglais de la possibilité, sans contrainte.

les autres termes "clefs" sont
shall: qui oblige, là pour le coup, on est certain que ç'est fait
should: qu est une forte recommandation mais laisse quand même le choix de ne pas le faire
le "MAY" est le plus permissif, c'est carrément une option.

voilà pourquoi la gestion du lipsync n'est pas une obligation.

(tout comme le 1080p24 ne l'est pas non plus ...)

» 04 Aoû 2007 15:58

WhyHey a écrit:j'ai précisé que c'était inutile entre Lecteur et AVR (ampli audio video receiver), je maintiens, c'est même écrit dans la norme, tu peux maitenant sité, comme je l'ai fait, le passage qui le dis.

Désolé, je ne comprend pas en quoi se serait inutile. Il n'y a jamais qu'un lecteur et un AVR, il y a forcément un diffuseur en plus (TV/Projecteur) et s'il n'y a pas de diffuseur et donc pas d'image, il n'y a pas de problème de synchro.

Entre VP et AVR, il y a un intérêt SI l'AVR fait toute la chaine son, chez moi ce n'est pas le cas, puisque entre l'AVR et les enceintes il y a 2 ou 3 composants, l'AVR est donc incapable de connaitre la latence audio (il ne connait que la sienne et celles de ceux qui sont connecté en Hdmi, ce qui n'est pas le cas des 2 composants qui sont des composants puremment hifi (pré_ampli crescendo et amplisherbourn et ampli divatech pour le SW) doncconnecté à partir des sorties pré-out de l'AVR.

Les composants (analogique donc) situés entre l'ampli et les enceintes ne devrait avoir qu'une latence totalement négligeable dans le traitement de synchro audio/vidéo mais ça c'est autre débat. Si tu connais cette latence supplémentaire, il devrait être invisageable d'integrer cette valeur dans l'AVR pour qu'il minore son delay d'autant.

» 04 Aoû 2007 16:02

MarcMAME a écrit:
WhyHey a écrit:j'ai précisé que c'était inutile entre Lecteur et AVR (ampli audio video receiver), je maintiens, c'est même écrit dans la norme, tu peux maitenant sité, comme je l'ai fait, le passage qui le dis.
Désolé, je ne comprend pas en quoi se serait inutile. Il n'y a jamais qu'un lecteur et un AVR, il y a forcément un diffuseur en plus (TV/Projecteur) et s'il n'y a pas de diffuseur et donc pas d'image, il n'y a pas de problème de synchro.

Entre VP et AVR, il y a un intérêt SI l'AVR fait toute la chaine son, chez moi ce n'est pas le cas, puisque entre l'AVR et les enceintes il y a 2 ou 3 composants, l'AVR est donc incapable de connaitre la latence audio (il ne connait que la sienne et celles de ceux qui sont connecté en Hdmi, ce qui n'est pas le cas des 2 composants qui sont des composants puremment hifi (pré_ampli crescendo et amplisherbourn et ampli divatech pour le SW) doncconnecté à partir des sorties pré-out de l'AVR.
Les composants (analogique donc) situés entre l'ampli et les enceintes ne devrait avoir qu'une latence totalement négligeable dans le traitement de synchro audio/vidéo mais ça c'est autre débat. Si tu connais cette latence supplémentaire, il devrait être invisageable d'integrer cette valeur dans l'AVR pour qu'il minore son delay d'autant.

ok,restons en là, nous ne sommes pas d'accord sur ce point, je décompose en deux le point afin de faire une réponse sur les deux sous-point pour ne pas tout mélanger mais tu ne me suis pas dans cette décomposition, tant pis, voyons le suivant: juste au dessus.

'ai soulevé 4 remarques et nous n'en sommes qu'à la 1ere (remarque N°3 dans mon post), même si nous ne sommes pas d'accord sur ce point, il en reste 3 !

évidemment je maintiens ma remarque N°3 dans mon cas, mais je reconnais sans pb que dans d'autre cas, ma remarque N°3 n'est pas pertinente.

» 04 Aoû 2007 18:12

WhyHey a écrit:évidemment je maintiens ma remarque N°3 dans mon cas, mais je reconnais sans pb que dans d'autre cas, ma remarque N°3 n'est pas pertinente.

Il existera toujours des configurations exceptionelles qui rendront plus difficile, voire empecheront, l'application d'une fonctionnalité.

» 04 Aoû 2007 18:31

sur l'aspect "optionelle" de la fonction on est d'accord avec ma lecture ? (post de 15h55)

» 04 Aoû 2007 18:37

WhyHey a écrit:comme tu le lis il est écrit:
"HDMI sinks and repeaters MAY declare ... in the EDID ..."

que signifie "MAY" ??
c'est expliqué au 2.1 et donc ... ?
un mot clef qui indique la flexiblité d'un choix "with no implied preference" que je traduis par:
"sans obligation d'implémentation", c'est le "may" anglais de la possibilité, sans contrainte.

les autres termes "clefs" sont
shall: qui oblige, là pour le coup, on est certain que ç'est fait
should: qu est une forte recommandation mais laisse quand même le choix de ne pas le faire
le "MAY" est le plus permissif, c'est carrément une option.

voilà pourquoi la gestion du lipsync n'est pas une obligation.

Effectivement, la présence du "may" laisse penser au coté facultatif de la chose mais il est également possible de l'interpreter d'une autre manière :
- Peut-être font-ils référence aux liaisons avec des appareils en version HDMI précédentes à la 1.3 et qui ne comportent pas ces informations ?
- Il est également envisageable d'imaginer que certains appareils ne générant aucun delai (tel qu'un switch HDMI) ne necessitent pas de modification de l'information EDID et encore moins de la traiter ?

En tout état de cause on peut esperer que tous les appareils répondant à la norme 1.3 et générant un delai ne fasse pas l'impasse sur cette fonction.

» 04 Aoû 2007 18:41

et bien, comme quoi il est toujours interressant de comparer les lectures d'un même texte !
Ensuite, chacun se fera sa propre opinion.

reste les 2 autres points:

WhyHey a écrit:2- cette synchro se base sur des infos de latences audio et video qui sont fixes (propre au récepteur Hdmi ou au repeteur) et les prochaines versions de Hdmi permettront d'avoir une valeur variable pour ces latences dont les valeurs varient de 0 à 500 ms (pour l'audio et la video)

4- ces latences sont fonctions du type de flux qu'il reçoit (l'AVR), il se peut que la latence d'un frame entrelacé est différent de la latence d'un frame progressif, la valeur choisi sera alors (2*max + min)/3, soit une valeur fausse pour les deux types de flux, allant même jusqu'à une erreur systématique de plus de 40ms (soit 2 images d'écarts pour du 50Hz !) (120 au max et 60 au min, la valeur sera fixée à 100, soit 40 d'écart pour le min de 60)