PowerPC Media Center 7.2.1 - Now With The Latest FFplay Media Player For All Macs Running Mac OS X 10.3.9+

[Dronecatcher]

I think that uses the 2005 Mplayer, which can't be used for streaming. I tried it when initially implementing Mplayer support.

It does work for streaming when just using straight youtube-dl - this has been an oddity for a while - can't be used with Viewtube for example.

 

[alex_free]

It does work for streaming when just using straight youtube-dl - this has been an oddity for a while - can't be used with Viewtube for example.

When I tried piping youtube streams into it the stream never started (same thing now happening with VLC 0.9.1). QuickTime remains working however.

 

[Dronecatcher]

When I tried piping youtube streams into it the stream never started (same thing now happening with VLC 0.9.1). QuickTime remains working however.

It was working when testing PPCMC the other week - maybe a recent youtube change? Will test again later if I get time - either way, the time taken for parsing the URL on a slow G3 is pretty intolerable and more a POC at this stage.

EDIT: Old version still working with youtube-dl for streaming in Snow Leopard...

 

[vddrnnr]

Hi @alex_free,

Regarding the problems with Snow Leopard and ffplay they are not Intel related.
I'm using the SL PPC betas and they also fail with the SDL error when trying to use ffplay.
Mplayer is working fine with the 7.2 version.

Do you know if there is a way to make ffplay not use SDL?

Best regards,
voidRunner

 

[TheShortTimer]

It was working when testing PPCMC the other week - maybe a recent youtube change? Will test again later if I get time - either way, the time taken for parsing the URL on a slow G3 is pretty intolerable and more a POC at this stage.

EDIT: Old version still working with youtube-dl for streaming in Snow Leopard...

Does this mean that a version with mViewX is possible?

In the meanwhile, 7.2.1 with the amended prefs file is working like a champ on my G3/800.

There's a noticeable slight pause whilst the video is being obtained but that's a minor issue - it works and that's the main thing!

Thanks a bunch @alex_free.

 

[Dronecatcher]

Does this mean that a version with mViewX is possible?

I don't see why not

 

[alex_free]

Does this mean that a version with mViewX is possible?

In the meanwhile, 7.2.1 with the amended prefs file is working like a champ on my G3/800.

There's a noticeable slight pause whilst the video is being obtained but that's a minor issue - it works and that's the main thing!

Thanks a bunch @alex_free.

That is insane! Thanks @Dronecatcher I'll definitely add a better performance option.

 

[alex_free]

It was working when testing PPCMC the other week - maybe a recent youtube change? Will test again later if I get time - either way, the time taken for parsing the URL on a slow G3 is pretty intolerable and more a POC at this stage.

EDIT: Old version still working with youtube-dl for streaming in Snow Leopard...

View attachment 975857

In that case a future version could allow you to select a mplayer binary manually, thanks for verifying. Good test case btw. I have an idea to speed up parsing URLs. It probably is much faster if youtube-dlc is decompressed and the extracted .py script is used directly,

 

[alex_free]

Hi @alex_free,

Regarding the problems with Snow Leopard and ffplay they are not Intel related.
I'm using the SL PPC betas and they also fail with the SDL error when trying to use ffplay.
Mplayer is working fine with the 7.2 version.

Do you know if there is a way to make ffplay not use SDL?

Best regards,
voidRunner

Interesting, SDL2 is definitely required for FFplay.

 

[MacFoxG4]

Hi @alex_free,

Regarding the problems with Snow Leopard and ffplay they are not Intel related.
I'm using the SL PPC betas and they also fail with the SDL error when trying to use ffplay.
Mplayer is working fine with the 7.2 version.

Do you know if there is a way to make ffplay not use SDL?

Best regards,
voidRunner

I can confirm that this is indeed an issue with Snow Leopard. I installed Leopard onto an external FireWire 800 SSD drive connected to my MBP and ffplay will run under Intel Leopard. Much like my iBook G3, h264 video playback has issues, but MPEG 4 part 2 videos play just fine, which makes sense given that I am using Rosetta.

 

[alex_free]

I can confirm that this is indeed an issue with Snow Leopard. I installed Leopard onto an external FireWire 800 SSD drive connected to my MBP and ffplay will run under Intel Leopard. Much like my iBook G3, h264 video playback has issues, but MPEG 4 part 2 videos play just fine, which makes sense given that I am using Rosetta.

That’s very strange a Mac mini G4 can outperform a MacBook Pro using Rosetta. I have no issue playing back downloaded 480p H.264 YouTube videos on the mini.

Have you tried Dronecatcher’s additional args?:

-skip_frame 8 -skip_loop_filter 48

You can add them when editing the preferences, I’ll add them as an additional FFplay preference option in a future update as well. @TheShortTimer said it greatly improved G3 playback to being usable on his iBook 800MHz. I’m gonna see what happens on my 300MHz clamshell and see if it can play MPEG-1 with them.

