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

TigerTube: a YouTube client for Tiger/PowerPC

cellularmitosis

cellularmitosis

macrumors regular
Original poster
I've been working on a YouTube client for PowerPC Macs: https://github.com/cellularmitosis/TigerTube

Can I get a few folks to beta test it?

This release is targeted at G3 Macs running Tiger (MPEG-1 video, raw audio), but should also run on G4/G5/Leopard.

Later releases will include a second codec (probably MPEG-4/Divx) and more resolution options when run on an Altivec-class Mac.

Instructions:​


Download the zip file here: https://github.com/cellularmitosis/TigerTube/releases/download/v0.3/TigerTube-0.3.zip

Unpack the zip, run TigerTube.app to your PowerPC Mac, and run proxy/tigertube-proxy.py on a modern laptop (on the same LAN as your PowerPC Mac). The (Python) proxy script will nag you to install the required dependencies (ffmpeg, yt-dlp, python-zeroconf).

Open TigerTube.app and search for a topic, then click on a video. TigerTube.app will request the video from the proxy script, which will fetch the video using yt-dlp and transcode it in real-time into MPEG-1 using ffmpeg, and stream it to TigerTube.app.

tigertube-0.3.png
 
  • Like
  • Love
Reactions: Dronecatcher, rb2112, maxoakland and 7 others
If you are curious, this was mostly vibe-coded over the course of about 4 days using Claude Code (Opus 4.6 and 4.7) (although the HTTP layer in the proxy script was pulled from a project which I had previously written). I transitioned from Objective-C to Swift about 12 years ago for my day job, so I while was able to follow along, I didn't actually write any of the Objective-C.

I am extremely impressed with Claude Code and simultaneously terrified of losing my job.
 
  • Like
  • Haha
Reactions: Ethan.Albano, Costco150HotDawgCombo, jjrtiger and 2 others
Why do you need a proxy? You can't just build curl + openssl and handle web requests on device?
 
srp said:
Why do you need a proxy? You can't just build curl + openssl and handle web requests on device?
Click to expand...
Yeah that’s exactly what the app does for search results JSON and thumbnails (see the libs directory).

The issue is that modern video codecs simply require too much horsepower. The proxy is just there to transcode the video into an older codec (and lower resolution)
 
cellularmitosis said:
Yeah that’s exactly what the app does for search results and thumbnails (see the libs directory).

The issue is that modern video codecs simply require too much horsepower. The proxy is just there to transcode the video into an older codec (and lower resolution)
Click to expand...
Huh? yt-dlp allows you to stream a feed in your preferred codec and resolution... swscale/AltiVec is there for hardware downsampling...

With pure ffplay + yt-dlp, an iBook G4 can easily play back a 480p h264 YouTube video. I think you (or Claude) are underestimating what these devices are truly capable of...
 
Cool idea and application, but if it requires a modern computer or a proxy its a no go for me. I agree with the other commenters above, this app could be amazing and it could be made to be independent and have the mac itself convert the video.
 
  • Like
Reactions: Slix
srp said:
Huh? yt-dlp allows you to stream a feed in your preferred codec and resolution... swscale/AltiVec is there for hardware downsampling...

With pure ffplay + yt-dlp, an iBook G4 can easily play back a 480p h264 YouTube video. I think you (or Claude) are underestimating what these devices are truly capable of...
Click to expand...

That would leave G3 Macs out of the picture.

In my testing, I found that on an Altivec-class Mac, dropping from h264 to MPEG-1 freed up enough CPU to step up a major resolution tier.

For example, my 1.42GHz G4 eMac could handle 480p h264 video probably 80% of the time, but it could handle 720p MPEG-1 without dropping any frames.

And those tests were just direct playback of local files -- they didn’t involve the additional overhead of using a python interpreter to remux a video and audio stream on the eMac, which would hindered playback even further.

Also, bundling Python, yt-dlp and ffmpeg into the app would make it much, much larger. If I use tiger.sh to install Python and ffmpeg (and all of their dependencies) on my eMac, my /opt directory sits at 487MB. TigerTube is 3MB.

