HDMI to IPTV converter

Johnboy1951 · 02-06-2017 12:24PM

I wanted to introduce this 'new channel' into my TV & media server set up, but at this time I do not know how to do this in my tvheadend backend.

So for the moment I added my new channel into Kodi on the clients using IPTV. Not at all ideal, but somewhat functional. At least it allowed me to watch live, the Irish team get beaten last night by Mexico.

Kodi would not properly display the stream until I caused the odd udp packages to be dropped. These are all reported as zero length packages, but are possibly related to the Tx & Rx set up or such. So, as root in a terminal I did

iptables -t raw -A PREROUTING -p udp -m length --length 28 -j DROP

Kodi plays the stream fine after that. I should set that up in a config file to be run on startup so it is always present.

#######

The most obvious problems at present:

The display resolution is incorrect. I expect 1920x1080 which is what the source is set to.
What I get at the client I tested with is 1728x1080
I can watch it, but know it is not correct.
Some firmware change will be needed to get at the settings I think.

The time for a remote control button press at source, to appear at client can be up to 5 secs!
I have no idea what the cause might be, but again it does not interfere with my viewing as I will set the box to one channel for an hour or two of viewing.

I think the transmitter might be susceptible to getting too hot, so its placement needs to be considered .... not on top of some other box that is warm/heating. Placing it on an old serving tray has kept it remarkably cool .... the heat being dispersed through its base to the tray.

***

I worry about downgrading the firmware but will probably have to do so to get better access to the settings. This has to be investigated yet. I don't want to brick the device at this early stage

With access to the settings I expect to be able to change the device from multicast to unicast which just might alleviate some of the problems mentioned, such as delay to button press.
It should also make it easier to manage the LAN.

At present the output is UDP only, but other options are possible i believe, such as RTP and maybe HTTP. Access to settings is vital to find out for definite.

Resolution and bitrate are other settings that might become available.

The nature of blogs, such as DanMan's, is that the information is not structured ..... bits added here and there. All info is present, but it can be difficult to extract the info that is pertinent to one particular version of the device.
It would be nice to see everything in one clear and concise article

emaherx · 02-06-2017 02:27PM

Johnboy1951 wrote: »

OK, I could not wait

I had also bought an iSolem 1 > 2 HDMI converter which strips out the DHCP/DRM, so I )

I also purchased the iSolem 1 > 2 HDMI converter and it arrived today, but still waiting on the HDMI to IPTV device

Johnboy1951 wrote: »

The nature of blogs, such as DanMan's, is that the information is not structured ..... bits added here and there. All info is present, but it can be difficult to extract the info that is pertinent to one particular version of the device.
It would be nice to see everything in one clear and concise article

You have have a week or two to write one for me!

Johnboy1951 · 02-06-2017 04:03PM

emaherx wrote: »

I also purchased the iSolem 1 > 2 HDMI converter and it arrived today, but still waiting on the HDMI to IPTV device

You have have a week or two to write one for me!

I am hoping that some braver soul than I will do it first as the only way to write it up is to do it first

I am afraid of bricking it, TBH!

Mine was actually a couple of days late arriving, but the response from the seller was excellent.
What threw me was the tracking status had not been updated .... I had received it before the update appeared I think.

For the moment it is working. so I will get the benefit from it for a while before I take any chances

Johnboy1951 · 02-06-2017 09:37PM

Tried re-configuring my LAN and got into all sorts of bother with the multicast interfering

I will definitely be looking at changing that to unicast to save me some headaches

Johnboy1951 · 05-06-2017 09:00AM

Johnboy1951 wrote: »

This the device type you mean?
http://www.freetv.ie/hdmi-modulator/

Nelbert wrote: »

Yep, there is a triax version for around £120 on Amazon from memory.
A bit of a long way round but end result is the same.
It's my long term plan as regards tv distribution in the house.

Ones on eBay that take two HDMI inputs.... satlink brand which I've to do so research on before deciding on.

I didn't find a Triax model but did find this Technomate £120
https://www.amazon.co.uk/Technomate-TM-RF-HD-Modulator-2017/dp/B07284V3RH/ref=sr_1_fkmr2_3?ie=UTF8&qid=1496663888&sr=8-3-fkmr2&keywords=Triax+HDMI+to+DVB-t

