That changed when Apple launched the Apple Vision Pro, announcing that unlike Meta Quest and other headsets, their new device would take advantage of MV-HEVC for immersive video experiences. In this blog post, we’ll explore what MV-HEVC is, its potential for enhancing streaming experiences and how to get started. 

What is MV-HEVC?

MV-HEVC stands for Multiview High Efficiency Video Coding, an extension of HEVC that was added to the second edition of the standard in 2014. It’s designed to support the efficient encoding of multiview video content captured from multiple viewpoints, often to create stereoscopic (3D) effects or spatial video experiences for virtual reality (VR) and augmented reality (AR). 

Doubling the encoding and bandwidth requirements for multiple viewpoints could potentially create buffering and playback issues, but MV-HEVC enables the efficient compression and storage of stereoscopic content, reducing the bandwidth required for streaming or the file size needed for storage without compromising the video’s quality.

In short, MV-HEVC allows the encoding of multiple views of the same scene in a way that preserves video quality while keeping the bitrates manageable. This makes it a good fit for 3D, AR and VR applications that require a lot of real-time data processing. 

How MV-HEVC works

Before getting into how MV-HEVC works, let’s take a quick step back to the basics of video encoding. Temporal compression is a technique for reducing file size that is common to all major video codecs. Unless there is a scene change, individual frames of video are usually not that different from one frame to the next. Temporal compression exploits that fact and reuses data where it can, saving some bits from being encoded and shrinking the file size. 

This is done by encoding different types of frames that require less data to reconstruct for playback. I-frames are fully encoded frames that serve as anchor points, while P-frames (Predictive frames) can reuse data from frames that came before them. B-frames (Bi-direcional predictive frames) can reuse data from frames both before and after them. If you’re interested in learning more about some of the fundamentals of video encoding, check out this guide. 

I touched on all of that because a key benefit of MV-HEVC is that it is also able to take advantage of the commonalities across multiple camera angles or views. In the cases of immersive and 3D videos that are created with different views for the right and left eye, the similar viewpoints usually mean there’s a lot of potential for compression, creating smaller, more manageable files for streaming and storage.

Applications of MV-HEVC

Stereoscopic Video (3D Video)

MV-HEVC is particularly useful in the realm of 3D video or stereoscopic content, where two slightly different views (one for each eye) create the stereoscopic effect. By encoding both the left eye and right eye views efficiently in a single stream, MV-HEVC reduces the file size and bitrate compared to other methods. This is crucial for streaming applications like 3D movies or immersive VR experiences where quality and efficiency are key. Other codecs can be used for 3D stereoscopic video as we cover in this blog, but MV-HEVC is more efficient. 

Spatial Video

Another application of MV-HEVC is in spatial video, which is typically used for virtual reality (VR) or augmented reality (AR) content. The Apple Vision Pro is built around the idea of capturing and presenting spatial video, allowing users to immerse themselves in a three-dimensional representation of a scene, combining video and depth information. MV-HEVC support is essential for these types of experiences, reducing massive bitrates of the raw files into something manageable for streaming and real-time immersive experiences. 

Multiview Video

MV-HEVC is also important for multiview video, where multiple views of the same scene are captured from different angles. This could be used in sports broadcasts, where different camera angles are encoded into a single video stream, or for applications that allow users to choose their viewing angle interactively. Depending on your exact use case, this may require multiple decoders or extra processing power that might not be available on all platforms. 

Dolby Vision with MV-HEVC

MV-HEVC is now also compatible with Dolby Vision, a popular High Dynamic Range (HDR) video format that helps ensure content looks as realistic and as true to the creator’s vision as possible. Most of the top-tier premium streaming content these days is being made available in Dolby Vision format, so it makes sense that companies investing in MV-HEVC production pipelines would want to take advantage of Dolby Vision. Dolby Vision Profile 20 extends the potential quality enhancements of Dolby Vision to MV-HEVC and immersive content. 

Apple Vision Pro and beyond

The Apple Vision Pro is pushing the boundaries of immersive media and while they didn’t create the VR headset segment, Apple definitely put their stamp on it. There are several examples over the years of Apple’s influence on the media technology industry, from their decision to not support Flash video to their decision to (finally) support AV1. 

