Troubleshooting

Last update:2026-10-19 14:40:57

Live Streaming Troubleshooting

Use this guide to diagnose ingest and playback issues with Media Acceleration Live Broadcast. Start with the symptom that matches the issue. If it persists, collect the details listed at the end and contact CDNetworks support.

Table of Contents

Ingest issues

The stream cannot be published

1. Check DNS

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

2. Check the encoder settings

Verify the ingest domain, application name, stream name, protocol, and port. In OBS Studio and similar encoders:

  • Server contains the protocol, ingest domain, and application name, for example, rtmp://push.example.com/live.
  • Stream Key contains the stream name and any required query parameters, for example, demo.
  • If URL authentication is enabled, include the required parameters using the signature and timestamp parameter names configured for the domain.

Confirm that the application name is allowed in the domain configuration. If possible, compare the result with another encoder.

3. Check audio and video formats

Check the encoder’s output codecs. H.264 video and AAC audio are commonly used for live streaming, but the output must also be compatible with the selected streaming protocol and target player.

If a source or playback URL is available, inspect its codecs with FFprobe from the FFmpeg project:

ffprobe -hide_banner "<source-or-playback-url>"

Replace the placeholder with an accessible source or delivery URL, including authentication parameters if required. An ingest-only URL is not a playback URL. If ingest has not started, inspect the encoder settings or a local recording instead.

4. Check for another active publisher

An active publisher using the same application name and stream name can prevent a new publishing session. If the encoder reports Server error: Failed to publish, check for another encoder or process publishing that stream. Stop the duplicate session or test with a different stream name.

5. Check authentication and access controls

The ingest URL must contain valid, unexpired authentication parameters when authentication is enabled. Check parameter names and values, and generate a new URL if needed. Also confirm that IP or other access rules allow the publisher’s request. An I/O error alone does not identify the cause.

See Access Control for configuration details.

6. Check stream-blocking tasks

In the console, check whether an active blocking task applies to the stream or publisher IP address. If the block is unintended, ask an authorized administrator to remove it before retrying.

7. Check the publisher’s network

  • Test connectivity to the ingest domain and the configured port. RTMP normally uses TCP port 1935; use the actual port if the URL specifies a different one.
  • Check for packet loss, unstable latency, or restrictions imposed by a firewall, proxy, router, or ISP.
  • Confirm that available upstream bandwidth can sustain the configured bitrate.

Playback issues

The stream cannot be played or returns an HTTP error

1. Check the playback URL

A playback URL contains a delivery domain, application name, and stream name. The path and extension depend on the protocol:

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

Check the domain, application name, stream name, protocol, path, extension, and letter case. For HTTPS playback, confirm that the delivery domain has a valid certificate.

If authentication is enabled, verify that all required parameters are present and unexpired. For HLS, inspect the failing request to determine whether it is the playlist or a media segment.

2. Check DNS and domain configuration

  • Confirm that the delivery domain resolves to its assigned CDNetworks CNAME target.
  • Confirm that the application name and selected playback protocol are allowed. See Application Names and Delivery Protocols.
  • Check access controls for the affected request, including the viewer’s IP address, Referer, User-Agent, and authentication parameters.

For a 403 response, prioritize authentication and access rules. For a 404 response, prioritize the URL path and source availability. Record the response status and body; the status alone does not identify the cause.

3. Check the stream source

  • Publisher Ingest: Confirm that the encoder is connected and sending data, and that the delivery domain is associated with the intended ingest domain. If ingest fails, follow The stream cannot be published.
  • Origin Pull: Confirm that the source stream is available at your origin. Check the origin address, protocol, port, Host header, and any origin-side access restrictions. See Origin Settings.

4. Test another player

Use another player that supports the protocol and codecs. If playback succeeds, review the original player’s support and configuration.

For browser playback, inspect the developer console and network requests. Check for certificate errors or an HTTPS page attempting to load an HTTP stream. If JavaScript requests fail because of cross-origin restrictions, check the CORS response headers. HLS may require these headers on both playlists and media segments.

5. Check the viewer’s network

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

Playback stutters or buffers frequently

  1. Confirm that the publisher’s upstream connection can sustain the configured bitrate. For Origin Pull, also check the source stream at the origin.
  2. Check encoder CPU and hardware usage. If the encoder is overloaded, test with a lower bitrate, resolution, or frame rate.
  3. Compare playback on another device, player, and network. Confirm that the viewer’s available bandwidth can sustain the stream bitrate.
  4. Distinguish a low source frame rate from buffering. A low frame rate can make motion look choppy even when delivery is stable.
  5. Review player buffer settings. A larger buffer can absorb network fluctuations but may increase playback latency.

The picture is blurry

  1. Check the source image before publishing.
  2. Review encoder output and available ingest analysis for unexpected changes in bitrate, frame rate, resolution, or stream errors.
  3. Confirm that hardware or network limits are not causing the encoder to reduce quality.
  4. If transcoding is used, confirm that the selected output resolution and bitrate meet your requirements.
  5. Compare another player. If supported, compare software and hardware decoding.

Playback stops unexpectedly

  1. Check whether the encoder or origin stream stopped at the same time. If so, troubleshoot the source and its network first.
  2. Check for an expired authentication URL or a stream-blocking task that took effect during playback.
  3. Determine whether the interruption affected one viewer, viewers on one network, or viewers in multiple locations.
  4. Compare another player, device, and network, and collect the incident details below.

RTMP and HTTP-FLV work, but HLS fails

  1. Confirm that HLS is enabled for the delivery domain and that the HLS URL is correct.
  2. Check the playlist and media-segment requests separately, including response codes, authentication parameters, and CORS headers when applicable.
  3. Inspect the source or playback stream with FFprobe and review player logs for codec, timestamp, or packaging errors.
  4. Confirm that the codecs are compatible with the target HLS player.
  5. For Origin Pull, check the origin Host header and confirm that the origin serves the requested playlist and media segments.

HLS has video but no audio

Check the source audio codec and confirm that the HLS player supports it. Compare the same stream over another enabled protocol. If audio works over RTMP or HTTP-FLV but fails over HLS, test with AAC audio. For browser playback, also check whether autoplay restrictions have muted the player.

Information to collect

If the issue persists, provide CDNetworks support with:

  • Ingest and playback URLs, with secrets and authentication signatures redacted
  • Domain, application name, stream name, and stream ingest mode
  • Protocol and player or encoder name and version
  • Incident time and time zone
  • Whether ingest, playback, or both are affected
  • Scope of the issue: viewers, networks, and locations affected
  • Affected public IP addresses, when appropriate and permitted
  • Error messages, HTTP response codes, and relevant encoder, player, or request logs
  • Results from another player, device, encoder, or network
  • FFprobe or FFmpeg output, if available

Redact credentials, stream keys, tokens, and authentication secrets from URLs, logs, and screenshots before sharing them.

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!