TV entertainment
It all started when several PBI DCH-4000P-S42 tuners were brought to us.
According to the characteristics, this miracle of the Chinese industry is approaching professional tuners, but at an incomparably low price. It was originally intended to use these tuners to replace the zoo, which began with Openboxes and Globes and ended with Vantags, as well as for implementing DVB-C in HFC and some sort of DVB-S using Mitris. A cursory examination of the documentation showed that in addition to the initially (and not interesting) ASI, SDI, A / V, RGB, CVBS, XRL outputs required from it, it can also IP input or output with UDP / RTP (optional) and Multicast and Unicast on IP is already much more interesting and more profound, as it were. There is such an occupational disease - be sure to touch the handles with something where there is at least a hint of network capabilities.
')
The first thought was something like “Let's play IPTV, since it is almost inside”
Initial conditions
1. There is an old analogue KTV network covering about 90% of the entire city where DOCSIS 2.0 lives
2. There is an FTTB network covering about 95% of all multi-storey buildings in the city and in many places intersecting with the cable TV network
3. FTTB consists of switches, mainly Zyxel GS-4012F, Zyxel GS-3012F, Zyxel ES-2108, Foxgate S-6024-S2L2, S-6008-S2L2, Foxgate S-6208-S1, Foxgate S-6024-S4L2 and other zoo of the entire range of Foxgate.
4. All the above devices in the manuals indicated that they can both igmp snooping and multicast support.
5. The unpleasant fact of course was that 90% of all these pieces of hardware were 100Mbit / s copper subscribers, but for testing purposes all this suited completely (it was not planned to replace several hundreds of switches for “play”)
Black magic
The first thing that came to mind is to simply set up the tuner on some 6 open channels on any one transponder. And then bend, stated in the multicast manual and poke it all into the switch located in the core of the FTTB network. That without prolonged deliberation and was done with the test tuners available at hand. The first suspicions of the failure of such a venture crept in 40 seconds after the sudden flurry of calls. At a quick glance at the self-monitoring of switches, it turned out that when the receiver was plugged into the nuclear switch, about of the network fell off at about the same time. Strange, but nevertheless we repeat sticking of 1 receiver in a switch and on the panic that began almost immediately on support, we understand that the matter is not clean. A more detailed study of the problem shows that two of the earliest Foxgate models fall out of the network, with old firmware at the sight of any even 4 megabit (1 channel in SD) multicaste. To be precise, the earliest and cheapest 6208 generally goes to the astral before the broadcast stops and the 24 port model with IP zomboyaschik began to ping under 900ms and with a hellish packlose (well, what did you want for such ridiculous money - tobish at a price of 2 times fewer similar solutions from Zyxel).
The second pebble in the garden of the original idea turned out to be that in the latest firmware available at that time for these receivers, the maximum TTL that could be indicated was 5 which somehow did not particularly agree with the realities of the existing infrastructure at that time. In addition, I remembered DOCSIS subscribers who may also want to see a “zomboyaschik through the Internet”.
The last two factors cut off the desire to cut out selectively on L3 devices that do not tolerate multicast broadcasting, and think about other options. Unicast on specific people from the receiver also turned out to be a stupid idea and we dropped it immediately.
After a brief googling and thinking, the simplest and most obvious (and also pioneer-artisan) solution seemed to be just catching the multicast on one machine with VLC installed and wrapping the resulting image in HTTP.
Since no one was going to buy any glands, they collected something from the pasture with a P4 2.4GHz / 1Gb RAM configuration / Some kind of screw from the desk drawer / 2 network card. It was installed frya 7.1 and VLC 0.8.6i. All this was collected in the following structure:
The config vlc.cfg looked like this:
Actually everything is clear and logical in it - we catch a Broadcast 239.0.0.x from the fxp0 network card and then return it from the network fxp1 already wrapped in http from ports 8011, 8012 and so on. There are no special nuances in all this, if you do not forget to write a rout on the broadband network through the necessary interface (route_broad = "239.0.0.0/24 192.168.8.8").
Then you can run all this with a view script.
and start enjoying life.
The next step was simply and naturally to transfer all this to the existing media server to which users have the maximum speed. To do this, we collect portfwd with a config for the same two channels shown for the example:
We start the forwarder with the portfwd –c /usr/local/etc/portfwd.cfg command and test using the same VLC. Next, we go to Wikipedia to read the description of the M3U format and build a playlist which we will distribute to users along with the instruction how to install VLC and feed the playlist to it.
It seems that everything works, the machine of the above-mentioned ridiculous configuration retransmits 20 channels (80 Mbit stream from 4 receivers) while gritting his teeth. Of the unpleasant effects, it is possible to note periodic VLC drops due to leaky memory, which can be treated with periodic restarts of VLC with the help of the crown, as well as the initial pioneering and dampness of the solution for obvious reasons - one user 4-4.5 Mbit, one hundred obviously already under half a gigabit. But for the sake of interest and lack of desire to finance something more serious, it will completely come down. In addition, users connected using DOCSIS technology will still be able to look at this, unlike other options.
Naturally, in the same way, you can catch channels using a DVB card, or simply show a movie from a file dump - this is how the imagination works / resources allow.
As a further development of the idea, we can consider writing a simple little gadget to billing that allows the user to create his prepaid playlist with the channels he needs and the distinction between banal imbued ones in ipfw tablets with allow / deny through the corresponding broadcast ports. But more about that next time.
Habrayuzer miver prompted to use in order to convert UDP Multicast -> HTTP a product called udpxy which is judging by its “documentation” nothing more than “UDP-to-HTTP multicast traffic relay daemon”. All the same, the world is not without good people because everything just shines with speed and simplicity.
Installation:
Use based on our example:
And a custom playlist will look like this:
It works with a load that is not comparable lower than VLC on the same tasks already for half a day. It seems no surprises. The only thing that depresses is the product is well documented in C. Actually I recommend watching uopt.h on the topic of editing options.
Afterword
1. I would like to express my special gratitude to habro user mkrentovskiy for their invaluable help with VLC. Actually, all the knowledge on the subject and the theory of stream broadcasting in general is drawn from his most interesting blog (I highly recommend, some articles about wowza are worth) and in person. Thanks again that there are people just for the sake of interest who are ready to spend their personal time helping here in such entertainments.
2. As a test implementation, assembled for half a working day - it may well be. But yes - not for serious production.
3. Yes, I am not literate, I know. Language is not native, the school did not learn, although I guess this is a weak excuse. If you perceive the missing comma as a personal insult - I apologize in advance. Honestly - I did not want to.
4. Firmware with the ability to specify a normal TTL and a glamorous web interface appeared much later.
5. It can be made simpler and “conceptual” - to put the receiver into one switch at the end of a switch and multicast - it’s not so fun to do, and even an article from line 1 seems not so entertaining.
According to the characteristics, this miracle of the Chinese industry is approaching professional tuners, but at an incomparably low price. It was originally intended to use these tuners to replace the zoo, which began with Openboxes and Globes and ended with Vantags, as well as for implementing DVB-C in HFC and some sort of DVB-S using Mitris. A cursory examination of the documentation showed that in addition to the initially (and not interesting) ASI, SDI, A / V, RGB, CVBS, XRL outputs required from it, it can also IP input or output with UDP / RTP (optional) and Multicast and Unicast on IP is already much more interesting and more profound, as it were. There is such an occupational disease - be sure to touch the handles with something where there is at least a hint of network capabilities.
')
The first thought was something like “Let's play IPTV, since it is almost inside”
Initial conditions
1. There is an old analogue KTV network covering about 90% of the entire city where DOCSIS 2.0 lives
2. There is an FTTB network covering about 95% of all multi-storey buildings in the city and in many places intersecting with the cable TV network
3. FTTB consists of switches, mainly Zyxel GS-4012F, Zyxel GS-3012F, Zyxel ES-2108, Foxgate S-6024-S2L2, S-6008-S2L2, Foxgate S-6208-S1, Foxgate S-6024-S4L2 and other zoo of the entire range of Foxgate.
4. All the above devices in the manuals indicated that they can both igmp snooping and multicast support.
5. The unpleasant fact of course was that 90% of all these pieces of hardware were 100Mbit / s copper subscribers, but for testing purposes all this suited completely (it was not planned to replace several hundreds of switches for “play”)
Black magic
The first thing that came to mind is to simply set up the tuner on some 6 open channels on any one transponder. And then bend, stated in the multicast manual and poke it all into the switch located in the core of the FTTB network. That without prolonged deliberation and was done with the test tuners available at hand. The first suspicions of the failure of such a venture crept in 40 seconds after the sudden flurry of calls. At a quick glance at the self-monitoring of switches, it turned out that when the receiver was plugged into the nuclear switch, about of the network fell off at about the same time. Strange, but nevertheless we repeat sticking of 1 receiver in a switch and on the panic that began almost immediately on support, we understand that the matter is not clean. A more detailed study of the problem shows that two of the earliest Foxgate models fall out of the network, with old firmware at the sight of any even 4 megabit (1 channel in SD) multicaste. To be precise, the earliest and cheapest 6208 generally goes to the astral before the broadcast stops and the 24 port model with IP zomboyaschik began to ping under 900ms and with a hellish packlose (well, what did you want for such ridiculous money - tobish at a price of 2 times fewer similar solutions from Zyxel).
The second pebble in the garden of the original idea turned out to be that in the latest firmware available at that time for these receivers, the maximum TTL that could be indicated was 5 which somehow did not particularly agree with the realities of the existing infrastructure at that time. In addition, I remembered DOCSIS subscribers who may also want to see a “zomboyaschik through the Internet”.
The last two factors cut off the desire to cut out selectively on L3 devices that do not tolerate multicast broadcasting, and think about other options. Unicast on specific people from the receiver also turned out to be a stupid idea and we dropped it immediately.
After a brief googling and thinking, the simplest and most obvious (and also pioneer-artisan) solution seemed to be just catching the multicast on one machine with VLC installed and wrapping the resulting image in HTTP.
Since no one was going to buy any glands, they collected something from the pasture with a P4 2.4GHz / 1Gb RAM configuration / Some kind of screw from the desk drawer / 2 network card. It was installed frya 7.1 and VLC 0.8.6i. All this was collected in the following structure:
The config vlc.cfg looked like this:
new channel11 broadcast enabled
new channel12 broadcast enabled
….
setup channel11 input udp://@239.0.0.1:1234
setup channel11 output #standard{access=http,mux=ts,dst=my.hostname:8011}
setup channel12 input udp://@239.0.0.2:1234
setup channel12 output #standard{access=http,mux=ts,dst= my.hostname:8012}
….
control channel11 play
control channel12 play
Actually everything is clear and logical in it - we catch a Broadcast 239.0.0.x from the fxp0 network card and then return it from the network fxp1 already wrapped in http from ports 8011, 8012 and so on. There are no special nuances in all this, if you do not forget to write a rout on the broadband network through the necessary interface (route_broad = "239.0.0.0/24 192.168.8.8").
Then you can run all this with a view script.
#!/bin/sh
/usr/local/bin/vlc --daemon --intf telnet --telnet-password gfhjkmnfrjqgfhjkm --vlm-conf /usr/local/etc/vlc.cfg
sleep 3
ps axv|grep vlc|awk '{print $1; exit;}' > /var/run/vlc.pid
and start enjoying life.
The next step was simply and naturally to transfer all this to the existing media server to which users have the maximum speed. To do this, we collect portfwd with a config for the same two channels shown for the example:
tcp {
8011 {=>172.40.0.121:8011}
}
tcp {
8012 {=>172.40.0.121:8012}
}
We start the forwarder with the portfwd –c /usr/local/etc/portfwd.cfg command and test using the same VLC. Next, we go to Wikipedia to read the description of the M3U format and build a playlist which we will distribute to users along with the instruction how to install VLC and feed the playlist to it.
#EXTM3U
#EXTINF:1,MTV
iptv.domain:8011
#EXTINF:1,QTV
iptv.domain:8012
It seems that everything works, the machine of the above-mentioned ridiculous configuration retransmits 20 channels (80 Mbit stream from 4 receivers) while gritting his teeth. Of the unpleasant effects, it is possible to note periodic VLC drops due to leaky memory, which can be treated with periodic restarts of VLC with the help of the crown, as well as the initial pioneering and dampness of the solution for obvious reasons - one user 4-4.5 Mbit, one hundred obviously already under half a gigabit. But for the sake of interest and lack of desire to finance something more serious, it will completely come down. In addition, users connected using DOCSIS technology will still be able to look at this, unlike other options.
Naturally, in the same way, you can catch channels using a DVB card, or simply show a movie from a file dump - this is how the imagination works / resources allow.
As a further development of the idea, we can consider writing a simple little gadget to billing that allows the user to create his prepaid playlist with the channels he needs and the distinction between banal imbued ones in ipfw tablets with allow / deny through the corresponding broadcast ports. But more about that next time.
Habrayuzer miver prompted to use in order to convert UDP Multicast -> HTTP a product called udpxy which is judging by its “documentation” nothing more than “UDP-to-HTTP multicast traffic relay daemon”. All the same, the world is not without good people because everything just shines with speed and simplicity.
Installation:
#wget downloads.sourceforge.net/project/udpxy/udpxy/Chipmunk-1.0/udpxy.1.0-Chipmunk-16.tgz
#tar zxvf udpxy.1.0-Chipmunk-16.tgz
#cd udpxy-1.0-Chipmunk-16/
# gmake && gmake install
Use based on our example:
#udpxy -p 8011 -M 30 -B 2Mb -a 8.8.8.8 -c 15
And a custom playlist will look like this:
#EXTM3U
#EXTINF:1,MTV
iptv.domain:8011/udp/239.0.0.1:1234
#EXTINF:1,QTV
iptv.domain:8011/udp/239.0.0.2:1234
....
It works with a load that is not comparable lower than VLC on the same tasks already for half a day. It seems no surprises. The only thing that depresses is the product is well documented in C. Actually I recommend watching uopt.h on the topic of editing options.
Afterword
1. I would like to express my special gratitude to habro user mkrentovskiy for their invaluable help with VLC. Actually, all the knowledge on the subject and the theory of stream broadcasting in general is drawn from his most interesting blog (I highly recommend, some articles about wowza are worth) and in person. Thanks again that there are people just for the sake of interest who are ready to spend their personal time helping here in such entertainments.
2. As a test implementation, assembled for half a working day - it may well be. But yes - not for serious production.
3. Yes, I am not literate, I know. Language is not native, the school did not learn, although I guess this is a weak excuse. If you perceive the missing comma as a personal insult - I apologize in advance. Honestly - I did not want to.
4. Firmware with the ability to specify a normal TTL and a glamorous web interface appeared much later.
5. It can be made simpler and “conceptual” - to put the receiver into one switch at the end of a switch and multicast - it’s not so fun to do, and even an article from line 1 seems not so entertaining.
Source: https://habr.com/ru/post/94184/
All Articles