Kassa test HDMI kabels & kwaliteit HDMI kabels

[Ejorne]

Heren,

Toch maar even terugkomend op de kabel kwestie.
Ik hoop binnenkort te beginnen met mijn ht-tje door een tw980 aan te schaffen.
Nu moet ik natuurlijk ook een fatsoenlijke hdmi kabel hebben, lengte ca 10 meter.
Wat is nu eens een aardige kabel om mee te beginnen?
Hoeft niet topsegment te zijn, maar rotzooi vind ik ook weer zonde.

bedankt..

Tja, lees eens terug. Welk antwoord wil je hebben? Pik er maar eentje uit...

[DeDream]

Quasi elke flatpanel doet basically aan buffering (de-interlacing + scaling), wat wil zeggen dat op niveau van jitter het weinig uitmaakt, omdat je eerst een full-frame moet kunnen bufferen alvorens je plasma, projector of lcd dit kan weergeven. En als bij 24P een frame 1/24 van een seconde duurt dan is de typische schaal van transmissiejitter (nano/pico ?) niet meer relevant. Het is niet zoals audio waarbij een sample onmiddelijk wordt afgespeeld en van een veeeeeeeeel kortere duur is dan een videoframe.

Dus als er al visuele verschillen zijn dan ben ik benieuwd naar een wetenschappelijke fundering hoe dit mogelijk is.

Goed zo, laten we on topic blijven...

Begrijp de opmerking van klinktbeter, interessant overigens, niet helemaal simpelweg omdat mijn kennis over het hdmi protocol niet toereikend is. Volgens enkelen waaronder garmtz is het hdmi protocol gevoeliger voor jitter dan bijv het s/pdif protocol. Dat het s/pdif een robuust protocol is, daar ben ik het mee eens voor zover het clock process naar behoren werkt.

Wat ik niet begrijp is dat het AUDIO signaal dus onderhevig is aan jittter, en dus minder klinkt dan een een s/pdif kabel, terwijl voor het VIDEO signaal een "intelligente" gebufferde oplossing wordt gehanteerd die de timing fouten (jitter) in het videosignaal opheft? Dat zou in theorie kunnen als de timing informatie in het signaal is opgeslagen net zoal bij s/pdif. Dit zou deels ook de verklaring kunnen zijn dat goedkope en dure kabels hetzelfde resultaat oplevert.

Maar dat lijkt op het "ei van Columbus" en ik vraag me af waarom die toepassing dan niet voor audiosignalen kan worden toegepast? Nogmaals mijn kennis is niet voldoende om datgene wat klinktbeter stelt te ontzenuwen maar ik blijf enige twijfels houden over de stelling. Naar mijn mening wordt het video signaal niet hergeklokt zoals in sommige dacs wordt gedaan of bijvoorbeeld in usb waar het een data signaal betreft en een master/ slave oplossing de integriteitvan het signaal kan bewaren. Ik zou niet weten hoe dat in een display in zijn werkt gaat...

Volgens mij is dat niet het geval (tot het tegendeel wordt bewezen) en is mijn stelling dus dat we tot nu toe bij audio veel kritischer zijn dan bij video het geval is en is het video signaal net als bij audio wel degelijk onderhevig aan jitter en dus degradatie van het signaal. Dat dat bij een kabel van 1,5m marginaal is en door de gemiddelde kijker niet wordt opgemerkt dat geloof ik best. In het artikel van gizmodo is overigens ook te zien dat de signaal analyse van een 1080p signaal een ander resultaat oplevert bij de goekope kabel.

DeDream

[ShellBeach]

Begrijp de opmerking van klinktbeter, interessant overigens, niet helemaal simpelweg omdat mijn kennis over het hdmi protocol niet toereikend is. Volgens enkelen waaronder garmtz is het hdmi protocol gevoeliger voor jitter dan bijv het s/pdif protocol. Dat het s/pdif een robuust protocol is, daar ben ik het mee eens voor zover het clock process naar behoren werkt.

