VPU-as-a-Service & Owning Your Infrastructure

VPU-as-a-SERVICE

Cloud video teams have spent the last decade learning how to scale transcoding in software. The model was straightforward: provision CPU instances, run FFmpeg or a commercial encoder, generate the required outputs, and scale horizontally when volume increases.

That model made sense when the main requirement was flexibility. It allowed video platforms to move quickly, avoid large upfront hardware purchases, and use cloud capacity as demand changed. But the video workload has changed. Today’s transcoding environments have to support more inputs, more output renditions, more codecs, higher resolutions, tighter latency targets, and larger libraries of both live and on-demand content.

At a certain point, the question stops being whether cloud transcoding works. It clearly does. The more important question is whether the default cloud model is still efficient enough for the next generation of video workloads. That is the opening for VPU-as-a-Service.

VPU-as-a-Service is not simply “hardware acceleration in someone else’s data center.” It is a different operating model for video infrastructure. It gives engineering teams access to purpose-built video-processing hardware via a cloud-style deployment model, while preserving the control they expect with infrastructure-level access.

That distinction matters. Many serious video platforms do not want a black-box encoding service. They already have media pipelines, automation, monitoring, packaging, origin integration, storage workflows, and business logic. What they need is not necessarily someone else to run the whole workflow. What they need is a better execution layer for the most expensive part of the workflow: video processing.

VPU-as-a-Service addresses that specific problem.

The cloud solved flexibility. It did not solve efficiency.

A CPU can encode video. That is not in dispute.

Software encoding is flexible, mature, and deeply embedded in media workflows. FFmpeg, GStreamer, commercial encoders, schedulers, packaging systems, storage workflows, and monitoring tools have all grown around that model.

The problem is that video encoding is not ordinary compute.

It is repetitive, intensive, and shaped by codec complexity, resolution, frame rate, quality targets, latency requirements, and output ladder design. A single live channel may need several renditions in real time. A VOD platform may need to process thousands or millions of assets. A service may need H.264 for broad compatibility, HEVC for bandwidth-sensitive delivery, and AV1 for newer compression gains.

When all of that lands on CPUs, the infrastructure plan starts to bend around the encode layer. More cores are consumed. Instance pools grow. Power and cooling become material. Performance gets harder to predict under sustained load. New codecs become expensive to test before the business case is even proven.

The issue is not that CPUs are incapable.

The issue is that specialized video work is being pushed through generalized infrastructure.

VPU-as-a-Service changes the operating model.

A , or VPU, moves encode, decode, and transcode work onto silicon designed for video. That is the technical part.

The more important shift is operational.

VPU-as-a-Service provides teams with access to dedicated video hardware via a cloud-style model. They do not have to start with hardware procurement, server design, driver validation, deployment planning, and a long-term operations commitment. They can provision accelerated infrastructure, attach VPU capacity to a virtual machine, and test real workloads with the tools they already use.

In the NetActuate model, NETINT VPUs are exposed as VM-attached accelerators through secure passthrough. A team can choose a deployment location, configure compute resources, attach the accelerator, and run FFmpeg, GStreamer, or NETINT’s Bitstream processing stack without giving up control over the pipeline.

That last point matters.

This is not a black-box transcoding service. It is infrastructure with built-in video encoding acceleration.

This is not managed transcoding.

Managed transcoding services have a clear role. They are useful when a company wants to submit jobs and let a provider handle much of the workflow. Define the input, output, and settings. Let the service abstract the rest.

Many serious video teams are not looking for that.

They already have presets, quality-control processes, packaging, storage integration, rights logic, monitoring, deployment automation, and business rules. In many cases, years of operational knowledge are embedded in scripts, APIs, job schedulers, and FFmpeg commands.

For those teams, the problem is not the absence of a workflow. The problem is that the execution layer has become too expensive.

VPU-as-a-Service fits that middle ground. It does not ask teams to rebuild around someone else’s encoding product. It gives them a better place to run the workflow they already trust.

That is why the model is compelling. It preserves control while changing the economics underneath.

The architecture gets cleaner.

In a CPU-only environment, the same compute layer often handles application logic, job coordination, file movement, monitoring, packaging support, and encode/decode operations.

As volume grows, encoding dominates the plan.

With direct VPU access, the roles separate. The CPU manages the workflow. The VPU handles the video operations.

That separation is simple, but the impact can be large. VOD pipelines can process more output per node. Live services can improve density and consistency of performance. AV1 and HEVC testing can happen without first standing up large CPU pools. Mixed workloads can scale the application and video processing layers more independently.

Not everything belongs on the VPU. Caption handling, metadata, packaging, monitoring, storage, and delivery still depend on the surrounding system.

But encode, decode, and transcode are exactly the stages where dedicated hardware can change the cost curve.

Codec strategy is now an infrastructure decision.

Codec strategy is often discussed as a playback or bandwidth decision. That is only half the story.

H.264 remains the compatibility baseline. HEVC matters for premium and bandwidth-sensitive delivery. AV1 is attractive to platforms seeking improved compression efficiency and a path to newer device ecosystems.

But every codec choice also carries an infrastructure bill.

A codec that saves bandwidth may still be difficult to adopt if encoding costs are too high. A ladder that looks smart in a planning document may become expensive at production volume. An AV1 pilot may be technically attractive but operationally painful if it requires a large CPU expansion just to learn whether the model works.

VPU-as-a-Service lowers that barrier.

Teams can test real content, real ladders, real latency targets, and real concurrency levels before committing to a broader rollout. The measurements become practical: streams per node, cost per encoded hour, watts per stream, latency under load, quality at target bitrates, and CPU capacity avoided.

That is the kind of evidence engineering, finance, and operations can all use.

What teams should prove before production.

The right proof of concept is not a generic benchmark. It is a production rehearsal.

Teams should validate codec, profile, resolution, bit depth, frame-rate, and caption requirements against their own media. They should run real adaptive bitrate ladders, not only sample clips. They should measure live latency under sustained load, not short bursts. They should test FFmpeg, GStreamer, SDK, driver, and firmware integration in the environment where the service would actually run.

They should also look closely at isolation, observability, and scaling.

Is the accelerator dedicated to the workload? Can utilization, errors, throughput, and job performance be monitored? Can the model expand from one VM to a larger deployment across multiple locations? What happens when demand spikes? What does the cost look like per stream or encoded hour, not just per hour of infrastructure?

That is where the decision gets real.

