MPlayer for Windows (2019-10-15)

[LoRd_MuldeR]

Ideally, this would leave yuv=2 as the only necessary option to get working and fast OpenGL playback and still acceptable speed without it.

Good to know and great idea. Dealing with these ultra-long "-vo" parameter lists wasn't very convenient.
Can I see the values choosen by MPlayer for my system in the log? Doesn't seem like that...

Thanks for your efforts :thanks:

[Vicki_21]

* To get the OpenGL renderer working with latest ATI Catalyst drivers use "gl:yuv=2:rectangle=2:force-pbo:ati-hack" for full
performance.

* There is a new "direct3d" renderer now, which should be helpful for Vista users that have Aero enabled.

* Finally the fontconfig "delay bug" has been fixed (hopefully). Still fontconfig will be disabled by default, just to be sure.

By latest ATI Catalyst drivers, do you mean 8.11 or 8.12?

Has anyone tried the direct3d renderer against opengl under vista with aero enabled?

In the past, opengl kept the aero interface, but with my ati radeon i noticed some artifacts (specially with red colored objects). So, i didn't prefer opengl and aero gets disabled every time mplayer starts (however the video playback quality now is excellent).

I am wondering if this new direct 3d renderer tends to exhibit similar behavior and i m also afraid to try it :p Any comments will be very useful.

[LoRd_MuldeR]

By latest ATI Catalyst drivers, do you mean 8.11 or 8.12?

8.11 (did not test 8.12 yet, but I'd expect it to break something ^^)

Has anyone tried the direct3d renderer against opengl under vista with aero enabled?

Don't have Vista installed, so can't test it ;)

I am wondering if this new direct 3d renderer tends to exhibit similar behavior and i m also afraid to try it :p Any comments will be very useful.

The Direct3D renderer certainly won't disable Aero. Think that's why it was added.

[Vicki_21]

