Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

barracuda156

macrumors 68040
Original poster
Sep 3, 2021
3,452
2,002
Could someone try updating `yt-dlp` to this version and see if it fixes YouTube playback?

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).
 
  • Like
Reactions: Matias_ and jktwice
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...
 
Could someone try updating `yt-dlp` to this version and see if it fixes YouTube playback?

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.
 

Attachments

  • quickjs.txt
    19.9 KB · Views: 1
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.
 
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
Code:
: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?
Code:
platform darwin 8 {
    depends_build-append port:gmake
    build.cmd ${prefix}/bin/gmake
}
Add this to portfile, run the build.
 
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.
 

Attachments

  • issue.txt
    1.9 KB · Views: 1
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:
 
Last edited:
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.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.