HDMI over tcpip (not a booster)

[Stonent]

What I'm looking for is something where you could plug either a smart TV into an ethernet jack OR a device that plugs into the HDMI port on a TV and makes it sort of an IP based monitor.
We have a lot of displays where I work.  They are either driven off of analog coax via a CCTV system, or they have some kind of HDMI to CAT5 to HDMI device that uses a dead ethernet cable (with no networking hardware) to get the video from point A to point B.

I'm wanting to do away with all of that and have some kind of system where the TV just plugs into an ethernet connection on the company network and we somehow pair it to a computer elsewhere that supplies the display.

Pretty much everything I find is just things from Extron or BlackBox that do basically what we already have, just run video over dead CAT5 cable.

Has anyone used anything like this?

[NiHaoMike]

http://hackaday.com/2014/01/25/reverse-engineering-an-hdmi-extender/
Or use a Raspberry Pi or similar programmed as a stream player or remote X server.

[Someone]

Apple TV:
https://support.apple.com/kb/PH14375

[Richard Crowley]

So, if you want to transmit video over the normal switched network, then you need to STREAM it. That turns it into packets of data that travel along with the rest of the network data packets. There are dozens of ways to input, compress, and send conventional data packets that happen to be a live video stream.  And then you receive the video stream at the other end with a computer. Perhaps nothing more than a RasPi, etc.

[Kjelt]

There are HDMI over ethernet extenders for sale.
They transport the HDMI signal over two CAT5/6 cables max. 100 metres and back to HDMI.

Problem is the bandwidth. Modern high res signals are already around 10Gbps, the new 4k HDR signals are even close to 18Gbps.
So these extenders are usually only for standard video upto 1080i.

[Galenbo]

There are HDMI over ethernet extenders for sale.
They transport the HDMI signal over two CAT5/6 cables max. 100 metres and back to HDMI.

That makes those CAT cables dedicated to that propriety extender/converter system, and not integratable into network, like the guy asked.

... sort of an IP based monitor.

I looked for the same thing in 2010, and the only relyable system was, like mentioned above, attaching a computer to each screen.
Solutions are Rpi, NUC, Thinclients, MediaplayerPC, VesaBoxPc...

I had some bad expierience with streaming also, the reasons were problems with subtitles, unrecognised sub-MKV and VOB formats... and internet tells me I'm not alone. The new "solution" to a previously unexisting problem was called "server transscripting" but I lost a complete day there with... new problems and exceptions.

So my new requirement was: A system that plays video + has real network access.
To not loose too much time again, I disregarded DLNA and XBMC etc, and went for a normal PC with normal Windows and normal VLC.
I'm sure those cisco guys will choose another solution here.

Now, 5 years later, I would maybe choose Rpi or NUC instead of a uATX.

I understand the difference between our situations, if you have much screens etc.
Maybe run Linux with a self starting script on it?

Can you give a very tight description of the video formats you want to stream?
Or do you want to show also PDF's or presentations?
Does every screen display the same thing at the same time?
Do you want to allow user control at the position a such monitor or is everything organised strictly centralised?

A thing to think about also is the number of sceens, and the expected bandwidth.
Many Pc's wanting to get videos over the network will give much more load than those PC's subscribing to a broadcast stream.

[Xenon Photon]

Chromecast?!
https://www.google.com/intl/en_us/chromecast/?utm_source=chromecast.com

[jc101]

What I'm looking for is something where you could plug either a smart TV into an ethernet jack OR a device that plugs into the HDMI port on a TV and makes it sort of an IP based monitor.
We have a lot of displays where I work.  They are either driven off of analog coax via a CCTV system, or they have some kind of HDMI to CAT5 to HDMI device that uses a dead ethernet cable (with no networking hardware) to get the video from point A to point B.

I'm wanting to do away with all of that and have some kind of system where the TV just plugs into an ethernet connection on the company network and we somehow pair it to a computer elsewhere that supplies the display.

Pretty much everything I find is just things from Extron or BlackBox that do basically what we already have, just run video over dead CAT5 cable.

Has anyone used anything like this?

If you have the coax already, consider ZeeVee, they encode video into digital TV muxes and send it down the coax, as long as the TV at the end has a DTV decoder you can watch any "channel" you like.  As the transmission path is coax, you can boost and split to your hearts content.  Quite nice kit actually.

