AIOZ Stream Explained: Decentralized Video Infrastructure

Most explanations of video streaming treat it as one step: you upload a file, someone else watches it. In practice a video goes through several distinct stages before it ever reaches a screen, and each stage is where a decentralized platform like AIOZ Stream actually differs from a traditional CDN. This is a walk through what happens between ingest and playback on AIOZ Stream specifically, not a generic "how streaming works" overview.

TL;DR:

• AIOZ Stream ingests a video, transcodes it into multiple resolution and bitrate renditions, then stores those renditions on the same decentralized network that delivers them.
• Playback quality gets adjusted per viewer based on real conditions, not a fixed setting.
• Storage and delivery are not two separate systems bolted together, they are the same network.

What happens between upload and playback

Five things happen to a video before someone watches it: ingest, transcoding, storage, delivery, and quality monitoring. On most platforms these are handled by different vendors stitched together. On AIOZ Stream they run on one combined network, which changes what each stage actually looks like in practice.

Ingest and transcoding: turning one file into many renditions

A single uploaded file is not what gets served to viewers. AIOZ Stream's media API transcodes an upload into a set of renditions at different resolutions and bitrates, using H.264 (up to 4K) or H.265/HEVC (up to 8K) depending on the target quality and device compatibility. This matters because a viewer on a phone over 4G and a viewer on a fiber connection watching on a TV should never receive the same file. Choosing between H.264 and H.265 for a given rendition isn't arbitrary either: H.264 decodes on essentially every device made in the last decade without hardware acceleration concerns, while H.265 compresses the same picture into roughly 30-50% less data at equivalent quality, at the cost of needing newer hardware decode support to play back efficiently. That's why AIOZ Stream supports both rather than picking one, a rendition aimed at an older Android device benefits from H.264's universal compatibility, while a 4K rendition aimed at a modern TV or fiber-connected desktop can lean on H.265's smaller file size without a playback risk. Chunking the output into short segments, packaged as an HLS or DASH manifest, is what lets a player switch between renditions mid-playback instead of committing to one quality for the whole video. Practically, this also means a viewer can seek to the middle of a long video without downloading everything before that point, since the player only has to fetch the specific segments covering the timestamp they jumped to, not the whole file in sequence. Transcoding a single upload into this full set of renditions and segments takes real compute time proportional to the source file's length and target resolutions, which is why AIOZ Stream's developer API reports transcoding status as an asynchronous job rather than something that completes the instant an upload finishes.

Adaptive bitrate: matching quality to the connection, not the file

Adaptive bitrate streaming is the mechanism that picks which rendition a viewer's player requests, moment to moment, based on measured bandwidth and buffer health. A good ABR implementation also has to avoid overcorrecting: switching resolution every few seconds because of a brief network blip is worse than holding steady through it, since a viewer notices frequent quality jumps far more than they notice a slightly lower but stable picture. That stability requirement is why ABR logic typically watches trends across several segments rather than reacting to any single slow download. That stability question, along with how "good enough" playback is actually measured, is worth its own detailed treatment; AIOZ Stream's QoE breakdown covers the metrics side of this in more depth than this overview does.

Where the video actually lives: decentralized storage

Once transcoded, renditions need somewhere to live between the moment they are created and the moment someone requests them. A traditional setup stores files in a data center and serves them from separate CDN edge nodes, which means storage and delivery are two systems that have to agree with each other about a file's status. AIOZ Stream's renditions are stored on the same network that delivers them. That is a structural choice, not an implementation detail, and it is why there is no separate storage vendor to reconcile with the delivery layer in the first place. A single point of failure in a centralized data center also means a single point of failure for every video stored there; distributing that storage across independently operated nodes removes that specific failure mode, at the cost of depending on the network's own redundancy instead of one company's infrastructure guarantees. The nodes doing this work are real and counted: AIOZ's own network dashboard reports over 327,000 total DePIN nodes contributing storage, compute, and delivery capacity as of this writing, not a fixed number of company-owned data centers. For the mechanics of how that node network is structured and rewarded, see our breakdown of AIOZ DePIN.

Delivery: HLS today, with low-latency work tied to the live roadmap

