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

[polopo]

Comment arriver par calcul à partir de ce doc au nombre magique de 24.576Mb/s, mystère pour le moment (de mon coté en tout cas!)

Je ne trouve pas dans ce doc de réponse directe à la question dont on a débattu avec Pathou, à savoir:

- faut il obligatoirement avoir plus de 5 Gb/s pour supporter les 24.576 Mb/s des codecs compressés?

"HDMI can also carry an IEC 61937 compressed (e.g. surround-sound) audio stream at bit rates up to 24.576Mbps."
(Page 9 of 153 / HDMI spécification version 1.3 / June 22, 2006)

J'avais précisé "par calcul"

[jpu017]

Oui on peut laisser tomber le débat la dessus... il n'y a pas mort d'homme! Mais comprendre ce point aurait pu nous permettre de faire la part des choses entre les annonces et la réalité et on aurait saisi la logique de calcul entre ce que permet le tuyau de transport et la maniere de transporter les flux.

Je pense que la clef du 24.576 est dans les docs IEC sur les formats compressés mais je n'ai pas trouvé ces docs en téléchargement gratuit (je n'ai pas cherché 10 heures non plus)

En tout cas à 340Mhz/10Gb/s on a le temps de voir venir en terme de bande passante, surtout si en grand public le 1080p est le plafond pour de nombreuses années, comme il semble que ce soit le cas.

(petit préambule : j'aime bien l'ambiance de ce post, ou on peut argumenter sans s'insulter. Fin du préambule.)
En effet, il y a sûrement un calcul subtil qui mène à 24,576.
Il y a une question, que je vous pose à vous, gentlemen qui vous êtes fadés la spéc HMDI : quelle est la structure de cette interface ? Au niveau électrique, elle a l'air synchrone. Le "canal audio" (formulation de mon cru), par contre, a l'air défini à la couche au-dessus, puisqu'asynchrone. Comment, du coup, est gérée cette limite à 24,576 ?
J'ai l'air de pinailler, mais la réponse à un impact sur l'argument du "débit crête", déjà évoqué.

[iceman]

Oui on peut laisser tomber le débat la dessus... il n'y a pas mort d'homme! Mais comprendre ce point aurait pu nous permettre de faire la part des choses entre les annonces et la réalité et on aurait saisi la logique de calcul entre ce que permet le tuyau de transport et la maniere de transporter les flux.

Je pense que la clef du 24.576 est dans les docs IEC sur les formats compressés mais je n'ai pas trouvé ces docs en téléchargement gratuit (je n'ai pas cherché 10 heures non plus)

En tout cas à 340Mhz/10Gb/s on a le temps de voir venir en terme de bande passante, surtout si en grand public le 1080p est le plafond pour de nombreuses années, comme il semble que ce soit le cas.