[Marco]

Raspberry Pi's with RDP are probably your best bet for low cost with reasonable build quality.

[Halcyon]

There are HDMI over ethernet extenders for sale.
They transport the HDMI signal over two CAT5/6 cables max. 100 metres and back to HDMI.

Problem is the bandwidth. Modern high res signals are already around 10Gbps, the new 4k HDR signals are even close to 18Gbps.
So these extenders are usually only for standard video upto 1080i.

I think you mean Mbps, not Gbps. Even HD-SDI (used in professional video applications) uses a data rate of around 1.5Gbps for transferring relatively uncompressed video. Even the current 3G-SDI is just under 3Gbps. You're probably referring to the maximum data rate of a particular HDMI standard. You'll find the actual signal is much much less.


But as Kjelt already mentioned, you can buy "HDMI over Cat 6" devices. It doesn't actually change the signal at all, it just a media converter essentially. They even sell them at office supply stores in Australia: http://www.officeworks.com.au/shop/officeworks/p/comsol-hdmi-extender-over-dual-cat-5-cat-6-cables-up-to-30m-cohdc545

You could also look at something like this: http://justaddpower.com/index.html but you're getting into specialised territory and it's not going to be cheap. Consumer displays aren't designed to connect to some kind of central video server. If it's for home (or even business) applications, keep it simple. Less things to go wrong, less maintenance, less cost for the same end result.

[andtfoot]

There are commercial solutions for streaming video (depending how much money you feel like spending). Look up IPTV systems.
Exterity and Haivision are a couple off the top of my head. They are generally systems that have a management server controlling (but can often run standalone, depending on equipment selection).
Otherwise, you can get individual encoders and decoders...
http://www.extron.com/product/product.aspx?id=sme100&s=4
http://www.extron.com/product/product.aspx?id=smd101&subtype=481&s=3
http://www.krameraustralia.com.au/products/model.asp?pid=2611&sf=537&pname=KDS-EN2T
http://www.krameraustralia.com.au/products/model.asp?pid=2612&sf=537&pname=KDS-EN2R
http://www.krameraustralia.com.au/products/model.asp?pid=2529&sf=536&pname=KDS-EN1
http://www.krameraustralia.com.au/products/model.asp?pid=2984&sf=536&pname=KDS-DEC3
http://svsiav.com/video-over-ip-products/

I don't have experience with these specific products, but I have some familiarity with the Exterity and Haivision stuff.

[Stigaard]

It sounds a lot like the problem airtame tried to solve https://airtame.com/ it is however based on wifi, I have do idea on how they perform with a bunch hanging off the same access point, the idea is nice though.

[Rasz]

more down to earth, but still somewhat expensive, hackish and work in progress:

http://hdmi2usb.tv
https://www.crowdsupply.com/numato-lab/opsis


Pee currently cant capture hdmi, but "6of9" (Ex-Broadcom engineer) wrote open MIPI CSI driver for Pee (https://www.raspberrypi.org/forums/viewtopic.php?t=109137 https://www.eevblog.com/forum/microcontrollers/displayport-with-fpga/msg760814/#msg760814), so it is possible to replace Pee fullhd camera with FPGA feeing captured HDMI feed into paspberypi, rPee has full hardware accelerated h264 encoder.

[Kjelt]

I think you mean Mbps, not Gbps. Even HD-SDI (used in professional video applications) uses a data rate of around 1.5Gbps for transferring relatively uncompressed video. Even the current 3G-SDI is just under 3Gbps. You're probably referring to the maximum data rate of a particular HDMI standard. You'll find the actual signal is much much less.

I do mean Gbps and unfortunately my one year old receiver has the 10,2Gbps HDMI chipset and this will not work with the new 4k ultra bluray players that will be released end of the year that will require the new 18Gbps HDMI chipsets which indeed is the limit it can handle but still the normal video and audiosignals transferred will be >10Gbps otherwise I would not have this problem  .
But I am as curious as others to see if this will still work with the standard HDMI connector and cables as the HDMI consortium so wisely have decided  .

[Halcyon]

I think you mean Mbps, not Gbps. Even HD-SDI (used in professional video applications) uses a data rate of around 1.5Gbps for transferring relatively uncompressed video. Even the current 3G-SDI is just under 3Gbps. You're probably referring to the maximum data rate of a particular HDMI standard. You'll find the actual signal is much much less.

I do mean Gbps and unfortunately my one year old receiver has the 10,2Gbps HDMI chipset and this will not work with the new 4k ultra bluray players that will be released end of the year that will require the new 18Gbps HDMI chipsets which indeed is the limit it can handle but still the normal video and audiosignals transferred will be >10Gbps otherwise I would not have this problem  .

I don't know the technical details about the HDMI signalling itself but 10Gbps for an audio/video signal I find very hard to believe, it would be SUCH a waste and just pissing away bandwidth. It's a bit like re-encoding your MKV movies into AVI format. They simply don't do it that way. The moment you start using longer runs of HDMI cabling (such as through in-wall installs etc...) you're compromising signal integrity in a big way. Could you imagine if whoever comes up with the codecs said told everyone "right, we're going to make our codecs super hungry and you'll need at least 10Gbps bandwidth, oh and by the way, you can't be more than 2 metres from your source", HDMI would die a very quick death.

Compared to the bitrate of other AV streams; take a normal 1080i television signal, it has a variable bitrate and usually hovers around the 3-4Mbps mark, depending on what you're watching, Blu Ray codecs max out at 48Mbps and even the AVID DNxHD codec 10-bit signal @ 4096x2160 resolution is ~3.7Gbps (and that's considered by many to be near enough to lossless).

