Streaming Learning Center Where Streaming Professionals Learn to Excel
Related Articles
Let’s save us both a lot of time. If you’re looking for the cheapest cloud encoding service for low-volume production quantities, skip to the next article; Elemental Cloud isn’t for you. On the other hand, if you’re a high-volume producer seeking the ability to acquire secure, dedicated cloud resources capable of fast, high-quality encoding, read on. Ditto if you’re an existing Elemental hardware customer seeking to send overflow jobs to the cloud, or if you’re just interested in learning the differences between platform as a service (PaaS) and software as a service (SaaS), which is the operating schema used by the bulk of cloud providers.
Still here? Okay, great. As you suspected by now, this is a review of Elemental Cloud. By design, Elemental Cloud uses the same interface and application as Elemental’s appliance-based encoders. I reviewed the Elemental Server appliance previously, and everything I wrote about the interface applies equally to Elemental Cloud. If you’re encoding with Elemental hardware, you can deploy the same presets and control the consolidated operation of the appliance and cloud from the same interface and/or API, which is an advantage no other cloud offering can match.
In this review, I’ll focus on the cloud-specific workflows and operation, as well as performance and quality comparisons with other cloud suppliers. I’ll discuss how pricing compares among the various suppliers, but Elemental doesn’t publish its pricing so I can’t share any hard numbers. Let’s start with a brief look at features.
Contents
Elemental Cloud Features
The Elemental encoders started life as high-volume H.264 encoding engines, and support for legacy formats such as VP6 was limited. While VP6 and H.263 were never available, Elemental Cloud can output Apple ProRes, HEVC/H.265, MPEG-2 and VC-1, along with AAC, AC3, DTS Express, Dolby Digital Plus, WMA2, and uncompressed WAV and AIFF audio files.
Available output container formats include 3GPP, MP4, F4V, MPEG-TS, MOV, CableLabs Compliant Option (MPEG-TS), Ultraviolet (CFF, UVU), and Microsoft Windows Media (WMV/ASF). For adaptive streaming, Elemental supports Adobe’s HTTP Dynamic Streaming (HDS), Apple’s HTTP Live Streaming (HLS), MPEG-DASH (MP4, ISO, TS) and Microsoft’s Smooth Streaming (ISMV).
Other features are extensive, including support for closed captions, advertising insertion, splicing, multiple audio tracks, multiple encryption, and digital rights management (DRM) technologies, as well as regulatory requirements such as the Commercial Advertisement Loudness Mitigation Act (CALM Act). As always with these types of features, the devil is in the details, so if you have particular captioning or rights management requirements, get them on the table first.
As an appliance vendor who transitioned to the cloud, Elemental offers far and away the best user interface (UI) for its encoding engine, along with a comprehensive and mature application programming interface (API). Zencoder doesn’t really offer an API, while Encoding.com’s UI is missing critical elements such as preset management. While most high-volume users obviously use the API, you’ll appreciate Elemental’s UI when you’re just starting out or if you’re just testing the service.
With this as background, let’s jump into web operation and the difference between PaaS and SaaS.
What You Buy
When you use a SaaS cloud vendor such as Zencoder or Encoding.com, you upload your files into an encoding engine that’s shared by all users. You don’t reserve any dedicated resources for your files, and you can’t control the algorithms used by either service to add resources when queue times start to grow. Don’t get me wrong, both services are mature and have large clients with mission-critical encoding chores who would have switched suppliers long ago if encoding times got excessive. The shared operation is simply the nature of the beast.
In contrast, with Elemental Cloud, you purchase a set number of hours of CPU-based or GPU-based encoding and a maximum number of nodes. Once the cloud computers are spun up, they are totally dedicated to your encoding chores. As shown in Figure 1, you control how quickly additional nodes are spun up by setting the number of pending jobs. Set the Node Creation Rate at one, and you’ll spin up another instance each time there’s one job pending. For even faster performance, you can set the minimum nodes to 10, which will burn through your monthly hours but will ensure the fastest possible responsiveness.
Figure 1. Determine the cost-efficiency performance trade-off with these controls.
This dedicated resource approach should also minimize the variation in encoding time experienced over the various tests, which I’ll explore in greater detail later. In terms of usability, after spending several weeks running dozens of episodic encodes in the cloud, it struck me that Elemental could do a lot more to help its users save encoding hours. For example, most high-volume producers likely have rush hours during their production cycles as well as slow times. Creating a simple schedule for spinning up and maintaining resources to meet this schedule and then (more importantly) spinning instances down after the rush would be nice. A simple switch to shut down all nodes after a certain duration of downtime, similar to the sleep mode on a computer, would also be helpful.
A few other points about Elemental’s PaaS offering: First, by design all deployments are created within a virtual private cloud for maximum security. In addition, while you select the region within which to deploy the nodes, Elemental transparently spins up nodes within different data centers within that region. Therefore, if one data center goes down, you’ll still have nodes available to handle the load. In addition, you can provision resources from multiple data centers in multiple regions to ensure that encoding resources are available.
The obvious downside for all this infrastructure is cost, at least for very small producers. While Encoding.com and Zencoder can be cost-competitive for even casual encoders, the lowest volume Elemental Cloud customers are paying in the low four figures each month. As I said earlier, if you’re looking for the cheapest service for low-volume production, Elemental Cloud isn’t for you.
This isn’t to say that Elemental would be more expensive for high-volume producers than Zencoder or Encoding.com. In fact, since pricing depends on factors such as node creation rate and minimum node settings, comparative costs would differ dramatically on a case-by-case basis. To further complicate matters for those attempting to compare pricing, note that Encoding.com charges by the gigabyte of input and output, which you can read about at features.encoding.com/pricing, while Zencoder charges for each encoded minute, which you can read about at zencoder.com/ en/file-transcoding/pricing. If comparative cost is a big factor in your cloud encoder selection, better sharpen your pencils and rev up your spreadsheet skills. You’re going to need them.
Working With Elemental Cloud
As mentioned, the previous Elemental Server review detailed the operation and workflow of that tool, which is identical to the Elemental Cloud, so you can check that review for the complete picture. The CliffsNotes version is this: A preset contains a single set of encoding parameters, while a profile contains multiple presets, say for an adaptive group or simply for multiple files that must be produced from a single source. You create encoding jobs by pointing a profile at a source file, whether via the UI, watch folders, or the API.
Producing groups of adaptive files is done at the profile level. After setting the base encoding parameters, you can add additional output groups for the adaptive streams. These can work off the base encoding parameters, or you can choose different parameters for these streams. This is shown in Figure 2. The File Group tab contains the encoding parameters for the 11 presets used in my standard tests. The additional tabs for Apple’s HLS, Adobe’s HDS, Microsoft’s Smooth Streaming, and DASH ISO contain the output parameters for the file in each adaptive group.
Figure 2. A profile containing multiple adaptive formats
If the adaptive files are derived from the encodings in the File Group, no additional encoding is performed; basically, the outputs are transmuxed from the original source files, which is fast and not taxing for the CPU. If the encoding parameters for the adaptive groups vary from the File Group, they are, of course, encoded separately.
In terms of performance, each job is submitted to a single core and can’t be shared over multiple nodes. From an encoding-efficiency perspective, if all four adaptive formats in Figure 2 used the identical encoding parameters from the original File Group, you’d want to keep them in a single profile and submit them as one job. If the encoding parameters in the four adaptive groups were all different, you would get faster performance on a multiple node system by creating separate profiles and encoding them as separate jobs.
Performance Trials
When I reviewed Encoding.com, I considered Amazon’s cloud encoding facility, the Amazon Elastic Transcoder, along with the Elemental Cloud for both performance and qualitative testing. For this review, I included Zencoder’s cloud encoding service instead of Amazon. Note that Zencoder doesn’t offer a fully functional UI, so Zencoder technicians created encoding scripts for my tests, which I reviewed and submitted into the site’s JavaScript request builder.
The results? Unfortunately, the nature of cloud encoding requires more disclosures and descriptions than a red herring prospectus for an internet startup. By way of comparison, when comparing desktop encoders you’d load them up, throw your tests at them, record the encoding times, and compare the quality. With cloud encoders, you have to incorporate factors such as upload time, queue time, service plan, the maximum number of available nodes, their status (running or not), and rules for spinning up additional nodes.
Upload time is a universal issue for all encoders, and you would think that it would apply equally to all cloud encoders. However, Zencoder starts encoding during the upload, while Encoding.com and Elemental don’t (Encoding.com has a planned feature called Instant Video that does, but it wasn’t ready during my testing). If you’re uploading a lengthy file on a slow connection, Zencoder could be almost done encoding before the other two even get started. On the other hand, if you’re encoding relatively short and compact files already in the cloud, upload time would be fast and largely irrelevant.
The encoding times presented in Table 1 ignore upload times. Why? Because every user’s scenario will be different, making it impossible to derive a single set of tests that would be universally relevant.
Table 1. Performance comparisons
Queue time (or wait time, as Zencoder calls it) is the time that a file sits in the queue, awaiting an encoder. With Zencoder, this seldom strayed above 4 or 5 seconds. With Encoding.com, it periodically took 1 to 2 minutes, with up to 6 to 7 minutes reported on a late Sunday night when the service appeared to spin up new cloud nodes to encode the newly submitted files. In all cases, queue and wait times are included in the overall time, since these are unavoidable.
With Elemental Cloud, there is no concept of queue time because I had dedicated resources. For my tests, I encoded using the fastest, most expensive configuration. That is, I always had nodes up and spinning before submitting the jobs, so I never experienced the 6-to-7-minute node startup time. I took this approach because one of the key reasons to use Elemental is retain control of your encoding times and because, unlike the queue times for Zencoder and Encoding.com, this decision is totally under the user’s control.
In terms of service plan, I encoded using Twin Turbo mode for all Encoding.com jobs, which ensured the fastest possible encoding, though it was at an additional $2 per GB. Note that Zencoder doesn’t offer a similar mode or I would have used that as well.
Finally, I’ll discuss the tests, of which there were three: The first was a 52-minute file encoded to 11 separate outputs in an adaptive streaming group, output to MP4 files for real-time messaging protocol-based (RTMP) Flash Dynamic Streaming. The second was a 210-minute SD file encoded to a single SD output. The third test involved six files, averaging about 45 minutes in duration, encoded to the same 11 outputs as the first test. I ran each test multiple times irregularly over 2 days and present the results in Table 1, which contains the average of the last three results. For the record, the 6-to-7-minute wait times that I experienced with Encoding.com were not in the last three encodes and are not included.
As you can see, Elemental was slowest in all three tests; Encoding.com was fastest in the tests involving multiple presets; and Zencoder was fastest in encoding the long SD file. On a positive note, Elemental was the most reliable performer, with by far the least variation between the fastest and slowest of the three recorded times.
Elemental Cloud Quality
What about quality? Here I looked at three scenarios. The first was the 640x360x30 at 240Kbps variant of the adaptive group produced for the first and third tests. In practice, this would be one of the streams sent to mobile devices connecting via cellular.
The second scenario was 1280x720x30 at 800Kbps, which is an aggressive encoding configuration that might be used by a website attempting to send the lowest possible data rate for a 720p video. By comparison, at this resolution most websites, including ESPN and YouTube, are encoded at 2.5Mbps, which is more than three times the tested data rate.
The final test scenario is the most relevant: 640x360x30 at 1200Kbps, which is a generous, but not an overly excessive, configuration from a data rate perspective. For example, while CNN publishes at around 800Kbps at this resolution, ESPN publishes at 1.4Mbps.
You can see all test files and still image comparisons. If I had to pick a winner in the 640x360x30 at 240Kbps comparison, it would be Encoding.com, although the difference between the contenders is commercially irrelevant, which I define as “indistinguishable without comparative videos,” and which web viewers never have. You can see this in Figure 3, where the frames in the background window are a bit more distinct, as are the faces of the dancers to the right. But this is the comparative frame that showed the most differential; most others showed little or none.
Figure 3. Encoding.com won the 640x360x30 at 240Kbps comparison.
In the other two comparisons, there was even less of a differential. Overall, as I’ve said many times, though all vendors tout the absolute top quality (as you would expect), they are all mature products running highly optimized H.264 code, so it’s not surprising that the differences are minimal and not commercially relevant.
Where does this leave us? The Elemental Cloud offering will appeal most strongly to those currently running Elemental hardware who need a cloud-based overflow valve for their appliance-based encodes. Elemental will also appeal to those seeking the benefits of PaaS as compared to SaaS, which includes the ability to create a private cloud and reserve resources.
The results? Unfortunately, the nature of cloud encoding requires more disclosures and descriptions than a red herring prospectus for an internet startup. By way of comparison, when comparing desktop encoders you’d load them up, throw your tests at them, record the encoding times, and compare the quality. With cloud encoders, you have to incorporate factors such as upload time, queue time, service plan, the maximum number of available nodes, their status (running or not), and rules for spinning up additional nodes.
Upload time is a universal issue for all encoders, and you would think that it would apply equally to all cloud encoders. However, Zencoder starts encoding during the upload, while Encoding.com and Elemental don’t (Encoding.com has a planned feature called Instant Video that does, but it wasn’t ready during my testing). If you’re uploading a lengthy file on a slow connection, Zencoder could be almost done encoding before the other two even get started. On the other hand, if you’re encoding relatively short and compact files already in the cloud, upload time would be fast and largely irrelevant.
The encoding times presented in Table 1 ignore upload times. Why? Because every user’s scenario will be different, making it impossible to derive a single set of tests that would be universally relevant.
Table 1. Performance comparisons
Queue time (or wait time, as Zencoder calls it) is the time that a file sits in the queue, awaiting an encoder. With Zencoder, this seldom strayed above 4 or 5 seconds. With Encoding.com, it periodically took 1 to 2 minutes, with up to 6 to 7 minutes reported on a late Sunday night when the service appeared to spin up new cloud nodes to encode the newly submitted files. In all cases, queue and wait times are included in the overall time, since these are unavoidable.
With Elemental Cloud, there is no concept of queue time because I had dedicated resources. For my tests, I encoded using the fastest, most expensive configuration. That is, I always had nodes up and spinning before submitting the jobs, so I never experienced the 6-to-7-minute node startup time. I took this approach because one of the key reasons to use Elemental is retain control of your encoding times and because, unlike the queue times for Zencoder and Encoding.com, this decision is totally under the user’s control.
In terms of service plan, I encoded using Twin Turbo mode for all Encoding.com jobs, which ensured the fastest possible encoding, though it was at an additional $2 per GB. Note that Zencoder doesn’t offer a similar mode or I would have used that as well.
Finally, I’ll discuss the tests, of which there were three: The first was a 52-minute file encoded to 11 separate outputs in an adaptive streaming group, output to MP4 files for real-time messaging protocol-based (RTMP) Flash Dynamic Streaming. The second was a 210-minute SD file encoded to a single SD output. The third test involved six files, averaging about 45 minutes in duration, encoded to the same 11 outputs as the first test. I ran each test multiple times irregularly over 2 days and present the results in Table 1, which contains the average of the last three results. For the record, the 6-to-7-minute wait times that I experienced with Encoding.com were not in the last three encodes and are not included.
As you can see, Elemental was slowest in all three tests; Encoding.com was fastest in the tests involving multiple presets; and Zencoder was fastest in encoding the long SD file. On a positive note, Elemental was the most reliable performer, with by far the least variation between the fastest and slowest of the three recorded times.
Elemental Cloud Quality
What about quality? Here I looked at three scenarios. The first was the 640x360x30 at 240Kbps variant of the adaptive group produced for the first and third tests. In practice, this would be one of the streams sent to mobile devices connecting via cellular.
The second scenario was 1280x720x30 at 800Kbps, which is an aggressive encoding configuration that might be used by a website attempting to send the lowest possible data rate for a 720p video. By comparison, at this resolution most websites, including ESPN and YouTube, are encoded at 2.5Mbps, which is more than three times the tested data rate.
The final test scenario is the most relevant: 640x360x30 at 1200Kbps, which is a generous, but not an overly excessive, configuration from a data rate perspective. For example, while CNN publishes at around 800Kbps at this resolution, ESPN publishes at 1.4Mbps.
You can see all test files and still image comparisons. If I had to pick a winner in the 640x360x30 at 240Kbps comparison, it would be Encoding.com, although the difference between the contenders is commercially irrelevant, which I define as “indistinguishable without comparative videos,” and which web viewers never have. You can see this in Figure 3, where the frames in the background window are a bit more distinct, as are the faces of the dancers to the right. But this is the comparative frame that showed the most differential; most others showed little or none.
Figure 3. Encoding.com won the 640x360x30 at 240Kbps comparison.
In the other two comparisons, there was even less of a differential. Overall, as I’ve said many times, though all vendors tout the absolute top quality (as you would expect), they are all mature products running highly optimized H.264 code, so it’s not surprising that the differences are minimal and not commercially relevant.
Where does this leave us? The Elemental Cloud offering will appeal most strongly to those currently running Elemental hardware who need a cloud-based overflow valve for their appliance-based encodes. Elemental will also appeal to those seeking the benefits of PaaS as compared to SaaS, which includes the ability to create a private cloud and reserve resources.
