Twenty-four hours of stream.
About thirty minutes worth keeping.

Most ad detection starts with the video, pulling the stream and searching its frames for where the break begins. That means choosing a resolution, and every step up multiplies the data to move, store and compare. Even at the lowest one, a day of stream is still a day of video to handle.

We went to the sound instead. Amazon Transcribe turns the stream's audio into text, and Bedrock-based tagging reads that text and marks each advertising segment with its start and end timestamps. Those timestamps are the cut list. The pipeline extracts the corresponding video and nothing else, so the stream is never kept, or processed end to end, at full resolution.

Why: the video was the expensive part of this pipeline, so the design keeps it out until the last step, and then only for the minutes that matter.

Each clip is then tagged, again with Bedrock: the brand behind the ad, which parent brand that product brand belongs to, and how often the ad runs. Those records are the base of the business's ad database, and they pass through the same confidence line as everything else (below).

A job that runs once or twice a day shouldn't need a server at all, because AWS Lambda only bills while code is running. Two things stood in the way. The scraper only ran on Windows, and it ran for 30 to 40 minutes, while a Lambda function stops at 15.

The first was a rewrite into Python, which doesn't care what it runs on. The second was the real design decision. The usual answer to a job that outgrows Lambda is a container that stays up, which would have brought the always-on bill straight back. We cut the job into phases instead, each short enough to finish inside the limit, which made the processing Lambda-based and event-driven.

Each phase writes its intermediate files to Amazon S3 and puts a message on an Amazon SQS FIFO queue, which starts the next phase. FIFO matters here, because a phase must never start on the files of one that hasn't finished. So S3 holds the state and the queue holds the sequence, with no persistent database and no server waiting between runs. The infrastructure bill fell about 90%, and a run now takes about 20 minutes where the old script took 30 to 40.

No extraction model is right every time, so the question that matters is what happens when it isn't. Every record the AI produces carries a confidence score. At 85% or above it's marked verified and written to the database. Below 85%, it goes out as a Slack notification for human validation.

That threshold is the decision. Set it lower and mistakes reach the database unseen; set it higher and people spend their day re-checking work the model got right. At 85%, about 15% of records go to a person. The colleague who once typed everything into a spreadsheet now only confirms or corrects those, with a click in the front end the business already had. Each correction goes back to the model, so that share can keep shrinking. The ad metadata follows the same rule: tags at 85% or above go straight into the ad database, and the rest go to a reviewer.

Every streaming service publishes its own release list. Nobody publishes the list the business needed: the upcoming originals across all of them, meaning the shows one service makes to run only on that service. Third-party sources had the data, spread across four providers, each unstructured, inconsistent and overlapping with the others.

We scrape all four and normalize what comes back, then hand a model on Bedrock the part that rules handle badly: deciding that two differently written entries are the same show. The pipeline merges them, and the output is one clean, deduplicated list of upcoming originals.