Where VPU-as-a-Service fits.

This model is not for every video workload.

Small or occasional jobs may be fine on CPU infrastructure or managed transcoding. Teams without media engineering resources may prefer a fully managed service. Workflows centered on rendering, graphics, or custom AI may also require additional accelerators.

VPU-as-a-Service is most relevant when video processing is persistent, high-volume, multi-codec, latency-sensitive, or geographically distributed. It is especially relevant for teams that already operate their own media stack and do not want to give it up just to improve efficiency.

That is the practical lane.

It is more controllable than managed transcoding. It is less operationally heavy than buying and deploying dedicated hardware. It gives video teams a way to keep their software model while changing the underlying hardware economics.

The bigger shift.

Cloud infrastructure is becoming workload-specific.

AI has GPUs and inference accelerators. Networking has SmartNICs and DPUs. Video processing has VPUs.

That does not mean every company needs to own specialized hardware. It means the cloud model is evolving so teams can consume specialized hardware when the workload justifies it.

For video platforms, this shift is overdue. The pressure on the transcoding layer keeps rising: more formats, more codecs, more devices, more live workflows, more libraries, and more cost scrutiny.

CPU-based cloud transcoding solved the flexibility problem. It did not fully solve the efficiency problem.

VPU-as-a-Service is a practical answer to that gap. It keeps the parts of cloud infrastructure that video teams value: self-service access, familiar deployment patterns, location choice, and operational control. It adds purpose-built video silicon where the economics matter most.

The point is not to hide the hardware. The point is to make the right hardware easier to use. 

Choose one:

We have two VPUaaS platforms ready to support your needs so that you can get started today: Akamai Cloud and NetActuate.

Overview for engineers and executives who own the streaming P&L

If video is a core line of business, transcoding costs shape margin, feature velocity, and even codec policy. The attached paper, ‘AWS Sanity Check,’ makes a bold claim that deserves attention: relying on general-purpose AWS infrastructure for transcoding creates a flawed cost model that erodes operating margin.

The paper puts it plainly through David Ronca’s warning, “There are two types of companies in the video business. Those that are using video processing ASICs… and those that will.”

This article translates the paper’s findings into an action plan. It is written for VPs of Engineering, Heads of Video, CTOs, and finance partners who need a clear cost and architecture path that they can validate quickly and easily. Expect direct comparisons, concrete numbers, and step-by-step guidance to pilot a more effective approach.

Key conclusions:

1. Hyperscalers have already moved off CPUs for large‑scale video, using custom silicon that delivers order‑of‑magnitude gains in throughput and efficiency. The paper cites Google’s Argos chip, which offers “20 to 33x” throughput compared to optimized CPUs, and Meta’s MSVP, which provides a “9x to 50x” uplift, demonstrating that generic servers are the wrong tool for this job.
2. AWS imposes three compounding costs on video: opaque pricing for MediaConvert, premium yet underwhelming accelerators, and expensive egress. The paper labels these as taxes on transparency, inertia, and success.
3. A like‑for‑like TCO comparison shows VPU‑accelerated instances cut per‑stream transcoding costs by two to four times, and egress from VPU‑enabled clouds is eighteen times cheaper. Tables on pages 8 to 10 show the math.
4. Operators that switched to VPU‑based servers reported large OPEX reductions, including one case of “$8.6 million annual OPEX savings” after an 80 percent reduction in server count and energy.
5. You can validate the claims in approximately a month with a parallel pilot, without requiring a rip-and-replace approach. The paper outlines a four-step plan that aligns neatly with common workflows.

Now, let’s review eight key findings from the paper that reveal where the money goes when you are using AWS, along with a blueprint for testing and adopting a VPU-first model.

Finding 1: Specialized Video Silicon Is the New Baseline at Scale

When workloads are repetitive, parallel, and bound by tight real‑time constraints, generic CPUs fall short. Video encoding checks all three boxes. That is why the largest platforms built chips instead of buying more servers.

The paper provides two anchor points:

• Google Argos (YouTube). Encoding 4Kp60 H.264 on CPUs would have required “an estimated 7.2 million Intel Skylake cores,” and “over 33 million cores” for VP9. Google built Argos and measured “20 to 33x” throughput vs. its optimized CPU system.
• Meta MSVP. Across Facebook and Instagram scale, MSVP delivers a “9x increase in throughput for H.264 and a 50x increase for VP9,” with modules consuming about “10 watts.”

Those numbers are not marketing puff; they describe architectural truth. CPUs carry control logic and flexibility that encoding does not need, then burn power on cache and branch mispredictions that content pipelines do not value. VPUs and ASICs trade that flexibility for deterministic video primitives, so throughput jumps and power consumption fall. As the paper states, “general‑purpose cloud computing is becoming a liability for scaling video streaming.”

WHAT TO DO WITH THIS: If hyperscalers abandon CPU encoding, even with bulk discounts and internal tooling, it is reasonable to assume that the rest of the market should follow suit. Price your roadmap on the assumption that specialized silicon is the standard for dense live and VOD workloads. Keep CPUs for orchestration, packaging, manifest work, and glue logic, not for the encoding itself.

Finding 2: The Three AWS Taxes That Quietly Drain Margin

The paper groups AWS‑related cost pain into three buckets. Treat them as a checklist when explaining overruns to finance.

The transparency tax: “normalized minutes”

MediaConvert bills on “Normalized Minutes,” not on real minutes or resources. Multipliers stack based on resolution, frame rate, codec, and tools such as multi-pass. The result is a pricing model that looks simple on the surface and behaves like a black box in production.

The example in the paper is blunt. A 60-second 1080p30 clip encoded at the Professional Tier with multi-pass HQ incurs a “3.5x multiplier.” You pay for “210 seconds” of work, not 60, and that is before you multiply across the ABR ladder. The paper warns, “This opaque system renders capacity planning uncertain,” and the uncertainty grows as you chase quality gains at the ladder’s top.

OPERATOR TIP: Calculate the implied cost per output minute across your typical ladder and settings, then pin it to a dashboard. If your implied cost per output minute exceeds your viewing mix, you are funding the opacity, not the output.

The inertia tax: VT1 accelerators that miss the mark

AWS recognizes CPU inefficiency for video and offers VT1 instances with Xilinx U30 FPGA cards. The issue is price‑to‑throughput. The paper’s comparison for 1080p live encoding puts an AWS VT1 plan at “about $62.72 per stream per month,” while a VPU plan in the Akamai cloud lands at “$15.55 per stream.” That is roughly four times the per‑stream cost.

