Skip to main content
Common issues you may encounter when working with Live Streaming, as well as steps you can take to troubleshoot them.

​
Current broadcast contains DVR chunks of the previous broadcast

Possible cause: The broadcast is over, but the stream has not been stopped.
Suggested solution: This is a normal behavior. To avoid this situation:
  • Stop the stream when the broadcast is finished.
  • Delete the DVR archive before starting a new broadcast.

​
Low-latency streaming is buffering

Possible cause: Perhaps end-user’s public internet speed and quality aren’t sufficient to download data in a timely manner. Suggested solution: For such users, provide an alternative viewing experience: display /master_mpegts.m3u8 link (HLS non-low-latency manifest URL from UI) in your player or add an attribute ?no_low_latency to our built-in player. Read more:

​
Manifest is empty and stream is not working

The stream is sent to ingester normally, ffmpeg or OBS show correct info. But the manifest .m3u8 is empty and the stream is not shown. Possible cause: The master stream is being sent with network problems, or the encoder settings are set incorrectly. Suggested solution: Our low latency solution has a latency of 4-5 seconds. If the delay is more than 5 seconds: Check the graphs for the relevant stream in your personal account under “Monitoring.” Frames per second, Interval between key frames, and Bitrate should be stable. If you see breaks in the graph, this means your stream is being sent from your encoder with issues. Check your encoder’s latency and settings. See the relevant sections in the documentation:

​
Picture is falling apart

When you see this picture, it means there is packet loss in the network from your encoder to our ingester. Picture is falling apart Possible cause: Packet loss during delivery from your encoder via SRT. Suggested solution: Try sending from another network of another provider, and also reduce the bitrate of the master stream plus set SRT latency explicitly. Read more about latency in section SRT Latency. And validate that PTS/DTS values in the master stream follow a continuous and monotonic timeline PTS/DTS timestamps.

​
Restream failed

Each social platform 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 the destination platform’s specifications; otherwise, the remote side may reject the connection or terminate the stream during broadcasting. When troubleshooting restreaming, always remember that when restreaming, your master-stream is multipied as is without transcoding. So verify your master-stream parameters to match the requirements of the target platform. In many cases, connection refusals or stream instability occur because of mismatched keyframe intervals, unsupported codecs, or exceeding bitrate thresholds. We collected some common cases on our page Restreaming troubleshooting

​
Stream is frozen or buffered

When the player stops and starts showing running dots or a clock. Possible cause: Packet loss during delivery from your encoder via RTMP. Suggested solution: Try sending from another network of another provider, and also reduce the bitrate of the master stream. Advanced solution:
  • Read more about recommended input parameters in section Input parameters. Set et the minimum specified values ​​or even lower (You won’t lose much quality, but you’ll still get the broadcast).
  • Verify that your master stream is configured with the recommended low-latency encoding parameters. See section RTMP.
  • Validate that PTS and DTS values in the master stream follow a continuous and monotonic timeline PTS/DTS timestamps.