YouTube playback after recent changes (Oct 2025)

[barracuda156]

Could someone try updating `yt-dlp` to this version and see if it fixes YouTube playback?

yt-dlp: update to 2025.11.12, yt-dlp-ejs: new port · macos-powerpc/powerpc-ports@903ba5b

Overlay repo with fixes to use with MacPorts on macOS PowerPC - yt-dlp: update to 2025.11.12, yt-dlp-ejs: new port · macos-powerpc/powerpc-ports@903ba5b

github.com

Provided you got some multimedia ports installed, it should be trivial.
As a check of functionality, try playing some YT vids from within QMPlay2. Is is expected to be broken right now (regardless of macOS version and arch) and hopefully gets fixed with this update.

I can only test on arm64 right now, where it works as expected.

In principle, anything relying on yt-dlp should be fixed, at least for now, with YouTube (other websites do not require the update at the moment).
If you use yewtube, pick these two commits: 1, 2.
ytsurf will likely work too (pay attention to port notes).

 

[ervus]

Thanks for all your work! I think PPCMC uses yt-dlp and is working as I post this from a PowerBook. That may not answer your question though...

 

[barracuda156]

Thanks for all your work! I think PPCMC uses yt-dlp and is working as I post this from a PowerBook. That may not answer your question though...

This might be relevant only for HD vids. Basically, see this for details: https://github.com/yt-dlp/yt-dlp/issues/14404

 

[Forest Expertise]

Could someone try updating `yt-dlp` to this version and see if it fixes YouTube playback?

yt-dlp: update to 2025.11.12, yt-dlp-ejs: new port · macos-powerpc/powerpc-ports@903ba5b

Overlay repo with fixes to use with MacPorts on macOS PowerPC - yt-dlp: update to 2025.11.12, yt-dlp-ejs: new port · macos-powerpc/powerpc-ports@903ba5b

github.com

Provided you got some multimedia ports installed, it should be trivial.
As a check of functionality, try playing some YT vids from within QMPlay2. Is is expected to be broken right now (regardless of macOS version and arch) and hopefully gets fixed with this update.

I can only test on arm64 right now, where it works as expected.

In principle, anything relying on yt-dlp should be fixed, at least for now, with YouTube (other websites do not require the update at the moment).
If you use yewtube, pick these two commits: 1, 2.
ytsurf will likely work too (pay attention to port notes).

From the command line, it works as expected: yt-dlp -f 96 www.youtube.com/watch?v=nZXRV4MezEw does download the video in 1080p. The implementation was far faster than I expected. I am using quickjs-ng, as quickjs proper has a build failure. I would rather patch the portfile to use quickjs-ng on Tiger rather than have to patch code to fix the build of quickjs. Easier to maintain, and as far as I can tell there is no reason not to use quickjs-ng.
Great work on this! While the 1080p video doesn't play perfectly on a Powerbook G4, it's great you are keeping this working for those with high-end PowerPC desktops. I also cannot test HD streaming in any meaningful way because of being on weaker hardware. But thanks to your clever idea of using quickjs, downloading HD is confirmed to work well.

 

[barracuda156]

From the command line, it works as expected: yt-dlp -f 96 www.youtube.com/watch?v=nZXRV4MezEw does download the video in 1080p. The implementation was far faster than I expected. I am using quickjs-ng, as quickjs proper has a build failure. I would rather patch the portfile to use quickjs-ng on Tiger rather

It is set as path-style, so you can just install whichever quickjs* you prefer, and it will satisfy the dependency and get picked by yt-dlp. It should also be switchable on-the-go.

than have to patch code to fix the build of quickjs. Easier to maintain, and as far as I can tell there is no reason not to use quickjs-ng.

In upstream tests quickjs was significantly faster than quickjs-ng (initially they only tried the latter, and that was the reason they did not want to support quickjs at all, assuming it is too slow; I raised the matter to the upstream, some fixes were done, and we convinced yt-dlp devs to give it another go, then it was added, see discussion here). But as long as it works fine, all good. Both forks are officially supported at the moment.

