Slot precision

The slot precision is 1 second.

With a 1s precision, this means that if the programming system defines a slot with a start-time, end-time or duration value in milliseconds, the platform will automatically round the time to the nearest second.

If content conditioning has not been performed - or simply is not possible, it may happen that the time value indicated is not falling exactly between HLS or MPEG-DASH segment boundaries. The following sections explain how this scenario would be handled on broadpeak.io.

Management of slot start time between two media segments in HLS

HLS Media playlists directly reflect the media segments through the numbering syntax. Each media segment has a duration, which in most cases, is the same for all media segments.
In the event that the startTime of the slot (or matchTime of the MediaPoint in ESNI) is not exactly falling into media segment boundaries, broadpeak.io identifies the start time of the last segment before the startTime value, and starts inserting the reference to the media segments of the alternate content there.

Example:
Assuming we have an original content whose media manifest reflects a 4-second media segment. This media manifest shows that the last available video segment starts at 12:00:00 and ends at 12:00:04. Here is how the original manifest would look like:

#EXTM3U                                                                                                              
#EXT-X-VERSION:5
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-TARGETDURATION:4
#EXT-X-PROGRAM-DATE-TIME:2022-11-10T11:59:40.000000+00:00
#EXTINF:4, no desc
audio=129117-video=633990-01.ts
#EXTINF:4, no desc
audio=129117-video=633990-02.ts
#EXTINF:4, no desc
audio=129117-video=633990-03.ts
#EXTINF:4, no desc
audio=129117-video=633990-04.ts
#EXTINF:4, no desc
audio=129117-video=633990-05.ts
#EXTINF:4, no desc
audio=129117-video=633990-06.ts

Assuming we also have a programming system which creates a MediaPoint with a startTime at 2022-11-10T12:00:02:456Z.

1. As the precision of the platform is 1s, the recorded startTime becomes actually 2022-11-10T12:00:02:000Z.
2. Also as '2022-11-10T12:00:02:000Z' does not exactly fall at the end of an existing media segment, broadpeak.io then starts inserting reference to media segments of the alternate source at 2022-11-10T12:00:00:000Z. In this case, the latest segment of the original content audio=129117-video=633990-06.ts is replaced by the latest segment available on the manifest of the replacement source.

#EXTM3U                                                                                                              
#EXT-X-VERSION:5
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-TARGETDURATION:4
#EXT-X-PROGRAM-DATE-TIME:2022-11-10T11:59:40.000000+00:00
#EXTINF:4, no desc
audio=129117-video=633990-01.ts
#EXTINF:4, no desc
audio=129117-video=633990-02.ts
#EXTINF:4, no desc
audio=129117-video=633990-03.ts
#EXTINF:4, no desc
audio=129117-video=633990-04.ts
#EXTINF:4, no desc
audio=129117-video=633990-05.ts
#EXT-X-DISCONTINUITY
#EXT-X-PROGRAM-DATE-TIME:2022-11-10T12:00:00.000000+00:00
#EXTINF:4, no desc
../../../../replacement_content/hls/audio=129117-video=633990-190.ts

The example above explains how it works with a single variant, but obviously this mechanism is applied to all the existing variants requested by the player.

Management of slot's start time between two media segments in MPEG-DASH

In MPEG-DASH, the slot precision of 1 second also applies.

The handling of these scenarios in MPEG-DASH is slightly different, as the protocol allows more flexibility with the multi-period syntax. Indeed, in MPEG-DASH it is possible to represent several periods on which media segments can overlap. In the event that the startTime of the scheduled slot ( or matchTime of the MediaPoint with ESNI) is not exactly between the end time of one media segment and the beginning of the next media segment, broadpeak.io sends out a MPD which reflects overlapping segments across two different periods.

We are reusing the previous example where the programming system creates a slot (or MediaPoint in ESNI) with a startTime at 2022-11-10T12:00:02:456Z.

1. As for HLS, the precision of the platform is 1s, the recorded startTime becomes actually 2022-11-10T12:00:02:000Z.
2. Even though '2022-11-10T12:00:02:000Z' timing does not exactly fall at the end of an existing media segment, broadpeak.io represents the alternate content on an another period at 2022-11-10T12:00:02:000Z, which automatically translates to the end of the previous period at the very same timing.