8.11 (did not test 8.12 yet, but I'd expect it to break something)

The Direct3D renderer certainly won't disable Aero.

I am now downloading 8.12 - the release notes report covers some major improvements for HD 4XXX series.

I guessed that the new direct3d renderer won't disable aero and that's exactly my problem. Every time i play videos with aero enabled (eg. either in mplayer or mpc-hc or vlc utilizing each time their respective "aero compatible" renderers/options ) i get those artifacts. The solution is to use the old method of playback eg overlay etc... which turns aero off and displays no artifacts.

Anyway, i am gonna give this a try on my secondary nvidia machine. If anyone (ati/vista user) has noticed something similar post a comment please.

[LoRd_MuldeR]

The old "directx" (Overlay) renderer is still there. So don't worry. Also you can completely disable Aero on your system, which avoids renderer problems and saves performance ;)

(The definitive solution would be dropping Vista as a whole though ...)

[Vicki_21]

The old "directx" (Overlay) renderer is still there. So don't worry.

:thanks: That's a relief. :)

[Leak]

In the past, opengl kept the aero interface, but with my ati radeon i noticed some artifacts (specially with red colored objects). So, i didn't prefer opengl and aero gets disabled every time mplayer starts (however the video playback quality now is excellent).
Ummm... would that "artifacts" be red edges that look like they're made out of pixels twice the normal size? In that case the chroma upsampling was done by point resizing instead of bilinear or better, and it's not really specific to mplayer.

But if chroma upsampling is done in the renderer it should be possible to do it right anyway...

np: Miwon - A To B (A To B)

[LoRd_MuldeR]

@Reimar
Would it be possible to add an sub-option for the Direct3D renderer to enforce TV Levles?
Or even better: Use TV Levels by default and add on option to use PC Levels.
Currently the Direct3D renderer gives much brigher output than OpenGL on my system...

[Reimar]

@Reimar
Would it be possible to add an sub-option for the Direct3D renderer to enforce TV Levles?


No. It uses the driver's conversion, no shaders or anything, no way to configure anything unless the driver provides a way.

[LoRd_MuldeR]

No. It uses the driver's conversion, no shaders or anything, no way to configure anything unless the driver provides a way.

Are there any plans/ideas to add it in the future? Maybe (optional) level conversion via shader?

[Vicki_21]

Ummm... would that "artifacts" be red edges that look like they're made out of pixels twice the normal size? In that case the chroma upsampling was done by point resizing instead of bilinear or better, and it's not really specific to mplayer.

Yes, it's not specific to mplayer. It happens also with vlc, mpc-hc, ffmpeg, xvid etc... and is related to vista/ati/"aero compatible" renderer.

Currently the Direct3D renderer gives much brigher output than OpenGL on my system...

By testing the latest 3d renderer under vista, i noticed the exact behavior. It needs some kind of conversion (16-235 to 0-255) like the one found in mpc-hc, in order to get rid of poor black levels.

One more question: I used the "check for updates" function to install the new version. Where is the setup file (which is automatically downloaded) stored? So i can delete it after a successful installation.

[LoRd_MuldeR]

One more question: I used the "check for updates" function to install the new version. Where is the setup file (which is automatically downloaded) stored? So i can delete it after a successful installation.

It's downloaded to your %TEMP% folder and it will delete itself (http://nsis.sourceforge.net/SelfDel_plug-in) after the setup is completed :D

[Vicki_21]

It's downloaded to your %TEMP% folder and it will delete itself (http://nsis.sourceforge.net/SelfDel_plug-in) after the setup is completed :D

Excellent! :cool:

[tekNerd]

I am using the latest svn mplayer (http://oss.netfarm.it/mplayer-win32.php) along with SMplayer as gui.
Since I run mplayer as a separate window to control mplayer I have input.conf as keyboard/mpuse configuration file, but it seems to me that it doesn't read it. Bug or...?

[LoRd_MuldeR]

I am using the latest svn mplayer (http://oss.netfarm.it/mplayer-win32.php) along with SMplayer as gui.
Since I run mplayer as a separate window to control mplayer I have input.conf as keyboard/mpuse configuration file, but it seems to me that it doesn't read it. Bug or...?

As soon as you run MPlayer from a GUI (e.g. SMPlayer) it will run in "slave" mode and it won't get any instructions from keyboard ;)

Only the GUI can pass instructions to MPlayer. So "input.conf" doesn't apply. You must configure the keys in SMPlayer's preferences ("Keyboard & Mouse" -> "Keyboard").

Or run MPlayer.exe from the Command Shell...

[tekNerd]

Ya, it doesn't work. It works if I keep Mplayer in SMPlayer, but if I have run mplayer on separate window...not working anymore.

Ok. It works for command line, as in execute mplayer without smplayer. Another thing is I put left double click as fullscreen, but it says that No bind found for key MOUSE_BTN0.

[LoRd_MuldeR]

Ya, it doesn't work. It works if I keep Mplayer in SMPlayer, but if I have run mplayer on separate window...not working anymore.

Works for me. But apparently the SMPlayer windows must be focused to make the key commands work...

[tekNerd]

You are right about the focus. Hmm...

[Romario]

long time no new build of Mplayer for Windows... :(

[LoRd_MuldeR]

long time no new build of Mplayer for Windows... :(

New build will be done as soon as new Win32 builds of MPlayers are available ;)

Which may happen soon:
Hi,
last try (yesterday) failed because of a compilation problem,
I'll need to check if devel fixed the buf, then I'll release new builds

Regards

[fxtech]

in meantime koversly last build is amazing , it shave 15% on decoding time on h264 stream

[roozhou]

New build will be done as soon as new Win32 builds of MPlayers are available ;)

Which may happen soon:

Why not do it yourself? I make MPlayer daily build every morning:)

[burro08]

Why not do it yourself? I make MPlayer daily build every morning:)

how???

[LoRd_MuldeR]

MPlayer for Windows 2009-01-14 :)