Even at the instance level, an “AWS vt1.3xlarge” with one U30 card lists around “$0.65 per hour” or “$475 per month.” The VPU instance cited runs at “$0.53 per hour” and produces more output per dollar. The paper calls it what it is, a premium that “delivers lower encoding throughput per dollar.”

OPERATOR TIP: When comparing instances, never stop at the hourly price. Normalize by concurrent ladders or channels at your quality targets.

The success tax: egress

Bandwidth dominates recurring spend for any streaming business with traction. The paper’s numbers put AWS egress around “$0.09 per GB” and the VPU‑accelerated alternative at “$0.005 per GB,” an eighteen‑to‑one ratio.

The table on page 8 quantifies it. At 1 PB per month, AWS egress is “$1,080,000 per year” versus “$60,000” on the alternative, a “$1.02 million” difference. At 5 PB per month, the gap grows to “$5.1 million per year.”

OPERATOR TIP: Compute egress as a first‑class KPI. Cost = delivered bytes × price per GB. Keep a simple sheet that ties catalog, average bitrate per title, viewing hours, and region mix to total GB. Your CFO should be able to run sensitivity scenarios in minutes.

Finding 3: TCO Reality Check, Side‑by‑Side

The centerpiece of the paper is Table 2, which takes a single 1080p live channel and asks, “What is the monthly cost per stream” under three options?

• VPU‑accelerated instance (Akamai). Two NETINT Quadra T1U cards per instance. “18 streams” per instance. “$488” per instance per month. $27.11 per stream per month.
• AWS VT1 accelerator plan. One Xilinx U30 per instance. “8 streams.” “$475” per instance per month. $59.38 per stream per month.
• Generic CPU plan. 8‑core dedicated CPU instance. “2 streams.” “$144” per instance per month. $72.00 per stream per month.

The conclusion is not subtle. The paper writes, “Running this workload on AWS means choosing to spend 200 to 300 percent more than necessary for the same output.”

Here’s how to reproduce this claim:

1. Fix your target quality and ladder. Use the same preset across all tests.
2. Measure stable channel density per instance at those settings.
3. Compute instance cost per month × required instances ÷ channel count.
4. Add egress deltas if you will deliver from the same platform.

This framework keeps the conversation honest. Hourly instance prices do not matter if one machine finishes five times the work.

Finding 4: Throughput per Dollar, Not Price per Hour

The table on page 10 reframes the discussion around work done for a given spend. With both instances priced around “$0.53” to “$0.52 per hour,” the VPU instance handled “six simultaneous 1080p HEVC encoding ladders,” while the CPU instance handled “one.” That yields “11.32 ladders per $1.00 per hour” on the VPU option and “1.92” on the CPU option. The paper summarizes it cleanly: “For the same hourly cost, the VPU‑powered instance delivers six times the output of the CPU‑based instance.”

OPERATOR TIP: Define “throughput unit” as ladders per hour at your desired quality. Place that on your internal scorecards alongside cost. This prevents false savings from cheaper machines that stall under load.

Finding 5: The Codec Trap, Solved

AV1 and HEVC reduce bitrate for the same quality, but CPU encoders make them look expensive. The paper notes AV1’s encoding effort can be “five to ten times higher” than H.264 on CPU farms. The result is a stalemate: cheaper delivery on paper, but higher costs in practice, so teams often punt on adoption.

VPU‑based pipelines end the stalemate. The paper argues that specialized video ASICs make heavy codecs “economically feasible to use widely,” which means you can reduce bitrates and decrease egress while maintaining or improving quality. That is real money once you account for the egress numbers earlier. The paper clearly describes the flywheel: more efficient codecs lower bandwidth, which further reduces the already lower egress bills on the new platform.

OPERATOR TIP: Set a target for AV1 or HEVC coverage by device cohort. Start with devices that already decode in hardware. Model the bitrate drop against your egress line at new prices. That saving alone may be enough to fund the migration.

Finding 6: Features That Were Out of Reach Become Routine

The paper goes beyond cost and calls out features that VPU density unlocks:

• Content‑aware encoding with on‑board AI engines or adjacent AI workflows, for example, detects faces or text and allocates bits to the right regions without adding file size. The paper notes these techniques are “computationally impractical” on CPU pipelines yet straightforward with specialized hardware.
• Multi‑view experiences, like synchronized camera angles or multiple games for sports streaming apps. On general‑purpose clouds, parallel encoding incurs multiple costs. With VPU density, “a single 1RU VPU server can handle multiple parallel encodes” that would take “dozens of CPU servers.”

These are not vanity features. A good multi‑view experience can drive engagement and retention, as platforms like YouTube have found. Content-aware encoding can increase VMAF scores without incurring a bitrate penalty. Both are difficult to fund in a CPU budget. They become straightforward once the per‑stream baseline drops.

Finding 7: Proof in One Month, Without Upending Your Stack

Technology leaders want proof of their own content. The paper provides a low‑risk path that mirrors standard engineering practice:

1. Scope a representative slice. One 24×7 live channel or a VOD subset covering your typical content complexity.
2. Deploy on a VPU‑powered instance using standard tooling like Kubernetes or Terraform. The paper calls out that this is “not a bespoke project” for a competent team.
3. Run in parallel for 30 days with identical settings to get apples‑to‑apples metrics on cost, density, and objective quality.
4. Measure and compare computed hours, dollars, and modeled egress at the new rates. Build the business case from your own numbers.

One detail to highlight for stakeholders who fear lock‑in. The paper notes that migrating off AWS for transcoding does not mean abandoning AWS entirely. A hybrid model is common. Keep generic services on AWS, move the encoding to a specialized platform, then deliver from the same provider to capture the egress benefit.

Finding 8: The Board‑Ready Argument

Finance leaders are concerned with EBITDA, payback, and risk. The paper gives talking points in their language.

• The paper documents an “80 percent reduction in server count and energy usage” and “$8.6 million annual OPEX savings” from a real migration to VPU servers.
• It asserts per‑stream compute cost reductions of “70 percent or more” and egress reductions “up to 95 percent.” Even if your numbers are half that, the impact is still material.
• It closes with a challenge that fits any quarterly review: “Knowing that a technically superior… alternative exists, one that can cut per‑stream compute costs by over 70 percent, can you confidently justify your current AWS transcoding expenditures to your board and shareholders?”

