Following the series of articles “Detailed Explanation of Live Broadcasting Technology”, we have launched this new series “Troubleshooting of Live Broadcasting Complicated Diseases” to share the experience of solving live broadcasting problems step by step. At the same time, some basic knowledge and optimization experience of audio and video development will be intermixed, hoping to help developers in the field of live broadcasting.

Topics covered in this series include, but are not limited to, the following:

  • Playback failed
  • Live caton
  • The first is slow
  • High latency
  • Out of sync
  • Severe Mosaic
  • Play black screen, splintered screen and green screen
  • Play noise, noise, echo
  • Drag on demand is not correct
  • Direct heat problem
  • Other questions (to be continued)

This is the ninth article in the series of “Live intractable Diseases Investigation”. We focus on the problem of inaccurate dragging when playing videos.

Phenomenon of the problem

During playback, after dragging the progress bar, the actual playing position is far different from the position when you release the drag.

Troubleshoot problems

Since the live stream is generated and transmitted in real time and cannot be dragged, this problem mainly occurs in “vod” or “local file” playback.

1. Basic concepts

First, we need to understand the fundamentals of player dragging: video is made up of a series of image frames, each with a corresponding time stamp. Drag, is to tell the playback of a timestamp, it directly jump to the specified frame to start playing.

Drag time = (Progress of the progress bar/maximum progress bar 100) x Total video duration

2. The interval between key frames is too large

Since the decoder must start decoding at frame I to avoid screen splintering, the player will typically look for the keyframe closest to the seekTo video frame and start decoding from that keyframe. Assuming that the key frame interval (GOP) is 3s, the time points of key frames are arranged as follows:

0s, 3s, 6s, 9s

If you drag it to 4s, the player will jump to the 3s key frame and start decoding. Therefore, certain errors will be generated.

The larger the interval between key frames, the larger the error. Therefore, in order to support dragging more accurately, it is recommended not to set the keyframe interval too large.

3. Lost frames during live broadcast

Frame loss mostly occurs in live broadcast scenes. Due to network jitter or lack of memory at the anchor end, some video frames have to be discarded. In order to ensure that no splintering occurs after decoding on the client end, frame loss is often accompanied by the discard of an entire GOP.

When GOP is lost, the interval time of some key frames will become larger, resulting in inaccurate dragging.

To avoid this situation, it is recommended that dynamic bit rate be enabled on the stream push end. When the network is not good, the bit rate can be actively reduced to quickly send out the accumulated video frames in the buffer, thus reducing the occurrence of frame loss.

Recommended reading: Detailed explanation of live video technology