Homebrew WiiMC-SS - GameCube controller support and more

[russianjoint]

Buddie are your standards that low?, if it crashes constantly due to not being very stable, then it doesnt work.

Sorry for calling you a troll. I can see that english isn't your first language, so it is forgiveable that you are loose with your definitions.

For future reference: "unstable" and "doesn't work/is broken" are not the same thing.

 

[HandsomeJack]

Sorry for calling you a troll. I can see that english isn't your first language, so it is forgiveable that you are loose with your definitions.

For future reference: "unstable" and "doesn't work/is broken" are not the same thing.

I suspect if this app was updated to the most recent version of the underlying PPC Linux libraries it's using and compiling with a more up-to-date toolchain, it would work better (the switching files thing is likely a memory leak, deallocation not taking place in C / C++).

Thing is, given the CPU was a budget CPU in 2006, using this app at all is going to be about figuring out a target format for 576p which is stable. I suspect that's figuring out Xvid downscaling settings and using MP3 rather than AAC for audio. AAC takes more CPU to decode and is a more complex audio codec. There's likely a sweet spot for MP3 which uses little CPU, probably MP3 VBR.

Once those optimal parameters are figured out, it would like be more stable to use. The best way to document this would be as an example ffmpeg command, something like:

ffmpeg -i input.mp4 output.avi -vcodec xvid -qscale:v 4 -c:a libmp3lame -vf scale=960:576

In principle, these optimal settings should only need to be figured out once. I also suspect the defaults in ffmpeg are more likely to be in the sweet spot for this app.

The fact that it's even possible to get a Wii playing 576p video at all without dropping frames is pretty good given it's a feature Nintendo never wanted.

Post automatically merged: Dec 9, 2023

https://forums.anandtech.com/threads/h264-vs-divx-xvid.1746319/

I've been trying to find anyone who did objective testing on H.264 vs Xvid on low end CPUs and found:

"laptop test - as far as cpu usage goes, the x264 version used approximately 30-50% utilization on a p-m 725 series 1.6GHz Dothan core that according to cpu-z 1.31 clocked itself down to 600MHz while the xvid version used approx 4-15% cpu utilization, again with cpu-z reporting 600MHz for the p-m 1.6GHz Dothan core cpu."

This would explain why 576p encoded with Xvid is more stable than H.264 in this app.

 

[HandsomeJack]

OK, I've now done an objective comparison where I used JDownloader 2 to get the 1080p Gangnam Style video and converted it at three different 576p resolutions, using Xvid, H.264 Baseline, H.264 Main and H.264 High (12 files in total). All with the same MP3 audio (to reduce CPU usage compared to AAC). I have 'Skip Deblocking Filter' set to 'On' (as this does make a difference).

I tested on a Wii U in normal Wii mode (not overclocked). The Wii is set to output at 480p. On a Wii U this app will automatically switch to 576p if you select that setting and my TV reports the Wii U outputting 720x576.

The results:

- All Xvid files work flawlessly.
- All H.264 High Profile files drop frames. The higher the underlying resolution, the more horrible the frame drops, despite MP3 being used for the audio.
- 1024x576 for both Baseline and Main drop frames. Less bad but not good.
- 960x576 for Baseline didn't seem to have any dropped frames, however, Main does have dropped frames at 960x576 at a level of being horrible.
- At 720x576 Main Profile crosses the performance threshold of dropping few frames. Baseline is fine at 720x576.
- Xvid produces better image quality than Baseline, however, the file sizes are about double Baseline.
- The best compromise on file size versus quality is 720x576 Main Profile. About 40% of the file size of Xvid, less than Baseline.

The upshot is if you're not bothered about file sizes, go with Xvid. 720x576 Main Profile is likely to be useful for most purposes.

If you're new to ffmpeg, one of the advantages of it is if you have loads of files to convert you can create a batch file to bulk convert.

EDIT 1: Have discovered some input files need bit depth set to 8 bits which is achieved using the additional parameter -pix_fmt yuv420p

ffmpeg -i input.mkv -acodec libmp3lame -qscale:a 4 -vcodec libx264 -profile:v main -crf 24 -vf scale=720:576 -pix_fmt yuv420p output.mp4

For a typical movie, this will be about 300Mb per hour.

