Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
11-7-2024 - PPCMC 7.2.7 - YouTube/Twitch Streaming, Downloading, File Conversion, Web Interface, & More For Mac OS X 10.3.9-10.5.8
- Thread starter alex_free
- Start date
-
- Tags
- release
- Sort by reaction score
The l̶e̶g̶e̶n̶d̶ Mac OS X 10.3.9 ability to play YouTube videos/Twitch streams
will never die
will never die
Along with many, many folks, I’ll be thrilled to witness your new coding chops being put to use with 7.2.7.
Just keep in mind a couple of things. One, we’ve all been incredibly grateful to have PPCMC as a utility all this time. And also, never forget that old maxim, “Let not perfection be the enemy of good”!
Welcome back, @alex_free !
Sneak peak at the new build system of PPCMC 7.2.7. This is not a new release, but rather a look at how I use only Xcode v2.5 (no MacPorts) in 2024 to bootstrap a ton of modern dependencies required to get YouTube on 10.3.9+ working. If you know bash or are interested in how to do what a package manager does without well, a package manager, give it a look.
Ton more work to do, but it's still on schedule by Halloween. By no means is this useful by itself
Ton more work to do, but it's still on schedule by Halloween. By no means is this useful by itself
It's alive!
I can't wait for a proper release, and neither can you. Getting very distracted "testing" it out. So here is a BETA version of the next PPCMC7.2.7. Please test it out with me.
Notes:
* Do not update youtube-dl with the app (I have not yet fixed this up).
* Some things don't work (many formats such as 480p, etc.). Use the 240p/360p formats (perhaps 720p works still, haven't got there yet).
* This is a panther optimized build, that has only been tested on 10.4.6. It should work on 10.3.9 and all tiger versions, but I haven't been able to test panther yet. Will you beat me to panther testing?? I got the backend dependencies finalized, and modified the front end to fix some bugs and fix youtube errors.
* This is NOT release quality.
* This DOES work to stream YouTube and download videos. Perhaps twitch as well. Very early build!
* The Tiger optimized build will be even faster.
* SERIOUS optimizations to FFmpeg 4.4.5. The entire backend has been upgraded and not documented yet.
* My preferences are preset in this download for FFplay (fast G4 optimized, fullscreen). Change these with the edit preferences option. Serious optimizations! Try fast G4 even if you have a slow G4 and see what happens, we have assembly support for perhaps the first time working correctly in FFplay with altivec since I found a GNU GAS supplement that seemingly even MacPorts doesn't have.
filetransfer.io
I can't wait for a proper release, and neither can you. Getting very distracted "testing" it out. So here is a BETA version of the next PPCMC7.2.7. Please test it out with me.
Notes:
* Do not update youtube-dl with the app (I have not yet fixed this up).
* Some things don't work (many formats such as 480p, etc.). Use the 240p/360p formats (perhaps 720p works still, haven't got there yet).
* This is a panther optimized build, that has only been tested on 10.4.6. It should work on 10.3.9 and all tiger versions, but I haven't been able to test panther yet. Will you beat me to panther testing?? I got the backend dependencies finalized, and modified the front end to fix some bugs and fix youtube errors.
* This is NOT release quality.
* This DOES work to stream YouTube and download videos. Perhaps twitch as well. Very early build!
* The Tiger optimized build will be even faster.
* SERIOUS optimizations to FFmpeg 4.4.5. The entire backend has been upgraded and not documented yet.
* My preferences are preset in this download for FFplay (fast G4 optimized, fullscreen). Change these with the edit preferences option. Serious optimizations! Try fast G4 even if you have a slow G4 and see what happens, we have assembly support for perhaps the first time working correctly in FFplay with altivec since I found a GNU GAS supplement that seemingly even MacPorts doesn't have.
Download Data package from October 21st.
Size of the data package: 147.89 MB. Free transfer of up to 6 GB of photos, videos and documents. Send large files via email or a link to share. No registration, no ads, just simple file sharing!
@alex_free I have tested this but your old version (with added newer python and mplayer) still works better for me - it's only around 5% CPU difference though.
Thanks for the feedback.
For that test to be fair, you'd need to use the 7.2.6 panther build. If your comparing the 7.2.6 tiger build with this it is kinda unfair since this is a panther build (which can't use all the optimizations available on Tiger, the biggest one is threading advancements as you go up to Leopard).
What is the newer Python for? 3.6.13 is fine for youtube-dl. Are there any advantages? I'm still on 3.6.13 because it builds/runs on 10.3.9 without issues.
Mplayer integration support with PPCMC7 still works OK for you right?
@alex_free Yes, definitely measuring against Tiger build.
Newer Python as you moved from youtube-dl to yt-dlp on the older PPCMC7, which nudged it's requirements higher.
Youtube-dl I didn't even know was working again - it certainly became useless a few years ago.
On this new version I let PPCMC7 hand over to ffplay but on my old version it passes to the Macports Mplayer for streaming and a much older Mplayer for playback after downloading (the difference is a few CPU cycles.)
Newer Python as you moved from youtube-dl to yt-dlp on the older PPCMC7, which nudged it's requirements higher.
Youtube-dl I didn't even know was working again - it certainly became useless a few years ago.
On this new version I let PPCMC7 hand over to ffplay but on my old version it passes to the Macports Mplayer for streaming and a much older Mplayer for playback after downloading (the difference is a few CPU cycles.)
Cool, so the comparison was unfair. Just sanity checking the expected performance.
Youtube-dl secretly works. They no longer make official releases (https://github.com/ytdl-org/youtube-dl/releases has the last release as from December 16th of 2021) but the actual source has been getting constant commits/updates and if you pull directly from that you get a working youtube-dl that works on python 2.7.x and 3.2.x+. AFAIK DLP doesn't have any advantages and is not compatible with older python releases (you correctly point out that it upping the 3.6 requirement is what broke 7.2.6). Using DLP with 3.6 was always playing with fire because it was the oldest python supported, I just barely met the requirement with 3.6.
I've been out of the loop with the youtube-dl forks for almost 3 years so I have no idea if DLP is superior (perhaps if age-gated videos work, as they still don't with youtube-dl and that bothers me because I haven't had a google account for almost 10 years at this point).
I guess lastly what I want to know is if there is anything in your workflow that PPCMC7 can do better. I'm pretty sure it lets you pick the mplayer executable already, but I might be misremembering.
@Dronecatcher with your modifications on the old build still using DLP allow for downloading 480p and other formats that are not 360p?
Sorry, meant to reply earlier. Regarding advantages of yt-dlp - it was simply because back then youtube-dl had become so slow as to be unusable - think it was throttled to less than 20kbps!
I only go for 360P - I think 480P needs muxing with the audio doesn't it?
Throttling was awful but it got fixed in the original youtube_dl (streaming works great). It's mentioned in one of the commits.
All formats besides 360p do require muxing with the m4a audio. But that is no issue when downloading (it is for streaming). Does the 480p YouTube download option work with your setup using DLP? Regular youtube-dl can't use that option atm. Do age gated videos work in your setup?
I don't know - my use of PPCMC7 is silent ie I have a 360P script shortcut in the dock and PPCMC7 is never opened. I guess I'm not your target user
I think one of the biggest hurdles for Youtube viewing on older Macs is actually getting a Youtube URL with a degree of efficiency. I use 1 Windows browser which defaults to a Google video search - in the past I've also used Links2 in Terminal.
Requesting anyone running Mac OS X 10.3.9 for help in testing a new beta build of PPCMC7 (or give me a dmg of your 10.3.9 partition).
I got Python 3.10.15 in this new beta build working on Tiger. This is as far as the original Xcode compiler (C99 standard) can go without rewriting major stuff, Python 3.11 and up is C11. Very similar story with newer versions of FFmpeg. I can't belive PowerPC Macs outlasted the C99 standard being relevent for big open source projects. I'm going to have to figure out how to get a C11 compiler targeting panther eventually.
This is great but I can't really further debug it for Panther without actually seeing what it does on Mac OS X 10.3.9.
I went to install 10.3.9 just now, and realized I can't install 10.3.9 on an iBook G4 mid 2005 🤦♂️. I am now heavily considering getting a iBook G4 2003/2004 (which would also allow two-finger touchpad right click with an additional app on Tiger from what I understand).
I saw https://forums.macrumors.com/thread...early-2005-powerbook-g4.2204504/post-28352708 and https://forums.macrumors.com/thread...ibook-g4.2369161/?post=31708412#post-31708412 as possible ways forward with my current iBook G4. Honestly the latter might be enough if someone can give me a dmg of their 10.3.9 partition. If the sound driver from the 10.4.2 iBook G4 install disc works (https://archive.org/details/ibook-2005) then I can use an ethernet to wifi adapter and usb mouse. Would definitely be happy until I can get a real panther machine again. Even if the sound doesn't work, I can still do the important part of testing (seeing if the executables actually run on Panther, I know FFplay sound works already on Panther its really just OpenSSL and Python and other back end stuff I need to see if it works).
I got Python 3.10.15 in this new beta build working on Tiger. This is as far as the original Xcode compiler (C99 standard) can go without rewriting major stuff, Python 3.11 and up is C11. Very similar story with newer versions of FFmpeg. I can't belive PowerPC Macs outlasted the C99 standard being relevent for big open source projects. I'm going to have to figure out how to get a C11 compiler targeting panther eventually.
This is great but I can't really further debug it for Panther without actually seeing what it does on Mac OS X 10.3.9.
I went to install 10.3.9 just now, and realized I can't install 10.3.9 on an iBook G4 mid 2005 🤦♂️. I am now heavily considering getting a iBook G4 2003/2004 (which would also allow two-finger touchpad right click with an additional app on Tiger from what I understand).
I saw https://forums.macrumors.com/thread...early-2005-powerbook-g4.2204504/post-28352708 and https://forums.macrumors.com/thread...ibook-g4.2369161/?post=31708412#post-31708412 as possible ways forward with my current iBook G4. Honestly the latter might be enough if someone can give me a dmg of their 10.3.9 partition. If the sound driver from the 10.4.2 iBook G4 install disc works (https://archive.org/details/ibook-2005) then I can use an ethernet to wifi adapter and usb mouse. Would definitely be happy until I can get a real panther machine again. Even if the sound doesn't work, I can still do the important part of testing (seeing if the executables actually run on Panther, I know FFplay sound works already on Panther its really just OpenSSL and Python and other back end stuff I need to see if it works).
Ok, so this is quite interesting (to me anyways, possibly to you as well).
Even back in 2021, I knew that I couldn’t build an OpenSSL targeting 10.3.9 that had threading enabled. The way threading is implemented in OpenSSL is not compatible with 10.3.9 (but is for 10.4.0). So the built executable and libraries with threading enabled won’t run on 10.3.9. My fix at the time (and still) is to build it without threads for the panther build.
Now I was interested in upgrading the Python 3.6.13 to something YouTube-dlp can use. For those that don’t know, the original youtube-dl is actively maintained now (unlike back in 2021) and usable on Python 2.7 and Python 3.2+. Updating Python would just also allow users to use DLP (if something only worked in DLP they could select that as the YouTube downloader to use). I’m still not really even sure if DLP is definitively better than the original YouTube-dl yet. Both seem fine to me.
The biggest issue I have with DLP is it ‘moves fast and breaks things’. Just 2 days ago, they removed even Python 3.8 support and now require Python 3.9.
Now the way I’m targeting panther is by using the original GCC 4.0 Xcode 2.5 compiler at the Mac OS X Deployment Target level of 10.3. So the absolute highest I can push this is Python 3.10.x. Python 3.11 and up requires the C11 standard which is not possible with GCC 4.
So 3.10.15, latest 3.10.x version (still getting security updates) i finesse into building with GCC4.0 and it even works on tiger. But alas, it needs a threaded OpenSSL (Python maintainers think everyone with an up to date OpenSSL has threads enabled!). So it can’t actually run on 10.3.9. I think there are other issues too with Python 3.10.15 itself unrelated to the OpenSSL threading requirement in regards to being built on the 10.4 SDK @ the 10.3 API level. I mean I’ve fixed issues with that before (SDL2.0.3 had very similar issues when I fixed it for Panther SDL 2.0.3. But this is a lot more extensive to figure out then that was.
So basically:
Panther build gets python3.6 and YouTube-dl
Tiger/Leopard builds get python3.10.15 and an option of either YouTube-dl or youtube-dlp
I actually kinda want to benchmark Python 2.7 vs 3.6 to see if 2.7 is faster. Since we only need 2.7 (YouTube-dl works again unlike 2021 and dlp has no chance in hell of working on panther anytime soon, unlike in 2021 when it only required Python 3.6) and it’s probably less complex/faster on older machines.
Even back in 2021, I knew that I couldn’t build an OpenSSL targeting 10.3.9 that had threading enabled. The way threading is implemented in OpenSSL is not compatible with 10.3.9 (but is for 10.4.0). So the built executable and libraries with threading enabled won’t run on 10.3.9. My fix at the time (and still) is to build it without threads for the panther build.
Now I was interested in upgrading the Python 3.6.13 to something YouTube-dlp can use. For those that don’t know, the original youtube-dl is actively maintained now (unlike back in 2021) and usable on Python 2.7 and Python 3.2+. Updating Python would just also allow users to use DLP (if something only worked in DLP they could select that as the YouTube downloader to use). I’m still not really even sure if DLP is definitively better than the original YouTube-dl yet. Both seem fine to me.
The biggest issue I have with DLP is it ‘moves fast and breaks things’. Just 2 days ago, they removed even Python 3.8 support and now require Python 3.9.
Now the way I’m targeting panther is by using the original GCC 4.0 Xcode 2.5 compiler at the Mac OS X Deployment Target level of 10.3. So the absolute highest I can push this is Python 3.10.x. Python 3.11 and up requires the C11 standard which is not possible with GCC 4.
So 3.10.15, latest 3.10.x version (still getting security updates) i finesse into building with GCC4.0 and it even works on tiger. But alas, it needs a threaded OpenSSL (Python maintainers think everyone with an up to date OpenSSL has threads enabled!). So it can’t actually run on 10.3.9. I think there are other issues too with Python 3.10.15 itself unrelated to the OpenSSL threading requirement in regards to being built on the 10.4 SDK @ the 10.3 API level. I mean I’ve fixed issues with that before (SDL2.0.3 had very similar issues when I fixed it for Panther SDL 2.0.3. But this is a lot more extensive to figure out then that was.
So basically:
Panther build gets python3.6 and YouTube-dl
Tiger/Leopard builds get python3.10.15 and an option of either YouTube-dl or youtube-dlp
I actually kinda want to benchmark Python 2.7 vs 3.6 to see if 2.7 is faster. Since we only need 2.7 (YouTube-dl works again unlike 2021 and dlp has no chance in hell of working on panther anytime soon, unlike in 2021 when it only required Python 3.6) and it’s probably less complex/faster on older machines.
Last edited:
I tried searching for this but to no avail so I guess this hasn't been brought up.
Why support Panther at all?
It sounds like a colossal headache for targeting a niche within a niche; I personally rarely see Panther mentioned on this board-- it's always Tiger/Leopard/even SL Betas are more mentioned, indicating to me that there's a very small potential Panther crowd.
I mean if you want to that's perfectly fine and you can just wave me off.
Why support Panther at all?
It sounds like a colossal headache for targeting a niche within a niche; I personally rarely see Panther mentioned on this board-- it's always Tiger/Leopard/even SL Betas are more mentioned, indicating to me that there's a very small potential Panther crowd.
I mean if you want to that's perfectly fine and you can just wave me off.
Back in 2020 when was this forked it was a defining feature of PPCMC7 versus PPCMC6.
There is a chicken and egg problem with Panther. There is no software so there is little interest and then little users. I tried to solve this, I did things like Links2 for 10.3.9+ (also coming back eventually) and whatnot.
Even if I'm the only panther user, I find it absolutely fascinating solving problems like this. It being a headache is what makes it so worthwhile. The fact that using the 10.4 SDK at the 10.3 API level mostly gets you all the way to 10.3.9 compatibility, then you just need to figure out the annoying bits that don't have availability in the 10.3 API. It's also interesting to see what the 10.3 API level doesn't provide (unicode stuff, atomics, and more advanced threads mostly it seems).
Also, early PPC Macs can't run Tiger without hacks (which are cool but say you just want to run the last officially supported version?) I think it might be slightly more lightweight but its really debatable. On the flipside, what if you want to take a newer PPC Mac as low as it can go and do something interesting with it?
Finally, it all comes togther for Panther!
Last edited:
OK, so currently DLP is way better. We can only get the-360p MP4 formats really with the original DL,
DLP will be the Tiger default, and the original youtube-dl the only option for panther.
If I keep tweaking the web interface, and get it to work on modern operating systems, that is probably a billion times better then a native panther build at this point since a modern OS can handle DLP just fine (unlike panther). Panther builds nonetheless wil still certainly exist, I just wish DLP didin't target python 3.9...
DLP will be the Tiger default, and the original youtube-dl the only option for panther.
If I keep tweaking the web interface, and get it to work on modern operating systems, that is probably a billion times better then a native panther build at this point since a modern OS can handle DLP just fine (unlike panther). Panther builds nonetheless wil still certainly exist, I just wish DLP didin't target python 3.9...
Last edited:
60 to 80% CPU utilization playing (using FFplay v4.4.5) a downloaded 480p YouTube video on an iBook G4 mid 2005 (1.33Ghz G4 512MB RAM) ain't bad and looks great. That's with no frameskip or skip loop filter options (when you have a newer G4 you can optionally enable those for better performance in the PPCMC7 preferences, that's what the "slow G4" option is. Older G4s and all G3s auto-enable this).
PPPCMC 7.2.7 is delayed to November 1st. I was really hoping for an October 31st release, because of the whole raising the dead thing. Sadly I’ve just made the final changes to the build system and started it up a few minutes ago. Which will take about 8 hours total (panther and tiger builds respectively take about 4 hours each to compile).
Polished like snow leopard. New features like leopard. I can’t wait for you to try it out and tell me your thoughts!
Polished like snow leopard. New features like leopard. I can’t wait for you to try it out and tell me your thoughts!
This is insane. My build script was not broken all this time. Tiger bash has the most obscure bug that triggers with this.
---------------------------------------------------
Build script layout:
build_ffmpeg()
compile_deps() - this compiles everything, and at the end calls build_ffmpeg() multiple times to create a fat ppc750/ppc7400/ppc7450
(execution actually starts here, because we need to define functions above us to call them)
sets bash shell $PATH to search through /Applications/PPCMC.app/bin and the source tree's deps/bin folder.
compiles newer build tools such as the latest GNUMake (which is needed to run compile_deps() successfully). It installs them into the source tree in a 'deps' folder, so it is self contained. So you have like the source tree and then a deps/bin/make command inside of it.
Then I call compile_deps() with the panther arg, and then with the tiger arg to generate releases.
--------------------------------------------------------
THE BUG
compile_deps() calls build_ffmpeg() but doesn't inherit the $PATH variable set IF the script has been executing for multiple hours. So it uses the ancient Tiger shipped original make which can't handle building FFmpeg and errors out. I forgot what this looks like because I hadn't encountered since 2020 when I started building my own GNUMake to build FFmpeg.
I came up with a debug test that built only FFmpeg after a failed build of FFmpeg occurred in the last execution of ./build (so all build dependencies and libraries were there to compile it still, not a clean build) and it worked. build_ffmpeg() inherited the correct environment and the $PATH told it to use our new GNUMake and it builds.
So if you define variables after you define functions you'll use later, call a function, that function runs for hours with the variables inherited, and then calls another function, that other function wont inherit the variables.
THE FIX
Set $PATH variables at start of execution and in build_ffmpeg().
---------------------------------------------------
Build script layout:
build_ffmpeg()
compile_deps() - this compiles everything, and at the end calls build_ffmpeg() multiple times to create a fat ppc750/ppc7400/ppc7450
(execution actually starts here, because we need to define functions above us to call them)
sets bash shell $PATH to search through /Applications/PPCMC.app/bin and the source tree's deps/bin folder.
compiles newer build tools such as the latest GNUMake (which is needed to run compile_deps() successfully). It installs them into the source tree in a 'deps' folder, so it is self contained. So you have like the source tree and then a deps/bin/make command inside of it.
Then I call compile_deps() with the panther arg, and then with the tiger arg to generate releases.
--------------------------------------------------------
THE BUG
compile_deps() calls build_ffmpeg() but doesn't inherit the $PATH variable set IF the script has been executing for multiple hours. So it uses the ancient Tiger shipped original make which can't handle building FFmpeg and errors out. I forgot what this looks like because I hadn't encountered since 2020 when I started building my own GNUMake to build FFmpeg.
I came up with a debug test that built only FFmpeg after a failed build of FFmpeg occurred in the last execution of ./build (so all build dependencies and libraries were there to compile it still, not a clean build) and it worked. build_ffmpeg() inherited the correct environment and the $PATH told it to use our new GNUMake and it builds.
So if you define variables after you define functions you'll use later, call a function, that function runs for hours with the variables inherited, and then calls another function, that other function wont inherit the variables.
THE FIX
Set $PATH variables at start of execution and in build_ffmpeg().
Last edited: