As devices and platforms evolve, the video format sands are ever-shifting.

Here, we go into detail on the VP9 codec and see what it offers versus the competition. We talk about its history, then look at its pros and cons, so you can make a decision on whether VP9 is a good fit for your video projects.

Use the links below to skip ahead.

What Are Codecs, and Why Are They Important in OTT Video?

Codecs are responsible for compressing and decompressing video when it is created and played back. Your choice of codec will affect your video compression ratio, encoding, and playback speed. It will also affect your videos’ quality and which devices and players are able to view them. It can affect their maximum resolution and features, too. In OTT video these are critical, as they directly affect your server and bandwidth costs. They also define your potential customers. Not every device can view every codec, and quality can vary even on supported devices.

You want to deliver your video to as many people as possible, with the best quality, at the lowest cost. Since there isn’t a dream codec that’s best in class for all of these, you need to compromise on at least one. To figure out which, you need the details.

What Codecs are Popular Today and why?

Things move quickly in the world of video, and what’s popular today may not be so for long. The current state of play is as follows. According to Bitmovin’s Video Developer Report, H.264 (AVC) is the world’s most popular codec with over an estimated 85% of video-on-demand using it.

Most modern devices have hardware that can decode AVC, making it easy to play, making it a great choice if you want the broadest possible user base.

This codec’s licensing system is complicated, though, with thousands of patents involved. That means you need to pay royalties if you want to use it for hardware or paid content. Despite this, it is used by many services, as well as Blu-ray discs, and was the codec of choice for many early HDTV broadcasts.

Its successor, H.265 (or HEVC), is also common, though less popular, and uses up to 50% less bandwidth than H.264. However, much like its predecessor, H.264, HEVC can be expensive, with patents and fees required to use it.

The VP9 Codec

Widely supported, open source and without royalties, the VP9 codec has several key advantages over the competition, with a few caveats.

History of VP9

Google purchased On2, creators of VP8 codec, for $124.6 million in 2010. They began work on VP9 soon afterward, eventually releasing it in late 2012. Support for it spread quickly, and by 2017 it was used by Chrome, Firefox, and Edge. It had hardware support from NVidia, ARM, and others. It is widely supported on Android, but iOS has added support only in its most recent version.

The base software used to encode VP8 and VP9 is called libvpx (it’s also possible to encode VP8 and VP9 using vpxenc.exe). Fortunately, it’s free, easy to use, well-documented, and can handle real-time encoding should you need it. Refinements to the libvpx library used to encode videos have improved VP9 over time, with a 50-70% speed boost, multithreading, and support for extra bit depths and chroma subsampling modes among the additions.

How Is VP9 Different?

There are several major differences between VP9 and its rival video codecs. Take a look at the pros and cons below.

Pros of VP9 vs. Other Codecs

Like HEVC, VP9 has a 50% advantage over H.264, but VP9 can outperform HEVC at resolutions above HD. That makes it a great choice if you’re working with video at different sizes, or if you’re focusing specifically on HD. VP9 can use hardware decoding on Intel and ARM devices. Thanks to widespread hardware support, it gives you smoother playback on PCs in most scenarios, making it ideal for general use.

Google and Youtube use VP9 for all of their 4K videos, which itself is a proof point that VP9 is a viable option for video streaming providers. Now even Apple has added support for the codec, making it the clear choice for high-resolution video in the macOS version of the Safari browser.

Android has supported VP9 since 4.4. “KitKat” launched in 2013, so all but the most ancient devices can use it. VP9 is open source, making it free and convenient to deploy. By contrast, HEVC is mired in patent issues, making it expensive—and potentially troublesome—to use. It costs $0.20 per device to include HEVC support, which discourages adoption and may well give VP9 a longer tail for hardware manufacturers, even as new codecs eventually take over.

Early comparisons suggested VP9 had a video compression disadvantage over its competitors, but Netflix claimed that this could be eliminated or reversed by fine-tuning the implementation. Like any general purpose video coding format, there are a lot of interdependent settings that can make a big difference to the size of the output bitstream, quality, and overall costs, so you’ll need to find the right balance for your workflow and business model. Some companies may closely guard their findings and exact video encoder settings, but information on the relative performance in different scenarios is available.

Cons of VP9 vs. Other Codecs

Not all players work well with VP9. Older devices that don’t support hardware decoding are still in use. If you’re a developer, your friends’ phones may not be representative of the wider population. At first, iOS devices didn’t support VP9, but that changed with the update to version 14. They have supported H.265 since iOS 11. The older, less cpu-intensive codec, H.264, runs smoothly on practically all devices, so if you want a single codec to run as close to everywhere as possible—and can budget for the monetary costs—that should be your preference.

There are some issues with 360 videos and VP9. While YouTube works well with VP9 360-degree video, its metadata injector doesn’t. Other publishers may have similar issues. It is important to confirm that your target platform has support for the specific type of video you want to deploy, so testing before making a commitment is recommended. VP9 is also slower to encode. The more videos you have to deal with, the more of an issue that will be.

Microsoft’s Internet Explorer (now Edge) browser added support for VP9 as an experimental feature in Windows 10 back in 2017, but it is now fully supported on Windows machines, bringing it in line with the VP9 support already available in Linux, Android, MacOS and iOS. The AV1 codec is already en route to replacing VP9. This codec builds on work done towards VP10 and could potentially halve video file sizes. Currently, VP9 supports HDR and DRM and still has wider hardware decoding support than AV1, but this is something to keep an eye on. 

Businesses Currently Using VP9

VP9 can be found in many places. Google uses it on YouTube and Google Stadia, as mentioned earlier. It is also used for videos on WikiMedia Commons. Netflix uses it, though not exclusively, giving it a 35% bandwidth saving at equivalent quality. Meta, especially Facebook, use VP9 extensively, but they have stated their intention to update the majority of their video encoding to AV1. 

Use Cases/Business Situations Where VP9 Might Be a Good Choice of Video Codec

VP9 works smoothly on PCs at high resolutions, so if you’re delivering OTT video to the desktop, it’s a great choice. It can save you bandwidth over other codecs while delivering the same or better quality. If you need control over your codec or even want to make a few customizations, then open source has obvious advantages over the competition. The lack of fees can add up to significant savings if you are delivering paid content. The better support for UHD, HDR and 360-degree videos also make it a great choice if those are your specialties. 

The Future of VP9

If H.264’s longevity is any indication, VP9 will still be around for some time. In the near future, next-generation codecs such as VVC (released in 2020) and AV1 (released in 2018) promise improvements. It will take time for them to spread, but all developers need to keep an eye on the horizon. VVC, the successor to H.265, promises a 50% bitrate improvement. AV1, building on VP10, is promising a 30% video compression rate improvement over H.265. Both of these are worth getting excited about, but of course, browser, device and feature support will be crucial when making a decision. If the pattern holds, it’s unlikely that companies using VP9 will completely phase it out any time soon. You can learn more about the current state of AV1 playback support here.

