live - create

Normal

doug.jpg

twitter-brands.svg

Doug Twitter

Doug Sillars

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

Frequently asked question: How many live streams can I use simultaneously with api.video? 
Answer: How many cameras do you have?

That sounds like a snarky response (and perhaps it is *a little bit* snarky). Some platforms - like YouTube Live or Twitch - allow just one live stream per account at a time. But, with api.video there is no such limitation - as long as you have cameras (and available bandwidth), you can stream to your heart’s content from every single one of them.

## Why would I stream more than once?

There’s no reason to limit your viewers to just one view - stream from every angle (or stream from every angle that you have a camera for!).  Or if your client needs video from a number of locations at once - api.video can support you.  Here are some example use cases:


Are you running a multi track conference?  Stream each room from the same api.video account. Add a hallway cam to show the social interactions.  
Do you support more than one client?  Don’t drive yourself crazy scheduling to fill the one slot - let everyone have their own live stream(s).
Sporting event - multiple angles.  Does the coach want a stream from the opposite side?  From behind the goal/end-zone? From the top of the stadium?

## Create your live streams


The first step in having multiple live streams is to create your live streams.  You can create as many streams as you’d like. 

Creating [live streams](https://api.video/blog/tutorials/live-stream-tutorial/) is easy with our [API](https://docs.api.video/reference/api/Live-Streams#create-live-stream).  

Once you’ve created your live stream you (or your clients/users) can re-use each livestream over and over (like a Space-X rocket). 

* Stop the stream after each conference talk, and restart before the next. If you have ```record:true``` set for the live stream, you’ll get VOD versions of each video saved into your account.  Each recording will have the livestream name, and the time (in GMT). 
* Assign live stream(s) to your clients, and let them use them to their heart’s content. No more work is needed on your part.
* Name each livestream for easy recovery of the videos:  “50 yard line”  “Client X” “Conference Fizz 2021: Buzz track”




## A wildly absurd demo 


As an example of using live concurrent live streams, I hooked up all the cameras I could find (and that were charged up) to my laptop/wifi. In the example below, I was able to run 5 concurrent live streams - showing the capabilities of api.video, but also pushing my computer (and my internet connection) to their limits:



medium_257523051420257536349489364058826396261704n.jpg

small_257523051420257536349489364058826396261704n.jpg

thumbnail_257523051420257536349489364058826396261704n.jpg

257523051420257536349489364058826396261704n.jpg

* [https://Livestream.a.video](https://Livestream.a.video) - using an USB webcam (mounted on monitor)
[https://Record.a.video](https://Livestream.a.video) - using Mac webcam
[OBS](https://api.video/blog/no-code/start-and-record-a-live-stream-with-obs/) - using Iriun and a phone - this app connects your phone to a computer via Wi-Fi (on right of photo on a stand)
[Android livestream](https://api.video/blog/tutorials/livestream-from-your-android-phone/) - phone using Larix Broadcaster to stream (leaning on laptop)
[Pi livestream](https://api.video/blog/tutorials/video-streaming-with-a-raspberry-pi/) - my raspberry Pi camera (pointed out the window)





This was a fun demo to try out, but it did push my laptop to the limit. What it does show is that with a few computers & cameras and an api.video account, it is really easy to simultaneously live stream as many views, angles, rooms as you desire.



How many live streams can I run at once?

large_concurrent-livestreams.jpg

medium_concurrent-livestreams.jpg

small_concurrent-livestreams.jpg

thumbnail_concurrent-livestreams.jpg

concurrent-livestreams.jpg

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

## The benefits of a cloud video platform
The cloud is collections of servers in data centers that run software, maintain databases and serve all kinds of content to all the corners of the world. As we make it easier to create and share video by adding technologies like fast 5G networks and cheaper camera equipment, more and more people are creating video content. To handle the demand, most video streaming platforms use the cloud. Netflix famously started the move to the cloud after a corrupted database prevented them from mailing anyone their DVDs for 3 days! YouTube uses the cloud, and so does api.video. There are many benefits to providing video via the cloud. 

## 1. You can use a network that can handle video streaming and heavy traffic
A major benefit to using a cloud video platform is that it's up to someone else to handle the technical details of video streaming and coping with heavy traffic. You can just add video to your company portal, or build your own viewing interface or whatever you like.

## 2. Lower cost
It's less money for your business or project if you don't have to store your video content, manage the servers with the content, or hire an IT team. Instead, you pay for a video service, like api.video, and everything is stored and managed for you. 

## 3. Video focused content delivery network
If you choose a cloud video platform like api.video, you get to use our private content delivery network. Because api.video handles only video content, the network is optimized to provide the best experience when working with video. Many companies that work with video have their own networks for their content, including Netflix - their network is called Netflix Open Connect. 

## 4. Continuity
When you store content yourself, you have to have a plan for what happens if part of your system goes down. If you use a cloud service for your video, this is handled for you. By storing it in the cloud, it can be replicated and maintained in multiple locations if need be, so that your video is always there when you need it. 

## 5. Mobility
If your video content is stored in the cloud, it's easier to access. You can stream content at home or a coffee shop, anywhere there's internet, you'll be able to get to your videos and interact with them. 

## api.video and the cloud
At api.video, all our services are in the cloud. We use our own Content Delivery Network (CDN) to ensure fast, reliable uploading, transcoding, and delivery. 

large_top-5-benefits-of-a-cloud-video-platform-1.jpg

medium_top-5-benefits-of-a-cloud-video-platform-1.jpg

small_top-5-benefits-of-a-cloud-video-platform-1.jpg

thumbnail_top-5-benefits-of-a-cloud-video-platform-1.jpg

top-5-benefits-of-a-cloud-video-platform-1.jpg

small_yvanmichel.png

thumbnail_yvanmichel.png

yvanmichel.png

Yvan Michel

All companies in the video streaming sector have the same goal-- guarantee the best watching experience with efficient cost control for ingest, transcoding, and delivery. It is not an easy task and requires a lot of considerations on the Product and Engineering sides.

Measuring the Quality of Experience (QoE) is one of the methods widely used to assist this process. In this blog post, we will go through the QoE principle and functioning by relying on common use cases and metrics.

## Principle

As soon as someone uses a website or an app, stakeholders need feedback in order to learn about the strengths and weaknesses of what they've built. The measurements performed for the QoE purpose are based on this same principle and are seamless for the end-user.

The QoE consists of collecting and sending users subjective data to better understand how the product is used to make the right decisions. In this case, knowing more about how videos are consumed by viewers through a first-party player.

It helps to get more insights about questions like "What will be the effects of reducing the 1080p video bitrate on the end-user engagement?" and "Is it a good approach to preload the video on the start-screen to boost its loading time?"

NOTE: QoE data must comply with local privacy policies like [GDPR](https://en.wikipedia.org/wiki/General_Data_Protection_Regulation) or [CCPA](https://en.wikipedia.org/wiki/California_Consumer_Privacy_Act). No data that breaks these laws or disrespects user privacy shall be stored without the user's explicit consent.

## Functioning

The player performs periodic measures related to the video playback but also computes metrics from its own runtime context like the [FCP](https://web.dev/fcp/), its loading time, and more. It then forwards all this info to a dedicated backend for later processing and analysis.

large_qos-and-qoe-workflow.jpg

medium_qos-and-qoe-workflow.jpg

small_qos-and-qoe-workflow.jpg

thumbnail_qos-and-qoe-workflow.jpg

qos-and-qoe-workflow.jpg

The objective is to gather enough relevant data about the "Where", the "Who" and the "How". The "Where" and the "Who" are quite important but are more "context" oriented. The "How" really refers to the QoE.

### The "Where"

Locate where videos are watched to know the distribution of the audience:

- The `continent` → *Is North America, the main continent in terms of audience?*
- The `country` → *How many videos are watched in France?*

GeoIP Databases allow retrieving the `continent` and the `country` based on the user IP.

### The "Who"

Identify the profile of devices used to watch the videos:

- The `device_type` → *Are CTVs representing a significant part of the audience in Asia?*
- The `platform` and the `browser` family or version → *When was the latest version of macOS released? What is the part of IE11 to clean legacy code?*

Even if it is not 100% trustable because it tends to be deprecated and it can be overridden, the `User-Agent` HTTP header exposes this info and provides, at least, good hints. There are some alternatives like [UA-CH](https://web.dev/user-agent-client-hints/).

For a given visit, having a `user_session` with the number of `views` helps to confirm that after consecutive video playbacks, the experience remains stable and great.

### The "How"

Understand the video consumption behaviours:

- The `rebuffering_time` → *Why is the engagement so low in Asia?*
- The `watch_time` → *What is the best moment to trigger an ad-break?*
- The `abr_max_rendition` → *Is the 720p more played when increasing the default player dimensions?*
- The `playback_error` → *Why are macroblocks appearing on Safari/desktop?*

There are a lot of factors that can influence video playback. Rebuffering is part of them but is the consequence of underlying problems: slow delivery, low user bandwidth, etc.

> A viewer who experienced a rebuffer delay that equals or exceeds 1% of the video duration played 5.02% less of the video in comparison to a similar viewer who experienced no rebuffering.
> 
> Source from [Akamai](https://people.cs.umass.edu/~ramesh/Site/HOME_files/imc208-krishnan.pdf)

But what is rebuffering? A `rebuffering` describes the moment when the video playback stopped because of an insufficient amount of downloaded video bytes *(buffering)* without any user interactions. Seeking or switching manually to another video rendition is not considered to be `rebuffering`.

In other words, `rebuffering` is an unexpected buffering lasting *N* milliseconds causing the video playback to stop.

The `watch_time` is a duration representing the time a user has watched a video. It can be associated with the `rebuffering_time` to compute the `rebuffering_precentage` during a `user_session`.

ABR (Adaptive Bitrate) algorithms choose the best video renditions according to user network conditions. The `abr_max_rendition` describes the highest video rendition reached when ABR is enabled.

Finally, the `playback_error` indicates which errors have occurred during the video playback to explain sudden disruptions or degradations within the network, transmuxing, or decoding.

## Conclusion

We've had a sneak peek at how QoE can be useful to drive operational decisions. Combined with the [Quality of Service](https://en.wikipedia.org/wiki/Quality_of_service) *(QoS)*, this data constitutes a powerful set of valuable information to continuously ensure that video playback is optimal.

At [api.video](https://api.video), we are committed to providing the best watching experience for all, no matter the location or the device. In another blog post, we will go through other side usages based on QoE data especially for observability to detect proactively issues and assess impact in case of outages. Stay tuned!

## Resources

- [https://www.akamai.com/blog/performance/enhancing-video-streaming-quality-for-exoplayer-part-1-quality-of-user-experience-metrics](https://www.akamai.com/blog/performance/enhancing-video-streaming-quality-for-exoplayer-part-1-quality-of-user-experience-metrics)

The benefits of measuring the video playback QoE

Benefits of measuring the video playback QoE

large_qoe-1.jpg

medium_qoe-1.jpg

small_qoe-1.jpg

thumbnail_qoe-1.jpg

qoe-1.jpg

## Responsive media on the web (ok, mostly responsive video)


As the web has evolved, building sites with media rich content has gotten more and more complex. We (as developers) are expected to build sites that are media-rich and engaging - but at the same time load quickly and work on many different platforms. This is a very hard balancing act that has been the focus of the web performance community...well since the beginning of the web.

In this post, we’ll focus on how media can be efficiently delivered on the web - we’ll focus mostly on video, but will use images as examples, as there has been a lot of work to make images fast for all devices and screens.


## Images

Images are a logical place to start when considering responsive media - I mean you could just consider them a single frame video!

When it comes to image delivery on the web, there are a lot of HTML native approaches to deliver images as small as possible - and properly sized for the device. Let’s use some examples with the ```<picture>``` tag to walk through how you can properly serve images responsively. Here’s the example from the MDN page:

```
<picture>
    <source srcset="/media/cc0-images/surfer-240-200.jpg"
            media="(min-width: 800px)">
    <img src="/media/cc0-images/painted-hand-298-332.jpg" alt="" />
</picture>
```
	
There are 2 images in the picture tag. The ```<img src>``` is the fallback for browsers that do not support the picture tag, and is the “image of last resort” in case the ```<source>``` images do not fit the criteria of the browser or space on the screen.

The ```<source>``` attribute describes alternative images that can be displayed. In the example above - there is a different image for screens where the screen width is over 800 pixels.  The idea is that a “big image” can be delivered to big screens, and a “small image” for mobile or smaller screens. We can use the picture tag with even more complex methods:  

```
<picture>
    <source media="(min-width: 1200px)" src="hero-large.webp 1200w" type="image/webp">
    <source media="(min-width: 1200px)" src="hero-large.jpg 1200w" type="image/jpg">
    <source media="(min-width: 800px)" src="hero-medium.webp 800w" type="image/webp">
    <source media="(min-width: 800px)" src="hero-medium.jpg 800w" type="image/jpg">
    <source src="hero-small.webp" type="image/webp">
    <source src="hero-small.jpg" type="image/jpg">
</picture>
```
	
In this example, we have 3 different versions of the same image - ‘hero-large’, ‘hero-medium’ and ‘hero-small’.  They are offered in 2 different formats: webp and jpg. While this is can lead to a great (and fast) experience for your customers, Iit does mean 6 different versions of each image must be created.

When the browser encounters the picture tag - it iterates through the options, and will use the first version of the image that meets all the criteria. If the browser supports webp, and the screen is over 1200 pixels wide, the first image will be used. If the screen is under 800px, and the browser does not support webp, the ‘hero-small.jpg’ will be used.

This is incredible - your website now supports 3 different screen sizes and 2 different image formats.  Of course, this means either the developers or the content management system must create 6 versions of each image that is uploaded - an extra development step, and potentially a lot more storage usage.

	
## Video

The video tag works in similar ways to the image tag when it comes to formats:

```
<video autoplay muted controls>
	<source src=”hero.webm” type=”video/webm”>
	<source src=”hero.mp4” type = “video/mp4”>
</video>
```
	
If the browser can handle webm videos - this format will be used, otherwise it will fallback to the mp4 (98.1% support in browsers today - and the last 1.9% don't support video at all).

In a soon to be published article, HTTP Archive data finds that using multiple source files is not used widely - less than 10% of video tags use this feature (on 7.6M webpages tested).  Even worse, of those that use multiple source files ~75% lead with the mp4, negating the presence of the other versions of the file (since the browser uses the first format it knows how to use, and all browsers know how to use a mp4.) This implies that only 2.5% of the video tags are correctly utilizing the source attribute to deliver different versions of the same video.

### No media queries

There are no media queries for video.  There *once were* media queries in the video specification, but they were removed, and support for media queries left Chrome in version 34 (In November 2021 Chrome is version 95).  So, the pattern we used to make images responsive will not work for video.


### Why were they removed?

When it comes to images, generating 3-4 different types of image can be tricky - which formats?  Which sizes? What is the process to generate - is it automated, or do you need to build a specialized upload process?  If your site has hundreds of images - you may now have thousands of images to store and deliver.

Video suffers from the same issues.  But videos - being generally more than one frame long - make the problem more immediate.  [Re-encoding](https://api.video/what-is/video-encoding/) a video takes much longer than reformatting an image - so the time to generate the files can be on the order of minutes (as opposed to a second or 2 for images). 

If you are using a CMS - it must know how to take an uploaded video, and turn it into several different sizes - with a couple of different formats.  If you are not using a CMS, guess what - it falls on you to learn how to re-encode the different sizes and formats for each video.

### Video doesn't work the same way

When you add an image to a webpage - it stays where it is.  It’s static.  If you download a huge image on a poor connection - it takes longer, but the page will still load.

Video is not static.  But since the ```<video>``` tag is markup, it cannot change what is rendered on the page.  

### Let’s consider a couple of use cases:

You have a ```<video>``` embedded on your page, and it renders at 600px wide.  Your page uses logic to choose and download a video source file that is optimized for a 600px space (saving a lot of data over the 'desktop' 1920x1080 video.)  

1. What happens when the user presses the “fullscreen” button?  
2. What if your customers have a chromecast, and they cast it to their 60” TV?  

The video sent to full screen/TV will be 600px wide, and will look pixelated. Even with media queries - there is no way to switch the video input without stopping the first download, and starting a new download.  If you are 15 minutes into the mp4  - the browser would have to have logic to figure out where that time is in the video.  Needless to say, this is not a good user experience.

3. What happens when you start a video, but then you move to an area with lower bandwidth?  

The video download will not be able to keep up with the video playback, and the video will stall.



## Responsive video: JavaScript player

Rather than create a myriad of different sizes and file types in the ```<video>``` tag, the solution is adaptive bitrate streaming (ABS), supported by a JavaScript player sitting on top of the ```<video>``` tag. We’ve described how [ABS streaming](https://api.video/what-is/adaptive-bitrate-streaming/) [works](https://api.video/blog/video-trends/responsive-video-delivery/) in  several posts. Esentially several different sizes of the video are created, and the video is delivered in short segments or chunks.  

The JavaScript player sits atop the video tag, and works as a controller for the video - monitoring both the screen size (and changes in screen size) and the network conditions.  When a change occurs that could affect the video playback, the player is able to make changes midstream to the video.  Since each chunk defines a timestamp in the video - switching midstream between different video qualities is a simple exercise for the player.

With ABS, jumping from 600p wide to full screen, or casting to a TV *just works*.  When the netwrork conditions deterioriate or improve, the player can adapt the playback quality to optimzie the experience for the viewer.

It is totally understandable to be hesitant in adding a new JavaScript framework to your page - we are so bloated in JS today (that's an entirely different topic) - but for a few hundred KB, the JS player enhances the video playback experience on all devices.  With a video that is specifically sized for mobile devices - the savings in video delivery is very likely to exceed the cost of the JS incurred on video setup.


## Conclusion

The video tag is amazing, and will continue to be the backbone of video on the web.  To make the video tag more responsive to various screen sizes, there are 2 possible approaches - reading media queries, or using a JavaScript controller to power adaptive bitrate video.

The media query approach solves one problem - but raises several more that impact the user experience.  The JavaScript player adds additional page weight, but delivers the video responsively, in a network-aware way.  We at api.video believe that adaptive bitrate video *is* the future of video, and the added weight of the JavaScript player to the video tag is a small tradeoff in exchange for providing stellar video experiences on the web.





Responsive Media: the right approach for images vs video 

Responsive media: The right approach for images is not the right approach for video

small_ResponsiveMedia.png

thumbnail_ResponsiveMedia.png

ResponsiveMedia.png

small_anthony.png

thumbnail_anthony.png

anthony.png

Anthony Dantard

Customers are "divinely discontent" and their expectations are constantly on the rise. Thanks to services like YouTube & Netflix, we all expect blazingly fast load times and smooth video playback for streaming on-demand video. What might be less obvious is that, whether we're aware of it or not, that expectation is slowly transferring to real-time video communication and live streaming applications as well.

At api.video, we're obsessed with delivering the best developer and viewer experience for our customers. So it's no surprise that we spend a lot of time thinking about and keeping up-to-date on video protocol development. Each video protocol has its strengths and weaknesses. Each is better suited for different applications. 

In this post, we outline four of the major low-latency protocols, talk about the pros and cons of each, and give our commentary on where we think the future of low latency streaming is going. We'll talk about the following protocols in depth in this post:

- WebRTC
- LL-HLS
- LL-DASH
- HESP

## WebRTC
The WebRTC protocol supports both audio and video streams for real-time bi-directional communication. It can be used for ingestion and distribution with an end-to-end latency between 300ms - 600ms depending on network quality and the distance between users. The protocol really took off in 2011 when Google bought Global IP Solutions, the company that originally developed the protocol, and gave the project significantly more human and financial resources. 

Ten years later, WebRTC has become the standard for real-time video communication on the web. The components that WebRTC is based on are accessible via a JavaScript API maintained by the W3C and the IETF, allowing users to live stream directly to a web browser without installation of any third-party tool.

In theory, WebRTC allows the establishment of a video conference system between 2 browsers by connecting them to each other peer-to-peer. However, in practice the architecture of computer networks (internet, corporate, and domestic) can greatly complicate matters.

large_webrtcprotocolstack.png

medium_webrtcprotocolstack.png

small_webrtcprotocolstack.png

thumbnail_webrtcprotocolstack.png

webrtcprotocolstack.png

### Finding your way through the internet labyrinth

In some cases, we are not directly connected to the internet and we are behind several network layers such as a NAT, a firewall, or a proxy. To get around these problems, WebRTC allows you to use the ICE (Interactive Connectivity Establishment) protocol. It allows you to find the most direct path to make two machines communicate and cross the different network layers. For this, a STUN / TURN server is necessary in order to obtain the external address of a user and relay the traffic if a direct connection is not possible.

The WebRTC protocol requires, in addition to its own multimedia server infrastructure, a STUN / TURN server infrastructure to operate communications in a production environment with real massive use.

## To further confuse the issue

The protocol specification requires that all data exchanged between peers must be encrypted (video, audio, data application). Thus, the protocol embeds several security protocols to fill the gaps of the UDP protocol when it's used. 

WebRTC uses SDP (Session Description Protocol) to expose some properties of the peer-to-peer connection like the types of media to be exchanged and their associated codecs, the network transports, and some bandwidth information.

Respectively DTLS (Datagram Transport Layer Security) is involved to generate Self-Signed certificates, for the negotiation of the secrets used for encrypting media data, and for secure transport of application data between peers. SRTP (Secure Real-Time Transport) is used for the transport of video and audio streams. The last security protocol involved is SCTP (Stream Control Transport Protocol), which is used for the exchange of application data.

### The challenges of WebRTC scalability

Several network architectures and topologies can be implemented to operate communications with the WebRTC protocol, each responding to a specific use case, with advantages and drawbacks specific to each topology. We will not dig into topology details in this article, but be aware that SFU (Selective Forwarding Unit) is perhaps the most popular architecture in modern WebRTC applications today.

The main challenge with this protocol is the scalability on a planetary scale that is cost effective. We are not saying that WebRTC can't be scaled worldwide, it was true a few years ago at its early stage but it's not true anymore thanks to the great improvements and work bring by some great companies to improve topology. 

As WebRTC is a mashup of several protocols that each have to be learned and mastered by engineers rendering it very complex. It's difficult for most companies to implement it in their infrastructure at a global scale in a cost effective way. That's why only a few companies have succeeded at making it fully scalable today. They do so by mixing SFU and MCU (MultiPoint Conferencing Unit) topologies, then putting it on the edge.

## Low Latency HTTP ABR streaming protocols

In contrast to WebRTC, which is a peer to peer protocol that, in theory does not require a central server to establish communication between two machines, HTTP-based streaming protocols require the use of a server and communication over standard HTTP. They are based on the very foundations of the web.

### HLS/LL-HLS

The HTTP Live Streaming (HLS) protocol can be used to deliver live and on-demand content streams to global-scale audiences and was introduced by Apple in 2009 with scalability in mind rather than latency. While the average latency faced by users is around 15s, the HLS latency can reach between 30s and 1 minute. Even with performant infrastructure and optimized packaging and player configuration, one can expect latencies of around 6s, which is just too high for real-time live video use cases. However it's still the most popular ABR streaming protocol. Its success is mainly due to its great compatibility with a wide range of devices and browsers and supports advanced features like closed captions, ads, and content protection with AES encryption or DRM.  

Although the protocol can also be used to ingest video, it's normally only used for distribution and then paired with the RTMP protocol for ingestion. Below is a typical live streaming architecture involving both the RTMP and HLS protocol.

large_rtmphlslivestreamingworkflow.png

medium_rtmphlslivestreamingworkflow.png

small_rtmphlslivestreamingworkflow.png

thumbnail_rtmphlslivestreamingworkflow.png

rtmphlslivestreamingworkflow.png

Without digging into the details of how HLS works (see our blog [articles](https://api.video/blog/video-trends/what-is-hls-video-streaming-and-how-does-it-work/) to learn more on this topic), below is a simple schema describing how playlists and media segmentation gives HLS the ability to do adaptive bitrate streaming (ABS).

Diagram of an HLS playlist and segmentation

large_hlsplaylistsmediasegmentation.png

medium_hlsplaylistsmediasegmentation.png

small_hlsplaylistsmediasegmentation.png

thumbnail_hlsplaylistsmediasegmentation.png

hlsplaylistsmediasegmentation.png

So how did HLS evolve to support lower latencies? In the beginning, HLS only worked with MPEG-TS container formats associated with the H.264/AVC video codec. In 2016, support for fragmented MP4 (FMP4) was added and this led to support for the CMAF format and compatibility with DASH distribution. One year later, HLS added support for H.265/HEVC (FMP4 only), which then allowed for a significant reduction in bandwidth usage.

Thus, Low-Latency HLS, an extension of the base HLS protocol, was finalized in April 2020 and enables low-latency video and live streaming by utilizing partial segments and on-the-fly transfer of those segments while maintaining HLS's inherent scalability. On the first draft of this extension, the protocol required the support of "HTTP/2 Push" which made it difficult to implement. Unsurprisingly, as major CDN vendors chose not to support this feature, killing the ability to scale LL-HLS, as none of the CDN players could cache the contents. Fortunately, Apple listened to community and industry concerns and came back with a new revision of the protocol extension, that removed the need for "HTTP/2 Push," but kept the need of relying on the "HTTP/2" protocol. They merged the spec into HLS making it fully backward compatible with the HLS specification and that also means that all features covered by HLS can be retrieved in LL-HLS. 

LL-HLS works practically the same way as HLS, but makes some important changes to reduce the latency in the packaging process. Below are the most important updates to the specification which make low-latency possible while preserving scalability and ability to do ABR streaming:

- **Partial Segments**: A segment is divided into Partial Segments or "Parts" of a few milliseconds which are referenced in the Media Playlist. These have a very short cache lifetime in contrast to the parent segment which can have a longer lifespan on the CDN. Once a complete segment is generated, its associated Partial Segments can be removed from the media playlist to reduce the bandwidth footprint.
- **Preload hints**: The media playlist can have a “Preload Hints” tag, which allows the player to know that new partial segments are coming so that the player can start to request them and the server will respond to this request as soon as the data is available.
- **Block Playlist Reload**: This feature avoids media playlist polling between the player and the server by adding query parameters to the request which inform the server that the player wants the response only when the playlist includes a new segment or partial segment.
- **Playlist Delta Updates**: Thanks to the new "EXT-X-SKIP" tag, a player can request just the updated part of the Media Playlist and save the transfer cost of the data that it already has.
- **Rendition Reports**: The "EXT-X-RENDITION-REPORT" tag added for each rendition line indexed in the Primary Manifest (aka: Master Manifest) provides some useful information for the Player to operate ABR such as the last sequence number and the last partial segment available for each rendition.

large_ll-hls-workflow-and-media-segmentation.png

medium_ll-hls-workflow-and-media-segmentation.png

small_ll-hls-workflow-and-media-segmentation.png

thumbnail_ll-hls-workflow-and-media-segmentation.png

ll-hls-workflow-and-media-segmentation.png

With current public cloud providers you can expect to reach an end-to-end latency in the range of 2s with appropriate Group of Pictures , partial fragments, and reasonable buffer size. While this is still much slower than what WebRTC can achieve, it involves significantly less complexity and is easier to implement in your existing live streaming architecture. You can also push the protocol to its limits by changing some settings and achieve a latency of around 1s, but this comes at the expense of stability and the quality of the playback experience.

### DASH/LL-DASH

DASH stands for Dynamic Adaptive Streaming over HTTP and was born in April 2012 by the work of the Moving Picture Experts Group (MPEG) in order to create an industry-standard alternative to the HLS protocol owned by Apple. It works similar to HLS in that it's based on the preparation of content at different quality levels and divides each video quality into several chunks indexed in manifest files to enable ABR streaming. 

It also supports content protection with encryption through Common Encryption standard (CENC) which makes it compatible with all common DRM systems.

The main difference between LL-HLS is that LL-DASH is completely agnostic of the codecs used for encoding video and audio streams. Unfortunately this codec freedom comes with the cost that LL-DASH is not compatible with Apple devices relying on iOS, including Apple TV.

In 2017, LL-DASH provided the necessary changes to the standardized protocol to decrease latency to 2s. Behind the scenes, it relied on the Common Media Application Format (CMAF). CMAF offers the ability to play with some useful HTTP features that can be used to decrease latency a lot. The two features that allow Low Latency for DASH with CMAF are "Chunked Encoding" and "Chunked Transfer Encoding" — both part of the HTTP/1.1 spec (prohibited in HTTP/2) that respectively allow you to break a segment into smaller chunks of a few milliseconds that can be sent to the distribution layer once encoded and this is where the "Chunked Transfer Encoding" feature take the relay to allow to distribute encoded chunks on the fly. However to operate this kind of delivery process, the whole distribution stack has to support the chunked transfer encoding feature from the origin right through to the CDN.

Diagram of LL-HLS workflow and media segmentation

large_dashll-dash2.png

medium_dashll-dash2.png

small_dashll-dash2.png

thumbnail_dashll-dash2.png

dashll-dash2.png

### HESP

The High Efficiency Stream Protocol (HESP) is another ABR HTTP based streaming protocol and is the most recent one of all. It was created by THEOPlayer through the HESP Alliance, whose main mission is to work on the standardization of the protocol and its promotion.

HESP has been developed with the aim of solving several of the main constraints of other HTTP streaming protocols. It's goals are:

- To reach ultra low latency(<500ms) while preserving scalability (i.e. it can still work with major CDN vendors)
- To reduce the bandwidth required during the streaming
- To reduce zapping times (zapping is the time it takes to switch between streams, think of it as changing the channels on cable television)

These three performance metrics have a direct impact on the user experience of the audience of a live stream. Given the extremely low latency, it can also be a viable alternative to WebRTC. The main drawback of HESP is that it's a proprietary commercial protocol and–for commercial use–it's quite expensive. Let's dig a bit into a technical overview of how it works.

The main difference with HESP in comparison to other low-latency protocols is that it relies on two streams rather than one. Before we go into the details of how these streams allow us to reach sub-second of latency, let's talk a bit about the different types of frames that are required when streaming video:

In video compression there are several types of frames:

- IDR-Frame (aka: Key Frame)
- I-Frame
- P-Frame
- B-Frame

Let's start with the I-Frame, you will better understand the others. An I-Frame contains the whole image and is coded without reference to any other frame except itself.

The key frame (or IDR-Frame) is a special I-Frame where no frame after the IDR frame can reference any frame before it. That being said, all IDR-Frames are I-Frames but not the other way around. The key frame is used by any player to be able to start a playback.

The P-Frame holds only the changes in the image from the previous one.

The B-Frame holds the changes between the current frame and both the preceding and following frames.

Now that you know the role of the different kinds of frames composing a video, we can go back to the streams that compose the HESP protocol:

- The first stream is called the "Initialization Stream" and contains only key frames.
- The second one is called the "Continuation Stream" and is like a normal encoded stream, meaning that it can contain all types of frames depending on the encoding parameters and defined profiles for maximum performance or maximum compatibility.

The Initialization Stream is used only for the start of the playback or when you slide on the video timeline to change the position of the playback. Because this stream contains only key frames, the decoder behind the player is able to instantly decode the frame and so start(or restart) the playback of the live event. Once the first frame is pulled from the first stream and decoded, the player switches automatically to the second stream to continue video playback. This is because key frames are complete images, so they have a high cost in terms of bandwidth. By switching to the second stream, the player falls back to a regular live streaming bandwidth footprint and profits from the CDN capability for scaling the audience and reducing the load to the origin.

As for DASH/LL-DASH, HESP works also with CMAF-CTE for packaging and distribution. It inherits from all the features such as encryption, DRM support, subtitles and captions, advertisements, and more.

large_hesp-workflow.png

medium_hesp-workflow.png

small_hesp-workflow.png

thumbnail_hesp-workflow.png

hesp-workflow.png

This protocol sounds revolutionary on paper, right? It does respond to many issues, it's true. But as with other protocols–and everything else in life–nothing is perfect and therefore it brings its own set of drawbacks and limitations.

The first drawback is that, as the protocol works with two streams which are encoded in sync, the encoding and storage cost is higher than the other HTTP based streaming protocols.

The second drawback is that even if it relies on CMAF-CTE packaging and distribution, the packager has to be updated to handle the two streams instead of one in the encoding and distribution steps.

Finally, as with the packager, the player must also be updated in order to be able to play with the HESP protocol and handle all of its subtleties.

And finally, last but not least, you have to pay royalties for any commercial use which inherently limits its adoption.

### So which protocol is the best?

The quick answer is none. What a helpful answer for making a choice, right?

The more complete answer is that it will depend heavily on the use case that you want to cover and the time and resources (both financial and human) you have at your disposal.

If your needs is to offer to your customers and audience the ability to live stream with a reasonable amount of latency (6s-15s), while remaining cost effective , we recommend you use HLS and/or DASH protocols as they can scale easily to millions of viewers. You can find many open-source libraries and streaming platforms that have implemented them very well. Our preferred choice, is HLS, as it has the largest footprint in terms of adoption and support across browsers and devices. It can be played virtually anywhere. (If you want to test it, you can try our live streaming service for free just by creating an account [here](https://dashboard.api.video/register)).

In the case that latency is critical for your business, you should look at low latency or even ultra low latency protocols. If you only needs mono-directional live streaming capability with a latency in the range of ~2s (e.g. for sport events, concerts, e-learning with students listening a teacher and can ask questions in a chat) and you don't have a big budget, you should look at LL-HLS and/or LL-DASH protocols.

For the remaining use cases where more than 1s of latency is not acceptable, you don't have many options left. It's either going to be WebRTC or HESP.

If you're a non-profit organization but need to serve a large audience or just don't want to have to build super complex infrastructure and don't have a lot of cash in your pocket, take a look at the HESP protocol.

In case you need bi-directional video communication, WebRTC has proven its ability to do it well, but if building an in-house infrastructure isn't part of your core business, you'll probably want to rely on a provider who already successfully built such an infrastructure in a scalable fashion. Be aware that the likelihood of having to pay a high cost is quite high. Since HESP Alliance's royalty fees are client-based and offer different packages to meet the fees, if you have a reasonable audience this can also be a good option for limited budget.

Finally, if money is not a concern, our choice would be HESP because it involves much less work compared to an implementation of WebRTC and is compatible with a wide range of devices and of browsers.

At [api.video](https://api.video) we deeply believe that HTTP-based Low or Ultra Low Latency streaming protocols will win this battle in the end. The reasons are quite simple, these protocols involve much less work to be implemented in a legacy infrastructure, profit from more support across devices and browsers, can scale more easily than WebRTC, and–as they don't have prohibitive licensing fees–they can be adopted by a larger number of companies. 

This is why we're building end-to-end Edge video infrastructure based on HLS. We're confident that, in the end, HLS will be the single streaming protocol that will meet all video streaming use cases in the near future.

The future of [ultra] low-latency video streaming

Ultra low latency for live streaming video

large_add-a-subheading.png

medium_add-a-subheading.png

small_add-a-subheading.png

thumbnail_add-a-subheading.png

add-a-subheading.png

Top 7 causes of streaming video buffering issues

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.

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. 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://api.video) to try it out. 

thumbnail_anne-sophie.jpg

anne-sophie.jpg

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

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

Our Zapier integration now features instant triggers

Updated: our Zapier integration now features instant triggers

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