It seems only likely there will be a halo effect for MV-HEVC around the Vision Pro. One early example is the Blackmagic URSA Cine Immersive camera. I expect in 2025 we’ll see more companies venturing into MV-HEVC support from capture to post-production to distribution. 

MV-HEVC video tools

Direct recording with Apple Vision Pro and iPhone

You can record spatial video using MV-HEVC directly on the Apple Vision Pro, iPhone 15 Pro and all iPhone 16 models. The distance between the 2 camera lenses on the Vision Pro seems to provide better results with more depth compared to spatial videos captured on iPhone.

Apple AVFoundation support

Apple also added support to their AVFoundation APIs for converting side-by-side 3D videos into MV-HEVC and spatial videos. You can find more information in their developer documentation here.

Bitmovin VOD encoding beta

Bitmovin’s VOD Encoding now supports MV-HEVC as part of a private beta. If you’re interested in adding MV-HEVC to your transcoding workflows, we’d love to discuss the details with you. You can reply in the Bitmovin Community, comment on this post or get in touch with your Bitmovin contact for more info. 

Conclusion

Thanks in large part to Apple, MV-HEVC is poised to become a key technology in the future of immersive and multiview content. Its ability to efficiently encode multiple views of the same scene, reduce the data required, and maintain high video quality makes it an essential tool for everything from stereoscopic 3D movies to virtual reality experiences on devices like the Apple Vision Pro.

On their other platforms, Apple seems to have signalled a shift toward using the AV1 codec, but AV1 does not currently have multiview support. It will be interesting to see how that situation evolves both within Apple’s products and the wider video ecosystem. While the only certainty is that things will change, unless Apple abandons the Vision Pro, MV-HEVC is likely to be part of the picture for the foreseeable future.

The post Multiview HEVC (MV-HEVC): Powering spatial video experiences and more appeared first on Bitmovin.

Table of Contents

Introduction

The post will explain how Per-Title Encoding works and the advantages of using Per-Title Encoding compared to using the same bitrate ladder for all your content. Per-Title often requires fewer ABR ladder renditions and lower bitrates that translate into storage, egress and CDN cost savings. It also improves QoE with less buffering and quality drops for viewers, along with better visual quality. On top of that, it can make 4K streaming viable, turning it from a loss leader and financial burden into a revenue generator. Keep reading to learn more. 

Per-Title Encoding is key for cutting streaming costs

For the past couple of years, “controlling costs” has been among the top challenges for video streaming, according to the results of Bitmovin’s annual video developer survey. While the pandemic years created a boom for streaming services and content creation, things have now shifted toward cost-cutting in a few different ways. Several platforms have cut back their budgets for original content and are removing shows and films from their libraries to save on licensing and other operational costs. 

Another trend highlighted by industry analyst Dan Rayburn, has been the lowering of bitrates, including removal of 4K streaming in some cases. Services that do still offer 4K often restrict it to their highest-priced subscription tier. Back in 2014, Dan called out the cost and QoS challenges services would face when delivering 4K video, and many are still struggling with that reality, especially those using a fixed bitrate ladder for their encoding. 

Per-Title Encoding can have a huge impact on 4K content, something that can be seen in the recommended internet connection speeds for 4K streaming:

Netflix: 15 Mbps (they use their own version of per-title encoding)

Disney+: 25 Mbps

Paramount+: 25 Mbps

Max: 50+ Mbps 

For long form content that gets even in the tens of thousands views, the difference between 15 Mbps and 25 or 50 Mbps will add up quickly in the form of excess network egress and CDN costs. With non-optimized encoding at those high bitrates, a viral hit that ends up getting hundreds of thousands or millions of views can end up being a financial burden. Using Per-Title Encoding ensures each video uses only the bits needed for its content and complexity and when combined with more advanced codecs like HEVC and AV1, it can make a game-changing difference. When Bitmovin added support for using Per-Title Encoding with the AV1 codec, I was shocked to see just how low the bitrate could go (often under 2 Mbps). 

How does Per-Title Encoding work?

In 2012, Bitmovin’s co-founders published a research paper titled “Dynamic Adaptive Streaming over HTTP Dataset” that, among other things, provided data for per-genre encoding that would further evolve into Bitmovin’s Per-Title Encoding. Per-Title Encoding is an optimization of adaptive bitrate encoding that analyzes the complexity of a video file and determines the encoding settings needed to maintain the highest level of visual quality together with the most efficient adaptive bitrate ladder. 

