AAMP Buffering, Underflow Handling and Stall Detection

Default gstreamer (pipeline) buffering for devices that don't support 4k:

• 4096k for video
• 512k for audio

 Above is tripled on 4k capable devices, i.e. XIONE, XClass, Sky Glass, xg1v4 and xi6), giving:

• 12288k for video
• 1536k for audio

Additionally, there is some segment based application-managed buffering done outside gstreamer.                

• For 4k playback, the average 2s 4k fragment size is ~4096k
• This gives 6s (worst case) buffering in gstreamer, to complement the 3-fragment (6s) application-managed buffering, for 12s of buffering in all.

• For non-4k playback, the biggest video fragments are typically under 1024k
• This gives 8s (worse case) buffering in gstreamer to complement the 3-fragment (6s) application managed buffering, for 14s of buffering in all.

• There is some additional more modest lower-level buffering in gstreamer feeding the video and audio decoders.

If buffered content runs try, AAMP player receives “underflow” events from gstreamer, and will report buffering state upstream. If new content is injected and playback is able to resume with short timespan, playback can resume automatically without much user impact (except for temporary freeze).

If underflow state persists, with repeated underflow (or pts error) events, an automatic "internal retune" is triggered as attempt to recover.

bool internalReTune;  /**< Internal re-tune on underflows/ pts errors*/ default: true

int ptsErrorThreshold; /**< Max number of back-to-back PTS errors within designated time*/ default 4

Independently we have "native stall detection" that can bubble up an error, with below default configuration:

#define DEFAULT_STALL_ERROR_CODE (7600)       /**< Default stall error code: 7600 */
#define DEFAULT_STALL_DETECTION_TIMEOUT (10000)   /**< Stall detection timeout: 10sec */JavaScript Player Platform handles these events by switching to an alternate CDN (when available).

Some additional detail, for scenarios where IP connection is lost completely:

For Linear

• AAMP downloads the fragments directly, so AAMP will hit Curl error 7 (or 28, just a probability), these will be marked as failed fragments
• While playlist refresh, since it will cause curl error 7 or 28, we will set the flag mNetworkDownDetected. This will prevent sending a stall detection error to application.
• We will wait in this state until network is restored. Operator UI App will retrigger a playback based on persistent channel info.

For FOG-Linear (separate component involved with review buffer)

• AAMP downloads the fragments through FOG. Above logic is also in-effect here, but the behavior depends on how FOG responds for playlist download when network is down

For VOD

• VOD will not depend on stall detection. When network goes down, all subsequent fragment and playlist download fail
• AAMP has a logic for max segment download fail count (default:10), when thats hit it will send an error AAMP_TUNE_FRAGMENT_DOWNLOAD_FAILURE to application.
• mNetworkDownDetected will be set here also, but we have fragments available in case of VOD, hence error will be sent.