my thoughts on hdmi cables, and the randomness of potential data loss...

[Anonymous]

professorhat:Mr Mellie:professorhat:Mr Mellie:Most of the answers are subjective so how about a more scientific approach?

Take a known source, say the fist 1GB of any film you like and save as a file on disk on computer 1.

Read the computer 1 file and send via HDMI to computer 2.

Computer 2 captures the data and saves to disk.

Now compare the file on computer 1 with that on computer 2.

Can not be that hard can it?

Finding two computers which communicate not only via HDMI cables, but which can also communicate using the same protocols that Blu-Ray players use to send data to TVs - that may be fairly hard, yes.

The reason for putting the data on disk was to remove and Blu-Ray /
dodgy disk problems. A computer disk will always return the same data.
The protocol will be HDMI surely? All we want to test is the cable nothing else.

I understand you want to use a computer's hard disk, but the reason a computer's hard disk returns the same data every time is down to similar transport protocols that ensure you always get the same data, such as the ones used when you download something from the internet - error correction is inherently built into these protocols to ensure data is always correct. Hard disks are not infallible and you'll get read errors from them just as you will from CDs, DVDs or Blu-Rays (though they are admittedly a lot less error prone for obvious reasons). These protocols ensure that any errors are corrected, if necessary by reading a hard disk again.

As well as this, as the_lhc has said, computers don't communicate with each other over HDMI cables. And HDMI is not a computer transport protocol (like TCP/IP is for example, which is the main transport protocol used by computers over networks at this point in time). HDMI is an interface created specifically for transmitting audio and visual data. So the major issues of setting up your test still stand I'm afraid.

Yeah I think I understand how computers communicate.

HDMI can be used to send and capture data using the video cards and HDMI capture cards. Just need someone with the time, money and inclination to do it.

WHF could look into the possibility of getting a test system set up. Maybe get the cable manufacturers to contribute

.

You are right in that HDMI is designed to transfer sound and video however the interface sends digital data it does not care about the content.

Having done some investigation HDMI looks more like UDP than TCP to me in that there is no time to check the receiver is getting the data correctly, the sender just keeps sending it. UDP is used for streaming media on the net for services like iPlayer. There is no error correction or resending of data with UDP.

 

[professorhat]

Mr Mellie:Having done some investigation HDMI looks more like UDP than TCP to me in that there is no time to check the receiver is getting the data correctly, the sender just keeps sending it.

Indeed, I'd agree, something like UDP, but doubtful it actually is UDP. I'm more than happy to stand corrected if you can show a source that it is UDP. However, the key statement there is no error checking as there is no time to check the receiver is getting data. This is fine in local connections like HDMI as, since it's local, there should be relatively few errors (compared with sending data over the internet for example). However, it won't be error free - that's impossible. So there needs to be some basic error correction going on to essentially "guess" what any data that hasn't come through is - this has to be guessed as errors cannot be resent when using UDP as there is no process to request this.

Mr Mellie:UDP is used for streaming media on the net for services like iPlayer. There is no error correction or resending of data with UDP.

No, TCP is used for streaming media over the internet, precisely because there has to be the ability to check for errors and get data resent when sending it over the internet. Try UDP streaming over the internet and you'll just get a mess of corrupt data. This is why you have a buffer build up when you start watching something through iPlayer over the internet - this gives enough data that has been sent through correctly to ensure the rest of the video can be played without interruption (as data needs to be requested and resent when it isn't received properly). Sometimes, it gets the size of this buffer wrong and it's too small, which is why video can start and stop when streaming over the internet as it has to stop and wait for enough correct data to be received before carrying on.

This article explains the process quite well.

 

[idc]

aliEnRIK:

....

I'll repeat, I personally havnt seen anything CONCLUSIVE to say one cd player is better than another with blind testing. If you recall you read on another forum where the cable believers got 100% right and the sceptics did no better than pure guessing. YOU said your not allowing that as it was one test. If your allowing the cd player, you HAVE to allow that forums cable test too

There have been positive blind tests at audioholics, stereophile, a number on ABX comparitor, Head-Fi, Hydrogen Audio and The Boston Audio Society. The likes of amps, CDPs and speakers are identified as being different so they are recognisable as such. Whether any is better or not is not what blind testing is about.

I have no idea what test you are referring to where cable believers got 100% right.

I think that confusion arises because one subject of a blind test or one blind test on its own is not good evidence. You need a whole load of blind tests to get an accurate idea of what the result is going to be. Since some get 0% and others get 100%, but the general cluster is around 50% and that strongly suggests random, which is a fail. To show something is recognisably different you really should get 90% plus all of the time, with different people in difference circumstances.

 