In 2015, Netflix published a tech blog that detailed their research and development of their own per-title encoding. Through brute force encoding of content at different resolutions and quality levels, they found that the ideal adaptive bitrate ladder for each video would form a smooth convex hull when plotting quality vs bitrate. When the bitrate and resolution pairs in their ABR ladder fell along the convex hull, it maximized quality for the viewer and meant that data was being distributed efficiently. Bitmovin’s Per-Title complexity analysis spares you the excessive testing and experimentation and automatically determines the ideal ABR ladder and convex hull for each file. 

Per-Title Encoding ABR ladder vs fixed bitrate ladder

The graph below shows how Per-Title Encoding provides better QoE with lower bitrates than the competition’s static bitrate ladder for a 4K source. Per-Title Encoding matches the source at 3840x2160p, with a bitrate of 6050 kbps and a VMAF score of 95.5. The static ladder is capped at 1080p and requires 7830 kbps for a lower VMAF score of 90.9. That’s 22.7% bitrate savings with better quality by using Per-Title.

The next example uses the HEVC codec for the customer’s UHD ladder vs Bitmovin Per-Title Encoding. The highest rendition on the Per-Title ladder only needs 1.9 Mbps to hit a VMAF score of 94.9, while the static ladder uses 15 Mbps, an increase of 13.1 Mbps in bandwidth for an undetectable VMAF difference. This equates to 87% savings on the CDN bill for viewers of the top rendition, without sacrificing quality. 

With a duration of 44:39, the top rendition for Per-Title would mean 0.622 GB in data transfer while the top rendition for the fixed ladder would require 5.023 GB. For popular content tens of thousands of views (or more) those savings add up quickly. At a time when some services are removing 4K renditions, these optimizations make it feasible to provide UHD and improve margins on premium subscription tiers. 

Next we have some medium-complexity 1080p content where using Bitmovin Per-Title with a more advanced codec like HEVC can make a huge difference. Throughout the ladder, using Bitmovin Per-Title with H.264 provides some quality gains and bitrate savings compared to the customer’s static ladder with ffmpeg, but the results from Per-Title with HEVC highlight the impact of using a newer generation codec. HEVC delivers 1080p in the 90+ VMAF range with only 2 Mbps while ffmpeg with H.264 needs over 6.5 Mbps for the same quality. That’s around 70% bandwidth savings for viewers of the top rendition. At the lower end of the spectrum, a viewer with 1 Mbps available bandwidth would be limited to 432p with the static H.264 ladder, but would still receive 1080p with Per-Title HEVC.

Storage savings with Per-Title Encoding

Bitmovin’s Per-Title Encoding can deliver massive storage savings when compared to fixed bitrate ladders, by removing unnecessary renditions from the ABR ladder and ensuring the most efficient bitrate is used for each piece of content. The chart below shows the potential savings on your storage bill from using Per-Title Encoding over a fixed ladder with AVC encoding. 

Improve quality without increasing bitrates 

Per-Title Encoding can also improve quality without needing to use additional data. The chart below references our customer’s fixed ABR ladder using the AVC codec and shows the quality improvements (% VMAF score) that Bitmovin’s Per-Title provided with different codecs at the same bitrate. 

Bitmovin Smart Chunking prevents lower quality outlier frames

The graphs below plot the VMAF quality scores of every frame in our customer’s sample content. Bitmovin’s smart chunking virtually eliminates all of the lower quality outlier frames that are present in our competitor’s encoding and would be noticeable by viewers. Smart Chunking is now active for all Bitmovin VOD Encoding without any additional configuration or cost to the user.

Conclusion

In the past, balancing cost and quality has always been a tradeoff, but using Per-Title Encoding may be the single most effective way for streaming services to reduce their total cost of ownership without sacrificing their viewers’ quality of experience. With consumers having an abundance of options, the QoE improvements Per-Title provides can mean the difference between renewal and churn and its cost savings can tip the scales toward profitability. With streaming firmly in a cost conscious era, using Per-Title Encoding makes more sense than ever before.   

Ready to see what difference Per-Title Encoding can make with your content? Anyone can test it out for free with no coding required using our VOD encoding wizard. We also have a comparison tool in our dashboard where you can input your own content or use common test videos. Try it out today!

