H.SBS vs F.SBS vs H.OU vs F.OU vs F.TB vs T.AB vs Anaglyph vs other: Stereoscopic 3D Video Formats compare

Half Side-by-Side vs Full Side-by-Side vs vs Over-Under / Top-And-Bottom vs Full Over-Under / Full Top-Bottom vs Half Over-Under vs Top-And-Bottom vs Anaglyph vs other: A Taxonomy of Illusions

Below is a “decoder ring” for the common stereoscopic 3D movie encodings. Almost all of them are just different ways to multiplex two views (Left + Right) into something legacy video pipelines can carry.

0) Anaglyph (the “wear red/cyan glasses and pray” method)

• Both eyes are encoded into color channels of one image (e.g., Left=red, Right=cyan).
• Pros: plays on almost anything; single standard 2D stream.
• Cons:
• Color fidelity is wrecked by design.
• More retinal rivalry/ghosting; discomfort is common.
• Depth quality depends heavily on scene colors and the anaglyph matrix used.

1) Spatial multiplexing (both eyes in the same video frame)

SBS: Side-by-Side

• FSBS (Full SBS)
• Layout: [Left | Right] in one wider frame
• Per-eye resolution: full (e.g., each eye 1920×1080)
• Stored frame example (to carry two 1080p eyes): 3840×1080
• Pros: best detail; simple decode/display if supported
• Cons: higher bitrate/storage; some players/TVs won’t accept “nonstandard” widths

• HSBS (Half SBS)
• Layout: [Left | Right] but each eye is horizontally squeezed to fit standard width
• Stored frame example: 1920×1080 containing two 960×1080 views
• Per-eye resolution: half horizontal
• Pros: compatible with standard 1080p pipelines; common for streaming
• Cons: loses horizontal detail; can look softer, especially in textures/subtitles

Rule of thumb: HSBS halves horizontal detail; FSBS keeps it.

OU / TAB: Over-Under / Top-And-Bottom (same thing, different slang)

• FOU / FTB (Full Over-Under / Full Top-Bottom)
• Layout: Top=one eye, Bottom=other eye, both full height per eye
• Stored frame example for two 1080p eyes: 1920×2160
• Per-eye resolution: full

• HOU / TAB (Half Over-Under / “regular” Top-And-Bottom in most releases)
• Stored frame example: 1920×1080 containing two 1920×540 views
• Per-eye resolution: half vertical

Key point:

• SBS variants trade horizontal resolution.
• OU/TAB variants trade vertical resolution.

2) Temporal multiplexing (eyes alternate over time)

Alternating / Frame Sequential / Page Flipping

These are closely related in practice:

• Frame Sequential (a.k.a. frame alternating)
• Stream is: L, R, L, R, ... (or R, L, ...)
• Each eye gets full spatial resolution, but only every other frame in time.
• Requires a display method that can deliver each frame to the correct eye (active shutter, some 3D projectors/monitors).

• Page Flipping (common PC/3D driver term; conceptually the same as frame sequential)

• Historically refers to switching (“flipping”) the displayed buffer/page between left and right images in sync with the display/eyewear.
• In files, it’s often indistinguishable from frame sequential; the difference is more about the display pipeline than the stored video.

Left-first vs Right-first (critical metadata)

• Left first: the first frame (or top/left region) is the Left eye.

• Right first: the first frame is the Right eye. If this is wrong, you get depth inversion (the “inside-out world” effect): near objects look far and vice versa. 🤢

Practical constraint: temporal methods want high refresh (often 120 Hz) to avoid flicker and reduce motion artifacts per eye.

3) Interleaving patterns (sub-sampling by rows/columns)

Line interleaving (Even rows vs Odd rows)

• Layout: alternating scanlines belong to different eyes.
• Example: even rows = Left, odd rows = Right (or swapped)
• Per-eye resolution: half vertical, but not in big blocks — interwoven lines.
• Used by: many passive polarized TVs/monitors (Film Pattern Retarder).
• Upside: simple; works well on displays designed for it.
• Downside: fine horizontal lines can shimmer; vertical detail is fundamentally limited.
• Even/Odd swapped = eyes swapped (again: depth inversion).

