On This Page

Get Status of Dynamic Ingest Requests (Legacy Ingest)

Product(s)

Video Cloud

Role(s)

API Developer

Task(s)

Add Videos/Assets

Topic(s)

Notifications

API(s)

Dynamic Ingest API

When you use the Dynamic Ingest API to add videos to your Video Cloud account, what you most want to know is when the video has been processed and whether or not renditions were successfully created. This document explains how you can do that using Dynamic Ingest API notifications. We also provide a sample dashboard app that automates the process.

Getting the data

The Dynamic Ingest notifications give you all the information you need to know when your video is ready - you just need to know what to look for...and to define what "ready" means for your systems. This diagram summarizes the workflow:

Ingest Status Workflow

Dynamic Ingest Notifications

The Dynamic Ingest notification service sends you notifications for several kinds of events. The three that are most useful for figuring out when the video is "ready" are ones indicating that particular renditions have been created, ones indicating that a manifest has been created, and the one that indicates that all processing is complete. Here are examples of each:

The videoId value lets you know which video the rendition is for (in case you have multiple ingest jobs running)

The profileRefId value is the reference id for the rendition specified in the ingest profile

if the status value is "SUCCESS", the rendition was created successfully

For a segmented type like HLS or MPEG-DASH, the existence of the rendition does not make it playable - you also need the appropriate manifest (see the next example). MP4 renditons are playable as soon as they are created.

The videoId value lets you know which video the rendition is for (in case you have multiple ingest jobs running)

The profileRefId value is a special code that tells you that the asset created was an HLS manifest (the other possible values are HdsManifest, DashManifest, and SmoothIsmManifest)

For HLS and HDS, one manifest will be created, so you will see one notification. For DASH and SmoothIsm, two manifests are created (one for use in the legacy Media API, the other for the CMS API), so you will see two notifications of this type.

If the status value is "SUCCESS", the manifest was created successfully

For a segmented type like HLS or MPEG-DASH, there is no definite order for the creation of the renditions and manifest - these renditions are not playable until both are created (or the video has been fully processed - see the next example).

Sample Dashboard

This section explains how notications can be put together to build a simple dashboard for the Dynamic Ingest API. The handler for notifications parses notifications from the Dynamic Ingest API to identify processing complete notifications. It then adds the video notifications into an array of objects for each video in a JSON file. The dashboard itself is an HTML page that imports the JSON file to get the notification data. It uses the ids to makes a request to the CMS API to get the video metadata. You can view the dashboard here.

All the files for this app, along with instructions for setting it up for your account, are in this repository.

Here is the high-level architecture of the app:

Ingest Dashboad Architecture

The app parts

The handler for notifications is built in PHP - it looks for processing complete notifications and adds the video id to an array in a separate JavaScript file:

There's a design choice to be made here: you can use the notification handler or the dashboard (or a combination of the two) to process the notications and extract the useful information. In this kind of app, we prefer to keep the notification handler simple, just using it to pass on the notification data, and let the client app (in this case the dashboard) do the information processing. This requires more processing on the client, but make the notification handler more reusable.