How to Encode 4K/8K Video via the API: H.264 vs H.265

The bitrate ladder article covered AIOZ Stream's 8-rung ladder in the abstract, 240p up through 4320p. This is the part that actually matters when you're the one calling the API: how a specific resolution and codec get requested, and why H.265 isn't a style preference once you're past 4K, it's the only option the platform allows.

TL;DR:

• Resolution and codec are set per output in a qualities array on video creation, each entry carrying its own resolution and a nested video_config.codec field.
• Valid resolutions run 240p through 4320p (8K); valid codecs are h264 and h265. AIOZ's docs cap H.264 at 4K, so any 4320p output must use h265.
• H.265's real-world efficiency advantage over H.264 averages around 44% less bitrate at equal VMAF, per independent testing, close to the ~50% figure Fraunhofer HHI (a co-developer of the HEVC standard) originally targeted, though actual savings vary by resolution and content.
• 8K has roughly 16 times the pixels of 1080p and 4 times the pixels of 4K, arithmetic worth knowing before assuming 8K support means 8K is a reasonable default.
• A /media/cost endpoint returns a real price estimate before you commit to a set of qualities, worth calling before, not after, encoding a large file at multiple resolutions.

The qualities array: how resolution and codec actually get requested

Codec and resolution aren't separate top-level settings, they live inside a qualities array passed when a video is created, one object per output rendition. Each object needs a resolution string ("1080p", "2160p", "4320p", and so on through the documented ladder), a video_config object containing the codec field ("h264" or "h265") plus a target bitrate and stream index, and an audio_config object alongside it with its own codec, bitrate, channel count, and sample rate. A single request can include multiple quality objects, one per rung you want encoded, which is how a full ladder gets built from one API call rather than one call per resolution. AIOZ's own documented example shows a 1080p and a 720p rendition side by side in one qualities array, both H.264, at 5,000,000 and 3,000,000 bps respectively, with 48kHz/44.1kHz AAC audio, the same shape this article extends up to 2160p and 4320p with H.265 instead.

Why H.264 stops at 4K, and what H.265 actually buys you

AIOZ Stream's documentation states the limit directly: H.264's maximum resolution on the platform is 4K, H.265's is 8K. That's not an arbitrary product decision, H.265 exists specifically because H.264 became inefficient at higher resolutions relative to a newer codec designed after lessons from two more decades of video compression research. The efficiency difference is real and independently measured, not just marketing: Fraunhofer HHI's own published figures, and Fraunhofer is one of the institutes that co-developed the HEVC (H.265) standard, state "about 50% bit-rate reduction at the same subjective video quality" compared to H.264. Independent testing measured at equal VMAF found a somewhat lower real-world average, HEVC needing about 44% less bitrate than H.264 across content types, with HD and 4K resolutions specifically landing in the 25-40% savings range, best-case scenarios on high-complexity high-resolution footage approaching that original 50% target, and lower resolutions settling closer to 15%. None of that is a fixed number, actual savings depend heavily on content and resolution, but the direction is consistent and well-established: the higher the resolution, the more H.265's efficiency advantage matters, which lines up with why AIOZ Stream requires it specifically at the top of the ladder rather than allowing H.264 all the way up.

The pixel-count math behind "just encode it in 8K"

It's worth doing the actual arithmetic before treating 8K as a reasonable default rather than a specific-use-case option. 1080p is 1920×1080, about 2.07 million pixels per frame. 4K (2160p, 3840×2160) is roughly 8.3 million pixels, almost exactly 4 times 1080p. 8K (4320p, 7680×4320) is about 33.2 million pixels, 4 times 4K and 16 times 1080p. Every one of those pixels needs to be analyzed and compressed for every frame, so encoding compute scales with that same multiplier, not linearly with some vaguer notion of "resolution." A video that encodes acceptably fast at 1080p doesn't scale to 8K by a small margin, it's asking for roughly 16 times the per-frame compute, which is exactly the kind of jump that makes checking cost and realistic turnaround time before committing worth the extra API call. The same multiplier matters again on the playback side, separately from encoding. Decoding 8K H.265 in real time needs a hardware decoder built for it, most phones and older TVs simply can't, which is the practical reason a real ladder keeps lower rungs around even when the top rung supports 8K: the highest resolution a platform can encode isn't the same question as which resolution a given viewer's device can actually play back.

A worked example: one video, three tiers