HDMI is designed to be backwards compatible, even when talking about 2.0 v 1.x standards so I suspect what's happening is your source is not capable of outputting a signal in the older standard, which is poor design in my opinion. If the roles were reversed however (your receiver was 2.0 capable but your source wasn't), your receiver will automatically switch to the earlier standard. Your issue isn't bandwidth, but more to do with HDMI revisions and what devices supports what. So saying your "10.2Gbps chipset" is no longer capable of playing your "18Gbps source" is not really correct, from a bandwidth point of view it's more than capable. It's just there is a revision mismatch and the source isn't capable of negotiating and rectifying it.

I've found that most decent players will down convert from whatever is on the disc to just about anything you need it to. For example, I have one of the earlier Samsung Blu-ray players which will happily let me select anything from 1080P down to 480P and switch between audio codecs.

To get around that, simply use the digital audio out into your receiver rather than HDMI, but then your player has to be capable of outputting an audio codec that the receiver can understand.

[Someone]

I think you mean Mbps, not Gbps. Even HD-SDI (used in professional video applications) uses a data rate of around 1.5Gbps for transferring relatively uncompressed video. Even the current 3G-SDI is just under 3Gbps. You're probably referring to the maximum data rate of a particular HDMI standard. You'll find the actual signal is much much less.

I do mean Gbps and unfortunately my one year old receiver has the 10,2Gbps HDMI chipset and this will not work with the new 4k ultra bluray players that will be released end of the year that will require the new 18Gbps HDMI chipsets which indeed is the limit it can handle but still the normal video and audiosignals transferred will be >10Gbps otherwise I would not have this problem  .

I don't know the technical details about the HDMI signalling itself but 10Gbps for an audio/video signal I find very hard to believe, it would be SUCH a waste and just pissing away bandwidth. It's a bit like re-encoding your MKV movies into AVI format. They simply don't do it that way. The moment you start using longer runs of HDMI cabling (such as through in-wall installs etc...) you're compromising signal integrity in a big way. Could you imagine if whoever comes up with the codecs said told everyone "right, we're going to make our codecs super hungry and you'll need at least 10Gbps bandwidth, oh and by the way, you can't be more than 2 metres from your source", HDMI would die a very quick death.

Compared to the bitrate of other AV streams; take a normal 1080i television signal, it has a variable bitrate and usually hovers around the 3-4Mbps mark, depending on what you're watching, Blu Ray codecs max out at 48Mbps and even the AVID DNxHD codec 10-bit signal @ 4096x2160 resolution is ~3.7Gbps (and that's considered by many to be near enough to lossless).

1080i uncompressed video is HD-SDI, 1.485Gbits/s. A DVB-T mux at 1080i might be 10-20Mbits/s but thats compressed as MPEG.

DVI, HDMI, Display Port, etc are all uncompressed transports like SDI, but unlike SDI they arent capable of being run long distances.

