Swapping the Engine While It Runs | How Video Platforms Introduce Hardware Acceleration Without Breaking Production

Swapping the engine while it runs sounds risky - and in production video systems, it is.

Hardware acceleration often gets positioned as “faster encoding,” but that’s not what makes engineering teams hesitate. The real challenge is introducing a new compute model without breaking workflows that already carry years of integrations, monitoring, and operational assumptions. As NAB approaches and the industry talks density and efficiency, the more important question is this: how do you evolve a platform without increasing fragility?

Leo Nieto from NETINT sits down with Dominique Vosters from Scalstrm to unpack what actually triggers the shift away from CPU-only scaling. The answer is less about technology hype and more about cost per stream across the full workflow, from transcoding through packaging and delivery. We explore why teams hesitate, what they are most concerned about breaking, and why live streaming raises the stakes compared to VOD.

We also get practical about architecture. Dominique explains how hardware acceleration fits into a broader system, where VPUs handle encoding while software layers manage resilience, synchronization, and recovery. From the outside, workflows often remain consistent. The real changes happen inside the system, where compute is relocated rather than the architecture being rebuilt.

Finally, we walk through a low-risk rollout approach: parallel environments, staging validation, and gradual channel-by-channel migration instead of big bang transitions.

If you are planning hardware-accelerated transcoding, VPU-based encoding, or broader video workflow optimization, this conversation will help you improve efficiency while protecting production stability.

Key topics covered

• why CPU-based video workflows become unsustainable primarily due to cost pressure across transcoding, packaging, and delivery
• why hesitation around hardware acceleration comes from fear of disrupting production systems, not skepticism about the technology
• differences between VOD and live streaming workflows, and why live environments require more cautious rollout strategies
• how hardware acceleration fits into existing architectures, with software layers handling resilience, synchronization, and recovery
• what actually changes when acceleration is introduced versus what remains stable for operators and workflows
• the concept of “swapping the engine while it runs” by keeping input and output behavior consistent while moving compute inside the system
• when orchestration layers add value and how that depends on platform maturity and scale
• practical deployment strategies including parallel environments, staging validation, and gradual channel-by-channel migration

Stay tuned for more in-depth insights on video technology, trends, and practical applications. Subscribe to Voices of Video: Inside the Tech for exclusive, hands-on knowledge from the experts. For more resources, visit Voices of Video.

Transcript

Why Acceleration Is Architectural

Voices of Video 0:07

Voices of video. Voices of video. Voices of video. Voices of video.

Anita Flejter 0:17

Welcome to Voices of Video. As we get closer to NAB, a lot of the industry conversations center around acceleration. Faster encoding, higher density, lower cost per stream. Those things matter, but for engineering teams, the more important question is not whether hardware acceleration works, but whether you can introduce it without disrupting everything else that already works. Like most things in technology or even life, video platforms are not greenfield environments. They've evolved over time, they carry integrations, operational habits, monitoring layers, and assumptions, often based under a different compute model. So introducing acceleration is not just a performance decision, it's actually an architectural decision. Today we're joined by Dominique Vosters from ScaleStream. Dominic brings more than two decades of experience across broadcast networking and large scale deployment. He has worked from proof of concept through integration and production rollout, translating technical challenges into something that teams can actually operate. Moderating today's discussion is Leonardo Nito, Director of Market Development for IMIA at NetInt. Leo approaches these conversations from the market side, surfacing deployment tensions and assumptions that teams don't always say out loud. Dominique, welcome. Leo, over to you.

When CPU Scaling Stops Working

Leo Nieto, NETINT 1:54

Thank you, Anita. Nice to have you, Dominic. It's always nice to have this discussion with every audience. So now let's just deep dive. I think people's times are precious. So you know, uh when CPU only stops scaling. Dominic, one pattern I see across the market is that teams rarely start by asking uh for hardware acceleration. They start by trying to extend uh what they already have or what they already built. You know, they add more CPU instances, you know, they tune presets and they stretch what you know they have already built within their own infrastructures. Uh then things change. We can start by asking from your perspective, what typically triggers the moment when CPU only workflows stop feeling sustainable?

