Wunderbar98 Posted February 28, 2021 Share Posted February 28, 2021 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 More sharing options...
Wunderbar98 Posted February 28, 2021 Share Posted February 28, 2021 Hi again RamonUn. Just got your original 2021 Ringo build running but don't know yet exactly how/why. Will do some more testing and provide feedback. Thanks. Link to comment Share on other sites More sharing options...
RamonUn Posted February 28, 2021 Author Share Posted February 28, 2021 There is a Win98 build dated from 2018 if you would like to give it a try. https://oss.netfarm.it/mplayer/files/MPlayer-win98-r38116+g23fe072e43.7z Link to comment Share on other sites More sharing options...
Wunderbar98 Posted February 28, 2021 Share Posted February 28, 2021 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 More sharing options...
Wunderbar98 Posted March 2, 2021 Share Posted March 2, 2021 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 More sharing options...
RamonUn Posted March 25, 2021 Author Share Posted March 25, 2021 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 More sharing options...
RamonUn Posted March 25, 2021 Author Share Posted March 25, 2021 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 More sharing options...
Wunderbar98 Posted March 26, 2021 Share Posted March 26, 2021 (edited) 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 March 26, 2021 by Wunderbar98 Wrapped ' vo_direct3d header' with square instead of arrow brackets else forum sofware doesn't display content. 1 Link to comment Share on other sites More sharing options...
Wunderbar98 Posted March 29, 2021 Share Posted March 29, 2021 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 More sharing options...
RamonUn Posted March 29, 2021 Author Share Posted March 29, 2021 -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 More sharing options...
RamonUn Posted April 13, 2021 Author Share Posted April 13, 2021 Last MPlayer build without the -Ofast and with latest ffmpeg https://github.com/RamonUnch/MPlayer-Ringo-builds/releases Link to comment Share on other sites More sharing options...
Wunderbar98 Posted April 19, 2021 Share Posted April 19, 2021 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. Link to comment Share on other sites More sharing options...
RamonUn Posted April 20, 2021 Author Share Posted April 20, 2021 (edited) 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 April 20, 2021 by RamonUn Link to comment Share on other sites More sharing options...
Wunderbar98 Posted April 22, 2021 Share Posted April 22, 2021 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 More sharing options...
DougB Posted April 23, 2021 Share Posted April 23, 2021 > 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. 1 Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now