Normal

large_logo_avatar.webp

medium_logo_avatar.webp

small_logo_avatar.webp

thumbnail_logo_avatar.webp

logo_avatar.webp

api.video

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

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

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

## What is video encoding?

large_poster-1_2.png

medium_poster-1_2.png

small_poster-1_2.png

thumbnail_poster-1_2.png

poster-1_2.png

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

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

## Why is video encoding used?

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

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

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

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

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

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

## Differences between video encoding and video transcoding

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

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

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

## Examples of video codecs

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

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

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

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

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

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

## How do different technologies handle video encoding

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

### Video editing software

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

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

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

### Websites

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

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

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

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

### API

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

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

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

## Conclusion

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

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

A Guide to Video Encoding & Video Codecs

large_poster-3.png

medium_poster-3.png

small_poster-3.png

thumbnail_poster-3.png

poster-3.png

Erikka Innes

4K has been around just long enough for some of us to want the next best thing and when it comes to resolution, we may be approaching our limit. That might sound strange at first, if you've heard about Roger Clark's project to find out how many megapixels the human eye can see. By his calculations, you can see up to 576 megapixels. 8K only creates 33.17 megapixel images, so what gives? We should be able to see a lot more.

&nbsp;

The answer in the way the human eye processes visual information. The way it's designed, you can only see with the kind of clarity required for a 576 megapixel image with a tiny part of your eye called the fovea. 
It lies at the center of your visual field and covers about 1% of the retina. Amazingly, about 50% of the part of your brain that's for visual processing focuses solely on details received from the fovea! What is more, in the very best of lighting conditions for your eye, with someone with the very best vision, that person can only see about 1/60th of a degree with their fovea. This is the equivalent of a dot .07 inches across and 20 feet away! 


## Okay, So Can We See 8K? 

If that's how we see, can our eyes detect 8K? Do we need 8K if it's just a tiny part of your eyeball that can really see with the incredible level of detail you'd need to enjoy 8K in an image? The answer is...it depends. If you're going to sit at home on the sofa and stare at a TV, then no, probably not. According to Paul Maguire, you'd have to sit less than 4.2 feet away from your 65 inch TV or 3.6 feet away from your 55 inch TV to see all the detail in 4K. For anything greater than 4K you'd have to sit less than 3 feet away. Which is liable to irritate any other viewers in the room that wanted to see the screen around you. This doesn't mean 8K resolution isn't useful. 

## Benefits of 8K

8K is potentially beneficial for recording video. If you have 8K quality, you can zoom in on parts of your shots and still have 4K quality or better. It can allow someone shooting to have more choices from every shot because the quality will still be very high. 

8K is also great creating intensely realistic, immersive experiences. If you have a wrap around TV or a planetarium, or virtual reality goggles, 8K is amazing. It allows for the rendering of softer, more realistic edges. It increases the realness of a scene because the human eye can't see any pixelation. 


## Conclusion

For virtual reality, 8K will probably become the standard. As for becoming the standard for streaming video, probably not for a while. It's not necessary in many cases, and at this time it's also difficult to stream at that level and know it will arrive at its destination as 8K. Someone streaming in 8K would likely end up outputting to lower resolutions based on the wide range of viewing devices users have.

&nbsp;

_api.video upload your videos up to 4K, with fast encoding and a worldwide delivery. You can [test it for free](https://dashboard.api.video/register) and start building your video project or check [our Community](https://community.api.video/)_.


What kinds of video experiences are best with 8K?

Can the human eye see 8K resolution and when is 8K most useful?

large_can-the-human-eye-see-8k-resolution-and-when-is-8k-most-useful.png

medium_can-the-human-eye-see-8k-resolution-and-when-is-8k-most-useful.png

small_can-the-human-eye-see-8k-resolution-and-when-is-8k-most-useful.png

thumbnail_can-the-human-eye-see-8k-resolution-and-when-is-8k-most-useful.png

can-the-human-eye-see-8k-resolution-and-when-is-8k-most-useful.png

live - create

doug.jpg

twitter-brands.svg

Doug Twitter

Doug Sillars

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

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

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

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.  

&nbsp;  

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.  

&nbsp;  

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.  

&nbsp;   

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.  

&nbsp;  

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.  

&nbsp;  

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.  

&nbsp;   

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.  

&nbsp;  

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.  

&nbsp;  

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.  

&nbsp;  

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](https://api.video/blog/video-trends/what-is-DRM/).  

&nbsp;  

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

rtmp-hls-live-streaming-workflow.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

hls-playlists-media-segmentation.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.  

&nbsp;  

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.  

&nbsp;  

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.  

&nbsp;  

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

&nbsp;  

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.  

&nbsp;  

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.  

&nbsp;  

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)  

&nbsp;  

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.  

&nbsp;  

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:  

&nbsp;  

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.  

&nbsp;  

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.  

&nbsp;  

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

&nbsp;  

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

&nbsp;  

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.  

&nbsp;  

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.  

&nbsp;  

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.  

&nbsp;  

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.  

&nbsp;  

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.  

&nbsp;  

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.  

&nbsp;  

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?  

&nbsp;  

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.  

&nbsp;  

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)).  

&nbsp;  

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.  

&nbsp;  

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.  

&nbsp;  

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.  

&nbsp;  

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.  

&nbsp;  

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.  

&nbsp;  