Great work on this! While the 1080p video doesn't play perfectly on a Powerbook G4, it's great you are keeping this working for those with high-end PowerPC desktops.

Well, G5s (at least better ones) handle up to 4k, and it is mostly usable (depends on compression etc., some videos play fine, some will lag), so it is certainly not pointless. 1080p stream with no issues on G5s (I think few to none frames dropped).

I also cannot test HD streaming in any meaningful way because of being on weaker hardware.

Yeah, likely won’t be particularly enjoyable on G4, it is better to download first and then watch.

 

[barracuda156]

I would rather patch the portfile to use quickjs-ng on Tiger rather than have to patch code to fix the build of quickjs.

The error in your log

:info:build Makefile:88: Extraneous text after `else' directive
:info:build Makefile:92: *** only one `else' per conditional.  Stop.

suggests it is just an old make is at fault.

Can you try this?

platform darwin 8 {
    depends_build-append port:gmake
    build.cmd ${prefix}/bin/gmake
}

Add this to portfile, run the build.

 

[Forest Expertise]

It is set as path-style, so you can just install whichever quickjs* you prefer, and it will satisfy the dependency and get picked by yt-dlp. It should also be switchable on-the-go.



In upstream tests quickjs was significantly faster than quickjs-ng (initially they only tried the latter, and that was the reason they did not want to support quickjs at all, assuming it is too slow; I raised the matter to the upstream, some fixes were done, and we convinced yt-dlp devs to give it another go, then it was added, see discussion here). But as long as it works fine, all good. Both forks are officially supported at the moment.



Well, G5s (at least better ones) handle up to 4k, and it is mostly usable (depends on compression etc., some videos play fine, some will lag), so it is certainly not pointless. 1080p stream with no issues on G5s (I think few to none frames dropped).



Yeah, likely won’t be particularly enjoyable on G4, it is better to download first and then watch.

Currently, it refuses to build if quickjs-ng is active:
powerbooks-powerbook-g4-88:~/powerpc-ports powerbook$ sudo port -n install yt-dlp-ejs
Password:
Warning: port definitions are more than two weeks old, consider updating them by running 'port selfupdate'.
---> Computing dependencies for yt-dlp-ejs
Error: Can't install quickjs because conflicting ports are active: quickjs-ng
Error: Follow https://guide.macports.org/#project.tickets if you believe there
is a bug.
Error: Processing of port yt-dlp-ejs failed
It then tries to force installation of quickjs, as documented in my attachment. I am unsure why this happens, but it is at worst annoying, not critical. Changing the portfile worked fine, and the portfile gives confirms that quickjs-ng is acceptable. Maybe this is a Tiger specific or 2.10.7 specific bug, if someone else wants to test.
The important thing is that you have preserved the future of yt-dlp on PowerPC OS X.
If quickjs is significantly faster I may have to try fixing it, but it's great that both are supported.
Edit: I will try your suggested fix as a build overnight, I will report back tomorrow.

 

[barracuda156]

It then tries to force installation of quickjs, as documented in my attachment. I am unsure why this happens, but it is at worst annoying, not critical. Changing the portfile worked fine, and the portfile gives confirms that quickjs-ng is acceptable. Maybe this is a Tiger specific or 2.10.7 specific bug, if someone else wants to test.

Ah, sorry, my bad, I used a wrong name for the binary there, LOL. Will fix it now.

Update. See if these fix the issue:

yt-dlp-ejs: fix quickjs* dependency spec · macos-powerpc/powerpc-ports@0cfb986

Overlay repo with fixes to use with MacPorts on macOS PowerPC - yt-dlp-ejs: fix quickjs* dependency spec · macos-powerpc/powerpc-ports@0cfb986

github.com

quickjs: use gmake on 10.4 · macos-powerpc/powerpc-ports@1b924d5

Overlay repo with fixes to use with MacPorts on macOS PowerPC - quickjs: use gmake on 10.4 · macos-powerpc/powerpc-ports@1b924d5