[2009-01-14]
* MPlayer binaries updated to SVN-r28311
* SMPlayer updated to Version 0.6.6 (SVN-r2680)


Note that this version adds experimental support for DVD menus:

To use dvdnav the best way is pick a recent svn build of smplayer from Mulder's homepage
* go to Preferences->Keyboard and mouse->Mouse and select "Activate option in DVD menus" for the left mouse button (so you can select the options in the menus with the mouse)
* go to Preferences->Drives and check the option "Enable DVD menus"

Some of the problems I found:
* it seems there's no way to know the current title that it's playing. MPlayer prints a line like this "DVDNAV, switched to title: 1" but unfortunately the title number that appears there may not match the title IDs that mplayer printed before (it may say "switched to title 2" but the actual title may be the 12th ). As smplayer doesn't know the title, restoring the previous position after a mplayer restart is impossible.
* when seeking the subtitles disappear.
* if the audio track is changed, when you return to the dvd menu the sound may be lost (while printing a lot of error messages "Too many video packets in the buffer").

[mhj911]

mplayer in "http://oss.netfarm.it/mplayer-win32.php" compile with dvdnav now. it is a good msg.

[LoRd_MuldeR]

mplayer in "http://oss.netfarm.it/mplayer-win32.php" compile with dvdnav now. it is a good msg.

These are the builds I have included in the 2009-01-14 packages :)

I agree that dvdnav support is nice. Better now then never, but there still are various flaws with dvdnav at the moment...

[mhj911]

yes, dvdnav also need to improve, if have some info to describe dvd menu and titles clearly, front will support dvdnav very well:)

[kypec]

@LoRd_MuldeR:
Could you please explain to me why the optimized (=UPX packed) executable files cannot be included in your installer package directly? Is it really necessary to do UPX packing during installation process on-the-fly?:confused:

[LoRd_MuldeR]

@LoRd_MuldeR:
Could you please explain to me why the optimized (=UPX packed) executable files cannot be included in your installer package directly? Is it really necessary to do UPX packing during installation process on-the-fly?:confused:

Because this would double the installer's size :eek:

The installer uses LZMA compression in "solid" mode (all files compressed in one block). The same algorithm used by 7-Zip (in fact 7-Zip SDK is the reference implementation of LZMA). And LZMA works extremely well for text files and for binary code. But as soon as you UPX a binary, it "looks" like random data to the LZMA compressor. It's like putting a ZIP archive into a RAR archive (or vice versa) - it just doesn't compress any further. You end up with an installer that is even bigger. A lot bigger in my experience! So I implemented the "on the fly" UPX code in my installer. You can always skip that part by running the installer with the "/NOPACK" commandline switch. However I think you don't install/upate MPlayer more than once a month, so giving the installer 3-5 minutes for UPXing the binaries should be acceptable. Isn't it?

[Leak]

Now, I haven't installed mplayer recently, but why not just make the UPXing optional in the installer?

np: The Gasman - Equino (Superlife)

[LoRd_MuldeR]

Now, I haven't installed mplayer recently, but why not just make the UPXing optional in the installer?

It already is optional. The "/NOPACK" switch was added at the same time when the UPX code was implemented.

Maybe you mean an option in the installer GUI? Well, I thought about that. But I assume the average user won't know what UPX is and don't understand what it is good for.

People that do understand, will also be able to use a commandline-switch...

[Leak]

Maybe you mean an option in the installer GUI? Well, I thought about that. But I assume the average user won't know what UPX is and don't understand what it is good for.
Call it "Take up 3 to 5 minutes of my life for miniscule space savings" and I'll bet a lot of people are going to use it... :p

How about a "Skip compression" button while UPX is running?

(Note: I haven't actually tested your installer, so I'm pulling things out of my a^w^wthin air... :D)

np: The Bug - Jah War (London Zoo)

[LoRd_MuldeR]

How about a "Skip compression" button while UPX is running?