At [api.video](https://dashboard.api.video/register) 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.  

&nbsp;  

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

small_The future of [ultra] low-latency video streaming.png

thumbnail_The future of [ultra] low-latency video streaming.png

The future of [ultra] low-latency video streaming.png

api-video-blog-product-updates.png

Product updates

After hearing from our customers about the need for low-latency live streaming, we at api.video have been relentlessly chasing seconds of latency everywhere, from ingest to delivery. Having already provided the best performance for on-demand delivery in terms of playback and [encoding](https://api.video/blog/product-updates/video-encoding-pricing-update/), we're excited to announce our latest upgrade: low-latency live streaming!

&nbsp;

Keeping true to our core belief of making video easy and manageable for you, we've rolled out our live streaming product with latency as low as 3 seconds in best conditions. Now, you can stream your videos with a latency of 3 seconds in ideal conditions, revolutionizing the way you connect with your audience.

## What does this mean for you?

With this latest upgrade, you can stream your videos live with a minimal delay of 3 seconds. This means that you can ensure better interaction with your viewers, lower bounce offs due to viewer frustration and a smoother viewing experience. 

&nbsp;

Additionally, you also get the flexibility to push a live stream using Real-Time Messaging Protocol (RTMP) or Secure Reliable Transport [(SRT)](https://api.video/blog/product-updates/SRT-livestreaming/) protocol based on your needs. 

&nbsp;

[*How do you choose between SRT or RTMP protocols? Read on!*](https://api.video/blog/video-trends/srt-vs-rtmp/)

## How can your business benefit from low latency?

Several use cases benefit significantly from low latency in live streaming:

### 1. Esport live streams
Low-latency live streaming is crucial for esports viewing as it ensures real-time action with minimal delay, providing a more immersive and engaging experience for fans. It allows viewers to stay in sync with live events, participate in interactive chats, and react instantly to game-changing moments. This immediacy becomes crucial to build the excitement and zeal of watching an esport live, making viewers feel as if they are right there in the arena.

&nbsp;

Additionally, top level games that are being broadcast all over the globe and possess official data feeds are where the issues of latency have the biggest impact. It can be unfair for punters who are watching and betting on the event as the stream does not reflect what is actually happening on the field. 

&nbsp;

As opposed to online gaming where latency as low as 25 miliseconds is ideal, esport broadcasting industry usually has a [latency of under 10 seconds](https://sbcnews.co.uk/features/2021/07/27/how-latency-stream-delay-work-esports/).

### 2. Live events and concerts

For virtual concerts, conferences, and other live events, low latency is crucial for delivering a seamless viewing experience to remote audiences. By minimizing delay, organizers can create a sense of presence and immersion, allowing viewers to feel like they're part of the action, even from afar.

### 3. Webinars and workshops

Low-latency live streaming can significantly enhance webinars and workshops by providing an  interactive experience for participants. With reduced delay between the presenter and the audience, feedback, questions, and discussions can take place with ease. The low latency here helps instructors or guest speakers of the webinar to adapt their content on the fly based on audience input. In case a webinar is being streamed live and is also happening in-person, the minimal delay for the virtual audience keeps the whole event synchronised.

### 4. Telehealth and live patient monitoring

A good usage of low-latency lives treaming in the healthcare industry is for remote patient monitoring and live consultations. These demand streaming capabilities with minimal delays to ensure the highest quality of care. For individual healthcare professionals and hospitals that offer this service, being able to monitor and interact with patients live is crucial for accurately assessing symptoms, providing diagnoses, and making treatment decisions within time. Delays or interruptions in the video feed in this scenario may hinder the communication between patients and providers, which shows the relevance low-latency live streaming holds in this space.

## How to live stream with api.video: Step-by-step guide

- In order to establish a video live stream, you must first create a live stream container at api.video.
- Then, you can begin streaming with the tool of your choice.
- For this guide, we’ll see how you can [create a live stream with OBS](https://api.video/blog/tutorials/live-stream-tutorial/) – free and open source software for video streaming. 

### **Step 1: Authenticate**

You need an access_token in order to create and upload a video.

&nbsp;

You will need your API key to obtain the access_token. You’ll find your API key in [your api.video dashboard](https://dashboard.api.video/overview).

&nbsp;

(This guide uses the sandbox endpoint. To upload your video in production, simply replace all `sandbox.api.video` instances with `ws.api.video`.)

&nbsp;

First, call the authentication endpoint and get your access token.
&nbsp;

**Example - Curl Request**

### **Step 2: Create the live stream**

Now we [create the live stream](https://docs.api.video/reference/api/Live-Streams#create-live-stream). In the JSON parameter, feel free to edit the name of the live stream from "Your Stream Name" to whatever you want to name your stream.

&nbsp;

**Example - Curl Request**

Your Stream Name

Now the server is ready to accept our live stream, and once broadcast begins (JSON above shows broadcasting:false), it will be viewable on the URLs listed in the JSON response.

### **Connecting live video**

The JSON response above lists your live stream's streamKey, which will be needed in OBS to connect your video to the server.

&nbsp;

Now in the OBS application,

1. Establish a source. In the sources section, choose a video feed to share. You could choose to share your screen, or to share your camera (on a Mac: Video Capture Device, and then in the "Device" dropdown choose the camera). You should now see the video source in the main OBS window.
2. Connect OBS to api.video. Under Settings, choose Stream. You'll see a choice for service - choose custom.
3. The server should be `rtmp://broadcast.api.video/s` and the `streamKey` is the value you received in the Json when you created the stream. Click OK to accept the changes.
4. Press ‘Start Streaming’.
5. Share the embed, iFrame, so that others can watch your stream!

## Player support for low-latency live streaming

We are pleased to announce that our low-latency live streaming feature has been thoroughly tested with several popular video players to ensure optimal performance and seamless integration. The players we have tested include:

&nbsp;

- api.video embed player
- THEOplayer 7.4.1
- Video.js 8.14.0
- hls.js 1.5.11
- JW Player 8.34.1

&nbsp;

These players have been verified to support low-latency streaming. However, if you encounter any issues with a specific player, please reach out to our support team through chat with detailed information about the problem.

&nbsp;

We highly value and appreciate any feedback you can provide to help us improve our services. Your insights and experiences are crucial to identifying potential issues, enhancing features, and ensuring the overall quality and performance of our product. 

&nbsp;

_To start live streaming with api.video, [sign-up](https://dashboard.api.video/register) now! For questions, [talk to our team](https://meetings.hubspot.com/apivideo/talk-to-us) and we’ll try to answer your queries._

Stream smarter, not slower: Introducing low-latency live streaming

Low-latency live streaming with api.video

small_Low latency livestreaming with api.video (1).png

thumbnail_Low latency livestreaming with api.video (1).png

low-latency-live-streaming-api-video.png

Tutorials

How do you make sure that your live stream viewer stays **engaged**? what are the tools that you can leverage in order to make **the most out of the experience**? and how can you **analyze the viewer's reaction**?  

&nbsp;  

In this article, you can learn about the way you can integrate real time communication into your live stream in order to make an engaging user experience with your live streams.  

&nbsp;  

Although we will only learn how to share emojis between viewers in your live stream, you will be able to leverage the example in order to build **robust analytics** that will provide you **great insight into when and how the viewers reacted to the stream**.  

&nbsp;  

We’ll leverage api.video with [Ably](https://ably.com/) to create a real time communication scenario where one viewer of the live stream will post an emoji, and all of the other viewers of the same live stream will be able to see the reaction.  

&nbsp;  

Check out the diagram below on how this works:

## Why do Livestream viewers need to be engaged?

Live streaming is growing at a very rapid pace. Let’s talk statistics:

- Did you know that the revenue for the entire video streaming app industry reached **$82.3 billion in 2022**, and is projected to reach **$115 billion by 2026.** according to some resources it’s going to be **$118 billion by 2025**. ([Business of Apps](https://www.businessofapps.com/data/video-streaming-app-market/))

- Live commerce-initiated sales could account for as much as **10 to 20 percent** of all e-commerce by 2026 ([McKinsey](https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/its-showtime-how-live-commerce-is-transforming-the-shopping-experience)) and **41.2%** of consumers said they tune in to live streams focused on home products, and **37.5%** said they watch [live shopping events](https://tinuiti.com/blog/paid-social/live-shopping-tips/) for electronics ([Retail Touchpoints](https://www.retailtouchpoints.com/topics/digital-commerce/livestreaming-update-coresight-debunks-5-common-myths)).

- In 2022, there were **532 million** esports viewers worldwide ([Insider Intelligence](https://www.insiderintelligence.com/insights/esports-ecosystem-market-report/)).

- **52%** of live video viewers stream content through social media ([eMarketer](https://www.insiderintelligence.com/content/livestream-viewers-social-media)).

- Brands earn nearly **40%** more engagement with Instagram Reels compared to other Instagram content formats ([Business Wire](https://www.businesswire.com/news/home/20220907005644/en/Brands-Earn-Nearly-40-More-Engagement-with-Reels-Compared-to-Other-Instagram-Content-Formats)).  

&nbsp;  

And this is just a small part of some impressive live stream and video content statistics. So you ask yourself, how do I start integrating livestream into my app or website? 

## How to build a scalable and engaging live stream quickly?

What we’ll be leveraging:
- **api.video** to create and deliver the live stream
- **Ably** for the real-time communication handling
- For streaming, you can use **OBS**, [one of our live streaming SDKs](https://docs.api.video/sdks/livestream/react-native-livestream-component), or stream directly from the [api.video dashboard](https://dashboard.api.video/overview)  

&nbsp;  

With api.video, you can integrate livestream into any project in a few minutes. You can find the article on how to get started here: [Create a live stream](https://docs.api.video/live-streaming/create-a-live-stream).  

&nbsp;  

We’ll start with this simple example that was built using Next.js. You can go ahead and clone it from here: [Live stream with Ably](https://github.com/apivideo/livestream-with-realtime-ably).  

&nbsp;  

Let’s break it down; what are we looking at here? 

### The api.video React Player module

We are using api.video in order to create a stream and then the [api.video React player SDK](https://api.video/catalog/react-js-player/) in order to create a responsive on-screen video delivery while removing the control elements.  

&nbsp;   

If you navigate to the `src/pages/index.tsx` file, here’s where we consume the player and buildout the video delivery:
- We consume the api.video React player SDK here: `import ApiVideoPlayer from '@api.video/react-player';`
- And we pass it as a component to be rendered:

_**Disclaimer! In this example, the streamId is hardcoded in the index file, however, you’ll probably want to serve the streamId dynamically from your backend when you get to production.**_  

&nbsp;  

You can notice that we are passing the `ApiVideoPlayer` component all of these parameters; let’s break it down a bit; I’ll focus on the important ones:
- With Style, we are passing CSS parameters in order for the video to fit the screen first while the `size` parameter is dynamic, as `size` is a state:

Each time you resize the window, the video player size will adapt to the size of the screen.

- `chromeless` parameter removes all the player controls, which will give the user a better experience.
- With the `video` parameter, we are passing an object that includes the stream id and the optional parameter `live` that is set to true in order to give the player the indication that we are passing in a live stream and not a video  

&nbsp;  

Getting the live stream id can be done in two ways.  

&nbsp;  

### Programmatically:

1. You can leverage the livestream endpoint in order to get the list of livestream ids from your workspace: [GET Livestreams](https://docs.api.video/reference/api/Live-Streams#list-all-live-streams).

2. You’ll get a JSON response from which you can get the stream id you need:


### Manually from the dashboard:

1. Click on the live stream in Live Streams

You can find more information about the api.video React Player in our documentation: [api.video React player](https://github.com/apivideo/api.video-react-player).

### Everyone loves Emojis!

Now let’s get to the fun part; the example gives you the ability to share emojis between all the viewers of the stream; each person in the stream gets an emoji picker; once the emoji is clicked, a cool little animation will play where the emoji is hovering and then disappearing. The cool thing about that is that the animation will be played to all the viewers.

This example is very basic; however, you can take the example and **expand** on it in order to create **real time statistics** for the live stream session, for example: 
- Count the reactions from the users
- Map the different reaction emojis and get the timeframe with the most reactions
- Get real time feedback from the users
- And more...  

&nbsp;  

The emoji animation is built with [React Simple Animate](https://www.npmjs.com/package/react-simple-animate), it has a bit of complex logic, but you are free to reuse it in your app. You can find the actual animation parameters in `src/utils/randomframevalues.tsx`  

&nbsp;  

The random values are being passed to the `<AnimateKeyframes>` component that includes the actual emoji:

Go ahead and play around with the random values and the parameters, should be fun 😃

### Spread the emojis

And now we get to the challenge, how do you get these emojis across to all other users? this was an interesting task, but with Ably, it wasn’t that difficult to implement.  

&nbsp;  

We created a new class that is called `MessageHandler` where we use the Ably node library: `import Ably from 'ably';`  

&nbsp;  

Ably has a great API that allows you to create channels, get users to subscribe to them, and then broadcast and listen to any events that happen inside these channels; that’s a great fit for our use case!  

&nbsp;  

In the example, all you need to do is to replace the values of the `#apiKey`  with the one that you get from Ably:

**Disclaimer! Please note that these keys should be consumed from the backend. In this example, just to make it easy, we expose the keys on the front end. Please ensure that the backend serves the keys when you go to production.**  

&nbsp;  

**Briefly on what we are doing in the `MessageHandler` class:**

When we use Ably there are a few things we need to understand and utilize:
- Channels
- Users
- Subscriptions (listeners)
- Message publishing  

&nbsp;  

Every time the user opens a new window, they will be assigned a user id for a session (this logic works in the `index.tsx` file); the userId is passed to the class when it is initialized in order to create a unique user id for each user that watches the stream.  

&nbsp;  

Then we use the stream id as the channel id for Ably, of course, you can generate any channel id, however, it’s easier to just leverage the values that we already have.  

&nbsp;  

We then subscribe to the same channel and also broadcast the messages to it at the same time.  

&nbsp;  

The caveat is that we set the listener in the `/src/components/emoji.tsx` file, if you look closely at the listener, we have a logic that will make sure that the listener is not getting duplicated. We check if there are no listeners created already; if there aren’t, we create one. This situation is caused by the fact that each time the state changes, React will re-render and will run the same code again, causing the listener to be created multiple times, so we do something like this:

Finally, we have two functions to generate the message (which will include the emoji) and publish the message to the channel.  

&nbsp;  

Now that you know how it works, you can run the example and play around with it.
- Just make sure to install all the dependent modules by running `npm install` or `yarn install`
- After the installation is done, run the example by `npm run dev`
- The example will run on `localhost:3000`  

&nbsp;  

Happy Hacking! 🙂  

&nbsp;  

If you have any questions about the article, feel free to raise issues on the [Github repo](https://github.com/apivideo/livestream-with-realtime-ably), reach out to me directly: artem@api.video, or just open a ticket with our support team.

Boost your live streams with user engagement & real time data

Boost your live streams with user engagement

live-streams-boost-user-engagement.jpg

SRT vs RTMP: Which one to choose for your livestream?

Choosing the right bitrate for your OBS live stream

Boost your live streams with user engagement 

A few months ago, my colleague Yohann wrote a fantastic article on [How to create a React Native live streaming application for mobile targets](https://api.video/blog/tutorials/how-to-build-a-live-streaming-app-in-3-steps/). This time, you will learn how to create the same application with a React Native competitor: Flutter.

In this article, you will develop a live streaming application in Dart. For further details, check out our official [Flutter live stream repository](https://github.com/apivideo/api.video-flutter-live-stream).

## **Few words about Flutter**

Google developed Flutter in 2015. In 2021, it was the most used cross-platform mobile framework (42% against 38% for React Native, [source](https://www.statista.com/statistics/869224/worldwide-software-developer-working-hours/)). It is used to develop cross-platform applications (including iOS and Android) quickly. The main difference between Flutter and React Native is that Flutter compiles Dart code to native bytecode/libraries, whereas React Native uses an engine to interpret JavaScript or TypeScript code. If you haven't heard of Flutter, you can learn more on the [Flutter website](https://flutter.dev/). 

## **Getting started**

First, follow the development setup steps from [Flutter's official documentation](https://docs.flutter.dev/get-started/install).

If you're new to Flutter, you may also need to [learn the basics](https://docs.flutter.dev/get-started/codelab).

*Quick reminder: iOS development is only enabled for macOS users. If you're on Windows or Linux, you can develop for Android.*

### **Create a new Flutter app**

1. Open Android Studio.
3. You should see a “New Flutter Project” button. Click on it.
5. Verify the Flutter SDK path and click on “Next.”
7. Enter your project name: “live_stream_app” (according to the [pubspec documentation](https://dart.dev/tools/pub/pubspec#name), the name must be lower_case_with_underscore.)
9. Make sure the project type is set to Application.
11. Click on “Finish.”

### **Launch the application**

Once Android Studio is launched, you can directly run your application with the control toolbar:

1. Select your phone.
2. Click on the *Run* ▶️ icon.

It will take several minutes to finish, stay calm and grab a coffee ☕️

When the application build completes, it will be launched on your phone. Check your phone 🤳🏾

🎉🎉🎉Congratulations, you have created your first Flutter application 🎉🎉🎉  

&nbsp;  

#### **Signs your iOS application (optional)**

If you have trouble building the application for an iOS device, it might be because the application is not associated with a development profile.

Open Xcode, click  "Open a project or file," and open the `Runner.xcworkspace` located in `live_stream_app/ios.`

Click on Runner, go to the `Signing & Capabilities` tab, add your team, and create a unique bundle identifier.

## Add the **live streaming client to your app**

Now let's install the [Flutter live streaming client](https://api.video/catalog/flutter-live-stream/)!

### **Installation**

Open a terminal in your `live_stream_app` folder and the following command:

Also, you need to set the Android minSdkVersion to the one supported by Flutter live stream client.

Open your application build.gradle. It's located in the live_stream_app/android/app directory and replace:

The Flutter default project Kotlin version and the `apivideo_live_stream` Kotlin version might not be in sync.
In this case, when building the application, you face errors like `was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.9.0, expected version is 1.7.1.`.

To fix this, open `android/settings.gradle` and set the `org.jetbrains.kotlin.android` in the `plugins` section to the appropriate version (`1.9.0` in the previous error log).

### **Permissions**

⚠️ Both iOS and Android need permission to broadcast from your device's camera and record audio.

You will also need to ask for internet permission for Android.

#### Android

From your project folder, open the `AndroidManifest.xml` file. It’s located in the `live_stream_app/android/app/src/main` directory.
Add the following content just under the opening `<manifest>` tag to enable internet, audio recording, and the camera for your application:

#### iOS

From your project folder, open the `Info.plist` file. It's located in the `live_stream_app/ios/Runner` directory.
Add the following content just under the opening `<dict>` tag to enable the camera and microphone:

Don't forget to add the app description, as shown above, if you want to deploy your application in app stores.

### **Usage**

You can check the [Flutter live streaming sample application](https://github.com/apivideo/api.video-flutter-live-stream/tree/master/example) for the whole application picture.

#### **Create a controller and the camera preview**

Change your `main.dart` file located in the `live_stream_app/lib` with the following code:

Launch your application. You now have the camera preview.

#### **Manage application lifecycle**

The next step is to manage application lifecycle. You will have to stop/start the camera when your application goes to/from the background. 

The class `_MyHomePageState` must implement the abstract class `WidgetsBindingObserver`. Replace its declaration with:

Register the lifecycle observer, add in `initState`:

#### **Add a control panel**

You still can't start a live stream because there is no way to do it. 

We are going to add a [Row](https://api.flutter.dev/flutter/widgets/Row-class.html) of [IconButton](https://api.flutter.dev/flutter/material/IconButton-class.html) that can control your live streaming.

Import the following package:

Then, add the following code in `_MyHomePageState`:

Then, add the `_controlRowWidget()` in the Colum under the `ApiVideoCameraPreview`. Replace your `_MyHomePageState` `build` method by:

Finally, update the `_isStreaming` variable in the controller’s callbacks to update the `IconButton` state when the live streaming is stopped.

Replace `createLiveStreamController` by:

#### **Launch your first live stream**

⚠️⚠️⚠️ If you want to run your live stream, you will need to change `YOUR_STREAM_KEY` to a real one. 

You can find yours in the [api.video dashboard](https://dashboard.api.video/). If you don't have an account yet, create one, it's free. Then, create a livestream from the overview or the “Live streams” page.

A modal will appear with several pieces of information in it, including the shareable link and stream key. Save the shareable link to access your live stream later.

💡 You can also use the api.video API to create a live stream and retrieve your stream key dynamically. Find how to do this right here. Paste your stream key in place of `YOUR_STREAM_KEY`. Paste your stream key in place of `YOUR_STREAM_KEY`.  

&nbsp;  
Click on the live button in your application; it should be disabled if the live streaming properly starts. Then, go to the shareable link you just saved. 

There you go! You can see what your mobile is streaming in real-time! If not, wait a few seconds and check your stream key value.

🎉🎉🎉 Congratulations, you have created your first live streaming Flutter application 🎉🎉🎉

You can now do an actual live stream directly from your Android and iOS devices. 

## And now what?

[api.video](https://api.video) provides two development environments. The sandbox allows you to live stream directly from your computer or mobile, but a watermark will be applied to your video, and there is a 30-minute limit for live streams.  

&nbsp;  

To avoid these limitations, [sign up](https://dashboard.api.video/register) to api.video and go into production mode 🚀.

Also, the Flutter RTMP live stream client allows us to do much more in terms of configuration!

You can match both audio and video configuration to your needs.

Also, there are some properties can be updated during the live stream:

* Camera: front or back
* Audio: muted or unmuted.

Check out the [README](https://github.com/apivideo/api.video-flutter-live-stream/blob/master/README.md) for exhaustive information about the `apivideo_live_stream` package.

Build your Flutter live streaming application with api.video

build-flutter-live-stream-app-api-video.jpg

api.video player for Flutter: playback videos on your apps

How to build a live streaming app in 3 steps

Here at [api.video](https://api.video/), we talk with lots of developers who are looking for ways to build cool and innovative services with video. Many are still figuring out all of their use cases, and trying to match them with the technical capabilities of different video services.

[Streaming live video](https://api.video/product/live-stream/) is one feature that we receive many questions about. At api.video, **our video streaming solution uses HTTP Live Streaming (HLS) to live stream video**. Another technology we are frequently asked about is WebRTC.  Both technologies are great, but have significantly different applications. In this post, we’ll look at the features and advantages of both, and the primary applications that they are suited for.

## What is HLS?

HTTP Live Streaming (HLS) was developed by Apple, and is currently the primary way that video is streamed on the web today.  The “live streaming” in the name HLS is a bit of a misnomer, as the video does not need to be live - YouTube, Netflix and other video on demand services use HLS to stream video that is not live.  This is an advantage of using HLS for live streaming - the same files used to deliver the video live can be used to playback the video later ‘on demand.’

The ‘HTTP’ in HLS indicates that it uses traditional web protocols to transmit the data over a TCP connection. The video is cut into small segments and sent from the server to the user. The player on the user’s device recombines the video for playback based on a text based manifest file that is transmitted with the video segments. What makes this powerful is that if you have different versions of the same video (different dimensions and bitrates), the player can optimise the delivery based on the actual conditions for each user (primarily network speed and screen size).

When a live video is being transmitted with HLS, the video is sent to a server and transcoded into segments for transmission to end users. This makes HLS ideal for live streaming in one-to-many streams - once the files are recorded, the files are sent like any other HTTP request and the limitation is essentially the server hosting the video. (and of course with CDNs this overhead can be further reduced).

**Latency**: HLS streaming does suffer from about 6-15 seconds of latency (and depending on architectures, it can even be longer). Since the video is transcoded into segments of finite length, the video must be held up for at least as long as the segment length. To reduce transmission errors, some players require 2 segments to be stored in the playback buffer before playback begins, further pushing playback time away from the exact live event.

NOTE: There is active work being done today to reduce HLS streaming latency, and this is expected to improve over the coming months (and api.video is investing in bringing low latency HLS to our users in the *very* near future).

**HLS Summary**: A robust solution for streaming to many users. The current state of HLS includes 10-20 seconds latency that makes HLS not ideal for interactive presentations. HLS videos are also available for playback after the live event.



## WebRTC

“Web Real Time Communication” or WebRTC is a W3C standard that is supported in all browsers, allowing for - as you might have guessed - real time communication. WebRTC has near instantaneous delivery, typically under 300ms, making it ideal for interactive back and forth conversations like in web conferencing solutions.  

The reduction in latency is (partly) due to the use of UDP instead of TCP, and because the formats being used do not require any transcoding before transmitting.

However, since there is instantaneous delivery of video between peers, there is a limit to the number of users who can share video, typically under 6. There are implementations for WebRTC where a small number of users (under 5) share their video, and another number of users can watch in real time (but this number is usually small - under 300.).  

Each person sharing video uses about 1 MBPS of bandwidth. If there are 4 people streaming, the video is 4 MBPS per viewer - the bandwidth coming out of the server will quickly be the limiting factor for the number of users who may join the stream. Additionally, users on low quality networks may not be able to ingest 4MBPS of video, and have trouble playing back the video due to the size. 

In order to save the video for later playback, the WebRTC implementation will use the MediaRecorder attribute to save the video on a local computer. For later playback, this video will have to be uploaded to a server.

WebRTC is ideal for real-time instantaneous communication, but is for small groups of viewers - typically 1-4 sharing video, and a small number of viewers.


## Are HLS and WebRTC independent?

Melding HLS and WebRTC is actually quite common. For example, if you are hosting a panel of speakers, they could join over WebRTC (like a Zoom call), and then stream the call over HLS to a large audience (Zoom offers this as a feature to increase your audience).

How are you using WebRTC and HLS in your video applications? Feel free to continue this conversation on our developer forum: [community.api.video](https://community.api.video).

Delivering live video: Streaming vs. WebRTC

webrtc.png

Live streaming your content is a great way to connect with your audience. In this tutorial, we'll walk through the steps you need to follow to set up a video livestream.

Note: we have example code of setting up a live stream in the [browser](https://api.video/blog/tutorials/live-stream-tutorial/), with [Zoom](https://api.video/blog/video-trends/start-remote-work-with-online-video-and-zoom-us/)
and with [OBS](https://api.video/blog/video-trends/video-live-streaming-in-just-5-easy-steps/).

[Here](https://docs.api.video/reference/api/Live-Streams#create-live-stream) is the direct link to the technical docs to create a live stream.

In order to establish a video livestream, you must first create a livestream container at api.video. Then you can begin streaming with the tool of your choice. In this example, the live stream will be created with OBS, free and open source software for video streaming.  

## Creating Live Stream

### Step 1: Authenticate

You need an access_token in order to create and upload a video.

You will need your API key to obtain the access_token. You can find your API key in [your dashoard](https://dashboard.api.video).  

This tutorial uses the sandbox endpoint. To upload your video in production, simply replace all `sandbox.api.video` instances with `ws.api.video`.

First, call the authentication endpoint and get your access token.


#### Example - Curl Request


### Step 2: Create the Live Stream

Now we [create the live stream](https://docs.api.video/reference/api/Live-Streams#create-live-stream). In the JSON parameter, feel free to edit the name of the live stream from "Your Stream Name" to whatever you want to name your stream.

#### Example - Curl Request

Now the server is ready to accept our live stream, and once broadcast begins (JSON above shows broadcasting:false), it will be viewable on the urls listed in the JSON response.

### Connecting Live Video

The JSON response above lists your live stream's streamKey, which will be needed in OBS to connect your video to the server.

in the OBS application:

1. Esablish a source.  In the sources section, choose a video feed to share.  You could choose to share your screen, or to share your camera (on a Mac: Video Capture Device, and then in the "Device" dropdown choose the camera).  You should now see the video source in the main OBS window.
2. Connect OBS to api.video. Under Settings, choose Stream.  You'll see a choice for service - choose custom.
3. The server should be `rtmp://broadcast.api.video/s` and the `streamKey` is the value you received in the Json when you created the stream. Click OK to accept the changes.
4. Press Start Streaming.
5. Share the embed, iFrame, so that others can watch your stream!


Extra Step:  The default video poster that your users will see is api.video branded.  You can update the thumbnail with an image of your choice:

## Conclusion

That's all it takes. We've walked through the process of creating a livestream at [api.video](https://api.video), and then how to connect that video's streamKey into OBS. Using OBS, we are then able to broadcast video to all our viewers, who can watch using the player (oriframe) url provided by the api.

[Give it a try](https://dashboard.api.video/register), and let us know how it worked for you in our [community forum](https://community.api.video). We're also there to help out if you run into any difficulties.

Create a Live Stream

create-a-live-stream.png

If you're seeking to stream live video with minimal end-to-end latency, the options for transport protocols are relatively few. This is particularly evident if you’re utilizing the public internet as a transport medium, given its inherent challenges like packet loss and jitter. In this blog, we will analyze and assess the two widely used protocols, RTMP and SRT, to aid you in your decision-making process.

## Streaming with RTMP

[RTMP](https://api.video/what-is/rtmp-real-time-messaging-protocol/), a protocol established roughly 20 years ago, initially served as a closed system for streaming audio and video between Macromedia's Flash players. Originating from Flash, it eventually transitioned to an open format, extending its reach beyond the Flash ecosystem and emerging as a dominant ingest protocol in the streaming landscape.  

&nbsp;  

However, [RTMP](https://api.video/blog/video-trends/what-is-rtmp-and-why-do-we-use-it-for-live-streaming/) encounters a notable issue while streaming known as head-of-line blocking which can be attributed to its reliance on Transmission Control Protocol (TCP). While transmitting audio and video packets, when the data does not arrive in sequence or is lost due to the inherent unreliability of networks, TCP reorders the packets and requests re-transmissions to compensate loss. It insists on perfect delivery and reordering, which in turn can impede the realtime transmission of audio and video streams.  

&nbsp;  

This lack of time assurance in data transmission over TCP translates into unstable latency during RTMP streaming, as the protocol automatically adjusts to fluctuating network conditions without user intervention.  

&nbsp;  

What does it mean for an end user watching a livestream?

- A sudden increase in latency may prevent the server from streaming data in real-time, leading to buffering.
- If the latency decreases after that, allowing the server to catch up, the end-user may still lag behind the livestream due to previous buffering. While the player may attempt to accelerate playback to reach the edge, recurring latency peaks will result in buffering interruptions.  

&nbsp;  

This undesirable outcome underlines the importance of finding alternatives to RTMP for delivering uninterrupted live streams in fluctuating bandwidth conditions. 

## Streaming with SRT

Now let us see how SRT is different.  

&nbsp;  

SRT uses a different approach compared to RTMP. It relies on User Datagram Protocol (UDP) which does not enforce packet re-ordering and does not manage packet losses, and so is not subject to head of line blocking that happens in TCP. However, this is something needed to provide a good playback experience, so it is handled by SRT but using an alternative method.  

&nbsp;  

It does this by letting the streamer choose the maximum latency they're okay with when streaming. The SRT server then holds back data for that amount of time. During this time, it re-organizes the packets and asks for any missing ones to be sent again. But if a packet isn't received by the end of this delay, it's considered lost, and it's up to the server to deal with that.  

&nbsp;  

By doing so, [SRT makes it possible to stream data with a stable latency](https://api.video/blog/product-updates/SRT-livestreaming/) to the server which limits buffering to a certain extent.  

&nbsp;  

Now of course, this comes with a price. If unexpected congestion occurs on the network, viewers may notice playback issues like visual artifacts, audio glitches, or black screens. However, the playback will be smoother which is why, the latency target you choose to achieve plays a very important role in how your video will be delivered. 

- If you set the latency too low, the viewer experience may be deeply impacted or may even not work
- If you set the latency too high, the viewer experience will be optimal but the end-to-end latency will be high, which may be a problem for the streamer.  

&nbsp;  

Therefore, finding a good compromise between latency and quality of stream becomes very important. The table below explains everything in a crystal clear format.

|  | End-to-end latency | Visual/audio quality | Playback reliability |
| --- | --- | --- | --- |
| RTMP | Close to optimal but subject to instability | Optimal | Fair but subject to buffering |
| SRT with very low latency | Very low | Very poor (too many losses) | Good (no buffering due to ingest) |
| SRT with good latency | Low but not optimal | Almost good | Good (no buffering due to ingest) |
| SRT with very high latency | Very high | Optimal | Good (no buffering due to ingest) |

## Closing thoughts

So, as you must have seen above, it is not straight answer if you should choose SRT or RTMP for your livestreams. If you stream in stable conditions over a wired network, with a low risk of congestion/jitter, you can start with RTMP and you will probably achieve a better latency than you would with SRT.  

&nbsp;  

If the network you use is known to be unstable or there is a chance that your users work frequently with wireless networks, then SRT may be a better fit.  

&nbsp;  

***With api.video, you can either choose RTMP or SRT for your livestream. Find more details about how to live stream with api.video in our [documentation](https://docs.api.video/live-streaming/create-a-live-stream).***  

&nbsp;  

 ***If you haven’t live streamed with api.video yet and would like to start your journey with us, [sign-up](https://dashboard.api.video/register) for a free sandbox account NOW!***

small_SRT-vs-RTMP.png

thumbnail_SRT-vs-RTMP.png

SRT-vs-RTMP.png

Live stream better with the Secure, Reliable, Transport (SRT) protocol

live-stream-srt-protocol.png

If you've watched videos, listened to audio, or seen a live stream, you've probably encountered RTMP. RTMP stands for Real-Time Messaging Protocol and it's been used for streaming video and audio on the internet as far back as 2002, which is when Macromedia first created it. In the beginning, [RTMP](https://api.video/what-is/rtmp-real-time-messaging-protocol/) was proprietary, but eventually Adobe bought Macromedia and made RTMP publicly available in 2008.  

&nbsp;  

We've been using it for live streaming since 2002. Even now, a common practice is to take data from a source, transcode it to RTMP, and then transcode that to HLS. Why is transcoding twice so common? Why don't we transcode straight to HLS for live streams? Why is RTMP so great? Well, there's a few reasons that we'll get into. 

## What Does RTMP Do? 

First of all, let's review what RTMP does. It uses a persistent (continuous) TCP (Transmission Control Protocol) to stream audio and video from a source to a destination. Using TCP enables it to keep packets of information in the right order when received and viewed - so you don't end up watching the end of your movie or sports game before the middle. Because RTMP uses TCP to travel, it uses a three-way handshake when transporting data. The client (live stream sender) requests a connection from the server it's sending data to. It receives a response, creates a session and transmits the data.  

&nbsp;  

RTMP combined with Flash Player became so popular because it was very fast, delivering content with around 5 seconds of latency. Over time, Flash has fallen out of use, but we continue using RTMP. 

## What are the Benefits and Drawbacks of RTMP? 
### RTMP is great (even now) because: 
* It's easy to set up an encoder. There are many software based encoders that are cheap, and often hardware solutions are also low cost.
* It's delivered as a single file, which is easier to manage and process than lots of chunks (looking at you HLS). 
* Because RTMP was the industry standard for so long, it's cheaper to set up and it's easier to support because there are many tools and people who are deeply knowledgeable about how to work with RTMP. 
* It's still one of the fastest solutions out there (don't worry, we'll get to why it isn't THE fastest anymore in a little bit). 
   
&nbsp;  

### RTMP is limited because:
* New standards were developed that allow for HTML5 video streaming and adaptive bitrate delivery (...HLS).
* It has difficulty getting past firewalls. 
* There are numerous security issues with Flash. 
* Today a lot of browsers don't support RTMP.
* RTMP doesn't work on mobile devices. 
* The quality of footage is not as high as newer standards. 

## RTMP for First-Mile Delivery and Last-Mile Delivery
Because of the points I've listed, RTMP is still used, but it's no longer used for everything. You might hear terms for live streaming like 'first-mile delivery' and 'last-mile delivery.' First-mile delivery is what happens right after you transfer footage from a source to an encoder, and the encoder converted it to RTMP. Wherever the encoder sends the RTMP content to is first-mile delivery. Last-mile delivery is the CDN (or sometimes EDGE server that also handles transcoding if you use a decentralized approach) that's going to deliver content to a viewer or user device. Due to the remaining benefits of RTMP, it's used for first-mile delivery. Because of the drawbacks, RTMP is not used for last-mile delivery.  

&nbsp;  

In the image, first-mile delivery is the phase from when footage becomes RTMP through to where it is going to be transcoded. Last-mile delivery is after something has been transcoded to HLS and is being delivered to a viewer (Delivery). For the Convert to RTMP section, note that some cameras stream in RTMP, handling this step automatically, some you can convert to RTMP on your computer, and some you can send to another place to be converted. 

## Why is Transcoding Twice So Common? 
If you've been reading closely so far, no doubt you guessed why all kinds of places, like Facebook, YouTube, api.video accept RTMP and then do a second transcoding to HLS. It's because RTMP is still a combination of the fastest and most popular (reliable) choice for first-mile delivery. (Note I said it's the combination - there's starting to be faster options, but we don't yet have something that's as popular as RTMP.) It's easy to use, cost effective, well known, and reliable. But it's not good for last-mile delivery. For last-mile delivery, you want a protocol that's going to be fast, good quality, and capable of being handled by mobile, browsers, whatever the situation might be. That's why everyone eventually ends up transcoding to HLS.  

&nbsp;  

Some day, RTMP might be replaced by other, newer standards being created, for example [SRT (Secure Reliable Transport)](https://www.srtalliance.org/) is a protocol that addresses some of the issues RTMP faces. SRT preserves video quality better than RTMP, has less trouble getting past firewalls, and is lower latency.

## A Little Bit About HLS
HLS (HTTP Live Streaming) is an open standard created by Apple that offers faster and faster options as time goes by. While initially HLS wasn't a great choice for live broadcasting (latency times were often 15-30 seconds), low latency HLS has started solving this problem. With low latency HLS, you can live stream with under 2 seconds of latency, and there are faster options all the time. A great thing about the HLS protocol, is if a receiver doesn't understand something about the HLS it's being sent - say it's missing an extension or similar, it will default to playing whatever form of the HLS it does understand. So while this might mean higher latency in some instances, it means more reliable playback overall.  

&nbsp;  

If you have more questions about RTMP or any other video-related information, contact us in the [community forum](https://community.api.video/)! 

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

Video trends

Guides and insights from the Video Industry