How I Spent 40 Hours Building a Serverless 8K Video Downloader on Android by Embedding CPython and FFmpeg

Rajan Prasaila Yadav — Wed, 28 Oct 2026 23:06:38 +0000

Building a mobile YouTube downloader seems straightforward at first glance—until you actually try to build one that runs 100% on-device, downloads in 4K and 8K, requires zero servers, and costs ₹0.

Over the last 40 hours of continuous research, day-and-night testing, and hundreds of failed experiments, I went down the deepest rabbit hole of mobile systems engineering I’ve ever experienced.

Here is the story of how I bypassed the infamous "360p ceiling," why free cloud hosting failed, and how I ended up embedding a full CPython 3.11 runtime and an ARM64 FFmpeg binary directly inside a modern Kotlin + Jetpack Compose Android app.

Act I: The 360p Ceiling and the DASH Problem

My original goal was simple: write a lightweight client using cross-platform tooling (Flutter + Dart) to download videos directly to mobile storage.

I quickly hit three massive walls:

1. The 360p Lock-In

YouTube stopped serving combined video-and-audio files for high resolutions years ago. If you want 720p, 1080p, 1440p, 4K, or 8K, YouTube serves them via DASH (Dynamic Adaptive Streaming over HTTP)—meaning the video track and the audio track are two completely separate network streams.

To get a playable .mp4, you must have a multiplexer (muxer) like FFmpeg running locally to combine them. Without an on-device muxer, pure mobile scrapers are permanently locked to legacy 360p (itag 18).

2. The 4–6 MB Stream Cutoff

When downloading direct HTTP stream chunks, downloads would start at full speed, hit around 5 MB, and suddenly choke to 0 KB/s before failing. YouTube's CDN actively rate-limits and drops TCP sockets if the client does not continuously solve and send valid player tokens.

3. Bot Challenges

Direct scraping triggered YouTube’s bot detection systems: HTTP 403 Forbidden and "Sign in to confirm you're not a bot".

Act II: The Free Cloud Hosting Dead-End

Thinking the mobile device’s network or CPU was the issue, I moved the extraction engine to free cloud hosting platforms:

Hugging Face Spaces
Railway
Fly.io
Vercel & Netlify
Render

The Result: Total IP Blockage

Every single cloud host failed. Why? Datacenter IP reputation.
YouTube maintains real-time blacklists of known cloud provider IP CIDR blocks (AWS, Google Cloud, Fastly, Cloudflare). The moment a request comes from a cloud datacenter IP, YouTube demands a CAPTCHA or blocks the connection outright.

A remote cloud server was not going to work. The only way to guarantee longevity was to make the app run entirely locally on the user's phone IP.

Act III: The Desktop Breakthrough

I stepped back and built a standalone Python desktop script using Tkinter, yt-dlp, and native ffmpeg.

On my PC, it worked flawlessly:

It parsed complete metadata (title, tags, thumbnail, duration).
It filtered out junk streams and identified the true highest available resolutions—from 144p all the way to 8K (4320p).
FFmpeg merged high-bitrate video with lossless audio streams locally with zero rate limits and zero cloud hosting fees.

That led to the ultimate question:

"If a local CPython engine and FFmpeg can download 8K videos without any server, why can't we bundle that entire engine inside an Android APK?"

Act IV: Packing an Entire Desktop Engine into Android

I started a clean native Android project built with Kotlin 2.0, Jetpack Compose, and Media3 ExoPlayer.

Here are the key technical challenges I had to overcome to embed CPython on Android:

1. SELinux & Native Execution (Error 13: Permission Denied)

Modern Android (API 29+) forbids executing binaries from external storage or normal cache partitions (noexec mount flag).

Solution: On first launch, the app decompresses a standalone Linux ARM64 CPython 3.11 bundle and static FFmpeg binary from assets/ into the app's private internal storage (/data/user/0/<package>/files/runtime/).
Then, low-level POSIX execution permissions are granted programmatically:

  android.system.Os.chmod(binaryFile.absolutePath, 493) // 0755 rwxr-xr-x

Environment variables (PYTHONHOME, PYTHONPATH, and LD_LIBRARY_PATH) are mapped dynamically so Python can load shared cryptographic libraries (libcrypto.so, libssl.so).

2. Solving JavaScript Cipher Challenges with QuickJS

YouTube uses dynamic JavaScript challenges (n-sig transformations) to throttle download speeds. Rather than bundling a bulky Node.js binary, I embedded QuickJS (libqjs.so), a tiny, lightweight C-based JavaScript engine that allows yt-dlp to evaluate cipher challenges in milliseconds directly on mobile.

3. Android Doze Mode & Foreground Services

High-resolution 4K/8K multiplexing consumes CPU cycles. When the user turned off the screen, Android's battery manager would kill the child process mid-stream.

Solution: Implemented an Android Foreground Service with FOREGROUND_SERVICE_TYPE_DATA_SYNC and a PARTIAL_WAKE_LOCK. Real-time stdout from the child process is parsed into an ongoing notification progress bar with download speed (MB/s) and ETA.

4. Scoped Storage & MediaStore Publishing

Under Android 11–15 Scoped Storage, child processes cannot write directly to /storage/emulated/0/Download/.

Solution: Downloads stage inside the private cache (context.cacheDir/staging/). Once FFmpeg finishes merging, a native Kotlin worker commits the file directly into MediaStore.Video or MediaStore.Audio using Android's ContentResolver. The files immediately appear in the user's Gallery, VLC, and MX Player.

Act V: Building the Native Media Player

Downloading high-quality media is only half the experience; playing it is the other half. I built a native player powered by Media3 ExoPlayer featuring:

MX Player-Style Aspect Ratio Modes: Cycle through FIT TO SCREEN, STRETCH, CROP, and 100% (unscaled 1:1 pixel rendering with borders all around) complete with centered bold HUD overlays.
Dual-Zone Gestures: Screen-left vertical swipe adjusts brightness; screen-right vertical swipe adjusts system volume; horizontal swipe scrubs the timeline with a +Xs / -Xs (MM:SS) HUD.
The Compose "Pointer Starvation" Fix: When implementing a "Touch & Hold for 2 seconds → 2X speed boost", standard Compose gesture loops (awaitPointerEvent()) only fire when the finger moves. Holding still produced zero touch events, meaning timer checks never ran! I solved this by decoupling the timer into an independent coroutine job:

  val holdJob = coroutineScope.launch {
      delay(1800L)
      if (!hasDragged && !isMultiTouch) {
          player?.setPlaybackSpeed(2.0f)
      }
  }

Persistent Speed Engine: Users can select speeds from 0.25x to 2.0x that persist across all video and audio tracks globally.

The Result: ₹0 Lifetime Cost & Total Privacy

After 40 hours of focused development:

Cost: Exactly ₹0. No monthly cloud bills, no VPS hosting, no paid API tokens.
Privacy: 100% direct connection between the phone and the media source. No proxy servers intercepting traffic.
Performance: Direct on-device multiplexing up to 8K (4320p).

Open Source & Download

The project is completely open source under the MIT License. You can check out the source code, architecture diagrams, and download the pre-compiled APK directly:

👉 GitHub Repository: https://github.com/Rajan7013/YtMax

📦 Direct v1.0.0 APK: Download from GitHub Releases

DEV Community: Rajan Prasaila Yadav