Normal

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

large_api-video-blog-video-trends.png

medium_api-video-blog-video-trends.png

small_api-video-blog-video-trends.png

thumbnail_api-video-blog-video-trends.png

api-video-blog-video-trends.png

Video trends

## What causes buffering?

Nobody likes waiting for buffering. In [one survey](https://www.streamingmedia.com/Articles/News/Online-Video-News/Streaming-Video-Services-Are-Getting-Worse-63-See-Buffering-122408.aspx), 63% of streaming viewers went so far as to say buffering issues were one of the most serious problems they encountered when trying to watch video. Slow buffering can take you out of the moment in an important part of a TV show, film, or game. Sometimes it can end your interest in watching something altogether if the buffering keeps happening with long delays. The way buffering is supposed to work, is your device streams ahead of what you’re watching so that there’s always more video ready for you to see. If everything goes according to plan, you’ll seamlessly be able to watch your video content. But when it doesn’t go to plan, what’s the cause? The source of your buffering problem can come from a few different places.  

&nbsp;  

The easiest way to start diagnosing your buffering problem is to check your internet speed. 
If your internet is slow, you’re going to have buffering problems. There’s a number of reasons your internet could be slow, so it’s best to start with a test. You can choose from any of these free online speed tests: [Internet Speed Test Sites](https://www.lifewire.com/internet-speed-test-sites-2626177). Should you determine that your problem is internet speed, you can then start looking at what’s slowing you down. 

## 1. You’re using wifi

Wifi is great, but sometimes it’s a lot slower than Ethernet. [Ethernet can transmit data at up to 10 Gbps per second, or higher, depending on the service you buy and your equipment. Wifi on the other hand, maxes out at around 6.9 Gbps or less.](https://blog.rottenwifi.com/wifi-vs-ethernet-speed/) If you’re having trouble with buffering, you might consider connecting your playback device using an Ethernet cable if it’s possible. This is a secure, fast solution that might solve your buffering problem. If you can’t set up your device to work with an Ethernet cable (for example if you’re using your mobile phone, or sometimes a device like a Roku or Fire stick), we’ll go over additional ways you can solve buffering issues.

## 2. Too many devices on your system or too many applications running

If you connect the maximum number of devices to your system, or you have too many devices trying to do something at once, this can slow down your network. Then you’ll get buffering problems on what you’re watching. A simple solution is to turn off some of the devices while you’re watching TV or a movie. If you’re not watching on your TV, but using a computer instead, then you might try closing applications and windows. The less your computer has to process, the more it can focus on delivering you a seamless video experience. 

## 3. Your internet plan

Some internet plans don’t provide speeds that are suitable for seamless video viewing or gaming. Check to see what you have, and then use the speed test we talked about earlier to make sure you’re getting what you were promised. If everything seems under the speed offered and you’ve diagnosed everything else, you can consider a different provider. You can also upgrade your plan if you are getting what you were promised, but the internet speed isn’t fast enough for your needs.

## 4. Old technology 

Some people love updating their computers and gadgets and routers all the time. If you’re not one of these people, you might have old computers, TVs, or an old router. Old computers and TVs are less efficient, but the real show stopper here would most likely be an old router. Old routers can cause interference with Wifi connectivity and slow down your internet speeds. So, if you can, try to keep your router up-to-date. It also helps to keep your devices up-to-date. If you can’t, then sometimes you can just update your graphics card and that will help. 

## 5. Change video resolution

If you don’t mind a lower quality video, you can try changing the resolution for your content. Choosing a lower level of quality will make it easier for the video content to be delivered as part of a seamless viewing experience. If you are using a small screen, it’s difficult to tell the difference between 720p and 1080p, so you won’t be missing much. As a general rule of thumb, the smaller your viewing screen, the lower the quality can be. Try different resolutions to see what works for your eyes and your system. 

## 6. Check your VPN 

If you added a VPN to your system, this slows performance because your data must be encrypted then decrypted at a remote server. Something you can do, is test your VPN to figure out if it’s impacting video delivery on your devices. 

## 7. Check your browser settings

If you are viewing from a browser on a computer, the problem could be your web browser. Clearing the cache, removing cookies and browsing history can speed everything up and improve your video viewing experience. 

## api.video and buffering

api.video helps avoid buffering issues by providing blazing fast transcoding and delivery via HLS. HLS uses adaptive bitrate, meaning your customers get the best quality video at the best speed for their devices. api.video also helps you and your customers avoid buffering by using its own, video-focused Content Delivery Network (CDN) and edge servers so that content can be delivered to users as quickly as possible from somewhere local to them.  

&nbsp;  

If you’re looking to add video to your website, platform, or application, api.video offers a complete, flexible end-to-end solution for VOD, live streaming, transcoding, hosting, delivery, and usage analytics. Sign up for an [api.video trial account](https://dashboard.api.video/register) to try it out. 

small_how-to-stop-buffering-when-live-streaming-620x315.jpeg

thumbnail_how-to-stop-buffering-when-live-streaming-620x315.jpeg

how-to-stop-buffering-when-live-streaming-620x315.jpeg

doug.jpg

Doug Twitter

Doug Sillars

## HLS Video Streaming

HTTP Live Streaming (HLS) is the current 'de facto' streaming standard on the web. The *actual* web standard is MPEG-DASH, but HLS has gained widespread use, making it the predominant streaming solution in use today. When you play a video hosted at [api.video](https://api.video) - you are watching a HLS video stream.


In this post, we'll walk through what HLS streaming is, and how it can be used to stream video, including streaming multiple video sizes and bitrates.  

## the ```<video>``` tag

HTML5 natively supports video with the ```<video>``` tag. The usage generally looks like:
	
	
	```
	<video {various attributes like autoplay poster, etc}>
		<source src= "video.webm">
		<source src = "video.mp4">
	</video>
	
	```
	
In the video tag, you set your attributes, and then link to the videos in the source tag. If you have multiple source tags, the browser chooses the first format it understands.
	
When the browser sees a video file (or the user presses play), it begins the download. There is only one version of the video being downloaded - no matter the screen size.
	
When the video source is larger than the screen, the phone will have to remove pixels to correctly display the video - using extra CPU and battery resources. If the video bitrate is higher than the available network connection - the video will be unable to play smoothly, and there will be stalls during the playback.
	
Another point to consider for longer videos: if a user seeks ahead in the video, the video will only start playing when every byte before the selected location is played.
	
## A Video Stream
	
At its simplest, a video stream is created by breaking the video into smaller segments (or chunks) with extension .ts (they are often numbered to make them human readable). The order and naming of these segments are stored in a manifest file (typically with extension .m3u8)

Here is a manifest file from api.video:

```
	#EXTM3U
#EXT-X-VERSION:3
#EXT-X-ALLOW-CACHE:NO
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-KEY:METHOD=AES-128,URI="aes.key",IV=0x1846cb99f30c689d11f79b110ce16cf7
#EXTINF:4.000000,
0000.ts
#EXTINF:4.000000,
0001.ts
#EXTINF:4.000000,
0002.ts
#EXTINF:4.000000,
0003.ts
#EXTINF:4.000000,
0004.ts
#EXTINF:4.000000,
0005.ts
#EXTINF:4.000000,
0006.ts
#EXTINF:1.800000,
0007.ts
#EXT-X-ENDLIST
```

The first 7 lines are header lines, describing the file. The TARGETDURATION says that each segment should be 4 seconds, and the PLAYLIST-TYPE indicates VOD, meaning video on demand.
	
Each segment is listed with the EXTINF 4.0000, indicating the length of the segment, followed by the filename.  

### Skipping ahead 

As mentioned earlier - skipping ahead in an mp4 requires all video before the new point to be downloaded. If you skip to 1hour ahead in the movie - the player needs to download 60 min of video.

If you wish to "seek ahead" with a video stream, the player can calculate which segment to request next. The example above is short, but if you were to seek to t=22, the player can quickly calculate that it would be in 0006.ts, and the player could skip any .ts 'in between' that are not yet downloaded. 
	
## Multiple Video Streams
	
In reality, it is rare to just have one video stream inside your HLS video. You often have many different versions of the same video. Here at api.video, each video is encoded at 240p, 360p, 480p, 720p, 1080p, and 2180p (up to the size of the original video).
	
Each of these formats will have a manifest file as above. But how do you differentiate between each version of the video?
	
## The Master Manifest
	
The first file of the video delivered to the video player is the master manifest. It is the 'menu' that lists all of the streams available to consume:
	
```
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=275000,RESOLUTION=134x240,CODECS="avc1.66.30,mp4a.40.2"
240/manifest.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=880000,RESOLUTION=202x360,CODECS="avc1.66.30,mp4a.40.2"
360/manifest.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2860000,RESOLUTION=404x720,CODECS="avc1.66.30,mp4a.40.2"
720/manifest.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1540000,RESOLUTION=270x480,CODECS="avc1.66.30,mp4a.40.2"
480/manifest.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=4840000,RESOLUTION=608x1080,CODECS="avc1.66.30,mp4a.40.2"
1080/manifest.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=17600000,RESOLUTION=1080x1920,CODECS="avc1.66.30,mp4a.40.2"
2160/manifest.m3u8
```
	
Each version of stream gets its own entry, and they are typically ordered from lowest quality to highest. Let's look at the last 2 lines - defining the 4K stream:
	
```
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=17600000,RESOLUTION=1080x1920,CODECS="avc1.66.30,mp4a.40.2"
2160/manifest.m3u8
```
	
The definitions include the bandwidth required to play the video (17.6 MBPS), the resolution 1080x1920, and the video codec (avc1) and the audio codec (mp4).
	
The second line is the link to the manifest for that stream that will list each segment's length and location.
	
### Player Power
	
The details of this 'master manifest' gives the video player a lot of power. With the ```<video>``` tag, there is one 1080p mp4 that will play: poor network conditions, small screen - doesn't matter.
	
The player, being on the local device, knows the available screen size - so can request the proper size for the screen - eliminating transport data wastage.  Never again will a device get too large a video, and have to resize the video on the fly.
	
The player can also track the network throughput by calculating how quickly each segment is downloaded.  If the video playing is 1080p (4.8 MBPS), but all of a sudden, the network speed drops to 3.0 MBPS, the player can quickly shift to the 720p stream, which at 2.86 MBPS will still be able to play.
	

## Video Startup
	
Have you ever watched a movie on Netflix, and noticed that the first few seconds had very low quality?  When a stream begins, the player has no idea of the available bandwidth, so to ensure fast delivery, it often starts with the lowest resolution (240p 275KBPS).  There are 2 things going on here:
	
	1. really fast startup time.  Most connections can handle 275 KBPS, so we know the video will play.  For most connections, 275 KBPS will download VERY quickly - which means that the video will start quickly.
	2. Math.  after 2 segments are downloaded - the player knows the network speed, and can jump to 1080p (or what the device can support).

screenshot-2021-02-18-at-19-14-08.png

In the image above, we see that 0000.ts and 0001.ts were downloaded at 480p, but from 0001.ts forward, we are at 1080p.

It's likely that the 2nd segment 0001.ts plays as 1080p, meaning that just 4 seconds is of lower quality.  But it was delivered quickly, and quickly changed to a higher quality - making the overall experience for the end user a positive one.

So the end user sees a fast video startup (maybe a bit blurry), but the video quickly improves to a crisp video.

## What's next for HLS?

For live streaming, api.video shortens each segment to 2s.  That way, if the player requires 2 segments to be buffered before playback, the delay is just 4s, not 8. 

Recently, Apple has released specifications for Low Latency HLS (LL-HLS):

Now each segment can be broken into 'parts':

```
#EXTM3U
# This Playlist is a response to: GET https://example.com/2M/waitForMSN.php?_HLS_msn=273&_HLS_part=2
#EXT-X-TARGETDURATION:4
#EXT-X-VERSION:6
#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES,PART-HOLD-BACK=1.0,CAN-SKIP-UNTIL=12.0
#EXT-X-PART-INF:PART-TARGET=0.33334
#EXT-X-MEDIA-SEQUENCE:266
#EXT-X-PROGRAM-DATE-TIME:2019-02-14T02:13:36.106Z
#EXT-X-MAP:URI="init.mp4"
#EXTINF:4.00008,
fileSequence266.mp4
#EXTINF:4.00008,
fileSequence267.mp4
#EXTINF:4.00008,
fileSequence268.mp4
#EXTINF:4.00008,
fileSequence269.mp4
#EXTINF:4.00008,
fileSequence270.mp4
#EXT-X-PART:DURATION=0.33334,URI="filePart271.0.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.1.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.2.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.3.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.4.mp4",INDEPENDENT=YES
#EXT-X-PART:DURATION=0.33334,URI="filePart271.5.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.6.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.7.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.8.mp4",INDEPENDENT=YES
#EXT-X-PART:DURATION=0.33334,URI="filePart271.9.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.10.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart271.11.mp4"
#EXTINF:4.00008,
fileSequence271.mp4
#EXT-X-PROGRAM-DATE-TIME:2019-02-14T02:14:00.106Z
#EXT-X-PART:DURATION=0.33334,URI="filePart272.a.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart272.b.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart272.c.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart272.d.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart272.e.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart272.f.mp4",INDEPENDENT=YES
#EXT-X-PART:DURATION=0.33334,URI="filePart272.g.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart272.h.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart272.i.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart272.j.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart272.k.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart272.l.mp4"
#EXTINF:4.00008,
fileSequence272.mp4
#EXT-X-PART:DURATION=0.33334,URI="filePart273.0.mp4",INDEPENDENT=YES
#EXT-X-PART:DURATION=0.33334,URI="filePart273.1.mp4"
#EXT-X-PART:DURATION=0.33334,URI="filePart273.2.mp4"
#EXT-X-PRELOAD-HINT:TYPE=PART,URI="filePart273.3.mp4"


```
 
As the first comment line says, 'This Playlist is a response to: GET https://example.com/2M/waitForMSN.php?_HLS_msn=273&_HLS_part=2'. 

Segments 270, 271 and 272 are 4s long, but broken into 12 'parts' of 1/3 second each.  The request was for segment 273 part 2... But, alink is presented for  273 part3, this is introduced as a PRELOAD-HINT - meaning - "hey this is not ready yet, but we know its coming, so you can request it when you need it"

The segments 266 - 271 are requested in case the viewer would like to 'rewind' a few seconds- the player has access to about 15s of video 'in the past.'


## Conclusion

Live streaming has a number of advantages over the HTML5 native ```<video>``` tag. Responsive by default, it ensures that less data is wasted by serving 'too large' video to a small screen.  It is also adaptive - so fluctuations of network speed are less likely to impact playback.

[api.video](https://api.video) uses HLS under the hood. Every video creation response includes the m3u8 url for the stream (if you are using a different player), but our player link, and iframe embed link are using HLS under the hood.

Are you curious to see your video as a stream? [Create an account](https://dashboard.api.video) and test in our developer's sandbox for free!

What is HLS video streaming and how does it work?

large_what-is-hls-video-streaming-and-how-does-it-work.png

medium_what-is-hls-video-streaming-and-how-does-it-work.png

small_what-is-hls-video-streaming-and-how-does-it-work.png

thumbnail_what-is-hls-video-streaming-and-how-does-it-work.png

what-is-hls-video-streaming-and-how-does-it-work.png

thumbnail_anne-sophie.jpg

anne-sophie.jpg

twitter-brands.svg

Twitter (Anne-Sophie)

Anne-Sophie Poupard

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

Following the launch of our [new visual identity](https://api.video/blog/product-updates/new-logo-same-mission-connecting-people-through-unique-video-experences/) a few weeks ago, we are now releasing **our new dashboard**: a complete visual and experience update providing easier access to manage your videos.

We have fully rebuilt the dashboard to feature a new, polished design. This redesign is not only about esthetics as we completely reviewed the navigation to provide a great user experience. 

The new dashboard has the same functionality that exists in the old design; all reimagined for the best usability. The new platform will improve the service we offer by increasing transparency, access to information and better management tools.

## What can you do?

* Access your API keys
* Access all the information related to your account and all the resources you need to use api.video (Clients, Tutorials, Docs, Demos, ...)
* Access and manage all your videos from your "Videos" section
* Upgrade to the Production environment and remove the watermark from your video content
* Monitor your usage
* Switch easily from a Sandbox to a Production environement to test without altering your Production.

large_dashboardapi.png

medium_dashboardapi.png

small_dashboardapi.png

thumbnail_dashboardapi.png

dashboardapi.png

## What is required from you?
You don't have to do anything, you already have access to the new dashboard: [Check it out](https://dashboard.api.video/register)

There are more great updates coming soon. It’s a really exciting time here at api.video and we can’t wait for you to see what’s next. 

If you have any questions, don't hesitate to contact us through the chat box inside the dashboard or through our [Community Forum](https://community.api.video)

Introducing our new dashboard

large_dahsboard.png

medium_dahsboard.png

small_dahsboard.png

thumbnail_dahsboard.png

dahsboard.png

small_cedric.webp

thumbnail_cedric.webp

cedric.webp

Cédric Montet

The difference between good products and great products is "the magic" we can feel when we are using them.

## Good products
Good products get the job done - but still require a thought process to walk through the steps required to accomplish a task. They make us feel, as users, the succession of technical steps when we want to accomplish something.

If I want to record a video with my iPhone, I first open the Camera app, then slide to the video mode, press the red button to start my recording and press again to finish it. All the steps are clear to me and I'm not surprised with the result: I want to create a video → the way I use the tool allows me to create the video.

I don't have an emotional reaction, because while the design is great, it is not an effortless process. I don't wonder *'how did it do that?'* or feel like some type of magic occurred.

## Great products
Great products are different: **they provide me value from nowhere** and make the technical aspects of using the product disappear.

A perfect example of this is **Shazam**. We launch the app and it recognizes the music around us. We don’t even have to guess something like the singer or the lyrics. Instead, the app creates an audio fingerprint, requesting a database of tracks to find similar fingerprints until it matches the song for us. The process is effortless. This is “the magic."

Another example - **Google Photos**: we type a location, an object or a word in the search bar and the app will show us all pictures related to these terms while we have never created any metadata around our pictures. This is "the magic."

**Netflix**: we used to spend countless hours on obscure directories to find the right torrent for a movie, which is not a screen cam, without Korean subtitles embedded on the picture and in good quality. Now, we launch Netflix on all our screens, and the movie we want starts immediately, according to our settings (the audio we want, the subtitle we want). And it’s effortless. This is "the magic."

## Transcoding is key, but unimportant to users
We are living in a video-first world, but all of us don't have access to fast broadband and large screens.

Some of this is changing. With the rise of affordable electronics for video creation, people everywhere can make and upload videos, even if they don’t have the greatest internet connections. And with the advent of 5G, the ability to rapidly upload and transmit content will become available all over the World.

We used to live in a world where downloading and consuming content was what happened most, especially with mobile. But with the addition of 5G, now we are entering **an era of upload**.

As we join this new time, manufacturers keep promoting their proprietary video format, preventing us from sharing a video easily. This is why all video platforms [transcode](https://api.video/what-is/transcoding/) videos right after the upload. 

Transcoding is not something users want to think about. What users want is to **make their videos available worldwide in seconds**. They don’t want to think about whether to choose HLS or Dash or VP9 or H264. And they don’t want to sit staring at a transcoding progress bar for minutes. This is not magic. It’s slow and tedious.

What should happen is magic - a video is uploaded and an invisible, rapid process ensures that users can immediately show their brand new content to their audience. 

This is "the magic" that api.video strives to provide. We want to make transcoding quick and efficient, something you don’t ever need to think about.

## Reinventing the video transcoding pipeline
At api.video, we have worked hard to **reinvent our video transcoding pipeline** to deliver exceptional performances: 

* We put the transcoding process on EDGE servers, which means your videos get transcoded to a server close to you. This saves seconds you'd usually have to wait when using a traditional video platform with a centralized approach.
* Different versions of your video are transcoded by several servers at the same time to avoid the queue effect (waiting for transcoding to complete before starting another)

large_transcoding-time-and-host.png

medium_transcoding-time-and-host.png

small_transcoding-time-and-host.png

thumbnail_transcoding-time-and-host.png

transcoding-time-and-host.png

In the image above, five servers were used to generate the five qualities of a five minute video at the same time. 

* We also changed the way HLS assets are generated and written to storage to transfer the transcoded files in a few milliseconds

large_hls-encoding-time.png

medium_hls-encoding-time.png

small_hls-encoding-time.png

thumbnail_hls-encoding-time.png

hls-encoding-time.png

In the illustration above, the average 240p encoding duration for the five minute video was four seconds. However it took .53 seconds to send it to the storage system.

* We transcode the lowest quality first to let the video plyer start once this quality is ready, even if the highest qualities are still in progress.

By working and improving all the steps of the pipeline, the **five minute video** we used for this article was **ready to play anywhere in the world only four to five seconds after the upload ended**, and the high quality 720p version of the video was ready just eight seconds later.

That's a total of only 12.5 seconds after the upload was completed!

That’s a superb experience for all people who put a video online to share it.
This is our magic. 

large_encodingbench.jpg

medium_encodingbench.jpg

small_encodingbench.jpg

thumbnail_encodingbench.jpg

encoding-benchmark.jpg

## What's next?
We are super proud to make this [magic available to everyone](https://api.video/what-is/video-encoding/) as our [benchmark](https://api.video/platforms-benchmark/) (you can download the repo [here](https://github.com/apivideo/video-platform-bench) and the video used [here](https://test-videos.co.uk/vids/bigbuckbunny/mp4/h264/1080/Big_Buck_Bunny_1080_10s_10MB.mp4)) demonstrates that we are increasing dramatically the Market performances to date.

Oh! And seconds are still too long: **we won't rest until we reach few milliseconds** :)

The magic behind great products

large_magicalproductpost.png

medium_magicalproductpost.png

small_magicalproductpost.png

thumbnail_magicalproductpost.png

magical-product-post.png

Video upload

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

api.video offers a PHP client to make it easier for you to upload your videos. Today we'll walk through how to do this. You can always hop on over to the GitHub repository if you'd prefer to learn about the client that way too - [api.video PHP client](https://github.com/apivideo/php-api-client).

## Prerequisites

For this project, you'll need these things: 

* Composer - if you don't have it set up, go here to learn about it and get it installed - getcomposer.org
* An api.video account - you can sign up [here](https://dashboard.api.video/register).

## Installation

You'll need to install a few things using Composer:

* The api.video PHP client - `composer require api-video/php-api-client`
* Symfony HTTP client - `composer require symfony/http-client`
* nyholm/psr7 - `composer require nyholm/psr7`

You can type **composer update** to make sure everything is pulled into your project and configured. 

## Code sample

Here is the code sample for uploading a file. You need to change **'yourAPIkey'** to your key that you retrieve from the api.video dashboard after you create an account. Place the video you want to upload in the same folder as your code sample. For the sake of simplicity, this code sample hardcodes the title of the video - change **VIDEO_TO_UPLOAD.mp4** to the title of your video file.

### Import the client
In the first part of the code, you import the parts of the api.video PHP client you'll need. The client is more efficient when you import the endpoints you need for your code, instead of everything. You also need the HttpClient from Symfony for this implementation. So it will look like this:

## Initialize the client 
Next you initialize the client for use in your API calls. 

## Create your video payload 
The next part of the code includes a video creation payload. This is a cool part of the PHP client. You can add all the metadata you'd like for your video here. Later, you're able to update your code as well. Consult the [Create a video](https://docs.api.video/reference/api/Videos#create-a-video-object) endpoint in our API reference documentation for available parameters. You capitalize them when adding them into your payload. So title becomes `setTitle` as shown in the code sample. Any parameters in camel case that you want to use would change a bit. For example, the docs have mp4Support, but if you are using the PHP client, you would write it as `setMp4support`. 

When you send multiple parameters, the code would look like this: 

`$payload = (new VideoCreationPayload())
    ->setTitle('My cool video');
$payload->setTags(['tag 1', 'tag 2']);`

When you're done setting up your payload, then you use the client to send this information to api.video servers and create your video container.

## Upload the video
In the last part of the video, you retrieve the video ID for the container you made and upload your video into the container. You can only upload into a container once, but you can change its metadata later if you wish. You can see whether it worked by reading the echoed response in the terminal.

## Conclusion
Now you know the basics of uploading a video with the api.video PHP client! You can check whether your upload worked by going into your dashboard and looking in the videos section. You should see it there. If you get a note that it's still processing, give it a bit of time to get the video ready, especially for big videos. 

If you have any questions or suggestion, please share them on our [community forum](https://community.api.video/). If you haven't created your api.video account yet, you can do that in just a few moments by follwoing [this link](https://dashboard.api.video/register). Happy building! 

Upload a video with the api.video PHP client

large_Upload with PHP.png

medium_Upload with PHP.png

small_Upload with PHP.png

thumbnail_Upload with PHP.png

Upload with PHP.png

large_api-video-blog-no-code.png

medium_api-video-blog-no-code.png

small_api-video-blog-no-code.png

thumbnail_api-video-blog-no-code.png

api-video-blog-no-code.png

No-code

no code

Zapier is a no-code platform that makes it easy to connect services together - without writing a single line of code.

We recently upgraded our [Zapier integration](https://zapier.com/apps/apivideo) to make use of our [API webhooks](https://docs.api.video/reference/api/Webhooks#create-webhook), so that Zapier can instantly report when an event occurs at api.video.

## Our webhooks

We currently have 4 alerts from our webhooks:

* video.encoding.quality.completed: This alert fires when a video quality is ready to playback.
* live-stream.broadcast.started: Alerts you to when a live stream has begun.
* live-stream.broadcast.ended: The opposite alert - the live stream has ended.
* video.source.recorded: Similar to the first, but specifically for when a livestream recording quality is ready.


## Now available in Zapier

When the webhook alert from api.video occurs, Zapier is alerted immediately.  That's why Zapier calls these triggers "Instant triggers"- there is no polling delay to know when the Zap must begin:

large_screenshot-2021-10-21-at-20-46-46.png

medium_screenshot-2021-10-21-at-20-46-46.png

small_screenshot-2021-10-21-at-20-46-46.png

thumbnail_screenshot-2021-10-21-at-20-46-46.png

screenshot-2021-10-21-at-20-46-46.png

As shown in the above screenshot, there are currently 4 instant Zap triggers offered by api.video.

* **Live stream started**  This alert will fire whenever a livestream has started.  You can filter on the liveStreamId to create a custom integration for a specific live stream ("when stream liXXX goes live - send an alert to a Discord channel), or have it fire for all of our live streams (livestream "liYYY" is now live.  Watch it here <link>") 
* **Live stream started** this is the opposite of the first alert - so the Discord channel knows the stream has ended "sorry you missed us, tune in tomorrow".
* **Video encoded completed**  This webhook fires for each version of the video created.  Currently, api.video encodes video at 240p, 360p, 480p, 720p, 1080p and 2160p.  When you create the Zap, you choose which size you wish to be alerted on.  For example, if you only want to show a video once the quality has reached 480p, you define the Zap to trigger when the 480p version of the video is ready, and then you'll receive that alert.
* **All live events**: This webhook incorporates all 3 live stream webhook events: started, ended and video.source.recorded (at a specific resolution). This allows you to create more elaborate Zaps with various paths based on the results - while just using one webhook.

Each Zap you create with the instant triggers will create a webhook at api.video (and when you disable the Zap, the webhook will be removed).  

> Note: There is a limit of 10 webhooks per account at api.video, so there should be some consideration on how the number of "instant Zaps" will affect your webhook limits.


In the below example, we use Zapier paths and the *All Live Events* trigger to do 3 different things - depending on the event type that is reported. (Note: Zapier paths require a "professional" level Zapier account.)


We're very excited to see how instant Zaps can help our no-code developers build apps that react instantly to changes in their api.video account.

large_screenshot-2021-10-22-at-10-55-09.png

medium_screenshot-2021-10-22-at-10-55-09.png

small_screenshot-2021-10-22-at-10-55-09.png

thumbnail_screenshot-2021-10-22-at-10-55-09.png

screenshot-2021-10-22-at-10-55-09.png

These Triggers are all live at Zapier, and our [docs](https://docs.api.video/sdks/nocode/zapier) are updated with more details on how to integrate each trigger and action.

Our Zapier integration now features instant triggers

medium_screen-shot-2021-01-28-at-2-13-01-pm.jpg

small_screen-shot-2021-01-28-at-2-13-01-pm.jpg

thumbnail_screen-shot-2021-01-28-at-2-13-01-pm.jpg

screen-shot-2021-01-28-at-2-13-01-pm.jpg

Updated: our Zapier integration now features instant triggers

## The history of live streaming

Live internet streaming didn’t start all that long ago - in fact it debuted only ten years after the official birthday of the Internet, which is touted as January 1st, 1983. Since then, live streaming technology has developed a lot. It’s hard for us to imagine now, but when the Internet first started there was no music or video. Let’s go back in time and see how far this technology has come! 

1993: The first live streaming event on the internet is created by a garage band
On June 24th, 1993, the band Severe Tire Damage was playing a gig at Xerox PARC. While this was going on, scientists were working on new technology called MBone. MBone was an experimental network for carrying IP multicast traffic. (IP multicast is used to stream media to multiple viewers.) It just so happened that the Chief Technologist at Xerox PARC, Mark Weiser was the drummer for Severe Tire Damage. They decided to test the network’s capabilities by broadcasting their band playing. This first stream was everything you’d imagine — super slow frame rate, very pixellated and it involved a bunch of nerds jamming together. See for yourself: https://player.vimeo.com/video/56349011

Additionally, in order to stream the content, they used half the bandwidth of THE ENTIRE INTERNET. 

## 1994: The first virtual concert live streams on the internet
In this situation, Severe Tire Damage reappeared to open for The Rolling Stones. Surprise! Because the internet was still small, and there was one Mbone network, the band connected about twenty minutes before The Rolling Stones concert started, and described themselves as being part of the first ever virtual concert, because they were popping in to play from California and then The Rolling Stones concert was going to happen in Texas. The news media was watching, and got a big enough kick out of their surprise performance that some articles spent more time on Severe Tire Damage than they did describing the rest of the concert (which was probably epic). When asked to comment on their extra act, The Rolling Stones told The New York Times “the surprise opening act by Severe Tire Damage was a good reminder of the democratic nature of the Internet.” (Reference: [https://query.nytimes.com/gst/fullpage.html?res=9A04EEDE1F31F931A15752C1A962958260](https://query.nytimes.com/gst/fullpage.html?res=9A04EEDE1F31F931A15752C1A962958260) 

## 1995: The first sporting event live streams on the internet
The internet company RealNetworks created a media player that could handle live streaming - RealPlayer. To show off RealPlayer’s capabilities, the company broadcasted a baseball game between the New York Yankees and the Seattle Mariners. The demo was interesting, but live streaming didn’t catch on.

## 1997: RealVideo launches
RealVideo was a program that let you commercialize live streaming. Things weren’t quite in place for this to catch on, but it remains an important milestone in live streaming. 

## 1999: The first presidential webcast streams on the internet
Bill Clinton appeared at George Washington University in Washington DC to speak in a webcast titled ‘Third Way Politics in the Information Age.’ Viewers online could submit questions and have them answered.

## 2008: YouTube hosts a live event and streams it from San Francisco and Tokyo at the same time
YouTube’s live event, named YouTube Live streamed from San Francisco and Tokyo. It included performances from artists like Katy Perry, Smosh, MythBusters and Bo Burnham. They continued offering occasional live streams, but their broadcasts were a bit slow so this didn’t take off for YouTube. It did put live streaming on the map though. 

## 2011: Twitch launches a live streaming platform for video games
Originally justin.tv, which was founded by Justin Kan. He broadcast his life 24/7 and popularized the idea of live or "life" streaming. Later he rebranded his company as Twitch and opened it up to many users. Twitch capitalized on YouTube’s inability to capture the live streaming market. They focused on live streams of gamers and within two years they had 45 million viewers each month. Their success led to other social media platforms rushing to add live streaming capabilities. 

## 2015: The live streaming app Periscope launches
Periscope was an app bought by Twitter before launch. It allowed users to live stream immediately. When it became obvious through Periscope that live streaming was popular and could be lucrative, other social media platforms followed suit. Facebook Live appeared in 2016. Today popular social media apps have great live streaming - YouTube and Instagram included. 

Today there are a number of trends in live streaming that are pushing the value of live streaming even further. People can easily give broadcasts talking about their company or work. There’s live shopping, where products are modeled and talked about by influencers live and viewers can purchase while watching. 

## 2020: api.video and the history of live streaming
api.video wants to help developers build the incredible video products they dream of. That’s why we offer an end-to-end solution that lets you build live streaming features into your website or mobile app with ease.

## Resources

1. The Not-So-Ancient History of Live Streaming - https://switchboard.live/blog/live-streaming-history/
2. The History of Live Streaming - https://espressolive.com/blog/the-history-of-live-streaming/
3. The Fascinating History of Live Streaming - https://restream.io/blog/history-of-live-streaming/

 The history of live streaming 

small_severe-tire-damage.png

thumbnail_severe-tire-damage.png

severe-tire-damage.png

The history of live streaming (and how a bunch of nerds opened for the Rolling Stones)

NodeJS

We've launched a number of demos at [a.video](https://a.video) to demonstrate the power of [api.video's APIs](https://api.video) and our video in the cloud service.  We have apps featuring video uploading, video streaming and also mashup collaborations that include auto-captioning, video moderation, live video chat and others with some select partners.

You might want to launch one of these demos for your own application or process - using your api.video account.  In this post, we'll walk through the steps we use to launch new demos for a.video, and if you follow along, you can launch your own versions in your Heroku account.

## Heroku

Heroku is a service that makes it easy to spin up a server, add your code, and launch a service on the internet.  We use Heroku for all the a.video demos, so will walk through the steps we perform in order to launch our demo applications.

## record.a.video

The [record.a.video](https://record.a.video) demo has been very popular. It allows you to record your screen and camera right from the browser.  You can choose to send that feed to api.video as a live stream, or record the video, and send it to our video hosting platform for later on demand viewing.

In this post, we'll take the record.a.video code from Github, and launch our own personal version of the application on Heroku.  At that point, you can update the page to match your expected user experience, and have a working app with just a little bit of work.

First off, we'll want to grab the code from Github.  Head to the [recordavideo](https://github.com/apivideo/recordavideo) repository, and fork it into your account:




medium_screenshot-2021-10-20-at-12-38-16.png

small_screenshot-2021-10-20-at-12-38-16.png

thumbnail_screenshot-2021-10-20-at-12-38-16.png

screenshot-2021-10-20-at-12-38-16.png

You should now have the repository in your account, with the format ```https://github.com/<your accountname>/recordavideo```.  

Before we can go live, the app uses a few api.video configurations that are set to the team's account, and you'll want to switch to yours.

There are a couple of ways to do this - you can clone the repository to your machine to make the edits (and then push the fixes back to Github). If you 've used Github a lot, this will feel like second nature.  For those who have not used git regularly, you can manually change 3 lines of code using the web interface.

We need to change the first 3 lines of ```/public/index.js```.  


```
RTMP_url = 'rtmp://broadcast.api.video/s/30087931-229e-42cf-b5f9-e91bcc1f7332';
live_url = 'https://embed.api.video/live/li400mYKSgQ6xs7taUeSaEKr';
delegated_token = 'tompBU8ZJcUCEsKGxxoBydh';
```

Record a video allows you to livestream, or upload a recorded video.  The RTMP_url and live_url are used for live streaming.  The video from the browser is sent to the RTMP_url, and then the broadcast is visible from the live_url.

* To set these up, you must [create a livestream](https://docs.api.video/reference/api/Live-Streams#create-live-stream) using our API.  We have a [tutorial using cURL](https://api.video/blog/tutorials/live-stream-tutorial/) to help you create a live stream. This will give you the RTMP and live URLs to update lines 1 and 2.
* Next, we'll create a delegated token, for the video on demand upload option. For this, we'll use the [generate upload token](https://docs.api.video/reference/api/Upload-Tokens#generate-an-upload-token) API endpoint - (and the corresponding [curl tutorial](https://api.video/blog/tutorials/delegated-uploads/).

Once you've updated the ```public/index.js``` with your values, we're ready to launch on Heroku.

Create a free account (or login) to [Heroku](https://dashboard.heroku.com/apps).  You'll land at your dashboard, and in the upper right corner is a button "New."  Choose "Create new app" from the menu.

The name "recordavideo" is taken, so pick another descriptive name for your application:


large_screenshot-2021-10-20-at-16-04-25.png

medium_screenshot-2021-10-20-at-16-04-25.png

small_screenshot-2021-10-20-at-16-04-25.png

thumbnail_screenshot-2021-10-20-at-16-04-25.png

screenshot-2021-10-20-at-16-04-25.png

Once you create the application, you'll land at the Heroku dashboard for the app, in the "Deploy" section.  We want to deploy via Github, so in the center, click the Github logo.  Then, choose the Github account and search for the repository you wish to deploy.  In the screenshot below, I have selected repordavideo in the dougsillars github account:

large_heroku-deploy.png

medium_heroku-deploy.png

small_heroku-deploy.png

thumbnail_heroku-deploy.png

heroku-deploy.png

Once you connect your repository, you can set it up to automatically redeploy when changes are made in Github.  Enable this, so when you do update the UI/UX, it will automatically appear in the launched app.  You can also manually deploy the repository from here.

### Settings

Move to the Settings tab in the dashboard to further configure your server.  The record.a.video application uses ffmpeg on the Node server - it [transmuxes](https://api.video/what-is/transmuxing/) the video from the canvas on the screen into RTMP for api.video.  We need to tell Heroku to install FFmpeg.  There is a buildpack already created ```https://github.com/jonathanong/heroku-buildpack-ffmpeg-latest.git``` so we'll add it. Then we will add the NodeJS buildpack.



large_buildpacks.png

medium_buildpacks.png

small_buildpacks.png

thumbnail_buildpacks.png

buildpacks.png

> Note: the buildpack for the language must be the last one on the list. If the order is reversed, your app will not build.

In the table above, you can add any environmental variables (there are none in this app, but many NodeJS apps use process.env.<variablename> to reference API keys and other values that should not be published into github, or left referenced in code.
	
For example:

```
const apiVideoKey = process.env.apiProductionKey;

```
	
You would have apiProductionKey in these variables - referenciung your api video production API key.
	

large_env.png

medium_env.png

small_env.png

thumbnail_env.png

env.png

With all these settings made, you can now go back to the "deploy" tab and manually deploy your application. Once that is completed, you can visit the URL listed in the settings page to run your own copy of record.a.video (or whichever app you copied).

### Bonus steps

If you have a domain you;d like to use, the Settings tab allows you to set a domain that will point to this app's instance. You'll need to do CNAME DNS work to make this all happen, but this is how we get our apps to point to our ```a.video``` subdomains.


## Conclusion

That's all there is to it - simply pick your app, fork it, and update to your API keys/ settings, and follow the steps to deploy on Heroku.



Build an api.video demo with Heroku

medium_screenshot-2021-10-21-at-10-59-29.jpg

small_screenshot-2021-10-21-at-10-59-29.jpg

thumbnail_screenshot-2021-10-21-at-10-59-29.jpg

screenshot-2021-10-21-at-10-59-29.jpg

video create

The first step to displaying your video online is getting it uploaded. Today we'll go over how to upload a video using Laravel 8 with api.video's PHP Client. Before we dive in, let's go over what we'll be doing when we upload a video. 

Uploading a video is a two step process. First, we create a container for the video and retrieve the video ID. Then, we upload a video into the container by referencing the ID. You can only upload a video to a container once, but you can modify details about the video at any time after that. Our uploader will let you add a title, description and list whether you want to have the video be public or private and whether you want to offer an MP4 link of the video for download. 

## What you'll need 
To get started, make sure you have these things:

* Account with api.video - you can sign up [here](https://dashboard.api.video/register)
* Laravel 8 - you can use other versions, but some things work differently
* NPM and node.js - you install these when you set up Laravel 
* Composer - you'll need this installed 
* [api.video PHP client](https://github.com/apivideo/php-api-client)
* Project repository - [https://github.com/apivideo/php-api-client/tree/main/examples/laravel/video_upload](https://github.com/apivideo/php-api-client/tree/main/examples/laravel/video_upload)

You can also review the API reference documentation for the endpoints used in this project: 
* [Create a video](https://docs.api.video/reference/api/Videos#create-a-video-object)
* [Upload a video](https://docs.api.video/reference/api/Videos#upload-a-video)

## Create your project
The first thing you'll need is a Laravel 8 project to work with. Here's what I did:

1. In a terminal make a new project by typing: **laravel new fileuploader** or similar project name.
2. Open your project folder, you'll need to install a few things.  
3. You'll need to add the api.video PHP client, so at the terminal type: **composer require api-video/php-api-client** 
4. You'll also need the symfony http client, at the terminal type: 
**composer require symfony/http-client**
5. And the last thing to add is nyholm/psr7:
**composer require nyholm/psr7**

You can type **composer update** to make sure everything is pulled in to your project and configured.
 
## Create a controller
We will need a controller for our video uploader, so let's go ahead and do that now. In the terminal in your project folder type: 

**php artisan make:controller UploadController** 

This will automatically create what we need to start building the controller. 

## Set up the home page with an upload form
For this walkthrough, we're using the home page to create an upload form. So in your views folder, go into **home.blade.php** and create the form. I selected to allow the user to add basic details about their project. I'm also using bootstrap, so the basic form looks like this: 

Image of upload form showing available fields

large_viduploadphp.png

medium_viduploadphp.png

small_viduploadphp.png

thumbnail_viduploadphp.png

viduploadphp.png

And here is the code that creates this form: 

We pull in the bootstrap details up top under the Scripts and Styles sections. Then for our form, we have all the form data sent in a POST request to the '/upload' route. (We'll need to create that route in a moment.) 

The form is straightforward - we list the type of data as text for the name of the file and the description of the file. For choosing whether the file will be public or offer an MP4 for download, we use a radio button, so the type is radio. For the video, we choose type file and then we set up our submit button. Bootstrap styles everything for us, so we're all set here. Now we need to handle the route. 

## Set up the /upload route
Open your **web.php** file and add a new route: 

**Route::post('/upload', 'UploadController@upload');** 

This route indicates that when submit is clicked in the form, it should go to /upload and carry out the upload instructions listed for the UploadController. 

We don't have that set up yet, so let's do that next. Also, the other routes are added into the project, you can see everything if you download the repository.

## Set up your UploadController
Our controller takes the details provided by the form, then uploads the content to api.video. Behind the scenes, we're going to need our api.video API key, so let's make sure we handle it securely. 

1. Go to your .env file. In the top section, you'll see items to do with your app. At the bottom of the list of items beginning **APP_** you'll see **APP_APIVIDEO=yourapikey**. Replace **yourapikey** with your key (retrieve it from your api.video dashboard). Don't add quotes. 
2. Open **RouteServiceProvider.php**.
3. In the file, take the commenting **\\** off of the line **protected $namespace = 'App\\Http\\Controllers';**. This returns the use of the automatic namespace, which is handy.
4. Open **UploadController.php**. 
5. Add this code: 


In our code, we set up the api.video client and collect the information from the request object that comes in from the form. We check if the data for the radio buttons is set and if it is, we add it to our payload for upload. Then we send the data and redirect the user to a page that says 'Success!' 

## Conclusion
These are the basics for uploading a video to api.video. You can try using different styles or set ups if you want to allow users to add more metadata on upload. If you have any questions or suggestions, please share them on our [community forum](https://community.api.video/). Thanks for reading! 



Upload a video with Laravel

webhooks

JavaScript

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

bumperavideo-1.png

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

Blog

Huge pricing update! Introducing video encoding at zero cost