[Anonymous]

Why do people think that u will see packet loss over a length of say 2m or less? For long runs I'd agree -but not for short lengths.

If u read what actually goes on within the HDMI certification labs, and what it required for a cable to pass certification then you will see its highly unlikey u will experience errors unless your cable is actually faulty.

 

[Anonymous]

edsib1:

Why do people think that u will see packet loss over a length of say 2m or less? For long runs I'd agree -but not for short lengths.

If u read what actually goes on within the HDMI certification labs, and what it required for a cable to pass certification then you will see its highly unlikey u will experience errors unless your cable is actually faulty.

yup, that's how i see it.
no errors = no data loss..

no data loss = no picture/sound degradation.

a cheap cable = any other cable.

 

[Streamer]

Surely one of these would all but guarantee the best picture/sound quality and solve the argument once and for all....

http://www.futureshop.co.uk/wireworld-platinum-starlight-hdmi-to-hdmi-cable-20m-p-3479.html

 

[Anonymous]

Streamer:
Surely one of these would all but guarantee the best picture/sound quality and solve the argument once and for all....

http://www.futureshop.co.uk/wireworld-platinum-starlight-hdmi-to-hdmi-cable-20m-p-3479.html

imagine how much money they would make if they only sold 100 of them a year

 

[Streamer]

I'd be amazed if they sold any at all at that price!

 

[idc]

Even Wireworld acknowledge that all their incredibly expensive cable needs to do is transfer data without errors "However, the ultimate image quality of HDMI connections is often clouded
by the data losses caused by inadequate cable performance." and meet specifications. They mention using more wires than other HDMI cables, but there is nothing beyond that in terms of evidence of improved performance.

 

[Anonymous]

idc:Even Wireworld acknowledge that all their incredibly expensive cable needs to do is transfer data without errors "However, the ultimate image quality of HDMI connections is often clouded
by the data losses caused by inadequate cable performance." and meet specifications. They mention using more wires than other HDMI cables, but there is nothing beyond that in terms of evidence of improved performance.
aye, and if a cable suffered from such data loss it wouldn't get past quality control

so erm.....

 

[The_Lhc]

maxflinn:and if a cable suffered from such data loss it wouldn't get past quality control

so erm.....

Well that depends entirely on the integrity of the company making it...

It's worth pointing out that that particular cable is 20m long, alright it's not worth 8 grand anyway, but to get an HDMI cable to work at all over that distance (where the extremely high frequency signal will be seriously attenuated by that distance and terminator reflections become a serious issue) will require a very well constructed cable.

 

[Clare Newsome]

Yep, as someone whom has used/uses 10-15m HDMI cables (from receiver to projector), I can testify that quality cable is a must at such lengths. I've tried some cables that simply didn't work (horrible sparklies etc) and others that were more temperamental than was liveable with. Not that you need to spend a fortune, mind you...

 

[idc]

In the test I read a Wireworld cable started to register fails at as little as 5 metres. It was also one of the more expensive cables on test.

 

[Anonymous]

the_lhc:maxflinn:and if a cable suffered from such data loss it wouldn't get past quality control

so erm.....

Well that depends entirely on the integrity of the company making it...

It's worth pointing out that that particular cable is 20m long, alright it's not worth 8 grand anyway, but to get an HDMI cable to work at all over that distance (where the extremely high frequency signal will be seriously attenuated by that distance and terminator reflections become a serious issue) will require a very well constructed cable.aye, agreed re quality control, though any company that isn't stringent in that area would soon be out of business, it's in their own interest to make sure their products are fit for purpose..

and yea, it's also my understanding that the longer the cable the more likelyhood of failure..

 

[Anonymous]

edsib1:Why do people think that u will see packet loss over a length of say 2m or less? For long runs I'd agree -but not for short lengths.
If u read what actually goes on within the HDMI certification labs, and what it required for a cable to pass certification then you will see its highly unlikey u will experience errors unless your cable is actually faulty.

You've just changed the story. Most cheap cables aren't certified! Even the famous flat van-den-hull is only certified HDMI 1.4 upto 7 meters.

 

[Anonymous]

If u want to buy a non-certified cable then u need to be aware that u may encounter problems.

Comparing a non-branded, uncertified hdmi cable made in china to a certified cable may well show differences depending on how poor the uncertified cable is.

All Im saying is that over a short length the picture quality between 2 certified cables - 1 cheap 1 expensive will be the same as there should be no packet loss.

I would also add that if a magazine/website wants to set itself up reviewing things like cables ideally they would publish the appropriate data to support their review. In this case that would be what % of packet loss (if any) they see when transmitting media over various lengths. Without the data its just an unsubstantiated opinion, and u should take that into account.

 