VP9 Encoding with Bitmovin

Bitmovin offers multiple ways to get started with your own VP9 encoding, even with a free trial account. In the dashboard UI, our encoding wizard allows you to choose between H.264, H.265/HEVC and VP9 without any coding skills or experience necessary.

For those with a little more experience, our APIs and SDKs have VP9 presets available, or you can fine tune all of the parameters individually. You can also use VP9 together with our award-winning Per-Title Encoding to analyze and adjust the settings for each piece of video content, ensuring the best possible quality of experience for viewers, without wasting any overhead data. 

Conclusion

VP9 has several advantages over other codecs. It’s open source, it works well with higher resolutions and enjoys support on many devices (including most browsers, mobiles and smart tvs). It also has drawbacks, such as slower encoding speed and slightly less playback support than H.264. If you’re delivering high-resolution videos VP9 is one of the strongest video codec choices, at least for now. If you want to target every legacy device, you’ll still need to use H.264 alongside VP9. You should consider which of these will make the most difference to your team and your customers when deciding what to use. If you need help upgrading or implementing multiple codecs, Bitmovin can help: https://bitmovin.com/encoding-service/

If you do choose VP9, you can take advantage of wide playback support, high-quality encoding, and a well-developed ecosystem of tools. It’s a great, low-cost way to deliver videos and can help you produce content that works for you and your clients.

Originally published in June 2021; this article was updated July 2023 for accuracy and completeness.

VP9 FAQs

Is VP9 better than H.264?

This depends on the specific use case and requirements, but VP9 generally offers better compression efficiency and quality compared to H.264, making it a popular choice for online streaming platforms and web-based video content.

What is VP9 video codec?

VP9 is an open and royalty-free video codec developed by Google (go to their website to find out more). It is designed to efficiently compress and decompress video content, allowing for high-quality streaming and playback while reducing bandwidth usage.

How do I get the VP9 codec?

Playback support for the VP9 codec is usually included in modern web browsers, video players, and streaming platforms. If you’re developing software or working with specific applications that require VP9 support, you’ll need to use a video encoder with VP9 support, like Bitmovin or ffmpeg.

Is VP9 better than H.265?

When comparing VP9 and H.265 (also known as HEVC), both codecs offer similar benefits in terms of quality and compression efficiency. The choice between them often depends on the specific requirements of the system or platform. H.265 is more widely supported, while VP9 is favored by Google and used extensively in the WebM container file format.

What is VP9 video quality?

VP9 video quality is generally considered to be very good. It can provide high-definition video playback with efficient compression, resulting in reduced bandwidth consumption while maintaining satisfactory visual quality. However, the actual quality may vary depending on factors such as the source material and encoding settings.

Is VP9 the best video codec?

While VP9 is a highly regarded codec, calling it the “best” depends on the context and criteria used for evaluation. VP9 has gained popularity due to its open and royalty-free nature, efficient compression, and wide adoption by major streaming platforms. However, other codecs like H.265 and AV1 also offer competitive features and more advanced video compression.

What is VP9 video compression technology?

VP9 technology refers to the technical specifications, algorithms, and encoding/decoding techniques used in the VP9 codec. It incorporates advanced video compression methods such as block prediction, entropy coding, and spatial and temporal scalability to efficiently encode video data. VP9 is developed by Google as part of their efforts to improve video streaming and enable high-quality playback on the web.

The post VP9 Codec: The Complete Guide to Google’s Open Source Video Codec appeared first on Bitmovin.

SD: 700 kbps to 1.1 Mbps 

1080p HD: 5 Mbps 

4K UHD: 15 Mbps to 25 Mbps

Those are largely based on what’s needed to view SD/HD content encoded with AVC and 4K content encoded with VP9 or HEVC. Apple’s HLS spec has examples for AVC and HEVC that fall in line with those numbers and they are familiar ranges to anyone who has done any live streaming recently. So I’ll ask again, would you be interested in 1080p at 286 kbps or 4K at 684 kbps? It really is possible, right now, with Bitmovin Per-Title and 3-pass encoding together with the industry standard AV1 codec. Keep reading to see a few real examples and learn how to get started with your own AV1 encoding.

Leading the Way with AV1

Bitmovin has a long history with AV1, first making headlines in 2017 for debuting the world’s first AV1 live stream at that year’s NAB show, winning a Best of NAB award in the process. Later that fall, we partnered with Mozilla to create the first AV1 HTML5 playback demo in the Firefox browser. You can read more details about our history and progress with AV1 in this post, but recent highlights include adding smart presets and support for 3-pass and Per-Title encoding optimization. We’ve also developed 2 new patent-pending technologies around AV1 that we hope to share more details about soon!
While early adoption was limited by slower performance and minimal playback support, the data from our most recent Video Developer Report shows that AV1 may be at an inflection point, with 15% of respondents saying they were already using AV1 in 2021 and another 22% saying they planned on adding it to the mix in 2022.

Getting started with a new codec usually means beginning with some educated guesswork followed by a lot of experimentation that can end up being costly in terms of both time and resources. With AV1, we’re trying to help eliminate that phase altogether by pairing our Per-Title ABR ladder optimization together with 3-pass quality optimization in a SINGLE API CALL!!! Our Simple Encoding API combines Bitmovin’s market-leading quality together with DASH and HLS packaging, delivering the ideal bitrates to maximize QoE without any unnecessary overhead data. You choose the codec, provide the source file and destination and that’s it, no other configuration required. We also have a Postman Repository with some example templates, which is actually what I used to create the AV1 samples below. For workflows requiring additional configuration, AV1 and Per-Title are fully available and supported within our standard APIs and SDks.

4K Bitrates: YouTube VP9 vs Bitmovin AV1

YouTube’s use of AV1 and other codecs was covered thoroughly in an enlightening series of posts by Jan Ozer. The quick recap is that YouTube is using AV1 for the 4K versions of their popular videos, but VP9 for less-viewed 4K content, as I confirmed with my own uploads below. So while it would be nice and a more direct comparison if we had the results of YouTube’s AV1 transcoding, it’s still interesting to see the potential bitrate savings when jumping from VP9 to AV1. For the analysis, I used youtube-dl to download the 4K VP9 versions and MediaInfo to identify the bitrate.  

Shot on iPhone 13 – “marina”