DLP Checkerboard (vs swapped)

• Layout: a checkerboard pattern assigns pixels alternately to Left/Right.
• Effective per-eye sampling: roughly half the pixels (but spread in both directions).
• Historically used by: some DLP HDTV / DLP projector 3D systems.

• “Swapped” means the checkerboard phase is inverted → eyes swapped → depth reversal.

4) “Frame Packing” vs “MVC” (people confuse these constantly)

Frame Packing (a packing format / transport layout)

• Both eyes are carried as two full frames packed into one “superframe” with blanking.
• Classic example: Blu-ray 3D 1080p24 frame packing uses 1920×2205:
• 1080 lines Left + 45 blanking + 1080 lines Right
• Pros: full per-eye resolution; standardized for HDMI 1.4 era 3D signaling.
• Cons: higher bandwidth than half-formats.

MVC (Multiview Video Coding) (a compression method)

• MVC is an H.264/AVC extension that encodes one eye as a base view and the other as a dependent view using inter-view prediction.
• This is how Blu-ray 3D usually stores stereoscopic video efficiently: you don’t duplicate everything.

Clean separation:

• Frame packing = how two views are arranged for transport/display.
• MVC = how two views are compressed in the bitstream. Blu-ray 3D commonly uses MVC + frame packing at output.

5) Dual Stream (two independent video streams)

• Left and Right are separate full video streams:
• Two files, or two tracks in one container (e.g., MKV), or two PIDs in broadcast.
• Pros:
• Maximum compatibility with custom pipelines; each eye can be full res, full frame rate.
• No special packing assumptions.
• Cons:
• More bitrate/storage unless you use a multiview codec; synchronization becomes your problem if not properly timestamped.

What do iPhone 17 Pro “3D videos” actually come out as?

If you record Spatial Video on an iPhone 17 (including Pro models), the file is not FSBS/HSBS/TAB/FTB.

• Apple records Spatial Video as MV-HEVC (multiview HEVC): two eye views stored as separate layers inside a single HEVC-based movie track, plus spatial metadata.
• iPhone spatial video capture is 1920×1080 at 30 fps (SDR); Apple’s iPhone 17 specs explicitly list “Spatial video recording at 1080p at 30 fps.”

So: iPhone → MV-HEVC “stereo layers,” not SBS/TB. (Then you convert to SBS/TB/etc for platforms that don’t understand MV-HEVC.)

Apple even ships an AVFoundation sample about converting SBS → MV-HEVC, which is basically proof of the ecosystem split between “consumer stereo packs” and “Apple spatial.”

If you care about objective quality (detail + fewer artifacts), the hierarchy is usually: Full-res methods (Frame Packing/MVC/Dual-stream) > Half formats (HSBS/HOU) > Interleaved patterns > Anaglyph. The best “real world” choice depends on what your display chain can correctly interpret without silently swapping eyes or scaling badly. 🔧

What 3D formats you’ll most commonly encounter in the wild 🧬

1) HSBS / HTAB (HOU) dominate

They squeeze two eyes into a standard 1080p (or 2160p) frame, so they’re easy to encode, stream, and play. Many “online collections” emphasize these because they’re small and broadly compatible.

• HSBS 1080p: stored 1920×1080, per-eye 960×1080
• HTAB/HOU 1080p: stored 1920×1080, per-eye 1920×540

2) Full-res Blu-ray 3D sources (MVC / ISO / Remux) exist but are bigger & less universally supported

Blu-ray 3D typically uses MVC (Multiview Video Coding) and tends to be tens of GB. Historically many VR players couldn’t decode MVC (forcing conversion to SBS/TAB), but that has been changing.

3) FSBS / FTB (true “full” spatial) are less common

They require “wide” or “tall” frames (e.g., 3840×1080 for FSBS 1080p-per-eye; 1920×2160 for FTB 1080p-per-eye). That stresses compatibility and bitrate.

4) Interleaved (row / checkerboard) + frame-sequential are relatively uncommon as downloadable “movie files”