[professorhat]

edsib1:Without the data its just an unsubstantiated opinion, and u should take that into account.

How does that differ from a review of any other type of product that you read?

 

[Anonymous]

professorhat:
How does that differ from a review of any other type of product that you read?

some websites publish their review data so you can form your own opinion.

 

[professorhat]

edsib1:professorhat:How does that differ from a review of any other type of product that you read?some websites publish their review data so you can form your own opinion.

Ah, so those are the only trustsworthy reviews. I see your angle now.

 

[Anonymous]

professorhat:
Mr Mellie:Having done some investigation HDMI looks more like UDP than TCP to me in that there is no time to check the receiver is getting the data correctly, the sender just keeps sending it.

Indeed, I'd agree, something like UDP, but doubtful it actually is UDP. I'm more than happy to stand corrected if you can show a source that it is UDP. However, the key statement there is no error checking as there is no time to check the receiver is getting data. This is fine in local connections like HDMI as, since it's local, there should be relatively few errors (compared with sending data over the internet for example). However, it won't be error free - that's impossible. So there needs to be some basic error correction going on to essentially "guess" what any data that hasn't come through is - this has to be guessed as errors cannot be resent when using UDP as there is no process to request this.

Mr Mellie:UDP is used for streaming media on the net for services like iPlayer. There is no error correction or resending of data with UDP.

No, TCP is used for streaming media over the internet, precisely because there has to be the ability to check for errors and get data resent when sending it over the internet. Try UDP streaming over the internet and you'll just get a mess of corrupt data. This is why you have a buffer build up when you start watching something through iPlayer over the internet - this gives enough data that has been sent through correctly to ensure the rest of the video can be played without interruption (as data needs to be requested and resent when it isn't received properly). Sometimes, it gets the size of this buffer wrong and it's too small, which is why video can start and stop when streaming over the internet as it has to stop and wait for enough correct data to be received before carrying on.

This article explains the process quite well.

Yes I meant like UDP, in that there is no recovery from missing packets rather than it is UDP.

Buffering is used for both UDP and TCP it is not exclusive to tcp.

I, will check on whether iplayer still uses it UDP - our firewalls block UDP on port 1948 amongst other things to block iplayer.

 

[Anonymous]

professorhat:Mr Mellie:
the_lhc:Yes but there is currently no way of using an HDMI cable to transfer data between two PCs, it's a display connection, you'd need to come up with an entirely new set of protocols to allow them to talk to each other.

Now whilst it may be beyond you and me in terms of time and money, hdmi output and capture is available on PCs via graphics cards. Google will help here. So I still do not see a technical problem. Send data across the interface and capture it the other end.

Ahh, but then you'd have to circumvent the HDCP protection. Which is of course illegal.

Only if the source material is protected.

So we have a non subjective solution of sorts, play a non protected source over hdmi to a capture card say 10 times.

Save the captured data to disk under different file names and compare the 10 captured files.

If there are differences then the corruption is random.

If there are no differences then there are 2 options, there is no corruption of the stream over the cable or the corruption is consistent. I do not believe the corruption can be non random myself so in my opinion the cable is not introducing errors in this case.

 

[professorhat]

Mr Mellie:I, will check on whether iplayer still uses it UDP - our firewalls block UDP on port 1948 amongst other things to block iplayer.

Yes, I believe UDP traffic is used in the initial establishment of a connection on iPlayer (so blocking that port prevents it), but there's no way the actual streaming process uses UDP for the reasons mentioned above.

 

[professorhat]

Mr Mellie:professorhat:Mr Mellie:
the_lhc:Yes but there is currently no way of using an HDMI cable to transfer data between two PCs, it's a display connection, you'd need to come up with an entirely new set of protocols to allow them to talk to each other.

Now whilst it may be beyond you and me in terms of time and money, hdmi output and capture is available on PCs via graphics cards. Google will help here. So I still do not see a technical problem. Send data across the interface and capture it the other end.

Ahh, but then you'd have to circumvent the HDCP protection. Which is of course illegal.

Only if the source material is protected.

So we have a non subjective solution of sorts, play a non protected source over hdmi to a capture card say 10 times.

Save the captured data to disk under different file names and compare the 10 captured files.

If there are differences then the corruption is random.

If there are no differences then there are 2 options, there is no corruption of the stream over the cable or the corruption is consistent. I do not believe the corruption can be non random myself so in my opinion the cable is not introducing errors in this case.

Okay, that might prove something, however, you'd need to ensure the material being sent was 1080p with HD audio soundtrack to ensure the sort of bandwidth requirements normally required within a Blu-Ray being played were being tested.