github.com

 

[Forest Expertise]

Quickjs builds fine with gmake - thanks for showing me that fix, there are a few other ports on Tiger which might benefit from it.
I can sort of stream 720p with yt-dlp -f 95 www.youtube.com/watch?v=nZXRV4MezEw -o - | mplayer -
Apparently I have been getting this warning - is it spurious?
No Javascript runtime could be found.
I have yt-dlp-ejs installed before rebuilding yt-dlp.
Everything seems functional.

 

[barracuda156]

Quickjs builds fine with gmake - thanks for showing me that fix, there are a few other ports on Tiger which might benefit from it.
I can sort of stream 720p with yt-dlp -f 95 www.youtube.com/watch?v=nZXRV4MezEw -o - | mplayer -
Apparently I have been getting this warning - is it spurious?
No Javascript runtime could be found.
I have yt-dlp-ejs installed before rebuilding yt-dlp.
Everything seems functional.

No idea, to be honest, but this is not a legacy OS issue, I get the same on Sonoma:

% yt-dlp -o - "https://www.youtube.com/watch?v=nZXRV4MezEw" | mpv -

[file] Reading from stdin...

[youtube] Extracting URL: https://www.youtube.com/watch?v=nZXRV4MezEw

[youtube] nZXRV4MezEw: Downloading webpage

WARNING: [youtube] No supported JavaScript runtime could be found. YouTube extraction without a JS runtime has been deprecated, and some formats may be missing. See  https://github.com/yt-dlp/yt-dlp/wiki/EJS  for details on installing one. To silence this warning, you can use  --extractor-args "youtube:player_client=default"

(The streaming still works.)

It is possible that JS runtime is not picked, but yt-dlp still manages to handle URL extraction (it is not guaranteed to be always broken without JS, it is just not guaranteed to work without it). MacPorts did not merge the update yet, and PR there, while not identical to my update, does not seem to do anything different.

Looking now at the FAQ, it seems that config may need to be modified to enable quickjs.

 

[barracuda156]

Upd. Create config file in one of specified locations and add `--js-runtimes quickjs:/opt/local/bin/qjs` in it.
Then QuickJS gets picked.

 

[Forest Expertise]

Upd. Create config file in one of specified locations and add `--js-runtimes quickjs:/opt/local/bin/qjs` in it.
Then QuickJS gets picked.

The config file takes care of the warning, it does now use QuickJS to solve the challenges. Slow on a Powerbook 1.5 Ghz (2-3 minutes). It may be worth passing as a command line option instead of a config when needed instead of all the time.
Great work!

 

[barracuda156]

The config file takes care of the warning, it does now use QuickJS to solve the challenges. Slow on a Powerbook 1.5 Ghz (2-3 minutes).

Is it with quickjs or quickjs-ng?

It may be worth passing as a command line option instead of a config when needed instead of all the time.

Let me know if that works better, I cannot try right now myself.

 

[Forest Expertise]

Is it with quickjs or quickjs-ng?



Let me know if that works better, I cannot try right now myself.

It was with quickjs. I'm glad that got fixed if quickjs-ng is even slower.
I assume it would work the same to pass on the command line, but it might save time to check if there are formats that don't require javascript versus always spending a couple minutes solving the javascript challenge just to check formats.

 

[barracuda156]

It was with quickjs. I'm glad that got fixed if quickjs-ng is even slower.

Initial testing on modern hardware (by developers of yt-dlp and quickjs-ng) shown times about 20 minutes LOL

QuickJS is very slow if used with `yt-dlp` · Issue #445 · bellard/quickjs

@bellard @bnoordhuis @saghul Cross-posting here, otherwise it might go unnoticed. Issue reported by yt-dlp developers in yt-dlp/yt-dlp#14404 (comment) Could it be addressed? QuickJS is the only por...

github.com

(Been improved significantly since then, AFAIU.)

So perhaps 2 minutes is not that awful for a G4.