I run HDMI in 4K and UHD resolutions all the time, the cables are critical and you get a poor enough bit error rate that its often visually distracting even with 25 or 30Hz field rate, 60Hz is a way off being reliable yet.

[ConKbot]

I think you mean Mbps, not Gbps. Even HD-SDI (used in professional video applications) uses a data rate of around 1.5Gbps for transferring relatively uncompressed video. Even the current 3G-SDI is just under 3Gbps. You're probably referring to the maximum data rate of a particular HDMI standard. You'll find the actual signal is much much less.

I do mean Gbps and unfortunately my one year old receiver has the 10,2Gbps HDMI chipset and this will not work with the new 4k ultra bluray players that will be released end of the year that will require the new 18Gbps HDMI chipsets which indeed is the limit it can handle but still the normal video and audiosignals transferred will be >10Gbps otherwise I would not have this problem  .

I don't know the technical details about the HDMI signalling itself but 10Gbps for an audio/video signal I find very hard to believe, it would be SUCH a waste and just pissing away bandwidth. It's a bit like re-encoding your MKV movies into AVI format. They simply don't do it that way. The moment you start using longer runs of HDMI cabling (such as through in-wall installs etc...) you're compromising signal integrity in a big way. Could you imagine if whoever comes up with the codecs said told everyone "right, we're going to make our codecs super hungry and you'll need at least 10Gbps bandwidth, oh and by the way, you can't be more than 2 metres from your source", HDMI would die a very quick death.

Compared to the bitrate of other AV streams; take a normal 1080i television signal, it has a variable bitrate and usually hovers around the 3-4Mbps mark, depending on what you're watching, Blu Ray codecs max out at 48Mbps and even the AVID DNxHD codec 10-bit signal @ 4096x2160 resolution is ~3.7Gbps (and that's considered by many to be near enough to lossless).

HDMI is designed to be backwards compatible, even when talking about 2.0 v 1.x standards so I suspect what's happening is your source is not capable of outputting a signal in the older standard, which is poor design in my opinion. If the roles were reversed however (your receiver was 2.0 capable but your source wasn't), your receiver will automatically switch to the earlier standard. Your issue isn't bandwidth, but more to do with HDMI revisions and what devices supports what. So saying your "10.2Gbps chipset" is no longer capable of playing your "18Gbps source" is not really correct, from a bandwidth point of view it's more than capable. It's just there is a revision mismatch and the source isn't capable of negotiating and rectifying it.

I've found that most decent players will down convert from whatever is on the disc to just about anything you need it to. For example, I have one of the earlier Samsung Blu-ray players which will happily let me select anything from 1080P down to 480P and switch between audio codecs.

To get around that, simply use the digital audio out into your receiver rather than HDMI, but then your player has to be capable of outputting an audio codec that the receiver can understand.

Well thats an odd thing to get all worked up over..
HD-SDI uses 20 bits per pixel (4:2:2 YCbCr color space), and 1080i, '60' fps is 1920x540x60 pixels per second, or 1.15 Gbps + timing, sound, encoding overhead and other faff, and you get your 1.485 Gbps that SMPTE-292M uses. 

DVI single link (1920x1200 @ 60 FPS), 8 bits per color per pixel, 8b10b encoding, so 30 bits pixel, or 3.86 Gbps for video data + your pixel clock (~0.128 Gbps) making for a touch under 4 Gbps.

Displayport 1.2 (since DP has more specs available online about the actual format itself) supports 3840x 2160 @ 60fps, 24bpp 8b10b encoding, for over 14 Gbps.


Yes sending boring old 1080p @ 30fps wont take anywhere near all of that, but its still uncompressed HD, and the color space doesnt have to be downsampled like HDSDI, which makes it even more hungry.

[Kjelt]

I don't know the technical details about the HDMI signalling itself but 10Gbps for an audio/video signal I find very hard to believe, it would be SUCH a waste and just pissing away bandwidth. It's a bit like re-encoding your MKV movies into AVI format. They simply don't do it that way.

Unfortunately the video is uncompressed, that is also the reason that any glitch can directly be seen.
Why I do not know, they also encrypt it,  so I can only imagine that they do this so you don't have to buy a new tv/projector for any new compression that comes out, but that is a guess.
Anyway that is the current state of affairs for HDMI at the moment.