Combine those statements with your pilot’s measurements and a table like the ones on pages 8 to 10, and you have a crisp board deck.

Download the PDF: https://netint.biz/AWS-sanity

Practical How‑Tos You Can Apply This Week

1) Quantify egress exposure by title and device.
Formula: Monthly GB = hours viewed × 3600 × average bitrate in bps ÷ 8 ÷ 1e9. Then multiply by price per GB. Run it twice, once at AWS rates and once at the VPU‑cloud rates from the paper’s table on page 8. Even modest catalogs will show six-figure annual deltas at realistic usage levels.

2) Recalculate your effective cost per output minute.
Take your last MediaConvert bill, divide by total output minutes produced. Then reconcile against ladder mix. If the effective rate jumps when you push quality or add multi‑pass, that is the transparency tax at work. The paper’s description of “Normalized Minutes” and the 3.5x multiplier example is your reference.

3) Choose the right target for a pilot.
Pick a channel with predictable traffic and a ladder you do not intend to tweak during the test. Keep presets locked. The goal is to measure density and cost, not to retune encoders for a bake‑off.

4) Lock in objective quality metrics.
Pick one metric, such as VMAF, and set a floor per rendition. Do not accept higher density at the expense of lower quality. If you need to move from H.264 to HEVC or AV1 to hit targets, model the egress savings side by side, as the paper suggests in its discussion of codec economics.

5) Model device support and rollout order.
Start where decoding is already in hardware. Newer TVs, streaming sticks, and mobile SoCs will handle HEVC and AV1. The paper outlines how VPU encoders make the compute side practical, allowing you to actually publish those streams.

6) Put “throughput per dollar” on your runbooks.
Adopt the paper’s framing from page 10, ladders per $1.00 of instance time. This single metric keeps teams honest and aligns engineering with finance.

Frequently Heard Objections, Answered with Data

“We already use VT1. That is hardware acceleration.”
Not all acceleration is equal. The paper’s VT1 plan works out to “about $62.72 per stream per month” for 1080p, against “$15.55” on the VPU plan. Even before egress, the delta is too large to ignore.

“MediaConvert’s pricing is pay‑as‑you‑go, so we can control spend.”
Pay‑as‑you‑go does not help if the meter uses “Normalized Minutes” that grow with multipliers you do not control at runtime. The paper’s 60‑second clip, billed as 210 seconds, is the simplest illustration.

“Migrating is risky.”
The paper shows a low‑risk, parallel, 30‑day pilot using your existing orchestration tools. Keep AWS for everything else if you prefer. Move only the encoding. That is a scoped, verifiable change with clear go‑no‑go criteria.

“Egress is the price of doing business.”
Yes, and egress is also a lever. The paper shows a $1.02 million annual difference at 1 PB per month. If your board can save that by agreeing to deliver from a VPU‑enabled cloud, it is a rational move.

Recap and a path to implementation

The paper’s thesis is clear. Generic AWS infrastructure is the wrong economic foundation for transcoding at scale. Specialized video hardware has moved from hyperscaler curiosity to industry baseline. The cost gaps are not marginal; they are 2 to 4 times on compute and roughly 18 times on egress in the examples shown. The data in the paper backs this up.

Here is a focused plan to act on this, built directly from the paper’s guidance:

1. Decide the pilot scope within one week. Select a channel or VOD subset that reflects your typical content complexity and ladder. Document presets and quality targets so tests are apples‑to‑apples. The paper’s Step 1 is to “identify and isolate a small, representative portion” of the workload.
2. Provision a VPU‑accelerated instance on a supported cloud and integrate it using your standard orchestration toolchain, for example, Kubernetes or Terraform. The paper notes that this step utilizes common infrastructure-as-code practices, rather than a bespoke project.
3. Run both paths in parallel for 30 days. Keep settings fixed, collect density, compute hours, and quality metrics. The paper explicitly suggests this window and method.
4. Calculate TCO with the paper’s structure. Use cost per stream per month and ladders‑per‑dollar from pages 9 and 10. Add egress using page‑8 rates to capture the delivery side.
5. Show the board the before‑and‑after as three numbers.
   • Per‑stream compute cost at fixed quality.
   • Egress cost at current and target codecs.
   • Total OPEX impact projected to your volume.
     Anchor it with the paper’s documented “$8.6 million annual OPEX savings” example to show plausibility.
6. Stage the migration. Start with live channels, where concurrency is predictable, and then expand to VOD transcodes that benefit from content-aware encoding or heavier codecs. Keep non‑video services where they run best. The paper endorses hybrid models.
7. Invest the savings. Utilize lower compute and egress costs to ship AV1 or HEVC across supported devices, roll out multi-view where it increases watch time, and raise quality floors using content-aware tools that are now practical at scale. The paper argues this is how operators turn cost relief into product leverage.

A closing thought, borrowed from the billboard on the cover: “Your margin is my opportunity.” That line captures the risk of staying put. If competitors achieve 70 percent compute savings and order-of-magnitude bandwidth relief, the extra cash will likely find its way into rights, features, and price pressure. The paper’s final challenge is the right one to present to leadership: “Can you confidently justify your current AWS transcoding expenditures to your board and shareholders?”

If the answer is no, the path forward is straightforward. Prove it in a month. Move the workloads that pencil out. Keep everything else where it belongs. Then reinvest the savings into quality and features that viewers notice.

Schedule a meeting to learn how NETINT VPUs can enhance live streaming with energy-efficient, scalable solutions.

ACCESS NOW: ASIC-Based Transcoding
for High-volume Use Cases
Including social media, broadcast, interactive platforms, and service providers

ACCESS NOW

BURNABY, CANADA, September 12, 2024 , NETINT Technologies today announced a partnership with Akamai, the cloud company that powers and protects life online, to integrate NETINT’s video processing units (VPUs) into Akamai’s massively distributed cloud platform. The collaboration kicks off a wave of development between the two companies to improve video processing and encoding in the cloud.

“The market is desperate for better performance, efficiency, and scalability. And that requires looking at different approaches to deliver on those requirements,” said Alex Liu, NETINT’s Co-Founder and COO of NETINT TECHNOLOGIES. “One way to do that is by innovating for power consumption with an order of magnitude improvement on stream density, which we pioneered with our VPUs. The other way is innovating for scale, which nobody does better than Akamai. Combine the two and you create a significant leap forward for the streaming video industry.”