Honestly, direct YouTube playback on PowerPC is a frustrating experience, and when YouTube migrates to h265, your options will drop from "frustrating" to "none".
 
cellularmitosis said:
That would leave G3 Macs out of the picture.
Click to expand...
Tiger on a G3 isn't a first class experience anyways.

cellularmitosis said:
And those tests were just direct playback of local files -- they didn’t involve the additional overhead of using a python interpreter to remux a video and audio stream on the eMac, which would hindered playback even further.
Click to expand...
Python is not the component doing the remuxing here. yt-dlp is handling extraction and ffmpeg is doing the actual remux/transcode work. I don't think Python overhead is the strongest argument for the proxy model.

cellularmitosis said:
Honestly, direct YouTube playback on PowerPC is a frustrating experience, and when YouTube migrates to h265, your options will drop from "frustrating" to "none".
Click to expand...
Have you seen the PPC media center I wrote? It already handles YouTube, Twitch, and several other web services directly on-device, and I want to add Tiger support in the future. From my perspective, Tiger is usually the harder and less worthwhile target to develop for. On Leopard, there are usable direct-playback paths already, QMPlay2, even VLC can handle streams from yt-dlp. I think it's only a matter of time before PowerFox has a JIT and we can just do all of this in browser again anyways.

cellularmitosis said:
Also, bundling Python, yt-dlp and ffmpeg into the app would make it much, much larger. If I use tiger.sh to install Python and ffmpeg (and all of their dependencies) on my eMac, my /opt directory sits at 487MB. TigerTube is 3MB.
Click to expand...
Space is not a huge concern for me on any of my Macs, in the age of mSATA and SSD upgrades etc, I’d personally rather spend 500MB locally and keep playback self-contained than require a second modern machine on the same LAN just to use the app.

There are also plenty of benefits to bundling these dependencies - for example, AquaCenter bundles an optimized version of ffmpeg that improves baseline HEVC performance.

Some of this is definitely just a difference between our use cases. But being tethered to another device is a limitation that is hard to overlook for me personally.
 
  • Like
Reactions: perrymason1980
I'll jump in and say that, yea iMac G3 on Tiger is not a first class experience. AltiVec was there primarily for people who wanted to decode and encode video. This is basically like, the limit of slower G3s really. The G3 with the Rage 128 should generally be fast enough to decode MPEG 1 and maybe MPEG 2 in time. I think the fastest iMac G3s should be able to do 480p h264 though.

The DivX option would definitely be the next step forward for this program.
 
> I think the fastest iMac G3s should be able to do 480p h264 though.

Nope, but we can speculate about what kind of hypothetical G3 you'd need.

mplayer supports a "benchmark" mode, where it renders every frame and times how long it took.

Here are the results of playing a 63 second video from three G3's I tested:

  1. PowerMac G3 (400MHz): 171.4s
  2. iMac G3 (600MHz): 157.3s
  3. iBook G3 (900MHz): 120.0s
That's not perfectly linear, but the best-case slope would be 0.124 seconds per MHz. We need to improve the iBook's time by 57 seconds, which translates to an additional 458MHz (assuming we can extrapolate linearly).

So we would need a 1,358MHz G3 to play 480p h264. Unfortunately, the fastest ever made was 900MHz.
 
  • Like
Reactions: perrymason1980
> The DivX option would definitely be the next step forward for this program.

You know that's what I was thinking originally, but after more testing I'm realizing that isn't true.

I had assumed that more advanced codecs could yield crisper video, but I'm now realizing that isn't true (edit: or rather, that is only true if you are bandwidth-limited). It turns out that if you give an MPEG-1 encoder all the bandwidth it can eat (like 10Mbit+), the output looks indistinguishable from the input.

So really, modern codecs are about trading off CPU in order to save on bandwidth, but in this case we have 100MBit Ethernet to throw at the problem

In other words, we can get higher quality video by spending our CPU on cranking up the resolution, rather than spending our CPU to save bandwidth.
 
Always cool to see new development!

