Live Streaming issues

Common issues encountered when working with Live Streaming, and steps to troubleshoot them.

​

Current broadcast contains DVR chunks of the previous broadcast

Possible cause: The broadcast ended, but the stream has not been stopped.
Suggested solution: This is expected behavior, not an error. DVR chunks from the previous broadcast persist until the stream is stopped and the archive is cleared. To prevent this:

• Stop the stream when the broadcast ends.
• Clear the DVR archive before starting a new broadcast.

​

Low-latency streaming is buffering

Possible cause: The viewer’s internet speed or quality is insufficient to download data in time.
Suggested solution: Switch affected viewers to the non-low-latency path. Standard HLS MPEG-TS segments are less sensitive to network variability and work on a wider range of devices. Use the HLS non-low-latency manifest URL (/master_mpegts.m3u8) shown in the Customer Portal, or add the ?no_low_latency attribute to the built-in player.

• Playback URLs lists the HLS non-low-latency manifest (/master_mpegts.m3u8).
• The built-in player accepts a ?no_low_latency query parameter.

​

Manifest is empty and stream is not working

The stream reaches the ingest point normally — ffmpeg or OBS show correct output — but the .m3u8 manifest is empty and playback fails. Possible cause: The master stream is being sent with network problems, or the encoder settings are incorrect.
Suggested solution: Check the Monitoring graphs for the stream in the Customer Portal. FPS, keyframe interval, and bitrate should remain stable. Breaks in these graphs indicate problems with the incoming stream. Check encoder settings:

• Input parameters and codecs
• RTMP protocol
• SRT protocol
• Broadcasting software (ffmpeg, OBS)

​

Picture breaks into artifacts when streaming via SRT

When the picture breaks into artifacts like the example below: Possible cause: Packet loss during delivery from the encoder via SRT.
Suggested solution: Try sending from a different network or provider. Reduce the master stream bitrate and set SRT latency explicitly.

• SRT latency covers latency configuration.
• If packet loss is not the cause, validate that PTS/DTS values follow a continuous and monotonic timeline — PTS/DTS timestamps.

​

Restream failed

Each destination enforces its own technical requirements for ingesting live video streams. These limits typically include constraints on bitrate, codec profiles, audio formats, keyframe intervals (GOP), and connection behavior. When restreaming through Gcore, the output must comply with destination specifications; otherwise, the remote side can reject the connection or terminate the stream. By default, restreaming forwards the master stream as is without transcoding (source: "original"). Verify that master stream parameters match destination requirements. To broadcast overlays and processed video instead, switch the restream source to transcoded. Common causes of connection refusals and stream drops:

• Mismatched encoding parameters: Mismatched keyframe intervals (GOP), unsupported video codecs, or exceeding bitrate thresholds.
• Missing audio track on YouTube: YouTube rejects incoming streams that lack an audio track. When disabling restream audio via API, set no_audio_mode to silence instead of drop.
• Expired stream keys: Expired or rotated stream keys on the target destination.

For destination-specific requirements, the Restream troubleshooting article covers common destination-specific issues.

​

RTMP stream freezes or buffers

Possible cause: Packet loss during delivery from the encoder via RTMP.
Suggested solution: Try sending from a different network or provider and reduce the master stream bitrate — this resolves most cases. If the issue persists, check these settings:

• Input bitrate: use the minimum recommended values from Input parameters and codecs. Quality impact is minimal, but broadcast stability improves.
• Encoder settings: verify the master stream uses recommended low-latency encoding parameters from the RTMP protocol article.
• Timestamps: validate that PTS and DTS values follow a continuous and monotonic timeline — PTS/DTS timestamps.

​

Live stream is 10-12 fps, but recording looks fine

Possible cause: The transcoder reads the source FPS once when the live session starts and keeps that value for the entire session. By default, Gcore does not upscale the detected FPS during the current session. If the encoder connected while already sending a reduced or unstable frame rate, the transcoder locks in that value. Recording is a separate workflow and may still look correct even when the live session started from degraded source metadata. Suggested solution:

• Check the stream Monitoring graphs in the Customer Portal. FPS, bitrate, and keyframe interval should be stable from the beginning of the session.
• Verify that the encoder is configured with a fixed FPS value rather than auto or variable behavior.
• Check encoder CPU load, dropped frames, and sender logs.
• Use the recommended low-latency encoder settings, including fixed GOP and monotonic timestamps.
• If encoder settings were corrected after the stream had already started, reconnect the encoder so the transcoder starts a new session with the correct FPS metadata.

For encoder settings reference:

• RTMP protocol
• SRT protocol
• PTS/DTS timestamps
• Record live streams

​

Low-latency playback fails on older Smart TVs

Possible cause: LL-HLS and LL-DASH are not supported on many older Samsung Tizen, LG WebOS, and similar Smart TV models.
Suggested solution: Use classic HLS MPEG-TS for maximum compatibility with older devices. Switch to the non-low-latency manifest URL (/master_mpegts.m3u8) for those viewers.

​

Broadcast does not play on some Smart TVs

Possible cause: Some older Smart TV models do not trust the Let’s Encrypt CA used by Gcore CDN resources by default.
Suggested solution: Upload a commercial SSL certificate from a CA trusted by the affected TVs to the CDN resource.

​

MPEG-DASH playback drifts on Smart TVs during long broadcasts

Possible cause: The number-based SegmentTemplate in .mpd manifests can cause clock drift between the encoder and player during long-duration (24/7) streams on Smart TVs, causing segments to fall out of sync.
Suggested solution: Use the time-based SegmentTimeline template in .mpd manifests. This aligns segment requests with the transmuxer clock and prevents drift.

​

HTTP 404 Not Found error

Possible cause: The master stream is missing (not pushed from the encoder), or the initial segments have not been generated yet (transcoding delay).
Suggested solution: Check the X-Err-Code response header for the specific error sub-code. The HTTP status codes guide lists all 404 sub-codes and their meanings.