Live pre-roll

In a Live DAI service configured with pre-roll insertion, ads are inserted in the stream at the start of the playback session, acquired from the ad server, if the following conditions are met:

  1. The ad server was called and returned a valid VAST response with one or multiple usable Ads.
  2. The ad creatives were in a format compatible with the source, or were successfully transcoded and packaged into a compatible format by broadpeak.io (assuming that the transcoding option was configured correctly).

The first manifest served to the users will only contain the first few segments of the pre-roll ads. As the player asks for refreshes of the manifest during the session, the size of the manifest increases, with more segments of the ads added, then segments of the live source.

This also means that the DVR window of the source is not retained. The manifest continues growing until the manifests have a similar length to the live source.

No ads

If the ad server does not return ads, or the ads cannot be inserted (whatever the reason), no pre-roll is inserted, and the full stream (with its DVR) is delivered at the start of the session.

Configuration options

The following options that may be useful to refine the ad insertion behavior for live pre-rolls.

Maximum pod duration

Maximum Pod Duration (or via APIs liveAdPreRoll.maxDuration) sets the maximum total duration of ads that will be inserted as pre-roll.

This value can automatically be sent as value to a macro in the ad tag call, to instruct the ad server on how many ads to return.

If the total duration of ads returned by the ad server exceeds this value, then only the first few ads will be inserted, in such a way that the complete pre-roll remains below this limit.

Pre-roll offset

Video players will usually - depending on their buffer management strategy - start rendering a live stream a few segments before the live edge. Usually this is 3 segments by default, but it is often configurable.

Since the first manifest served with pre-roll only contains a few segments of ad, it is normally sufficient to ensure that the player starts playback at the start at the stream. If however you notice that the player is not starting playback at the beginning of the first ad, you can use this option to alter its behavior.

This option (of via APIs liveAdPreRoll.offset) defines the offset between the start time of the first segment in the first manifest and the live edge. In effect, it enables you to control the number of media segments inserted in the first manifest delivered to the player: the value represents a cap (in seconds) on the total duration of segments inserted in the first manifest.

For example, if your ads have segments of 4 seconds, and you set the offset to 12, the first manifest will contain 3 segments of ads.

For best results, you should set this value to a multiple of the source segment duration.

If you do not set this value (or set it to 0), broadpeak.io will fall back onto its default behavior, which is:

  • for HLS: to populate the first manifest with pre-roll segments of an equivalent duration to 2 segments of the live source (as defined by EXT-X-TARGETDURATION).
  • for DASH: to populate the first manifest with pre-roll segments of an equivalent duration to the suggested presentation delay in the live manifest (as defined by MPD@suggestedPresentationDelay)

For example, if your HLS source has 4 sec segments, and the ads have 2 sec segments, the first manifest will contain 4 segments (or 8 seconds)