Related Links

Choosing the Best Per-Title Encoding Technology

What is Per-Title Encoding and how does it work 

How to Create a Per-Title Encoding

Advanced Per-Title configuration 

The post Game-Changing Savings with Per-Title Encoding appeared first on Bitmovin.

Quietly, without any announcement or updates on support pages, Google fixed a bug in Chrome with a significant implication for the video streaming industry: Support for adaptive streaming of HEVC/H.265 video content has finally been enabled! 

Thanks to Bitmovin (Humble Brag, just kidding), we submitted a bug report about 6 years ago about this very thing. After a “small” bit of waiting, we got the answer that It’s now officially supported for Chrome 104, and with a little investigation also found out that it’s enabled by default for Chrome 105 for all platforms, ready to be used in the wild. 

Why does support for HEVC matter?

High-Efficiency Video Coding (HEVC) provides better compression for files than the ubiquitous AVC/H.264, meaning you will be able to stream the same quality with lower bandwidth and big savings on CDN costs with the added bonus of improving the user experience. 

While HEVC is commonly used for serving content to Smart TVs, set-top boxes, and devices like Roku and Fire TV, its usage on mobile and desktop browsers was limited to just Safari for a long time (after Microsoft changed the Edge browser to being Chromium-based). With Safari’s market share still below 19% globally, the vast majority of users had no choice but to use another codec. However, with this latest change from Google, Chrome’s market share of more than 65% can be “theoretically” added to the HEVC-capable browsers, making it available to 84% of browser users. 

I say “theoretically”, as there’s often a caveat: HEVC is only supported if the underlying device has an HEVC hardware decoder. 

Today’s modern devices should already have that as standard, but reliable global data on this point are scarce. If you are curious to see if your device can play HEVC-encoded DASH and HLS streams, open our stream test page with an HEVC-encoded DASH and HLS URL, or you can use this example URL.

Does is also work with DRM?

That’s where the catch is, unfortunately. The biggest drawback is that HEVC with Widevine DRM is not supported at this point, only clear, unprotected content. It’s unclear whether Google has plans to add support for this in the future or not.

Great feature, but where is the necessary hype!?

While this sounds like a feature Google should be boasting about to the moon over their comms channels, they haven’t really updated their documentation. In fact, Chromium’s Audio/Video codec & container support page was not updated as of the writing of this article, and the popular caniuse.com still lists HEVC as unsupported.

Android already supported HEVC, but Chrome on Android only supported HEVC with progressive files, not via the Media Source Extension (MSE) API, which is used for adaptive streaming like DASH or HLS. After little movement for years from Google, the bug finally got picked up earlier this year and fixed. So despite the original scope being just Android, it was a very positive surprise to see HEVC support enabled and rolled out on all Chrome platforms. Now, we just need to see DRM supported along with it!

The post Google Quietly Added HEVC Support in Chrome appeared first on Bitmovin.

Versatile Video Coding (h.266/VVC) is the newest block-based hybrid codec from the Joint Video Experts Team (JVET), a group comprised of MPEG and ISO/ITU members such as Bitmovin and Fraunhofer HHI, and promises to vastly improve the compression capabilities of workflows for any organization within the streaming industry, including but not limited to, OTT, VR, AR, and many other providers. As fellow members of MPEG, the Bitmovin encoding team was eager to test the capabilities of the newest codec and the potential improvements it offered over its predecessor h.265/HEVC. The ultimate goal of the project was to determine the performance parameters of the VVC codec and the subjective visual quality enhancements that ensue. While Fraunhofer HHI claimed that the VVC codec promises to improve visual quality and reduce bitrate expenditure by around 50% over HEVC, we wanted to prove the validity of the statement.

“Overall, H.266/VVC provides efficient transmission and storage of all video resolutions from SD to HD up to 4K and 8K, while supporting high dynamic range video and omnidirectional 360° video.” – Fraunhofer HHI

The end goal of our research was to implement the VVC distribution process into Bitmovin’s standard encoding process, as illustrated below:

Developing a VVC Encoding Process

To kick-off our experiment, we added the VVC Test Model (VTM) encoder library into our encoder with a flexible interface. However, some critical changes were needed in the Bitmovin API to enable VVC encoding. 

Implementing the VVC codec