Fear Of Breaking Production

Dominique Vosters, Scalstrm 2:46

Yeah, I what we noticed uh lately um with with our customers is that yeah, cost is uh mainly a driver. We see it more and more in uh different parts of uh the ecosystem, uh, from uh transcoding, packaging, uh the whole flow more or less. So customers are becoming much much more uh cost uh aware. And yeah, then of course, I when when they they come to us and uh yeah on the origin we've already proven to be cost effective. Um and since uh yeah two years we also launched uh transcoding. Um and also there we we want to do the same uh cost savings. And then one way that we can realize this is by using uh the net in uh VPU hardware accelerated cards. And uh I with these cards we can definitely do cost savings. So I from our point of view, um what we see with our customers is that the the discussion is not necessarily CPU VPU driven, it's mainly cost-driven. Um, and then of course, yeah, if if if you make the calculation based on uh CPU versus VPU, yeah, it is quite quickly tilts over to uh to the VPU card. So um yeah, and then of course, uh the typically they're already running on uh CPU, so it's not mainly uh extending what they have on CPU, but mainly building uh a VPU uh system uh in parallel next to it. That that's that's what we mainly see as uh as a driver from beyond interesting.

Leo Nieto, NETINT 4:17

Um you know when we speak uh with these platform teams, you know, hesitation really comes from I guess like uh skepticism uh about acceleration itself. Uh I think it it comes more from fear or disruption. As you mentioned, you know, customers are are cost conscious. People are running CPUs, VPUs. I mean, maybe that's not the center point of it. But I do feel sometimes that um when people are trying to change something, especially if it's you know very performant and it takes a lot of boxes, there's always this hesitation uh to change, hence you know, fear of disruption. I think you know it's natural for for any human just to oh, maybe we're doing something a little too different. When customers hesitate, what do you think they are most afraid of breaking inside their existing workflows?

Dominique Vosters, Scalstrm 5:12

So yeah, I typically uh it depends a bit on which flow. Uh if you're in the the video uh on demand flow, yeah, it is less critical, definition critical, because uh you do the transcoding offline, then put the content on uh the storage. Um so there I think the the part is is less critical. Of course, in in the live stream, yeah, it's it's it's quite critical. Um so there they are always a bit uh a bit more careful uh and don't want to interfere with with what they have uh too much. Um but there I think it's important to have a good system around it. So I you always have the engine, uh in this case uh the VPU card, and then it's it's about uh the vendor what you do with it. Where we invested uh a lot of effort from our time uh from development in is making uh a rock solid uh solution from from the input stream till uh till the player, let's say, um like uh resilience, synchronization, frame loss, repair. Um so I just that you just to make sure that you have an end-to-end uh resilient flow. Um and then what technology is behind it. I we use the VPU for the hardware acceleration part, but we built uh a software layer around it to make it uh resilient and then rock solid for the end customer. And then this is what the customers really like because I it's it's uh yeah, they need to have reliability and they need to have a system that works. Um and of course, I if they can rely on uh on the VPU hardware acceleration, they can save costs. Also, the uh the performance they can get out of it, but that they they look more as a as a at a total solution, um, and that's where we try to be as less disruptive as possible. Um with the technology behind it, it's quite disruptive. But from the end, customer point of view, they don't really see it as disruptive in that sense.

What Changes Versus What Stays

Leo Nieto, NETINT 7:09

That's disruptive, right? You guys make it a little bit smoother so that you know exactly. They don't we don't mention the the the ugly D-word, but it's like no, look, we can do changes. And I guess uh what you're really about is to provide that architectural stability. Of course, performance and other things, they they have to come because that's that's the promise uh of the objective or what what we're doing. But uh let's clarify what actually changing changes in practice because this is this is very interesting. There is often confusion between you know workflow logic and uh compute location. Uh, from a practical standpoint, when acceleration is introduced, what truly changes and what usually remains surprisingly consistent?