<MPD xmlns="urn:mpeg:dash:schema:mpd:2011" type="dynamic"> 
  <Period id="1" start="PT1668081000.00S"> <!-- Period 1 -->
    <BaseURL>../../../dash/originalcontent/</BaseURL> <!-- path points to original content -->
    ...
    <AdaptationSet ...>
      <SegmentTemplate timescale="60000" presentationTimeOffset="100084860000000">
        <SegmentTimeline>
          <S t="100084860000000" d="120000" r="299" />
        </SegmentTimeline>
      </SegmentTemplate>
      <Representation id="video=991000" ... />
      <Representation id="video=2971000" ... />
    </AdaptationSet>
  </Period> 
  <Period id="2" start="PT1668081602.00S">  <!-- Period 2 -->
    <BaseURL>../../../dash/replacementcontent</BaseURL> <!-- path points to replacement content -->
    ...
     <AdaptationSet ...>
      <SegmentTemplate timescale="60000" presentationTimeOffset="100084896120000">
        <SegmentTimeline>
          <S t="100084896120000" d="120000" r="5" />
        </SegmentTimeline>
      </SegmentTemplate>
      <Representation id="video=991000" ... />
      <Representation id="video=2971000" ... />
    </AdaptationSet>
  </Period>
</MPD>

Note: The manifest above is not a fully functional MPD. Parts of the MPD structure that are not relevant for the example have been omitted.

In the end, it is up to the client to present the latest media segment of the first period fully or only partially.
As MPDs are not always easy to interpret, here is a graphical representation of the example.

For more information, we invite you to check the following section of the DASH-IF implementation guidelines

📘

Note:

The same logic described in this section also applies to the endTime value.

Precision of program duration

The duration of Asset Sources is not always an integer number of seconds, but rather a float that is a combination of seconds and milliseconds. In the case of a content-replacement slot, the duration specified in the API call must be rounded down to the second below.

Example: The duration of a program is 600s and 80ms. In this case, the time to be used as the duration value in the Slot is 600 seconds.

Consequences of slot duration inaccuracy

Below is a description of what would happen if the duration defined in the replacement slot did not exactly match the duration of the replacement asset, or live event.

VOD as a replacement source

If the specified duration is shorter than the total duration of the VOD, the VOD will only be inserted on the specified duration. The end of the VOD will then be truncated.

If the specified duration is longer than the total duration of the VOD, the VOD will only be inserted on the specified duration. The VOD will be looped once it reaches the end, and will start again from the beginning until it reaches the duration specified in the slot.

Live as a replacement source

If the specified duration is shorter than the total duration of the Live event, the replacement Live will only be inserted on the specified duration. The end of the event will then be truncated. Using broadpeak.io, it is possible to extend the duration of an existing scheduled event by updating the existing slot.

If the specified duration is longer than the total duration of the Live event, the replacement Live will be inserted on the specified duration. This means that the content on the Live source will be inserted, even after the end of the actual program. Using broadpeak.io, it is possible to reduce the duration of an existing scheduled event by updating the existing slot.

Scheduling a program in the Past

Creating a replacement slot with an end in the past is now accepted by the API, and will have no effect.
Any replacement slot scheduled in the past with an end in the future will be scheduled and will take effect immediately after the consideration period. The manifest will reference the program where it should be at the time of the streaming.

Ex: A VOD asset of 60 minutes is scheduled at 22/06/2022, 16:00 UTC. The API call is sent at 22/06/2022, 16:30 UTC. When retrieving the manifest at 16:30, the manifest will reference the content of the VOD, 30 minutes, in the VOD content.

Slots consideration and reflection period

When creating or updating a slot, there is a necessary delay for the platform to take into account the information, propagate it and reflect it into the manifest. This delay is 15 seconds.
To translate this into the implementation of the scheduling logic, this means that sending API calls to create or update a slot must be done at least 15 seconds before you want to see the change reflected on the stream.

Example:

• If we want to schedule a program to start at 2022-12-20T16:20:00.000Z, the API call to create the slot must be sent before 2022-12-20T16:05:00.000Z
• If we want to extend the duration of a program which is initially supposed to end at 2022-12-20T16:47:30.000Z, the API call to update the slot must be sent at least 15 seconds before the end of the initial scheduled event, so at 2022-12-20T16:47:15.000Z. The duration value in this call must be extended to the actual new duration.

Working with out-of band trigger (API) on Virtual Channel

We invite you to consult the Ad insertion specifics section