Benefits of Guaranteed Processing Speeds and Queue Time SLAs
When evaluating cloud transcoding solutions, we are often asked about speed. “How fast are you compared with my on premise solution or desktop encoder?”When people use speed and encoding in the same sentence, they are usually referring to processing speed. However, when you talk about speed and cloud transcoding, you have to consider all four components of the cloud encoding job that make up total job time: ingest time, queue time, processing time and delivery or egress.
While most cloud providers make generic marketing claims like “we are really fast,” and “we process your job with no delay,” we thought it was worthwhile to help educate the marketplace on the different components of the cloud transcoding workflow and the steps Encoding.com has taken to accelerate each step of the process, in addition to offering guarantees and SLAs to support a predictable enterprise encoding workflow.
We are the fastest cloud encoding platform, and we guarantee it with our industry leading queue time SLA (Service Level Agreement). There are several features of our software as a service that will significantly reduce your total job time.
There are numerous benefits to using our cloud encoding software over processing your video with on-premise hardware. The key benefit being speed. Everyone wants to save time on encoding jobs and increase their efficiency, and Encoding.com is here to help. Let us do the work for you.
|wdt_ID||Steps in Cloud Encoding Workflow||Encoding.com Accelerated Workflow|
|1||INGEST Amount of time it takes source video to reach the processing center||• 10 Global Ingestion Centers|
• Aspera API Ingest
• Multi-Thread S3 Transit
• Multi-Thread FTP Transit
|2||QUEUE Amount of time the source video sits in a queue after it is uploaded to the processing center and before it begins processing||• Up to 18 second average queue time|
• Guaranteed maximum queue time SLAs
|3||PROCESSING Amount of time it takes the video to process||• All output formats processed in parallel|
• Guaranteed dedicated processing levels
• Baseline 4 cores
• Turbo 8 cores
• Twin Turbo 16 cores
|4||EGRESS Amount of time it takes to deliver the encoded assets to one or more delivery points||• Multi-Threaded Delivery|
• Aspera API Delivery
• Simultaneous delivery to multiple endpoints
Take control of where your processing occurs! By housing Encoding.com’s software on both Amazon’s EC2 and the Encoding.com Private Cloud, we have access to data centers around the globe. No matter where you decide to host your videos, there’s a data center nearby to handle your encoding tasks and return your content back to you in the most efficient manner. Check out the complete list of data centers that we support here:
Private Cloud (Oakland, CA): oak-private-clive
US (Northern Virginia): us-east-1
US (Northern California): us-west-1
US (Oregon): us-west-2
EU (Ireland): eu-west-1
Asia Pacific (Singapore): ap-southeast-1
Asia Pacific (Tokyo): ap-northeast-1
Asia Pacific (Sydney): ap-southeast-2
South America (Sao Paulo): sa-east-1
EU (Frankfurt):"EU (Frankfurt): eu-central-1"
<!-- Format fields -->
<!-- ... -->
With our global coverage, we allow you to select the processing data center closest to your source media’s location. Encoding.com ensures coverage globally with our 10 data centers throughout North America, Europe and Asia, including our own private cloud in California. Having regional processing servers reduces any latency in video transfer times.
Encoding.com is capable of ingesting hundreds of video codec and container combinations and all popular source video formats including .mov, .avi, .wmv, .mp4, .3GP, .3G2, .mj2, .m4v, .flv, .mpg, .flv H.264, .flv VP6, .asf and more. We can also process audio formats (.mp3, .aac, .amr, etc.) and image conversions (jpeg, gif, jpeg-2000, png, tiff, etc.). Click for the complete list of supported media formats. We also make encoding for mobile devices seamless and easy.
We employ several methods to accelerate the transfer of your source media to any of our processing centers: Optimized S3 Transit, Multi-thread FTP, and Aspera High Speed file transfer.
Encoding.com utilizes Amazon S3, one of the leading web services that can be used to store and retrieve any amount of data, at any time, from anywhere on the web. There are a variety of innovative ways that Encoding.com uses Amazon Web Services to power its service and make it easy for other AWS customers to integrate their videos.
Speed The upload and download times from your S3 bucket to our processing system on EC2 is lightning fast because it does not travel over the public internet.
For lightning fast transit you can add ?nocopy to the end of your Amazon S3 URL and we will begin encoding the video immediately from your S3 location as opposed to waiting for the media to transfer to EC2 before processing.
No S3 Bandwidth Costs Because we use Amazon EC2 for video processing, if you store your source video on S3 you will not be charged bandwidth to your S3 account for transferring to and from Encoding.com.
Advanced S3 Integration Using the web interface, watch folder or API, you can specify S3 buckets as either source or destination locations. And we have built full support for the Amazon S3 ACL permissions so you can ensure your encoded output files are set to the correct permissions.
Automatic CloudFront Distribution To stream content with Amazon CloudFront, users simply store the original copy of their media objects in the Amazon S3, and then enable those files for distribution in Amazon CloudFront with a simple command using the AWS Management Console or the Amazon CloudFront API. End users requesting streaming content are automatically routed to the CloudFront edge location best suited to serve the stream, so end users can get the highest bit rate, and therefore highest quality, stream possible. Multiple levels of redundancy built into Amazon CloudFront ensure that customers’ streams are served reliably and with high quality.
Multi-Thread FTP Ingest Encoding.com can now ingest your source media using multiple FTP threads for up to 3x faster ingest than our previous single threaded version. To give this update a test simply add ?multithread to the end of your existing FTP path. For example: ftp://user:password@server/path/movie.mp4?multithread
Multi-Thread S3 Transfer is Now a Default Encoding.com now uses a multi-thread transfer protocol as the default for all jobs using S3 as a storage location. No need to add ?multithread to the end of your S3 source path anymore and no need to remove it if you already have it hardcoded into your workflow. The transfer is now 2-3 times faster than our previous platform!
We also utilize Aspera, a cutting edge software technology that moves large volumes of data at maximum speed, regardless of file size, transfer distance and network conditions for larger bulk projects requiring rapid, efficient processing. fasp™ is Aspera’s proprietary technology that leverages UDP. Aspera is up to 100x then traditional FTP (file transfer protocol)
*UDP (User Datagram Protocol) has several benefits over standard TCP file transfers. UDP is normally employed for mass volumes of content and data. UDP is superior to TCP in terms of speed and are the preferred method of transfer for both larger and faster file transmission.
Content owners who operate an Aspera Enterprise Server™ or Aspera Connect Server™ can utilize the Encoding.com API to automate the transfer of files from the source location to the Encoding.com processing centers as well as delivery of encoded content to specified destinations. Both the source and destination transfers can utilize the fasp™ protocol. This self-service solution is ideal for existing Aspera server operators who have a high volume of video and need a way to automate high-speed transfer and encoding in the cloud. The well-documented and extensible XML API is easy to integrate, and it’s a great white-label option for leveraging cloud encoding in user-generated video sites, content management systems and desktop applications.
Download the Aspera Encoding.com whitepaper.
Scenario #1: Encoding.com vs. Localized Video Transcoder
A 1.5GB source video !le at 720p 3500k needs to be encoded into !ve output renditions: MP4 at 1600k, iOS at 720p, FLV at 1200k, WEBM at 2500k and OGV at 800k. It takes 48 minutes to process this job using an open-source video transcoder running on a 64-bit 2X Quad Core Xenon with 24GB of RAM, and this encoding job consumes a lot of system resources during the 48-minute window. It takes only 9 minutes to process this same job through Encoding.com, and during the 9-minute window, the system, its resources and its user are all free to perform other tasks.
Scenario #2: Encoding.com + fasp™ vs. Localized Video Transcoder
To continue the scenario above, add 11 minutes of upload time to the processing time of 9 minutes to give us a total of 20 minutes, more than twice as fast than the 48 minutes it takes to process this job on the localized encoding solution. (It would have taken 31 minutes to upload this same !le using TCP, but with fasp™, upload time has been reduced by 65%.). Moreover, adding additional bandwidth leads to even faster upload times with no theoretical limit on speed and throughput.
Many cloud encoding providers often advertise “really low queue times” or “virtually no queue times.” What they are leaving out is that this refers to “average queue time”. While average queue time is certainly critically important, it neglects a very important variable. What happens if you need to send 1000 jobs within a few minutes time, or what if another user of the system sends an enormous job to the platform. How does this affect my account’s queue time? Despite the massive scale enabled by software as a service, computing power is still a finite resource and requires a specific amount of time to provision new compute resource in the event that current running capacity is not sufficient.
Maximum Queue Time SLAs
While Encoding.com maintains some of the fastest average queue times in the industry, we believe enterprise class encoding workflows need to be guaranteed by more than variable or average encoding queue times. Encoding.com introduced queue time SLAs which guarantee that each individual job will never sit in a queue for longer than 4 minutes. This is especially critical when processing large libraries or when overall job turnaround time is critical to your workflow. No matter if you send us one job with one output or 1000 jobs with 10 outputs, our queue time SLAs will stand up for the job helping us provide the fastest video transcoder for your company!
|wdt_ID||Plan||Average Queue Time||Maximum Queue Time|
|1||Free 1 GB||32s||30m|
*Encoding.com guarantees that no video will sit in a queue for longer than your SLA regardless of how many videos you send at one time.
Many cloud providers don’t guarantee processing speed, because they offer variable processing speeds depending on the amount of available compute resource at any one time. For example, if you send a job to a cloud provider and they are underutilized, they will likely dedicate all available cores to the job. If you send the same job to a cloud provider at a time when they are at or near capacity, they will likely dedicate fewer cores to the job resulting in drastically slower processing time.
|wdt_ID||Speed Level||CPU Cores||Designed For||Benchmark||Price|
|1||Baseline||4||Small video under 100MB, Image2Image processing or large videos that are not time sensitive||14m (10 min SD video @ 3000Kbps)||Included in per/GB rate|
|2||Turbo||8||SD video from 500MB-1GB, or larger HD videos that are not time sensitive||8m (10 min SD video @ 3000Kbps)||+$1.00 per/GB output GB only|
|3||Twin Turbo||16||SD or HD videos over 500MB. Videos sent with twin turbo enabled under 500MB will be automatically degraded to Turbo level processing||4m (10 min SD video @ 3000Kbps)||+$2.00 per/GB output GB only|
Encoding.com introduced guaranteed processing speeds with a guaranteed allocation of processing cores for each job. In addition to our baseline 4 core processing speed, we offer two optional guaranteed speed levels: turbo (8 cores) or twin turbo (16 cores).
Why No Processing Speed SLAs?
Processing speed is primarily a function of three variables: source media characteristics (bitrate, resolution, etc.), output encoding parameters (format, bitrate, resolution, etc.) and processing cores dedicated to the job. Since Encoding.com is a self-service platform, we cannot control the first two primary variables. For instance, a high bitrate 4K file would take longer than a 480p low bitrate source file. If you are interested in getting an idea of how long your source video will take to process with Encoding.com, we recommend benchmarking your source video with all three of our different processing speed levels and then experimenting with output encoding parameters to find the desired balance of process speed, output file size, and playback quality.
With Encoding.com you can deliver to multiple CDNs and YouTube in one step. Simply specify multiple destination tags in your format requests and we will distribute your videos to the CDNs of your choice.
You can easily send your completed source videos to Amazon S3, Rackspace, Edgecast, Highwinds, Akamai, CloudFront, Limelight, Level 3, CDNetworks, & Brightcove.
Along with multiple delivery options, you can also inject varying metadata into each delivery location.
<!-- Main fields -->
<format> <!-- YouTube delivery Description-->
<format> <!-- Amazon S3 Delivery Description Metadata insertion-->
<format> <!-- Rackspace delivery Description Metadata insertion-->
The HEVC codec is on the rise.
Visit Encoding.com at AWS re:invent Encoding.com will highlight the latest in
https://t.co/aGwkhHWOFk Winter 2020 News - https://t.co/DWbtgTI34l3 weeks ago
RT @LiveVideoStack : Developers are starting to pay more attention and implementing HEVC, according to an outlook of codec-related usage dat…2 months ago