Dominique Vosters, Scalstrm 7:49

Um yeah, I don't know, different customs. So either they go uh I let's say in the cloud uh or they stay on-prem. Uh typically that doesn't really change uh by using uh the existing CPU or the new VPUs. I so nothing really changes on that. Um so if they're running in in a cloud environment, uh we can offer it to Vacamai Cloud in the cloud as well. If they stay on-prem, then then of course we can stay it on-prem. And then for the rest, yeah, I on the the the flow as such, we try to be yeah, have a have a system that that can do it, can do it all, let's say. Uh we can do the monitoring, we can do the analytics, um, we can do the uh reliability, the redundancy. So I from from the customer point of view, not that much will change in in that flow. Uh or we at least we try uh not to change too much.

Leo Nieto, NETINT 8:45

So if um it would be fair to say that most of the workflow remains intact. Um does the change uh you know the change is primarily about where the compute is executed?

Dominique Vosters, Scalstrm 8:56

Um yeah, again, but but I that's a bit transparent uh because we get uh we get an input feed. Um then on our side we do the I depending on the stream, we do the de-interlacing, we do the decoding, then we feed the frame to the to the VPU card that does the transcoding for us, then we get the frame back, and then we do all the intelligence uh like synchronization, uh alignment, uh frame repair. So I that's that's again done in software on our end. So if you take from uh the beginning, the input stream and output stream, uh in our case the transcoding feeds it to the origin, and the origin feeds it to the to the CDN. Um but the magic happens inside the box. Um but from the the customer point of view, yeah, it's kind of swapping boxes. Um so they have an existing CPU with an input stream and an output stream. Um typically uh I usually they have a transcoder or an encoder uh and uh a known packager or a third-party packager. In our case, yeah, we just uh replace the box. We we have our own transcoding solution combined with uh the origin packaging, where the combined uh solution uh the magic happens. And then for them it's more or less swapping boxes uh in the in that in that case.

Platform Versus Direct Integration

Leo Nieto, NETINT 10:18

In a sense, right. Hence, you know, the stability that it's offered. You know, some teams introduce acceleration directly into their into their pipeline, uh while others rely on an orchestration layer to manage that complexity. Um, in your experience, does every deployment require a platform approach, or does that depend on maturity and scale?

Dominique Vosters, Scalstrm 10:42

Yeah, that that depends a bit on the customer. I we we can manage uh both. Um so we we kind of adapt what the customer requires, which is not something we we have force. Um so this is where we we follow the customer mainly.

Leo Nieto, NETINT 10:59

And at what point does the operational overhead or or direct integration begin to a road, uh architectural stability?

Dominique Vosters, Scalstrm 11:06

Yeah, I think this is a critical point because I as as we go back to the beginning, being disruptive and uh replacing a system to uh a new system, hardware accelerated in this case, there you have to make as a solution provider, uh Skill Streep in this case, the road or the migration as smooth as possible. Because yeah, I if you just need to swap and you need to need to change the whole flow, yeah, customers are really reluctant uh to do that. So the the the smoother you can make this uh operation, the better, I would say. And then yeah, one of our uh key differentiators uh both on origin and on scoding, I think the whole solution is yeah, the performance uh we mentioned in the beginning, but also the uh the ease of use. So I we we we have made our platform quite intuitive that it's uh yeah more or less plug-and-play to to insert a new solution. Um I we have uh concepts like publishing points where they can uh match the existing URL. We have adaptations where we can uh map uh the same stream to 10 different players in in different formats. Um also creating a channel uh involving or introducing the VPU hardware acceleration part for the transcoding. Yeah, this is all quite intuitive. Um and then yeah, of course, it depends a bit on the complexity of the existing system, but we try to make it as much plug-and-play as we can.

Leo Nieto, NETINT 12:37