Don't think this can be done with NSIS easily. And it's not really what I'd like to have in my installer.

Again: People who know what UPX is and who don't like to use it, can use the "/NOPACK" switch to skip that part.

All the others will have to wait a few minutes :p

[avih]

Don't think this can be done with NSIS easily. And it's not really what I'd like to have in my installer.

Again: People who know what UPX is and who don't like to use it, can use the "/NOPACK" switch to skip that part.

All the others will have to wait a few minutes :p
I second the opinion to add a GUI switch for UPXing the files. Something like "Compress installed files from X MB to Y MB to preserve disk space. NOTE: this might make the installation process few minutes longer.". Not sure if it should be on by default BTW.

I was well aware of the process but completely unaware of the CLI switch. It is a bit unusual to upx post install to a degree that it takes a noticeable duration. I fully understand the motivation and elegance of your procedure, but these days, when disk space is usually abundant and time sometimes isn't, not many people care for preserving another 10-20M.

It's not a terribly important issue IMHO, but the addition of this GUI switch would make the installer somehow more complete IMO.

Regardless, rvm's work and your timely packaging is invaluable to many people. Keep up the good work :)

[LoRd_MuldeR]

Okay, I just did a test. And the complete install process (including UPX) took 1 minute, 52 seconds. Without UPX it took 46 seconds.

At the same time the "uncompressed" binaries (MPlayer, SMPlayer, MPUI and Codecs) take ~64 MB of disc space, while the UPX'd ones only take ~27 MB.

So the UPX procedure takes roughly one minute and reduces the disc space requirement to 42%. Do you still think we need a GUI option for that ???

[kypec]

I really appreciate your work on providing these binaries to us, LoRd_MuldeR. However, I strongly agree with everything Leak and especially avih have said.
First of all, /NOPACK switch should be clearly and visibly mentioned on your homepage beside the download links as a note to experienced users. GUI option in the installer with brief explanation like avih already stated would be even better solution. IMO UPX-ing of executables is really welcomed only by few skilled users who probably want to put MPlayer along with their media files for distribution/portability (CD-R/DVD/USB Flash disk/...) where space saving is desired. All the others equipped with 250+ GB HDDs today really do not care whether their favourite application takes 40MB more upon installation. On the other hand they care whether installation process is smooth and fast. I was really a bit scared after 1 minute of seemingly "dead" installer on my 2.22GHz Athlon 64 X2.

My humble proposal is to make there /PACK switch optional for advanced users and let the executables non-packed by default.

[Leak]

