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



I never used plain ffmpeg since in my set up both qmplay2 and mpv performed better.
If you can identify any fixes or opportunities to build on what I have here please let me know - this is just research/experimentation at this point.

Some modern codecs like AV1 are definitely more data-intensive than h264, but there is no reason this needs to be fatal, even on a G4. This is exactly the kind of stuff that SIMD instructions can help us with - nobody has bothered to write out AltiVec pathways for these codecs, but it doesn't mean the hardware isn't capable.

The goal with these FFmpeg optimizations is to create a CorePlayer-type experience I can combine with AquaCenter's pacing and player experience, with first class PPC decoding, being more than willing to drop frames, skip IDCT/run optimized CABAC calculations, and squeeze every CPU cycle, sacrificing visual quality for smooth playback.

This is also why I think running a bunch of hypothetical frame math for these machines is pretty pointless. I don't think anybody is asking for 2160p 10bit video to be playable on their G3. But a G5 Quad? These are totally realistic goals to achieve, and the improved end-user experience by doing it all on-device is worth the effort imo.
 
nobody has bothered to write out AltiVec pathways for these codecs, but it doesn't mean the hardware isn't capable.

dav1d has powerpc SIMD, but they should be adjusted for our case.

libvpx also has powerpc SIMD, but they are largely broken, and, as I recall, only cover VP8 but not VP9. Still may be better than to start from scratch.
 
  • Like
  • Love
Reactions: z970 and srp
> 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.

Was it with default keyframe interval? (250 in ffmpeg IIRC) ?

I think motion estimation at encoding takes most cpu time, so in theory (!) setting keyframe to all-I-frames (g=1) should speed up encoder considerably?

On x86 (celeron/P2 at around 433 Mhz) I had such lines for mencoder-based tv capture back in 2005:


Code:
vcodec=asv1:vqscale=2:keyint=2
for width=384:height=288 and 25 fps I guess (because SECAM)

ASV1 is Asus V1 video codec, blocky a bit, but fastest. ffmpeg/libavcodec has support for it since around 2003.
 
Optimised Tiger runs pretty well on my iMac G3/350 with an SSD.

In theory, a thoroughly optimized Tiger should run even better than both Panther and Jaguar on weaker hardware (Classic notwithstanding). If I recall correctly, it ran less processes, used less total CPU threads, and (I believe) used at least a similar amount of RAM to Jaguar. I don't think there's ever been a direct detailed comparison between the three though, particularly in OpenGL performance.

Plus you get all the compatibility / usability improvements Tiger brings over its predecessors, which many would say is worth a small hit in performance anyway.


If you don't want to manually input terminal commands and keep track of changes made, then technically this also exists, if it's of any use:

 
Last edited:
Was it with default keyframe interval? (250 in ffmpeg IIRC) ?

I think motion estimation at encoding takes most cpu time, so in theory (!) setting keyframe to all-I-frames (g=1) should speed up encoder considerably?

On x86 (celeron/P2 at around 433 Mhz) I had such lines for mencoder-based tv capture back in 2005:


Code:
vcodec=asv1:vqscale=2:keyint=2
for width=384:height=288 and 25 fps I guess (because SECAM)

ASV1 is Asus V1 video codec, blocky a bit, but fastest. ffmpeg/libavcodec has support for it since around 2003.
Oh I'll definitely have to give that a shot.

Earlier in this process I was a bit shocked to learn that the default keyframe interval for MPEG-1 was only 12!
 
  • Like
Reactions: Appleuser201
In theory, a thoroughly optimized Tiger should run even better than both Panther and Jaguar on weaker hardware (Classic notwithstanding). If I recall correctly, it ran less processes, used less total CPU threads, and (I believe) used at least a similar amount of RAM to Jaguar. I don't think there's ever been a direct detailed comparison between the three though, particularly in OpenGL performance.

Plus you get all the compatibility / usability improvements Tiger brings over its predecessors, which many would say is worth a small hit in performance anyway.



If you don't want to manually input terminal commands and keep track of changes made, then technically this also exists, if it's of any use:

I have Shuriken running on my 12 inch Powerbook 1.5ghz. Runs amazing, and Aquafox is super fast on it especially with KaiOS UA. Powerfox works too, obviously a lot slower.
 
  • Like
Reactions: z970
I applaud developments like this - well done, although running a proxy/helper on my network is not my bag.

TigerTube would be an efficient portal to grabbing URLs for existing Youtube playback solutions - any chance of incorporating a "copy url" option into a future release?

Also, have you explored the proxy being based on a VPS (requiring manual addressing obviously) - that would give a more untethered appeal and work from any machine from any location?

Obviously, a shift to MPEG4 (Apple compressor) or similar would be needed to counter bandwidth problems.
 
I applaud developments like this - well done, although running a proxy/helper on my network is not my bag.

TigerTube would be an efficient portal to grabbing URLs for existing Youtube playback solutions - any chance of incorporating a "copy url" option into a future release?

Also, have you explored the proxy being based on a VPS (requiring manual addressing obviously) - that would give a more untethered appeal and work from any machine from any location?

Obviously, a shift to MPEG4 (Apple compressor) or similar would be needed to counter bandwidth problems.
Thanks for the feedback!

Using it solely as a YouTube API browser is an interesting idea. I could add an option to make a table row click result in "copy to clipboard" rather than "open player window". Potentially I could also have it execute a command instead (e.g. launch mplayer or whatever).

Yeah, going outside of your local LAN would require a bump in codec, but G4's and G5's could definitely handle MPEG4 and good resolutions. Right now, the proxy URL is discovered via Bonjour (ZeroConf), but I could also add in a setting for a custom proxy url.

Well, actually, even MPEG-1 would still be an option for a vps proxy if ffmpeg caps the bandwidth (i.e. target bitrate mode rather than target quality mode). And for a G3, it will likely be playing at 320x240, which likely won't be more than 2 or 3 Mbit, which a vps shouldn't have a problem with.

I'll work something up.
 
  • Love
Reactions: TheShortTimer
How "modern" does the second Mac need to be to run the proxy? I'm wondering if this would work on some of my older Macs that are already being used for other things regularly, rather than my MacBook which isn't always online.
 
  • Like
Reactions: TheShortTimer
How "modern" does the second Mac need to be to run the proxy? I'm wondering if this would work on some of my older Macs that are already being used for other things regularly, rather than my MacBook which isn't always online.
I'm actually not sure, but probably not that modern, the default is to use a 720p source (if I remember correctly) and transcode down from there, which is a pretty light load. An early-gen i3 would be fine, I would think.
 
  • Like
Reactions: Slix
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.