First let’s look at a short 4K (3840 x 2160) clip I shot on iPhone 13, “marina”. It’s a mostly static shot, with a few high motion/high detail regions. Bitmovin’s Per-Title optimization set the top 4K ladder rung at 1.37 Mbps. At the low end, the 240 kbps rendition was 1440p, meaning even on the slowest connections, viewers would still see better than full HD.
[bitmovin_player id=’225410′]

Youtube’s 4K version – VP9 @ ~22 Mbit/s

Big Buck Bunny

Next, let’s look at a more familiar example, everyone’s favorite animated short,  Big Buck Bunny. On the top end, Bitmovin’s Per-Title AV1 delivers 4K under 2 Mbps. The bottom 240kbps rung is 1600 x 900, so even on over-shared wifi, your users would still be happily watching even better than 720p video. You can see the result here. 

Youtube’s 4K version – VP9 @ ~12 Mbit/s

Tears of Steel

Last but not least, we have Tears of Steel, the cinematic short from the Blender Foundation that combines real footage and human actors with computer generated animation and effects. Again we see the top quality 4K variant under 2 Mbps and  still have a full HD frame for the bottom 240 kbps version. Imagine being able to deliver at least HD video to all of your customers, regardless of connection speed. You can see the result here.

Youtube’s 4K version – VP9 @ ~12 Mbit/s

Get Started Now and Ride the AV1 Momentum

YouTube and Netflix have both been delivering AV1 to compatible Android devices since 2020 and last November, Netflix published a detailed post about using AV1 for 4K content, so while support for AV1 still lags a bit behind older codecs, there’s clearly already enough of a device footprint to make it worthwhile. Roku and Amazon’s newest “sticks” and the upcoming generation of Chromecasts are all <$100 options that give older TVs an AV1 upgrade and Intel, Qualcomm, and multiple SoC manufacturers have recently announced upcoming AV1 support, so the wave of capable devices will continue growing. While the actual numbers will vary based on your CDN and storage pricing, we’re seeing that for content with as few as 10K views, there is potential ROI in adding AV1 to your multi-codec strategy (AVC +HEVC). 

Updating to AV1 means being able to deliver at least HD, in many cases 4K, over network connections that had been limited to Standard Def or compromised, blocky versions of your content. Improving and maintaining consistently higher quality with AV1 means happier customers and a larger potential market for HD and UHD upsell tiers, not to mention lower CDN and storage costs. For most streaming services, adding AV1 to their multi-codec strategy will be inevitable, the only question is how soon will they start reaping the benefits?
You can start seeing the benefits of AV1 + Per-Title and 3-Pass encoding today with our free trial, so sign up now and give it a shot! !
AV1 is the next generation video codec and it’s on track to deliver a 30% improvement over VP9 & HEVC – Learn More

More AV1 Resources:

• Bitmovin Improves Support AV1 Video Encoding for VoD
• Bitmovin’s AV1 Encoding Gift Guide
• Cool New Video Tools: Five Encoding Advancements Coming in AV1

The post 4K Video at SD Bitrates with AV1 appeared first on Bitmovin.

Codec Presets for H264, HEVC, VP9

The presets in Bitmovin’s dashboard for VoD and live content flattens this learning curve significantly. Every codec has its own configuration options and presets. At the time of this blog post, Bitmovin offered presets for H264/AVC, H265/HEVC, and VP9 to give you a quick start for the most supported/used codecs.
For an example of how to use the presets, you can check out our getting started guides. E.g. for Java:

