Video upload

webhooks

Normal

doug.jpg

twitter-brands.svg

Doug Twitter

Doug Sillars

large_api-video-blog-tutorials.png

medium_api-video-blog-tutorials.png

small_api-video-blog-tutorials.png

thumbnail_api-video-blog-tutorials.png

api-video-blog-tutorials.png

Tutorials

JavaScript

NodeJS

Video bumpers are small video intro and exit scenes added to a video to help the viewer understand what they are about to watch.  The intro 'bumper' often has a title or description of the video that is to follow, and the outro 'bumper' provides a call to action on what the viewer can do next - now that they have watched the video.

At api.video, we add bumpers to many of our videos to provide context and a subject for each video, and the end bumper provides a 'call to action' after the video has been watched.

Adding bumpers to your video makes your video appear more polished, as an editing step was taken to add these to the raw video you recorded with your camera (or screen sharing tool).  It is often a manual task in your video editing software.

In this post, we'll automate the task of adding bumpers to a video recording.  We'll use the [Shotstack API](https://shotstack.io/) to add the bumper image and text titles to the front and end of a recorded video.  The completed video will then be uploaded to api.video, and be ready to play in seconds - removing several manual steps from the creation of your training videos!

You can also check out the API reference documentation for the endpoints used for this project: 
* [Webhooks](https://docs.api.video/reference/api/Webhooks#create-webhook)
* [Video status](https://docs.api.video/reference/api/Videos#retrieve-video-status-and-details)

## The "old way" of adding bumpers:

1. Create slides in Google Slides for the intro & outro
2. Take screenshots of the slides
3. Import the screenshots into iMovie
4. Add them to the video timeline
5. Encode the video
6. Upload the video to api.video


The downsides to this: 
Steps 1-4 are all manual, and are repeated for each video that I create.
In steps 5&6 there is a lot of waiting.  

## The "new way": bumper.a.video

Add images, text and video to a web form. Click "upload." The video will upload and have the bumpers added automatically - with no manual work, and (what seems like) a lot less waiting.



Let's see how it is built!


## Ingredients for the demo

* [api.video account](https://dashboard.api.video/register)
* Background image: a 16:9 image suitable for the background

large_bumperbackground.png

medium_bumperbackground.png

small_bumperbackground.png

thumbnail_bumperbackground.png

bumperbackground.png

* Watermark image.  In this demo, we'll use the api.video logo. It is sized to 100x100 pixels to fit properly on the video. The image is also transparent to ensure that there is no white "background" on top of the video.

logoorange100.png


* 4 Text fields

  * Intro title
  * Intro 2nd title
  * Outro title
  * Outro 2nd title


## The tools used in this demo

### Shotstack

The Shotstack API is a video editing API. You can splice together videos, add watermarks, and add text into your video using their API.  We'll use this API to create our bumpers:

1. Upload a background image (we use the same image for both bumpers)
2. Add a title and a 2nd title for both bumpers (text fields)
3. Add a watermark in the upper right corner for the entire video.

### api.video

The initial video will be uploaded to api.video. Once the mp4 has been produced, it is sent to Shotstack for 'bumper work.' Once the video with bumpers has been created via the Shotstack API, we will re-add the completed video to api.video, and provide a playback url.


## Creating the video

Once you hit 'send' on the form at bumper.a.video, a lot of action takes place:

1. The 2 images are uploaded to bumper.a.video/images.  Shotstack requires that the images be publically available on the internet for the api to process them.
2. The video is uploaded to api.video.  For security reasons there are a few steps in this process:

   * The node server makes 2 calls to api.video: creating a delegated token and a videoId (with the name & description provided by the user). 
   * A delegated token works as a public API token for upload only.  
   * Sending this and the videoID back to the browser, we can use the api.video [JavaScript uploader](https://docs.api.video/sdks/vod/apivideo-typescript-uploader) to securely upload the video to api.video.
3. Once the video is uploaded - a message appears to the user, and a button appears to update the status of the processing.

Now that the video has been uploaded to api.video, the rest of the work is done between the Node server, api.video and Shotstack. 

1. Shotstack requires a publically available video URL for processing the video.  We use the ```video.encoding.quality.completed``` [webhook](https://docs.api.video/reference/api/Webhooks#create-webhook) to monitor the creation of the videos at api.video. When the webhook alert tells us that the mp4 version of the video has been created, we know that the mp4 file is ready.  Now we can request the api for the URL of the mp4 (to send to Shotstack).
2. In order to build the bumpers correctly, we also need the duration of the video uploaded. The [video status](https://docs.api.video/reference/api/Videos#retrieve-video-status-and-details) endpoint tells us the duration of the video in the metadata section of the response.

### Creating the call to Shotstack

The Shotstack API works like an onion with many layers that must be defined to create a full video: 

Every video has a ```timeline``` that defines the overall video.

Each ```timeline``` has one or more ```tracks```.  Tracks sit atop one another (in our case, we will have a watermark track sitting atop the video track).

Each ```track``` has one or more ```clips```.  The clips are bits of video/text or images that have specific durations inside the track.

Each ```clip``` has an ```asset``` that defines the clip - this could be a string of text, or an image or a video file.



large_screenshot-2021-09-30-at-17-10-37.png

medium_screenshot-2021-09-30-at-17-10-37.png

small_screenshot-2021-09-30-at-17-10-37.png

thumbnail_screenshot-2021-09-30-at-17-10-37.png

screenshot-2021-09-30-at-17-10-37.png

There are two tracks that play the length of the video - the watermark track - which has a single clip for the single image asset.

the code for this (using the NodeJS SDK) looks like this:

```
let watermarkAsset = new Shotstack.ImageAsset;
							watermarkAsset.setSrc('https://bumper.a.video/images/'+wmpath)
						//watermark to run full video 
						let watermarkClip = new Shotstack.Clip;
							watermarkClip.setAsset(watermarkAsset);
							watermarkClip.setPosition("topLeft");
							watermarkClip.setOffset({"x": 0.05,"y": -0.05});
							watermarkClip.setOpacity(0.5);
							watermarkClip.setFit("none");
							watermarkClip.setStart(0);
							watermarkClip.setLength(4+duration+4);
```

The clip is used to set the location - in this case the top left - with a bit of (x,y) adjustment, the opacity (50%), and how long the clip should play.

Since the intro and outro are 4 seconds, and the video has length ```duration``` - we set this clip to appear for the entire video.

The main track of the video has many clips (and assets).  Both the intro and outro have background and 2 text assets each, and the middle section has just the video clip/asset.

Shotstack does not like having clips with identical times. That means I cannot add the titles at the same moment as the background image. I could have perhaps placed the text items into different tracks to overlay the background - and then had them all start at the same time.  Instead I have the background appear, and then add each bit of text every 100ms:

```
						let titleIntroTextAsset =new Shotstack.TitleAsset;
							titleIntroTextAsset.setText(introTitle);
							titleIntroTextAsset.setStyle('chunk');
							titleIntroTextAsset.setColor('#ffffff');
							titleIntroTextAsset.setSize('x-large');
							titleIntroTextAsset.setPosition('center');
						let titleIntroClip = new Shotstack.Clip;
							titleIntroClip.setAsset(titleIntroTextAsset);
							titleIntroClip.setStart(0.1);
							titleIntroClip.setLength(3.9);

						let titleIntroTextAsset2 =new Shotstack.TitleAsset;
							titleIntroTextAsset2.setText(introTitle2);
							titleIntroTextAsset2.setStyle('chunk');
							titleIntroTextAsset2.setColor('#ffffff');
							titleIntroTextAsset2.setSize('large');
							titleIntroTextAsset2.setPosition('bottom');
						let titleIntroClip2 = new Shotstack.Clip;
							titleIntroClip2.setAsset(titleIntroTextAsset2);
							titleIntroClip2.setStart(0.2);
							titleIntroClip2.setLength(3.8);
```

The main text asset is present from 100ms into the video to 3.9s, and the secondary text asset is present from 200ms to 3.8s.  It looks kind of cool, as if they are boomeranging in and out, so I kept it this way.

The video clip in the middle has the volume set to 50%. It starts at 4s, and has a length of ```duration``` seconds.

```
						let videoAsset = new Shotstack.VideoAsset;
							videoAsset.setSrc(mp4Url);
							videoAsset.setVolume(0.5);
						let videoClip =  new Shotstack.Clip;
							videoClip.setAsset(videoAsset);
							videoClip.setStart(4);
							videoClip.setLength(duration);
```


All of this data is sent to the Shotstack API, and it begins processing the video - adding the watermark and the bumpers.

Once the video is completed (the Node server polls every 2s to get an update), a new video at api.video is created, using the source URL from Shotstack:


```
	function updateApiVideo(url){
							//ok so the video is created at Stostack
							const videoCreationPayload = {
								title: title, // The title of your new video.
								description: descr, // A brief description of your video.
								source: url, // If you add a video already on the web, this is where you enter the url for the video.
								
							}; 
							finalUpload =  client.videos.create(videoCreationPayload);
							finalUpload.then (function(finalVideo) {
								console.log(finalVideo);
								var finalvideoId = finalVideo.videoId;
								var finalPlayerURL = finalVideo.assets.player;
								console.log('finalvideoid',finalvideoId);
								console.log('finalPlayerURL',finalPlayerURL);
								//res.send(finalPlayerURL);
								videoProgressJson.finalVideoId = finalvideoId;
								videoProgressJson.finalPlayerURL = finalPlayerURL;
								videoStatus(videocreationList, videoId);



							});
						}
```

Finally - we use the same video encoding webhook we used earlier to wait until the 720p version of the video is ready for playback (looking for the new videoID, and the HLS version at 720p resolution).

The user - back on the webpage, can click the "update status" button and track this process.  The update status reports:

* Initial mp4 created
* Shotstack id
* Shotstack status
* New api.video videoID
* Final video at 720p

When the last item reports true - we add a link and embed the new video right onto the bumper.a.video page.

## Conclusion

Automating the mundane tasks we run regularly makes life easier. In this demo, I identified a process that was very manual - creating video bumpers for demo videos.  I used [api.video](https://api.video) and [Shotstack.io](https://shotstack.io) to automate the process, and thereby making the creation of video demos faster and easier!

If you have any questions or suggestions, please share them on our [community forum](https://community.api.video). If you still need to create your api.video account, you can do that in just a few moments by following [this link](https://dashboard.api.video/register). Happy building! 

Add bumpers to your video with bumper.a.video

large_bumperavideo-1.png

medium_bumperavideo-1.png

small_bumperavideo-1.png

thumbnail_bumperavideo-1.png

bumperavideo-1.png

video create

When our API has completed a video upload, the response contains all of the URLs you will need for playback:


```
"assets": {
          "iframe": "<iframe src=\"https://embed.api.video/vod/vi4blUQJFrYWbaG44NChkH27\" width=\"100%\" height=\"100%\" frameborder=\"0\" scrolling=\"no\" allowfullscreen=\"\"></iframe>",
          "player": "https://embed.api.video/vod/vi4blUQJFrYWbaG44NChkH27",
          "hls": "https://cdn.api.video/vod/vi4blUQJFrYWbaG44NChkH27/hls/manifest.m3u8",
          "thumbnail": "https://cdn.api.video/vod/vi4blUQJFrYWbaG44NChkH27/thumbnail.jpg",
          "mp4": "https://cdn.api.video/vod/vi4blUQJFrYWbaG44NChkH27/mp4/1080/source.mp4"
      },

```

Of course - the video has only **just** finished uploading. It needs to be transcoded into a video stream for playback. If you try to open the player URL, you'll get an error saying the video is not ready yet.

It's just like a false start in a race - you're ready to go - and you want to show the video to your users, but you show the link too soon - and it doesn't work. Disappointing all around. :(

You can see this for yourself at [upload.a.video](https://upload.a.video).  Upload a large file, and then click the "watch here" link. If you're fast enough, you'll get the error. (Our encoding keeps getting faster though!!)

"task failed successfully" windows "error"

small_windowserrorremixt.jpeg

thumbnail_windowserrorremixt.jpeg

windowserrorremixt.jpeg

## No more errors

No one wants to see an error. And we want to show off your new video to everyone ASAP. In order to ensure that the video is ready to playback (and avoid the false start), we can use api.video's [webhooks](https://docs.api.video/reference/api/Webhooks#create-webhook).  More specifically, we're interested in the ```video.encoding.quality.completed``` notification.

The response for this notification looks something like:

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

For each video uploaded, you'll get a webhook alert for each version of the video created. This adds a new wrinkle (or a new feature) to how we can display the video:




medium_quote-admiral-farragaut-upon-entering-mobile-bay-damn-the-torpedos-full-speed-ahead-david-farragut-143-46-25.jpeg

small_quote-admiral-farragaut-upon-entering-mobile-bay-damn-the-torpedos-full-speed-ahead-david-farragut-143-46-25.jpeg

thumbnail_quote-admiral-farragaut-upon-entering-mobile-bay-damn-the-torpedos-full-speed-ahead-david-farragut-143-46-25.jpeg

quote-admiral-farragaut-upon-entering-mobile-bay-damn-the-torpedos-full-speed-ahead-david-farragut-143-46-25.jpeg


* **As fast as possible (and damn the torpedoes!)**: Each video size is released as soon as it is encoded. Since the 240p video is the smallest video (in terms of pixels and KB), it is typically the first video encoded.  With this option, as soon as the 240p version of the video is encoded - play the video.  The downside is of course that the quality at 240p is less than ideal on most screens.


thumbnail_keep-calm-and-wait-for-it-400-400-black-white.jpeg

keep-calm-and-wait-for-it-400-400-black-white.jpeg


* **Wait for the nicest version**:  Only release the video when the 1080p version is released.  That way, you know that your viewers will have the best quality experience (but being a much larger video - it may take more time).



large_firstroundggk3mslrlqqobv3sv1vagoldilocks-hires.jpeg

medium_firstroundggk3mslrlqqobv3sv1vagoldilocks-hires.jpeg

small_firstroundggk3mslrlqqobv3sv1vagoldilocks-hires.jpeg

thumbnail_firstroundggk3mslrlqqobv3sv1vagoldilocks-hires.jpeg

firstroundggk3mslrlqqobv3sv1vagoldilocks-hires.jpeg

* **Goldilocks**:  Find the balance in the middle: not too fast/not too slow.  Not the lowest quality/not the highest quality. Perhaps the 480p version of the video is a good balance point: it'll look OK, won't take too long, and the 720p 1080p/4k versions are not far behind.

## Implementing your webhook

You can test this integration at [upload.a.video/webhook](https://upload.a.video/webhook).  

First we register a webhook at api.video to report to: upload.a.video/receive_webhooks

Then we add this code to process the webhook result when it arrives:

```
app.post("/receive_webhook", function (request, response) {
	console.log("new video event from api.video");

	//we're only getting video.encoding.quality.completed right now.. but let's be careful in case the webhook changes

	if (type =="video.encoding.quality.completed"){
	  let videoId = body.videoId;
	  let encoding = body.encoding;
	  let quality = body.quality;
	  liveStreamId = body.liveStreamId;
	  webhookResponse = {"event":type, 
	  					"emittedAt": emittedAt, 
						"videoId":videoId,
						"encoding":encoding,
						"quality": quality
						}
	  
	} 
	webhooks.push(webhookResponse);
	response.sendStatus(200);  
  });

```

This endpoint takes the webhook and adds it to an array.

## Video upload page

We've made 2 changes to the video upload page:

### Add an encoding selector

We add a selector in the form to allow to you pick the level of encoding you desire to release the video.  By default, we've selected 720p - on the higher end of things.

### Change how the video url is displayed

When the video is uploaded, the earlier versions of the upload demos just added the link to the video (the false start!).  We'll change the JavaScript on the page to do two things:

1.  Update the page that the video is being encoded, and the URL will be available shortly.
2.  Call the webhook endpoint to find out when the video encoding is completed.

```
console.log(video);
					videoId = video.videoId;
					playerUrl = video.assets.player;
					//we have the video URL, but it miight not be encoded yet. We need to get the webhook confirmation

					//STEP 1 tell them upload complete
					//hack to make the math look good.  yeah. i know.
					document.getElementById("chunk-information").innerHTML = "Last chunk"  + " is " + "100" + "% uploaded. Total uploaded: " + "100" +"%";
					document.getElementById("video-information").innerHTML = "all uploaded! We're now waiting for the server to tell us that the encoding is ready to play." ;
					//step 2 - start a new request for the webhook:
					var oReq = new XMLHttpRequest();


					oReq.open("POST", '/webhook', true);
					var qualityJson = {"quality":videoQuality,
										"videoId": videoId};
					console.log(qualityJson);
					var qualityJsonstring = JSON.stringify(qualityJson);
					oReq.onload = function (oEvent) {
						//encoding at selected quality is completed - tell the customer!!!
						console.log("Video encoded! Watch here: ",playerUrl ) ;
						document.getElementById("video-information").innerHTML = "Your Video has been encoded and is <a href=\'" + playerUrl +"\' target=\'_blank\'>ready to watch!</a>" ;
					}
					//send the quality value and the videoId we want to check on...
					oReq.send(qualityJsonstring);


```

So now the webpage is waiting for the Node JS server to say "hey the video encoding you are looking for is ready."

### Node JS code to check encoding versions

Recall that the webhook is writing every videoId and encoded version into an array. So we can just cycle through that array every 2 seconds to see if there is a video with the videoId and the encoding quality present. Once the webhook adds the video/quality - this will read that it is ready, and then reply back to the website that it is safe to show the URL to the user:


```
app.post('/webhook',(req,res) =>{
	var reqBody = JSON.parse(req.body);

	//video uploaded -but check to see if the 
	var videoId = reqBody.videoId;
	var videoQuality  = reqBody.quality;
	console.log("received  " + videoId + " " +videoQuality);
	//we need to see if this videoId and qulity have been encoded.
	//loop through all the webhook responses
	
	function checkWebhook(videoId, videoQuality, webhooks){
		foundMatch = false;
		console.log("there are " + webhooks.length + " webhook entries to scan");
		
		
		for(var i=0;i<webhooks.length;i++){
				if(webhooks[i].videoId === videoId && webhooks[i].quality === videoQuality){
					//we have a match!!
					foundMatch = true;
					res.sendStatus(200); 				

				}
			//}
		}
		if(!foundMatch){
			//no match yet, so wait 2 seconds and try again
			//not encoded yet, wait 2 sec and re-reun checkMp4
			console.log("no webhook yet.");
			setTimeout(checkWebhook,2000,videoId, videoQuality, webhooks);
		}
	}
	checkWebhook(videoId, videoQuality, webhooks);

})

```

## Conclusion

That's all there is to it. Instead of just showing the URL immediately after upload, we wait until the webhook tells us that the video is ready for playback. We can then provide the URL to our users (including the person who uploaded the video), and the link works - with "please wait while the video encodes" message.

Try it out at [upload.a.video/webhook](https://upload.a.video/webhook), and then use the code on [Github](https://github.com/apivideo/uploadavideoApps) to create your own webhook alerting function for videos.

If you have any questions or suggestions, please share them on our [community forum](https://community.api.video). If you dont' have an api.video account yet, you can create on in just a few moments by following [this link](https://dashboard.api.video/register). Happy building! 

False start: showing the playback url before the it’s ready

small_false-start1959569i.jpeg

thumbnail_false-start1959569i.jpeg

false-start1959569i.jpeg

False start: showing the video playback url before the video is ready

Analytics

One of the most satisfying features of livestreaming is seeing a live counter of how many people are watching your live stream.  In this demo, we’ll build a counter that gives a real time count of the number of viewers watching a live stream.

## api.video livestreams

Each livestream at api.video can be used over and over. It is a conduit for your livestreams.  There is a RTMP url that you use to send your livestream to api.video, and a playback url that you can embed in your website.  When you look at a livestream on your [api.video dashboard](https://dashboard.api.video/), you’ll see all the connection details (some are obfuscated in the screenshot) to connect your livestream. 

large_screenshot-2021-07-22-at-06-12-10.png

medium_screenshot-2021-07-22-at-06-12-10.png

small_screenshot-2021-07-22-at-06-12-10.png

thumbnail_screenshot-2021-07-22-at-06-12-10.png

screenshot-2021-07-22-at-06-12-10.png

 

Right underneath the thumbnail of the livestream, you can see a viewer count.  In the screenshot above it is at 632.  That is the count of historical views for this livestream - a sum of all the views for every livestream that has been run.  While this is an interesting stat, this is not exactly what we want to see during a livestream.

This NodeJS function takes your liveStreamId, and calls the analytics endpoint to get the total number of sessions that have occurred for that live stream:

```
function getLiveSessionCount(liveStreamId){
 
   return new Promise(function(resolve, reject){
       console.log(liveStreamId);
       var pageSize=1;
       var currentPage = 1;
       params = {
           "liveStreamId": liveStreamId,
           "pageSize":pageSize,
           "currentPage":currentPage
       }
       //get all sessions for livestream
       var sessionList = client.rawStatistics.listLiveStreamSessions(params);
       sessionList.then(function(liveSessionList){
           //get total sessoin
           var sessionCount = liveSessionList.pagination.itemsTotal;
           console.log("live sessions" , sessionCount);
           resolve(sessionCount);
       }).catch((error) =>{
           reject(error);
       });
   });
}

```

## Counting the views

To get an accurate count of viewing sessions during a livestream, we need to grab the livestream count when the stream starts (all of the views PRIOR to the current stream).  As the stream progresses, the number will increase, but a simple difference ```currentCount - startCount``` will provide the number of sessions that occurred during the current stream.

### Live stream webhooks

In July 2021, we launched 2 new webhooks: ```live-stream.broadcast.started``` and ```live-stream.broadcast.ended```.  These webhooks announce whenever one of your live streams begin/end broadcasting. 

When the ```live-stream.broadcast.started``` webhook fires, our webhook listener identifies that a live stream has started.  Then it calls the getLiveSessionCount function to get the starting count of sessions.

```
app.post("/receive_webhook", function (request, response) {
   console.log("new video event from api.video");
    let event = request.body;
   let body =request.body;
   let type = body.type;
   let emittedAt = body.emittedAt;
   webhookResponse = "";
   if(type =="live-stream.broadcast.started"){
       liveStreamId = body.liveStreamId;
       liveStreamStatus = true;
       webhookResponse = "event: " +type+ " at: "+ emittedAt+ " LiveStream,Id: "+liveStreamId+ "  has started.";
      
       //change the broadcasting status in the JSON pbject
       broadcastingStatus[liveStreamId]=liveStreamStatus;
       //TODO - get the number of views at start
       startViews = getLiveSessionCount(liveStreamId);
       startViews.then(function(startcounter){
           console.log("number of views when broadcast starts", startcounter);
           viewersAtStartOfStream[liveStreamId] = startcounter;
           webhookResponse = "event: " +type+ " at: "+ emittedAt+ " LiveStreamId: "+liveStreamId+ "  has started. There have been "+startcounter+" at the beginnig";
 
       });
      
    } else if (type =="live-stream.broadcast.ended"){
       liveStreamId = body.liveStreamId;
       liveStreamStatus = false;
       broadcastingStatus[piLiveId]=liveStreamStatus;
       webhookResponse = "event: " +type+ " at: "+ emittedAt+ " LiveStreamId: "+liveStreamId+ "  has stopped.";
    }
  
   //console.log(headers);
   console.log("response",webhookResponse);
 
  
   response.sendStatus(200); 
 });


```

Now, as the streaming progresses, the website polls /getLivecount every three seconds:

```
// Send list of the new count of viewers every x seconds
app.get("/getLivecount", function (request, response) {
 
 
   var LiveId = request.query.live;
   console.log("LiveId", LiveId);
   console.log(viewersAtStartOfStream);
   startCount = viewersAtStartOfStream[LiveId];
   console.log("startCount", startCount);
   //we have liveid get new user count
   var currentCount = getLiveSessionCount(LiveId);
           currentCount.then(function(currentWatchCount){
 
               console.log(startCount + " " + currentWatchCount);
               numberOfWatchers = currentWatchCount - startCount;
               console.log("numberOfWatchers", numberOfWatchers);
               response.send("There are " +numberOfWatchers + " watching this stream!");
           }).catch((err) => {
               console.log(err);
           });
 });

```

And this returns the difference from the start of stream (stored in an array on the server), and the current count.  Voila, a simple view counter!

##  Conclusion

In this demo, when the live stream begins broadcasting, we utilize the [live stream started webhook](https://docs.api.video/reference/api/Webhooks#create-webhook), which broadcasts that the stream has started. We determine the ‘seed’ number of sessions using the [Live stream session analytics](https://docs.api.video/delivery-analytics/analytics). Now we know the “0” for this live streaming session.

We can call the same endpoint every 3 seconds and report the growth in the number of sessions.  Each one of these is a new loading of the live stream video player - counting as a new viewer of the stream. This is then added to the page to indicate how many viewers are watching the live stream.

This demo is live at [watch.a.video/broadcast](​​https://watch.a.video/broadcast?streamId=li400mYKSgQ6xs7taUeSaEKr). To begin the stream, head over to [livestream.a.video](https://livestream.a.video) and begin the stream. To grow the number of viewers, you must open [watch.a.video/broadcast](​​https://watch.a.video/broadcast?streamId=li400mYKSgQ6xs7taUeSaEKr) in multiple incognito/private browser tabs (since the session is browser window based).

Try it out, and tell us what you think! If you’d like to look at the code to modify for your app, it is live on [Github](https://github.com/dougsillars/watchLivestream).


Count your live stream viewers with api.video

thumbnail_counter.jpeg

counter.jpeg

large_api-video-blog-product-updates.png

medium_api-video-blog-product-updates.png

small_api-video-blog-product-updates.png

thumbnail_api-video-blog-product-updates.png

api-video-blog-product-updates.png

Product updates

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

A couple of times a month, we get queries about a video not being ready to play. In this post we'll walk through how you can check the status of your video upload using our API and using our webhook.

large_screenshot-2021-05-05-at-16-12-51.png

medium_screenshot-2021-05-05-at-16-12-51.png

small_screenshot-2021-05-05-at-16-12-51.png

thumbnail_screenshot-2021-05-05-at-16-12-51.png

screenshot-2021-05-05-at-16-12-51.png

Sometimes we'll be asked: *"I uploaded my video a few minutes ago, and the quality is really pixelated. Why does my video look so bad?"*

Both of these questions have roots with the same phenomenon. When a video is uploaded, there is a period of time while the api.video servers encode your video, and place it on our hosting server for delivery.  Until the videos are encoded, they cannot be played back.

When we can up the video's encoding status on our backend, and we often see something like:

large_longvideo.png

medium_longvideo.png

small_longvideo.png

thumbnail_longvideo.png

longvideo.png

The 240p video took 17 minutes to encode, but is ready for playback. The other video qualities are being processed, but are not yet ready, so when the developer looks at the video, she only sees the 240p version. For an idea of why this video was so slow, the video was 120 minutes long.  Shorter videos encode faster than longer ones, because there is less data to process.

Our first user (above) had a very long video, and none of the versions had been encoded yet.

## You can check this yourself!

The [video status](https://docs.api.video/reference/api/Videos#retrieve-video-status-and-details) API endpoint will give you the encoding status of each version of your video.

```
"encoding":{
"playable":true
"qualities":[
{
"quality":"360p"
"status":"encoded"
}
{
"quality":"480p"
"status":"encoded"
}
{
"quality":"720p"
"status":"encoded"
}
{
"quality":"1080p"
"status":"encoding"
}
{
"quality":"2160p"
"status":"waiting"
}
]
```

This API is what we used to diagnose the video encoding above - we've used it to built an internal dashboard to tell where a video stands in the encoding pipeline.  You could do this too! 

In the JSON example above, all versions from 240p to 720p have been encoded and are ready to play. The 1080p encoding is in progress, and the 4K is waiting in the queue to be encoded.

## Is my video ready to play?

With this endpoint, you can check to ensure that the minimum quality that you want is ready for playback.  You can use this to decide whether or not to show the video on your site

## Polling is slow

Polling a server for this status is slow and time consuming.  If your app will be handling many videos being uploaded, you don't want to manage polling the status for each video.

## Webhooks push the encoding status to you

We have a [video encoding webhook](https://docs.api.video/reference/create-and-manage-webhooks) that pushes an alert to your server whenever a video/quality combination is ready for playback.  That way, you can set up a webhook, and let api.video *tell you* when your videos are ready for playback.  You can see a demo at [webhook.a.video](https://webhook.a.video), and read the [blog post](https://api.video/blog/product-updates/new-feature-webhooks/) on how we built this app.

## We're here to help

If you think your video encoding is slow, we're here to help you understand what is going on, and we are happy to help.  But, you can also use our APIs and tools to get this information to your servers in an automatic fashion - and it might just give you the answer you are looking for. (And while we're here for support during the week, the API does not take evenings or weekends off.)


Why isn't my video ready yet?

medium_processing.jpeg

small_processing.jpeg

thumbnail_processing.jpeg

processing.jpeg

## Webhooks

We're super excited to begin rolling out webhooks as a part of api.video. Today we have released our video on demand (VOD) encoding webhook. 

## What are webhooks

Webhooks are callbacks that announce when something has occured (pushing data to you), rather than having to ask whether an event has occurred (polling data from the server).


small_2247608175268b5d4f7o.jpg

thumbnail_2247608175268b5d4f7o.jpg

2247608175268b5d4f7o.jpg

The classic polling interface is children asking "are we there yet?" every few minutes from the backseat of the car.

The classic "pushing" of notifications is your phone telling you when you have a new email message. Your phone is not asking every minute, but the server tells your phone that an email has arrived.

Polling takes more energy - as both sides have to keep asking for data, and depending on the polling interval, can add delays to the process. Pushing data delivers the needed data as soon as it is available - using fewer resources to deliver more timely data.


## Polling for video encoding complete

Before webhooks were launched, you had to poll the [video status](https://docs.api.video/reference/api/Videos#retrieve-video-status-and-details) endpoint to know when a video was ready for playback. The ```encoding.playable``` result tells us if one version of the video is ready (typically a low quality version), but if you wanted to wait until a higher quality, like 720p video was encoded, you could look at that size to see when the encoding was completed.

## Webhook encoding events

Our first webhook is the ```video.encoding.quality.completed``` which pushes a message for each quality of each video has been encoded.

For example, when a recently uploaded video was encoded, the webhook received several webhooks: one for each version.  Here is an example:

```
{ type: 'video.encoding.quality.completed',
  emittedAt: '2021-03-23T17:03:39.908Z',
  videoId: 'vi7DWgHCu29smlHThpzEajfs',
  encoding: 'hls',
  quality: '720p' }
```

This tells us that this videoId was encoded as HLS at 720p.  


### Usages

* **Track uploads**: If you allow users to upload videos, you can track every videoId uploaded every day.
* **Display in your app**: Perhaps you only want to display a video when the 720p (or 1080p) video is ready (240p is great, but can be really fuzzy).  You can now use these webhooks to decide when a video can be pushed live.
* **Send your mp4 for analysis**.  Perhaps you would like to do further processing with the mp4 (to add captions, or to performa video moderation). Now, when the webhook alerts you that it is ready, you can begin that secondary processing.

## API calls

[Create webhook](https://docs.api.video/reference/api/Webhooks#create-webhook)
[List webhooks](https://docs.api.video/reference/api/Webhooks#list-all-webhooks)
[Get webhook](https://docs.api.video/reference/api/Webhooks#retrieve-webhook-details)
[Delete webhook](https://docs.api.video/reference/api/Webhooks#delete-a-webhook)

## Limitations

* Today, we allow you to have 3 webhook endpoints.  We may allow for more endpoints in the future.
* Each webhook event is sent 3 times. If it fails 3 times, no further attempts are made to deliver the message.
* There is no tracking or history of webhook notifications.
* There is no authentication or certificate validation at this time.

## Live demo

[Webhook a video](https://webhook.a.video) displays encoding events when a video is uploaded. It is connected to the [upload a video](https://upload.a.video) application, so if you upload a video there, you'll see the encoding events in the webhook application.

small_screenshot-2021-03-23-at-17-59-28.png

thumbnail_screenshot-2021-03-23-at-17-59-28.png

screenshot-2021-03-23-at-17-59-28.png

In the screenshot above, you can see multiple encoding events have occurred: for several different videos.  It shows the webhook event, the date & time, the videoId, and the format and size of the encoding.

Rather than display these results, your application can base it's internal logic on these events.

## Conclusion

We're excited to begin launching webhooks, with the first being VOD encoding events. We'll next be working on live stream webhooks, so look for that coming in the near future.

If you have any comments about our webhooks (or any other feature you'd like to see, please leave a post at out [community forum](https://community.api.video).


New feature: Webhooks

codec

small_cedric.webp

thumbnail_cedric.webp

cedric.webp

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/apivideo/talk-to-us) 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/apivideo/talk-to-us)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

small_Blog_Zero Cost.webp

thumbnail_Blog_Zero Cost.webp

Blog_Zero Cost.webp

api.video

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/what-is/video-encoding/) that allows companies to add on-demand videos to their websites more efficiently.

Using [api.video](https://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](https://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

Erikka Innes

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? 

large_EncodingTranscoding.png

medium_EncodingTranscoding.png

small_EncodingTranscoding.png

thumbnail_EncodingTranscoding.png

EncodingTranscoding.png

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.

Video on demand

Live streaming

Analytics

Video infrastructure

Video player

See all features

Online learning

Short-form videos

Marketplace & E-commerce

Video messaging and recording

Quickstart guides

Documentation

Ecosystem catalog

Clients & SDKs

Community

Blog

Demos

Help center

Webhooks