Im going to look into what I can do about snow leopard, thanks again to you and @vddrnnr for bringing this issue to my attention.

 

[MacFoxG4]

That’s very strange a Mac mini G4 can outperform a MacBook Pro using Rosetta. I have no issue playing back downloaded 480p H.264 YouTube videos on the mini.

Have you tried Dronecatcher’s additional args?:

-skip_frame 8 -skip_loop_filter 48

You can add them when editing the preferences, I’ll add them as an additional FFplay preference option in a future update as well. @TheShortTimer said it greatly improved G3 playback to being usable on his iBook 800MHz. I’m gonna see what happens on my 300MHz clamshell and see if it can play MPEG-1 with them.

Im going to look into what I can do about snow leopard, thanks again to you and @vddrnnr for bringing this issue to my attention.

You're welcome. One thing that surprised me during these tests was Rosetta reporting itself as a G4 7400. I had always heard that Rosetta was like a G3 and my experiences with Rosetta have showed me that PPC native apps behave like they would on a G3, though in the case of PPCMC video conversion is faster in Rosetta than on a G3. I assume this is due to Rosetta supporting Altivec. I wonder if Rosetta always reports itself as a G4 7400 or if it only does that if the program asks for Altivec?

I tried the command args on both the iBook G3 and on the MBP and both showed an improvement for h264 playback in ffplay. The h264 video I have been using is 360p. There is some slowdown here and there, but the video is actually watchable now. This is true of both the iBook G3 and Rosetta. Overall, I like ffplay. It's great to have h264 videos be watchable on my iBook G3. I usually convert any video I download on my G3 to MPEG 4 part 2, but now with ffplay I can watch the downloaded video without needing to wait and convert it first.

 

[vddrnnr]

Hi @alex_free,

I've been trying out running the terminal commands you are using
when doing youtube streaming through a "do shell script" inside
an applescript script.
As far as I can see they run fine, although I don't get any output to see if an error
happens.
Maybe this can be an improvement ( IMHO ) to not make it depend on terminal at least
for streaming. This is because if you already have terminal running this makes you jump
to the workspace where terminal started when opening the new window.

I've also tried another thing which might be a way to find if using youtube-dl has failed.
If you run it using "-f <format> -g" or just "-g" you get the url of the video as output.
This way you can check if it returns an url for the video and see if it failed.
You can set a variable to the result of "do shell script" and then run
for example mplayer feeding this url directly to it instead of piping what youtube-dl is
streaming. From my tests at least with mplayer it seems to lower cpu usage a few percent.

To not have applescript blocked by running mplayer through "do shell script" you can add
" > /dev/null 2 > &1 & ". This will make "do shell script" release without waiting for mplayer
to finish.

Best regards,
voidRunner

 

[alex_free]

You're welcome. One thing that surprised me during these tests was Rosetta reporting itself as a G4 7400. I had always heard that Rosetta was like a G3 and my experiences with Rosetta have showed me that PPC native apps behave like they would on a G3, though in the case of PPCMC video conversion is faster in Rosetta than on a G3. I assume this is due to Rosetta supporting Altivec. I wonder if Rosetta always reports itself as a G4 7400 or if it only does that if the program asks for Altivec?

I tried the command args on both the iBook G3 and on the MBP and both showed an improvement for h264 playback in ffplay. The h264 video I have been using is 360p. There is some slowdown here and there, but the video is actually watchable now. This is true of both the iBook G3 and Rosetta. Overall, I like ffplay. It's great to have h264 videos be watchable on my iBook G3. I usually convert any video I download on my G3 to MPEG 4 part 2, but now with ffplay I can watch the downloaded video without needing to wait and convert it first.

That bit about Rosetta, I think it does just pretend to be a 7400. The ffplay binary for example has all these arches:
ppc
ppc750
ppc7400
ppc7450

It should want the 7450 but it picks 7400 anyways.

I'm glad you like FFplay, it was alot of work to get it on panther.

The 300MHz clamshell is still a slideshow (albeit a faster one) unfortunately even with the args.

 

[alex_free]

Hi @alex_free,

I've been trying out running the terminal commands you are using
when doing youtube streaming through a "do shell script" inside
an applescript script.
As far as I can see they run fine, although I don't get any output to see if an error
happens.
Maybe this can be an improvement ( IMHO ) to not make it depend on terminal at least
for streaming. This is because if you already have terminal running this makes you jump
to the workspace where terminal started when opening the new window.

I've also tried another thing which might be a way to find if using youtube-dl has failed.
If you run it using "-f <format> -g" or just "-g" you get the url of the video as output.
This way you can check if it returns an url for the video and see if it failed.
You can set a variable to the result of "do shell script" and then run
for example mplayer feeding this url directly to it instead of piping what youtube-dl is
streaming. From my tests at least with mplayer it seems to lower cpu usage a few percent.