HDMI doet meer dan alleen video .... het doet naast audio en video ook nog eens signalisatie ...
Buffering is dus kritisch. Bij video gaat dat makkelijker dan bij audio, lees verder ....

Wat ik niet begrijp is dat het AUDIO signaal dus onderhevig is aan jittter, en dus minder klinkt dan een een s/pdif kabel, terwijl voor het VIDEO signaal een "intelligente" gebufferde oplossing wordt gehanteerd die de timing fouten (jitter) in het videosignaal opheft? Dat zou in theorie kunnen als de timing informatie in het signaal is opgeslagen net zoal bij s/pdif. Dit zou deels ook de verklaring kunnen zijn dat goedkope en dure kabels hetzelfde resultaat oplevert.

Je moet eens naar de eerste Matrix kijken, de scene waar neo leert vechten tegen Morpheus. De crew van het schip zit op zo'n stom TFT scherm mee te kijken. Je ziet dat het beeld schokt en in stukken wordt opgebouwd. Dit is natuurlijk een bewust gedaan effectje, maar als je pixel per pixel van een HDMI kabel realtime onmiddelijk zou toveren op je panel, zonder buffering of processing, dan zou het beeld er ongeveer zo uitzien. Och, in de eerste versie van quake kon je dit ook instellen, hoe het beeld refreshed moest worden: wachten op de sync van de refresh rate, of zo snel mogelijk. Dat laatste gaf ook het matrix effectje en zou voor videofielen onkijkbaar zijn.  Oude optoma projectoren hadden ook deze bug in hun firmware.

Video processing komt er ongeveer op neer:

- er komen fields of frames binnen, en uiteindelijk al dan niet na de-interlacing staat er een full frame klaar in een buffer
- de DAC of whatever circuit dat het beeld uitleest switcht naar het beeld wat klaar staat in de buffer
- ondertussen wordt het toekomstige beeld in een andere buffer opgebouwd

en op die manier wordt er dus tussen twee volledige beelden steeds geswitched. Terwijl het ene beeld getoon wordt, wordt het andere ontvangen/opgebouwd.
Doe je dit niet en update je de pixels zoals ze binnenkomen over een digitale link, dan heb je picture breakup.

Iets wat ik al lang intuitief begrijp, op wikipedia staat een variant:

Deinterlacing requires the display to buffer one or more fields and recombine them into a single frame. In theory this would be as simple as capturing one field and combining it with the next field to be received,  producing a single frame. However the originally recorded signal was produced as a series of fields, and any motion of the subjects during the short period between the fields is encoded into the display. When combined into a single frame, the slight differences between the two fields due to this motion results in a "tearing" effect where alternate lines are slightly displaced from each other.

Modern deinterlacing systems therefore buffer several fields and use techniques like edge detection in an attempt to find the motion between the fields. This is then used to interpolate the missing lines from the original field, reducing the "tearing" effects.[1]

Hoe past jitter in dit verhaal ?

De tijd die nodig is om een field of full frame binnen te krijgen is max 1/60 of 1/25 van een seconde, want anders kan je link niet snel genoeg de data binnen krijgen. De variabele transfer delay (jitter) van die ene pixel (dit is de transfer van 24 bits bij sRGB) is daardoor niet meer relevant tov de totale duurtijd van het volledige field, wat 2x10E6 langer duurt (ja 2 mljoen, een full-hd beeldje heeft +- 2 miljoen pixels per frame).

Maar dat lijkt op het "ei van Columbus" en ik vraag me af waarom die toepassing dan niet voor audiosignalen kan worden toegepast? Nogmaals mijn kennis is niet voldoende om datgene wat klinktbeter stelt te ontzenuwen maar ik blijf enige twijfels houden over de stelling. Naar mijn mening wordt het video signaal niet hergeklokt zoals in sommige dacs wordt gedaan of bijvoorbeeld in usb waar het een data signaal betreft en een master/ slave oplossing de integriteitvan het signaal kan bewaren. Ik zou niet weten hoe dat in een display in zijn werkt gaat...

