Customer Issue Prompts New Encoding and Compression Format for CloudX

A customer was having issues creating a time lapse without getting significant glitches across various portions of the image and recently reached out to us for help.

It was an exciting issue to investigate, as we create hundreds of time lapses per month and had never run into such an issue. This customer also had several cameras active, only affecting one particular view.

It wasn’t restricted to specific colors or regions, affecting both areas in the sky and the ground.

We didn’t yet understand why the compression algorithm was getting too aggressive in these areas, dramatically reducing the quality and resulting in visible artifacts.

Sky patch

Ground patch

We jumped down the rabbit hole of media encoding and video compression. We had been there before when we built CloudX, but it was time to revisit.

Our default encoding was h.264 using the mp4 video container format. It is a relatively old format in some ways. Still, it remains one of the de facto standards on the web with excellent compatibility across browsers and playback devices using HTML5 video and, of course, video editing software.

We had played around with the newer h.265 encoding, which is twice as efficient as h.264 in terms of file sizes, but compatibility is not great due to the myriad of licensing issues with h.265 and associated device compatibility. It is also much more processor-intensive in encoding the video and the playback. Many laptops struggle to playback full 4K H265 encoded videos depending on the quality. This is one of the reasons GoPro provides two choices in their video encoding (both h.264 and h.265).

VP8 encoding is another video compression scheme, originally created by On2 Technologies and purchased by Google in 2010. Google subsequently made the format essentially free for everyone to use to solve the issue that licensing arguments like with h.265 presented. It utilizes the WebM container format and is generally supported natively in HTML5.

We were aware of VP8/WebM but had never had cause to pursue it due to h.264/mp4 generally working well. On further investigation, we found that VP8 is pretty aggressive in its compression resulting in some very small but poor-quality files. Not bad for a web format, but not great for a customer trying to build a high-quality time lapse. After many iterations and testing, we came up with the correct settings to balance quality, file size, and encoding speed.

There are two successors to VP8, being VP9 and AV1 encoding. The compatibility of VP9 is still not excellent on iOS right now (e.g., it works on iOS for iPad but not iPhone), plus VP9 and AV1 also take a long time to encode, requiring a high level of server resource. So until compatibility improves, we have parked VP9 and AV1 encoding.

So, where does this leave us?

We have decided to provide our customers with the choice of h.264/mp4 and vp8/WebM formats via a new dropdown menu when building their time lapse in the CloudX dashboard. We will also run some trials by making available the h.265/mp4 format as a beta. The h.265/mp4 format won’t play in the CloudX player due to the browser issues mentioned above, but the thumbnail will display, and you can download the file and import it into your video editing software of choice. If you choose this path, we are keen to hear your feedback!