Do you have any update on what you decided to buy?

Wondering how it worked out for you.

Johnboy1951 · 06-06-2017 05:25PM

Regarding the strange resolution I get on the output, it appears that something in the stream is 'converting' the video from AR of 16:9 to AR of 16:10 by reducing the 1920 to 1728.

Strange!

As an aside I have had a small improvement to my fiscal situation so will try this unit for a permanent install, leaving me free to play with the HDMI>IPTV device without fear of borking it and leaving me without anything.
http://www.freetv.ie/hdmi-modulator/
About €165 with 'boards' discount.

Tvheadend tuners should pick it up with ease and add it to the available channels for the Kodi frontends in the client devices.
It is a costly way to manage things, but as the eir sports is free to eir customers I can persuade myself it is worth it

I have so far failed in my attempt to control the multicast messages and broadcast from the present device.
Whether this is due to the extra packages being transmitted in the stream or my own failure to set it up correctly I have not as yet determined.

Johnboy1951 · 07-06-2017 09:35PM

http://www.freetv.ie/hdmi-modulator/
Unit received and set up today.

Had trouble trying to figure out the simplest bit ...... how to add the channel to tvheadend

After that everything worked very well.
The Edision channel is available at all client devices in 1080

Only problem remaining is the very high bitrate of the channel, which I have to look into.

emaherx · 08-06-2017 07:58AM

My HDMI to IPTV device arrived, much quicker than I expected too.

Had a bit of a play with it, flashed it with the firmware recommended in Danman's Blog and it gives access to more settings such as resolution and IP address.

Multicast options don't seem to be of much use through the GUI.

Taken from Danman's Blog:

But to set your unicast destination you need to use following URL:
"http://DEV_IP/dev/info.cgi?action=streaminfo&rtp=on&multicast=on&mcastaddr=DST_IP"
e.g.:
"http://192.168.0.87/dev/info.cgi?action=streaminfo&rtp=on&multicast=on&mcastaddr=192.168.0.227"

Seems to be working well but its not really an ideal solution.
With Multicast on it floods every port with traffic non stop (as you would expect but not something I want on my home network)
For Unicast to work you need to specify a destination address so only one client device will work and it will be bombarded nonstop with traffic (also not that surprising, but still not ideal for my home network)

I think the ideal use for this is probably with the transmitter and multiple receiver devices connected to a dedicated switch or at least vlan on a managed switch.

Vlan or dedicated switch is not going to be workable as I don't have enough cabling at all TV's and I'm not going to buy a receiver for each TV either.

I have some Cisco switches lying around and I could disable multicast on all ports, but the few that might want to connect to the stream, again this is far from ideal as all potential client devices will constantly have busy ports and the Cisco device will consume far more electricity than my current switch and be noisy also.

Probably the best solution, mentioned in some of the comments in Danman's Blog is to connect directly to a Proxy device, possibly a raspberry PI with a second USB ethernet controller and have it convert the stream to RTSP.

Johnboy1951 · 08-06-2017 10:26AM

Wow! That was fast! ..... and you got it flashed very quickly too

I fed its output through two different switches with IGMP snooping active.
In neither case did that prevent the hammering of all connected devices with some form of (apparently) multicast) data.
I failed miserably to control the multicast data even in the managed switch.

Can you please give me the exact firmware you used as I got really confused about which I should use.
I will flash it when I am sure.

What resolution are you getting at the output?
Is it 1920x1080 or 1728x1080?

Thinking about the unicast problem I wonder if a second NIC in the tvheadend backend machine would be a solution?
A dedicated NIC for incoming and the outgoing data served on the existing NIC? Its unicast output set to that NIC might work.

Thanks for the report ....... hopefully I won't need Windows to do any of this.

emaherx · 08-06-2017 12:10PM

Johnboy1951 wrote: »

Wow! That was fast! ..... and you got it flashed very quickly too

Well at that price I had no issue with bricking it. Was pretty sure for a few min that I had too...... But DHCP gave it a new address when the firmware was applied.

Johnboy1951 wrote: »

Can you please give me the exact firmware you used as I got really confused about which I should use.
I will flash it when I am sure.