Bij audio daarentegen duurt een sample bij DVD 1/48.000 van een seconde, en de typische jitter over HDMI is dus proportioneel vele malen groter tov deze duurtijd. En omdat HDMI ook audio transfered en de designers nog niet even leentjebuur hebben gespeeld bij de netwerkjongens die al 20 jaar jitter onder controle hebben, is het voor audio over HDMI wel een issue. Want als ze de data juist bufferen dan is transport jitter geen issue voor wat de DAC uiteindelijk ziet.

Het bewijs daarvan is internet radio: of ik nu adsl of kabel heb, een radiostation klinkt even mooi ondanks het feit dat de data met andere jitterwaardes mijn buffer van mijn netwerkspeler binnenloopt, want elke ISP heeft zijn eigen belasting en eigen routers die ene variabele delay in de datastroom gooien. Maar zolang er maar snel genoeg data binnenloopt en de buffer niet leeg geraakt klinkt het over adsl of kabel identiek, nochtans hebben elk hun eigen jitter waardes. Ik heb die test jaren geleden gedaan met een degelijke geluidskaart, maakt geen drol uit, omdat de basis goed is, en deze jongens geen belangen hebben in de verkoop ethernet kabels van 1000/meter terwijl jitter toch niks uitmaakt in deze netwerkwereld.

Volgens mij is dat niet het geval (tot het tegendeel wordt bewezen) en is mijn stelling dus dat we tot nu toe bij audio veel kritischer zijn dan bij video het geval is en is het video signaal net als bij audio wel degelijk onderhevig aan jitter en dus degradatie van het signaal. Dat dat bij een kabel van 1,5m marginaal is en door de gemiddelde kijker niet wordt opgemerkt dat geloof ik best. In het artikel van gizmodo is overigens ook te zien dat de signaal analyse van een 1080p signaal een ander resultaat oplevert bij de goekope kabel.

DeDream

Stel dat de vertoningstijd van elk frame bij 24p varieert met de gemiddelde jitter van enkele pico of nanoseconden. Maakt geen drol uit, want de video DAC leest toch gewoon uit een full-frame buffer, en als een frame nu begint op 1/24 van een seconde, of 1/24 + 10E-12 ... wel dat maakt niks uit. Waarom denk je dat 24 frames per seconde de filmstandaard is ? We kunnen gewoon niet veel meer beelden per seconde verwerken, enige uitzondering daarop zijn pans, omdat het een statisch beeldje is wat schuift, op 48p of 60p zijn de pans wel smooth.

Voor audio is het een totaal andere kwestie, uit testen blijkt dat we jitter van 500ns reeds kunnen onderscheiden:

http://www.jstage.jst.go.jp/article/ast/26/1/50/_pdf

De discussie gaat natuurlijk over video jitter. Laten we stelling even poneren:

500ns (500 * 1/1 000 000 000 s) gemiddelde delay op de vertoning van een 24p (1/24 s) beeldje is voor het oog niet capteerbaar. Als er al een verschil in kabels zit op videogebied dan is dit volgens mij te wijten aan foutieve transmissie en het niet toepassen van foutcorrectie. Het fisheye pattern is de industrie standaard voor het meten van rotzooi op 10 Gbps transmissie, je ziet heel duidelijk de verschillen tussen de kabels. De geintroduceerde fouten en verschillen moeten in het domein van een een hoge ber (bit error rate) te zoeken zijn.

PS: ik wens hier de discussie verder te zetten of het feit waarom jitter op video bij een correcte transmissie niet echt relevant is.
Geen 100e discussie over audio jitter aub, daarvoor zijn er reeds threads. On topic graag.

PS2: misschien kent Frank Doorhof een aantal industry experts welke mee hebben geholpen met de HDMI standaard die hier eens een echte ongezouten mening durven neerzetten zonder kleuring of bias, ter verificatie van mijn ponering, zonder belangen in kabelverkoop.

[marconist]

Lijkt mij nuttig als dit eerst wordt doorgenomen.
Anders wordt het weer een gebed zonder end ...... 

http://www.siliconimage.com/docs/understanding_DVI/

[roland p]