EDIT 2: Did more fine grained testing on what's the best video quality possible for Main Profile 720x576 without dropping frames. Frames start to drop at -crf 22. The optimal video setting is either -crf 24 or -crf 23. It's possible to improve audio quality with -qscale:a 2 without dropping frames. This will be quite good audio for the vast majority of TV / movie content. Again, think about the hardware constraints here in 'Budget Windows 98 PC from 1999' terms.

EDIT 3: I had a go at doing a very long movie at 576p on Main Profile. This app seems to have a scalability point where beyond a certain file size (somewhere over 1GB) or a movie length (over 3 hours) the app becomes non-responsive.

c:\ffmpeg\bin\ffmpeg.exe -i GGS.mp4 -acodec libmp3lame -qscale:a 4 -vcodec libxvid -qscale:v 4 -vf scale=1024:576 GGS-Xvid-MP3-1024.avi c:\ffmpeg\bin\ffmpeg.exe -i GGS.mp4 -acodec libmp3lame -qscale:a 4 -vcodec libxvid -qscale:v 4 -vf scale=960:576 GGS-Xvid-MP3-960.avi c:\ffmpeg\bin\ffmpeg.exe -i GGS.mp4 -acodec libmp3lame -qscale:a 4 -vcodec libxvid -qscale:v 4 -vf scale=720:576 GGS-Xvid-MP3-720.avi c:\ffmpeg\bin\ffmpeg.exe -i GGS.mp4 -acodec libmp3lame -qscale:a 4 -vcodec libx264 -profile:v baseline -crf 24 -vf scale=1024:576 GGS-Baseline-MP3-1024.mp4 c:\ffmpeg\bin\ffmpeg.exe -i GGS.mp4 -acodec libmp3lame -qscale:a 4 -vcodec libx264 -profile:v baseline -crf 24 -vf scale=960:576 GGS-Baseline-MP3-960.mp4 c:\ffmpeg\bin\ffmpeg.exe -i GGS.mp4 -acodec libmp3lame -qscale:a 4 -vcodec libx264 -profile:v baseline -crf 24 -vf scale=720:576 GGS-Baseline-MP3-720.mp4 c:\ffmpeg\bin\ffmpeg.exe -i GGS.mp4 -acodec libmp3lame -qscale:a 4 -vcodec libx264 -profile:v main -crf 24 -vf scale=1024:576 GGS-Main-MP3-1024.mp4 c:\ffmpeg\bin\ffmpeg.exe -i GGS.mp4 -acodec libmp3lame -qscale:a 4 -vcodec libx264 -profile:v main -crf 24 -vf scale=960:576 GGS-Main-MP3-960.mp4 c:\ffmpeg\bin\ffmpeg.exe -i GGS.mp4 -acodec libmp3lame -qscale:a 4 -vcodec libx264 -profile:v main -crf 24 -vf scale=720:576 GGS-Main-MP3-720.mp4 c:\ffmpeg\bin\ffmpeg.exe -i GGS.mp4 -acodec libmp3lame -qscale:a 4 -vcodec libx264 -profile:v high -crf 18 -vf scale=1024:576 GGS-High-MP3-1024.mp4 c:\ffmpeg\bin\ffmpeg.exe -i GGS.mp4 -acodec libmp3lame -qscale:a 4 -vcodec libx264 -profile:v high -crf 18 -vf scale=960:576 GGS-High-MP3-960.mp4 c:\ffmpeg\bin\ffmpeg.exe -i GGS.mp4 -acodec libmp3lame -qscale:a 4 -vcodec libx264 -profile:v high -crf 18 -vf scale=720:576 GGS-High-MP3-720.mp4

 

[HandsomeJack]

This video helps to explain CRF in the previous post. My testing indicates CRF 23 / CRF 24 work with MP3 VBR quality level 4 for the vast majority of TV / movie content at 576p (720x576) H.264 Main Profile Level 3.0 without dropping frames and acceptable audio quality.

CRF 24 is at about web streaming quality. Overclocking on a Wii U will likely get CRF 22 working, however, the quality jump won't be all that dramatic.