To not have applescript blocked by running mplayer through "do shell script" you can add
" > /dev/null 2 > &1 & ". This will make "do shell script" release without waiting for mplayer
to finish.

Best regards,
voidRunner

The get url thing is actually how QuickTime streaming works. That would make sense to use for YouTube streaming, I'd have to check if Twitch works as well. I can see how much more 'clean' this app can get though now.

That bit about redirecting to /dev/null and putting it in the background, that's really smart. I was using terminal because otherwise I'd have the AppleScript app essentially "loading" all the time while it was playing.

Not sure when the next release is but I'll definitely try the above out and if I use the ideas credit you in the changelog.

 

[alex_free]

PowerPC Media Center 7.2.1 is now also available on GitHub:

Releases · alex-free/powerpc-media-center

Contribute to alex-free/powerpc-media-center development by creating an account on GitHub.

github.com

GitHub - alex-free/powerpc-media-center: YouTube/Twitch Downloader/Streamer For Mac OS X 10.3.9-10.5.8.

YouTube/Twitch Downloader/Streamer For Mac OS X 10.3.9-10.5.8. - alex-free/powerpc-media-center

github.com

 

[vddrnnr]

Hi @alex_free,

Youtube-dl is mostly failing on youtube.
I think youtube changed something in the video pages so
now it fails almost 100%.
I think it's fixable since Viewtube from Sebaro already issued an update dated today and
videos are working again.
I know it's not up to you but do you have any ideas for this?

PS. no need to give credit for /dev/null I'm glad I can help
I've also done some more testing on this and found you also need to put the call to
"do shell script" inside a "try" block to catch some of the errors so the script
won't break.

Best regards,
voidRunner

 

[alex_free]

Hi @alex_free,

Youtube-dl is mostly failing on youtube.
I think youtube changed something in the video pages so
now it fails almost 100%.
I think it's fixable since Viewtube from Sebaro already issued an update dated today and
videos are working again.
I know it's not up to you but do you have any ideas for this?

PS. no need to give credit for /dev/null I'm glad I can help
I've also done some more testing on this and found you also need to put the call to
"do shell script" inside a "try" block to catch some of the errors so the script
won't break.

Best regards,
voidRunner

So it turns out YouTube-dlc had a fix pushed to git days ago that fixes every error so far, it works just as good as it used too months ago. That fix is not yet available in any release as there has not been a new official release yet. If you take the latest YouTube-dlc source though you’ll have no errors.

To prevent this from happening again, I think a new additional update option in PPCMC will allow you to update to the latest commit (using git), not just the latest official update of YouTube-dlc. So you can get fixes before even official releases exist containing them.

 

[vddrnnr]

Hi @alex_free,

I did the youtube-dl update with PPCMC and a new release dated today downloaded
and it's working now
Thanx

Best regards,
voidRunner

 

[alex_free]

Hi @alex_free,

I did the youtube-dl update with PPCMC and a new release dated today downloaded
and it's working now
Thanx

Best regards,
voidRunner

That’s great they pushed a new release! YouTube from what I can tell intentionally broke everything to make the original YouTube-dl officially useless. That’s why I switched to YouTube-dlc.

 

[vddrnnr]

Hi @alex_free,

Just to let you know that I tried the idea you posted about using youtube-dlc
unpacked by downloading the current sources from git.
It works fine and it shaves off a few seconds when retrieving
the download URLs ( at least in my tests in a DLSD between 4 and 5 seconds)

You just need to download it somewhere maybe directly inside de app and then
move youtube-dl to a backup like youtube-dl-orig abd then
create a symlink ( ln -s ) from youtube-dl inside bin to

<folder with sources from git>/yt-dlc/youtube_dlc/__main_.py

Also take a look at this link where I found the relevant info on this.

Speeding up youtube-dl - Raspberry Pi Forums

www.raspberrypi.org

Best regards,
voidRunner

 

[alex_free]

Hi @alex_free,

Just to let you know that I tried the idea you posted about using youtube-dlc
unpacked by downloading the current sources from git.
It works fine and it shaves off a few seconds when retrieving
the download URLs ( at least in my tests in a DLSD between 4 and 5 seconds)

You just need to download it somewhere maybe directly inside de app and then
move youtube-dl to a backup like youtube-dl-orig abd then
create a symlink ( ln -s ) from youtube-dl inside bin to

<folder with sources from git>/yt-dlc/youtube_dlc/__main_.py

Also take a look at this link where I found the relevant info on this.

Speeding up youtube-dl - Raspberry Pi Forums

www.raspberrypi.org

Best regards,
voidRunner

I’m surprised on that Mac it made such a difference. I was thinking more about my 300MHz Clamshell

When I first heard this was thing in Python, I honestly questioned if the trade offs of having to uncompress a binary every run was really worth it for such little space savings.