PS: ik wens hier de discussie verder te zetten of het feit waarom jitter op video bij een correcte transmissie niet echt relevant is.
Geen 100e discussie over audio jitter aub, daarvoor zijn er reeds threads. On topic graag.

Waarom wil je discusseren over iets wat niet relevant is?
Het gaat hier meer om foute bitjes.

[marconist]

Dit is ook wel even leuk. Deep color vergroot de eis aan de verbinding, dus de wat mindere kabels zullen hier meer moeite mee hebben.  

https://www.simplaylabs.com/flash/deepcolor.html

[marconist]

Waarom wil je discusseren over iets wat niet relevant is?
Het gaat hier meer om foute bitjes.

Foute bitjes is geen probleem ..... foute woorden (een reut bitjes dus!) wel.
In die zin is zijn stelling relevant.

[roland p]

Foute bitjes is geen probleem ..... foute woorden (een reut bitjes dus!) wel.
In die zin is zijn stelling relevant.

Waarom is jitter relevant bij een correcte transmissie?

[marconist]

Waarom is jitter relevant bij een correcte transmissie?

Omdat de kwaliteiten van de chips (ic. de bufferingtechniek) en de filosofie van de clocktransmissie bij HDMI/DVI een grote rol spelen. Zie mijn berichtje van 11.09u.
Edit: dat verschilt wezenlijk van b.v. SPDIF. 

[roland p]

Omdat de kwaliteiten van de chips (ic. de bufferingtechniek) en de filosofie van de clocktransmissie bij HDMI/DVI een grote rol spelen. Zie mijn berichtje van 11.09u.

Ik probeer dat document te openen, maar ik zie alleen een grijs beeld, zowel met IE7 als FireFox...

[ShellBeach]

Waarom wil je discusseren over iets wat niet relevant is?
Het gaat hier meer om foute bitjes.

Lees mijn stelling opnieuw. Als er een verschil zit tussen kabels dan is het omwille van de ber (bit error rate).
Gisteren maar eens de specs opgevraagd van HDMI buffer chips, er zit effectief equi en impedantie matching circuitjes in om om te kunnen met diverse en vooral lange kabels.

Och deze chips kosten 1,5$ stuk voor groter oplages 

[roland p]

Lees mijn stelling opnieuw. Als er een verschil zit tussen kabels dan is het omwille van de ber (bit error rate).
Gisteren maar eens de specs opgevraagd van HDMI buffer chips, er zit effectief equi en impedantie matching circuitjes in om om te kunnen met diverse en vooral lange kabels.

Och deze chips kosten 1,5$ stuk voor groter oplages 

Ik denk dat we het wel met elkaar eens zijn.

Die chips zouden ze gewoon in elke projector moeten zetten

[Alleycat]

Lees mijn stelling opnieuw. Als er een verschil zit tussen kabels dan is het omwille van de ber (bit error rate).
Gisteren maar eens de specs opgevraagd van HDMI buffer chips, er zit effectief equi en impedantie matching circuitjes in om om te kunnen met diverse en vooral lange kabels.

Och deze chips kosten 1,5$ stuk voor groter oplages 

Wat staat hier nou ? leest men zelf wel eens terug wat men schrijft ?

"Verschil omwille van de ber" bedoel je hiermee dat bewust de ber per kabel wordt veranderd?


"er zit effectief equi en impedantie matching circuitjes in om om te kunnen met diverse en vooral lange kabels."

[marconist]

Och deze chips kosten 1,5$ stuk voor groter oplages 

Jaaaa, en hebben niet allemaal approval van SG, dus de kwaliteit kan nogal variëren. Daar zit minstens zo'n probleem als bij krakkemik vervaardigde kabels.

[ShellBeach]

Lijkt mij nuttig als dit eerst wordt doorgenomen.
Anders wordt het weer een gebed zonder end ...... 

http://www.siliconimage.com/docs/understanding_DVI/

DVI is resistent tegen jitter als de kabels en transceivers binnen de specs vallen
En de clock kan recovered worden net zoals bij SP/DIF met een PLL schakeling, maar hier is het bidirectionele communicatie.