For on-demand video, which is what AIOZ Stream supports today, HLS is the delivery protocol doing the work: segmented files requested over standard HTTP, cacheable at any node that has already fetched them. HLS trades a few seconds of startup and rebuffer-recovery latency for that simplicity and reach, which is the right tradeoff for on-demand content where nobody is watching the exact same second as anyone else. The caching part matters more than it sounds: because each segment is a plain HTTP file at a fixed URL, once one node on the network has fetched a given segment for one viewer, that same segment is already available for the next viewer requesting it, without re-fetching it from wherever it was originally stored. That's the same caching behavior any HTTP CDN relies on, just running across independently operated nodes instead of one company's edge servers. Lower-latency delivery is more relevant to live, interactive streaming than to on-demand playback, and AIOZ Stream's live streaming feature is not yet available at the time of this article. There's a real middle ground worth knowing about ahead of that: Low-Latency HLS keeps HTTP-based delivery but cuts glass-to-glass latency from HLS's usual 15 to 30 seconds down to roughly 2 to 5 seconds, without needing to switch to a fully different protocol like WebRTC. We cover the mechanics of how it does that in our LL-HLS explainer, and the full definition of glass-to-glass latency itself, camera to screen, in this deeper piece. Once AIOZ Stream's live feature ships, which of these approaches it actually uses will be worth a dedicated, verified writeup rather than a guess made ahead of launch.

Quality monitoring: knowing whether playback was actually good

None of the above matters if nobody is checking whether it worked. AIOZ Stream's player reports startup time, rebuffer events, and the bitrate actually delivered, which is what lets the ABR logic make its next decision instead of guessing. These signals feed a composite quality model rather than getting reported in isolation, weighing perceived picture quality against rebuffer and startup penalties, then adjusting for how stable the session stayed over time. A high average bitrate with frequent interruptions scores worse under that model than a steadier, more modest one, which matches what actually frustrates viewers in practice, not just what looks best on a spec sheet. AIOZ Stream's own documented starting targets give a sense of what "good" actually means in numbers rather than just intent: startup to first frame under roughly 2 seconds for short-form content, and a rebuffer ratio under roughly 0.5 to 1.0%, tracked at the 95th percentile rather than just the average, since a healthy average can still be hiding a meaningful tail of bad sessions behind it. This is also the part of the pipeline most explainers skip entirely, because "the video played" and "the video played well" are different claims, and only one of them is measurable after the fact without this kind of telemetry.

Where to go deeper

This overview intentionally stays at the level of what happens and why, without fully unpacking any single stage. Each stage above has its own deeper treatment if you need it: the network architecture behind storage and delivery in What Is AIOZ DePIN, latency specifically in Low-Latency HLS and Glass-to-Glass Latency Explained, and what all of this actually costs to run in our pricing breakdown.

Frequently Asked Questions

Do I need to manage transcoding myself before uploading to AIOZ Stream?
No. Upload the source file and AIOZ Stream's media API generates the resolution and bitrate renditions from it.

Does AIOZ Stream support both H.264 and H.265?
Yes. H.264 is supported up to 4K, and H.265 (HEVC) up to 8K, chosen per rendition based on target quality and device compatibility.

Is storage separate from delivery on AIOZ Stream?
No. Both run on the same underlying network, which is the main structural difference from a traditional setup where a storage vendor and a CDN are two separate systems.

Can I use WebRTC for low-latency delivery on AIOZ Stream today?
Not yet. Low-latency, interactive delivery is tied to the live streaming feature, which has not shipped as of this article. On-demand delivery today runs on HLS.

Why does AIOZ Stream use HLS instead of a lower-latency protocol for on-demand video?
Because nobody watching on-demand video is watching the exact same second as anyone else, so the few seconds of extra startup latency HLS trades for simplicity and wide device support does not cost anything a viewer would notice.

How many nodes actually make up this network?
AIOZ's own network dashboard reports over 327,000 total DePIN nodes as of this writing, contributing storage, compute, and delivery capacity across the wider AIOZ Network, not a Stream-specific subset of that figure.

Related Reading

• WebRTC Mesh vs SFU vs MCU: the interactive, many-to-many use case this topology question applies to, versus today's one-to-many HLS delivery
• What Is a CDN Edge Node: how content actually gets cached and served once it reaches an edge node
• What Is DRM and Do You Need It: what content-protection options actually exist today versus what DRM would require
• One DePIN, Three Workloads: why storage, compute, and streaming on one network changes the architecture
• What Is AIOZ DePIN: the node network behind storage and delivery
• What Is Low-Latency HLS: how LL-HLS cuts glass-to-glass latency without switching protocols entirely
• Glass-to-Glass Latency Explained: what the term actually measures and how to measure it yourself
• AIOZ Stream Pricing: what storage, delivery, and transcoding actually cost
• AIOZ Stream vs Livepeer vs Theta: what's actually different across the three networks

References

• HTTP Live Streaming (HLS) specification, Apple Developer: the protocol reference for how HLS segments and manifests work
• Video Streaming APIs: What Developers Actually Need to Know, Mux: general background on transcoding and delivery API design