In Handbrake, make sure you've enabled hardware encoding in Preferences. When encoding a video, select 'Very Fast 576p25'. In the Video tab, select the hardware encoder (in my case H.264 (AMD VCE)). At Encoder Profile, select Main, 3.0. At Quality, move CQ to 24. In the Audio tab, select the codec as MP3, Quality, 4.

In the app, 'Skip Deblocking Filter' set to 'On' (as this does make a difference).

For context, downscaling a 1080p file to 576p like this still produces way, way better results than a 576i PAL DVD, which is pretty good considering the hardware limitations of a Wii.

I've done a bit more on encoding very, very long movies (more than 3 hours). This app seems to have difficulty coping with files above about 1.2GB. Dropping the resolution down to 480p (720x480) and CRF to 28 gets these working. I found when doing 480p with CRF 26 on a long movie, I had needed to swap the container from MP4 to MKV to get the audio working (it was playing silently in MP4). The ffmpeg for this is:

ffmpeg -i input.mp4 -acodec copy -vcodec copy output.mkv

480p with CRF 26 produces pretty decent results. I later had a go at getting Handbrake to put 480p (720x480) CRF 24 directly into an MKV container itself and this also worked despite the file being 1.5GB.

EDIT: Have discovered in order for MP3 playback to work without distortion in this app, the internal volume in the app needs to be set at about two thirds.

EDIT 2: Also, if the content has subtitles, it's probably going to be better to get Handbrake to burn in those subtitles whilst downscaling.

EDIT 3: When downscaling 2.35:1 movies, Handbrake has an option to custom crop out the sides of the movie to zoom in on the center. For a typical 1080p file, cropping 248 left and right will zoom in to a 16:9 ratio area in the middle.

 

[HandsomeJack]

Having done more testing, I'm concluding if when downscaling to 576p you get Handbrake to encapsulate it in MKV (as opposed to getting ffmpeg to do that after the fact), almost all content will work with these settings (even very long movies):

Preset: Very Fast 576p25

Summary tab: Under Format, select MKV.

Video tab: Select the hardware encoder (in my case H.264 (AMD VCE)). At Encoder Profile, select Main, 3.0. At Quality, move CQ to 24.

Audio tab: Codec as MP3, Quality, 4.

In the app, 'Skip Deblocking Filter' set to 'On'. Set 'Force 576p' to 'On'.

At these settings there may be a few frame drops here and there but not that many.

If you're having too many frame drops on a particular video, drop CQ to 26 and / or change to 'Very Fast 480p30'.

Note: Widescreen movies can be cropped to zoom into the middle 16:9 part by custom cropping left/right.

Post automatically merged: Dec 17, 2023

This is a good explainer on why, given the choice, it's better to figure out how to get H.264 working rather than use Xvid.

Whilst it's still possible these days to 'find' Xvid files in places people put them to be 'found', they usually have been horribly encoded at resolutions like 640x360. You're going to get better results doing your own encoding in Handbrake to H.264.

Post automatically merged: Dec 17, 2023

Just to document this here, if you have a PAL DVD rip at 720x576 and it's still dropping frames, you can swap only the audio codec using (preserving the video):

ffmpeg -i input.mp4 -vcodec copy -acodec libmp3lame -qscale:a 4 output.mp4

 

[HandsomeJack]

There is another approach to figuring out the maximum possible quality with this app using Constrained Encoding (VBV / maximum bit rate). Initial testing I've done on using the maximum bit rate approach indicates it's possible to attempt to target a CRF as low as 14 on a maximum bit rate target of 1600k:

c:\ffmpeg\bin\ffmpeg.exe -i input.mp4 -acodec libmp3lame -qscale:a 4 -vcodec libx264 -profile:v main -crf 14 -maxrate 1600k -bufsize 2M -vf scale=720:576 output.mp4

This looks pretty fkn good for 576p considering the hardware limitations of the Wii!!! This suggests the limiting factor is the slow SD card speed on Wii hardware. I've not done testing on external USB sticks, however, it's likely higher bit rates could be achieved this way. This approach produces files of about 700MB per hour.

I also had a go with finding out if better audio quality works with these settings (-qscale:a 2) and there does seem to be enough CPU left for extra audio quality without dropping frames.

There may be a few videos where this has frame drops. In that case increase the crf value (-crf 18).