So to calculate the new 2160p@60fps with HDR (new in the 2.0 spec bringing 12 bits instead of 8 bits per color per pixel):

Ultra-high-definition television = 3840 × 2160 1.78:1 (16:9) = 8294400 pixels * 3 (RGB) * 12 (bpp for HDR) * 60fps = 17915904000 = 17,9 Gbps
then we also have tens of channels of soundtracks and other stuff which I will skip for the calculation.

Downconverting is ofcourse always an option but if you spent many k$ on a 4k projector/tv I do no think you want that 

[Halcyon]

So why on earth does anyone use HDMI (except for the reason that it's included in almost all consumer products). SDI is clearly a far better solution. Reminds me of the VHS v Betamax or HD-DVD v Blu Ray wars. The better technology is pushed to the sidelines merely because of popularity and marketing.

[Richard Crowley]

So why on earth does anyone use HDMI (except for the reason that it's included in almost all consumer products). SDI is clearly a far better solution. Reminds me of the VHS v Betamax or HD-DVD v Blu Ray wars. The better technology is pushed to the sidelines merely because of popularity and marketing.

I suspect that HDMI is more popular for consumer goods because it "splits up" the data into four parallel streams which are each 1/4 the total bandwidth. And that lower speed makes it less expensive to implement.  SDI is pretty much seen on professional gear, and almost never on consumer goods. 
It seems easy enough to convert HDMI <-> SDI. You can find dozens of inexpensive conversion products even on Amazon and Ebay. For distances longer than 2-3m, it is more reliable (and probably less expensive) to convert HDMI to SDI and then back again at the other end.  That is certainly my working practice.

[Kjelt]

Some questions can not be answered but probably have a marketing/sales point of origin.
Just as the question why they ever multiplexed the clock and data signal for digital audio into an inferior jitter prone SPDIF solution.
The answer is probably because they could save one lousy connector 

[Richard Crowley]

Some questions can not be answered but probably have a marketing/sales point of origin.
Just as the question why they ever multiplexed the clock and data signal for digital audio into an inferior jitter prone SPDIF solution.
The answer is probably because they could save one lousy connector 

The SPDIF "jitter problem" has never held any water with me.  It seems like it might have been a very early problem with SOME dodgy, first-generation gear, but it has taken on an "audiophool" life of its own.  The notion that any gear would directly use the transmission self-clock just seems completely preposterous to me.

[BradC]

I just installed a set of HDMI over ethernet extenders at my folks place. One transmitter to 3 receivers. Just hook each unit up to a gigabit switch and they work on broadcast. Don't really want to share the network with anything else, but it does work and it is possible.

http://www.altronics.com.au/p/a3140-hdmi-over-ethernet-balun-extension-transmitter/
http://www.altronics.com.au/p/a3141-hdmi-over-ethernet-balun-extension-receiver/

I know it *says* "balun", but it's not. It's a network packet stream. Each device has its IP and MAC address and away it goes.
It was much cheaper than a 3 way HDMI splitter and 3 pairs of extenders, and it works a treat.
The receivers all come default with the same IP and MAC, so you need to change both to get them to co-exist on the network.

[Rasz]

there is also HDCVI - fullhd over coax @500m, mostly in chinese security cameras

http://www.altronics.com.au/p/a3140-hdmi-over-ethernet-balun-extension-transmitter/
http://www.altronics.com.au/p/a3141-hdmi-over-ethernet-balun-extension-receiver/

you "slightly" overpaid
http://www.ebay.com/itm/330ft-100M-HDMI-Extender-Over-TCP-IP-Convert-Ethernet-Lan-Only-Receiver-IR-/311384903083

this product is the exact same thing reverse engineered by Daniel and covered on hackaday: http://hackaday.com/2014/01/25/reverse-engineering-an-hdmi-extender/

[Kjelt]

The SPDIF "jitter problem" has never held any water with me.  It seems like it might have been a very early problem with SOME dodgy, first-generation gear, but it has taken on an "audiophool" life of its own.  The notion that any gear would directly use the transmission self-clock just seems completely preposterous to me.

That was how it was intended to work, use the clock in the spdif signal itself to clock the dac.
Then (due to the jitter discussion) all kinds of solutions came with extra one stage even two stage re-buffering and reclocking with picosecond clock audiophool blabla.
But hey even in this forum we use 10MHz picosecond atom clocks to sync our gear