Adding NETINT VPUs into Akamai’s distributed cloud platform opens the potential to reshape the economics of streaming media by addressing persistent industry challenges, such as rising content licensing and operational costs; the need for more efficient implementations of advanced codecs; pressure to improve video quality while managing bandwidth consumption; and scalability requirements for growing audience consumption and higher resolutions.

“Our customers are looking for ways to deliver better experiences to their customers,” said Shawn Michels, Vice President, Product Management, Akamai, “Adding NETINT’s silicon to our platform, customers who don’t want to build or operate their own hardware can access ASIC technology just as Google does for YouTube and Meta does for Facebook and Instagram.”

• Encoding Density: Up to 320 live 1080p30 streams, or 80 4Kp30 streams, or 20 8Kp30 channels on a single server.
• Codec Versatility: AV1, HEVC, and H.264 encoding support with VP9, HEVC, and H.264 decoding.
• Resolution Flexibility: Up to 8Kp60 with HDR and 10-bit color depth.
• Application Integration: API and plug-in support for FFmpeg and Gstreamer.
• AI-Powered Processing: Up to 180 TOPS AI processing per server.

NETINT and Akamai are exhibiting at IBC 2024 at the RAI Amsterdam, September 13-16. NETINT is demonstrating Quadra VPU capabilities on stand 5.A54. Akamai will show its range of cloud-based media delivery, computing, and security capabilities in the Akamai Lounge, located in the Elicium (Hall 13) on the third floor.

About NETINT

NETINT Technologies is the founder of the VPU (video processing unit) category and an innovator in ASIC-based video processing solutions for unparalleled encoding performance, density, and energy efficiency. Pioneering green computing approaches for video, NETINT VPUs offer a 20-40x reduction in energy requirements and operational costs. NETINT is shaping the future of hyperscale media encoding and processing with advanced codec support for AV1, 8K, HDR, and on-chip AI engines. Learn more at netint.com.

About Akamai

Akamai powers and protects life online. Leading companies worldwide choose Akamai to build, deliver, and secure their digital experiences , helping billions of people live, work, and play every day. Akamai Connected Cloud, a massively distributed edge and cloud platform, puts apps and experiences closer to users and keeps threats farther away. Learn more about Akamai’s cloud computing, security, and content delivery solutions at akamai.com and akamai.com/blog, or follow Akamai Technologies on X, formerly known as Twitter, and LinkedIn.

Contact

Mark Donnigan,
Head of Strategic Marketing
NETINT Technologies
+1 604-628-8177
email us here

Visit us on social media:

Linkedin


Youtube


Twitter


Facebook

ACCESS NOW: ASIC-Based Transcoding
for High-volume Use Cases
Including social media, broadcast, interactive platforms, and service providers

ACCESS NOW

The cloud is a great resource for launching new products and services, particularly interactive streaming services, where capital costs can be high and demand uncertain and highly variable. Still, it’s crucial to remember that the cloud, while a remarkable launchpad, isn’t the ideal rocket ship for sustained flight. To truly soar towards profitability and long-term success, owning your transcoding infrastructure, particularly ASIC-based solutions, can become the game-changer.

cloud as the great equalizer for small businesses

Cloud services, like nimble spaceships, offer undeniable advantages for nascent streamers. They provide instant scalability, eliminate upfront hardware investments, and simplify operations. As authors Kate Duricko and Miranda Adams observe in BizTech Magazine, the “cloud is the great equalizer for small businesses. While larger budgets allow enterprises to purchase more on-premises hardware and spend on skilled staff, cloud solutions provide a way for small and midsize businesses to access enterprise-level resources and computing power on demand.”

Startups and businesses testing the streaming waters can leverage the cloud’s flexibility to experiment, adapt, and iterate swiftly. However, the cost equation shifts dramatically as streaming audiences soar and demand explodes.

The Cloud’s Costly Tailwind

While the cloud seems initially light on the wallet, its true price tag unfolds as volumes escalate. Each transcoded stream incurs recurring per-use fees, leading to a ballooning operational expenditure (OPEX) as your audience grows. In addition, as your encoding needs get more sophisticated, using a service provider constrains your operation to their vision, not yours.

In these cases, on-premise equipment offers a tempting alternative. The upfront investment might seem steep, but long-term operational expenses are undeniably lower; often significantly so. Broadcasters also gain complete control over their systems, tailoring encoding, transcoding, and delivery to their specific needs. This flexibility translates to a more efficient and customized streaming experience for viewers, reflecting the broadcaster’s unique brand.

Real-world examples show the potential. Swedish telecom operator Sappa found cloud transcoding wasn’t cost-effective for their live OTT channels. They migrated on-premise to gain control, upgrade to new services, and reduce overall costs. Similarly, A1 Croatia, a Croatian telecom company, switched for similar reasons, enjoying increased energy efficiency and a future-proof platform.

Entering the ASIC Orbit

Once you consider on-premise equipment, ASICs become the obvious choice. ASICs, or Application-Specific Integrated Circuits, are custom-designed chips built for a single purpose – in this case, transcoding video with unparalleled efficiency. While the initial investment in hardware might seem daunting, the long-term savings are quite substantial (see here and here). This translates to a dramatic improvement in profit margins, freeing up resources for content creation, marketing, and audience engagement.

That’s obviously why both Meta and Google have transitioned much of their transcoding from CPUs to ASICs, with Google claiming that their ASIC, called Argos, replaced over ten million Intel CPUs. Once you decide to quit the cloud, it’s critical to transition to the most efficient transcoding technology available, which ASICs clearly are.

Owning Your Destiny

Beyond mere cost savings, owning your transcoding infrastructure grants you unparalleled control and resilience. You’re no longer beholden to the whims of external pricing changes or service disruptions. As your streaming empire expands, ASICs scale effortlessly, handling even the most demanding workloads with unwavering performance. And you gain complete command over video quality and latency, shaping the viewing experience according to your exacting standards.

From Seedling to Sequoia

Think of the cloud as a nurturing greenhouse, offering the perfect environment for your streaming seedling to sprout. It provides the initial warmth and support to launch your venture. However, as your business matures and ambitions blossom, transitioning to owning your infrastructure, symbolized by the robust growth of an ASIC-powered system, becomes the key to reaching your full potential.