What resolution are you getting at the output?
Is it 1920x1080 or 1728x1080?

Firmware Version :4.0.0.0.20160427
Encoder Version :7.1.2.0.11.20160407

Resolution is still not perfect, but much better.

Johnboy1951 wrote: »

Thinking about the unicast problem I wonder if a second NIC in the tvheadend backend machine would be a solution?
A dedicated NIC for incoming and the outgoing data served on the existing NIC? Its unicast output set to that NIC might work.

Thanks for the report ....... hopefully I won't need Windows to do any of this.

That is exactly what I went looking at after my last post. I'm hoping that a Raspberry Pi 3 will be able to run the backend server as well as Kodi to avoid adding any extra hardware to the network (except a USB Ethernet adapter that is). I dont currently have a TVHeadend machine since I replced the big old noisy PC with a Vbox.

You won't need Windows but you do need to factory reset the device after loading new firmware to reset password,there is a handy Windows program for that, but also some CLI options to do it too.

Johnboy1951 · 08-06-2017 01:05PM

Your resolution is perfect ....... it is the Display resolution that matters which is 1920x1080

Firmware Version :4.0.0.0.20160427
Encoder Version :7.1.2.0.11.20160407

My original firmware is

Version :4.0.0.0.20161031
Encoder Version :7.1.2.0.11.20161031

What I wanted to know what what file/s you used from Danman.
Did you flash two files or one?

I am totally confused about this, sorry top be a pain.

Is it these two files?

IPTV_TX_PKG_v4_0_0_0_20160427.PKG
Encoder_20160407_0942.bin

emaherx · 08-06-2017 01:33PM

Yes both of those files, they are the exact same filenames I used.
I did the Firmware first... (then no encoder was showing as installed in Command Centre)
Then I did the encoder and all was good again.

I did use the Windows Command Centre Application to update the firmware, but you shouldn't need it if you don't have Windows.

Johnboy1951 · 08-06-2017 01:54PM

emaherx wrote: »

Yes both of those files, they are the exact same filenames I used.
I did the Firmware first... (then no encoder was showing as installed in Command Centre)
Then I did the encoder and all was good again.

I did use the Windows Command Centre Application to update the firmware, but you shouldn't need it if you don't have Windows.

Thanks.
I had previously downloaded

IPTV_TX_PKG_v4_0_0_0_20160427.PKG

so I have that one, but I cannot seem to locate this file

Encoder_20160407_0942.bin

Have you any link that I could use to download it?

Thanks.

I see there is a new Zip file on the google drive but have no idea if any of those files are to be used
TX firmware-20170608T123154Z-001.zip

I seem to delight in confusion

emaherx · 08-06-2017 01:58PM

https://drive.google.com/drive/u/0/folders/0B3mWuDyxrXyKM0tpa3RGNHRtWW8

Johnboy1951 · 08-06-2017 02:11PM

emaherx wrote: »

https://drive.google.com/drive/u/0/folders/0B3mWuDyxrXyKM0tpa3RGNHRtWW8

Getting blind in my old age it seems

Thanks

Johnboy1951 · 08-06-2017 02:38PM

OK, for anyone using Linux only I followed the following scheme

Brought up the web page in Chrome
Chose to update firmware.PKG and selected the file.
All good but I got no opportunity to also update the encoder.
It required a reboot but I did not want to just pull power .....

so in a terminal I did

nc 192.168.1.XXX 9999 <the IP address of the device>

and entered
reboot

When it rebooted and I again got in via the terminal I issued

factory_reset

and when it rebooted I was able to log in with

admin
123456

I then chose to upgrade the Encoder (last option on page) and the reboot prompt came up - OK.
I got a wee bit of a scare as it took ages for the log in page to come up.

Thanks emaherx for the hand-holding.

I will see if I can make changes to its operation now.

Johnboy1951 · 08-06-2017 03:18PM

The good news is that I have Full HD and I can change the video bitrate if I wish.

More good news is that I can disable multicast/select unicast and it keeps after a reboot. That eliminates the flooding of the LAN.

The bad news is that I cannot seem to specify anything for unicast so cannot access the stream.

###

It seems that a single IP can be specified for the multicast address from the command line.
This seems to be a sort of bodge .... ?