(petit préambule : j'aime bien l'ambiance de ce post, ou on peut argumenter sans s'insulter. Fin du préambule.)
En effet, il y a sûrement un calcul subtil qui mène à 24,576.
Il y a une question, que je vous pose à vous, gentlemen qui vous êtes fadés la spéc HMDI : quelle est la structure de cette interface ? Au niveau électrique, elle a l'air synchrone. Le "canal audio" (formulation de mon cru), par contre, a l'air défini à la couche au-dessus, puisqu'asynchrone. Comment, du coup, est gérée cette limite à 24,576 ?
J'ai l'air de pinailler, mais la réponse à un impact sur l'argument du "débit crête", déjà évoqué.

En fait il n'y a pas de canal dédié à l'audio.

les 3 canaux TDMS servent à la vidéo. cependant ce flux vidéo n'est pas continu il ya des coupures et c'est dans ces coupures qu'on insère les paquets audio.
Comme je l'ai dit plus haut il faut donc des mémoires tampons et des modules de découpage et de reconstitution du flux audio.

je pense que cette limite de 24,576 est liée surtout à la latgeur des intervalles laissés libre dans le flux vidéo et par où doivent transiter les paquets audio.

[polopo]

Sinon pour ton dernier argument, (le décodage dans l'ampli ca peut etre mieux parce que le tuyau peu poser probleme): ca ne change rien: si les données sont lues dans la platine, elle doivent etre transportées dans l'ampli par le fameux tuyau. Et si elles sont altérées dans le transport vers l'ampli, qu'elles soient décodées ou codées, elles seront altérées

Il y a une différence fondamentale pour les exigeants, le lieu du décodage lossless,
décodage lossless dans l’ampli ou
décodage lossless dans la platine + parcours des bits primaires PCM via la liaison HDMI jusqu’à l’ampli, qui génère du jitter.

Le média c'est du HDMI, avec 3 canaux de données qui multiplexent la video et le son: il n'y aura pas plus de jitter sur un flux que sur un autre, en tout cas si le jitter provient du média.

Pour les exigeants, un bit qui arrive à destination mais décalé dans le temps à cause du jitter est un mauvais bit.

Et ton image sera alors pourrie aussi... ce n'est pas le cas. Pourquoi ca ne fonctionnerait pas pour le son alors que ca marche pour l'image et que la bande passante utilisée est infime en comparaison?

Un papier sur le sujet par Bob Stuart, le patron fondateur de Meridian.
http://www.meridian-audio.com/w_paper/Coding2.PDF

Ce papier porte sur le CD qui a des problemes particuliers (voir http://en.wikipedia.org/wiki/Jitter ). Comme en HDMI, vu la quantité et la qualité des données qui passent, il a fallu revoir justement comment on échange les informations au lieu de cracher les octets les uns derriere les autres sans trop se poser de question. HDMI c'est tout l'inverse du CD à ce niveau.

Une explication de texte d’Amir, VP de Microsoft.

C'est bien le mec qui explique que Vista dispose maintenant d'un systeme de correction accoustique similaire à Audyssey et consors, mais avec n'importe quel micro non calibré ?

The comment from the paper was that "packed PCM" (compressed with TrueHD, DTS lossless, etc.) can sound better than regular PCM. The question is why and what on earth is he talking about. Two people chimed in with the right conclusion (one in PM and one here), saying lack of correlated noise can result in better sound. But what is correlated noise and what causes it?
....
In case of compressed bit streams like lossless audio codec (and even lossy), the sequence of bits arriving into the decoder has no relationship whatsoever to the actual PCM samples. They have been randomized completely by the process of compressing the signal much like if you look at the zipped version of this post – you won’t recognize anything in there. This means that any distortion induced by the input signal, does not get transmitted to the output of the DAC so it is “uncorrelated” and less bothersome to the ear.
...
In the case of PCM coming across HDMI, that chain is quite long. Signal travels over HDMI receiver and over to the DAC. Because the signals have to travel far, they have to have very high level of power, which means that their impact on power supply and DAC will be far greater. In case of a compressed stream being decoded in a well designed player, the output signal can be very close to where the DAC is, and of much lower power than something coming across HDMI.

Sur du matos à 3 francs ou conçu il y a 30 ans et qui ne passerait pas la CEM aujourd'hui il a probablement raison. Mais dans un système conçu correctement ce genre de probleme ne doit pas se poser. A le lire on a l'impression que le PCM non compressé tire plus sur l'alim que du PCM compressé, c'est risible (surtout que dans les faits ca doit etre l'inverse: généralement plus tu traites un signal, plus tu consommes de l'énergie)

Parfois j'ai l'impression que parce qu'on parle de son, on entre dans le domaine de la magie noire, un peu comme ce gugus américain qui est convaincu que les cables d'enceinte donnent un meilleur son dans un sens que dans un autre.

T'imagines ce qui se passerait si dans ton PC les signaux videos bavaient sur les données du disque dur? Si le volume des HP avaient une influence sur les cycles de rafraichissement de la RAM? Si le trafic de ton cable Ethernet avait un impact décelable sur ton moniteur video? Ca serait catastophique, le signe d'un grave probleme de conception.

Alors qu'aujourd'hui le moindre PC trouvé en grande surface ne présente pas ces problemes, avec des composants et des bus qui tournent à des centaines de Mhz, pourquoi produire correctement quelques kilohertz de signaux pour le son serait si difficile? Si un bon signal numérique bien propre arrive à un bon DAC bien alimenté et non impacté par les autres composants, on aura un bon son (si on a des bonnes enceintes!), que le bon signal numérique sans erreur provienne du composant situé à 2mm ou 20 000km du DAC.

Ce Amir est connu pour troller partout sur le net pour faire de la pub pour les produits et technos dans lesquelles M$ a des intérêts...

[jpu017]

En fait il n'y a pas de canal dédié à l'audio.

les 3 canaux TDMS servent à la vidéo. cependant ce flux vidéo n'est pas continu il ya des coupures et c'est dans ces coupures qu'on insère les paquets audio.
Comme je l'ai dit plus haut il faut donc des mémoires tampons et des modules de découpage et de reconstitution du flux audio.

je pense que cette limite de 24,576 est liée surtout à la latgeur des intervalles laissés libre dans le flux vidéo et par où doivent transiter les paquets audio.

Yeah, j'avais dit "canal" pour dire quelque chose, puisque l'audio passe, vaille que vaille...
Ce que tu dis est ce qu'avais cru comprendre jusqu'à présent.
Du coup, la question devient : comment sont définies ces "coupures du signal vidéo" ? Sont-elles seulement statistiques ? Auquel cas, la valeur du débit audio (pour ne pas parler de canal), est-elle, elle aussi, statistique ? Non garantie ? Mais alors, pourquoi 24,576 ?
Sinon, s'il y a une sorte de délai de garde défini en clair dans le flux vidéo, et qui servirait à l'audio, ça revient à définir... Un canal !

[iceman]

en regardant de plus près il semble que l'audio n'a pas été prévu au départ.

en fait l'audio est inséré dans les espaces reservés pour les metadatas de la vidéo.

je m'explique le flux vidéo est interrompu par moment à intervalles réguliers pour y insérer des métadats qui serviront à le reconstruire correctement à l'arrivée par le récepteur une sorte de données de contrôle. et c'est avec ces métadatas de contrôle que sont insérés les paquets audio.

ça sent le bricolage à plein nez comme si on s'était rendu compte que la l'espace alloué aux métadatas était trop grand et on a par la suite décider d'y mettre l'audio.

[WhyHey]

le 24.576 est défini dans l'IEC 61937 pas dans l'HDMi, mais l'HDMi supporte cette norme, donc reprend ses caractéristiques.
on retrouve cette valeur dans l'IEEE 1394 (i-link), C.1.2.1.3 et c'est cette valeur qui donne justement le jitter max accepté par cette norme (ce que ne fait pas la norme HDMi 1.3a).
C'est 2 fois le max des fréquences d'échantillonages acceptés (cf page 33 des specs du 1394)

[WhyHey]

en regardant de plus près il semble que l'audio n'a pas été prévu au départ.

oui, et c'est normal puisque l'HDMi est la suite du DVi (la version 1.0 de l'HDMi est pratiquement un copier/coller de la version 1.1 du DVi), et en DVi: pas d'audio.

Alors après, faut bricoler pour tout mettre dedans (avec une seule horloge video ...)

[jpu017]

en regardant de plus près il semble que l'audio n'a pas été prévu au départ.

en fait l'audio est inséré dans les espaces reservés pour les metadatas de la vidéo.

je m'explique le flux vidéo est interrompu par moment à intervalles réguliers pour y insérer des métadats qui serviront à le reconstruire correctement à l'arrivée par le récepteur une sorte de données de contrôle. et c'est avec ces métadatas de contrôle que sont insérés les paquets audio.

ça sent le bricolage à plein nez comme si on s'était rendu compte que la l'espace alloué aux métadatas était trop grand et on a par la suite décider d'y mettre l'audio.

Passionnant... Nous progressons.
Il y a donc bien un canal ("à intervalles réguliers"). Là-dessus, ton hypothèse me parait bonne : comme il y avait de la bande passante, on y a casé l'audio.... Mais comme il y a quand même, en vérité, des métadatas, ce canal n'est pas dédié, et donc impose un multiplexage statistique au flux audio.

[jpu017]

en regardant de plus près il semble que l'audio n'a pas été prévu au départ.

oui, et c'est normal puisque l'HDMi est la suite du DVi (la version 1.0 de l'HDMi est pratiquement un copier/coller de la version 1.1 du DVi), et en DVi: pas d'audio.

Alors après, faut bricoler pour tout mettre dedans (avec une seule horloge video ...)

OK, c'est très clair.
A la base d'HDMI 1.0, il y a donc trois ingrédients :
- DVi 1.1
- un connecteur
- Et... Un canal de gestion ! Fourre-tout : métadatas, mais aussi sans doute l'échange d'infos entre appareils (c.f. le bon vieux "slow switch" de péritel).
Là-dessus, nos industriels s'avisent que le canal de management est surdimensionné, et visent un coup plus haut : une interface vidéo ET audio... Avec ça, ils ont presque rattrapé péritel. Presque, parce que HDMI reste mono-directionnel.
Bon, mieux vaut en rire, hein ?

[iceman]

CQFD

[polopo]

En rire je ne sais pas... après tout ce n'est pas la première fois qu'un canal d'information est employée à des fins qui n'ont rien à voir avec ce pour quoi il a été conçu (par exemple les SMS).

Pour en revenir au débat auprès duquel celui du sexe des anges est du music-hall

1) En HDMI 1.2 (j'ai pas été vérifier sur les versions antérieures) on passe à 96Khz 8 canaux sur 24 bits.

Combien de bits cela fait il par seconde? 96 000 * 8 * 24 = 18 432 000

C'est le débit max du LPCM non compressé: 18.432 megabit/s, soit la limite retenue par le DD TrueHD! Mais le LPCM est, déjà, par définition, lossless!

Alors qu'apporte DD TrueHD de plus avec la même quantité d'information?

C'est difficile à dire, mais je serai journaliste j'aimerai bien poser la question à quelqu'un de chez Dolby mais continuons:

2) Que se passe-t-il chez DTS?

Quand on lit la doc sur leur encodeur ( http://www.dts.com/media/DTS_MAS_brochure.pdf ) il apparait clairement (dans les photos d'écrans) que le débit est positionnable PAR CANAL! (je suppose que c'est pareil chez Dolby?)

Et bien supposons que les voix gauches et droites soient à 192Khz, le reste à 96Khz. Ca fait:

2*24*192000 + 6*24*96000=23 040 000.

Ah, pas mal, mais il en manque encore pour arriver à 24.576!

DTS permet de rajouter une piste appelée 'legacy core' pour offrir le support de matériel ne comprenant pas les derniers codecs. Cette piste 'héritée' plafonne à 1 536 000 b/s (et non 1509 kb/s comme on lit parfois)

23 040 000 + 1 536 000 = 24 576 000 b/s

CQFD (p'taing deux CQFD dans la journée dans le même sujet!). (si jamais ma cuisine avec 2 x 192 + 6 x 96 ne relève pas de la science fiction)

conclusion: a mon sens, le doublement de la bande passante de tout le HDMI uniquement à cause des codecs HD est injustifié. La preuve: le LPCM non compressé prend la même place que le débit max affiché par Dolby pour son TrueHD et je vois mal HDMI tout bazarder pour faire plaisir à DTS.

[jpu017]

En rire je ne sais pas... après tout ce n'est pas la première fois qu'un canal d'information est employée à des fins qui n'ont rien à voir avec ce pour quoi il a été conçu (par exemple les SMS).
[...]
DTS permet de rajouter une piste appelée 'legacy core' pour offrir le support de matériel ne comprenant pas les derniers codecs. Cette piste 'héritée' plafonne à 1 536 000 b/s (et non 1509 kb/s comme on lit parfois)

23 040 000 + 1 536 000 = 24 576 000 b/s

CQFD (p'taing deux CQFD dans la journée dans le même sujet!). (si jamais ma cuisine avec 2 x 192 + 6 x 96 ne relève pas de la science fiction)

Exact, les SMS passent par le canal de signalisation du GSM. Puisqu'on est dans les télécom', il y a aussi des canaux de management monstrueux spécifiés dans la SDH. Mais on sort du sujet...

Ton calcul est assez saisissant.
La piste "legacy core" pourrait bien être celle qui porte... Le DTS actuel !
En effet, DTS a structuré précisément son algo comme ça : un "core" qui correspond au DTS actuel, et une couche supérieure, qui correspond aux algos HD. Plus précisément encore, cette couche porte les infos complémentaires, celles que le core a poubellisées.
Ce point a été discuté ici (bas de page) il y a qqes mois.
C'est grace à ça qu'ils se proclament rétro-compatibles.

[WhyHey]

2) Que se passe-t-il chez DTS?

Quand on lit la doc sur leur encodeur ( http://www.dts.com/media/DTS_MAS_brochure.pdf ) il apparait clairement (dans les photos d'écrans) que le débit est positionnable PAR CANAL! (je suppose que c'est pareil chez Dolby?)

Et bien supposons que les voix gauches et droites soient à 192Khz, le reste à 96Khz. Ca fait:

2*24*192000 + 6*24*96000=23 040 000.

Ah, pas mal, mais il en manque encore pour arriver à 24.576!

DTS permet de rajouter une piste appelée 'legacy core' pour offrir le support de matériel ne comprenant pas les derniers codecs. Cette piste 'héritée' plafonne à 1 536 000 b/s (et non 1509 kb/s comme on lit parfois)

23 040 000 + 1 536 000 = 24 576 000 b/s

CQFD (p'taing deux CQFD dans la journée dans le même sujet!). (si jamais ma cuisine avec 2 x 192 + 6 x 96 ne relève pas de la science fiction)

pas mal vu !!
mais c'est dire que le "core" vient en plus,
en DTS 6.1 ou 96/24, ce n'est pas le cas, lire:
http://www.analog.com/UploadedFiles/Tec ... _final.pdf
je doute qu'en DTS-MA ils aient changé le découpage qu'ils avaient initié avec le 6.1 ou le 96/24, le "core" se déduit (grace à des filtres, ceux qui existent en standards dans les machines qui n'ont pas évoluées), il ne s'ajoute pas.

Mais ça y est presque ... (enfin sauf que le flux n'est pas un flux LPCM donc on ne peut pas atteindre le résultat avec ce genre de calcul qui convient aux LPCM)

[coldhand]

DTS seras a l'IFA pour des demo DTS-HD MA....

affaire a suivre car je ne voit pas comment il pourrais présenter autre chose qu'un platine compatible bitstream sur un ampli hdmi 1.3