Those formats are more tied to particular display hardware pipelines (passive TV rows, DLP checkerboard, active shutter frame-sequential) than to universal file playback.

5) Anaglyph is rare and usually a last resort

It’s the “works anywhere, looks compromised” format.

For VR/AR/MR headsets: what should you choose? 🎥🥽

The core constraint

Most VR “cinema” players want a file that’s easy to split into two textures:

• SBS (left/right halves) or
• TAB/OU (top/bottom halves)

So: SBS/TAB are the safe universal choices.

A pragmatic ranking (best → worst) for head-mounted theaters

A) MVC / Blu-ray 3D (ISO or MVC remux) — choose this if your player supports it

• Pros: typically full per-eye detail (closest to disc quality)
• Cons: large files; not every app supports it

Examples of VR players that explicitly advertise MVC 3D / Blu-ray 3D decoding include 4XVR and newer SKYBOX VR releases that added MVC decoding.

If your headset/app stack truly decodes MVC, this is usually the quality ceiling.

B) “4K SBS” (3840×2160 SBS) — often the best compromise

Important subtlety: lots of files called “4K SBS” are still SBS, meaning each eye gets half the width:

• Stored: 3840×2160 SBS
• Per-eye: 1920×2160

That per-eye pixel count is much friendlier to modern headsets than 1080p HSBS (960×1080 per eye). In practice, this is where VR movie viewing stops looking “DVD-ish” and starts looking meaningfully crisp.

C) 1080p HSBS — the common baseline

• Per-eye 960×1080 is mediocre on high-res headsets, but it’s widely supported and small.

D) 1080p HTAB/HOU — usually worse than HSBS in VR

• Per-eye 1920×540 throws away vertical detail, and VR lenses + resampling tend to make low vertical resolution look especially mushy (faces, subtitles, fine textures).

There are exceptions (some content and players scale one better than the other), but as a default: HSBS beats HOU for perceived sharpness in most headset “big screen” viewing.

E) Anaglyph — avoid unless you have no other option

Color fidelity and comfort take a hit.

Your file’s resolution matters more than the label

Ignore marketing names; compute per-eye resolution:

• SBS per-eye = (W/2) × H
• TAB per-eye = W × (H/2)

So:

• 1920×1080 HSBS → 960×1080 per eye
• 3840×2160 SBS → 1920×2160 per eye
• 1920×1080 HOU → 1920×540 per eye

That one arithmetic step predicts VR sharpness better than most forum lore.

Bottom line recommendation 📌

• Best quality (if supported): MVC / Blu-ray 3D (ISO/remux/MVC)
• Best universal VR choice: 3840×2160 SBS (often called “4K SBS”)
• Most common acceptable: 1080p HSBS
• Usually avoid (in VR): 1080p HOU/HTAB unless HSBS isn’t available
• Avoid: anaglyph unless you enjoy suffering as a hobby

If you push the “scientist mode” dial: the real optimization target is maximizing per-eye pixel density after lens distortion + resampling, which is why higher per-eye source resolution (MVC or 4K SBS) so reliably wins in headsets.

2) What does a “regular stereo camera” output?

This varies by vendor, but the common outputs are:

• Dual stream (two files or two tracks: Left + Right) — common in pro workflows.
• Frame-compatible packs: HSBS or HTB/TAB — common in consumer gear because it stays in standard 16:9 dimensions.
• Some cameras can do higher-end multiview/VR formats (especially 180/360 rigs), but for “rectangular stereo” it’s usually dual stream or SBS/TB.

So: a stereo camera might output FSBS, but “FSBS by default” is not something you should assume.

3) Best choice for YouTube in 2026: it’s basically SBS (LR), with metadata

YouTube’s own help page is blunt:

• For rectangular 3D, YouTube supports left-right side-by-side (LR SBS) stereo layout, and it expects proper stereo metadata (e.g., st3d box in MP4/MOV, or StereoMode in MKV/WebM).

That implies two practical consequences:

