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

## 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

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

dashboard-screenshot-api-video.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 - Video management made easy!

large_dahsboard.png

medium_dahsboard.png

small_dahsboard.png

thumbnail_dahsboard.png

api-video-dahsboard.png

## What is the Admin API?

The Admin API is a tool that enables you to directly manage your api.video projects and API keys through a secure API.

&nbsp;
 
It is a robust solution with a simple goal – to make it easy for you to manage your projects and thus your users, and their access to your platform on a programmatic level.

&nbsp;
 

With the Admin API tool, you can now: 

- easily automate the creation or deletion of users’ Projects
- manage a large number of projects with a single Admin API key without doing manual work in the [api.video dashboard](https://dashboard.api.video/overview)  

&nbsp;
 
_Watch the tutorial below to learn how to set up the Admin API._

### What are Projects?

_A ‘Project’ is a container within your workspace that allows you to isolate a set of videos, live streams, and player themes. Each Project holds its own API keys for authentication._
_Creating Projects is especially helpful if you want to create a clear separation between different customers, companies, or even working environments._

## Key benefits of the Admin API

The Admin API is built to enhance your control over your api.video environment.

- **Granular user segmentation and measurement**: With the Admin API, you can segment your user base more effectively. This is particularly useful when you need detailed insights into usage patterns and performance metrics across different user groups. By measuring usage at a more granular level, you can optimize your service delivery and tailor your offerings to meet specific user needs.
- **Enhanced multi-client management**: If you work with multiple clients, the Admin API allows you to provide each client with separate access to different projects. This ensures that clients can only interact with the projects they are authorized to access, enhancing security and simplifying project management.
- **Secure API key management**: The Admin API offers a secure way to create, update, and revoke API keys, ensuring that only authorized users can access your resources. This reduces the risk of unauthorized access and potential breaches.

## Getting started with the Admin API

If you’re an enterprise with a large number of accounts or customers as your end users, the Admin API is for you. Managing numerous APIs for various clients can quickly become cumbersome and inefficient. Manage API can be a game-changer for your operational efficiency. So if you have a large number of accounts/customers as your end users, Manage API can come handy to manage their APIs centrally.

&nbsp;
 
 
Integrating the Admin API into your workflow is straightforward. The [API is well-documented](https://docs.api.video/reference/admin-api-overview) and easy to use, with clear endpoints for managing projects and API keys. For any questions about the API, you can chat with us through our website or [talk to our team here](https://meetings.hubspot.com/apivideo/talk-to-us). 


Introducing the Admin API: A single API to enhance user management

small_Blog Cover.png

thumbnail_Blog Cover.png

admin-api-blog-cover.png

Did you know that once you become an [api.video](https://api.video) customer, you have the power to activate even more features?

&nbsp;

Yes, additional features we call ‘Add-Ons’.

&nbsp;

As it must be clear by the word itself, the Add-Ons offer you a wide set of ‘additional’ services that you can purchase to unlock the full potential of your video experience with api.video. The Add-Ons are primarily useful for teams looking to grow and scale faster.

&nbsp;

There are four Add-Ons that you get when you become a customer of api.video:

&nbsp;

- Projects
- Members
- Custom Domains
- Analytics

&nbsp;

Let’s look at them one by one.


## Projects

A ‘Project’ is a container within your workspace that allows you to isolate a set of videos, live streams, and player themes. Each Project holds its own API keys for authentication.

&nbsp;

Creating different Projects is especially helpful if you want to create a clear separation between different customers, companies, or even working environments. The way you choose to organize your videos, streams, and players with Projects will be completely at your disposal.


## Members

A ‘Member’ is any person who can access the api.video service. So, you can make others a member of your project and grant them the ability to access and contribute towards effective collaboration and communication.

&nbsp;

A ‘Member’ is any person who can access the api.video service. So, you can make others a member of your project and grant them the ability to access and contribute towards effective collaboration and communication.

&nbsp;

There are two types of members you can add to your projects:**

&nbsp;

**Owner**: One owner can be added to a single workspace and represents the person who owns the account. He/she can view the account's billing details, change the payment method, and is the only one that can transfer ownership.

&nbsp;

**Collaborators**: It is possible to add as many collaborators as you want per account, to a project. You can invite and work together with collaborators in the common workspace.


## Custom Domains

‘Custom Domains’ is a feature that lets you stream videos or live streams from your own domain (such as videos.yourdomain.com/ or livestreams.yourdomain.com/).

&nbsp;

It lets you brand your video URL, comply with network security and increase your SEO ranking.


## Analytics (Limited offer)

Analytics is an Add-On that allows you to see how your videos and streams are performing. It shows you the number of plays, how your videos perform in each country, device, and many other things through your dashboard.

&nbsp;

You can use this Add-On for free as a part of our free trial ending on July 28, 2023. 

&nbsp;

_Do [check it out ](https://dashboard.api.video/register)and use it to your advantage for these bonus days!_


## How are the Add-Ons helpful

Add-Ons can prove really helpful if you wish to optimize the complete potential of api.video. Here are some of the things you can achieve with Add-Ons:

&nbsp;

- Maximise your productivity by managing your customers via dedicated customer video libraries, and inviting collaborator members.
- Save on monthly fees by managing multiple production environments and accesses under a single workspace.
- Maximise your efficiency by facilitating coordination between your creators, editors, reviewers, and publishers, and encourage your customers’ firewall management with Custom Domains.
- Save the extra investment on Video Asset Management (VAM), Production Asset Management (PAM), and other Digital Asset Management (DAM) tools.
- Optimise your revenue by looking at the usage per project and maximizing the profit with your customers using Analytics.

## How to use Add-Ons for your business

Let me share examples of how Add-Ons can be used in three different industries. 

&nbsp;

**E-Learning:** If you are an e-learning platform or website, Projects can be useful to classify content and streams based on classrooms, teachers, or mandatory and pre-requisite learnings. Teachers or tutors of the platform can be added as Collaborators so that they can upload tutorials, lessons or conduct a class via live- streaming. Additionally, Custom Domains can help you manage multiple e-schools and their specific firewall requirements. 

&nbsp;

**Social Media**: If you are a social media platform, Projects can be helpful to classify content and streams based on brands and targeted destinations. Collaborators, who are often content creators, can easily upload videos via their dashboard, allowing non-technical people to assist in the process. Lastly, Custom Domains can be used to protect and maintain the brand identity through personalized domains.

&nbsp;

**Marketplace:** If you are a marketplace, you can use Projects to monetize your services based on your end customers' usage and maximize your profits. Influencers and content creators can be added as Members to your workspace and Custom Domains can be used to retain and establish the brand identity.

&nbsp;

To conclude, Add-Ons will be immensely helpful if you want to extract the maximum output from api.video tools. Use the Add-Ons to facilitate important business decisions, analyse your videos’ performance and collaborate for your ongoing projects.  

&nbsp;

_To try out Add-Ons before subscribing, [sign-up](https://dashboard.api.video/register) for a free via Sandbox account now!_

Unlock the complete potential of api.video using Add-Ons

addons_cover.jpg

Company News

At api.video, we recognize that large-scale organizations have unique and demanding requirements when it comes to video delivery and streaming. That's why we've developed a suite of advanced functionalities specifically designed to empower enterprises. 

&nbsp;
 
Here's a glimpse into what our [Enterprise](https://api.video/enterprise/) offerings entail.  

## 1. Increased upload API calls per minute

For enterprises that need to upload multiple videos simultaneously or frequently, being able to have uninterrupted uploads without delays becomes crucial. For this reason, and to avoid hiccups in your video upload journey, you get a higher number of upload API calls per minute as a part of our Enterprise offering. This is mainly to supports a high-demand environment, allowing you to maintain productivity, meet tight deadlines, and provide a seamless experience for your end users.

&nbsp;

As of now, [as per the Enterprise Plan](https://api.video/pricing/#features), your API rate limiting will be as follows:  

- **200 Upload API calls/min**

- **1000 Write API calls/min**

- **2500 Read API calls/min**

## 2. Detailed audit logs for up to 60 days

For an enterprise, audit logs are like those behind-the-scenes heroes ensuring your company stays secure, and accountable. They're your compliance buddies, making sure every interaction follows those pesky regulations and they also come handy when it comes to security, sniffing out any unauthorized access.

&nbsp;

[Audit logs](https://api.video/blog/product-updates/easier-troubleshooting-with-audit-logs/) in our Enterprise Plan are available for a period of 60 days to track user interactions and provide transparency by attributing actions to specific users. They aid in troubleshooting by detailing API activities and facilitating issue resolution. Audit logs also enable performance analysis, identifying usage patterns and areas for optimization. 

&nbsp;
 

The audit logs for your videos can be easily accessed via the api.video dashboard.



## 3. Signed MSA, SLA, and DPA

Apart from the basic contracts and agreements that you sign with us when you become our customer, we also offer signed Master Service Agreements (MSA), Service Level Agreements (SLA), and Data Processing Agreements (DPA). Here we go an extra mile to tailor these agreements to meet any specific needs you may have. Whether it's customizing service levels to ensure optimal performance, outlining data processing protocols for enhanced security and compliance, or defining the scope of our services to align with unique business requirements, these agreements will ensure that you have everything you need to move forward with your video journey.

## 4. SAML-based single sign-on (SSO)

Another very important feature that we have seen Enterprises requesting for, is SSO.  Our SAML-based Single Sign-On (SSO) feature simplifies user authentication by allowing your teams/employees to access api.video using their existing enterprise credentials. This integration not only streamlines the login process but also enhances security by centralizing authentication and reducing the risk of password-related breaches.

&nbsp;
 

Plus, it will be breeze for your IT teams to manage access permissions and keep an eye on who's doing what. With SSO, everyone wins – users, admins, and the company's bottom line. It's a no-brainer for any modern enterprise.

## 5. Guaranteed SLAs and credits

We maintain a Service Level Agreement (SLA) guaranteeing 99.999% uptime, ensuring unparalleled reliability at all times. This high level of availability ensures that your video services remain operational and performant, minimizing downtime and maximizing user satisfaction. Additionally, our SLA credits program provides added security by offering compensation for any potential downtime, ensuring you receive tangible returns for any service disruptions. 

## 6. Personalised support

If you have a large number of videos to migrate to api.video, or just a large volume to handle, there is a chance you get stuck during the process. With our tailored Enterprise Level Support, you’ll be prioritized to ensure the continuity of your operations, technical or operational. We’ll ensure a swift resolution of critical anomalies, both for migration of content and starting anew. 



## 7. Comprehensive security reviews

For the maximum security of your videos, we provide thorough reviews to ensure that our platform meets the highest standards of data protection and privacy. A dedicated security team continuously monitors and updates our systems to safeguard against emerging threats and vulnerabilities. Rest assured that your data remains secure, and also compliant with industry regulations.


&nbsp;
 

For more details on what our Enterprise Level support entails, [talk to our team](https://meetings.hubspot.com/apivideo/talk-to-us) or visit our [pricing page](https://api.video/pricing/). 

&nbsp;
 

_Explore the full potential of api.video and discover how we can help your enterprise thrive in the digital age. [Contact us](https://api.video/contact/) to get more precise information about our Enterprise Plan or [sign-up](https://dashboard.api.video/register) for a sandbox account to explore our features._

How api.video empowers enterprises with advanced assistance

api-video-enterprise-plan.png

Introducing ASICs-based encoding at api.video

ASICs-based encoding: Building a greener tomorrow through reduced carbon footprint

Beyond CPUs: api.video’s tech tale of switching from CPUs to ASICs

Empowering through values: api.video's core principles

Scaling up: How api.video empowers enterprises with advanced assistance

We're excited to announce the launch of a highly requested feature: **Workspaces**.

Anyone can now share their [api.video dashboard](https://dashboard.api.video/login) with a colleague or client. It's a great way to involve stakeholders in your projects.
Workspaces enable the primary account owner to invite unlimited team members to their dashboard securely, so they can help with video integration or add video content.

The new feature will allow multiple users to share videos and collaborate under the same roof, with a unique API key and unique billing.

> Just tried it out and sent a bunch of invites to my coworkers! We're all very excited about this feature. Thank you for being so attentive to our needs.

Michael, Senior Software Engineer from TractApp

## Why would I want to share my api.video dashboard?

### Manage different clients
You are an agency, and you need a separate api.video accounts to facilitate usage and billing management.

You can set up a different Workspace for each client as an account holder.
To do so, create a new workspace, give it a name, and add billing information.

### Integrate video in my app, website, or software

You need to integrate on-demand video or live stream into your app or software. By inviting your dev team to your Workspace, they will access the API key and all features included in your plan. 

You can easily give team members access to your Workspace. This is helpful if you typically have more than one person working with you on video content and development.

## Owners vs. Members

'Owner'status is automatically assigned to the user who created the organization. All new invited users are ‘Members.’

Owners and members have the same access rights. The owner cannot be removed from the Workspace. However, the owner can transfer his Workspace to another member.

Once you’ve invited a user to your Workspace, they can edit any video content and access the API key. Invitees will only have access to the Workspace from where the invite was sent. If you would like a user to have access to different workspaces, you will need to invite them to each one. 

As an account holder, you have access to everything except team members’ personal Workspaces.


## Receiving invoice emails

The workspace Admin will receive an invoice email monthly.


Have questions about Workspaces? Contact us on the chat or [our Community](https://community.api.video/).
The Workspace feature is the beginning; stay tuned! 

Introducing Workspaces

api-video-workspace-feature.png


If you have kids or know anybody that has kids, then you’ve probably been exposed to the frustration surrounding the rapid and non-optional transition from a classroom learning environment to a remote one.

One of the primary sources of frustration for teachers and parents stems from the need for teachers and students to adopt new technology with which they are unfamiliar.

**Imagine that you are a developer in the booming field of e-learning. Since you are smart, one of your primary goals is to make the interface as self-explanatory and straightforward as possible for teachers and students.**

To accomplish that, you may decide that each student or teacher who logs in should, by default, see only videos relevant to them on their dashboard.

Implementing such customization may seem like a herculean task. After all, you’ve got hundreds of teachers and students and thousands of videos.

Don’t fret. It’s quite easy with api.video’s API.

Let’s dive in!

## A bird’s eye view

Before looking at any code, let’s restate the problem. I’ll begin with the teacher's use case.

**Problem:** We have many teachers uploading videos, and we want each teacher to see only their videos on their dashboard.

**Solution:** We make use of api.video’s **tagging** feature on our backend.

There are two reasons for this:

1. We want to make this as simple as possible. This implementation is entirely invisible to the teachers and requires no action from them, not even a checkbox.
2. Having implemented a login on our backend means that we are holding a unique identifier (i.e., username, id) for our logged-in user. That makes tagging and accurate retrieval a breeze.

## Upload

For simplicities sake, let’s assume that students and teachers share a table in our database that looks like this:


When a teacher logs in, we query this table to authenticate them. It’s trivial to grab the unique username at the same time.

Every time the logged-in teacher uploads a video, we include their “username/tag” in the ‘Create video’ request we make to the api.video API.

When [creating the video](https://api.video/blog/tutorials/video-upload-tutorial/), you can include tags in the request body like so:

An amazing video explaining the string theory

Maths video

We can take this a step further, allowing the teacher to select which course they are uploading the video to and adding a tag for that as well.

**Retrieving the users' videos**
Every video is now associated with the unique identifier of the uploader. When a teacher logs into his video dashboard, all we need to do on the backend is to add their unique identifier to the query string when requesting the video list from api.video’s API.

For example, if the teacher’s unique tag is “einstein,” our request would look like so:

Our backend would get a response from api.video’s API that looks like this:

We can then handle that response however we’d like, passing on to the client app whichever properties we choose, confident that this user uploaded these videos.

**What about the students?**
Applying the above technique to provide each student with a video dashboard tailored to them is simple.

Let’s say we have a table for courses that lists all the essential info for each course.

When a student logs in, it’s a simple query to get the tags of all their courses:

With this information, we can display a friendly UI allowing the student to choose which course they would like to see from a personalized course list.

audacity.png

Based on their selection, we’ll request their videos from our backend with the appropriate tag attached.

We can then pass the required fields from the response back to the client UI.

audacitydashboard.png

That’s all folks!

I hope you’ve got the picture. Remember, our community is here for you at [community.api.video](https://community.api.video), and you can always reach out to us at hello@api.video.

Thanks for reading!

Creating unique video dashboards for individual users

large_dashboard.jpg

medium_dashboard.jpg

small_dashboard.jpg

thumbnail_dashboard.jpg

dashboard.jpg

The [api.video dashboard](https://dashboard.api.video) is the first step to getting started with our API - whether you are accessing your API key for the first time or quickly uploading a video on the fly. The second step is implementing the API into your app or product. 

Our goal is to help you quickly implement video into your app by facilitating communication between the two services.

facilitate communication between the two services.

untitled.png

A little over a year ago, we released our [first iteration on webhooks](https://api.video/blog/product-updates/new-feature-webhooks/) which enabled developers to receive events when a **video quality had finished being encoded**.

This opened up a series of potential use-cases enabling product builders to know when a user’s video is ready to be watched. Once a video is ready, using webhooks, you can build follow-up actions to give your users a better experience. 

We later introduced other events for you to capture, such as **when a user starts and stops broadcasting a live stream** or when a **live stream has finished being recorded.**

But up until now, setting up webhooks was only doable through the API. This could be done by making a curl request on the command line or by building your own custom form to make things easy.

## Sometimes you just need a form.

You can quickly set up the endpoint to receive live events from api.video, saving you precious development effort and time.

set up the endpoint to receive live events from api.video

untitled-2.png

Along with the action of creating webhooks, you’ll also find a new webhooks list and delete actions to help you deal with your endpoints without the hassle of code implementations.

screenshot-2022-04-07-at-12-20-13.png

## Shortcut to the important stuff

Once you’ve set up your first webhook endpoint, you can now focus on building the workflow when receiving the event. 

Here’s an example of data your newly set up endpoint will receive when the quality has finished encoding.

Learn more about what you can do with webhooks from our blog [webhooks articles](https://api.video/blog/endpoints/webhooks/) or our [docs](https://docs.api.video/reference/api/Webhooks#create-webhook).

## More to come

Over the coming months, we’ll be making more and more enhancements to our Dashboard, making it even more straightforward for you to create your dream video features. 

We hope these changes make it faster and easier to manage your webhooks and speed up implementation. We’re constantly working to make the Dashboard more productive for you — [please send us ideas and feedback](https://community.api.video) on what we should improve next!

Setup Webhooks from your api.video Dashboard to save time

large_webhooks_dash.png

medium_webhooks_dash.png

small_webhooks_dash.png

thumbnail_webhooks_dash.png

webhooks_dash.png

Setup Webhooks from your api.video Dashboard: a feature to save you time.

Introducing our new dashboard

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

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-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! 

Video on demand

Live streaming

Analytics

Video infrastructure

Video player

AI features

See all features

Online learning & Corporate training

Social & Entertainment

Marketplace & E-commerce

Communication & UGC

Generative AI

Quickstart guides

Documentation

Ecosystem catalog

Clients & SDKs

Community

Blog

Demos

Customer success stories

Help center

Blog

AI >< Video: The Video Model Hub unveiled