Dus als een kabel en de transceiver chips aan de specs gehoorzamen, dan mag de jitter NUL invloed hebben op het beeld. Alle de rest moet als gevolg ofwel ingebeeld zijn of ten gevolge van niet-compliancy in je apparatuur en dus bit errors.

[roland p]

Jaaaa, en hebben niet allemaal approval van SG, dus de kwaliteit kan nogal variëren. Daar zit minstens zo'n probleem als bij krakkemik vervaardigde kabels.

Nou, ik heb zo'n kastje wat heel goed werkt. Chipje opgezocht op internet, was niet duurder dan een paar dollar. Maar het zou natuurlijk slecht voor de kabelbranche zijn als er in ieder apparaat zo'n chipje zou zitten

[marconist]

DVI is resistent tegen jitter als de kabels en transceivers binnen de specs vallen
En de clock kan recovered worden net zoals bij SP/DIF met een PLL schakeling, maar hier is het bidirectionele communicatie.

Dus als een kabel en de transceiver chips aan de specs gehoorzamen, dan mag de jitter NUL invloed hebben op het beeld. Alle de rest moet als gevolg ofwel ingebeeld zijn of ten gevolge van niet-compliancy in je apparatuur en dus bit errors.

Als je SG even volgt, zie je dat één van hun worries het niet goed begrijpen van de aanpak van het circuit is. Daarom leveren ze zelf ook nog steeds een chip (let wel: het stukje silicium dat je als onderdeel in het totale circuitje van een IC-fabrikant plakt). Er zijn echter nog steeds (Chinese??) leveranciers die zelf maar wat aanprutsen en daarmee de kabeltoepassing kritischer maken dan noodzakelijk is.


Edit: waarom noem je de datacomm bidirectioneel??

[ShellBeach]

Als je SG even volgt, zie je dat één van hun worries het niet goed begrijpen van de aanpak van het circuit is. Daarom leveren ze zelf ook nog steeds een chip (let wel: het stukje silicium dat je als onderdeel in het totale circuitje van een IC-fabrikant plakt). Er zijn echter nog steeds (Chinese??) leveranciers die zelf maar wat aanprutsen en daarmee de kabeltoepassing kritischer maken dan noodzakelijk is.

Ik heb het duidelijk gemerkt. Vroeger had ik een BenQ scherm, slikte perfect alle DVI/HDMI kabels en alle dongles, mijn Panasonic plasma wil enkel met degelijke kabels en een officiele ATI DVI->HDMI adapter locken, al de rest werkt niet. Ergerlijk is dat. Och de BenQ had toch geen bitfouten in het beeld whatever kabel ik gebruikte ik kon geen verschillen zijn.

Je vraagt je dan af waarom ze de implementatie zo "brak" (lees gevoelig) maken ... kabelverkoop ? Of het ontbreken van goede transceiver chips.

Edit: waarom noem je de datacomm bidirectioneel??

DVI en HDMI zijn bidirectioneel

[garmtz]

Begrijp de opmerking van klinktbeter, interessant overigens, niet helemaal simpelweg omdat mijn kennis over het hdmi protocol niet toereikend is. Volgens enkelen waaronder garmtz is het hdmi protocol gevoeliger voor jitter dan bijv het s/pdif protocol. Dat het s/pdif een robuust protocol is, daar ben ik het mee eens voor zover het clock process naar behoren werkt.

Dat zeg ik echt NERGENS!!! Ik zeg alleen dat de hoeveelheid jitter op het audio-gedeelte van een HDMI stream zo enorm hoog is, dat het weinig zin heeft naar de kabel-interface te kijken, maar eerder naar het protocol. Dit komt omdat de audio wordt geclocked op het videosignaal.

Een snelle zoekactie via Google levert het volgende op: http://www.avforums.com/forums/blogs/welwynnick-64635/626-how-does-jitter-affect-hdmi.html

Deze man legt goed uit wat ik hierboven zeg.

