The Bitmovin API enables you to build cutting edge video workflows while leveraging emmy-award winning encoding solutions, that automatically optimize your catalog for high quality and cost efficient video streaming.
This Quick Start Video will demonstrate 3 different approaches to setup an encoding workflow using either a
- Watch Folder Workflow (No Code Required),
- the Simple Encoding API (Documentation) using a Postman Collection and a
- full Python API SDK example using this Colabortory Notebook.
The following steps will walk you through adding the SDK to an new or existing Project step by step.
Starting an encoding triggers a request for encoding instances. Once available, the input file will be downloaded, divided into chunks, and distributed between all of them. Those instances transcode each chunk into segments for all configured video/audio representations (muxings) in parallel and write them to the designated output destination. This approach makes Bitmovin's encoding the fastest in the world.
In this tutorial you will implement a simple VOD online streaming scenario, where an input file containing a video stream and stereo audio stream is transcoded into ...
- a fixed ladder of 3 video representations at different resolutions and bitrates using the H264 codec, and
- an audio rendition with the AAC codec.
Each individual stream is wrapped into fragmented MP4 (fMP4) containers. HLS and DASH manifests are generated so the encoded content is stream- and playable on the majority of modern devices and browsers out there today.
Add the Bitmovin SDK
Add this to your composer.json:
For the latest version please refer to the GitHub repository or check the changelog of the Bitmovin API. Open API SDK versions and the Bitmovin API share the same versioning.
And then execute:
Initialize a Bitmovin API Client
The Bitmovin API client instance is used for all communication with the Bitmovin REST API, pass your API key to authenticate with the API. You can find your
API_KEY in the dashboard in your Account Settings.
An input holds the configuration to access a specific file storage, from which the encoder will download the source file.
We support various types of input sources including HTTP(S), (S)FTP, Google Cloud Storage (GCS), Amazon Simple Storage Service (S3), Azure Blob Storage, and all cloud storage vendors that offer an S3 compatible interface.
Below we are creating an input. You can change the input type on the top right of the code panel.
Inputs refer to a location, not a specific file.
This makes them easily reusable. Create an input once and reuse it for all your encodings.
Hint: All resources in our API are identified by a unique id which enables you to reuse many resources. So you only have to create one input for each location and can reuse it for all encodings.
Outputs define where the manifests and encoded segments will be written to.
Like inputs, outputs represent a set of information needed to access a specific storage. From this storage players can access the content for playback.
Similar to inputs, outputs also refer to a location, not a specific file.
So they're exactly as reusable as inputs. Create it once and reuse it for all your encodings.
Codec configurations specify the codec and its parameters (eg. media codec, bitrate, frame rate, sampling rate).
They are used to encode the input stream coming from your input file.
Video Codec Configurations
Below we are creating video codec configurations. We support a multitude of codecs, including H264, H265, VP9, AV1 and many more.
For simplicity, we use H264 now, but you can easily change that after finishing the getting started.
Audio Codec Configurations
As audio codec configuration we are creating one AAC configuration.
We also support many more audio codecs including Opus, Vorbis, AC3, E-AC3 and MP2.
Reusing Codec Configurations
As inputs and outputs, codec configurations can also be reused.
To use existing video or audio codec configurations, loading them with their id.
An encoding is a collection of resources (inputs, outputs, codec configurations etc.), mapped to each other.
The cloud region defines in which cloud and region your encoding will be started.
If you don't set it, our encoder takes the region closest to your input and output.
Inputs, outputs and codec configurations can be reused among many encodings. Other resources are specific to one encoding, like streams, which we'll create below.
A stream maps an audio or video input stream of your input file (called input stream) to one audio or video codec configuration.
The following example uses the selection mode
AUTO, which will select the first available video input stream of your input file.
You can choose an input file from 3 predefined examples on the top right of the code panel.
A muxing defines which container format will be used for the encoded video or audio files (segmented TS, progressive TS, MP4, FMP4, ...). It requires a stream, an output, and the output path, where the generated segments will be written to.
FMP4 muxings are used for DASH manifest representations, TS muxings for HLS playlist representations.
Hint: To optimize your content for a specific use-case you can also provide a custom segment length. Further, you can also customize the naming pattern for the resulting segments and the initialization segment as well.
DASH & HLS Manifests
Its recommended to use Default Manifests, one each for DASH (API-Reference) and HLS (API-Reference). They are a construct that leaves it to the encoder to determine how to best generate the manifest based on what resources have been created by the encoding. This simplifies the code greatly for simple scenarios like this guide is about.
Create a DASH Manifest
Create a HLS manifest
Let's recap - We have defined:
- an input, specifying the input file host
- an output, specifying where the manifest and the encoded files will be written to
- codec configurations, specifying how the input file will be encoded
- streams, specifying which input stream will be encoded using what codec configuration
- muxings, specifying the containerization of the streams
- manifests, to play the encoded content using the HLS or DASH streaming format.
Now we can start the encoding with one API call, including additional configuration so the DASH and HLS Default-Manifests are created as part of the encoding process too:
What happens next: After the successful start of the encoding, it will change its state from
STARTED, and shortly after that to
RUNNING it will be in as soon as the input file starts to get downloaded and processed. Eventually
FINISHED will indicate a successful encoding and upload of the content to the provided Output destination. More details about each encoding status can be found here.
Congratulations! You successfully started your first encoding :) and this is only the beginning. The Bitmovin Encoding API is extremely flexible and allows many customizations and provides with access to the latest codecs and video streaming optimizations and technologies out there. Have a look at the API Reference to learn more.
You can find many more fully functional code examples in our Github Repository.