Handbrake doesn't have this equivalent feature (targeting both bit rate and CRF quality at the same time).

If you need to custom crop left/right to zoom into the middle 16:9 bit -vf will look something like:

-vf "crop=1920-250-248:800,scale=720:576"

Here a 1920x800 video is being cropped 250 left, 248 right to zoom in on the middle 16:9 part. Cropping and scaling at the same time in ffmpeg produces better results than the equivalent in Handbrake.

If the app isn't able to cope with a very large file (above about 1.4GB), this will split the file into one hour segments:

ffmpeg -i input.mp4 -c copy -map 0 -segment_time 01:00:00 -f segment output%03d.mp4

The app is compatible with these ffmpeg segmented files. It'll know which file is for which hour in the movie.

 

[grandosegood]

hey there, thank you very much for the testing effors. so your ffmpeg command is ideal for playing video files from the SD card, and it utilizes xvid so longplay movies shouldn't have an issue? and would you happen to have a batch version of these commands? thanks.

edit: nm, just seen your handbrake suggestions and the mention of h.264, gonna try that out instead.

 

[HandsomeJack]

hey there, thank you very much for the testing effors. so your ffmpeg command is ideal for playing video files from the SD card, and it utilizes xvid so longplay movies shouldn't have an issue? and would you happen to have a batch version of these commands? thanks.

edit: nm, just seen your handbrake suggestions and the mention of h.264, gonna try that out instead.

The ffmpeg command uses H.264:

c:\ffmpeg\bin\ffmpeg.exe -i input.mp4 -acodec libmp3lame -qscale:a 4 -vcodec libx264 -profile:v main -crf 14 -maxrate 1600k -bufsize 2M -vf scale=720:576 output.mp4

That's what the "-vcodec libx264" bit is. For all 1080p files I've tested, this works, ffmpeg seems to have more difficulty with 4K files, which Handbrake handles better.

If you're on Linux, there is a couple of example shell scripts on how to get the script to run ffmpeg on multiple files:

https://stackoverflow.com/questions...files-to-multiple-output-files-with-single-co

Post automatically merged: Dec 21, 2023

I've been looking into the process of hard burning subtitles with ffmpeg using this approach. With ffmpeg you need to first extract subtitles out of an MKV file into SRT:

ffmpeg -i input.mkv -map 0:s:0 subs.srt

Double check the srt file in Notepad.

Then:

c:\ffmpeg\bin\ffmpeg.exe -i input.mkv -acodec libmp3lame -qscale:a 4 -vcodec libx264 -profile:v main -crf 14 -maxrate 1600k -bufsize 2M -vf "crop=1920-236-234:816,scale=720:576,subtitles=subs.srt:original_size=1920x1080:force_style='Fontsize=26,PrimaryColour=&HFFEF00&'" -pix_fmt yuv420p output.mp4

Here, there are three things going on in -vf

1. Left / right cropping is being done on a 1920x816 file (236 right, 234 left).
2. Scaling to 720x576.
3. Subtitling after scaling, where the subs.srt file is used, they're marked as having been intended originally for 1920x1080, a large font size of 26 is applied with what works out in the end result as a blue tint. The font size can be reduced, however, not too much for 576p video.

What I've found with this is it's more difficult to target a low CRF (higher quality, here 14) without dropping frames when hard burning subtitles. I have a Wii U, so overclocking the app gets around that problem. Raising the CRF (lowering quality) to say 18 to 23 would probably get around that problem on a regular Wii.

Post automatically merged: Dec 21, 2023

I've asked Bard AI about a Powershell script to do a batch of files in a directory and it says this:

$ffmpegPath = "c:\ffmpeg\bin\ffmpeg.exe" # Adjust the path if needed
$inputDirectory = "C:\path\to\input\files" # Replace with the actual input directory
$outputDirectory = "C:\path\to\output\files" # Replace with the desired output directory

Get-ChildItem $inputDirectory -Filter *.mp4 | ForEach-Object {
$inputFile = $_.FullName $outputFile = Join-Path $outputDirectory ([io.path]::GetFileNameWithoutExtension($_) + "_processed.mp4")
& $ffmpegPath -i $inputFile -acodec libmp3lame -qscale:a 4 -vcodec libx264 -profile:v main -crf 14 -maxrate 1600k -bufsize 2M -vf scale=720:576 $outputFile
}

 