Het ligt dus niet aan de HDMI kabels zelf, maar aan de audio-clock die wordt geslaved aan de video-clock. Ik heb zelf een test gedaan met 16bit/44.1kHz data (CD) over HDMI vs een S/PDIF coax en de S/PDIF verbinding was absoluut superieur.

Ik zie niet in waarom een HDMI kabel om andere redenen 'gevoeliger' zou zijn voor jitter dan een coax of Toslink.

[marconist]

DVI en HDMI zijn bidirectioneel

Nee, hoor. Gewone stream. Kan ook niet anders als je die drie datastromen bij de les wilt houden m.b.t. de klok.
Streams zijn tijdkritisch. Je bent wellicht in de war met een "gewone" datastroom zoals gebruikt in karaktertransmissie-systemen.

[roland p]

Nee, hoor. Gewone stream. Kan ook niet anders als je die drie datastromen bij de les wilt houden m.b.t. de klok.
Streams zijn tijdkritisch. Je bent wellicht in de war met een "gewone" datastroom zoals gebruikt in karaktertransmissie-systemen.

Je hebt met HDMI wel handshaking, (ok andere data) dus in zekere zin is het wel bidirectioneel.

[BWzes03]

Heren,

Toch maar even terugkomend op de kabel kwestie.
Ik hoop binnenkort te beginnen met mijn ht-tje door een tw980 aan te schaffen.
Nu moet ik natuurlijk ook een fatsoenlijke hdmi kabel hebben, lengte ca 10 meter.
Wat is nu eens een aardige kabel om mee te beginnen?
Hoeft niet topsegment te zijn, maar rotzooi vind ik ook weer zonde.

bedankt..

Heb zelf een kabel gekocht via één van de forumsponsors, en heb gekozen voor een "Profigold SKY", zeer degelijk gemaakte kabel, goed klemmende connectoren, en goed meervoudig afgeschermd, wat wel nodig is bij langere lengten...
Is zomaar een keuze.... er zijn er zoveel....

[marconist]

Je hebt met HDMI wel handshaking, (ok andere data) dus in zekere zin is het wel bidirectioneel.

Welke handshake? Ik neem aan dat je niet doelt op DDC of CEC. Dat zijn statuslijnen.

[garmtz]

Welke handshake? Ik neem aan dat je niet doelt op DDC of CEC. Dat zijn statuslijnen.

Ik denk dat Roland HDCP handshaking bedoelt... Er is wel bi-directioneel verkeer, maar geen flow control. Misschien bedoel jij dat marconist?

[marconist]

Dat zeg ik echt NERGENS!!! Ik zeg alleen dat de hoeveelheid jitter op het audio-gedeelte van een HDMI stream zo enorm hoog is, dat het weinig zin heeft naar de kabel-interface te kijken, maar eerder naar het protocol. Dit komt omdat de audio wordt geclocked op het videosignaal.

Een snelle zoekactie via Google levert het volgende op: http://www.avforums.com/forums/blogs/welwynnick-64635/626-how-does-jitter-affect-hdmi.html

Deze man legt goed uit wat ik hierboven zeg.

Het ligt dus niet aan de HDMI kabels zelf, maar aan de audio-clock die wordt geslaved aan de video-clock. Ik heb zelf een test gedaan met 16bit/44.1kHz data (CD) over HDMI vs een S/PDIF coax en de S/PDIF verbinding was absoluut superieur.

Ik zie niet in waarom een HDMI kabel om andere redenen 'gevoeliger' zou zijn voor jitter dan een coax of Toslink.

Je zit m.i. op het goede pad.  
Maar het valt met die videoklok wel mee denk ik, anders krijg je dat "eye-pattern" niet voor elkaar. Ik denk dat de constructeurs van het audiodeel verzuimen om daar een extra PLL o.i.d. in te frommelen om zeker te maken dat bij het aanbieden van de verschillende videoklokfrequenties de audiokant rocksolid gelijk blijft lopen.
Je kunt inderdaad soms hebben dat de zaak  hartstikke fout sync'ed en je leuke CD'tje klinkt alsof ie via een mobiele telefoon is verstuurd.