Which brings us to you know real operational questions. Like in in conversations we've had with teams, the hesitation is rarely technical. It seems that it's mostly operational. And they ask, uh, how do we introduce this without destabilizing production? From what you have seen, what does a sensible low-risk rule rollout actually look like in practice?

Dominique Vosters, Scalstrm 12:59

Yeah, I since it's uh I for the Vault flow, it's it's less critical. Um, so I this is something you can can easily build in parallel, activate once it's up and running. A live flow, of course, yeah, this is this is uh much more critical. So typically this is built uh aside it in uh first a test environment and a staging environment. Um once it uh has proven itself, then channel per channel is taken into production. Um so I on on the live side, customers are a bit uh bit uh more careful, I would say. Um Big Bang scenarios are uh rarely done in these cases. So it's mainly uh the solution is to prove itself in a staging environment, uh, and then gradually, channel by channel, then moved into uh production. And this is makes it also uh quite I guess it gives a good overview for the operational team to see what's what's happening. Um on our part, um, since it's all microservices, we can even do the staging and production on the same machine. Um so that's that's also something that we we often do is that um we have let's say the staging and the production system all running on the same hardware, and that it's just a matter of uh yeah, feeding the ingest uh to the right uh process, let's say.

Leo Nieto, NETINT 14:23

Do you see teams with feed more often when they treat acceleration as incremental rather than transformational? Not a yes or no answer, but uh maybe maybe something just to, you know, it's it's an opinion, it's never a right or wrong answer.

Dominique Vosters, Scalstrm 14:35

I'm not sure if if customers uh try to pick one of the two. Um for them it's mainly like all it's objective to either one of them. Yeah, yeah, indeed. And then for them, yeah, it needs to work. That's that's that's the first thing. Um the migration needs to go smooth and then uh as cost efficient as possible. And then then if one tilts to to one or the other. Yeah, I I don't know.

Closing Takeaways And NAB Invite

Leo Nieto, NETINT 15:04

I I'm I'm not not sure if you're no it's it's not I think the answer is there, it's neither it's it's not uh something that one can pick, but rather something that you know one has to confront in a way. Yeah, and obviously, you know, as things as technologies uh you know keep evolving and they look very cool, etc. You know, the the goal is really not disruption, it's more controlled evolution. And I guess uh architectural stability is preserved uh when change is introduced gradually with measurable boundaries and of course low risks for ongoing operations. Correct. Um what stands out to me in this discussion is that hardware acceleration is primarily an architectural decision, not necessarily a performance upgrade. Uh, teams succeed when they recognize that most of the workflow can remain stable, and that the real work lies in managing compute placement, orchestration, and rollout discipline. Thank you, Dominique. Thank you. This was a practical and grounded uh discussion uh in real deployment experience. We will be at NAB. We can continue these discussions down the line. Uh we welcome anybody just to come and discuss with us. This is by no means, you know, uh necessarily a commercial effort. This is more, you know, uh a meeting of minds. Thank you so much so much for joining us, Dominic.

Dominique Vosters, Scalstrm 16:20

Yeah, happy to. And uh let's uh connect uh at NAB or before, of course. Or before indeed.

Anita Flejter 16:27

That was a great conversation, Dominique. I appreciate how clearly you frame this as an architectural adjustment, not a system replacement. Acceleration only becomes valuable if it strengthens the system without destabilizing it. Leo, thank you for grounding this in the real questions teams ask before committing to change. As we head into NAB, there will be a lot of discussion around density and efficiency. Those metrics matter, but as we said, for engineering teams, the more important question is this can you evolve your system without increasing fragility? Because growth has a way of exposing weak assumptions very, very quickly. And let's be honest, in production, stability will always matter more than peak numbers. Thanks for joining us on Voices of Video. We'll see you at the next episode.

Voices of Video 17:22

This episode of Voices of Video is brought to you by Netting Technologies. If you are looking for cutting edge video encoding solutions, check out Netint products at netint.com.