Bundle Deno runtime to support YouTube JavaScript challenges #2640

Checklist

• This feature I'm requesting is already implemented in yt-dlp.
• This feature is merely a UI/UX update.
• This feature is suitable for primary users with little knowledge about yt-dlp.
• This feature is available for most websites, not only the video platform I use.
• This feature is suitable for a large variety of videos.
• This feature is not going to conflict with many of the existing options.

Is your feature request related to a problem? Please describe.

Bundle Deno runtime for YouTube JavaScript challenges

Problem

Recent versions of yt-dlp require a JavaScript runtime for some YouTube extraction paths. On Android, Seal currently does not bundle one, so YouTube downloads can fail with:

WARNING: [youtube] No supported JavaScript runtime could be found.
Only deno is enabled by default; to use another runtime add
--js-runtimes RUNTIME[:PATH] to your command/config.

This is especially noticeable on recent Android versions, where users cannot simply install a system-wide Node.js or Deno runtime.

Proposed solution

I tested bundling the Android ARM64 build of Deno 2.8.3 directly into Seal as a native library:

app/src/main/jniLibs/arm64-v8a/libdeno.so

No changes to Seal's normal download flow are required.

The important detail is that youtubedl-android already adds the application's nativeLibraryDir to PATH when launching yt-dlp. Therefore, once Deno is packaged into the application's native library directory, yt-dlp can discover and execute it automatically.

Test result

I built Seal 1.13.1 with Deno 2.8.3 bundled this way and tested it on:

• Device: Samsung Galaxy S26 Ultra
• Android: 16 / API 36
• ABI: arm64-v8a
• Seal: 1.13.1
• yt-dlp: 2026.09.16
• Deno: 2.8.3

The resulting APK successfully downloaded a YouTube video using the normal Seal download flow.

No:

• root access
• Termux
• separately installed Deno
• custom yt-dlp command
• --js-runtimes option
• user configuration

was required.

Implementation

The only additional native artifact required for the ARM64 build was:

app/src/main/jniLibs/arm64-v8a/libdeno.so

The Deno binary is an Android ARM64 ELF executable and was built for Android API 30+, so it runs on Android 16.

The resulting APK contained:

lib/arm64-v8a/libdeno.so

with a size of approximately 88 MiB.

Considerations

I have only tested the ARM64 variant so far. Other ABIs would require their corresponding Android Deno binaries.

The main questions for upstream integration would therefore be:

1. Whether bundling Deno is acceptable from an APK size perspective.
2. Which Deno version should be bundled and how it should be updated.
3. Whether all supported Seal ABIs should receive a bundled runtime.
4. Whether there are any licensing/distribution considerations for the Deno binary.
5. Whether this approach fits the current Seal architecture, especially considering the ongoing Seal 2.x development.

I'm opening this issue primarily to share a working approach and verify whether this is something the project would consider for an upstream implementation.

If useful, I can also provide the minimal source change and build instructions used for the test.

Describe the solution you'd like

No response

Video link

No response

Additional context

No response