The first step to enable VVC encoding is to add VVC as a new video codec to our API. Since we haven’t established a “real” encoder yet, there are limited settings, parameters, and inputs that we can use. For the first set of tests we used the following: width, height, bitrate, pixelFormat, rate, and Constant Rate Factor (CRF); as seen below:

There are additional input values necessary for a real VVC encoding but didn’t apply for our test. These are colorConfig, sampleAspectRatio, encodingMode, preset, and profile. Any other specialized settings will depend on the encoder implementation that we use when live. At the time of our test, VVenC and other encoder implementations, like x266 were not yet available and thus the settings are unknown. Now that the VVC codec parameters have been established we needed to actually implement them into the Bitmovin encoder.

Testing VVC in Bitmovin’s Encoder

Thanks to our flexible interface, Lead Encoding Engineer, Christian Feldmann, had already added the library interface to the open-sourced reference encoder (VTM) and also added a patch to our internal encoder, which pushes frames to the VTM encoder and retrieves any data from it. Then, we implemented a new Bitmovin encoder Dependency that contains VTM with h.266 support.

Lastly, we created a VideoService integration test that would prove that the VTM integration works. However, as expected of a brand new codec implementation – most of the initial tests failed.

Trial, error, and repeat: VVC encoding initial failures

Although expected, we were disappointed to find that running multiple renditions using the h.266 codec doesn’t work as the VTM implementation uses global variables. Thus we were not able to launch multiple encoding tasks on the same “machine” (respectively within the same docker container). Another issue that we encountered is that only the 1080p output format worked as a result of the encode. While promising, the VVC codec and encoding are intended to work for nearly any output format, and a single output is clearly not the intended result. To resolve these issues we implemented a few minor patches within our API.

Resolving the VVC encoding failures

Fortunately for our experiment, a simple patch to the encoder, as well as the implementation of the libVTM worked almost out-of-the-box. The remaining issues were two minor bugs that required the connection of the CRF value of our API to the baseQP value in libVTM. 
Now that the encoding issues were resolved, we were able to run the first objective visual quality evaluations using the Peak Signal-to-Noise Ratio (PSNR). As a baseline, we ran four different CRF values at 1080p resolution to calculate BD-rate curves in comparison to h.265/HEVC. The result was h266 and h265 output files with the same four CRFs that allowed the first quality comparison.

How did VVC stack up?

Once our initial implementation tests were complete, we set up a complete end-to-end encoding test with a single asset, Mango’s open-source project Tears of Steel. 

Side by side comparison video of encoded asset VVC vs HEVC
Given the limitations of the encoder implementations, VVC’s performance was as promised (and expected), offering ~45% percent lower bitrate compared to HEVC. As visualized in the graph below, our results are nearly identical to that of the official measurements provided by JVET.
Although there are significant visual quality improvements and at lower bitrate expenditure, the current encoding results came at an immense computing and time cost. In our initial tests, the encoding time for a 4-second video ranged between 2.5-6.4 hrs (varied based on output parameters).

What does this mean moving forward?

Our initial tests of the VVC codec were run with the bare bones VTM encoder implementation without any adjustments, optimizations, or improvements. As the industry continues to develop the back-end tech to support h.266/VVC, we can expect that encoding times and computing power will decrease significantly in the very near future. Since the Bitmovin encoding team ran this first test, our academic and research arms ran additional tests at both the Alpen Adria University in Klagenfurt, as well as at the 132nd MPEG meeting. The next set of verification tests extended VVC’s capabilities to successfully encode ultra-high definition (UHD) content with standard dynamic range so that it can be used in newer streaming and broadcast television applications. The latest tests were run using the recently released open-source encoder implementation of VVC (VVenC), which displayed an additional 10% bitrate savings over the original VTM implementation. The Bitmovin encoding team plans to continue testing the VVC codec and adding new encoder implementations into our workflows – with expectations of officially launching VVC support sometime in the near future.

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 State of Compression: Testing h.266/VVC vs h.265/HEVC 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.

This year Apple announced at their WWDC conference support for HEVC/H.265 with HLS for macOS High Sierra and iOS11