A source file gets encoded as a ladder rather than a single output, and mixing codecs across that ladder is normal, not an edge case. A practical shape: 720p and 1080p in H.264 for broad compatibility with older decoders and any player without H.265 support, then 2160p and 4320p in H.265 since AIOZ's platform requires it above 4K anyway. The request body extends the documented pattern directly: a qualities array with four objects, the first two using "codec": "h264" at 720p/1080p exactly as AIOZ's own example shows, the last two using "codec": "h265" at 2160p and 4320p with proportionally higher bitrates to match the ladder published in the bitrate ladder article (roughly 30 Mbps for 2160p, 60 Mbps for 4320p). A source file large enough to justify an 8K output is also almost certainly large enough to need the chunked upload sequence covered separately, worth planning for together rather than as two unrelated steps.

Checking cost before you commit

A GET request to /api/media/cost, with the target qualities, content type, and duration as query parameters, returns a price estimate and a boolean flag for whether the account's current balance covers it, before any actual encoding happens. That's a real, callable check, not a documentation aside, worth running specifically before queuing a 4320p output on a long source file, since the pixel-count math above means an 8K rendition of a two-hour video costs meaningfully more than the same ladder capped at 1080p, and finding that out from a failed job partway through is a worse experience than checking first. AIOZ's published rate card gives per-minute transcoding prices for HD ($0.01), 2K ($0.02), and 4K ($0.05), a clear, roughly linear-with-resolution pattern up to that point, but doesn't list a separate rate for 8K/4320p at all. That's not a rounding gap, it's a real absence worth noticing before assuming an 8K job simply costs whatever the 4K tier costs; calling /media/cost with the actual target qualities is the only way to get a real number for an 8K rendition rather than guessing at how the documented pattern might extend.

What isn't documented

AIOZ's public API reference doesn't specify expected encoding turnaround time for a 4K or 8K job, nor does it state an explicit file-size or duration ceiling for a 4K/8K upload specifically. That's worth planning around rather than assuming: build in a status-check loop against the video's processing state rather than assuming a fixed completion time, and treat "no documented limit" as "not yet tested at the extreme end" rather than "confirmed unlimited."

Frequently Asked Questions

Where exactly do I set the codec for a video encode?
Inside each object in the qualities array, at video_config.codec, set to either "h264" or "h265". It's not a separate top-level parameter.

Can I encode a video at 8K using H.264?
No. AIOZ Stream's documentation caps H.264 at 4K resolution; any 4320p (8K) output requires H.265.

How much more efficient is H.265 than H.264, exactly?
It varies by content and resolution, but independent VMAF-based testing found roughly 44% less bitrate on average at equal quality, with HD/4K content commonly seeing 25-40% savings, close to Fraunhofer HHI's original ~50% target for the standard.

Does 8K really need that much more processing than 4K?
Yes. 8K has about 4 times the pixels of 4K and 16 times the pixels of 1080p, and encoding compute scales with that pixel count, not with a small resolution bump.

Can I check the cost of an encoding job before running it?
Yes, via a GET request to /api/media/cost with the target qualities, content type, and duration, which returns a price estimate and whether the account balance covers it.

What does 8K transcoding cost on AIOZ Stream?
AIOZ's published rate card lists per-minute prices for HD, 2K, and 4K, but not 8K specifically. Call /api/media/cost with the actual target qualities to get a real number rather than assuming it extends the documented pattern.

Is there a documented time limit for how long a 4K/8K encoding job takes?
No. AIOZ's public docs don't specify expected turnaround time for high-resolution jobs; plan to poll the video's processing status rather than assume a fixed completion window.

Related Reading

• Podcast and Audio Hosting with the AIOZ Stream API: the audio-side equivalent of this article's quality/codec configuration
• Video Transcoding Basics: H.264 vs H.265 vs VP9: the general codec history, licensing patterns, and why VP9 isn't an option here
• How to Build a Video Bitrate Ladder: A Practical Guide: the ladder methodology this article's worked example is built on
• Chunked Video Upload Tutorial: 50-200MB Parts Explained: the upload mechanics a large 4K/8K source file likely needs
• AIOZ Stream Pricing: Storage, Delivery, Transcoding: the transcoding rate card behind the /media/cost estimate

References

• AIOZ Stream Media Video API documentation: the qualities array structure, valid resolution/codec values, and codec resolution caps cited above
• Fraunhofer HHI: H.265/HEVC: the official ~50% bit-rate-reduction figure, from a co-developer of the standard
• GetStream: H.264 vs H.265, File Size, Bitrate, and When to Use Each: the independent VMAF-measured real-world efficiency figures cited above