My experience with Tiger on G3 Macs has been that machines with 100mhz FSB speeds (B&W G3, PowerBook Pismo, Slot-load iMac G3) seem to run it really well. Where as the 66mhz FSB models (most requiring xpostfacto to install) are a lesser experience when otherwise stock (Beige G3, PowerBook Wallstreet/Lombard, tray-load iMac G3).

Regardless though, G4 and its AltiVec (along with better stock video cards) bring much more possibilities.
 
cellularmitosis said:
> I think the fastest iMac G3s should be able to do 480p h264 though.

Nope, but we can speculate about what kind of hypothetical G3 you'd need.

mplayer supports a "benchmark" mode, where it renders every frame and times how long it took.

Here are the results of playing a 63 second video from three G3's I tested:

  1. PowerMac G3 (400MHz): 171.4s
  2. iMac G3 (600MHz): 157.3s
  3. iBook G3 (900MHz): 120.0s
That's not perfectly linear, but the best-case slope would be 0.124 seconds per MHz. We need to improve the iBook's time by 57 seconds, which translates to an additional 458MHz (assuming we can extrapolate linearly).

So we would need a 1,358MHz G3 to play 480p h264. Unfortunately, the fastest ever made was 900MHz.
Click to expand...
What if it converts the video to MPEG-1 prior to playback? How many seconds per one minute of 480p h264 do you estimate would be required?
 
> What if it converts the video to MPEG-1 prior to playback? How many seconds per one minute of 480p h264 do you estimate would be required?

Not as bad as I had thought, actually!

Some results:

  • iMac (600MHz G3):
    • Time to transcode 63 second h264 360p source video to mpeg1 240p: 2m18.112s
  • eMac (1.42GHz G4):
    • Time to transcode 63 second h264 480p source video to mpeg1 480p: 54.205s
  • iMac (2.0GHz G5):
    • Time to transcode 63 second h264 720p source video to mpeg1 720p: 1m7.062s
That approach wouldn't be too bad for short videos.
 
  • Like
Reactions: just.in.time, Andrew-R and Appleuser201
barracuda156 said:
G5 can handle h265 and even av1. Up to 1080p it should be usable. Higher resolution becomes frustrating, though for something like podcasts or news it is probably tolerable.
Click to expand...

You should take a look at my ffmpeg patch which adds AltiVec swizzling for HEVC and improves performance on baseline by about 30%. Within a year, H265 and even AV1 should be playable at 1080p on a G5.
 
  • Like
Reactions: z970, AdamBuker and Appleuser201
srp said:
You should take a look at my ffmpeg patch which adds AltiVec swizzling for HEVC and improves performance on baseline by about 30%. Within a year, H265 and even AV1 should be playable at 1080p on a G5.
Click to expand...

With 30% improvement we should have 4k working smoothly.

P. S. Where to check the patch btw?
 
barracuda156 said:
With 30% improvement we should have 4k working smoothly.

P. S. Where to check the patch btw?
Click to expand...

github.com

HEVC improvements · FFmpeg/FFmpeg@f563012

Mirror of https://git.ffmpeg.org/ffmpeg.git. Contribute to FFmpeg/FFmpeg development by creating an account on GitHub.
github.com github.com

In my experience with this build of FFmpeg, I am able to (almost) reliably playback 1080p HEVC video on my Quad, whereas the version I grabbed off of PPCPorts struggles.

There are some visual regressions that this introduces which I haven't fully resolved yet. The optimizations are targeted at improving CABAC throughput which is a huge chunk of the decoding time for HEVC video.

The 8x8 implementation is completely wrong, feel free to ignore that. These commits are still a bit of a playground.
 
  • Like
Reactions: z970 and barracuda156
srp said:
github.com

HEVC improvements · FFmpeg/FFmpeg@f563012

Mirror of https://git.ffmpeg.org/ffmpeg.git. Contribute to FFmpeg/FFmpeg development by creating an account on GitHub.
github.com github.com
Click to expand...

Thank you.

srp said:
In my experience with this build of FFmpeg, I am able to (almost) reliably playback 1080p HEVC video on my Quad, whereas the version I grabbed off of PPCPorts struggles.
Click to expand...

I never used plain ffmpeg since in my set up both qmplay2 and mpv performed better.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back