The cloud might be the perfect launchpad, but for enduring success in the streaming cosmos, it’s time to ignite the power of your own ASIC-powered rocket ship and chart your independent course toward streaming stardom. By embracing the shift from cloud dependence to ASIC ownership, you empower your streaming venture to transcend the confines of survival and chart a course toward long-term, sustainable success.

WATCH ON DEAMAND:
Building Your Own Live Streaming Cloud

ACCESS NOW: ASIC-Based Transcoding
for High-volume Use Cases
Including social media, broadcast, interactive platforms, and service providers

ACCESS NOW

Why coordination, not raw speed, determines whether video infrastructure scales with confidence

The Operational Breaking Point

Large video systems rarely fail because encoding stops working. They fail because operational complexity overtakes human and system capacity. The technical components keep running, but the ability to reason about, direct, and recover the whole system erodes as concurrency grows.

As pipelines scale, teams contend with more simultaneous jobs, more pipeline stages, more regions, and more failure domains. State proliferates. Dependencies multiply. Small misalignments propagate quickly, surfacing as symptoms far from their root causes.

This is the paradox of modern video infrastructure: the hardware has never been more capable, yet the systems it powers have never been harder to operate. The bottleneck has shifted from processing power to operational control. At scale, control is the system that matters.

When Efficiency Amplifies Complexity

Video Processing Units (VPUs) have materially improved the economics of transcoding. They increase density, reduce power consumption per stream, and make capacity more predictable. These gains are significant, but they also reshape the operational landscape in ways that are easy to underestimate.

When transcoding becomes cheaper and denser, teams respond by running more concurrent jobs, distributing workloads more aggressively, and concentrating more work on fewer resources. Each of these decisions is rational in isolation. Together, they expand the blast radius of any single mistake.

Efficiency, in other words, does not remove the operational problem. It shifts it. The faster and denser the system becomes, the more critical it is to decide precisely where jobs run, when they run, how they fail, and how they recover. Without those decisions being made deliberately, efficiency becomes a liability rather than an advantage.

KEY INSIGHT
VPU efficiency is a necessary condition for scalable video infrastructure, but it is not sufficient. Efficiency without orchestration concentrates risk. Orchestration is what converts hardware gains into system reliability.

The Hidden Pipeline

Modern video pipelines are no longer linear chains of discrete tasks. They are event-driven, multi-stage systems with dynamic, often unpredictable, behavior.

Ingest triggers processing. Processing fans out across encoding ladders and codecs. Outputs feed packaging and delivery. Monitoring loops feed back into scheduling, scaling, and retry logic. Each stage operates semi-independently, and each introduces its own failure modes, timing constraints, and resource requirements.

Newer architectures add further dynamism. Just-In-Time transcoding, for example, defers encoding until a viewer actually requests a stream, creating segments on demand rather than pre-encoding an entire catalog. Scalstrm’s JIT implementation supports H.264, HEVC, and AV1 in software and hardware (VPU), and VP9 in software, generating adaptive bitrate ladders in real time. The approach can reduce storage and compute consumption by up to 90 percent, but it also means that the pipeline’s workload is inherently unpredictable, shaped by viewer behavior rather than batch schedules.

Modern Video Pipeline: From Linear Chain to Event-Driven System

Exhibit 1: A modern video pipeline viewed as an event-driven system with control plane coordination.

 

In this environment, static configuration is insufficient. Control logic must respond continuously to queue depth, capacity availability, error rates, and downstream pressure. Without centralized visibility and intent-driven control, teams are forced to infer system behavior indirectly, debugging symptoms rather than directing outcomes.

The result is a pipeline that looks manageable on a whiteboard but behaves unpredictably under load. Failures appear upstream while their root causes hide downstream. Operators add compute to relieve congestion, only to discover they have made it worse by overwhelming a bottleneck further along the chain.

Orchestration as the Leverage Point

Once video infrastructure incorporates specialized compute such as VPUs, orchestration determines whether that efficiency is realized or wasted.

A capable control plane allows teams to allocate VPU capacity intentionally rather than opportunistically, balance workloads across heterogeneous resources, prevent overcommitment, and isolate failures before they cascade. It transforms scheduling from a mechanical task into a strategic function.

In practice, several operational patterns emerge when orchestration is treated as a first-class system component rather than an afterthought. Intent-based scheduling places workloads according to policy, not just availability. Graceful degradation lets systems shed load or reduce ladder complexity under pressure rather than crashing outright. Failure isolation ensures that individual pipeline stages can fail without collapsing the entire workflow. Capacity transparency gives teams real-time understanding of not just how much capacity exists, but precisely how it is being consumed.

Orchestration Maturity: From Manual Control to Intent-Driven Automation

Exhibit 2: The orchestration maturity model, from fragile manual control to resilient intent-driven automation.

These patterns are difficult to achieve through scripting or manual intervention. They require continuous coordination across pipeline stages, informed by real-time system state rather than static assumptions.

Where Scalstrm Fits

Scalstrm is a Stockholm-based streaming infrastructure company founded in 2017 by Ola Bengtsson and Patrik Alm, who bring 75 years of combined experience in media technology. The company now operates across 35 countries with 57 partner organizations, and its platform is used by operators including Telia (TV4, C More), Altibox, Tele2, and NEP Group.

Within the VPU Ecosystem, Scalstrm addresses the coordination problem directly. Rather than treating encoding, packaging, and delivery as isolated steps, the platform unifies them into four tightly integrated components: an Origin Platform for cloud-based tile recording and live stream management, a CDN Platform with a real-time programmable HTTP pipeline for content delivery, the Just-In-Time Transcoding engine described earlier, and an Origin Shield that provides content-aware caching across RAM, NVMe, and disk tiers.

The architecture is built on what Scalstrm calls a scalable micro-component model. Each component can be deployed and scaled independently across on-premises, private cloud, public cloud, or hybrid environments. This modularity matters because it allows the control plane to manage heterogeneous infrastructure as a single system rather than a collection of disconnected services.

At the hardware level, the numbers are concrete. A single server running Scalstrm’s Origin Platform can manage up to 800 adaptive bitrate channels while pushing 200 Gbps of egress. The transcoding layer integrates with CPU, GPU, and dense VPU architectures, including NETINT Quadra T1U units, supporting HEVC encoding across SD, HD, and 4K resolutions. New live channels can be launched in seconds through instant scaling, with operators paying only for active capacity.

