VDO Panel: Create and Test a Live Streaming Channel

What this guide helps you do

A practical workflow for creating a live channel, checking ingest details and validating viewer playback before publishing it. VDO Panel and similar streaming panels separate the broadcaster’s ingest connection from the viewer-facing playback URL. The exact labels and available protocols vary by edition and release, so use the connection details generated by your own panel rather than copying ports from another server. This guide is written for production-minded administrators and site owners: make a backup before material changes, keep credentials private, and prefer the controls supplied by your own hosting provider when its environment differs from a generic example.

Before you begin

Record the domain, server or station you are changing and the current working state. If the task touches DNS, SSH, firewall rules, databases, stream credentials or application configuration, make sure you have a recovery path first. Screens and menu names can vary between cPanel, AzuraCast, VDO Panel and Linux releases, so follow the purpose of each step rather than forcing an old screenshot onto a newer version.

Step 1: Create a new live channel and choose only the options you understand: channel name, limits, recording/VOD behaviour and any transcoding profile supplied by the host.

Create a new live channel and choose only the options you understand: channel name, limits, recording/VOD behaviour and any transcoding profile supplied by the host.

Step 2: Open the encoder or connection information and record the server URL, stream key or credentials exactly as displayed. Treat stream keys like passwords and never place them in a public webpage.

Open the encoder or connection information and record the server URL, stream key or credentials exactly as displayed. Treat stream keys like passwords and never place them in a public webpage.

Step 3: Configure your broadcaster with a conservative bitrate that matches the plan and expected viewer connectivity. Start with a known-good 720p or 1080p profile rather than maximum quality.

Configure your broadcaster with a conservative bitrate that matches the plan and expected viewer connectivity. Start with a known-good 720p or 1080p profile rather than maximum quality.

Step 4: Start the encoder, then return to the panel and verify that the source is recognised. A connected source is only the first checkpoint; it does not prove the public player works.

Start the encoder, then return to the panel and verify that the source is recognised. A connected source is only the first checkpoint; it does not prove the public player works.

Step 5: Open the viewer page or HLS playback URL from a separate network/device. Test audio, picture, startup time and several minutes of continuity before announcing the stream.

Open the viewer page or HLS playback URL from a separate network/device. Test audio, picture, startup time and several minutes of continuity before announcing the stream.

Verification checklist

Validate source connected status, stable bitrate, audible audio, public HLS/player playback, HTTPS, viewer compatibility and that the stream stops/starts predictably. Keep the panel’s generated settings as the source of truth. Always test from the user side as well as the administrator side. A control panel saying “active” is useful evidence, but it is not the same as an external browser, player or SSH client proving that the full path works.

Troubleshooting method

When the result is not what you expected, avoid changing several unrelated settings at once. Identify the last known-good point, collect the exact error message and determine which layer is failing: DNS, network, authentication, service process, application configuration, web/stream delivery or browser/player. Check timestamps and logs around the failure. If you need to escalate to hosting support, include the affected hostname or station, the time of the test, what you expected, what happened instead and the checks you already completed. Do not include passwords, API keys or private stream keys in a public ticket or screenshot.

Keep the system maintainable

Document the final configuration after it works. Note the important URLs, service names, backup locations, renewal/expiry dependencies and any change that would surprise another administrator. Revisit the setup after major platform upgrades because defaults, supported runtimes and interface labels evolve. A reliable environment is not one that was configured once; it is one whose current state is understood, monitored and recoverable.

Where to go next

Use the related guides below to expand the setup rather than solving the same problem from scratch. If the platform has outgrown shared hosting or you need managed implementation, the service recommendation at the bottom of this guide links to the most relevant hosting, streaming, development or optimisation option on this site.