Every year at Apple’s annual Worldwide Developer Conference (WWDC) they present updates and new features that will be available to their products soon. This year Apple announced support for HEVC/H.265 for macOS High Sierra and iOS 11. According to Netflix’s experiments HEVC/H.265 can reach up to 50% bitrate savings compared to AVC/H.264 which allows to stream better quality to customers and saves storage and bandwidth costs for content providers.
We at Bitmovin are of course always especially interested in the video related updates from Apple. Last year we were a first mover to support fMP4 in HLS after Apple announced it at WWDC16. This year we are even in a position where we already support HEVC/H.265 end-to-end in both our products encoding and player.

Multi Codec Support with Bitmovin’s API

With the Bitmovin API you can encode content with different codecs like AVC/H.264, HEVC/H.265, VP9, and recently also AV1 using MPEG-DASH and HLS. This allows to use the best codec for the platform when streaming content to your users. HEVC/H.265 and VP9 are more efficient than AVC/H.264 allowing to deliver higher quality with the same bitrate, or save costs by delivering similar quality to less bandwidth. VP9 is supported on Google Chrome, Firefox and Android devices which allows you to stream VP9 to about 70% of your users. For Safari there was still the need to use AVC/H.264 until now. With the announcement of Apple we will soon see HEVC/H.265 to be streamed to macOS and iOS devices.
With our flexible Bitmovin API generating content encoded in HEVC/H.265 and mux it to fMP4 segments works out-of-the-box as we do that today for HEVC MPEG-DASH content. The trick to make it available as an HLS asset is just to reference the the segments in the playlist files in the same way we do it today with fMP4 in HLS.

Bitmovin HTML5 and Native Players Already Support HLS with HEVC

Apple supports now HEVC video in fMP4 segments in HLS. While this works on iOS 11 and macOS High Sierra only, the reached audience can be extended using the Bitmovin Player. It supports HEVC HLS in all browsers which support HEVC decoding already out of the box. Also the Bitmovin Player iOS SDK is ready for HEVC HLS on iOS 11.

Test Vectors

There are a few ways to deliver HEVC content to users:

1. HEVC in HLS using MPEG-2 Transport Stream chunks, which Apple doesn’t support
2. HEVC in HLS using fMP4 segments, which is what Apple announced on WWDC17 and our player supports
3. HEVC in MPEG-DASH using fMP4 segments

All of these options can already be created using our Bitmovin API. For playback, it depends on the HEVC support in the browser. Obviously, Apple added this for Safari on macOS High Sierra and iOS 11, but also Edge on Windows 10 already supports it. HEVC can be streamed using HLS or MPEG-DASH to Edge with the Bitmovin Player.
We provide test vectors for the three above mentioned types for public testing:

• HEVC HLS with fMP4: http://bitmovin-a.akamaihd.net/content/dataset/multi-codec/hevc/stream_fmp4.m3u8
• HEVC HLS with TS (not supported by Apple): http://bitmovin-a.akamaihd.net/content/dataset/multi-codec/hevc/stream_ts.m3u8
• HEVC MPEG-DASH: http://bitmovin-a.akamaihd.net/content/dataset/multi-codec/hevc/stream.mpd

Beside HEVC/H.265 we can also encode the same asset to AVC/H.264 and VP9 which we introduced earlier this year. With this configuration you can deliver the best codec to every device, improving quality and save costs. VP9 is supported on multiple platforms including Google Chrome, Firefox and Android devices. Google Chrome currently has a market share of 57% in North America and Firefox accounts for roughly 12% in that region. Taking these two alone you could probably reach up to 70% of your users with VP9. So basically 70% of your users could benefit from VP9 which could reduce your bitrate by 50% and lower your CDN costs dramatically.
Here are some more test vectors including the VP9 codec:

• Multi-Codec MPEG-DASH (AVC/H.264, HEVC/H.265, VP9): http://bitmovin-a.akamaihd.net/content/dataset/multi-codec/stream.mpd
• VP9 MPEG-DASH: http://bitmovin-a.akamaihd.net/content/dataset/multi-codec/stream_vp9.mpd

We wish you happy testing and would love to get your feedback!

Popular 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 WWDC17 – HEVC with HLS – Apple just announced a feature that we support out of the box appeared first on Bitmovin.

High Efficiency Video Coding (HEVC) or H.265 is a compression standard that doubles the compression efficiency while maintaining similar or same video quality compared to its predecessor H.264/AVC

