MRSS feeds and ad-break cue points, explained

A delivery is two things

Handing a playout platform a video file achieves nothing on its own. The platform receives an object in a bucket with no idea what it is, how long it runs, or where advertising may be inserted. So every delivery has two halves:

• The media — the file itself, uploaded into the ingest storage the platform watches.
• The metadata — an entry in a feed the platform polls, describing that file.

They are matched on the delivered filename. A file with no feed entry behind it does not air; a feed entry pointing at a file that never arrived is an error at ingest. Both halves, every time.

Why MRSS, of all things

MRSS — Media RSS — is an old, boring XML format, and that is exactly why platforms use it. It is a list the platform fetches on a schedule, needing no inbound API, no credentials issued to you, and no coordination when either side deploys. You publish a URL; they poll it.

It has real limitations worth planning for. There is no versioning, so a removed item is simply gone. And an unbounded feed grows until pagination becomes a problem, which is why MediaBlaze windows its feed to recent deliveries and exempts slates — the fallback cards a channel must always be able to reach for.

Cue points, and why a black hole is not one

An ad break is a declared position in the asset where the playout system may insert advertising. It is metadata, not video. The single most common and most expensive mistake made by people arriving from an editing background is to cut literal black into the timeline where the commercials should go. That does not produce an ad break. It produces dead air — and a run of black frames long enough will fail the platform's quality checks outright.

The break has to arrive as a cue point in the metadata, so the platform's own automation can fire against it. Get this wrong and the channel airs with no advertising in it at all, which is usually discovered after launch.

The spacing rules are not advisory

Platforms impose a minimum gap between consecutive breaks — four minutes is a common figure, and it is the one MediaBlaze enforces. Two breaks closer than that will be rejected, and where that rejection happens matters enormously: catching it when the operator places the marker costs seconds, catching it at the platform's ingest costs a re-delivery and possibly a slot.

So MediaBlaze refuses the placement at the point of placement, and quotes the reason. It also seeds a break every eight minutes as soon as an asset's duration is known, because an asset that starts with no breaks marked is an asset somebody has to remember to mark — and on a daily schedule, somebody eventually won't.

What to check before you integrate

• Technical conformance — bitrate, resolution, audio sample rate and scan type all have accepted ranges, and an undeterminable scan type is usually a hard failure.
• That detection is not repair. A pre-flight check that silently re-encodes to pass its own test is worse than no check. MediaBlaze reports and lets you decide.
• What withdrawal actually does. Removing a feed entry stops the platform listing an asset. It does not remove the file, and it does not un-air anything already scheduled. Delivery is not reversible, and any vendor implying otherwise is worth questioning.