Sanctus TV

• 

• 

• 

• 

• 

Inspiration

Sanctus TV started long before this competition. I have been building it as a live TV platform, and as the number of channels increased, one problem kept coming back.

Sometimes a stream would still be connected, but the picture was frozen, black, or simply not moving. From the server side, the channel could look fine. But for the person watching, it was not fine at all.

I found myself checking channels manually to know what was really happening on the screen. That may be possible with a few channels, but Sanctus TV is growing, and I knew it would not be practical for long.

That was where the idea for this project came from.

Instead of asking only, “Is this stream online?”, I wanted Sanctus TV to also ask, “Is there actually a healthy picture playing?”

What it does

I built a visual monitoring system for Sanctus TV using OpenCV 5.

It watches frames from a live stream and looks for signs that something is wrong with the actual picture. For example, it can notice when the picture has stopped changing for a sustained period or when the output has gone black.

I did not want one unusual frame to be enough to declare a channel faulty. Television can naturally have quiet or almost static scenes. So the system observes what is happening over time before making a decision.

When it has enough evidence that the picture has really stalled, it can recommend or carry out a safe retest.

But there is another part that was very important to me: reconnecting the stream is not automatically counted as success.

OpenCV checks the picture again.

Only when fresh visual activity is seen does the system record that the channel has recovered. If it cannot be sure, it does not pretend to know. It can leave the result as Inconclusive or send it for human review.

How we built it

OpenCV 5 handles the visual side of the system. I use it to examine frames and measure changes in the picture over time.

Around that, I built a small state system that keeps track of what is happening. A channel can move from a normal state to suspected trouble, confirmed failure, a recovery attempt, and finally either recovered or still needing attention.

This also became the basis of the agentic part of the project.

OpenCV does not just produce information that sits on a dashboard. What it sees can affect what happens next.

For example:

OpenCV detects a sustained freeze → the system gathers evidence → a safe retest is selected → the stream is checked again → OpenCV verifies whether the picture actually returned.

I use AWS for the cloud side of this process. The observations, actions and outcomes are stored through an AWS-backed API so that there is a record of what happened and why.

I also built a Broadcast Health dashboard where I can see the channel state, the visual evidence, what action was taken, whether recovery was confirmed, and cases that still need human attention.

For important decisions, the human operator remains in control and can confirm, reject or override what the system recommends.

Challenges we ran into

The biggest challenge was false alarms. A television picture does not have to move constantly to be healthy. A presenter may sit almost still. A logo or title screen may remain for several seconds. Some religious programmes also have long periods with very little movement. My earlier approach could mistake some of these situations for a frozen stream. I had to change the detector so that it looked at a sequence of frames and required sustained evidence before confirming a freeze. That made the system much more careful.

Another challenge was deciding what “recovered” really means.

At first it is tempting to say that if the stream reconnects, the problem is solved. But that brought me back to the original problem: a connection can be alive while the picture is still bad.

Accomplishments that we're proud of

I am particularly happy that I tested this with both controlled failures and real Sanctus TV channels.

The controlled tests included a healthy video, a genuinely frozen picture, a black picture, legitimate low-motion video, successful recovery, and a case where recovery never happened.

I also ran the system against 12 real channels from 10 different programming groups. During that test it decoded 5,314 frames and made 525 OpenCV observations.

I later ran repeated observation rounds and successfully stored 24 out of 24 health events through the AWS system.

But the part I am most proud of is much simpler:

The system can see a visual problem, use that evidence to decide what should happen next, and then look again to check whether its action actually worked.

That is the behaviour I wanted when I started.

What we learned

This project changed the way I think about monitoring video.

Before this, I was spending a lot of effort checking whether streams could connect. I learned that for live television, connectivity is only part of the story. What matters to the viewer is whether there is actually a usable picture on the screen.

I also learned that an AI system does not always have to give a definite answer.

Sometimes “I don't have enough evidence yet” is the correct answer. That is why I kept Inconclusive as a real state instead of forcing every observation into Healthy or Failed.

Most importantly, I learned that automation becomes much more useful when it can explain what it saw, take only a limited action, check the result, and still leave room for a person to intervene.

What's next for Sanctus TV

Sanctus TV is still growing, so I want this system to grow with it.

The next step is to improve the visual checks for more kinds of broadcast problems and gradually use the health system across a larger part of the channel catalogue.

I also want to keep improving the balance between automatic recovery and human control. My aim is not to remove people from the process. It is to make it possible for one person to manage a large live TV service without having to sit and watch hundreds of channels manually.

Sanctus TV existed before this competition. What I built for this competition is the new visual reliability system around it: the OpenCV 5 monitoring, failure detection, recovery and verification workflow, AWS audit trail, testing framework, and Broadcast Health dashboard.

Built With

• amazon
• amazon-dynamodb
• amazon-web-services
• api-gateway
• aws-lambda
• cloudformation
• html
• javascript
• opencv
• python