Setting Up a Secure Feed Delivery Link With a Broadcaster

Most delivery problems begin before any cable is plugged in. A feed can leave the venue clean and still be unusable at the other end because nobody asked the receiving desk what it expected. So the first job is a short written exchange with the broadcaster or news desk, and I keep it to the points that decide whether the picture lands properly.

Ask for the video format and frame rate they ingest, the audio layout and channel order, the timecode or clock reference if one is used, and the name of the person who will be watching the incoming link. Ask also how they want the feed labelled when it arrives, because a desk handling several sources at once will not guess which one is yours.

Put the answers in one message and ask them to confirm it. When something changes on the day, you then have a document to point at, and the person at the desk is not trying to remember a phone call.

• Picture format and frame rate
• Audio channels and their order
• Timecode or clock reference
• Name and number of the contact on the receiving desk

Once you know what the desk wants, decide how the feed will travel. Secure links come in a few forms: a dedicated circuit, an encrypted stream over a managed internet connection, or a bonded cellular path where nothing fixed exists. Each has a different tolerance for delay and for interruption, and the right one depends on where the feed starts and how much it matters that it never drops.

For a studio or a venue with a proper connection, an encrypted stream over a monitored line is usually enough, provided there is a second route ready. For a location with a weak signal, bonding several paths together gives more headroom than leaning on one. The common error is picking the link by habit rather than by the site.

Check the upload capacity you will really have, not the figure on the contract, and test it at the hour you will be live. Venue networks that behave well in the morning can slow badly once an audience arrives.

A secure link is only secure if both ends have set it up the same way. Settle who generates the access details, how they are passed on, and who is allowed to receive the feed. Passing credentials by the same channel as the schedule is a habit worth breaking; send them separately and to the named person only.

We treat discretion as part of the job. A feed that carries unreleased footage or a developing story should reach the intended desk and nobody else, so access is limited to the people listed in the confirmation message and removed once the job is complete.

Write down the stream name, the destination address given by the broadcaster, and the point at which each side stops transmitting or receiving. These small facts are the first thing anyone reaches for when a link misbehaves at an awkward moment.

• Separate delivery of access details
• A named list of people who may receive the feed
• Stream name and destination recorded in writing

A test from our side proves very little. What counts is that the receiving desk sees the picture and hears the sound as they expect it, so a proper test is a short live check with someone at the other end looking at it. Do this at least a day before, and again on the morning of the job if timing allows.

Send a test pattern or a few minutes of the actual camera output with tone. Ask the desk to confirm picture, sound, channel order and labelling, and to tell you what delay they measure. Note the figure, because it helps the production team time cues and talkback.

If the test shows a fault, change one thing at a time. Swapping the encoder, the route and the settings together leaves you unsure which change cured it, and the same fault tends to return on the day.

Plan for the link to fail, because over enough jobs one will. A fallback needs to be ready to switch to in seconds, not assembled after the drop. That might be a second path on a different provider, a lower bitrate stream held in reserve, or a recorded copy that can be sent on afterwards.

Agree with the desk beforehand what they want to see when the main feed is lost. Some prefer a hold slate, some want audio only for a short time, and some would rather cut away at once. Having that decided means nobody is improvising during a live bulletin.

Keep one person watching the outgoing signal for the whole transmission. In our team that is usually the coordinator or the signal engineer, and their only task is to notice a problem before the audience does and to act on the plan already agreed.

• Second path on a different provider
• Lower bitrate stream held in reserve
• Agreed slate or audio-only behaviour

When transmission ends, do not pack away straight away. Confirm with the desk that they have what they needed, that the feed ended cleanly, and whether any recording or clip should follow. A short message at this point settles questions that otherwise surface days later.

Keep a simple log of the job: formats used, the link chosen, the delay measured, any faults and how they were handled. Next time the same broadcaster asks for a feed, you begin from known settings rather than from a blank page, and the first test goes faster.

Then remove access. Credentials that remain active long after a job are a small risk that is easy to avoid, and clearing them is part of finishing properly rather than an extra.