Jump to content

MPlayer builds for Win98/ME/2k/XP/2k3


RamonUn

Recommended Posts

Hi RamonUn. No success trialing all three new executables inside your unzipped build 'MPlayer.Ringo.2021-01-08.ffmpeg.N-100581-ga454a0c.7z'. Tried every combination of video out, no sound, even video null and still nothing. Also trialed swapping out SDL.dll with the other download link you provided earlier and using a known working msvcr71.dll from my K-Meleon install.

Interestingly there is now no error message or output in the COMMAND.COM window when attempting to launch a video, no matter which combinaton used. The cursor prompt just returns, nothing happens, no video. Let me know if there's anything else to trial. As mentioned earlier, the old MPlayer release used here is working well, so if you don't have time for further tests that's okay.

Link to comment
Share on other sites


Took some cold boots to figure this out. Unzipping MPlayer.Ringo.2021-01-08.ffmpeg.N-100581-ga454a0c.7z and attempting to play video results in the error message i pasted into a post above long time ago. Copying your new mplayer-a1.exe executable into this directory and attempting to play a video with mplayer-a1.exe just returns the cursor, no error message or video, as reported in previous post.

But now when i attempt to use Ringo's original mplayer.exe again the video plays back beautifully. Don't even need any arguments or config changes. Without arguments this system defaults to directx video. Using a 'vo sdl' argument works well too for SDL. Using either video output full-screen works well but SDL requires this CRT monitor to 'mode switch' while directx seems more seemless. Regardless all looks good with nice playback. Compared to the old version i've been using the OSD time counters are a welcome improvement.

So mplayer-a1.exe appears to load something into a freshly booted system that is required by mplayer.exe to work properly (on this hardware). I didn't test with fresh boots for the other new executables. Let me know if you want any further testing or screen outputs to better figure this out. Thanks.

Just saw your last post, didn't try your 2018 build since it looks like we may get this 2021 built working...


C:\WINDOWS\temp\MPlayer.Ringo.2021-01-08.ffmpeg.N-100581-ga454a0c>mplayer.exe de
er.mp4
MPlayer Ringo 2021-01-08 (ffmpeg N-100581-ga454a0c) (C) 2000-2021 MPlayer Team

Playing deer.mp4.
libavformat version 58.65.101 (internal)
libavformat file format detected.
[mov,mp4,m4a,3gp,3g2,mj2 @ 014036c0]Protocol name not provided, cannot determine
if input is local or a network protocol, buffers and access patterns cannot be
configured optimally without knowing the protocol
[lavf] stream 0: video (h264), -vid 0
[lavf] stream 1: audio (aac), -aid 0, -alang und
VIDEO: [H264] 640x360 24bpp 29.970 fps 651.8 kbps (79.6 kbyte/s)
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 58.115.102 (internal)
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
Clip info:
major_brand: isom
minor_version: 512
compatible_brands: isomiso2avc1mp41
encoder: Lavf58.45.100
Load subtitles in ./
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 48000 Hz, 2 ch, floatle, 96.0 kbit/3.13% (ratio: 12006->384000)
Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio))
==========================================================================
AO: [dsound] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [directx] 640x360 => 640x360 Planar YV12

Exiting... (Quit)

Link to comment
Share on other sites

Hi again RamonUn. Tested on separate cold boots, running the alternative executable first then launching MPlayer via Ringo's mplayer.exe works for all three alternative executables (mplayer-a1.exe, mplayer-a2.exe, mplayer-nosimd.exe). My limited Windows knowledge checking with Dependency Walker everything looks good except Link Checksum is flagged (red) for all four of these MPLayer executables and for PTHREADGC2.DLL.

Link to comment
Share on other sites

  • 4 weeks later...

I forgot to update here but there is the latest MPlayer Ringo build.

https://github.com/RamonUnch/MPlayer-Ringo-builds/releases/tag/v2021.02.27

I changed again a few things, may have an effect, I have no idea at this point.

I do not perfectly understand your problems.

PTHREADGC2.DLL was no build by myself I think, (need to check that because I have several versions lying around)

So actually it seems that after a clean boot Ringo builds work after lunching the test mplayer-a1.exe, that I build for you.

If it is reproducible, then it is a solution to your problem, but I have no idea of why!

Link to comment
Share on other sites

Your CPU being "slow", I would be interesting in some benchmarks from you, from the versions of MPlayer that run on your system.

> mplayer shortTestFile.mp4 -vo null -nosound -benchmark

