prehakanson-art/OrivioTVAppleTV v5

Orivio TV v5 — new native player

on GitHub

Orivio TV v5 is a rebuild of how playback actually works. The headline is a new native player, but the real story is that most of the pipeline between "a file on a debrid server" and "pixels on your TV" was replaced or repaired.

Downloads

Both are Release builds of the same code.

The new native player

Dolby Vision used to reach the screen by remuxing: the app rewrote the movie on the fly into a format Apple's player would accept, served it to itself over a local HTTP server, and played that. It worked, but it cost memory, disk, CPU and startup time — and it was the source of a whole class of crashes.

v5 replaces it with a direct sample-feed engine. FFmpeg demuxes the file, the compressed video is fed straight into the display pipeline, and nothing is rewritten or written to disk.

• Dolby Vision Profile 5, 7 and 8, with Profile 7 converted to 8.1 (enhancement layer dropped, RPU converted) so Apple's pipeline accepts it
• HDR10 / HDR10+ pass through untouched — the dynamic metadata rides inside the bitstream
• The stream is tagged with the file's real base-layer compatibility flavor (8.1 HDR10-base vs 8.4 HLG-base). Assuming HDR10 made 8.4 files render with visibly wrong colors
• Flat memory (~150 MB for an entire movie) instead of memory that climbed until the system killed the app
• The old remux tier is gone — about 1,500 lines including a POSIX HLS server, playlist windowing, disk budgeting, and the failure modes that came with them

Smoother playback on heavy remuxes

The stutter that plagued high-bitrate UHD remuxes turned out to be real, measurable, and specific.

Encoders differ in how deeply they reorder frames. A file using runs of 7 consecutive B-frames (~83% B-frames, reorder depth ~8) forces the decoder to hold and reorder eight 4K 10-bit frames before it can emit anything — so on older Apple TV hardware its output arrives in bursts, roughly three group-boundaries per second. Files with shallow IPBPB structure never hit it. Filming the TV at 240 fps confirmed it on the glass: about three repeat/catch-up frame pairs per second, while every software clock read perfect.

v5 fixes it by decoding ahead: the engine runs its own VideoToolbox decode session, keeps finished frames in a display-ordered buffer, and hands the display layer ready-to-flip pixel buffers. Burst decoding can no longer reach the screen.

Also fixed along the way:

• Frame timing — MKV stores timestamps in whole milliseconds while a 23.976 fps frame lasts 41.708 ms, so every frame landed slightly off the display's grid. Timestamps and durations are now snapped to the exact frame grid
• Buffering — a 10-second compressed buffer with an escalating cushion, so a cold link produces one honest pause instead of a stop-start loop
• Audio starvation — the clock now holds when either queue runs dry (audio-only starvation was dragging video into visible hitches, since video is slaved to the audio clock)

Audio

• Everything plays: TrueHD, DTS-HD, FLAC, Opus decode to PCM; AC3, E-AC3 and AAC pass through compressed
• Dolby Atmos passes through on DD+/E-AC3 tracks. TrueHD-Atmos cannot be bitstreamed on tvOS by any app, so those decode to PCM
• Correct 5.1/7.1 channel order. FFmpeg emits back-surrounds before side-surrounds; the CoreAudio layout tags expect the reverse. Every multichannel track was playing rear content from the side speakers and vice versa
• Track ranking — commentary and described-audio tracks no longer win the default pick, and preferred-language/channel-count ranking decides the rest
• Multichannel LPCM now carries a channel layout (without it, lossless tracks were silent)

Embedded subtitles

Subtitle tracks inside the file now work: SubRip, ASS/SSA, MOV_TEXT, plus PGS and DVD bitmap subs — the ones that exist nowhere else on disc remuxes.

They appear in the normal picker next to addon subtitles, labeled by language and format, with forced tracks marked. Selecting one replays a buffered backlog so cues appear immediately instead of when the demuxer's read-head catches up.

Display handling

Grey-screen and handshake trouble came from renegotiating the HDMI mode too often and at the wrong moments. v5 follows the discipline good players use:

• One display switch per session, requested while the loading screen is still static — never over live video
• The app waits for the panel to report the new mode and hold it steady before attaching video
• No in-app switch back. The mode is held for the whole session; tvOS reverts it on its own when the app backgrounds
• The request is clamped to what the TV actually advertises (DV → HDR10 → HLG → leave it alone)
• Frame rate is matched on the one switch, so 24 fps film isn't shown with 3:2 pulldown
• Manual re-sync: triple-press Play/Pause to renegotiate the connection if your TV ever wedges — it works blind, which matters when the screen is grey

Reliability

• Fixed an 80 MB-per-session leak — playback engines were kept alive by a retain cycle and their queues never freed, so sessions accumulated until the system killed the app mid-movie
• Mid-movie engine switching works: the old engine is stopped properly (it used to keep decoding, giving a frozen picture over doubled audio) and playback resumes at the right position
• Stuck-engine recovery: if a remembered engine choice can't open a file (AVPlayer can't open MKVs, for example), the app clears that memory and retries the same source automatically instead of marching through every link
• VLC resume uses the position-fraction API — VLC silently ignores time-based seeks on network streams, so it restarted movies from zero
• Seeking no longer stacks a buffering penalty, so scrubbing lands and plays promptly
• Crash classes from earlier builds (preferences-size aborts, memory kills, teardown races) are fixed

Convenience

• Per-title memory for audio track (matched by exact track, not just language), subtitles, engine and playback speed
• Playback info panel (swipe down): DV profile, FEL/MEL enhancement-layer type, resolution, frame rate, the display's live refresh rate, bitrate, and a decision log explaining why each choice was made
• Chapters, scrub thumbnails, precise seeking, and a Skip Intro control that's actually focusable

Note for older Apple TV hardware: the 2017 Apple TV 4K handles most content well, but the very heaviest disc remuxes (70–90 Mbps) sit at the edge of what it can decode. Decode-ahead removes the stutter that came from frame reordering; if a specific file still struggles, a WEB-DL of the same title will play comfortably.