Back
Media Acceleration Live Broadcast
CDNetworks Documentation Media Acceleration Live Broadcast Troubleshooting

Troubleshooting

Last update：2026-07-10 17:27:20

Use this guide to diagnose common stream ingest and playback issues with CDNetworks Media Acceleration Live Broadcast. Start with the symptom that best matches the issue, complete the checks in order, and collect the requested details before contacting CDNetworks support.

Table of Contents

Stream ingest issues

The stream cannot be published

1. Verify DNS and CNAME configuration

After you add an ingest domain, CDNetworks assigns it a CNAME target. Create the corresponding CNAME record with your DNS provider.

  • Use a DNS lookup tool to confirm that the ingest domain resolves to the CNAME target assigned by CDNetworks.
  • If the domain does not resolve or points elsewhere, correct the DNS record and allow time for the DNS change to propagate.

2. Verify the encoder settings

Confirm that the encoder contains the correct server URL and stream key. In OBS Studio and similar encoders:

  • Server contains the ingest domain and AppName.
  • Stream Key contains the StreamName and any query-string parameters.
  • If URL authentication is enabled, include all required authentication parameters. Timestamp authentication, for example, may require wsTime and wsSecret.

If possible, test with another encoder to determine whether the issue is specific to the original encoder or its configuration.

3. Verify the audio and video formats

H.264 video and AAC audio are commonly used for live streaming. Inspect the stream with FFmpeg:

ffmpeg -i "rtmp://<ingest-domain>/<app-name>/<stream-name>"

Replace the placeholders with the ingest domain, AppName, and StreamName. Review the output for the detected codecs and any connection, authentication, or decoding errors.

4. Check for a duplicate active stream

Two publishers cannot publish simultaneously with the same StreamName under one AppName. If the encoder reports Server error: Failed to publish, confirm that another encoder or process is not already publishing the same stream, then retry.

5. Check URL authentication

When URL authentication is enabled, the ingest URL must contain valid, unexpired parameters. Missing, misspelled, invalid, or expired parameters can cause publishing to fail with an I/O error. Verify values such as wsTime and wsSecret, then generate a new authenticated URL if necessary.

6. Check whether stream publishing is blocked

Use the stream-blocking task list in the console to check whether the stream or publishing IP address is blocked. If the stream should be restored, follow your organization’s change process or contact an authorized administrator.

7. Check the publisher’s network

  • Use a DNS lookup tool to confirm that the ingest domain resolves correctly.
  • Check for packet loss or unstable latency between the publisher and the ingest domain.
  • When using RTMP, test connectivity to the ingest domain on TCP port 1935.
  • Confirm that the publisher has enough stable upstream bandwidth for the configured bitrate.

If the connection test fails, check local firewall, proxy, routing, and ISP restrictions.

Playback issues

The stream cannot be played or returns 404

1. Verify the playback URL

A playback URL normally contains the delivery domain, AppName, and StreamName. Its path and extension depend on the protocol. For example:

rtmp://play.example.com/app/stream
https://play.example.com/app/stream.flv
https://play.example.com/app/stream/playlist.m3u8

Confirm the domain, AppName, StreamName, protocol, path, extension, and letter case. If authentication is enabled, also verify that all required parameters are present and have not expired.

2. Verify DNS and CNAME configuration

Use a DNS lookup tool to confirm that the playback domain resolves to the CNAME target assigned by CDNetworks. If it does not, correct the DNS record or contact your DNS administrator.

3. Confirm that ingest is active

Playback fails if the source stream is not being published. Confirm that the encoder is connected and sending data, then complete the checks in The stream cannot be published.

4. Test another player

Try a player that supports the playback protocol. If the stream works in another player, review the original player’s protocol support, media codec support, and configuration.

For browser-based playback, inspect the browser console for cross-origin errors. When the player page and stream use different origins, the playback response must include the required CORS headers.

5. Check the viewer’s network

Compare playback on another device or network. If only one viewer is affected, investigate that viewer’s connection, firewall, proxy, browser, and player environment.

Playback stutters or buffers frequently

Check the stream from ingest to playback:

  1. Confirm that the publisher’s upstream connection is stable and can sustain the configured bitrate.
  2. Check encoder CPU and hardware utilization. If the encoder is overloaded, test with a lower bitrate, resolution, or frame rate.
  3. Confirm that the configured frame rate is appropriate for the content. Very low frame rates can appear visibly choppy.
  4. Compare playback on another device, player, and network.
  5. Review the player’s buffer configuration. A larger buffer may improve resilience but can increase playback latency.

The picture is blurry

  1. Confirm that the source looks clear before publishing.
  2. Review the ingest analysis for unexpected bitrate, frame rate, resolution, or stream errors.
  3. Confirm that the encoder is not unexpectedly lowering the bitrate or resolution because of hardware or network limitations.
  4. Check whether stream metadata changes during publishing. Unexpected changes can affect downstream processing.
  5. Test another player. If supported, compare software and hardware decoding.

Playback stops unexpectedly

  1. Confirm whether ingest stopped at the same time. If it did, troubleshoot the publisher and its network first.
  2. Determine whether the interruption affected one viewer, one network, or multiple viewers in different locations.
  3. Test another player, device, and network.
  4. Record the incident details listed in Information to collect.

RTMP and HTTP-FLV work, but HLS fails

  1. Inspect the stream with FFmpeg or FFplay and note any codec, timestamp, or packaging errors.
  2. Confirm that the audio and video codecs are compatible with the target HLS player.
  3. Ask an administrator to confirm that the origin Host header or back-to-origin Host configuration is correct.
  4. Recheck the HLS URL, authentication parameters, and player support.

HLS has video but no audio

Inspect the source audio codec and confirm that the target HLS player supports it. Compare the same stream over RTMP or HTTP-FLV. If audio works with those protocols but not with HLS, test the stream with AAC audio.

Information to collect

If the issue continues, provide the following details to CDNetworks support:

  • Ingest and playback URLs, with secrets and authentication signatures redacted
  • Domain, AppName, and StreamName
  • Protocol and player or encoder name and version
  • Approximate incident time, including the time zone
  • Whether the issue affects ingest, playback, or both
  • Whether one viewer or multiple viewers are affected
  • The affected viewer’s public IP address, when appropriate and permitted
  • Encoder or player error messages and relevant logs
  • Results from another player, device, encoder, or network
  • FFmpeg or FFplay output, if available

Do not share unredacted credentials, stream keys, tokens, or authentication secrets.

Is the content of this document helpful to you?
Yes
I have suggestion
Submitted successfully! Thank you very much for your feedback, we will continue to strive to do better!

CDNetworks Inc., © 2025. 1840 Enterprise Way, Monrovia, CA 91016 – All rights reserved.