Also try different -vo to know which is best on your system (I guess sdl will be fastest).

I think those details may help also others to make their choices.

If you need better performances from MPlayer there are some flags that you may want to consider:
 

Fast: >mplayer filename.mp4 -priority high -lavdopts "fast:skiploopfilter=all"

Faster:>mplayer filename.mp4 -priority high -lavdopts "lowres=1:fast:skiploopfilter=all:skipframe=nonref" -nodouble

Crazy Psychedelic WTF Fastest: >mplayer filename.mp4 -lavdopts "skipframe=nonkey" -priority high -really-quiet

You could set those option into different shortcuts in your SendTo folder, or you could associate them to different verbs in your registry (see the reg file I posted in the first page).

Link to comment
Share on other sites

Hi RamonUn. Unfortunately MPlayer Ringo 2021-02-27 also fails to launch. The work-around of running one of the three alternative executables first then the MPlayer Ringo 2021-02-27 executable still works. Thanks for trying to help, maybe a hardware or driver incompatability on my system. For now i will stick with my ancient MPlayer.

Thanks for the performance tips. MPlayer always outputs slow hardware for me, even in GNU/Linux, it is slow. I already use 'really-quiet' and sometimes 'framedrop' and 'hardframedrop'. Not fond of priority high as i'm usually multi-tasking and Windows 98 already struggles with this.

Ran benchmarks with -nosound after using the work-around to launch your MPlayer Ringo build (2021-02-27). Video out null is listed first with other relevant tests alphabetical. Looks like SDL does very well, assume 'VO: 7.777s' is the most important output generated, as the video races like a son-of-a-gun.

For comparison my old 'MPlayer Sherpya-SVN-r28311-4.2.5 (C) 2000-2009' was also benchmarked. This release does not support SDL or gl_tiled video out and for whatever reason, neither MPlayer works with direct3d. Results are listed below, those pertaining to my old MPlayer Sherpya are prepended with ***.

Basic summary, only direct comparison is directx video out, where my old build is slightly faster, but your SDL is significantly faster which is not supported in old MPlayer releases. So yeah, if the new builds work on others Windows 98 systems they should try it. For me MPlayer is the best video player, especially for old hardware.

--

VO: [null] 480x360 => 480x360 Planar YV12
BENCHMARKs: VC: 7.354s VO: 0.017s A: 0.000s Sys: 0.604s = 7.975s
BENCHMARK%: VC: 92.2132% VO: 0.2132% A: 0.0000% Sys: 7.5737% = 100.0000%

*** VO: [null] 480x360 => 480x360 Planar YV12
*** BENCHMARKs: VC: 9.038s VO: 0.047s A: 0.000s Sys: 0.409s = 9.494s
*** BENCHMARK%: VC: 95.1970% VO: 0.4950% A: 0.0000% Sys: 4.3080% = 100.0000%

--

VO: [directx] 480x360 => 480x360 Planar YV12
BENCHMARKs: VC: 7.232s VO: 11.660s A: 0.000s Sys: 0.575s = 19.467s
BENCHMARK%: VC: 37.1500% VO: 59.8962% A: 0.0000% Sys: 2.9537% = 100.0000%

*** VO: [directx] 480x360 => 480x360 Planar YV12
*** BENCHMARKs: VC: 8.799s VO: 10.468s A: 0.000s Sys: 0.442s = 19.709s
*** BENCHMARK%: VC: 44.6446% VO: 53.1128% A: 0.0000% Sys: 2.2426% = 100.0000%

--

[vo_direct3d] Allocating OSD texture in system RAM failed.
FATAL: Cannot initialize video driver.
Too many buffered pts
FATAL: Could not initialize video filters (-vf) or video output (-vo).
BENCHMARKs: VC: 117.425s VO: 0.000s A: 0.000s Sys: 0.632s = 118.057s
BENCHMARK%: VC: 99.4644% VO: 0.0000% A: 0.0000% Sys: 0.5356% = 100.0000%

--

VO: [gl_nosw] 480x360 => 480x360 BGRA
BENCHMARKs: VC: 7.624s VO: 14.162s A: 0.000s Sys: 0.624s = 22.410s
BENCHMARK%: VC: 34.0205% VO: 63.1950% A: 0.0000% Sys: 2.7845% = 100.0000%

--

VO: [sdl] 480x360 => 480x360 Planar YV12
BENCHMARKs: VC: 7.621s VO: 7.777s A: 0.000s Sys: 0.805s = 16.203s
BENCHMARK%: VC: 47.0345% VO: 47.9973% A: 0.0000% Sys: 4.9682% = 100.0000%

