Stream lag or jump forward solution

Encoders should detect that current RTMP packets are lagging behind or jumping forward in the timestamp. This condition might happen due to many reasons, such as:

  • Network connectivity issue between an encoder and our Entrypoint/Ingest;
  • Exhaustion of CPU and memory resources on the encoder;
  • Encoder bugs.

If the stream lag/jump forward is greater than the configurable number of GOP sizes (default should be 2 GOP sizes), an encoder should take the following actions if it detects such condition:

  • TCP disconnect and reconnect all renditions/bitrates in that adaptive bitrate session
  • Drop all data from the time that the timestamp lag or jump forward is detected until the current time when connection has been re-established
  • Restart the stream at the GOP boundary
  • Resend all stream initialization information on a reconnect such as onMetadata, if video is H.264 encoded then video sequence headers, if audio is AAC-encoded then audio sequence headers.

If this feature is not available on the encoder there is a setting per stream on the our ingest system that can be enabled to do the above from the ingest system - the ingest will detect the lag and disconnect all renditions assuming the encoder reconnects all of them. The lag amount required to disconnect the stream is configurable on the ingest.

This has been seen to work well for transient network loss/latency issues. If the degradation is ongoing for a longer period, then this would result in frequent disconnections and reconnections.