Normal

doug.jpg

twitter-brands.svg

Doug Twitter

Doug Sillars

Product updates

A year ago, we looked at how [fast videos are encoded](https://api.video/blog/product-updates/video-encoding-rates-2h-2020/) at api.video. Over the past year, we've made huge upgrades to how we store and deliver video, as well as completely revamped our encoding infrastructure.  

In this post, we'll look at how quickly you can expect your video to be ready today, and we'll do some comparisons to our encoding speed 12 months ago.

## **TL;dr** Our encoding pipeline is a LOT faster. The median video encoding time is 20-40% faster over last year. We see even more impressive results at the 95th percentile where we are 48-63% faster year over year.  This means faster access to the videos uploaded for all of our customers and their users.

## Encoding process

When your video is uploaded to api.video, we take the video and create several different versions of the video HLS [adaptive bitrate streams](https://api.video/what-is/adaptive-bitrate-streaming) and a [mp4](https://api.video/what-is/mp4/) version of the video.

The streams will have several different sizes: 240p, 360p, 480p, 720p, 1080p and 2160p.  We'll create versions up to the size of the video uploaded but no larger (so a 720p uploaded video will not have a 1080p or 2160p video).

The mp4 will be the size of the uploaded video (unless the video is 4K, where a 1080p mp4 version will be created.)

Based on data from June - September, we can count each encoded HLS version and determine the size of the original video:



large_encoded-video-size.png

medium_encoded-video-size.png

small_encoded-video-size.png

thumbnail_encoded-video-size.png

encoded-video-size.png



* 80% of videos uploaded are 720p or better, and 50% of all videos are either 1080p or 4K.


## Encoding time

As each version of the video is encoded, we measure the amount of time it took. 

There are two features that determine the encoding time - the size (dimensions) and duration of the video.

### video dimensions
A 240p video has 102,240 pixels in each frame (426x240).  A 1080p video has 2,073,600 pixels in each frame (1920x1080). With fewer pixels, the 240p video will generally encode faster than a 1080p video of the same duration.

### video duration

A video that is 1 minute long and encoded at 24 [frames per second](https://api.video/what-is/framerate-frames-per-second-fps/) will have 1,440 frames to be encoded. A 5 minute long video will have 7,200 frames, and will take longer to encode.

To try to make sense of this, we'll break down the video encoding times by the video's size, and create buckets of lengths, so that when we compare video encoding times, we are looking at videos of similar duration.

## Percentiles

Percentiles allow us to rank our data into even segments that add up to 100 - making comparison across different collections of data easier. The median value is the 50th percentile, or the value that falls exactly in the middle of the data set. In our charts, we'll show 25%, 50%, 75% (quartile data) for the encoding times.  We also will show the 90 and 95th percentiles, as these can give you an idea of the longer times a video might take to encode.



## Short video encoding (under 5 minutes)

Let's take a look at short videos - those that are under 5 minutes long.  we can calculate the tie it will take for each version to be created:



large_video-encode-times-2021.png

medium_video-encode-times-2021.png

small_video-encode-times-2021.png

thumbnail_video-encode-times-2021.png

video-encode-times-2021.png

The black line shows the 50th percentile - or when 50% of videos will have been encoded.  50% of videos will have a 240p version of the video ready in 7.8 seconds, a 720p version in 15.3 seconds, and a 4K in 35s.

95% of videos under 5 minutes will have the 720p video in 85s or less.  Larger sized videos take longer, and the 95th percentile for the 4K videos is 384s.

You can compare these numbers to the data from 2020, and they are very similar - within a few seconds of the data from a year ago.  We have a few tricks up our sleeve to make the next data set faster for these shorter videos.


## Longer video encoding

In order to compare against the data from a year ago, let's look at the encode times for videos 45-75 minutes long.  Note that the 2020 data omits the 4K data, as there were not enough 4k files at this duration to make a good analysis.  Here is the data at the 50th percentile:



large_50thpercentile-encode-data.png

medium_50thpercentile-encode-data.png

small_50thpercentile-encode-data.png

thumbnail_50thpercentile-encode-data.png

50thpercentile-encode-data.png

medium_screenshot-2021-09-27-at-19-57-03.png

small_screenshot-2021-09-27-at-19-57-03.png

thumbnail_screenshot-2021-09-27-at-19-57-03.png

screenshot-2021-09-27-at-19-57-03.png

The encoding for the median video is 21-38% faster, depending on the size of the video. A really nice improvement!

When reporting performance of our service, we want to monitor the 95th percentile - because we want EVERY video encoding to be fast.  In the chart below, we can see that difference between 2020 and 2021 is even larger at the 95% percentile than it is at the 50th:

large_95thpercentileencodingdata.png

medium_95thpercentileencodingdata.png

small_95thpercentileencodingdata.png

thumbnail_95thpercentileencodingdata.png

95thpercentileencodingdata.png

medium_screenshot-2021-09-27-at-19-59-28.png

small_screenshot-2021-09-27-at-19-59-28.png

thumbnail_screenshot-2021-09-27-at-19-59-28.png

screenshot-2021-09-27-at-19-59-28.png

At the 95th percentile, we see that all versions are ~50%-60% faster!  Longer videos that are uploaded to api.video are ready for playback significantly faster than a year ago. The changes to our encoding system is making a big difference in making videos available faster!


## Time as a continuum

We see that video encoding is faster, and we've looked at two data points - short and longer videos.  What can we learn about video encoding times over different periods of time?

Let's look at the 720p data.  720p is often a 'good enough' quality for playback - it may not be as good as 1080p or 4K, but you can start the playback, and most users will be satisfied with the video (and the 1080p and 4K videos will be ready right afterwards, if available).



720p encode times for different duration videos

large_720pencode-data.png

medium_720pencode-data.png

small_720pencode-data.png

thumbnail_720pencode-data.png

720pencode-data.png

This graph gives a good idea on how long you might have to wait after uploading a video before the 720p VOD file will be ready (assuming you know the duration).  For a very quick estimate - if you take the duration of your video in seconds, and divide by 2, over 95% of videos will be encoded by that time.


## Why wait?

api.video's encoding is continuing to improve, and we expect to see more jumps in encoding time in the near future.  Over the last year, we have improved the "waiting game" by introducing [webhooks](https://api.video/blog/endpoints/webhooks/) which will push to your server when each version of your video is encoded.



## Conclusion

Over the last year, we have made significant jumps in our encoding times - meaning that the videos your customers upload to api.video are ready for streaming playback faster than ever before.  We're not resting idly with this improvement - we expect our infrastructure and encoding pipelines to have further improvements as we continue to improve our service in the coming months!

If you haven't seen our lightning fast encoding yet, what are you waiting for - try it yourself by [signing up](https://my.api.video) today!

api.video encoding times: 2H 2021 edition

large_screenshot-2021-10-05-at-09-22-57.png

medium_screenshot-2021-10-05-at-09-22-57.png

small_screenshot-2021-10-05-at-09-22-57.png

thumbnail_screenshot-2021-10-05-at-09-22-57.png

screenshot-2021-10-05-at-09-22-57.png

thumbnail_anne-sophie.jpg

anne-sophie.jpg

Twitter (Anne-Sophie)

Anne-Sophie Poupard

Today is the day - we are proud to officially launch our brand new visual identity!

As excited as we are to unveil our new look, this brand refresh symbolizes a lot more than just a fresh look. Our product, our features, our values, our mission are all reflected in this brand refresh.

A lot has happened over the past two years. It has been an exciting journey, and we have made tremendous progress in building a high-quality, high-performance product and assisting you in developing your own video products. Our recent achievements include: 

* New API Clients: [C#](https://docs.api.video/sdks/api-clients/apivideo-csharp-client), [Go](https://docs.api.video/sdks/api-clients/apivideo-go-client), [Python](https://docs.api.video/sdks/api-clients/apivideo-python-client), [Java](https://docs.api.video/sdks/api-clients/apivideo-java-client)
* [Live streaming](https://api.video/blog/product-updates/live-stream-webhooks-we-ll-tell-you-when-the-stream-starts/) and [VOD webhooks](https://api.video/blog/product-updates/new-feature-video-on-demand-webhooks/)

But one thing hasn’t changed: **our mission to make video accessible to every developer on the planet**.
 
Why the change?
Due to the high technical nature of our business and the complex nature of the industry we serve, it's crucial for us to keep our work simple and clear. Our brand should reflect this as well.
We created our previous logo at an early stage of api.video, when we had 10 people on the team with a goal to make the developers' life easier. The logo was dynamic, and colorful, but it was not representative of who we are and what we do: **video**!

Now we are 30 (and counting!) and our new look reflects the image of our company.

large_api-video-team.jpg

medium_api-video-team.jpg

small_api-video-team.jpg

thumbnail_api-video-team.jpg

api-video-team.jpg

First, we focused on what the current brand was representing and our mission: we are a tech company building an innovative, reliable, and developer-friendly video API. 

How?

Our logo lacked the main element of our product, and this was the first requirement of the brief.
We worked on a very popular symbol, used all over the Web: the play button. 

Yes, a simple triangle.

The new logo was created based on different key messages that combine a unique value proposition. As part of this logo we drew inspiration from the play button to represent video. Other references in this logo include:

* Technical: AV represents inputs and outputs that some of you may be familiar with from your old TVs
* Symbolic: the letters overlay represents the layering of the API
* Geeky: there is a reference to a classic video game (did you spot it?)

large_api-video-logo-process.png

medium_api-video-logo-process.png

small_api-video-logo-process.png

thumbnail_api-video-logo-process.png

api-video-logo-process.png

You shouldn't be constrained by your understanding of video codecs and protocols. Our goal is to enable you to build wildly innovative video experiences more quickly and easily than ever before.

New logo, same mission: Connecting people with video

large_blogimagenewbranding.png

medium_blogimagenewbranding.png

small_blogimagenewbranding.png

thumbnail_blogimagenewbranding.png

blogimagenewbranding.png

New logo, same mission: Connecting people through unique video experiences

small_olivier.png

thumbnail_olivier.png

olivier.png

Olivier Lando

Today, api.video automates all of its clients and general client documentation. It's fast and convenient for developers to get up and running with the language of their choice. But it wasn't always so easy.

## The issue 

By the start of 2021, we had 4 SDKs for the api.video API. We had one for each of the following languages: 
* Java
* Node.js
* Go 
* PHP 

These SDKs had been built by different developers. They worked pretty well but there were some inconsistencies between them, for example: 
* How methods were named
* How the client was instantiated
* What features were included or updated

While we were trying to decide how to handle these inconsistencies, we also decided to meet the demands of our customers by developing two additional SDKs: 
* Python
* C#

We also realized that we wanted to use the correct nomenclature for our clients. While SDK is a popular term, it’s usually misused. A true software development kit is a complete set of tools that facilitates the creation of applications. It’s typically a set of software components that allow you to handle more complex tasks in a particular way out-of-the-box. It can include helper tools for debugging, complete solutions for certain tasks, detailed documentation, different kinds of integration options and more. On the flipside, a client library creates reusable chunks of code you can use as building blocks to do more complex tasks - like the ones you might see in an SDK. We wanted to start using the term clients and made the decision to move to this term rather than SDK. 

With that decision settled, we were still faced with maintenance for our growing list of clients. We realized that maintaining all 6 of the clients plus adding more of them and keeping them in sync with our API was going to be really painful. These considerations led us to question the possibility of generating these API clients automatically, instead of maintaining them manually.

## The envisaged solution

An API client is a pretty simple thing. It’s mostly composed of models reflecting the API payloads, and methods that make the http calls. All this is pretty well described in the OpenAPI description of our API that we already had for documentation purposes. Therefore, we realized that it shouldn't be too strenuous to generate our API clients using the API description.

After a few investigations on how to achieve this, we chose to use the OpenAPI client generator. The reasons were the following:
* OpenAPI generator is widely used, including in large projects
* It supports a lot of target languages
* It’s open source and highly customizable

## Our requirements
Before we got started, we put together our requirements for the new clients. We wanted something that would work well for us and especially our customers. So we came up with this list:

* Ease of use for our customers: Generated clients are often rough and don't handle the small particulars that an API may have. We didn't want the switch to generated clients to make our clients more complicated to use. That means things like authentication, results pagination, efficient upload of huge files using a chunk splitting mechanism, all must be handled seamlessly by the client.
* Release efficiency: One of the goals of having a generated client is to be able to release new versions very quickly. In particular, when a simple change is made to our API (for example adding a new attribute in a payload), we wanted to be able to release a new version of all our API clients the same day.
* Automation: We wanted to avoid manual actions as much as possible between the moment when the API description is updated and when new API clients are released.

## The painful part: building the generator templates

For each target language, the OpenAPI generator uses a bundle of templates of the code files that will be generated. If you want to see what it looks like, you can take a look at the base templates for Typescript here: typescript templates. The templating system used is Mustache. Mustache syntax is really simple (sometimes too simple). 

For each target language, we started from the base templates included in the OpenAPI generator and we updated them to make them match our needs. 
In particular, we had to modify them to:
* Implement our authentication mechanism: the most common authentication mechanisms (OAuth2, basic password)  are handled by most of the template bundle, but ours is based on an exchange of a private API key to an access token was not.
* Handle our video upload mechanism: to improve reliability of huge video files transferred we use a mechanism based on file splitting into chunks. This is a particular use case that is of course not handled in the default templates. 
* Facilitate the use of the endpoints of our API that return paginated results (it must be easy to retrieve the results of the next page)
* Make some client parameters modifiable by the user, such as: the size of the upload chunks, the API environment to use (sandbox or production), etc.

For some of these adaptations, modifying the templates was not enough, we had to go a little further by modifying the code of the generator itself. It’s pretty straightforward, each target language has a dedicated Java class responsible for generating the variables sent to the template engine from the API description. We simply had to write subclasses of these Java classes and put the needed changes in them. 

## The release process before automation

Once the template has been written, generating the code of a client is done by executing a single Maven command. In the weeks following the end of the development of our generator, the process of releasing new versions of the clients after an API change was very manual. It looked like this:
1. The API description was updated to reflect the change made in the API
2. Someone from the Ecosystem tech team launched the generator 6 times on their computer (1 execution per client)
3. For each generated client, the teammate ran the unit tests & integration tests
4. If everything went well, they committed the new code of each client to its dedicated GitHub repository (6 commits)
5. They created a GitHub release on each of the 6 repos
6. They manually released a new package on each package repository (npm.js for javascript, maven for java, pypi for python, etc.)

That was really painful and error-prone, so we decided to automate all of this.

## The release process with automation

In total we have 7 GitHub repositories for our client : 1 for the generator itself, and one per generated client. 

Thanks to GitHub Actions, we have implemented the following process:

When a pull request is made on the generator repository (this happens when the API description itself is updated, or when templates are changed), 6 GitHub actions are triggered on the generator repository: one per client. Each of them will: 

* clone the code of the client from its repository
* launch the Maven command to generate a new version of the client
* if something changed in the code of the client a branch is created on the client repository, a commit is made, and a PR is created



large_update-client.png

medium_update-client.png

small_update-client.png

thumbnail_update-client.png

update-client.png

After this step, is most cases, 6 pull requests have been created: one on each client repository, but it may be less (for instance in we updated the template of the Python client, only the code of the Python client will change and then a PR will only be created on the Python client repository). 

For each PR created, a GitHub action will be triggered on the associated repository in order to run the unit tests and the integration tests. 

If everything goes well (i.e. the tests are not failing), the pull request on the generator repository is merged by someone from the ecosystem team.  That will trigger another GitHub action that will merge all the pull requests that have been created on the clients repository. 

After that we manually create a release on each repository that will trigger the last actions responsible for deploying a new package on each package manager (Maven, npm.js, etc.)

## Links

The client generator: https://github.com/apivideo/api-client-generator

The generator GitHub actions: https://github.com/apivideo/api-client-generator/tree/master/.github/workflows

The generated API clients:
https://github.com/apivideo/php-api-client
https://github.com/apivideo/go-api-client
https://github.com/apivideo/python-api-client
https://github.com/apivideo/java-api-client
https://github.com/apivideo/nodejs-api-client
https://github.com/apivideo/csharp-api-client

## Conclusion 

And that’s everything! We now have an automated solution that lets us keep up with all the new changes to our API while providing clients in the language of choice of our developers. 


Why and how api.video automated all their API clients

medium_possessed-photography-ykw0jjp7rlu-unsplash.jpg

small_possessed-photography-ykw0jjp7rlu-unsplash.jpg

thumbnail_possessed-photography-ykw0jjp7rlu-unsplash.jpg

possessed-photography-ykw0jjp7rlu-unsplash.jpg

## What's .new at api.video?

We've been really busy building the best video streaming API around.  All of our teams are growing to meet the need of the rapid growth going on.  (Interested?  Check out the [careers page](https://api.video/careers/).)

We recently launched [webhooks](https://docs.api.video/reference/create-and-manage-webhooks) that tell your backend when a live stream starts or finishes.  Our video player has undergone a number of [new features](https://docs.api.video/sdks/player/apivideo-player-sdk), and we've launched [a half dozen new API clients](https://docs.api.video/sdks/api-clients/apivideo-csharp-client), a React Native [Live Stream](https://docs.api.video/sdks/livestream/react-native-livestream-component) and [player](https://docs.api.video/sdks/player/apivideo-react-native-player) modules. There's so much more coming that we cannot wait to share with you!

## Why does your post say .new?

Aren't all these features just *new*?

Ahh, yes.  We have also launched a number of domains that showcase one of the basic premises of api.video: uploading videos for video on demand (VOD) playback.  

These all use the Top Level Directory ".new", and utilize the most basic function of api.video - a video upload:

* [embed.new](https://embed.new)
* [ingest.new](https://ingest.new)
* [mp4.new](https://mp4.new)

All of these videos are using synonyms to describe a video upload.

* [Embedding](https://api.video/what-is/embed) a video is the ability to add external video content onto your webpage.  When your video is uploaded to api.video, the JSON response will contain the code for an iframe embed of your video.

* [Ingesting](https://api.video/what-is/ingest) a video is the process of uploading and converting a video for streaming on demand.  All videos uploaded to api.video are ingested and made into [HTTP Live Stream (HLS)](https://api.video/what-is/http-live-streaming-hls) videos for responsive and optimized playback.

* [mp4](https://api.video/what-is/mp4) is the most common format of video on the web.  In the case of api.video, when you upload or ingest a video, you'll have a playable h.264 mp4 video ready to be shared in addition to the HLS video stream.

When you use these sites to upload a video, you'll see the progress of the video ingestion into api.video. Upon completion, get a JSON response of the completed upload, and retrieve links for an iframe *embed* and *mp4* playback.

After a few seconds, you can also refresh the video, and see the video on demand video stream right from the page:

large_screenshot-2021-08-09-at-21-06-11.png

medium_screenshot-2021-08-09-at-21-06-11.png

small_screenshot-2021-08-09-at-21-06-11.png

thumbnail_screenshot-2021-08-09-at-21-06-11.png

screenshot-2021-08-09-at-21-06-11.png

Give our demos a try, and if you like what you see, they all have links to the code on GitHub, so you can copy and reuse for your application. All you have to do is add your api.keys and delegated upload tokens to ensure the videos end up in your [api.video](https://api.video) account.

Finally - you might see all the links that point to definitions in this post. We're building a [video glossary](https://api.video/what-is) to help you navigate all the terms that are sometimes thrown about when working with video on the web.

What's ".new" at api.video

small_dotnew-1.png

thumbnail_dotnew-1.png

dotnew-1.png

In the early 2000s, most educational content creators used tools such as Adobe Captivate, Camtasia, or even PowerPoint to create independent e-learning materials. It was tedious and used a fair amount of bandwidth. By 2010, most web-based applications dominated. That's when LTI connectors began appearing. LTI is a standard aimed at delivering a single framework for integrating any LMS platform with third-party applications.

In this post, we will focus on the connection with Moodle LMS.


## What is an LTI?

LTI stands for Learning Tools Interoperability. It enables third-party tools to integrate into an LMS (Learning Management System), such as Moodle or Blackboard, without the students realizing they are interacting with another tool. LTIs provide a direct connection, so content and courses can be updated dynamically. Think about the LTI connector as a universal cable that can connect with all kinds of devices.


## Why do you need an LTI Connector for video?

Without an LTI connector, each time you need to add a video, you will need to upload a video in another tool, such as api.video, and then copy and paste the iframe into your LMS. 

If you try to upload a video file directly in a program like Moodle (without using a service like ours), there would be no transcoding. Streaming would dramatically slow down the page, and if too many students try to watch simultaneously, the video will probably fail.

The LTI connector lets you view, upload, publish, search, and share video directly in your LMS environment. Api.video's connector makes it easy for teachers to share content quickly and improve learners' engagement by having adaptative streaming with high-quality videos.

**The benefits**

For institutions:
* LMS infrastructure won't be negatively impacted by video hosting and streaming bandwidth demand.
* Only one interface is needed to add videos and create a course, keeping the end-user processes simple.
* All user management is handled by your LMS, no need to worry about access restrictions in another tool.
* You benefit from the LMS tracking analytics on video activities.

For LMS editors:
* It provides a native video streaming feature
* No development work is needed.



## How to use the LTI connector with your Moodle LMS?


Few simple steps:

1. Log in to your Moodle LMS as a contributor or an administrator

2. Choose the course you want to add your video content

3. Click on "Add an activity or resource" and go on the api.video LTI Connector 

4. Then click on "select content" to choose content from your library. there you will have access to your existing uploaded videos, or you can add a new one from your computer.

5. You can customize the title, the description, add a tag or make your video downloadable if you want your students to get the video source.

6. Save it and it's done! Your video is available to be watched!

Here is a step by step demo to add a video content to your Moodle LMS:


If you have any comment or question, don't hesitate to [contact us](https://api.video/contact/).

LTI connector to integrate your videos into Moodle LMS

large_pexels-julia-m-cameron-4144222.jpg

medium_pexels-julia-m-cameron-4144222.jpg

small_pexels-julia-m-cameron-4144222.jpg

thumbnail_pexels-julia-m-cameron-4144222.jpg

pexels-julia-m-cameron-4144222.jpg

Use the LTI connector to easily integrate your api.video videos into Moodle LMS

webhooks

When your application is managing a number of live streams (or live streamers), it might be tricky to keep tabs on which streams are live at any given time. The [List all livestreams](https://docs.api.video/reference/api/Live-Streams#list-all-live-streams) endpoint will give a list of the streams, and you could parse the ```broadcasting``` attribute: true - the stream is live: false - the stream is not live.

But polling an endpoint is less than optimal, so we have just released new webhooks that will push this information to your server.  The 2 new webhooks for live streaming status are:

1. ```live-stream.broadcast.started```  A livestream has begun broadcasting.  The body of the message will look like:

```
{
	"type": "live-stream.broadcast.started",
	"emittedAt": "2021-01-29T16:46:25.217+01:00",
	"liveStreamId": "liXXXXXXXX"
}
```
 
	This data says - hey this livetream with liveStreamId "lixxxxxxx" has began broadcasting - you can now perform tasks to make this live stream visible.  
>Note: This webhook fires when the broadcast has just started. It will take a few seconds for the video to become encoded and be available for playback for your viewers. If you use the api.video player url, the player will refresh for 20s, giving plenty of time for the livestream to establish streaming and appear to your viewer.

2. ```live-stream.broadcast.ended``` Like all good things, a livestream will eventually end. This webhook will fire when the last bit of video has been encoded (typically a few seconds after the streamer has actually stopped streaming).  The body of this message looks like:

```
{
	"type": "live-stream.broadcast.ended",
  "emittedAt": "2021-01-29T16:46:25.217+01:00",
	"liveStreamId": "liXXXXXXXX"
}
```

Now your application logic can remove this stream from your users.


## Creating a Live Webhook

Using the [Create Webhook](https://docs.api.video/reference/api/Webhooks#create-webhook) endpoint, you can establish the URL where the webhooks will be sent. Here is an example using curl:

```
 curl --request POST  --url https://ws.api.video/webhooks   --header 'accept: application/vnd.api.video+json'  --header 'authorization: Bearer <api_token here>' --data '{"events": [
		"live-stream.broadcast.started", "live-stream.broadcast.ended", "video.encoding.quality.completed"
	], "url": "https://webhook.a.video/receive_webhook"
}'
```

https://webhook.a.video/receive_webhook is the url that will get the updates on live streaming (and also on video encoding quality). If you guessed that [https://webhook.a.video](https://webhook.a.video) has a demo showcasing these webhooks, you'd be correct.  To start a livestream - visit [record.a.video](https://record.a.video) or [livestream.a.video](https://livestream.a.video), and start a livestream.  You'll see the webhook alert that the livestream has *started* at the bottom of the list.  When you end your livestream, you'll see the *ended* notification a few seconds after you stopped (after all of the video has been processed).  As the video is recorded into VOD, you'll also see the quality encoding completed alerts. ([read more about the quality.encoded webhook](https://api.video/blog/product-updates/new-feature-webhooks/)).

## Other Livestream Webhooks

We have 2 additional features in our webhooks that help simplify live stream management - mainly if you record your livestreams for [video on demand](https://api.video/what-is/vod-video-on-demand) playback.  

1. ```video.source.recorded```  The live stream has completed, and the recording is ready to be transcoded. Note: this does not tell you that the recording is ready for playback, only that recording/transcoding is starting, and the videoId where the recording of the livestream will be stored.  The webhook message appears as:

```

{
	"type": "video.source.recorded",
  "emittedAt": "2021-01-29T16:46:25.217+01:00",
	"liveStreamId": "liXXXXXXXX",
  "videoId": "viXXXXXXXX"
}

```

2.  ```video.encoding.quality.completed``` - our VOD webhook - now lists the liveStreamId in the response (if the video's source is a live stream).  This webhook notification will tell you when each VOD quality has been encoded.  You'll get the videoId (as before), but if the video is a recorded live stream, you'll also get the liveStreamId:

```
{
	"type": "video.encoding.quality.completed",
  "emittedAt": "2021-01-29T16:46:25.217+01:00",
	"videoId": "viXXXXXXXX",
  "liveStreamId": "liXXXXXXXX",
	"encoding": "hls",
	"quality": "720p"
}
```

## Conclusion

We're very excited about our new live streaming webhooks - we've had several customers ask for them over the last few months, and we know it will make the managment of multiple live streams a lot easier.  If you are using our webhooks for your livestream management - drop us a note on our [community page](https://community.api.video) and let us know how they work for you.

Live stream webhooks: We'll tell you when the stream starts

large_stream-63820101280.png

medium_stream-63820101280.png

small_stream-63820101280.png

thumbnail_stream-63820101280.png

stream-63820101280.png

medium_screen-shot-2021-01-26-at-11-48-47-am.jpg

small_screen-shot-2021-01-26-at-11-48-47-am.jpg

thumbnail_screen-shot-2021-01-26-at-11-48-47-am.jpg

screen-shot-2021-01-26-at-11-48-47-am.jpg

Erikka Innes

UPDATE: Stay tuned! We'll be back with our contest later this year, after summer vacation and holidays. The contest is post-poned for now. 

api.video is hosting its first contest! We want you to build the coolest thing you can think of with api.video’s API in the language of your choice. To make things easier, we’ve recently released brand new clients to make coding fast and simple. Try one of our clients in [Go](https://docs.api.video/sdks/api-clients/apivideo-go-client), [Java](https://docs.api.video/sdks/api-clients/apivideo-java-client), [C#](https://docs.api.video/sdks/api-clients/apivideo-csharp-client), [Python](https://docs.api.video/sdks/api-clients/apivideo-python-client), [PHP](https://docs.api.video/sdks/api-clients/apivideo-php-client) or [NodeJS](https://docs.api.video/sdks/api-clients/apivideo-nodejs-client). 

[Official Rules / T&C](https://url.video/contestrules)

## What are the judging criteria? 
We will choose the most creative and inspiring implementation of the API, in whatever language you want to program in. Bonus points for Haskell! (Kidding.) 

Each project must include: 
* You must use api.video’s API 
* Upload your project to Github
* Provide a readme file explaining what your project does and how to set it up
* Video demoing or describing your project (you don’t have to appear in it if you don’t want, you can just show off what you’ve made if you prefer)

### Main categories 

Below is the breakdown of the three criteria we will evaluate you on. You can score 0-5 points in each of the following:

**Overall idea / originality:** Is the hack more than just another generic social/mobile/local app? Does it do something entirely novel, or at least take a fresh approach to an old problem? How good and original is the idea? Does it solve a real problem? Usually fun and even silly ideas are good at hackathons but more arbitrary things that nobody gets score low.

**Technical execution:** Is what the participant created hard to do? Does it use cutting edge technology in combination with api.video? Is the project technically feasible? Is the hack technically interesting or difficult? Is it just some lipstick on an API, or were there any technical challenges to surmount when building it?

**Viability:** Is the hack practical? Is it something people would actually use? Does it fulfil a real need that people have? While there is no need for a business plan for the project, the audience and the problem / solution  should still be clearly defined. 

### Bonus points 

You can score additional 2 bonus points for any of the following: user experience, design and polish. Is the hack usable in its current state? Is the user experience smooth? Does it work as the creators say? Is it well designed? Our judges will see and/or want to use your prototype - so make sure it works!

## How do I sign up? 

* You must have an api.video account. If you don’t have one, sign up by going to [https://my.api.video/register](https://my.api.video/register). Follow the steps to create your account.

* Register for the contest with this form here [https://url.video/contest](https://url.video/contest). 

Within 24 hours of when you sign-up for the contest, we’ll give you a $15 credit for an api.video production account. The credit is good for the duration of the contest. 

## When does the contest start and end? July 15th-22nd

The contest starts Thursday, July 15th. The contest lasts for one week, you have until midnight Thursday, July 22th. Because the competition is open to anyone around the world, you may submit by midnight in your timezone. We post the contest results to the forum and the blog on July 28th.

## Where / What do I submit? 

When you are ready to submit, do these things: 
* Post your project on GitHub. 
* Include a readme describing your project, how to set it up, and any other information people will need to understand what you create. 
* Add a video of yourself describing your project! Or if you don’t want to be on camera, a demo of your project. We’d love to see/hear you talking about your work and what inspired you to put this together.
* Send an email to our Developer Relations team at **devrel@api.video** with a link to your project. Include any details or feedback about your experience developing.  

## What can I win?

**1st Prize**: $250 Amazon gift card*, $10 [Open Collective](https://opencollective.com/) gift card to donate to the open source project of your choice and a write up in our blog interviewing you about your project and $75
api.video credit.

**2nd Prize**: $150 Amazon gift card*, $10 Open Collective gift card to donate to the open source project of your choice and a write up in our blog interviewing you about your project and $50 api.video credit

**3rd Prize**: $100 Amazon gift card*, $10 Open Collective gift card to donate to the open source project of your choice and a write up in our blog interviewing you about your project and $25 api.video credit.

**Honorable Mention**: $10 Open Collective gift card to donate to the open source project of your choice, post in our blog interviewing you about your project and  $15 api.video credit.

* Or comparable gift card depending on your location
  

Be part of api.video's first online contest! 

small_blog-preview-a.png

thumbnail_blog-preview-a.png

blog-preview-a.png

Be part of api.video's first online contest! We're looking for the most creative and inspiring implementation of our API

api.video is proud to announce a brand new PHP client for our video API. Our old PHP SDK will be deprecated. You can continue to use it, but it will no longer be updated. Instead, the new PHP client will stay up-to-date with all our new feature releases. 

Like our other clients, it's autogenerated and handles authentication for you, including refreshing your access token when needed. It also handles paginated responses and chunked uploads for large files. A unique aspect of this client is that it is also [PSR-18](https://www.php-fig.org/psr/psr-18/) compliant. This makes it more reusable as it reduces the number of dependencies and lowers the likelihood of version conflicts.

You can install our new client with:
```composer require api-video/php-api-client```

And the entire client is available in the GitHub repository here: 
[https://github.com/apivideo/php-api-client](https://github.com/apivideo/php-api-client)

In addition to the documentation we have at docs.api.video, you can find client-specific documentation in the GitHub repository. If you are looking up parameters, we recommend that you refer to the content provided in the client respository first. Some information may be tweaked to make it easier to create and use the client. There's a docs page for each part of the API here: [https://github.com/apivideo/php-api-client/tree/main/docs/Api](https://github.com/apivideo/php-api-client/tree/main/docs/Api) 

PHP is fast, flexible and widely used in web applications. We hope you'll enjoy using our new client to code your video projects! 



api.video announces a new PHP client

large_php.png

medium_php.png

small_php.png

thumbnail_php.png

php.png

NodeJS

The SDKs for api.video make it easier to get started building with our tools.  Abstracting all the authentication and taking care of a lot of the connections for you, our SDKs help you plug and play api.video into your codebase quickly.  Historically, our most popular SDK has been our NodeJS SDK. 

That said, we had some limitations in our Node SDK: 

* search results included EVERY result without pagination.  This is great if you expect only a few results, but for our power users, this meant thousands of results, slowing the response time, and making parsing difficult.  We wanted to upgrade our SDK to allow for better search results.
* The analytics endpoint was not easy to use (mainly due to above, and a lack of filtering options).

We also had many requests for a TypeScript SDK using the api.video APIs.

When we took all of this feedback to the ecosystem team, they created a new [API Client for NodeJS and Typescript](https://github.com/apivideo/nodejs-api-client).  Our old SDK is still here and not going anywhere, but it is also no longer going to be updated, and all future features will be incorporated into the API client.  There are not that many changes between the two, so a migration will not be that hard (and we've created a [migration guide](https://github.com/apivideo/nodejs-api-client/blob/main/doc/MIGRATE.md) to make it even easier for you!)


New NodeJS/Typescript API Client

small_screenshot-2021-06-03-at-08-23-46.png

thumbnail_screenshot-2021-06-03-at-08-23-46.png

screenshot-2021-06-03-at-08-23-46.png

Python

For all our Python programmers out there, it's finally happened! api.video is releasing a Python client! The repository is here: [https://github.com/apivideo/python-api-client](https://github.com/apivideo/python-api-client). And we invite you to submit code sample showing you use the client to the examples folder here: [https://github.com/apivideo/python-api-client/tree/master/examples](https://github.com/apivideo/python-api-client/tree/master/examples).

It's our first time releasing a Python client, so let us know what you think of it. What do you like about it? What could be improved? We're all ears! 

Our client allows you to make requests with or without threading, depending on your project. It also handles chunked uploads for large files, pagination, and authentication. You'll be able to use everything in api.video's API through the Python client.

Python is an incredible choice when it comes to working with video. Enthusiastic fans of FFMPEG have created many Python bindings you can use to work with FFMPEG directly in your code instead of just at the command line. And you're able to access the powerful OpenCV libraries via Python bindings if your project involves the use of real-time computer vision. 

Python is also a great choice because it's popular, robust, easy-to-learn and well documented. There are many excellent frameworks and libraries that can help you complete all kinds of tasks, and Python is regularly used for big data and machine learning projects. These are often complimentary to video projects, especially if you want to build something like a ratings or recommendation system, or collect analytics about your video content. 

It's a very flexible language, that compliments other languages well. For web applications, you'll find that many use Python for the back end and JavaScript for the front end. These combinations are also well documented, so if you're a newcomer, it's easy to get started. If you're a seasoned developer, there's also lots of details for advanced implementation.

We hope you'll enjoy using the new Python SDK and share your projects with us. Happy coding!

Try api.video's new Python client!

medium_pythonclientapivideo.png

small_pythonclientapivideo.png

thumbnail_pythonclientapivideo.png

pythonclientapivideo.png

Try api.video's new Python client! 

codec

video create

small_cedric.jpeg

thumbnail_cedric.jpeg

cedric.jpeg

Cédric Montet

At api.video, our goal is for video to be easy and affordable for anyone to build, be it individuals or organizations. We understand that achieving this goal means reducing costs at some stage of the video streaming process. That’s why, we now offer adaptive bitrate encoding for your videos at zero cost. 

&nbsp;

Yes, you heard me right. 

&nbsp;

**Encoding videos will be absolutely free for all video qualities (1080p or 4K) at [api.video](https://api.video/) - no hidden calculations, footer notes or tricks.**

(Check out this [video](https://www.youtube.com/watch?v=ouosgLbW7Ts) for more details) 


## A step towards making video streaming affordable

Video encoding is crucial as it makes it possible for videos to be shared and played smoothly on the internet. It is why we are easily able to consume various types of video media, whether it’s a YouTube video, our favorite shows on Netflix, or even catching up with friends across the globe on Zoom. Video encoding basically makes the world go around in regards to anything related to video and video content.

&nbsp;

We at api.video recognize that. From [increasing the transcoding and playback speed ](https://api.video/blog/product-updates/2021-in-review/)to building [specialized hardware like ASICs](https://api.video/blog/video-trends/the-comeback-of-specialized-hardware/) cards to increase our transcoding capacities, we've been working to make video streaming easier for you every day. And after dedicating ample time to engaging with our customers and learning about their concerns, free encoding seemed to be the next step in this direction. 

&nbsp;

So, we worked tirelessly behind the scenes to give you what no one else will - free encoding for all video qualities, be it 360p or 4K. 

## How does free video encoding benefit you as a customer

The benefit is straightforward: you save a LOT of money!

&nbsp;

- With free video encoding, you will have one less thing to worry about. As you know, you pay for three things for streaming videos — encoding, hosting, and delivery – out of which encoding is the most expensive, especially if you have a lot of videos. Free video encoding will allow you to focus your attention and resources to what is most important.

&nbsp;

- As the video needs of your app users grow, you might need to scale up your encoding capacity. Free video encoding services will give you the power to scale without any additional costs, meaning your users can handle more videos without increasing your expenses.

&nbsp;

- You can [migrate from your previous provider to api.video](https://api.video/compare/azure-media-services/) without paying an ‘entry tax’ to us. With free video encoding, you no longer need to spend money on encoding videos with a new provider when you have already paid for encoding with an older one.

&nbsp;

Now with all the saved cost, you can allocate your resources and money to a place where it is actually important – building your product and delighting your users. 

## How to get started

To use the free video encoding benefit, getting started is easy. 

&nbsp;

- If you’re a new user, [sign-up](https://dashboard.api.video/register) for a free sandbox account and start uploading your videos
- If you are looking to migrate from another vendor, [import](https://import.api.video/) your videos from your current vendor
- If you have any questions, [talk to us](https://meetings.hubspot.com/diego398/cc-talk-to-us?__hstc=54467703.754940701eda85e3c99a902d8ab0b988.1687266643206.1694417789132.1694427271479.149&__hssc=54467703.3.1694427271479&__hsfp=3654297906) by booking a slot in our calendar

&nbsp;

To know more about our[ features](https://api.video/features/), [pricing](https://api.video/pricing/) or ask any other questions, [talk to our team ](https://meetings.hubspot.com/diego398/cc-talk-to-us?__hstc=54467703.754940701eda85e3c99a902d8ab0b988.1687266643206.1694162373815.1694167498585.144&__hssc=54467703.1.1694167498585&__hsfp=3654297906)and we will help you out. 

&nbsp;

Or, you can straightaway [sign-up](https://dashboard.api.video/register) for a free sandbox account and check our product out for yourself. 


Huge pricing update: Introducing video encoding at no cost

large_Blog_Zero Cost (2).png

medium_Blog_Zero Cost (2).png

small_Blog_Zero Cost (2).png

thumbnail_Blog_Zero Cost (2).png

Blog_Zero Cost (2).png

api.video team

Video trends

Modern technology has been helpful for an increasingly fast and simple method of consuming various types of video media, whether it’s a YouTube video, our favorite shows on Netflix, or even catching up with friends across the globe on Zoom. Despite the relative ease of doing anything related to video, a few complex processes take place behind the scenes, away from public view. One such process is video encoding.

Video encoding basically makes the world go around in regards to anything related to video and video content. Thanks to the technologies behind the video encoding process, it has become much easier for people and companies to share video content on the internet. But what exactly is video encoding, and what happens during the process? We’ll take a closer look at this and much more in this handy guide to video encoding.

## What is video encoding?

In a nutshell, video encoding occurs when you take raw video footage, either from a digital camera or an analog film camera, and digitally compress it to make it a more manageable file size. Video encoding happens daily in both professional and personal capacities, and many people don’t realize it.

But, without encoding, services like Netflix and YouTube would not exist – or, at least, not in the same way that it does today. Without it, we couldn’t send videos of our beloved pets to our friends and family as easily as we can today.

## Why is video encoding used?

There are a variety of reasons why video encoding is used, but all factors point to the single function of video encoding – **compression**.

This is done to ensure optimal performance and compatibility with a selected suite of software and hardware, be it for DVD/Blu-ray playback, mobile viewing, online video streaming, or general video editing. A file's video and audio information undergo transformation and compression during the encoding process, all in accordance with the requirements of the selected encoding standard.

On a professional level, the ability to compress raw video into more manageable sizes makes it easier to transmit video content such as training, promotion, presentation, and so on over the internet. 

On a personal level, video encoding makes it much easier to send videos taken from your phone directly to friends and family. Most modern-day personal devices have built-in video encoding capabilities to allow for this to happen without a second thought.

To put things in perspective, uncompressed or unencoded video can have a data rate that’s as low as 3,000 Mbps and as high as 12,000 Mbps, depending on the length and quality of the video recorded. 

**Without encoding, it would take up to days for anyone to not just transmit video, but to be able to consume it, too.**

## Differences between video encoding and video transcoding

You need to be familiar with two more [essential terms related to video encoding](https://api.video/what-is/) – transcoding and codecs.

Transcoding relates to the conversion from one digital encoding format to another. It takes the already encoded video file, decompresses it, and then alters it before re-encoding or compressing it into a different codec. Codecs are what allow encoding to occur in the first place. They are software or hardware that gives us the ability to compress video to make them more easily stored and delivered tightly.

While you may hear “encoding” and “transcoding” used interchangeably, the two terms actually mean different things. Putting it succinctly, encoding is the initial process of compressing a video from a source – such as a camera – into a codec, while transcoding takes an already encoded video file to convert it into a different codec.

## Examples of video codecs

In order to understand video encoding, you must first be familiar with two interrelated terms: [video codecs and video formats](https://api.video/blog/product-updates/every-video-format-codec-and-container-explained/). These also tend to be used interchangeably, but much like the terms encoding and transcoding, they refer to two different things.

Video formats are the type of files in which the compressed video/audio is stored. Also known as a “container”, you can tell what a video format is by looking at the file’s extension — the three to four characters that sit after a period in a file name. Here are some of the most common video formats used today:

* MP4
* FLV
* MOV
* MKV
* LXF
* MXF
* AVI
* WebM
* QT

On the other hand, **the codec is short for “Coder / Decoder” (compression / decompression)** and relates to the video compression algorithms that allow encoding to happen. Over the years, codecs have gone through multiple iterations as it coincides with the increasing sophistication and rise in the quality of filmmaking. 

If you’re a content creator, you might be aware of some of the video codecs that exist today:

- **H.264 – also known as AVC, this is the most widely-used video codec available on every platform and mobile device.**
- H.265 – also known as HEVC, stands for High-Efficiency Video Coding, and it’s slowly overtaking H.264 as the standard. This codec can compress video much more efficiently than its predecessor.
- **VP9 – is an open-source, royalty-free codec developed by Google and is considered the direct competitor of H.265. The video compression codec VP9 was created to reduce file sizes, making streaming videos simpler.**
- **AV1 – is another royalty-free, open-source codec released in 2019 by the non-profit Alliance for Open Media. It was developed to become the successor to Google’s VP9 and contend with HEVC more directly.**

## How do different technologies handle video encoding

As you may have suspected, there are a majority of ways that different technologies handle the video encoding process. Let’s take a look at the most common technologies that use video and how video encoding works on each of them:

### Video editing software

When it comes to video content creation, a majority of people will use one of two video editing software — Adobe Premiere Pro or Apple’s Final Cut Pro. Both of these video editing software handle video encoding in very similar ways: when exporting the finished video.

Depending on which device the video content is recorded on, it will already be encoded and formatted according to the settings of the device. For those using iPhones recording 1080p video at 25 frames per second (FPS), for example, the iPhone will automatically encode the video using H.264 and contain it in a .mov file format. The video editing software will “open up” the container to get to the encoded, compressed video file within so the editing process can begin.

After editing the footage is complete, it will need to be exported, which typically concerns video encoding. The edited raw media taken from a recording device such as a camera will be encoded via the codec of the person’s choosing before being put into a .mp4 container once they’ve hit “export”. As we’ve mentioned before, the most common codec used in video content creation is H.264 for HD videos, with 4K videos using H.265. 

### Websites

Different websites utilize different techniques to handle video encoding – with a majority of the major sites like YouTube, Netflix, and so on using their own technologies to handle the process. A majority of social media websites allow you to upload video files directly onto the site to share, although most of them require the files to be saved in specific containers. 

These websites will take your video file and transcode it before using their own systems and serves to re-encode it to match multiple display resolutions. This process will happen regardless of your video file's original codec and settings. Different websites have different processes, but companies that don’t have the capacity to build their own video encoding systems can use a third-party application programming interface (or API) to handle this process. These APIs act as [dedicated video encoder](https://api.video/encoding/) that allows companies to add on-demand videos to their websites more efficiently.

Using [api.video](http://api.video) as an example, all of the videos submitted to the platform will be transformed into H.264 codec in an MP4 container. This may be done using transmuxing and/or transcoding.

We expect the video bitrate to be lower than 16 Mbps for up to 1080p resolution and 50 Mbps for up to 4K resolution. We accept any bitrates, however, we will scale them down to the limits mentioned because anything above is usually challenging for most viewers’ connection to watch.

### API

The ability to generate, store, and distribute video is made possible via a video API. [api.video](http://api.video)’s solution can be tailored to suit any specific need. 

The backend process of video on demand (VOD) is exceptionally complex, even if you’re a software programmer specializing in video. It is necessary to encode, package, and typically transcode the data before sending it to any of several possible destinations. All of these things, and more, may be done with minimal fuss using api.video.

Our API basically keeps the complexities of streaming media hidden from view, so you can rapidly develop apps with as much control as you need. This saves time and effort so developers can concentrate on making the product.

## Conclusion

As you can see through this video encoding guide, a lot of work goes into making the video you watch and the video you share possible. Without video encoding compressing raw video footage, it could take days to upload and transmit video content over the internet and perhaps even longer to be able to download and enjoy them. 

The best part about encoding at api.video is that is offered at ZERO cost. You will only be charged for delivery and hosting of your videos, and the encoding will be free. Now integrate your videos in minutes with api.video or [contact us](https://api.video/contact) for more information.

A Guide to Video Encoding & Video Codecs

large_poster-3.png

medium_poster-3.png

small_poster-3.png

thumbnail_poster-3.png

poster-3.png

Encoding and transcoding are often used interchangeably but they have slightly different definitions. **Encoding is the initial process of converting raw video files into a specific digital format or codec.** It involves compressing and packaging the video data, often to reduce file size while maintaining acceptable quality. Encoding prepares the video for storage, transmission, or playback.

&nbsp;

**Transcoding, on the other hand, involves converting a video from one digital format or codec to another.** This is typically done to optimize the video for different devices or platforms, adapt to varying network conditions, or ensure compatibility with specific playback requirements. Transcoding occurs after encoding and often involves changing resolution, bitrates, or formats without altering the content itself.

## What goes on behind encoding a video?

It's easy to say that encoding is when you go from an _uncompressed source_ to a _compressed source_, but you may ask, what exactly do compressed and uncompressed sources mean?

&nbsp;

Uncompressed sources are video files that contain data that comes directly from a camera sensor vs. encoded video. In the digital space, it's SDI (Serial Digital Interface) or HDMI (High Definition Multimedia Interface). Both of them are popular standards. You'll find HDMI in places like your GoPro camera, or a mini camcorder. These days, you might also find HDMI in professional settings, but SDI is more common due to its reliability. Another example of an uncompressed source would be something analog, for instance, VHS tapes.

&nbsp;

A compressed sources, on the other hand, are video files that have undergone compression during the encoding process. Compression involves reducing the file size by removing unnecessary information or encoding the data in a more efficient format. This process results in a smaller file size, making it more manageable for storage, transmission, and playback.


## What are the types of transcoding methods?

There are three types of transcoding, depending on what you are trying to do to get a video to suit a particular browser, player, or platform:

* **Lossless-to-lossless** - This type of transcoding maintains the quality of your video across formats but allows you to take advantage of better hardware or compression algorithms. 
* **Lossless-to-lossy** - This type of transcoding will decrease your video in quality, but it will benefit you in ways such as – you will get a smaller and/or faster playing file, or a file that is compatible with the requirements of a particular platform, player, or browser.
* **Lossy-to-lossless** - Sometimes people think this means they are regaining quality. This isn't the case in this type of transcoding. If you transcode from a lossy format to a lossless format, all that it means is that you will not lose additional quality in the conversion process. You will not regain data you already lost through compression.

## Codecs for encoding and transcoding

For both encoding and transcoding, you will need to make use of codecs. A codec's job is to compress and decompress video files. It's right there in the name -  **co**mpress **dec**ompress or encode decode. So basically, codec is an algorithm that takes the video and shrinks it or changes it into a format that makes it compatible with the requirements of wherever you want the video to play. There are many codecs because there are many ways to compress a video or livestream for playback.



## What is transmuxing?

Now that you know the difference between encoding and transcoding, let's throw one more term in there - transmuxing. Transmuxing is when you change the container for a video instead of the format. It's a way of repackaging a video to make it compatible somewhere without changing what's in the file. 

&nbsp;

This process is faster than encoding or transcoding and takes less computing power because you only change the container, not the file. It's great when you need to quickly make something available, but the downside is that it doesn't handle things like making multiple video resolutions available. If you choose a container type that's incompatible with your video file, you may also cause compatibility issues, resulting in not being able to play the video.

## In closing

* **Encoding** - Encoding happens when you compress a raw data file from a video camera sensor or an analog source like a VHS tape. 
* **Transcoding** - Transcoding happens when you take an already compressed video file and change it to another format.
* **Transmuxing** - Transmuxing happens when you change the container of a video file but leave the video file untouched. 

We hope that explains the difference between encoding and transcoding clearly. 

_If you are looking for an affordable video API solution that does not burn a hole in your pocket for transcoding and encoding videos, check out our offerings on our [homepage](https://api.video/) or [sign-up for a free account here](https://dashboard.api.video/register)!_

Encoding and transcoding: what's the difference? 

Encoding and Transcoding - What's the Difference?

large_encoding-and-transcoding-whats-the-difference.jpg

medium_encoding-and-transcoding-whats-the-difference.jpg

small_encoding-and-transcoding-whats-the-difference.jpg

thumbnail_encoding-and-transcoding-whats-the-difference.jpg

encoding-and-transcoding-whats-the-difference.jpg

Once I upload my video, how quickly will it be ready to be viewed?

Our reply to this question has always been “it's really fast.”  And it is really fast. But, the dev team gave me access to the backend database, and pointed me to a few tables that might be helpful (thanks to Thomas Persohn for your patient help!)

Thus armed, I waded into a sea of data to better understand how fast our videos are encoded at api.video

## Encoding

When a video is uploaded to api.video, it is re-encoded to a HLS stream, with several different video dimensions and bitrates.  This allows api.video to deliver properly sized video to all users - no matter the device or network connection. (Read our post on [Responsive video delivery](https://api.video/blog/video-trends/responsive-video-delivery/) to learn more.)

> Summary:  All videos are encoded at 240p, 360p, 480p, 720p, 1080p and 2160p. However, the videos are only encoded up to the initial size of the video (so if the original video is 720p, there will not be 1080p or 2160p versions available). 

**FYI:** For our customers, encoding is absolutely free – we offer adaptive bitrate encoding at zero cost. 

How long does this step take? If a customer uploads a video to our service - they want to know how efficient api.video creates the content for viewing.

### Data in the study

We are constantly making adjustments to our infrastructure to speed the encoding step of our video (and that is one reason this post is dated 2H 2020 - we expect to be faster in early 2021). The last major adjustment was made in mid October, so the data presented in this study from every video uploaded to the api.video service between 15 October and 2 December 2020.

### Parameters that affect encoding

There are 2 major parameters that affect the speed of encoding a new video stream: the output dimensions and the length (duration) of the video.  

#### Dimensions

The output video dimensions have a huge impact on video creation - a 3840 × 2160 (or 4K or 2160p) video has millions more pixels than a 320x240 (240p) video, so it takes a lot longer to create.  In general, the videos exit the encoding process from smallest to largest.

#### Duration

If a video is 30 frames per second, and is 60 seconds long, there are 1800 frames to be created.  If a 30 frame per second video is an hour long 3600s), there are 108,000 frames to be created, so the longer the video - the more time for creation.

## Analysis

To better understand the encoding time, I divided the data by the size of the output video size, and looked at 2 lengths of video  - those under 5 minutes, and videos that are 45-75 minutes long (we are often asked how long a 1 hour video takes to encode).

I calculated encoding time for each bucket of video using percentiles.  

> Quick review - percentiles break the data into 100 evenly sized segments, so the 25th percentile is when 25% of the videos have been encoded. The median is the 50th percentile, and is when 50% of videos have been encoded.  We report here to the 95th percentile for video encoding.

### Short videos - under 5 minutes long

Many of the videos uploaded to api.video are short - under 5 minutes long.  These videos are generally ready to play in a few seconds:



The above chart has a lot of data, the 25, 50, 75, 90 and 95th percentile encoding times for all 6 variants of the video that api.video creates.

The median video is ready to play (at 240p) in 5.6 seconds, but a 720p version will be ready in 15s after encoding begins, and the 4K version will be ready in 37 seconds.

95% of all videos (under 5 minutes) will be playable in 32.6s, and will have 1080p versions ready in just over 2 minutes (140s).

### Long videos - 45 - 75 minutes long

Our most frequently asked question on encoding is "how long for a 1 hour video to be encoded and ready?"  Here are the numbers:


Observant viewers will see there are no 4K videos in this report. At this time, there are very few 4K streams that reach the 1 hour timeframe, and the data was quite noisy.  Hopefully, more of our 'long uploads' will add 4K support, so we can add this metric in our next update.

The median hour long video (red line) will be ready to play (at 240p) in just over 9 minutes (555s), and a 720p version will be ready about 18 minutes after encoding begins (1099s).

95% of hour long videos will have a 240p version ready in 33 minutes, and 720p in 54 (3230s).  the 1080p version will be available for 95% of videos in 108 minutes,

## Conclusion

Short videos will be ready to play - even at high resolution - in under a minute: the median 4K encoding for a short video is 37s. 

Hour long videos take longer to encode, and the median 720p video will be ready in 18 minutes.  95% of 720p videos will be ready to play in 54 minutes.

This is really fast! You can have responsive streaming video ready for your customers in just a few minutes with a simple upload!

That said, our team is working hard in the background to improve our infrastructure to make our encoding speeds even faster! 

We're really excited to have hard numbers to share with you on our encoding speeds, and we cannot wait to re-benchmark this data in 2021 to see how much faster your videos will be encoded as we improve our service.

Do you have questions about api.video or video encoding? Reach out on our [community page](https://community.api.video).


How fast does api.video encode video? 2H 2020 data

medium_gif.jpg

small_gif.jpg

thumbnail_gif.jpg

gif.jpg

Huge pricing update! Introducing video encoding at zero cost

Featured article

# api.video blog

Blog

Follow the api.video Blog to explore tutorials, video use cases, and learn about on-demand and live-streaming video updates.

api.video Blog

Video on demand

Live streaming

Analytics

See all features

Online learning

Short-form videos

Marketplace & E-commerce

Video messaging and recording

Quick start guides

Documentation

Ecosystem catalog

Clients & SDKs

Community

Blog

Demos

Help center

Blog

Huge pricing update! Introducing video encoding at zero cost