So the UPX procedure takes roughly one minute and reduces the disc space requirement to 42%. Do you still think we need a GUI option for that ???
So it reduces the disc space requirement from 0.025% of a 250GB harddisc (and that's probably a small drive these days) to 0.0105%.

Uhhh... miniscule non-epic kinda-win? :confused:

Not to say I don't appreciate saving space, but it probably has more use when space is actually tight, like on a CD...

How about optionally setting the NTFS compression flag on the directory that the installer creates as a compromise?

[LoRd_MuldeR]

So it reduces the disc space requirement from 0.025% of a 250GB harddisc (and that's probably a small drive these days) to 0.0105%.

Now imagine all developers think that way and all applications on your HDD suddenly take twice the discspace...

How about optionally setting the NTFS compression flag on the directory that the installer creates as a compromise?

Specific to NTFS. Also I doubt it can keep up with the excellent compression of UPX.

Another point for UPX is that it actually speeds up the application launch. Sure, we have some overhead for decompressing the code.
But that happens in RAM and is really fast. Loading the smaller (UPX'd) file from HDD saves more time, as HDD's are sloooow...

However I will look for a way to make UPX optional with a GUI option. It seems people don't have much love for UPX :o

[Leak]

Another point for UPX is that it actually speeds up the application launch.
Considering that modern HDDs can read up to 100MB/second if it's sequential reads I'd rather say if it takes long to load then a defrag (http://www.kessels.com/Jkdefrag/) is in order...

And seriously, I couldn't care less if my media player starts in one or two seconds if I'm going to watch a 2 hour movie... even stand-alone DVD players take longer to boot up.

np: Apparat - Arcadia (Telefon Tel Aviv Remix) (Things To Be Frickled (Disc 2))

[smok3]

i did a lil test, there is no big difference really;
26.580.711 installed.7z
22.293.663 installer.7z
other than that:
my vote goes for -> nuke UPX.

(or there could be a batch file for ppl who would want to upx it latter, after the installation...)

[LoRd_MuldeR]

Comparing 7-Zip'ed sizes isn't very useful. Also comparing installed size -vs- installer size is not correct, as the installer contains more binaries (not all binaries will be extracted during install).

The real interesting test is: Install the MPlayer for Windows package, with and without UPX, and compare the install folder sizes. It's 37.6 MB -vs- 78.5 MB according to my test. Far enough difference IMHO.

Uploading a new test version right now, but MediaFire seems to be overloaded and sluggish right now...

[smok3]

right, so several upx-ed mplayers wont 7zip well, is that so?

[roozhou]

Another point for UPX is that it actually speeds up the application launch. Sure, we have some overhead for decompressing the code.
But that happens in RAM and is really fast. Loading the smaller (UPX'd) file from HDD saves more time, as HDD's are sloooow...

However I will look for a way to make UPX optional with a GUI option. It seems people don't have much love for UPX :o

Completely wrong! UPX'd MPlayer needs more loading time because it has to decompress ALL its code. It will first completely read its image into memory, then decompress and write them into another memory location, and finally jumps to the "Entry point". This is a waste of time and memory.

For unpacked executables, code is swapped into memory from HDD only when the first time it is executed. e.g. when playing a mp3 file, MPlayer only consumes ~1.5M memory although MPlayer.exe is ~14M. That's because other code such as h264 decoders will never be executed and thus never be read from HDD.

Please run packed and unpacked MPlayers with the same cmdline, and see memory usage in task manager.

[LoRd_MuldeR]

several upx-ed mplayers wont 7zip well

And since NSIS uses the same compression agorithm as 7-Zip (LZMA) putting several UPX'd MPlayers into the installer wouldn't compress well either!

That's exactly the reason why I include "uncompressed" MPlayers in my installer and apply UPX after extraction from installer ;)

[LoRd_MuldeR]

Completely wrong! UPX'd MPlayer needs more loading time because it has to decompress ALL its code. It will first completely read its image into memory, then decompress and write them into another memory location, and finally jumps to the "Entry point". This is a waste of time and memory.

Sorry, but you are wrong here. RAM is faster than HDD by several orders of magnitude! Also the UPX decompression algorithm is extremely fast (several GB per second). So if UPX saves X milliseconds by loading a smaller binary from HDD (compared to uncompressed file) to RAM and adds an overhead of Y milliseconds for decompressing the code in RAM, then X > Y. So after all you save time. Also: If any additionlal memory is rquired during the decompression process, that memory will be freed up immediately after the decompression has finished. None of your arguments can persist...

[roozhou]

Wrong. RAM is faster than HDD by several orders of magnitude. And the UPX decompression algorithm is extremely fast (several GB per second). So if UPX saves X milliseconds by loading a smaller binary from HDD (compared to uncompressed file) to RAM and adds an overhead of Y seconds for decompressing the code in RAM, then X > Y. So after all you save time. Also: If any additionlal memory is rquired during the decompression process, that memory will be freed up immediately after the decompression has finished...

This time you refused to understand.

UPX needs to load LARGER binary from HDD. And all code and data sections will be decompressed and will never be freed up. Even worse, you cannot free up uncompressed data though it will not be used any more.

[LoRd_MuldeR]

To put end to this discussion, here you have a build with UPX made optional:
MPUI.2009-01-16.Test-2.exe (http://www.mediafire.com/file/ynytzd2di0n/MPUI.2009-01-16.Test-2.exe)

The new option is available from the "Choose Components" page. You need to choose the "Custom" setup type to get there.
Also note that the "/NOPACK" switch is still implemented and working, as people may need that for "silent" install...


UPX needs to load LARGER binary from HDD.

Nope. Original MPlayer.exe is ~15 MB in size, the UPX'd one is only ~5 MB. Loading the 5 MB binary from HDD to RAM instead of loading the 15 MB one safes more time than decompressing the UPX'd code in RAM takes. Consequently the startup time is reduced. At least when you really load from the HDD (not from HDD Cache). Also discussion can be stopped here, as I already made UPX optional in my installer. If you don't like UPX, then simply use the new option to disable it and that's it. Everybody can get what he/she prefers. So please don't let us mess this thread with an UPX flamewar...

[Leak]

Nope. Original MPlayer.exe is ~15 MB in size, the UPX'd one is only ~5 MB.
Not to flame you or anything, but he's right.

Whenever you use mplayer to play a certain movie you usually only need one file parser, one video decoder, one audio decoder and a few filters out of the oodles of things that are compiled into mplayer's executable.

If the executable is uncompressed, Windows will only load parts of the executable into the program's address space when they're first accessed (i.e. 4k pages of the executable are loaded when execution reaches them), which may well be from the disk cache due to file read-ahead.

If the executable is compressed, this mechanism simply doesn't work since a UPX compressed executable to Windows is just a few kilobytes of decompressor code with a huge amount of data attached to it, and that way the decompressor has to first load all that data into memory and then uncompress it all, since there's no way to on-demand load only the parts that are actually used.

And while the whole unpacked executable may well get read into the disk cache due to read-ahead, any parts of that can simply be evicted from the cache anytime. The uncompressed executable, on the other hand, has to be saved into the pagefile instead since it cannot be read back from the executable on disk if it's needed again.

Look at it like this - an unpacked executable can start right away while it's still being read in while a packed executable needs to be loaded fully before execution can start.

But, meh... I really don't want to turn this into an operating system lecture...

np: The Orb - High Noon (The Dream)

[LoRd_MuldeR]

If the executable is uncompressed, Windows will only load parts of the executable into the program's address space when they're first accessed (i.e. 4k pages of the executable are loaded when execution reaches them), which may well be from the disk cache due to file read-ahead.

Well, that sounds like a nice theory. But is it really implemented in Windows that way in reality? We can only guess, as Windows is ClosedSource. And even if it was implemented that way, there is absolutely no guarantee that MPlayer won't access code all over the place. Functions call sub-function. Sub-functions call sub-functions themselves. And so on. All these functions my originate from completely different modules and hence may be distributed all over the application code. The only way the OS can compensate is loading all that code (not later than it is accessed first). So instead of loading the entire application to RAM at once, you end up loading it successively (maybe excluding a few parts, yes). That in fact may turn out to hurt performance...

[roozhou]

Well, that sounds like a nice theory. But is it really implemented in Windows that way in reality? We can only guess, as Windows is ClosedSource. And even if it was implemented that way, there is absolutely no guarantee that MPlayer won't access code all over the place. Functions call sub-function. Sub-functions call sub-functions themselves. And so on. All these functions my originate from completely different modules and hence may be distributed all over the application code. The only way the OS can compensate is loading all that code (not later than it is accessed first). So instead of loading the entire application to RAM at once, you end up loading it successively (maybe excluding a few parts, yes). That in fact may turn out to hurt performance...

I have seen WinXP running with 96MB RAM. If the OS always loads all code of a EXE (and all code of its depending DLLs), how could this be done?

Press CTRL+ALT+DEL and the task manager will prove my words. I guess you really need to take an operating system lecture. And I highly recommend you read MPlayer source code carefully(i guess you have never read them) and they will tell you why MPlayer never calls H264 decoder routines when playing an MP3 file.