--

VO: [gl] 480x360 => 480x360 BGRA
BENCHMARKs: VC: 7.648s VO: 14.161s A: 0.000s Sys: 0.617s = 22.426s
BENCHMARK%: VC: 34.1033% VO: 63.1455% A: 0.0000% Sys: 2.7513% = 100.0000%

*** VO: [gl] 480x360 => 480x360 BGRA
*** BENCHMARKs: VC: 9.453s VO: 13.280s A: 0.000s Sys: 0.501s = 23.234s
*** BENCHMARK%: VC: 40.6861% VO: 57.1576% A: 0.0000% Sys: 2.1563% = 100.0000%

--

[gl_tiled] bilinear linear
BENCHMARKs: VC: 7.512s VO: 17.596s A: 0.000s Sys: 0.568s = 25.676s
BENCHMARK%: VC: 29.2569% VO: 68.5309% A: 0.0000% Sys: 2.2122% = 100.0000%

Edited by Wunderbar98
Wrapped ' vo_direct3d header' with square instead of arrow brackets else forum sofware doesn't display content.
Link to comment
Share on other sites

Hi RamonUn. Just reviewed your patch.txt. In a previous life i spent too much time compiling in Tiny Core. Submitted extensions were to always use either -O2 or -Os flags to ensure compatability with other systems. Noticed you're optimizing with -Ofast. This was new to me so looked it up. According to a limited documentation review, -Ofast disregards strict standards compliance and enables optimizations that are not valid for all standard-compliant programs.
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Further documentation indicates 'The -fast option is unsuitable for programs intended to run on a different target than the compilation machine'. AFAIK you're compiling with MinGW on Windows Vista with different hardware than utilized here.
https://northstar-www.dartmouth.edu/doc/solaris-forte/manuals/c/user_guide/cc_options.html

Not knowing what configure commands you used for all of these recent MPlayer tests, just wondering if trialing -O2 instead of -Ofast may be beneficial for your next build, whenever that may be. Maybe just grasping at straws. Regardless i'll keep testing your new builds as they become available. Thanks for considering.

Link to comment
Share on other sites

-Ofast is an alias for -O3 and -ffast-math -fallow-store-data-races

those fast-math makes a lot of optimization for the fpu disregarding IEEE 754. those optimization are ignoring infinite, NaNs, associative math ie:

3*(4*5) is considered to be equal to (3*4)*5, which is an approximation because of rounding etc.

They should be perfectly safe in the case of Mplayer, they should just lead to slightly less accurate results (maybe) and it is enabled by default by the configure.

the -fallow-store-data-races should not be a problem outside of multi-threading (that should not be used on a single CPU anyway).

I do not think this is the problem, but I will give it a try; if it works it would be an ez fix.

Link to comment
Share on other sites

  • 2 weeks later...
17 hours ago, Wunderbar98 said:

Hi RamonUn. Sorry the new build didn't work either, will leave it alone, as long as it works for others great. Take care and thanks for your efforts.

It was somewhat expected.

On 2/28/2021 at 10:56 AM, Wunderbar98 said:

Just saw your last post, didn't try your 2018 build since it looks like we may get this 2021 built working...

Just to be clear, this 2018 build is not mine and you may be still interested because it has more chances to work for you.

https://oss.netfarm.it/mplayer/files/MPlayer-win98-r38116+g23fe072e43.7z

https://oss.netfarm.it/mplayer/

Maybe you already used this one; but from your other posts it seems you use a version from 2009 which is quite dated.

Edited by RamonUn
Link to comment
Share on other sites

Hi RamonUn. This alternate MPlayer-win98-r38116+g23fe072e43 works even with SDL. Unfortunately it causes my CRT monitor to mode switch with every fullscreen toggle, like when launching a fullscreen video game. To me this is harsh on the monitor when toggling frequently, such as consecutive YouTube videos. My old MPlayer does not do this. I will leave this build alone but it may be useful for others that need an alternative. Thanks for the suggestion.

Link to comment
Share on other sites

> it causes my CRT monitor to mode switch with every fullscreen toggle

I don't know if this will fix the issue, but there is this setting in the MPlayer config file:

# Change to a different videomode when going fullscreen:
vm=yes

Of course, lines that begin with # are comments. So comment out the "vm" line, and see if that helps.

- Doug B.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...