Management of PDT not synchronized with current time

Some of our customers have Live sources with a PDT (Program-date-time) that is not synchronized with the current time.

We have lifted the requirement to have the origin Manifest (PDT) synchronized with the wall clock. From now on, Manifest PDT can run behind or in front of the wall clock.

Addition of new IPs to whitelist

We continue to extend our infrastructure, which means we ask potentially for our customers to whitelist additional IPs in case of any geo-fencing or whitelisting at the Origin level.

Please check our Platform Access page for the list.

Service tagging

You can now tag services with custom values (a-z, 0-9, - and _) in order to categorize your services (by environment, customer, project..). The configuration happened via API in creation/update of services:

Note: tags replaces former environmentTags property (that has been deprecated).

Or you can use our web app to define tags on services (at the "Input" step):

You can now filter your consumption by tags:

Addition of new IPs to whitelist

We continue to extend our infrastructure, which means we ask potentially for our customers to whitelist additional IPs in case of any geo-fencing or whitelisting at the Origin level.

Please check our Platform Access page for the list.

Enable/disable ad replacement in the past

In your Live Ad Replacement services, you can now select whether you want to activate or de-activate replacement in the past inside the DVR window of your manifests.

You have the choice between no replacement of ad breaks at all, the replacement of the full DVR or just a specific duration in the window .

The configuration happened via API in Live Ad Replacement in creation or update of services:

or on the web app at the source edition step, when you activate the Ad Replacement

Convert source/ad segments to absolute URI

You can now change the default way media segments are referenced in manifests, using relative or absolute URLs or even adding a prefix in the segment’s path location.

More details are specified in a Knowledge Center (you will notice that this has been mostly developed for Dynamic Ad Insertion applications) article.

The configuration happened via API in advanced options in creation or update of services:

or on the web app at the source edition step, when you click on “More options”:

Flexibility in ad insertion

We now provide more flexibility in terms of ad insertions.

Originally, if the ad marker duration was 15 seconds and the ad returned by the ad server was 15.2 seconds, the insertion was not performed. This was creating a loss in monetization that some of our customers were not willing to take.

Starting today, we allow a certain threshold so the ad (or pod of ads) can be inserted when it runs longer than the break duration. The web app and the API allow you to input a threshold value for Ad Insertion services.

For the web app, you will be able to configure that at the Ad Insertion service edition step:

Custom headers to origin servers

You can now set one or more custom headers (name and value) that will be sent in the manifest requests to the sources. This is typically used as an authorization mechanism by the origin servers.

This applies to:

• Live sources
• Asset sources
• Asset catalog sources
• Ad server sources (ad origin)

In the WebApp, this is available in the "More options" section of the source creation and edition pages.

In the API, please see the origin / customHeaders parameters (e.g. create live source API).

This is also available when validating a source (More options).

The players in the preview page automatically add these custom headers to the requests, so that you can keep watching these sources and the services that use them, even when these headers are required by the origin servers.

Please see below a screenshot of the service creation page of the WebApp showing the custom header configuration fields:

Authorization headers

You can now prevent unauthorized access to your broadpeak.io services by requiring each request to contain a specific http header.

When definining your service, you may specify an optional header name and an associated value.

All incoming requests for your service will be checked and any request that doesn't have the proper name and value will be answered with a 403 Forbidden response, with the following payload: "Incorrect or missing authorization header".

The player of the service preview page will automatically send the authorization header so that you can watch your service.

Please see our API reference (advancedOptions / authorizationHeader)

See below a screenshot of our WebApp showing the authorization header in the "More options" section of the service edition page.

API key scopes

We have added scopes to our API keys. You can now create API keys that have limited rights on specific API endpoints.

Please see below a screenshot of the WebApp showing the addition of scopes during the creation of an API key.

By default all scopes are added.

You can also have a look at the API key creation endpoint