1. TAB / top-bottom is not the safe path for ordinary rectangular YouTube 3D uploads (even if some legacy tutorials claim otherwise). The current official guidance emphasizes LR SBS.
2. You should embed correct metadata (or use a workflow that does) so YouTube flags it as 3D.

HSBS vs FSBS for YouTube

Think of this as a trade between compatibility vs per-eye detail:

• HSBS (1920×1080 container) → each eye is 960×1080 samples (half horizontal detail).
• FSBS (3840×1080 container) → each eye is 1920×1080 samples (full 1080p per-eye).

If you care about per-eye detail, FSBS wins. The “cost” is that your container becomes ultra-wide (32:9). YouTube can still host odd aspect ratios; it will just letterbox/pillarbox in 2D mode.

Also, YouTube supports uploads up to 8K (7680×4320) and recommends bitrate tiers accordingly. So if you do have high-res stereo masters, you can upload a very high-res FSBS master (bandwidth permitting) and let YouTube downscale.

But: if your source is iPhone Spatial Video (1080p per eye), converting to a gigantic FSBS frame does not magically create new detail; it just repackages the same 1080p-per-eye information.

4) Your “half formats lose pixels because the eye adjusts FOV” model is slightly off 🎯

What actually happens:

• HSBS/HTB throw away samples at encode time (you downsample one dimension).
• Playback typically scales the half-resolution eye image back to the display’s per-eye canvas.

So yes, you end up with fewer unique pixels per eye. But it’s not because “FOV normalization eats pixels” in some additional step — it’s just classic sampling theory: you downsample → you cannot recover.

Also, the streaming reality check: at a fixed bitrate, half formats often look less artifacty because there are fewer pixels to compress. Full-res formats can look worse if you starve them of bitrate.

5) Is Full Top/Bottom (FTB) “better for vertical platforms”?

First: FTB is “full per-eye,” but the container aspect gets weird

If each eye is 16:9 (say 1920×1080), then FTB is 1920×2160.

That’s 8:9 aspect ratio (taller than 16:9, but nowhere near 9:16). So it’s “closer to square,” yes — but it’s not “vertical video” in the Shorts/TikTok sense.

Second (more important): most short-video platforms won’t decode stereoscopic layouts

Even if your container is tall, TikTok/Snap/IG-style feeds generally treat uploads as 2D video. Without a stereoscopic-aware player path, your audience just sees:

• two stacked views (TB) or
• two side-by-side views (SBS)

…which is not a great user experience.

So FTB is not a cheat code for vertical stereo distribution. It’s mostly useful when:

• you control the playback environment, or
• you’re targeting a platform/player that explicitly supports TB stereo.

If you insist on “vertical stereo” as an engineering exercise

Let each eye be 9:16 (e.g., 1080×1920).

• Vertical FSBS container: 2160×1920 (aspect 1.125:1 ≈ near-square)
• Vertical FTB container: 1080×3840 (aspect 0.281:1 = extremely tall)

If you’re trying to avoid being mangled by aspect-ratio normalization in social apps, SBS is less insane than TB for vertical compositions — but again, you still don’t get native stereoscopic playback in the main feed.

6) A pragmatic creator workflow (works in the real world)

Keep a “master” that preserves the stereo information

• iPhone: keep the MV-HEVC spatial master for Apple ecosystem playback/editing.
• Stereo rigs: keep dual-stream or your highest-quality stereo master.

Export “distribution derivatives”

• YouTube rectangular 3D: export LR SBS + correct metadata (YouTube explicitly supports LR SBS).
• Everything else (TikTok/Snap/Reels/Shorts): export a 2D cut (usually left-eye view), and optionally a “depthy” variant (wiggle/parallax/AI depth) as a stylistic effect, because the feed won’t present true binocular stereo anyway.

One last nerd note: comfort beats pixels 🧠

If your goal is “people actually watch this,” stereo comfort often dominates resolution. Vertical misalignment, bad convergence, and excessive disparity drive discomfort more reliably than HSBS vs FSBS. The vision science literature on stereo viewing makes that painfully clear.

If you optimize anything first, optimize camera alignment + disparity budget + motion — then fight about packing formats.