Decisions about placement, retries, and prioritization are informed by real-time system state. When a VPU node reaches its encoder session limit, the control plane deprioritizes it and redistributes work. When a downstream packaging service slows, backpressure is applied automatically to upstream stages rather than allowing queues to grow unchecked. The Origin Shield layer adds a further coordination point, automatically identifying and protecting live streams, catch-up TV, and network PVR content with redundancy for uninterrupted service.

Scalstrm treats all compute resources as abstract execution targets, exposing hardware capabilities through normalized metrics. This allows scheduling decisions to be made based on actual performance characteristics rather than static labels, keeping orchestration hardware-agnostic while still optimizing for throughput, energy efficiency, and cost per processed hour.

The Failure Equation

Even with strong orchestration, video systems remain complex. Teams must still manage imperfect observability, evolving workload characteristics, and external dependencies such as networks and third-party services. These challenges do not disappear.

What changes is how failures are experienced. Two failure modes are especially common and consistently underestimated.

The first is silent performance degradation from partial resource exhaustion. Unlike complete node failures, conditions such as VPU encoder session limits being reached, CPU thermal throttling under sustained load, or memory pressure causing increased I/O wait do not trigger immediate alarms. In un-orchestrated pipelines, jobs continue to flow to affected nodes, processing times drift upward, and SLAs are missed without a clear root cause. Operators often misdiagnose the issue as bad content or temporary load.

The second is cascading backlogs caused by downstream bottlenecks. When packaging services, storage endpoints, or CDN ingest connections slow down, an un-orchestrated system keeps producing output at full speed. Queues grow invisibly. Failures surface upstream, far from the real problem. Operators respond by adding more compute, which only deepens the congestion.

Failure Response: The Orchestration Difference

Exhibit 3: How orchestration transforms failure response across five critical dimensions.

With coordinated control, both patterns are handled differently. Scalstrm’s platform continuously monitors resource health through its WebUI dashboard, providing real-time metrics and analytics across every pipeline stage. Degraded nodes are automatically deprioritized, and backpressure is applied when downstream systems falter. The auto-scalable architecture dynamically allocates resources based on real-time traffic, eliminating the need for operators to guess at capacity during demand spikes. Instead of cascading outages, teams encounter bounded incidents with clearer signals, controlled impact, and defined recovery paths.

THE BIGGER PICTURE
Orchestration does not eliminate failures. It converts unknown unknowns into known, bounded risks. The distinction between feeling brittle and feeling resilient is not about the absence of problems. It is about the presence of predictable, controlled responses

Economics Follow Control

Operational efficiency and economic efficiency are inseparable in video infrastructure.

Without orchestration, capacity is stranded across underutilized nodes, peaks are overprovisioned because there is no mechanism to redistribute load dynamically, and failures generate hidden costs through retries and reprocessing. Efficiency gains from VPU hardware erode quietly, diluted by the operational overhead of running an uncoordinated system.

With coordinated control, the gains compound. Scalstrm reports that its live transcoding layer delivers 50 percent savings per channel compared to conventional architectures, while requiring 75 percent less server footprint and 80 percent less power consumption. These numbers reflect what becomes possible when orchestration ensures that workloads are placed where capacity actually exists, rather than distributed across partially utilized or thermally constrained nodes.

The sustainability dimension is increasingly difficult to ignore. At 80 percent lower energy consumption and a corresponding reduction in carbon footprint, the economic case and the environmental case converge. Organizations operating at scale cannot separate cost-per-stream from watts-per-stream indefinitely.

In this sense, orchestration is not an operational luxury. It is an economic multiplier. The return on investment in VPU hardware is directly proportional to the quality of the control plane that manages it.

Four Questions That Reveal Readiness

Teams evaluating their readiness to operate VPU-accelerated video pipelines at scale should begin with four questions. If these questions prove difficult to answer, efficiency gains alone will not translate into operational confidence.

First: can you see where every job is running and why? If the answer requires checking multiple dashboards, querying separate systems, or asking a colleague, the pipeline lacks the visibility that coordinated control provides.

Second: can you change scheduling behavior without redeploying the pipeline? If policy changes require code modifications and release cycles, the system cannot respond to operational realities at the speed they demand.

Third: can individual stages fail without failing the workflow? If a single component failure triggers cascading impact across the entire pipeline, the system lacks the isolation that resilient architectures require.

Fourth: can you explain capacity usage in real time? If utilization is only understood in retrospect, through post-incident analysis or monthly reports, the team is operating reactively rather than proactively.

Closing Perspective

As video infrastructure evolves, performance improvements increasingly come from how systems are controlled, not just how fast individual components run.

VPUs make video processing efficient. Platforms like Scalstrm make that efficiency usable. Together, they represent a shift in how the industry thinks about scale: not as a problem of raw throughput, but as a problem of coordination, visibility, and control. The fact that a platform born in Stockholm now orchestrates video infrastructure across 35 countries suggests the market has arrived at the same conclusion.

The organizations that navigate this transition successfully will be those that recognize orchestration not as an operational add-on, but as the foundational layer that determines whether their infrastructure scales with confidence or collapses under its own complexity.

This article is part of the VPU Ecosystem series exploring how purpose-built silicon is reshaping video infrastructure across the technology stack. Each article examines a different architectural perspective through the lens of a partner within the ecosystem.

 

ACCESS NOW:  ASIC-Based Transcoding
for High-volume Use Cases
Including social media, broadcast, interactive platforms, and service providers

ACCESS NOW

Cloud services are an effective way to begin live streaming. Still, once you reach a particular scale, it’s common to realize that you’re paying too much and can save significant OPEX by deploying transcoding infrastructure yourself. The question is, how to get started?

NETINT’s Build Your Own Live Streaming Platform symposium gathers insights from the brightest engineers and game-changers in the live-video processing industry on how to build and deploy a live-streaming platform.

In just three hours, we’ll cover the following:

• Hardware options for live transcoding and encoding to cut costs by as much as 80%.
• Software options for producing, delivering, and playing your live video streams.
• Co-location selection criteria to achieve cloud-like performance with on-premise affordability.

You’ll also hear from two engineers who will demystify the process of assembling a live-streaming facility, how they identified and solved key hurdles, along with real costs and performance data.

NOW AVAILABLE ON DEMAND: https://netint.com/symposium-on-building-your-live-streaming-cloud/

Cloud? Or your own hardware?

It’s clear to many that producing live streams via a public cloud like AWS can be vastly more expensive than owning your hardware. (You can learn more by reading “Cloud or On-Premises? The Streaming Dilemma” and “How to Slash CAPEX, OPEX, and Carbon Emissions Using the NETINT T408 Video Transcoder”).