[HandsomeJack]

https://github.com/AnimMouse/ffmpeg-stable-autobuild/releases

Just for info, I always use 'non-free' (for licensing reasons) builds of ffmpeg. These are builds which have various compilation options selected which aren't in the vanilla build.

 

[mcfry666]

I'm using wiimc-ss.dol plugin on wiiflow lite currently however i'm having trouble figuring out how to activate subtitles. When i looked into my plugins folder i found the following:

README_WIIMC-Plugin.txt

* Plugin 2 : Recompiled with the 'right' freetype. Prevents a bug with subtitles according to SuperrSonic.

However i can't seem to find plugin 2? Does anyone have plugin 2 or a recompiled version?

 

[Disorarara]

Definitely if you have the space for it it seems like 576p on xvid is the way to go

 

[HandsomeJack]

Definitely if you have the space for it it seems like 576p on xvid is the way to go

In terms of low CPU usage, yes.

I've managed to get CRF 14 working on a great deal of content on H.264 Main Profile without dropping frames. That's like an equivalent of Blu-ray quality for 576p. The only modern tool I know of which does Xvid is ffmpeg.

EDIT: XMedia Recode supports exporting to Xvid paired with MP3 audio on AVI:

https://xmedia-recode.de/en/formats.php

However, I can't find an option in this tool to do both conversion to Xvid and rescaling at the same time. It's still the case the only tool I know which can do that is ffmpeg.

 

[Disorarara]

In terms of low CPU usage, yes.

I've managed to get CRF 14 working on a great deal of content on H.264 Main Profile without dropping frames. That's like an equivalent of Blu-ray quality for 576p. The only modern tool I know of which does Xvid is ffmpeg.

EDIT: XMedia Recode supports exporting to Xvid paired with MP3 audio on AVI:

https://xmedia-recode.de/en/formats.php

However, I can't find an option in this tool to do both conversion to Xvid and rescaling at the same time. It's still the case the only tool I know which can do that is ffmpeg.

PAL DVDs come encoded in 576p right? For those of us who have Wiis with DVD reading it's a good choice

 

[HandsomeJack]

PAL DVDs come encoded in 576p right? For those of us who have Wiis with DVD reading it's a good choice

Almost all PAL DVDs are 576i, not 576p.

You'll get way, way better results downscaling a 1080p file to 576p, especially with ffmpeg.

 

[T0biasCZe]

When playing 576p video on Wii set to 576i, does it actually output 576i quality signal? or is the internal framebuffer still 720x480p

 

[HandsomeJack]

When playing 576p video on Wii set to 576i, does it actually output 576i quality signal? or is the internal framebuffer still 720x480p

Yes. The one caveat on that is a Wii U can't output 576i in Wii mode.

 

[T0biasCZe]

Yes.

yes that it outputs 576i quality signal or yes that the framebuffer is still 720x480p

and i meant physical Wii not vWii

 

[HandsomeJack]

yes that it outputs 576i quality signal or yes that the framebuffer is still 720x480p

and i meant physical Wii not vWii

Both. The internal framebuffer shouldn't change.

 

[grandosegood]

hi there @HandsomeJack , thanks once again for your help. i typically use an external hard drive for my wii, do you have an updated script that would be able to add a bit more bitrate/quality, taking into account faster usb vs sd card slot. or should i change only the bitrate in the commands listed in the post above? Thanks.

 

[HandsomeJack]

hi there @HandsomeJack , thanks once again for your help. i typically use an external hard drive for my wii, do you have an updated script that would be able to add a bit more bitrate/quality, taking into account faster usb vs sd card slot. or should i change only the bitrate in the commands listed in the post above? Thanks.

c:\ffmpeg\bin\ffmpeg.exe -i input.mp4 -acodec libmp3lame -qscale:a 4 -vcodec libx264 -profile:v main -crf 14 -maxrate 1600k -bufsize 2M -vf scale=720:576 output.mp4

Bump up -maxrate 1600k to say -maxrate 1800k

That said, it's CRF which most influences quality. CRF 14 is pretty fkn high and on 576p video will be indistinguishable from CRF 13.