Video Source Control
This code was written to control the video source of dish network receivers. The receivers output multicast video in a transport stream as mp4. The control functions used soap, while the video streams were controlled using rtsp. The output video was what showed up on the set top box in the guest rooms. This application became absolutely essential as it provided an easy, point and click way to:
- Check stream status
- Restart streams
- Reboot receivers
- Modify channel numbers
- Modify multicast destinations
- View a sample of the video stream
- View historical graph of signal strength
- Get receiver information such as channels playing, signal strength, receiver id, etc
- Provide email alerts for when channels went down or a receiver signal strength went below a provided threshold
There is also a daemon running in the background that automatically checks each receiver every five minutes. The daemon verifies:
- The stream is still running
- The receiver is on the correct channel
- The receiver signal strength is above a provided threshold
- That the packet count coming from the stream is above a provided threshold
- Record the signal strength in an rrd database
- Corrective actions if any of the above criteria fail
- E-Mail alerts if the corrective actions do not resolve the issue
Programming languages used: perl (backend), php (frontend), javascript (frontend)
OS: CentOS 5.5
Closed Captioning
This code was written because the set top boxes that were in use were unable to read the closed captioning information coming from new video streams. While the finished product took several weeks to complete, it was absolutely essential as the customers had to be able to provide the closed captioning service to their guests.
The machine had to accomplish multiple tasks: it would join the entire lineup of HD and SD multicast video streams at a specific property, extract the closed captioning information from the video stream, modify the data and write it to an xml formatted file on a ramdisk, and serve the files through an apache webserver to interested set top boxes.
In the video, you can see roughly 200Mb/s coming in on each interface that is joining the multicast groups (in this case, two interfaces load balancing the streams), the netstat command showing the joined multicast streams on each interface, and the xml files that are output after being formatted for set top box consumption.
Programming languages used: perl, c
OS: Ubuntu Server 12.04
Ethernet to COAX to Ethernet
This code was written to manage the large number of moca (Multimedia Over Coax) devices that were used for properties that had an existing coax infrastructure and did not want to run new copper cabling. These devices converted ip traffic over ethernet, to a TDM signal over coax, back to ethernet at the end device in the guest room, where the payload was delivered to the set top box.
Each NC head-end device had multiple CPE guest room devices that connected to it. Since properties rarely had accurate information available describing their coax infrastructure, the application automatically discovered which NC each CPE connected to as the CPE's were installed in the guest room (this functionality is provided by the "Start Engine" button on the bottom). Once new devices were discovered (show up in the web interface), it was a simple click to reconfigure the NC and CPE to work nicely together and provide network access to the guest room. The application also provided:
- IP of the NC device
- Physical location of the device (rack and label number)
- Signal strength of the device over the coax cable
- Frequency of the devices on the coax cable
- Ping a device
- Reset a device configuration
- Reboot a device
- Auto discover NC to CPE mapping
- Warning if a head-end NC has too many CPE devices attached to it (which would degrade service)
- Get information for an NC device, such as uptime and logs
- Historical notes for devices to keep track of recurring issues
- Email alerts for when a device became unreachable
Programming languages used: perl (backend), php (frontend), javascript (frontend)
OS: CentOS 6.3
Custom Reports
This code was written to provide summary reports on a per property basis, and a general overview, of the network infrastructure. The monitoring system being used is zabbix, and is collecting data mostly through snmp, although also utilizing the zabbix agent and the zabbix proxy.
Zabbix does not come with a built in report generation tool that can be used to create nicely formatted pdf's for managment, so I decided to write my own. Zabbix provides a nice api through json that can be used to gather information or modify devices.
Note that I have blurred out the property names, or anything that may give away customer information in the below video.
Programming languages used: perl (gather json information), php (pdf report generation)
OS: CentOS 6.3
In addition to the zabbix server performing active checks, there was also a splunk server collecting syslog information. All of the network infrastructure devices (routers and switches), as well as ineoquest crickets (devices that interrogate video streams for quality) were set up to send syslog messages to this system, and I was responsible for creating useful information out of the deluge of logs. This was accomplished using a variety of splunk search commands, and some of the resulting reports are shown below, with usernames blurred out.
OS: CentOS 6.3