High Efficiency Video Coding (HEVC) or H.265 is a compression standard that was jointly developed by ISO/IEC MPEG SC29/WG11 and the ITU-T Video Coding Experts Group (VCEG). The standard was officially ratified by MPEG on the 13th of April 2013. As for every new video codec the goal of HEVC was to double the compression while maintaining similar or same video quality compared to its predecessor H.264/AVC. HEVC has been designed to take advantage of very high resolutions such as 4K and 8K which usually contain very wide areas of similar blocks. Therefore, one of the first things that was changed was the block size on which the codec operates. H.264/AVC was using 16 by 16 blocks at a maximum and these blocks were replaced by Coding Tree Units (CTU) that can take up to a maximum of 64 by 64 sizes. This allows utilization of big homogenous areas as very big blocks can be used that enable higher efficiency. HEVC also only allows Context Adaptive Binary Arithmetic Coding (CABAC) as entropy encoder as it is the most efficient one and decoding performance considerations are less important now as every smartphone has already two or more cores and built-in decoding chipsets.

There are several other small improvements that lead to the encoding efficiency gain, and the performance of the HEVC implementations will definitely increase over the next few years. Additionally, MPEG added the support for HEVC in several container formats such as MPEG 2 Transport Stream (MP2TS) and ISO Base Media File Format (IBMFF) that is used as the basis for MP4. As MPEG DASH is container and codec agnostic, HEVC is supported anyway, but with the support in the MP4 container format it’s even easier to integrate HEVC seamlessly into your workflow.

MPEG DASH HEVC Encoding with Bitmovin’s API

MPEG DASH HEVC encoding with Bitmovin is very simple and is supported through our REST-API and with our API Clients such as PHP and Python. Basically there is just one parameter in the Encoding Profile that needs to be changed. Specifically the codec attribute in the Encoding Profile needs to be changed to hevc. This attribute is optional, which means if you don’t specify it, we will use h264 as codec. Currently MPEG DASH HEVC is supported within all plans and for all of our users.

Python API Client MPEG DASH HEVC

A simple Python example of an MPEG DASH HEVC encoding can be found at our python github example.

1. Follow the instructions on github to setup bitcodin-python.
2. Make sure to set the correct API key:

   bitcodin.api_key = 'INSERT YOUR API KEY'

3. Create an MPEG DASH HEVC encoding profile

   video_configs = list()
   video_configs.append(bitcodin.VideoStreamConfig(
       default_stream_id=0,
       bitrate=1024000,
       profile='Main',
       preset='standard',
       height=768,
       width=1024,
       codec='hevc'
   ))
   audio_configs = [bitcodin.AudioStreamConfig(default_stream_id=0,
                                               bitrate=192000)]
   encoding_profile_obj = bitcodin.EncodingProfile('HEVC Encoding Profile',
                                                    video_configs,
                                                    audio_configs)
   encoding_profile = bitcodin.create_encoding_profile(encoding_profile_obj)
   

4. Create and start MPEG DASH HEVC encoding

   manifests = ['mpd']
   job = bitcodin.Job(
       input_id=input_result.input_id,
       encoding_profile_id=encoding_profile.encoding_profile_id,
       manifest_types=manifests
   )
   job_result = bitcodin.create_job(job)
   

Playback with the Bitmovin Player

The Bitmovin Adaptive Streaming Player utilizes the browser build-in HTML5 Media Source Extensions (MSE) to playback HEVC native through the browser decoding engine. If the underlying browser supports HEVC, the Bitmovin Player supports it too. Currently this works on Microsoft Edge and Android native Apps based on ExoPlayer with devices that support HEVC but with MPEG-DASH you can use H.264/AVC in parallel with H.265/HEVC and only devices that are capable of playing HEVC will use the HEVC Representations.

Conclusion

HEVC is probably the most efficient codec on the market and it’s worth trying it out. The integration with MPEG-DASH is seamless and the Bitmovin API allows you to setup an HEVC encoding workflow in just a few minutes. If you want to try our MPEG-DASH HEVC encoding and playback with your content, you can use our free plan with 2.5GB encoding output per month. That’s great for testing and playing around with our HEVC encoder.
See an MPEG-DASH example using HEVC. Scroll down to the Telecom ParisTech, GPAC: UHD HEVC DASH Dataset

The post MPEG-DASH HEVC Encoding appeared first on Bitmovin.