First group is the multicast and the second group comes after the curl command to change the address.
It seems it only sends the stream to the single IP address - in this case 'Beigebox.local'.

16:53:52.193683 IP 192.168.1.102.5004 > 239.255.42.42.5004: UDP, length 1316
16:53:52.193912 IP 192.168.1.102.5004 > 239.255.42.42.5004: UDP, length 1316
16:53:52.194142 IP 192.168.1.102.5004 > 239.255.42.42.5004: UDP, length 1316
16:53:52.194447 IP 192.168.1.102.5004 > 239.255.42.42.5004: UDP, length 1316

528 packets captured
24451 packets received by filter
22257 packets dropped by kernel
[root@Beigebox user]# exit
[user@Beigebox user]$ curl "http://192.168.1.102/dev/info.cgi?action=streaminfo&udp=n&rtp=y&multicast=n&unicast=y&mcastaddr=192.168.1.101&port=5004"
<html><head><meta http-equiv="pragma" content="no-cache"/><meta http-equiv="expires" content="0"/><meta http-equiv="refresh" content="0; URL=/dev/info.html"/></head></html>[user@Beigebox user]$ su
[root@Beigebox user]# tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:55:03.269003 IP 192.168.1.102.5004 > Beigebox.local.5004: UDP, length 1316
16:55:03.269368 IP 192.168.1.102.5004 > Beigebox.local.5004: UDP, length 1316
16:55:03.269715 IP 192.168.1.102.5004 > Beigebox.local.5004: UDP, length 1316
16:55:03.270880 IP 192.168.1.102.5004 > Beigebox.local.5004: UDP, length 1316

Unfortunately I have been unable to grab the RTP stream ...... according to VLC and others it does not have all the required data in it.

emaherx · 08-06-2017 06:51PM

Johnboy1951 wrote: »
The good news is that I have Full HD and I can change the video bitrate if I wish.

More good news is that I can disable multicast/select unicast and it keeps after a reboot. That eliminates the flooding of the LAN.

The bad news is that I cannot seem to specify anything for unicast so cannot access the stream.

###

It seems that a single IP can be specified for the multicast address from the command line.
This seems to be a sort of bodge .... ?

First group is the multicast and the second group comes after the curl command to change the address.
It seems it only sends the stream to the single IP address - in this case 'Beigebox.local'.
16:53:52.193683 IP 192.168.1.102.5004 > 239.255.42.42.5004: UDP, length 1316
16:53:52.193912 IP 192.168.1.102.5004 > 239.255.42.42.5004: UDP, length 1316
16:53:52.194142 IP 192.168.1.102.5004 > 239.255.42.42.5004: UDP, length 1316
16:53:52.194447 IP 192.168.1.102.5004 > 239.255.42.42.5004: UDP, length 1316

528 packets captured
24451 packets received by filter
22257 packets dropped by kernel
[root@Beigebox user]# exit
[user@Beigebox user]$ curl "http://192.168.1.102/dev/info.cgi?action=streaminfo&udp=n&rtp=y&multicast=n&unicast=y&mcastaddr=192.168.1.101&port=5004"
<html><head><meta http-equiv="pragma" content="no-cache"/><meta http-equiv="expires" content="0"/><meta http-equiv="refresh" content="0; URL=/dev/info.html"/></head></html>[user@Beigebox user]$ su
[root@Beigebox user]# tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:55:03.269003 IP 192.168.1.102.5004 > Beigebox.local.5004: UDP, length 1316
16:55:03.269368 IP 192.168.1.102.5004 > Beigebox.local.5004: UDP, length 1316
16:55:03.269715 IP 192.168.1.102.5004 > Beigebox.local.5004: UDP, length 1316
16:55:03.270880 IP 192.168.1.102.5004 > Beigebox.local.5004: UDP, length 1316
Unfortunately I have been unable to grab the RTP stream ...... according to VLC and others it does not have all the required data in it.

Yes, this is what I have at the moment its essentially a multicast to one IP address, this fixes one issue and creates a new one (can only work with one client and it will get hammered with traffic anyway). would rather go the TVHeadend method than use that.

But when Set to Unicast a new port opens 554 RTSP!!!!

root@zeroshell ~> nmap -v -A 192.168.x.x

