Projects:2015s2-212 TV Control and Monitoring
Contents
Introduction
The TV Control and Monitoring project was established to design part of a system that will be able to detect and block advertisements from being shown on TV in real-time. The system will primarily be used in a study on the effects of unhealthy food TV advertising on children. The study is funded by the Heart Foundation and will be run by the university’s School of Population Health.
Project Scope
The scope of the project involved designing a system that could receive notifications from an existing ad detection system, and then ensuring that ads are blocked from showing on study participants’ TVs. Two features that the system could be capable of providing were also included: First, gathering of TV ratings data in real-time. And second, gathering of TV advertising statistics.
High-Level Design
The following diagram shows one set-top box (STB). However, there will be as many as several hundred in use at one time. All communication takes place over the Internet.
Detection System
The detection system comprises a number of servers located on campus that receive the digital TV signals. The servers implement an algorithm developed by co-supervisor Ben Agnew, which detects advertisements in real-time.
Remote System
The remote system sits between the detection system and STBs. It maintains the connections to the STBs and upon receiving an ad notification from the detection system, notifies the STBs that are tuned to the same channel.
Set-Top Box
The STB replaces the home’s existing tuner. It is based on the Raspberry Pi and the free and open source Kodi software. The project logic was modelled as a finite-state machine and developed as a Kodi add-on. Upon receiving an ad notification from the remote system, the STB is responsible for blocking the ad from being shown.
Design Details
Message Flow
The communication between the detection system, remote system, and STBs is modelled on the so-called publish-subscribe pattern. As users change channel on their TVs, the STBs subscribe to notifications on that particular channel. As the remote system receives notifications from the detection system, it publishes notifications to subscribers of the channel on which an ad is detected. This allows the remote system to gather real-time ratings data, as well as reduce unnecessary notifications, i.e. the alternative is to send a notification of an ad received on a channel to all of the STBs, regardless of what channel they're tuned to.
The following figure shows an example of the message flow that takes place, with only one STB connected:
- User changes channel to 7, STB subscribes to notifications on that channel
- STB receives status of channel 7 (no ad)
- User changes channel to 9, STB subscribes to notifications on that channel
- STB receives status of channel 9 (no ad)
- Detection system detects ad on channel 10, tells remote system
- Detection system detects ad on channel 9, tells remote system
- Remote system has a subscriber of channel 9 and publishes notification
- STB receives notification and blocks ad
- User changes channel to 9, STB unblocks and subscribes to notifications on that channel
- STB receives status of channel 10 (ad)
- STB blocks ad
- Ad ends prematurely and detection system tells remote system
- Remote system publishes notification and the STB unblocks
Programming Model
The STB can be modelled as a finite-state machine (FSM). An FSM is an abstraction of a machine that can be in one of a finite number of states at a time. The machine can transition from one state to another when a certain event occurs.
For example, a simple microwave can be thought of as an FSM. At any time, it can be in one state, e.g. cooking, not cooking, door open. It can transition from one state to another when e.g. a particular button is pressed, the cooking timer finishes.
Modelling the STB this way helps to organise when certain events should be handled, how to handle them, etc.
The below figure shows the FSM. It has four states: not_playing, playing, blocking, and aborting. The arrows show how states can transition from one to another. For example, when in the blocking state, if the user changes channel, as discussed in Message Flow, the STB will subscribe to that channel. If an ad is being broadcast on that channel, the STB will remain in the blocking state; otherwise, it will transition to the playing state.
NAT Traversal
For STBs to be notified when an ad has been detected, they could either periodically poll the remote system or be alerted immediately. The latter was chosen because polling would result in a lot of unnecessary requests to the remote system, and ads wouldn't be blocked as fast, e.g. an ad could be detected right after the last poll, but the STB won't know until its next poll.
The challenge with alerting STBs is that they will use existing home Internet where possible, and devices in homes are typically on private networks. So that these devices can access the Internet, an Internet router performs what's called network address translation (NAT). When a device makes a request out to the Internet, NAT involves translating the private IP address of the device to a public IP address of the router (typically a home will have one public IP). That way, replies to the device are received back at the router, and then the router forwards them onto the device.
This situation is a common problem for applications that require immediate access to devices behind NAT, e.g. a VoIP phone needs to be alerted immediately when someone calls it. To get around it, a technique known as hole punching is used.
In the design, the STB makes and persists a TCP connection to the remote system. This "punches a hole" in the router: there is now a channel between the STB and remote system. The remote system can then send ad notifications to the STB using that channel.
Members
Students: Brendan, Zhuoyao Li
Supervisor: Matthew Sorell
Co-supervisor: Ben Agnew