[bg_collapse view=”button-blue” color=”#fcfafa” icon=”arrow” expand_text=”View configuration input” collapse_text=”Hide configuration input” ]
H264VideoConfiguration videoCodecConfiguration1 = new H264VideoConfiguration();
videoCodecConfiguration1.setName(“Getting Started H264 Codec Config 1”);
videoCodecConfiguration1.setBitrate(1500000L);
videoCodecConfiguration1.setWidth(1024);
videoCodecConfiguration1.setPresetConfiguration(PresetConfiguration.VOD_STANDARD);
videoCodecConfiguration1 = bitmovinApi.encoding.configurations.video.h264.create(videoCodecConfiguration1);

H264VideoConfiguration videoCodecConfiguration2 = new H264VideoConfiguration();
videoCodecConfiguration2.setName(“Getting Started H264 Codec Config 2”);
videoCodecConfiguration2.setBitrate(1000000L);
videoCodecConfiguration2.setWidth(768);
videoCodecConfiguration2.setPresetConfiguration(PresetConfiguration.VOD_STANDARD);

videoCodecConfiguration2 = bitmovinApi.encoding.configurations.video.h264.create(videoCodecConfiguration2);

H264VideoConfiguration videoCodecConfiguration3 = new H264VideoConfiguration();
videoCodecConfiguration3.setName(“Getting Started H264 Codec Config 3”);
videoCodecConfiguration3.setBitrate(750000L);
videoCodecConfiguration3.setWidth(640);
videoCodecConfiguration3.setPresetConfiguration(PresetConfiguration.VOD_STANDARD);

videoCodecConfiguration3 = bitmovinApi.encoding.configurations.video.h264.create(videoCodecConfiguration3);
[/bg_collapse]

Our Promise

As a promise to all of our customers, partners, and partners to help reduce their time to market while maintaining (or improving) your viewers’ Quality of Experience we made sure to invest a lot of time and resources to determine and provide select the best configuration combinations. As many settings are interdependent, creating an appropriate preset involves a lot of testing to arrive at the best possible configuration for your specific content. As a general rule of thumb, we recommend to only begin your optimization step once you have your general setup up and running.
However, the offered presets can be used as a starting point and can be extended/overwritten after launch to optimize for your specific use-case once you made yourself familiar with the available options and their impact on your content. To further ease your organization into the process of selecting a new encoder, we’ve listed our available presets at the links below:

• All available H264 presets: https://bitmovin.com/docs/encoding/tutorials/h264-presets
• All available H265 presets:https://bitmovin.com/docs/encoding/tutorials/h265-presets
• All available VP9 presets: https://bitmovin.com/docs/encoding/tutorials/vp9-presets

Shorten your time-to-market while maintaining a high quality of experience using Bitmovin’s encoder with Codec Presets. Do you want to learn more? Check some of our other great codec-oriented content:
[Blog] Battle of the Codecs: VP9 vs HEVC
[Blog] Living in a Multi-Codec World
[E-Book] Ultimate Guide to Container Formats

The post Improving Time-to-Market: H264, HEVC, and VP9 Video Codec Presets appeared first on Bitmovin.

VP9 vs HEVC: The encoding setup

Software

For the test I used the following:

• libvpx-vp9 encoder (version 1.8.2) for VP9 encoding
• x264 encoder (tag235ce6130168f4deee55c88ecda5ab84d81d125b) for h.264/AVC encoding
• x265 encoder (version 3.2) for h.265/HEVC encoding.

I also compiled libvmaf (version 1.5.1) and ffmpeg (version 4.2.3) to run the encoders and perform PSNR, SSIM and VMAF measurements.
If you want to recreate the same execution environment: I used Docker to build it so you can recreate the exact same environment using my Dockerfile which can be found here.

Test set

For the test set I used Full HD and 4K sequences from the JEVT SDR test set [1] which was also used in the standardization of VVC.
Some of these sequences are well known and were already used in several prior standardization activities. All sequences are 10 seconds long and used in YUV 4:2:0 subsampling.
The sequences are as follows:
 

Encoding

For encoding, I used default settings with ffmpeg. All encodings implemented 2-pass encoding with a set target bitrate. The corresponding ffmpeg calls look like this: 

ffmpeg -i input.yuv -c:v libx264 -preset veryslow -b:v br --pass 1/2 enc.mp4
ffmpeg -i input.yuv -c:v libx265 -preset slow -b:v br --pass 1/2 enc.mp4
ffmpeg -i input.yuv -c:v libvpx-vp9 -b:v br --pass 1/2 enc.mp4

Presets

I used the following presets for each encoder:

• x264 – very slow
• X265 – slow 
• libvpx-vp9 no preset was chosen (which corresponds to a cpu-used value of 1)

These settings were chosen from experience. While they do not yield the highest possible compression performance, they correspond to a very high quality encode with a good trade-off between encoding time and quality. 
The encodings were performed under two scenarios:

1. Fixed Resolution: no scaling is applied. Encoding was performed at the resolution of the original sequence with various different target bitrates. The bitrates for x265 and libvpx-vp9 were: 4.8 Mbit/s, 2.4 Mbit/2, 1.8 Mbit/2, 1.2 Mbit/s and 0.8 Mbit/s. For x264, these values were multiplied by a factor of two. Based on the pixel count, another factor of four was applied to the bitrates for the 4K encodes.
2. Bitrate Ladder: Encoding was performed at a range of different resolutions and bitrates also referred to as a bitrate ladder. These were: 1920×1080 at 4.8Mbit/s, 1920×1080 at 2.4Mbit/s, 1280×720 at 1.8Mbit/s, 1280×720 at 1.2Mbit/s, 854×480 at 0.8 Mbit/s, 640×360 at 0.4 Mbit/s and 426×240 at 0.2 Mbit/s. For the 4K encodes, two additional points with 3840×2160 at 19.2 Mbit/s and 9.6 Mbit/s were added. As in the first scenario, the bitrates were multiplied by a factor of two for x264. The final measurement step was performed after upsampling back to the resolution of the original source. The default scaling algorithm is bicubic.

Results

For each encoding, multiple different measurements were performed.
In the cases where encoding was performed at a lower spatial resolution, the measurement was performed after upscaling the reconstruction back to the resolution of the source.
PSNR and SSIM measurements were performed for the three components (Y/U/V) as well as an averaged value. VMAF was calculated as well. For the 4k source files, the 4k VMAF model was applied.
For the encoding time, I measured the absolute elapsed time as well as the CPU time per thread. This is a sample plot for the sequence “MarketPlace” in the fixed resolution scenario (hover over image to zoom):

Coding performance

For both scenarios I calculated BD-rate results for the average PSNR, average SSIM, and VMAF values relative to x264 [2]: 

VP9 vs HEVC Complexity Levels

For all encodings, I also measured the overall runtime of the encoding as well as the CPU-time per thread. Both of these values can give us an indication of how well the encoders can utilize multiple cores.
All tests were performed on an Intel 6 core (12 thread) processor. The results for x265 and libvpx-vp9 were taken relative to the values of x264 and then averaged.
The following table displays the relative factors compared to x264:

Files

Finally, I would like to provide all the files needed in order to recreate the results.
Furthermore, the archive includes all the result files that were used to determine my findings. I encourage everybody to double-check them.
However, for legal reasons, I can not provide the encoded video sequences or the original uncompressed YUV test sequences.
The archive includes the following scripts which should be helpful:

• Test shell scripts: These scripts were used to perform the encoding and the measurements in the docker container. Please feel free to use these in your own tests.
• Python scripts: The python scripts were used to calculate the BD results (calculateBDResults.py), to plot the measured values per sequence (plotResults.py) and to plot the results per frame (plotPerFrameResults.py). Please use these scripts to take a detailed look at the results. You require python 3 and matplotlib installed. Each script must be called with the name of a sub-folder that should be plotted.

File:
https://drive.google.com/file/d/1wbUA56vB-LeH2H8nV-EGzhJPWW7ikkwx/view?usp=sharing

Summary

While this is just a quick and superficial encoder comparison, I tried to keep it close to practical applications. From the VP9 vs HEVC test here, libvpx-vp9 is able to take on x265 when it comes to coding performance.
Please note that only these encoders were tested and there are other AVC, HEVC, and VP9 encoders out there which may perform better.
If you have additional inputs to the test please reach out to me! I am very willing to run this again using a different set of settings. 

References

[1] – A. Segall, E. François, W. Husak, S. Iwamura, D. Rusanovskyy – JVET common test conditions and evaluation procedures for HDR/WCG video – JVET-P2011 
[2] – Gisle Bjontegaard – Calculation of average PSNR differences between RD-curves – VCEG-M33 Austin, Texas, USA, 2-4 April 2001

More video technology guides and articles:

Did you know?

Bitmovin has a range of VOD services that can help you deliver content to your customers effectively.
Its variety of features allows you to create content tailored to your specific audience, without the stress of setting everything up yourself. Built-in analytics also help you make technical decisions to deliver the optimal user experience.
Why not try Bitmovin for Free and see what it can do for you.

The post HEVC vs VP9: The Battle of the Video Codecs appeared first on Bitmovin.

This scientific evaluation puts AV1 to the test against industry standard codecs and shows that AV1 is able to outperform VP9 and even HEVC by up to 40%

Introduction

For practical Over-the-top (OTT) streaming applications it is mostly necessary to supply streams using multiple different video codec standards in order to stream to a wide range of devices and platforms.

The most commonly used video codes in this scenario are AVC, VP9 and HEVC. With the standardization of AV1, another modern video coding standard is joining in.

While AVC offers the best compatibility across devices and platforms, the newer standards such as HEVC and AV1 offer a much higher compression efficiency and thereby also a better user experience.

Another key difference between the codecs is that VP9 and AV1 were developed with the goal of being open source and freely available for anybody to implement and use without any royalties while AVC and HEVC require a royalty to be paid.

The multi-codec dataset presented here adopts the aforementioned standards in a practical OTT adaptive streaming scenario. The full dataset is freely available online (http://www.itec.aau.at/ftp/datasets/mmsys18/). For an in-depth description of the dataset, please reference (https://arxiv.org/abs/1803.06874).

The Dataset

Since the main focus is on an HTTP Adaptive Streaming (HAS) dataset, we adopted a set of bitrate/resolution pairs – referred to as the bitrate ladder – with a range from very low bitrates/resolutions of 100 kbits at 256×144 pixels up to 4k resolutions at 20 megabits.

This is a well-established approach for OTT streaming applications.

For the video sequences, we tried to cover a range of video sequences with different properties. For this, we calculated the spatial and temporal information so that the sequences contain different amounts of motion and texture.

For the adaptive streaming encoding, a size per segment of 2, as well as 4 seconds, was used.

For AV1 encoding a snapshot of the reference software was used (v0.1.0-7691-g84dc6e9). For the encoding, the cpu_used preset was set to 2.

The encoding for AVC, HEVC, and VP9 was performed utilizing ffmpeg and, thus, libx264, libx265, and libvpx-vp9 are used. For these codecs, encoding performed with the slow preset. For all codecs, a two-pass scheme is employed.

Encoding of the AV1 bitstreams according to these specifications was performed by the Institute of Information Technology at the Alpen-Adria Universität Klagenfurt. Encodings using the other codecs AVC, HEVC, and VP9 was carried out by Bitmovin using the Bitmovin Video Encoding cloud infrastructure.

All bitstreams were then collected and jointly evaluated.

The Evaluation

For evaluation, the reconstruction at lower resolutions was upscaled to the original resolution and the weighted PSNR relative to the original source was calculated ((6*Y+U+V)/8).

From these values we calculated the corresponding Bjøntegaard-Delta bit-rate (BD-rate) values.

When calculated over the entire bitrate ladder, we were able to observe an average bitrate reduction of AV1 compared to VP9 of 13% and compared to HEVC of 17%.

When we focus on the higher part of the bitrate ladder, the BD-rate reduction compared to VP9 increases to 22%-27% while compared to HEVC, the reduction increases to 30%-43%.

It should be noted that because of the fixed bitrate ladder, the overlap becomes rather small for the highest resolutions in some sequences and the results should therefore be interpreted with some caution.

This could definitely be improved by adapting the bitrate ladder to the properties of the different sequences.

Conclusion

The dataset is meant to offer a first HLS set environment for the emerging video coding standard AV1 and the other in OTT applications most frequently used codecs AVC, VP9 and HEVC.

The coding performance results for this test set indicate, that AV1 is able to outperform VP9 and even HEVC by up to 40%.

Please note that this evaluation primarily targets HAS services and has a very specific setup.

While it can give an indication on the coding performance of AV1, the results should be interpreted with caution.

Video technology guides and articles

• Back to Basics: Guide to the HTML5 Video Tag 
• What is a VoD Platform?A comprehensive guide to Video on Demand (VOD)
• Video Technology [2023]: Top 5 video technology trends
• HEVC vs VP9: Modern codecs comparison
• What is the AV1 Codec?
• Video Compression: Encoding Definition and Adaptive Bitrate
• What is adaptive bitrate streaming
• MP4 vs MKV: Battle of the Video Formats
• AVOD vs SVOD; the “fall” of SVOD and Rise of AVOD & TVOD (Video Tech Trends)
• MPEG-DASH (Dynamic Adaptive Streaming over HTTP)
• Container Formats: The 4 most common container formats and why they matter to you.
• Quality of Experience (QoE) in Video Technology [2023 Guide]

The post Best Video Codec: An Evaluation of AV1, AVC, HEVC and VP9 appeared first on Bitmovin.

By encoding your videos using a multi-codec approach you can double the quality while still reducing your bandwidth consumption and maintaining maximum device reach.

In the spectrum of online video, you probably already know that H.264 (also known as AVC) is ubiquitous. Nearly every device and operating system supports decoding either on hardware or software. Although this compression technology is widely supported, which is a significant advantage, it is nowhere near as efficient as the next generation codecs in terms of compression rate.
According to Netflix’ experiments, H.265 (also known as HEVC) can deliver up to 50% bitrate savings when compared to previous generation codecs like H.264/AVC. Besides Apple devices equipped with iOS 11 and macOS High Sierra, H.265 is also supported by most 4K SmartTVs and Microsoft Edge for Windows 10 (with hardware decoder present in the device).
Similar to H.265, VP9 is another great option when it comes to reducing bandwidth consumption or delivering higher quality with the same bitrate. Bitrate savings can reach up to 50% compared to H.264, dramatically lowering your CDN costs. VP9 is supported on multiple platforms including Google Chrome, Firefox, Microsoft Edge and Android devices.
Roughly 83% of the internet users in the US could be reached with VP9 and HEVC. The remaining 17% would fall back to H.264 and you would still have complete coverage of every browser. The table below shows the browser market share for desktop and mobile.

Source: netmarketshare.
* Only available in Safari for iOS 11 and macOS High Sierra.
** Only available in Edge 14.14291.

Codec comparison

The figure below shows a side-by-side codec comparison. Maintaining the same visual quality, a Full HD content could be encoded at 4 Mbit/s (50% less than H.264) with H.265/HEVC and VP9.

Saving potential exemplified

As previously stated, roughly 83% of the internet users in the US could be reached with H.265 or VP9, thus benefiting both end users by consuming less bandwidth and also streaming companies by reducing CDN costs. Considering 50% of bandwidth reduction by leveraging these codecs your total saving potential would be of 42%. Under those circumstances, let’s picture the scenario described in the table below:

How to implement multi-codec streaming with Bitmovin

Now that we have established the effectiveness of a multi-codec approach on your online video strategy we can jump right into the “how to” section of the article. First of all let’s evaluate what we can do on the encoding side.
With the Bitmovin API you can encode your content with different codecs like H.264/AVC, H.265/HEVC, VP8, VP9, and recently also AV1. Ultimately the output can be MPEG-DASH, HLS, Microsoft Smooth and/or progressive MP4/WebM/TS.

To work with the Bitmovin API we have API clients for all the major programming languages. Visiting our Github page you will find all of them as well as code examples. For this particular topic of multi-codec streaming we have this Java API Client example which covers everything that is being presented in this article.

Each video and audio stream encoded using a given codec needs to be wrapped in a container. A container/muxing supports multiple streams, such as audio and video tracks. For adaptive streaming formats such as MPEG-DASH and HLS it is common to have separated muxings for audio and videos, however, for progressive formats obviously audio and video tracks needs to be muxed altogether. The table below shows the containers that can be used for each of the codecs.

As shown above, fMP4 muxings can be used to hold H.264 and H.265 segments for both HLS and MPEG-DASH. As a result these segments can be encoded only once and be referenced by a MPEG-DASH and HLS manifest, reducing your storage costs by 50%.
Adaptive streaming formats also allow us to include multiple codecs to the same manifest/playlist, that is the beauty of the solution. By encoding your content like this, you can hand over the logic of choosing the most appropriate codec to the player (you will find more details on that further down).
The examples below show how a multi-codec MPEG-DASH manifest and HLS playlist look like. For MPEG-DASH we use one AdaptationSet for each codec. On the other hand, for HLS we simply list all the variant streams with it’s codecs one below the other.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MPD id="fc7573ef-1945-4eea-91b0-fe6e20e870ca" profiles="urn:mpeg:dash:profile:full:2011" type="static" mediaPresentationDuration="P0Y0M0DT0H0M46.067S" minBufferTime="P0Y0M0DT0H0M2.000S" bitmovin:version="1.19.0" xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:bitmovin="http://www.bitmovin.net/mpd/2015" xmlns:ns2="http://www.w3.org/1999/xlink">
    <Period id="437c9a5c-a403-499c-92ca-b24944a70b77" start="P0Y0M0DT0H0M0.000S">
        <AdaptationSet segmentAlignment="true" mimeType="video/mp4">
            <Representation id="990f791b-984f-4566-a3b1-77a0ffbe2e60" bandwidth="875000" width="854" height="480" frameRate="30" codecs="hvc1.1.c.L90.90">
                <SegmentTemplate media="video/875_h265_fmp4/segment_$Number$.m4s" initialization="video/875_h265_fmp4/init.mp4" duration="120000" startNumber="0" timescale="30000"/>
            </Representation>
            <Representation id="6c1b1d6f-8a59-4a97-9424-ee99bb17819b" bandwidth="1175000" width="1280" height="720" frameRate="30" codecs="hvc1.1.c.L93.90">
                <SegmentTemplate media="video/1175_h265_fmp4/segment_$Number$.m4s" initialization="video/1175_h265_fmp4/init.mp4" duration="120000" startNumber="0" timescale="30000"/>
            </Representation>
        </AdaptationSet>
        <AdaptationSet segmentAlignment="true" mimeType="video/webm">
            <Representation id="00f77da9-8658-4afb-9710-0dfb08e7d346" bandwidth="875000" width="854" height="480" frameRate="30" codecs="vp9">
                <SegmentTemplate media="video/875_vp9_webm/segment_$Number$.chk" initialization="video/875_vp9_webm/init.hdr" duration="120000" startNumber="0" timescale="30000"/>
            </Representation>
            <Representation id="60ad47c8-9b48-41a9-8c3d-16fe4c9e56b2" bandwidth="1175000" width="1280" height="720" frameRate="30" codecs="vp9">
                <SegmentTemplate media="video/1175_vp9_webm/segment_$Number$.chk" initialization="video/1175_vp9_webm/init.hdr" duration="120000" startNumber="0" timescale="30000"/>
            </Representation>
        </AdaptationSet>
        <AdaptationSet segmentAlignment="true" mimeType="video/mp4">
            <Representation id="e53c20bd-519d-4881-9e35-6dd1a3817eaf" bandwidth="1750000" width="854" height="480" frameRate="30" codecs="avc1.4D401F">
                <SegmentTemplate media="video/1750_h264_fmp4/segment_$Number$.m4s" initialization="video/1750_h264_fmp4/init.mp4" duration="120000" startNumber="0" timescale="30000"/>
            </Representation>
            <Representation id="8138b60d-2bc8-4eef-91b9-3ef9e27b6cbb" bandwidth="2350000" width="1280" height="720" frameRate="30" codecs="avc1.4D401F">
                <SegmentTemplate media="video/2350_h264_fmp4/segment_$Number$.m4s" initialization="video/2350_h264_fmp4/init.mp4" duration="120000" startNumber="0" timescale="30000"/>
            </Representation>
        </AdaptationSet>
        <AdaptationSet lang="en" segmentAlignment="true" mimeType="audio/mp4">
            <AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2"/>
            <Representation id="3565543a-8524-41ac-98b4-006fcd21eaea" bandwidth="128000" audioSamplingRate="48000" codecs="mp4a.40.2">
                <SegmentTemplate media="audio/128_aac_fmp4/segment_$Number$.m4s" initialization="audio/128_aac_fmp4/init.mp4" duration="192000" startNumber="0" timescale="48000"/>
            </Representation>
        </AdaptationSet>
    </Period>
</MPD>

Example of a multi-codec MPEG-DASH manifest.

#EXTM3U
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-VERSION:6
#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio_128",NAME="audio_128.m3u8",LANGUAGE="en",URI="audio_128.m3u8"
#EXT-X-STREAM-INF:BANDWIDTH=2101985,AVERAGE-BANDWIDTH=1796254,CODECS="avc1.4D401F,mp4a.40.2",RESOLUTION=854x480,AUDIO="audio_128"
video_h265_480p_1750.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2739681,AVERAGE-BANDWIDTH=2372431,CODECS="avc1.4D401F,mp4a.40.2",RESOLUTION=1280x720,AUDIO="audio_128"
Video_h265_720p_2350.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2049427,AVERAGE-BANDWIDTH=1824322,CODECS="hev1.1.6.L90.90,mp4a.40.2",RESOLUTION=854x480,AUDIO="audio_128"
video_h264_480p_1750.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2706785,AVERAGE-BANDWIDTH=2421640,CODECS="hev1.1.6.L93.90,mp4a.40.2",RESOLUTION=1280x720,AUDIO="audio_128"
video_h264_720p_2350.m3u8

Example of a multi-codec HLS playlist.
On the playout side, as you can see in the code example below, by using Bitmovin Adaptive Player you just need to provide the dash, hls and/or progressive URLs as you would normally do. The player is responsible for identifying the most appropriate codec to deliver based on the browser/device capabilities.

var conf = {
  key: 'INSERTPROVIDEDKEYHERE',
  source: {
    dash       : 'http://path/to/mpd/file.mpd',
    hls        : 'http://path/to/hls/playlist/file.m3u8',
    progressive: [{
      url: 'http://path/to/mp4',
      type: 'video/mp4'
    }, {
      url: 'http://path/to/webm',
      type: 'video/webm'
    }]
  }
};
player.setup(conf).then(function(value) {
  // Success
}, function(reason) {
  // Error!
});

Example of a player configuration and setup.
There is also the possibility of having separated manifests/playlists for each codec you want to work with. In this case you would need to handle the logic of choosing the best source on your side – which would not be too complicated and you could have custom business rules as well.

Conclusion

As we were able to see, addressing multi-codec streaming can be a very effective measure towards reducing costs on bandwidth while delivering the same quality of experience to your viewers. Here at Bitmovin we treat this subject seriously and are constantly improving and adding new features such as Per-Title Encoding, Per-Scene Adaptation, Stream Conditions and others.
It is also important to mention that one of the complexities of multi-codec streaming is the increase of computational resources necessary to encode the same content, which usually also leads to higher turn-around times. However, by leveraging on Bitmovin Containerized Video Encoding, where we split the input file into multiple small parts to encode in parallel, this is just a matter of adding more nodes to the cluster, problem solved.
We are looking forward to helping you reduce your CDN costs or deliver higher qualities to your viewers.

The post Efficient Multi-Codec Support for OTT Services: H.264/HEVC/VP9 and/or AV1? appeared first on Bitmovin.

VP9 is the next level in video compression and can help you to save up to 50% on your CDN costs, or significantly increase the quality of your streams.

We are happy to announce the introduction of full VP9 support for our HTML5 video player and our video encoder, both in the cloud as well as for containerized deployments that can run on-premise or in your own cloud account with Docker and Kubernetes. VP9 has recently gained popularity as there is still an uncertain royalty situation with HEVC which is the main competitor for VP9. Similar to HEVC, VP9 can perform up to 50% better, as a compression format, than H.264/AVC, especially for UHD or 4K resolutions. This results in higher quality video that can be delivered to the users, or help saving on bandwidth and thus reduce CDN costs by up to 50%!
VP9 is a royalty free codec that is developed by Google as an alternative to the commercial video formats. YouTube has been successfully using VP9 to deliver video content to their users for several years already and claims to deliver the same quality at half the bandwidth used by H.264/AVC. This is why YouTube prefers to stream VP9 on browsers/devices that have support for it, delivering better quality with less bandwidth. When streaming UHD and 4K content, VP9 is getting even more efficient. YouTube has chosen to deliver 4K resolutions only with VP9 and thus locking out Safari users to consume 4K content via YouTube.
This rise in popularity of VP9 is not only caused by the uncertain situation with the HEVC royalties, but also because of the ongoing development of AV1, a royalty-free video coding format developed by the Alliance for Open Media, which can basically be seen as a successor of VP9.
Looking at the range of supported browsers, VP9 is well ahead of HEVC. As of early 2017, VP9 is supported by roughly 75% of the browser market. This includes Google Chrome, Firefox, Opera, and also Microsoft Edge since summer 2016. On the other hand, HEVC is only supported in Microsoft Edge in cases where hardware decoding is available.
The Bitmovin encoder produces segmented VP9, which is perfectly suited for VoD streams as well as live streams. Furthermore our Live-to-VoD workflow fits perfectly with this format and allows you to generate VoD streams out of the live stream right after the stream has finished or even while the live stream is still running.

VoD Encoding for MPEG-DASH VP9

With the Bitmovin API you can create MPEG-DASH VP9 content for live as well as VoD use-cases. First we will demonstrate how to create an encoding job with MPEG-DASH VP9 output with our C# API Client. A full example can be found in our examples list in the GitHub repository.

Setup the Bitmovin API client with your API key

var bitmovin = new BitmovinApi(API_KEY);
Create an output configuration
We are using a Google Cloud Storage bucket as output location for the MPEG-DASH VP9 content. However, if you prefer you could also use an AWS S3, Azure Blob, Scality, FTP, SFTP, or any S3 compatible storage instead.
var output = bitmovin.Output.Gcs.Create(new GcsOutput
{
    Name = "GCS Ouput",
    AccessKey = GCS_ACCESS_KEY,
    SecretKey = GCS_SECRET_KEY,
    BucketName = GCS_BUCKET_NAME
});

Create an encoding and define the cloud region and version to be used
When you create an encoding you can choose the cloud region where the encoder should run. Ideally, the region matches the cloud region in which your bucket resides in so you save egress traffic. Besides the cloud region you can also pinpoint special encoder versions or use our STABLE branch that always points to the latest stable encoder version.
var encoding = bitmovin.Encoding.Encoding.Create(new Encoding.Encoding
{
    Name = "VP9 VoD Encoding C#",
    CloudRegion = EncodingCloudRegion.GOOGLE_EUROPE_WEST_1,
    EncoderVersion = "STABLE"
});

Create an input source
We need to create a source for your input file. If you have stored your input files on an HTTP server, you can just configure this server as source of your inputs with the code below. Please note that many other input sources such as AWS S3, Google Cloud Storage, Azure Blob, Aspera, (S)FTP, Scality and any S3 compatible storage is also supported.
var httpHost = bitmovin.Input.Http.Create(new HttpInput
{
    Name = "HTTP Input",
    Host = INPUT_HTTP_HOST
});

Create video codec configurations and add it to the encoding
A codec configuration contains the encoding related configuration for a video rendition or an audio rendition. You need to link the codec configuration to a stream of your encoding that connects an input stream with the codec configuration. For example, link your input video stream to a H.264 1080p codec configuration will encode this video stream to H.264 1080p output. The following example uses the AUTO selection mode and position “0”, thus links this configuration to the first video stream of the input file. Beside VP9 we also support H.264/AVC and H.265/HEVC as codecs, and resolutions of 8K and higher.
var videoConfig1080p = bitmovin.Codec.VP9.Create(new VP9VideoConfiguration
{
    Name = "VP9_Profile_1080p",
    Width = 1920,
    Height = 1080,
    Bitrate = 4800000,
    Rate = 30.0f
});
var videoStream1080p = bitmovin.Encoding.Encoding.Stream.Create(encoding.Id,
                CreateStream(httpHost, INPUT_HTTP_PATH, 0, videoConfig1080p, SelectionMode.VIDEO_RELATIVE));

Similar to the code above you can add more video codec configurations and then add them to streams of your encoding to generate alternative renditions (e.g., 720p, 360p, etc.). Additionally to the video rendition you may also want to add an audio track. For audio it works in the same way as for video, as you will see in the example below:
var audioConfig = bitmovin.Codec.Aac.Create(new AACAudioConfiguration
{
    Name = "AAC_Profile_128k",
    Bitrate = 128000,
    Rate = 48000
});
var audioStream = bitmovin.Encoding.Encoding.Stream.Create(encoding.Id,
                CreateStream(httpHost, INPUT_HTTP_PATH, 0, audioConfig, SelectionMode.AUDIO_RELATIVE));

Mux the encoded data for MPEG-DASH
In order to create MPEG-DASH, the VP9 encoded data needs to be packaged accordingly. In the following lines of code we will define segmented WebM for MPEG-DASH. Here you also define how long a single segment should be. Note that we also define where the segments should be stored in your output bucket. You have full control over the output location of the video and the audio streams. If you added multiple video renditions you also need to create a segmented WebM muxing for each rendition.

First we will create the required fMP4 muxings for MPEG-DASH:
var videoWebmMuxing1080p = bitmovin.Encoding.Encoding.SegmentedWebm.Create(encoding.Id,
    CreateSegmentedWebmMuxing(videoStream1080p, output, OUTPUT_PATH + "video/1080p", segmentLength));
var audioFMP4Muxing = bitmovin.Encoding.Encoding.Fmp4.Create(encoding.Id,
    CreateFMP4Muxing(audioStream, output, OUTPUT_PATH + "audio/128kbps", segmentLength));

Start the VP9 Encoding
Finally we can start the encoding job to encode your source asset to MPEG-DASH VP9.
bitmovin.Encoding.Encoding.Start(encoding.Id);

With the following code snippet you can wait for the encoding job to be finished:
var encodingTask = bitmovin.Encoding.Encoding.RetrieveStatus(encoding.Id);
while (encodingTask.Status != Status.ERROR && encodingTask.Status != Status.FINISHED)
{
    // Wait for the encoding to finish
    encodingTask = bitmovin.Encoding.Encoding.RetrieveStatus(encoding.Id);
    Thread.Sleep(2500);
}

Besides that you can also use webhooks to get notified as soon as the encoding job has finished.
Create the MPEG-DASH Manifest
After the encoding is finished we also need an MPEG-DASH manifest in order to be able to playback the content with MPEG-DASH players. With the Bitmovin API you have full control over creating manifests, e.g., create multiple manifests with a different set of qualities for targeting desktop or mobile, etc. When creating the MPEG-DASH manifest you also specify the output and the location and filename of the manifest:
var manifestOutput = new Encoding.Output
{
    OutputPath = OUTPUT_PATH,
    OutputId = output.Id,
    Acl = new List<Acl> {new Acl {Permission = Permission.PUBLIC_READ}}
};
var manifestDash = bitmovin.Manifest.Dash.Create(new Dash
{
	Name = "MPEG-DASH VP9 Manifest",
	ManifestName = "stream.mpd",
	Outputs = new List<Encoding.Output> { manifestOutput }
});

Define the default period and video and audio adaptation sets. In the audio adaptation set you can define the language of the audio track.
var period = bitmovin.Manifest.Dash.Period.Create(manifestDash.Id, new Period());
var videoAdaptationSet =
	bitmovin.Manifest.Dash.VideoAdaptationSet.Create(manifestDash.Id, period.Id, new VideoAdaptationSet());
var audioAdaptationSet = bitmovin.Manifest.Dash.AudioAdaptationSet.Create(manifestDash.Id, period.Id,
	new AudioAdaptationSet { Lang = "en" });

Add the created segmented WebM muxings to the adaptation sets. You also need to define the relative path to the segments based on the manifest output location:
bitmovin.Manifest.Dash.Webm.Create(manifestDash.Id, period.Id, videoAdaptationSet.Id,
    new Manifest.Webm
    {
        Type = SegmentScheme.TEMPLATE,
        EncodingId = encoding.Id,
        MuxingId = videoWebmMuxing1080p.Id,
        SegmentPath = "video/1080p"
    });
bitmovin.Manifest.Dash.Webm.Create(manifestDash.Id, period.Id, audioAdaptationSet.Id,
    new Manifest.Webm
    {
        Type = SegmentScheme.TEMPLATE,
        EncodingId = encoding.Id,
        MuxingId = audioWebmMuxing.Id,
        SegmentPath = "audio/128kbps"
    });

After that the manifest is configured completely, we can start the manifest creation:
bitmovin.Manifest.Dash.Start(manifestDash.Id);

Equally, as for the encoding job, we also need to wait for a successful manifest creation:
var status = bitmovin.Manifest.Dash.RetrieveStatus(manifestDash.Id);
while (status.Status == Status.RUNNING)
{
    status = bitmovin.Manifest.Dash.RetrieveStatus(manifestDash.Id);
    Thread.Sleep(2500);
}

Again, you can also use webhooks here to get notified as soon as the manifest creation is finished. After that, we have an MPEG-DASH manifest for the VP9 encoded content available and can test the playback in MPEG-DASH compatible players like the Bitmovin player, Shaka player, or Dash.js.
Live Encoding for MPEG-DASH VP9
Starting a live encoding for MPEG-DASH VP9 is not much different to starting a VoD encoding. We also have a full example available in our GitHub repository.

Obviously, the input will not be based on a file but rather be an RTMP source. The following shows how to grab the default RTMP input that is available in your account.
var rtmpInput = bitmovin.Input.Rtmp.RetrieveList(0, 100)[0];

When creating the streams in the different qualities, use the rtmpInput instead of the HTTP input from the example above.

The second difference is related to the manifest generation which must be done before the live encoder is started. Just create the MPEG-DASH manifest as in the example above, and pass it in the start encoding call:
bitmovin.Encoding.Encoding.StartLive(encoding.Id, new StartLiveEncodingRequest
{
    StreamKey = "YourStreamKey",
    DashManifests = new List<LiveDashManifest>
    {
        new LiveDashManifest
        {
            ManifestId = manifestDash.Id,
            Timeshift = 300,
            LiveEdgeOffset = 180
        }
    }
});

That is the whole difference when starting a live encoding compared to a VoD encoding.
Playback of MPEG-DASH VP9 Content
There is no difference between the playback of VP9 encoded MPEG-DASH streams and H.264 encoded MPEG-DASH streams. In both cases you set the MPEG-DASH manifest as the source for your player and there is no need to define the type of codec that is used. Below you can see an example of our player with VP9 encoded content through our Bitmovin API.
VP9 playback is not supported by your browser, falling back to H.264 playback.





Video technology guides and articles

Back to Basics: Guide to the HTML5 Video Tag 
What is a VoD Platform?A comprehensive guide to Video on Demand (VOD)
Video Technology [2022]: Top 5 video technology trends
HEVC vs VP9: Modern codecs comparison
What is the AV1 Codec?
Video Compression: Encoding Definition and Adaptive Bitrate
What is adaptive bitrate streaming
MP4 vs MKV: Battle of the Video Formats
AVOD vs SVOD; the “fall” of SVOD and Rise of AVOD & TVOD (Video Tech Trends)
MPEG-DASH (Dynamic Adaptive Streaming over HTTP)
Container Formats: The 4 most common container formats and why they matter to you.
Quality of Experience (QoE) in Video Technology [2022 Guide]



The post VP9 Codec: MPEG-DASH VP9 for VoD and Live appeared first on Bitmovin.
]]>