Starting Nmap 6.47 ( http://nmap.org ) at 2017-06-08 18:44 IST
NSE: Loaded 118 scripts for scanning.
NSE: Script Pre-scanning.
Initiating ARP Ping Scan at 18:44
Scanning 192.168.x.x [1 port]
Completed ARP Ping Scan at 18:44, 0.00s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 18:44
Completed Parallel DNS resolution of 1 host. at 18:44, 0.00s elapsed
Initiating SYN Stealth Scan at 18:44
Scanning 192.168.x.x [1000 ports]
Discovered open port 80/tcp on 192.168.x.x
Discovered open port 554/tcp on 192.168.x.x
Discovered open port 8000/tcp on 192.168.x.x
Discovered open port 7002/tcp on 192.168.x.x
Discovered open port 9001/tcp on 192.168.x.x
Discovered open port 7000/tcp on 192.168.x.x
Discovered open port 9999/tcp on 192.168.x.x
Completed SYN Stealth Scan at 18:44, 0.22s elapsed (1000 total ports)

Stream should be some thing like rtsp://192.168.x.x:554/???/???

emaherx · 08-06-2017 06:53PM

Wonder if something like Camreadar could find the correct path?
Cameradar

Johnboy1951 · 08-06-2017 07:38PM

If you look at the tcpdump after the command I used above, it shows UDP and not RTP from the device.

This even though RTP is specified in the command.

Also that command apparently has no effect on the port numbers used, if my results here are anything to go by.

###

Checked the device here for open ports

$ nmap 192.168.1.102

Starting Nmap 7.40 ( https://nmap.org ) at 2017-06-08 19:52 IST
Nmap scan report for 192.168.1.102
Host is up (0.0049s latency).
Not shown: 995 closed ports
PORT     STATE SERVICE
80/tcp   open  http
7000/tcp open  afs3-fileserver
7002/tcp open  afs3-prserver
9001/tcp open  tor-orport
9999/tcp open  abyss

emaherx · 08-06-2017 07:56PM

Johnboy1951 wrote: »

If you look at the tcpdump after the command I used above, it shows UDP and not RTP from the device.

This even though RTP is specified in the command.

Also that command apparently has no effect on the port numbers used, if my results here are anything to go by.

not RTP but RTSP it is a TCP Protocol you won't see any traffic from it unless you actually manage to create a connection. RTP on the other hand is a UDP protocol and will spew out all it has to say whether or not any clients are trying to connect.

The default port for RTSP is 554 and it becomes open when you select Unicast on this device. It makes sense as this is the same protocol used with nearly all IP based CCTV systems and they don't flood the network with traffic and are not limited to one client connection.

Johnboy1951 · 08-06-2017 08:00PM

OK, I got the single IP stream to play.

EDIT:

No I didn't ....... mcast was enabled again whenever I tried

Johnboy1951 · 09-06-2017 03:05PM

emaherx wrote: »

not RTP but RTSP it is a TCP Protocol you won't see any traffic from it unless you actually manage to create a connection. RTP on the other hand is a UDP protocol and will spew out all it has to say whether or not any clients are trying to connect.

The default port for RTSP is 554 and it becomes open when you select Unicast on this device. It makes sense as this is the same protocol used with nearly all IP based CCTV systems and they don't flood the network with traffic and are not limited to one client connection.

From what I could determine, when I tried to enable unicast and specified the target IP, I was able to receive the stream there using UDP.

BUT, it appears that Multicast was not properly disabled ...... the multicast notifications were still going to the whole network causing some probs.

I would need to go back and look more closely in the future, as I got rather confused during that last session

emaherx · 09-06-2017 03:52PM

Johnboy1951 wrote: »

From what I could determine, when I tried to enable unicast and specified the target IP, I was able to receive the stream there using UDP.

BUT, it appears that Multicast was not properly disabled ...... the multicast notifications were still going to the whole network causing some probs.

I would need to go back and look more closely in the future, as I got rather confused during that last session

The methods of "unicast" discussed in Danman's Blog is not true unicast.

Johnboy1951 · 09-06-2017 04:12PM

emaherx wrote: »

The methods of "unicast" discussed in Danman's Blog is not true unicast.

I suppose a firmware change would be needed to achieve proper unicast

I have not seen any indication on how to achieve it so far.

Any ideas?

emaherx · 09-06-2017 05:24PM

Johnboy1951 wrote: »

I suppose a firmware change would be needed to achieve proper unicast

I have not seen any indication on how to achieve it so far.

Any ideas?

Set your device to unicast by unchecking multicast in the web GUI (don't run any other commands). Now rerun your nmap you will now see port 554 is open.

This is the proper rtsp port for unicast streams so it is likely that the firmware is fine. But you would need to know the correct URL to connect to it.

How you find it, I don't know. I've tried using CCTV software to auto detect or brute force find the URL but no luck yet.

Edit: I wonder if we had the rx device could we intercept the packets and see what the URL is?

Johnboy1951 · 09-06-2017 08:57PM

emaherx wrote: »

Set your device to unicast by unchecking multicast in the web GUI (don't run any other commands). Now rerun your nmap you will now see port 554 is open.

This is the proper rtsp port for unicast streams so it is likely that the firmware is fine. But you would need to know the correct URL to connect to it.

How you find it, I don't know. I've tried using CCTV software to auto detect or brute force find the URL but no luck yet.

Edit: I wonder if we had the rx device could we intercept the packets and see what the URL is?

I ran tcpdump after disabling multicast and noticed the following ...

20:45:36.412379 IP 192.168.1.102 > 239.255.42.196: igmp v2 report 239.255.42.196
20:45:36.412388 IP 192.168.1.102 > all-systems.mcast.net: igmp v2 report all-systems.mcast.net

192.168.1.102 is the device and I ran tcpdump on 192.168.1.101

emaherx · 09-06-2017 09:17PM

I got a unicast stream to play by using one of my Kodi R-Pi's as Proxy and a second Ethernet adapter connected by USB. So a unicast stream and no multicast traffic on network. If this works out it might just do.

I'm going to the pub now, but will give more detailed report of whats what before the weekend is out.

Johnboy1951 · 09-06-2017 09:42PM

emaherx wrote: »

I got a unicast stream to play by using one of my Kodi R-Pi's as Proxy and a second Ethernet adapter connected by USB. So a unicast stream and no multicast traffic on network. If this works out it might just do.

I'm going to the pub now, but will give more detailed report of whats what before the weekend is out.

Thanks.
I look forward to the details

emaherx · 10-06-2017 08:25AM

Johnboy1951 wrote: »

Thanks.
I look forward to the details

OK so its working but not without issue, there is occasional buffering at the client Devices. Not sure if its a Network limitation with my bodged together home network or if the Pi is just not up to the Job.

For my test I'm streaming the output of the same Raspberry Pi so it may be under a little pressure. Basically I'm streaming a HD channel from my TV server to the R-Pi the output of its HDMI is sent to the IPTV converter and back to eth1 of the R-Pi by multicast converted to unicast and back out through eth0.

Perhaps a NUC would be a better choice for this Job.

Anyway R-Pi is running Libreelec, took me ages to figure out how to install Udpxy as I couldn't compile it on the device due to the cut down nature of the OS. But it is actually on the Libreelec Repo as part of network-tools addon listed under programs. :rolleyes:

Statically set IP on IPTV converter to 192.168.10.20 (or whatever address not in your main subnet)

Connect USB Network Adapter to R-Pi
Install the network-tools addon from libreelec repo

ssh into the device
ifconfig eth1 192.168.10.10 netmask 255.255.255.0
route add -net 224.0.0.0 netmask 240.0.00 dev eth1
iptables -t raw -A PREROUTING -p udp -m length --length 28 -j DROP (thanks Johnboy1951)
cd /storage/.kodi/addons/virtual.network-tools/bin
cp udpxy /usr/bin/
udpxy -p 81

On client device.
http://192.168.x.x:81/udp/239.255.42.42:5004 (need to edit x.x for your udpxy server)
http://192.168.x.x:81/status (will show status of udpxy server)

I added 2 lines to my channellist.m3u file and the IPTV stream shows as a channel named HDMI on all of my Kodi device (they all link to the same file)
#EXTINF:-1, HDMI
http://192.168.x.x:81/udp/239.255.42.42:5004

HDMI to IPTV converter

Comments