Live stream status

Normal

medium_screen-shot-2021-01-26-at-11-48-47-am.jpg

small_screen-shot-2021-01-26-at-11-48-47-am.jpg

thumbnail_screen-shot-2021-01-26-at-11-48-47-am.jpg

screen-shot-2021-01-26-at-11-48-47-am.jpg

Erikka Innes

Video trends

[FFMPEG](https://api.video/what-is/ffmpeg) allows you to stream and [live stream](https://api.video/live-streaming/) video, but sometimes what the output means can get confusing. 

We are going to go over every part of the information in the output, so if something seems obvious, skip ahead to the part you wanted to learn about.

Here's our sample. This sample shows a session where a live stream is started using my Mac and the Mac's iSight camera. I started it using the [livestream.a.video](https://livestream.a.video) demo through a Chrome browser. There might be some differences based on what computer you're on, so keep that in mind. 

## Hello from mediarecorder-to-rtmp server!

We're using an RTMP connection, which is based on TCP. So when I connect with my request to create a live stream, my client gets a response: 

"SERVER:Hello from mediarecorder-to-rtmp server!" 

I'm asked to provide my stream key, which is going to be what I will use to broadcast. Because of how the demo is set up, that's already been sent, so now the server tells me it's received the information about where I want to broadcast my live stream to: 

"SERVER:Please set rtmp destination before start streaming.
SERVER:rtmp destination set to:rtmp://broadcast.api.video/s/30087931-229e-42cf-b5f9-e91bcc1f7332"

The last part tells me what version of FFMPEG we're using and provides a link to static builds of FFmpeg for Linux kernels 3.2.0 and up. It also gives me copyright information - wow we've had FFMPEG for 22 years!

## Configuration details 

The next part of the FFMPEG output shows us the configuration details for the live stream. 

In this section, we're told that FFMPEG was built with gcc 8. GCC stands for GNU Compiler Collection and it's the standard compiler for Linux. It's associated with the Linux distribution Debian (Debian GNU/Linux). The Debian Linux distribution is super popular and while it's less user friendly than distributions like Ubuntu, it is great for people who like free and open source software. 


## FFMPEG library versions
This section of output lists the main libraries in FFMPEG and the versions you have installed. 


## FFMPEG input info 

This section shows you details about your video live stream. 

Here's the first line: 

"FFMPEG:Input #0, matroska, webm, from 'pipe:':

This explains how video is being input. We can see here that the multimedia container matroska and the open video format webm is being used to capture video.

"Metadata:
  encoder         : Chrome
 Duration: N/A, start: 0.000000, bitrate: N/A"
 
 Next, there's more information about the streams being input: 
 
 "Stream #0:0(eng): Audio: opus, 48000 Hz, mono, fltp (default)
  Stream #0:1(eng): Video: h264 (Constrained Baseline), yuv420p(progressive),   
	240x240, SAR 1:1 DAR 1:1, 1k tbr, 1k tbn (default)"

### The audio stream
The audio stream is using the opus codec with a sample rate of 48000 Hz, which is standard for digital video files. Mono means the audio is monophonic, meaning all sounds are mixed together in a single channel. And fltp is Planar Floating point format. It's a way of retrieving the sample format for your audio. Sample format information is used to determine how many bits will be in each audio sample. The higher the number of bits per sample in a file, the more data that will be stored in the sample. You can learn more about sample format here: What is Sample Format?

### The video stream
The video stream is using the h264 codec with a constrained baseline. The term constrained baseline describes the video stream profile. A profile determines the methods that an encoder can use to generate streams and also describe the methods a decoder is expected to perform in order to decode the stream later. The term 'yuv420p' describes the type of video signal you're using. 

YUV is a type of video signal where colors are split into three channels, one for luminance (brightness) which includes green, and two for chrominance (color) which include blue and red in separate channels. 420 describes the chroma subsampling used on the video. Normally, you'd notate this as 4:2:0. It's telling you that the color channels have half the resolution of the luminance channel. If you want to learn a bit more about this way of representing color, see the api.video definition for YCbCr. The term progressive means that the video is in a progressive format, which means that the TBR value (coming up in our discussion) is talking about the frame rate rather than the field rate. There's confusion about both these terms. For the purpose of this walkthrough, let's keep things simple. A progressive video format will use frame rate to describe frames per second. An interlaced video format will use field rate. It takes two fields to show you one image. 

240x240 describes the pixels in each frame of video. SAR stands for Sample Aspect Ratio, and it's showing you the ratio between the width and the height of each individual pixel - 1:1. DAR stands for Display Aspect Ratio and that's the ratio between the width and height of a full image in your video. In this case it's also 1:1. 

In the final line, it closes out with "1k tbr, 1k tbn (default)." TBR represents the frame rate baseline. This is guessed by FFMPEG when it looks at the video stream. At the start of a video stream, TBR is low. In our stream, it's 1 at the very start. Sometimes if you have a video format that's interlaced, the TBR will be twice as high as expected, because there are two fields used to create an image. TBN represents the time base in AVStream that comes from the container. TBC is the time base for the codec for the stream.

## Stream mapping 
Next in our information from FFMPEG we have a section about stream mapping that looks like this:

Stream #0:1 is our video stream. This means that the input stream is from the first file '0' and it is the second stream in that file '1.' h264 (native) means that the detected codec of the input stream is H.264 and that FFMPEG is going to use the built-in decoder to decode the stream. It's being mapped to h264 (libx264) meaning that the output stream is going to be H.264 and FFMPEG will use the libx264 encoder to generate the stream. 

Stream #0:0 is our audio stream. This means that the input stream is from the first file '0 and its the first stream in that file '0.' opus (native) means that the detected audio codec of the input stream is opus and as before, native means that FFMPEG is going to use its built-in decoder for opus to decode the stream. aac (native) means the output audio will be in aac, and FFMPEG will use the built in encoder for aac to generate the stream. 

## Configuration details for libx264
We're mapping to libx264, so now we receive some details about how libx264 is configured for our stream. 

You can see the Video Buffering Verifier confirms that there's a buffer size set, but the max bit rate it can handle isn't specified, so it's ignored. Then the SAR is 1:1, as it was to start with. We can see the CPU capabilities available for sending our live stream and that we'll be using the constrained baseline for H.264. 

Next there's the line: 

"FFMPEG:264 - core 164 r3065 ae03d92 - H.264/MPEG-4 AVC codec - Copyleft 2003-2021 - http://www.videolan.org/x264.html"

This tells us what version of the H.264 codec FFMPEG uses. It's followed by options that are configured for the codec. 

**cabac=0** 
Cabac stands for context-adaptive binary arithmetic coding. It's a type of entropy encoding, which is a lossless data compression technique. H.264 is lossy, so cabac is used at the end to do a final compression that is lossless. You should not mistake its inclusion in H.264's compression steps as meaning all the steps are lossless. Also, explaining this algorithm in detail would take some time. If you want to learn more about cabac, look here: Context=adaptive binary arithmetic coding

**ref=1**
This indicates which frame will be the first reference frame. Here, it's the first frame.

**deblock=0:0:0**
This is the deblock filter for H.264. It creates pixelation to help improve the appearance of your video. It's useful when macroblocking occurs, which would be a huge block of pixels that look unnatural. Deblocking blurs these blocks to make them look normal again.

**analyse=0:0** 
This is part of deblocking. It helps determine the size of each block you will apply deblocking to. 

**me=dia**
This is saying that the motion estimation method is diamond or dia. Motion estimation is the process of determining motion vectors that describe the transformation from one 2D image to another; usually from adjacent frames in a video sequence. Diamond search technique for block motion estimation is based on diamond search patterns. The process of block matching motion estimation is to find out a candidate block, within a search area in the previous frame, which is most similar to the current block in the present frame. So you're saying here use this technique for motion estimation.

**subme=0** 
This is for the sub-pixel motion estimation method. It's important for video coding inter-frame prediction and has high computation complexity. It's set to 0 meaning there will be zero sub-pixel motion estimation done. 

**psy=1 psy_rd=1.00:0.00**
This is also to do with motion-compensated DCT, which is a lossy block compression transform coding technique. If set to 1 it means use psychovisual optimizations. It means optimizing quantization tables based on the human visual system and humans see. It's a complex topic that can't be fully explained here. psy_rd is about setting how strong the psychovisual optimization will be.

**mixed_ref=0** 
This allows you to use one reference per partition as opposed to per macroblock. A macroblock is a large block of pixels and a partition is a smaller, multiple variable-sized prediction block. 

**me_range=16**
Again about motion estimation, but this time about the range for a motion vector. In video compression, a motion vector is the key element in the motion estimation process. It is used to represent a macroblock in a picture based on the position of this macroblock in another picture, called the reference picture. This parameter lets you set the range.

**chroma_me=1** 
Typically when doing motion estimation, only luminance is examined. You can have chroma considered as well by setting chroma_me to be 1.

**trellis=0** 
This lets you set the rate-distortion optimal quantization. This is a method used to improve video quality in video compression. It optimizes the amount of video quality lost per chunk of data by measuring how far an optimization will deviate from the source material and the cost of that deviation. This can be used to decide what choices are useful vs. resulting in the loss of too much data. It's a slow process, so sometimes it's better not to use it, which is what's being done here by setting trellis=0.

**8x8dct=0** 
With this parameter you can enable adaptive spatial transform. This is a way of altering an image or video frame through rotation, flips, scaling and deformation. For our case, where it's for video, it's about ways to manipulate the block of data so it appears less distorted and of higher quality.

**cqm=0** 
Allows the use of a custom quantization matrix to weight frequencies differently in the quantization process. The presets quant matrices are "jvt" and "flat". Recommended only if you know what you're doing.

**deadzone=21,11** 
When trellis isn't activated, deadzone parameters determine how many DCT coefficients are rounded up or down. Rounding up results in higher quality and more detail retention, but costs more bits--so rounding is a balance between quality and bit cost. Lowering these settings will result in more coefficients being rounded up, and raising the settings will result in more coefficients being rounded down. Recommended: keep them at the defaults. This is part of the settings for rate-distortion optimal quantization. This is again fairly complex to explain. If you want to learn more about it conceptually, check out this page: Quantization

**fast_pskip=1** 
By default, x264 will skip macroblocks in P-frames that don't appear to have changed enough between two frames to justify encoding the difference. This considerably speeds up encoding. However, for a slight quality boost, P-skip can be disabled. In this case, the full analysis will be done on all P-blocks, and the only skips in the output stream will be the blocks whose motion vectors happen to match that of the skip vector and motion vectors happen to match that of the skip vector and which have no residual. The speed cost of enabling no-fast-pskip is relatively high, especially with many reference frames. There is a similar B-skip internal to x264, which is why B-frames generally encode much faster than P-frames, but it cannot be disabled on the commandline.

**chroma_qp_offset=0** 
This stands for chroma quantization parameter offset. It is the quantization parameter difference between chroma and luma. 

**threads=3**
FFMPEG is multi-threaded by default. How many threads it will use depends on the codec. By default for libx264 it is cores x1.5 for frame threads and cores x 1 for slice threads. 

**lookahead_threads=3** 
A lookahead thread looks at incoming frames before they are transcoded. Number of lookahead threads can impact performance speed.

**sliced_threads=1** 
Sliced threading decodes multiple parts of a frame at the same time.

**slices=3**
If the codec you're using supports multi-threading, you can decode more than one part of a single frame at once by working on multiple slices. This is only available if the video was encoded using slices.

**nr=0** 
Confusingly, this stands for noise-sensitivity. You can use it with static-thresh to change the threshold on blocks that are examined in an image. If they fall below the specified threshold the encoder skips them.

**decimate=1** 
This allows you to drop duplicated frames at regular intervals. 

**interlaced=0** 
This is a simple interlacing filter from progressive contents. This interleaves upper (or lower) lines from odd frames with lower (or upper) lines from even frames, halving the frame rate and preserving image height.

**bluray_compat=0** 
Configure the encoder to be compatible with the bluray standard. It is a shorthand for setting "bluray-compat=1 force-cfr=1".

**constrained_intra=0** 
You can enable constrained intra prediction, which is required for the base layer of SVC encodes. This is an intra prediction technique where the video encoder limits the use of neighboring blocks as reference blocks in the intra prediction process. If you're using constrained intra prediction, you can configure video to not use neighboring blocks as reference blocks if the neighboring blocks were coded using inter prediction. By not using inter predicted blocks as reference blocks for intra prediction, the video encoder may create an encoded video bitstream that is more error resilient.
 
**bframes=0** 
You can set the maximum number of concurrent B-frames that x264 can use. Without B-frames, a typical x264 stream has frame types like so: IPPPPP...PI. With --bframes 2, up to two consecutive P-frames can be replaced with B-frames, like: IBPBBPBPPPB...PI. B-frames are similar to P-frames, except they can use motion prediction from future frames as well. This can lead to significantly better efficiency in terms of compression ratio. 

**weightp=0** 
Use this to enable use of explicit weighted prediction to improve compression in P-frames. Higher modes are slower.

**keyint=30** 
This sets the maximum interval between IDR-frames (aka keyframes) in x264's output. You can specify "infinite" to never insert non-scenecut IDR-frames. IDR-frames are 'delimiters' in the stream - no frame can reference data from the other side of the IDR-frame. As well as this, IDR-frames are also I-frames, so they don't reference data from any other frame. This means they can be used as seek points in a video.

**keyint_min=16** 
This sets the minimum length between IDR-frames. Very small keyint ranges can cause "incorrect" IDR-frame placement (for example, a strobing scene). This option limits the minimum length in frames after each IDR-frame before another can be placed.

**scenecut=0** 
This sets the threshold for I/IDR frame placement (read: scene change detection). x264 calculates a metric for every frame to estimate how different it is from the previous frame. If the value is lower than scenecut, a 'scenecut' is detected. An I-frame is placed if it has been less than keyint_min frames since the last IDR-frame, otherwise an IDR-frame is placed. Higher values of scenecut increase the number of scenecuts detected.

**intra_refresh=0** 
You can disable IDR-frames, instead H.264 uses intra coding for each macroblock in the frame every keyint_min frames. Blocks are refreshed in a horizontally scrolling column - the 'refresh wave'. This benefits low-latency streaming by making it possible to achieve more constant frame sizes than is possible with standard IDR-frames. It also increases the resilience of the video stream to packet loss. This option does reduce compression efficiency, hence only use it when needed.

**rc=crf**
rc stands for Rate Control. You can adjust the file data rate in several ways, the option shown here is CRF, or Constant Rate Factor. CRF is an encoding mode that adjusts the file data rate up or down to achieve a selected quality level rather than a specific data rate. CRF values range from 0 to 51, with lower numbers delivering higher quality scores.

**mbtree=0** 
This stands for macroblock tree rate control. Macroblock tree rate control improves compression by tracking how long different parts of an image last across frames. For parts of an image that stay the same, you don't need to continually save that data, only make a note that it continues to be there so you can use that as a reference to reconstruct that part of the frame later. 

**crf=25.0** 
This is related to the rc=crf command. CRF is an encoding mode that adjusts the file data rate up or down to achieve a selected quality level rather than a specific data rate. CRF values range from 0 to 51, with lower numbers delivering higher quality scores.

**qcomp=0.60** 
The default setting is 0.60. qcomp stands for quantizer curve compression factor. A setting of 0 will give you a constant bitrate while a setting of 1 will give you a constant quantizer. This can be combined with mbtree, but the higher your qcomp setting, the weaker the effect of the mbtree setting.

**qpmin=0** 
The default setting for this is 0 and raising this minimum is discouraged because it can negatively impact the quality of background areas in your frame. 
qpmin defines the minimum quantizer that H.264 will ever use. The lower the quantizer, the closer the output is to the input. 

**qpmax=51** 
The default setting for qpmax is 51. The default of 51 is the highest quantizer available for use in the H.264 spec, and is extremely low quality. This default disables qpmax. You can set this as low as the 30-40 range if you want to cap the minimum quality x264 can output, but adjusting it is not recommended.

**qpstep=4**
This allows you to set the maximum change in the quantizer between two frames. 

**ip_ratio=1.40** 
The default setting is 1.40. You can change the average decrease in quantizer for B-frames vs. P-frames, with higher values decreasing B-frame quality.

**aq=0**
aq stands for Adaptive Quantization. This helps distribute bits between macroblocks in your video. If you don't use it, it can underallocate bits to sections that lack detail. A setting of 0, as with other FFMPEG settings, means you will not use it at all. 

## Output to api.video
Now that you've got all the configuration settings for your streams and you've mapped them, you'll want to see some details about what will be output to your destination. 

Here you can see the destination, shown by the stream key and then a summary of details about your video and audio streams. The encoders being used are listed as well. We don't need to walk through everything listed here because we covered it in the earlier sections when we mapped the video and audio streams. FPS is frames per second. 

Now we can take a look at the lines that show us details about each chunk of data being streamed. Here's one of the lines: 

"FFMPEG:frame=65 fps= 55 q=12.0 size=29kB time=00:00:05.06 bitrate=  47.1kbits/s speed=4.26x"

The line is a snapshot where everything that is happening at that moment is reported to the terminal. It says that in this moment, you're streaming frame 65. The frames per second is 55, and the quality (q) is 12. The lower the number for quality, the better the video. The higher the number, the worse. The size of the chunk of data being streamed is also listed in kB with size. The time is the time from when the live stream started, and the bitrate is how many kbits per second yu're streaming. speed is how fast everything is streaming. 

## Conclusion
While this guide doesn't tell you everything about all concepts (for example quantization, which is too complicated to include in this post) I hope that this walkthrough helped explain what things are a bit more.
To help you further, you can go on [our Community](https://community.api.video/) or [start building](https://dashboard.api.video/register) now.



What do my video output live stream details from ffmpeg mean ? 

What do my video output live stream details from ffmpeg mean?

large_what-do-my-video-output-live-stream-details-from-ffmpeg-mean.png

medium_what-do-my-video-output-live-stream-details-from-ffmpeg-mean.png

small_what-do-my-video-output-live-stream-details-from-ffmpeg-mean.png

thumbnail_what-do-my-video-output-live-stream-details-from-ffmpeg-mean.png

what-do-my-video-output-live-stream-details-from-ffmpeg-mean.png

Video list

doug.jpg

twitter-brands.svg

Doug Twitter

Doug Sillars

Tutorials

NodeJS

With your api.video livestream you can have video streaming out to the internet in no time. (If you don't have an api.video livestream yet, here's how to [create a livestream](https://api.video/blog/tutorials/live-stream-tutorial/).) We have demos on how to stream with your [browser](https://api.video/blog/tutorials/live-stream-tutorial/), [Zoom](https://api.video/blog/video-trends/start-remote-work-with-online-video-and-zoom-us/), [OBS](https://api.video/blog/tutorials/live-stream-tutorial/), with a [Raspberry Pi](https://api.video/blog/tutorials/video-streaming-with-a-raspberry-pi/), and you can expect more tutorials in the future!  Every stream that you create has a player that can be embeded on any webpage.  

In this post, we'll create a very simple webpage to host your livestream using NodeJS. This page will show the current livestream (if it is broadcasting), and a few recent recordings from the stream.



## Is the Stream Broadcasting?

When you request the [live stream status](https://docs.api.video/reference#get_live-streams-livestreamid) API endpoint, you'll receive a JSON response with a lot of details about your stream.

Here the response from the live stream:

```json
{
  liveStreamId: 'li400mYKSgQ6xs7taUeSaE',
  streamKey: '30087931-229e-42cf-b5f9',
  name: 'Live Stream',
  record: true,
  broadcasting: false,
  assets: {
    iframe: '<iframe src="https://embed.api.video/live/li400mYKSgQ6xs7taUeSaE" width="100%" height="100%" frameborder="0" scrolling="no" allowfullscreen="true"></iframe>',
    player: 'https://embed.api.video/live/li400mYKSgQ6xs7taUeSaE',
    hls: 'https://live.api.video/li400mYKSgQ6xs7taUeSaE.m3u8',
    thumbnail: 'https://cdn.api.video/live/li400mYKSgQ6xs7taUeSaE/thumbnail.jpg'
  }
}
```


You'll notice the broadcasting parameter.  If this value is true - the stream is live! At the moment I made this request, the livestream was not active.

Our Node application calls the live status, and if the stream is broadcasting, the site is served an iframe with the video, and if not, we serve the thumbnail image:

```
		if(broadcasting){
			liveResult = "Here is your Live Video:";
			videoIframe = "iframe src=\""+liveStream.assets.player+"#autoplay\" width=\"100%\" height=\"50%\" frameborder=\"0\" scrolling=\"no\" allowfullscreen=\true\"";
		}else{
			videoIframe = "img src ="+liveStream.assets.thumbnail +" width=\"100%\"";
		}

```

If you look closely, I don't use the exact iframe returned in the response. I build an iframe with the player url, and I add '#autoplay' to the end of the url. This tells the player to autoplay the video as soon as it loads.

## Video recordings

In the JSON response above, we also can make user of the "record" attribute.  If this parameter is set to true, the video is re-encoded as video on demand (VOD) when the livestream ends. These videos have a 'liveStreamId' parameter linking them back to the original livestream.

If we request the [video search](https://docs.api.video/reference#list-videos) endpoint with the livestreamId, we get a list of all the videos that have been saved from the stream.  In the below code, we sort by newest videos first, and save the first 5 (most recent) videos into an array. This array is used by Pug and Express to create a list of the videos.

```
	//Now we can get the most recent VOD from the stream.
		    let videoList = client.videos.search({'liveStreamId': liveStreamId, sortOrder: 'desc', sortBy: 'publishedAt'});
			videoList.then(function(liveStreamList){
				//console.log(liveStreamList);

				//loop through all the videos, we'll show 5, and if there are more than 20 - delete them
				
				for(i=0; i< liveStreamList.length; i++){
					if(i<5){
						var iframe = "iframe src=\""+liveStreamList[i].assets.player+"\" width=\"50%\" height=\"25%\" frameborder=\"0\" scrolling=\"no\" allowfullscreen=\true\"";
						var name = liveStreamList[i].title;
						var data = {
							"name": name, 
							"iframe":iframe
						};
						recordedVideos.push(data);
					}else if(i>20){
						//delete the videos...
						var videoId = liveStreamList[i].videoId;
						let deleteVid = client.videos.delete(videoId);
						deleteVid.then(function(statusCode) {
		  					console.log(videoId, "deleted");
		  					console.log(statusCode);
						}).catch(function(error) {
		  					console.error(error);
						});	
					}


				}
				//now we have an array with all the videos to show:
				console.log(recordedVideos);
				return res.render('live', {liveResult, videoIframe, recordedVideos});
			}).catch((err) => {
				console.log(err);
			});
```

NB the second part of this if/else.  If there are over 20 videos, we delete all of the oldest videos (ensuring there are never more than 20 stored in my account). This is my *super simplistic* approach to remove older recordings from my account, but is not unlike security systems that delete all videos over X days old.

That's it! Thank you for reading. 

How are you using live video in your projects?  We'd love to know - leave a note over on our [community forum](https://community.api.video). If you haven't created your api.video account yet, you can do that in just a few seconds [here](https://dashboard.api.video/register). 

Watching a Livestream

large_television-40695101920.jpg

medium_television-40695101920.jpg

small_television-40695101920.jpg

thumbnail_television-40695101920.jpg

television-40695101920.jpg

codec

video create

small_cedric.jpeg

thumbnail_cedric.jpeg

cedric.jpeg

Cédric Montet

Product updates

At api.video, our goal is for video to be easy and affordable for anyone to build, be it individuals or organizations. We understand that achieving this goal means reducing costs at some stage of the video streaming process. That’s why, we now offer adaptive bitrate encoding for your videos at zero cost. 

&nbsp;

Yes, you heard me right. 

&nbsp;

**Encoding videos will be absolutely free for all video qualities (1080p or 4K) at [api.video](https://api.video/) - no hidden calculations, footer notes or tricks.**

(Check out this [video](https://www.youtube.com/watch?v=ouosgLbW7Ts) for more details) 


## A step towards making video streaming affordable

Video encoding is crucial as it makes it possible for videos to be shared and played smoothly on the internet. It is why we are easily able to consume various types of video media, whether it’s a YouTube video, our favorite shows on Netflix, or even catching up with friends across the globe on Zoom. Video encoding basically makes the world go around in regards to anything related to video and video content.

&nbsp;

We at api.video recognize that. From [increasing the transcoding and playback speed ](https://api.video/blog/product-updates/2021-in-review/)to building [specialized hardware like ASICs](https://api.video/blog/video-trends/the-comeback-of-specialized-hardware/) cards to increase our transcoding capacities, we've been working to make video streaming easier for you every day. And after dedicating ample time to engaging with our customers and learning about their concerns, free encoding seemed to be the next step in this direction. 

&nbsp;

So, we worked tirelessly behind the scenes to give you what no one else will - free encoding for all video qualities, be it 360p or 4K. 

## How does free video encoding benefit you as a customer

The benefit is straightforward: you save a LOT of money!

&nbsp;

- With free video encoding, you will have one less thing to worry about. As you know, you pay for three things for streaming videos — encoding, hosting, and delivery – out of which encoding is the most expensive, especially if you have a lot of videos. Free video encoding will allow you to focus your attention and resources to what is most important.

&nbsp;

- As the video needs of your app users grow, you might need to scale up your encoding capacity. Free video encoding services will give you the power to scale without any additional costs, meaning your users can handle more videos without increasing your expenses.

&nbsp;

- You can [migrate from your previous provider to api.video](https://api.video/compare/azure-media-services/) without paying an ‘entry tax’ to us. With free video encoding, you no longer need to spend money on encoding videos with a new provider when you have already paid for encoding with an older one.

&nbsp;

Now with all the saved cost, you can allocate your resources and money to a place where it is actually important – building your product and delighting your users. 

## How to get started

To use the free video encoding benefit, getting started is easy. 

&nbsp;

- If you’re a new user, [sign-up](https://dashboard.api.video/register) for a free sandbox account and start uploading your videos
- If you are looking to migrate from another vendor, [import](https://import.api.video/) your videos from your current vendor
- If you have any questions, [talk to us](https://meetings.hubspot.com/diego398/cc-talk-to-us?__hstc=54467703.754940701eda85e3c99a902d8ab0b988.1687266643206.1694417789132.1694427271479.149&__hssc=54467703.3.1694427271479&__hsfp=3654297906) by booking a slot in our calendar

&nbsp;

To know more about our[ features](https://api.video/features/), [pricing](https://api.video/pricing/) or ask any other questions, [talk to our team ](https://meetings.hubspot.com/diego398/cc-talk-to-us?__hstc=54467703.754940701eda85e3c99a902d8ab0b988.1687266643206.1694162373815.1694167498585.144&__hssc=54467703.1.1694167498585&__hsfp=3654297906)and we will help you out. 

&nbsp;

Or, you can straightaway [sign-up](https://dashboard.api.video/register) for a free sandbox account and check our product out for yourself. 


Huge pricing update: Introducing video encoding at no cost

large_Blog_Zero Cost (2).png

medium_Blog_Zero Cost (2).png

small_Blog_Zero Cost (2).png

thumbnail_Blog_Zero Cost (2).png

Blog_Zero Cost (2).png

api.video team

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

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

## What is video encoding?

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

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

## Why is video encoding used?

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

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

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

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

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

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

## Differences between video encoding and video transcoding

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

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

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

## Examples of video codecs

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

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

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

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

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

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

## How do different technologies handle video encoding

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

### Video editing software

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

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

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

### Websites

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

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

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

Encoding and transcoding are often used interchangeably but they have slightly different definitions. **Encoding is the initial process of converting raw video files into a specific digital format or codec.** It involves compressing and packaging the video data, often to reduce file size while maintaining acceptable quality. Encoding prepares the video for storage, transmission, or playback.

&nbsp;

**Transcoding, on the other hand, involves converting a video from one digital format or codec to another.** This is typically done to optimize the video for different devices or platforms, adapt to varying network conditions, or ensure compatibility with specific playback requirements. Transcoding occurs after encoding and often involves changing resolution, bitrates, or formats without altering the content itself.

## What goes on behind encoding a video?

It's easy to say that encoding is when you go from an _uncompressed source_ to a _compressed source_, but you may ask, what exactly do compressed and uncompressed sources mean?

&nbsp;

Uncompressed sources are video files that contain data that comes directly from a camera sensor vs. encoded video. In the digital space, it's SDI (Serial Digital Interface) or HDMI (High Definition Multimedia Interface). Both of them are popular standards. You'll find HDMI in places like your GoPro camera, or a mini camcorder. These days, you might also find HDMI in professional settings, but SDI is more common due to its reliability. Another example of an uncompressed source would be something analog, for instance, VHS tapes.

&nbsp;

A compressed sources, on the other hand, are video files that have undergone compression during the encoding process. Compression involves reducing the file size by removing unnecessary information or encoding the data in a more efficient format. This process results in a smaller file size, making it more manageable for storage, transmission, and playback.


## What are the types of transcoding methods?

There are three types of transcoding, depending on what you are trying to do to get a video to suit a particular browser, player, or platform:

* **Lossless-to-lossless** - This type of transcoding maintains the quality of your video across formats but allows you to take advantage of better hardware or compression algorithms. 
* **Lossless-to-lossy** - This type of transcoding will decrease your video in quality, but it will benefit you in ways such as – you will get a smaller and/or faster playing file, or a file that is compatible with the requirements of a particular platform, player, or browser.
* **Lossy-to-lossless** - Sometimes people think this means they are regaining quality. This isn't the case in this type of transcoding. If you transcode from a lossy format to a lossless format, all that it means is that you will not lose additional quality in the conversion process. You will not regain data you already lost through compression.

## Codecs for encoding and transcoding

For both encoding and transcoding, you will need to make use of codecs. A codec's job is to compress and decompress video files. It's right there in the name -  **co**mpress **dec**ompress or encode decode. So basically, codec is an algorithm that takes the video and shrinks it or changes it into a format that makes it compatible with the requirements of wherever you want the video to play. There are many codecs because there are many ways to compress a video or livestream for playback.



## What is transmuxing?

Now that you know the difference between encoding and transcoding, let's throw one more term in there - transmuxing. Transmuxing is when you change the container for a video instead of the format. It's a way of repackaging a video to make it compatible somewhere without changing what's in the file. 

&nbsp;

This process is faster than encoding or transcoding and takes less computing power because you only change the container, not the file. It's great when you need to quickly make something available, but the downside is that it doesn't handle things like making multiple video resolutions available. If you choose a container type that's incompatible with your video file, you may also cause compatibility issues, resulting in not being able to play the video.

## In closing

* **Encoding** - Encoding happens when you compress a raw data file from a video camera sensor or an analog source like a VHS tape. 
* **Transcoding** - Transcoding happens when you take an already compressed video file and change it to another format.
* **Transmuxing** - Transmuxing happens when you change the container of a video file but leave the video file untouched. 

We hope that explains the difference between encoding and transcoding clearly. 

_If you are looking for an affordable video API solution that does not burn a hole in your pocket for transcoding and encoding videos, check out our offerings on our [homepage](https://api.video/) or [sign-up for a free account here](https://dashboard.api.video/register)!_

Encoding and transcoding: what's the difference? 

Encoding and Transcoding - What's the Difference?

large_encoding-and-transcoding-whats-the-difference.jpg

medium_encoding-and-transcoding-whats-the-difference.jpg

small_encoding-and-transcoding-whats-the-difference.jpg

thumbnail_encoding-and-transcoding-whats-the-difference.jpg

encoding-and-transcoding-whats-the-difference.jpg

Once I upload my video, how quickly will it be ready to be viewed?

Our reply to this question has always been “it's really fast.”  And it is really fast. But, the dev team gave me access to the backend database, and pointed me to a few tables that might be helpful (thanks to Thomas Persohn for your patient help!)

Thus armed, I waded into a sea of data to better understand how fast our videos are encoded at api.video

## Encoding

When a video is uploaded to api.video, it is re-encoded to a HLS stream, with several different video dimensions and bitrates.  This allows api.video to deliver properly sized video to all users - no matter the device or network connection. (Read our post on [Responsive video delivery](https://api.video/blog/video-trends/responsive-video-delivery/) to learn more.)

> Summary:  All videos are encoded at 240p, 360p, 480p, 720p, 1080p and 2160p. However, the videos are only encoded up to the initial size of the video (so if the original video is 720p, there will not be 1080p or 2160p versions available). 

**FYI:** For our customers, encoding is absolutely free – we offer adaptive bitrate encoding at zero cost. 

How long does this step take? If a customer uploads a video to our service - they want to know how efficient api.video creates the content for viewing.

### Data in the study

We are constantly making adjustments to our infrastructure to speed the encoding step of our video (and that is one reason this post is dated 2H 2020 - we expect to be faster in early 2021). The last major adjustment was made in mid October, so the data presented in this study from every video uploaded to the api.video service between 15 October and 2 December 2020.

### Parameters that affect encoding

There are 2 major parameters that affect the speed of encoding a new video stream: the output dimensions and the length (duration) of the video.  

#### Dimensions

The output video dimensions have a huge impact on video creation - a 3840 × 2160 (or 4K or 2160p) video has millions more pixels than a 320x240 (240p) video, so it takes a lot longer to create.  In general, the videos exit the encoding process from smallest to largest.

#### Duration

If a video is 30 frames per second, and is 60 seconds long, there are 1800 frames to be created.  If a 30 frame per second video is an hour long 3600s), there are 108,000 frames to be created, so the longer the video - the more time for creation.

## Analysis

To better understand the encoding time, I divided the data by the size of the output video size, and looked at 2 lengths of video  - those under 5 minutes, and videos that are 45-75 minutes long (we are often asked how long a 1 hour video takes to encode).

I calculated encoding time for each bucket of video using percentiles.  

> Quick review - percentiles break the data into 100 evenly sized segments, so the 25th percentile is when 25% of the videos have been encoded. The median is the 50th percentile, and is when 50% of videos have been encoded.  We report here to the 95th percentile for video encoding.

### Short videos - under 5 minutes long

Many of the videos uploaded to api.video are short - under 5 minutes long.  These videos are generally ready to play in a few seconds:



The above chart has a lot of data, the 25, 50, 75, 90 and 95th percentile encoding times for all 6 variants of the video that api.video creates.

The median video is ready to play (at 240p) in 5.6 seconds, but a 720p version will be ready in 15s after encoding begins, and the 4K version will be ready in 37 seconds.

95% of all videos (under 5 minutes) will be playable in 32.6s, and will have 1080p versions ready in just over 2 minutes (140s).

### Long videos - 45 - 75 minutes long

Our most frequently asked question on encoding is "how long for a 1 hour video to be encoded and ready?"  Here are the numbers:


Observant viewers will see there are no 4K videos in this report. At this time, there are very few 4K streams that reach the 1 hour timeframe, and the data was quite noisy.  Hopefully, more of our 'long uploads' will add 4K support, so we can add this metric in our next update.

The median hour long video (red line) will be ready to play (at 240p) in just over 9 minutes (555s), and a 720p version will be ready about 18 minutes after encoding begins (1099s).

95% of hour long videos will have a 240p version ready in 33 minutes, and 720p in 54 (3230s).  the 1080p version will be available for 95% of videos in 108 minutes,

## Conclusion

Short videos will be ready to play - even at high resolution - in under a minute: the median 4K encoding for a short video is 37s. 

Hour long videos take longer to encode, and the median 720p video will be ready in 18 minutes.  95% of 720p videos will be ready to play in 54 minutes.

This is really fast! You can have responsive streaming video ready for your customers in just a few minutes with a simple upload!

That said, our team is working hard in the background to improve our infrastructure to make our encoding speeds even faster! 

We're really excited to have hard numbers to share with you on our encoding speeds, and we cannot wait to re-benchmark this data in 2021 to see how much faster your videos will be encoded as we improve our service.

Do you have questions about api.video or video encoding? Reach out on our [community page](https://community.api.video).


How fast does api.video encode video? 2H 2020 data

medium_gif.jpg

small_gif.jpg

thumbnail_gif.jpg

gif.jpg

Huge pricing update! Introducing video encoding at zero cost

Featured article

# api.video blog

Blog

Follow the api.video Blog to explore tutorials, video use cases, and learn about on-demand and live-streaming video updates.