To quote serial entrepreneur David Hansson, who recently migrated two SaaS services from the cloud to on-premise, “Don’t let the entrenched cloud interests dazzle you into believing that running your own setup is too complicated. Everyone and their dog did it to get the internet off the ground, and it’s only gotten easier since.”

For those who have only operated in the cloud, there’s fear of the unknown. Fear buying hardware transcoders, selecting the right software, and choosing the best colocation service. So, we decided to fight fear with education and host a symposium to educate streaming engineers on all these topics. 

“Building Your Own Live Streaming Cloud” will uncover how owning your encoding stack can slash operating costs and boost performance with minimal CAPEX.

Learn to select the optimal transcoding hardware, transcoding and packaging software, and colocation facilities. We’ll also discuss strategies to reduce carbon emissions from your transcoding engine.

This FREE virtual event takes place on August 17th, from 11:00 AM – 2:15 PM EST.

Five issues tackled by nine experts:

Transcoding Hardware Options:

Learn the pros and cons of CPU, GPU, and ASIC-based transcoding via detailed throughput and cost examples shared by Kenneth Robinson, Manager of Field Application Engineers at NETINT Technologies. Then Ilya Mikhaelis, Streaming Backend Tech Lead at Mayflower, will describe his company’s journey from CPU to GPU to ASICs, covering costs, power consumption, latency, and density metrics.

Software Options:

Jan Ozer from NETINT will identify the three categories of transcoding software: multimedia frameworks, media servers, and other tools. Then, you’ll hear from experts in each category, starting with Romain Bouqueau, founder of Motion Spell, who will discuss the capabilities of the GPAC multimedia framework. Barry Owen, Chief Solutions Architect at Wowza, will discuss Wowza Streaming Engine’s suitability for private clouds. Lastly, Adrian Roe, Director at Id3as, developer of Norsk, will demonstrate Norsk’s simple, scripting-based operation, and extensive production and transcoding features.

Housing Options:

Once you select your hardware and software, the next step is finding the right co-location facility to house your live streaming infrastructure. Kyle Faber, with experience in building Edgio’s video streaming infrastructure, will guide you through the essential factors to consider when choosing a co-location facility.

Minimizing the Environmental Impact:

As responsible streaming professionals, it’s essential to address the environmental impact of our operations. Barbara Lange, Secretariat of Greening of Streaming, will outline actionable steps video engineers can take to minimize power consumption when acquiring and deploying transcoding servers.

Pulling it All Together:

Stef van der Ziel, founder of live-streaming pioneer Jet-Stream, will share lessons learned from his experience in creating both Jet-Stream’s private cloud and cloud transcoding solutions for customers. In his closing talk, Stef will demystify the process of choosing hardware, software, and a hosting facility, bringing all the previous discussions together into a cohesive plan.

Full Agenda:

11:00 am. – 11:10 am EST

Introduction (10 minutes):
Mark Donnigan, Head of Strategic Marketing at NETINT Technologies
Welcome, overview, and what you will learn.

11:10 am. – 11:40 am EST

Choosing transcoding hardware (30 minutes):
Kenneth Robinson, Manager of Field Application Engineers at NETINT Technologies
You have three basic approaches to transcoding, CPU-only, GPU, and ASICs. Kenneth outlines the pros and cons of each approach with extensive throughput and CAPEX and OPEX examples for each.

11:40 am. – 12:00 pm EST

From CPU to GPU to ASIC: Our Transcoding Journey (20 minutes):
Ilya Mikhaelis, Streaming Backend Tech Lead at Mayflower
Charged with supporting very high-volume live transcoding operations, Ilya started with libx264 software transcoding, which consumed massive power but yielded low stream density per server. Then he experimented with GPUs and other hardware and ultimately transitioned to an ASIC-based solution with much lower power consumption and much higher stream density per server. Ilya will detail the costs, power consumption, and density of all options, providing both data and an invaluable evaluation framework.

12:00 pm. – 12:10 pm EST

Choosing your live production software (10 minutes): 
Jan Ozer, Senior Director of Video Technology at NETINT Technologies
The core of every live streaming system is transcoding and packaging software. This comes in many shapes and sizes, from open-source software like FFmpeg and GPAC, to streaming servers like Wowza, and production systems like Norsk. Jan discusses these multiple options so you can cohesively and affordably build your own live-streaming ecosystem.

12:10 pm. – 1:10 pm EST

Speed Round (60 minutes):
20-minute presentations from GPAC, Wowza, and NORSK.
Speakers from GPAC, Wowza, and NORSK discussing the features, functions, operational paradigms, and cost structure of their live software offering.

Speakers include:

• Adrian Roe, CEO at id3as, Product: Norsk, Title: Make Live Easy with NORSK SDK
• Romain Bouqueau, Founder and CEO, Motion Spell (home for GPAC Licensing), Product: GPAC Title of Talk: Deploying GPAC for Transcoding and Packaging
• Barry Owen, Chief Solutions Architect at Wowza, Title of Talk: Start Streaming in Minutes with Wowza Streaming Engine

1:10 pm. – 1:40 pm EST

Choosing a co-location facility (30 minutes): 
Kyle Faber, Senior Director of Product Management at Edgio.
Once you’ve chosen your hardware and software, you need a place to install them. If you don’t have your own connected data center, you may consider a colocation facility. In his talk, Kyle addresses the key factors to consider when choosing a co-location facility for your live streaming infrastructure.

1:40 pm. – 1:55 pm EST

How to Greenify Your Encoding Stack (15 minutes):
Barbara Lange, Secretariat of Greening of Streaming.
Learn how video streaming companies can work to significantly reduce their energy footprint and contribute to a greener streaming industry. Implement hardware and infrastructure optimization using immersion cooling and data center design improvements to maximize energy efficiency in your streaming infrastructure.

1:55 pm. – 2:15 pm EST

Closing Keynote (20 minutes):
Stef van der Ziel, Founder Jet-Stream
Jet-stream has delivered streaming solutions since its launch in 1994 and offers its own live streaming platform. One focus has been creating custom transcoding solutions for customers seeking to create their own private cloud for various applications. In his closing talk, Stef will demystify the process of choosing hardware, software, and a hosting facility and wrap a pretty bow around all previous presentations.

REGISTER NOW & WATCH ON-DEMAND!