MPlayer for Windows (2019-10-15)

[ElQuia]

You can also try to replace the 'MPlayer.exe' with the one from this (http://sourceforge.net/projects/mplayer-win32/files/MPlayer%20and%20MEncoder/revision%2030369/MPlayer-rtm-svn-30369.7z/download) download. That build is newer (by 3 days) than the one that is currently included in my installer package.

MuldeR, did a complete reinstall, previously reseted ALL preferences to base, uninstalled december build, installed january build. DID NOT WORK.
Replaced mplayer.exe as indicated by you and EVERYTHING WORKS OK, video formats, audio, DVD disc, everything. :D
Don´t know why, but it works.
:thanks: :thanks: :thanks:

[LoRd_MuldeR]

Maybe I should update my package from the 2010-01-16 builds to the 2010-01-19 builds. But pushing out an update takes time. And my time is rare at the moment...

[ElQuia]

MuldeR, at least maybe you should post on your home page (http://mulder.dummwiedeutsch.de/home/) the recomendation you gave me (replacing mplayer.exe). I´m one of the multiple users sort of "evaluating" mplayer/smplayer combination, after years of having three or four media players to be able to play different formats and get different features (video eq for ex). Your setup in particular calls attention to somebody doing some research on the net. It would be a "low down" having a build that does not work as it should. Maybe you could just leave the december build till you fix actual one?.
Best, thanks for your advice and your cool work! :D

[LoRd_MuldeR]

I will update the package asap...

[LoRd_MuldeR]

MPlayer for Windows 2010-01-23 :)

[2010-01-23]
* MPlayer binaries updated to SVN-r30369
* QT Runtime Libs updated to Version 4.6.1

[ElQuia]

MPlayer for Windows 2010-01-23 :)

Downloading NOW! ;-)
Will post IF any problems.
Otherwise: :thanks::thanks::thanks:

[Alante]

Nice, the package is done right, SMPlayer runs real smith on windows, but that's also Windows related. On Linux (Deb/RPM based) runs like crap compared to Windows, but this days guess that's the difference between paid and free. On old days Mplayer used to run real smooth on linux, compare to any player for windows. But those days are gone and the hardware support is as slim as ever, unless you use an old PC or a server.

As mentioned in the other post, didn't try MPlayer lately and now that I did with SMPlayer and this package it's a nice surprise. Still feels like a Linux application, but one done right... definitely a keeper, might even switch it to Main Video player. I used KMPlayer for the last years and tried other alternatives but none got me interested beyond the tryout. I still consider KMPlayer a good video player, but this has all I need out-of-box, even so extras (filters) that work as they should. :)

[nijiko]

Why not also update the pack of MT ver.?

[LoRd_MuldeR]

Why not also update the pack of MT ver.?

There are new MT builds on Sherpya's site and you can use them as replacement for 'MPlayer.exe' with my package easily:
http://sourceforge.net/projects/mplayer-win32/files/MPlayer MT/revision 30369

Unfortunately MPEG-2 decoding is broken with those builds. That's a real showstopper! So I won't include the MT builds yet.

[roozhou]

There are new MT builds on Sherpya's site and you can use them as replacement for 'MPlayer.exe' with my package easily:
http://sourceforge.net/projects/mplayer-win32/files/MPlayer MT/revision 30369

Unfortunately MPEG-2 decoding is broken with those builds. That's a real showstopper! So I won't include the MT builds yet.

Use libmpeg2 for MPEG1/2 decoding will perfectly solve this problem.

[ElQuia]

Guys, sorry for the noob question, but, what are exactly MT builds and why are they better? or in what are they better than the builds mulder uses now?

[roozhou]

MT build provides frame level multi-threaded H264 decoding compared to non-MT build.

[LoRd_MuldeR]

Use libmpeg2 for MPEG1/2 decoding will perfectly solve this problem.

Tell that the MPlayer developers/builders ;)

Even if I can enforce libmpeg2 as MPEG-2 decoder at runtime via command-line switch, I will try to avoid such workaround in my package.

So I wait until they have fixed the libavcodec MPEG-2 decoder or until they make libmpeg2 the default decoder...

[ElQuia]

MT build provides frame level multi-threaded H264 decoding compared to non-MT build.

Thanks for the answer.

About MT: I'm all for improving performance. BUT I use 2 kinds of software: work or production soft and the soft I toy around with. I like the first stable and working, kind of all terrain, the latter can be beta, experimental, etc. Must say from my user point of view, after trying a LOT of media players that I'm starting to think of mulders package as my MAIN media player, It´s stable, flexible, plays everything I`ve thrown at it till now, plays with good quality (visible nearly the same as powerdvd), etc.
Might toy arround with MT mplayer, but please, keep the main package stable!
:thanks::thanks::thanks:

[roozhou]

Tell that the MPlayer developers/builders ;)

Even if I can enforce libmpeg2 as MPEG-2 decoder at runtime via command-line switch, I will try to avoid such workaround in my package.

So I wait until they have fixed the libavcodec MPEG-2 decoder or until they make libmpeg2 the default decoder...
No because mplayer-mt is not official. This is only my suggestion and I don't care whether Sherpya's build crashes or not(I make my own mplayer build).

You don't need to force -vc via cmdline. Just modify codecs.ini and put it in ./mplayer

[nijiko]

There are new MT builds on Sherpya's site and you can use them as replacement for 'MPlayer.exe' with my package easily:
http://sourceforge.net/projects/mplayer-win32/files/MPlayer MT/revision 30369

Unfortunately MPEG-2 decoding is broken with those builds. That's a real showstopper! So I won't include the MT builds yet.

Kovensky's version fixed that problem with MPEG2.
But another problem with AC3 decoding is not solved.
It's not updated over nearly a half of year...

[blackspawn]

Hello, first off, a big thanks goes for LoRd_MuldeR for making this great package and for rvm for making such a nice front end for mplayer!

Now on to my problem. I'm trying to configure MPlayer for Windows to use core AVC to decode HD media. However for the life of me I can't get it to work. All I get is sound and no picture.
I have put coreavc's .ax on the smplayer's codec folder and checked the necessary options on smplayer to use coreavc (including passing "-vc coreavc,") but I always get black picture with sound.

I've checked the log file and no error appears (the codec is correctly identified and loaded) the only "weird thing" is the following message:

MplayerProcess::parseLine: 'VideoDecoder::SetExtAttr: registry failure'


Just to be sure I downloaded Media Player Classic and was able to configure it with coreavc just fine. Is it possible to configure mplayer to use coreavc?


Possible relevant info:

Windows XP SP3
Nvidia 8800GTS 512 Graphic Card
MPlayer for Windows (2010-01-23)

[ElQuia]

blackspawn, please just to learn: what is the advantage of using core AVC to decode HD media?
Sorry for the noob question ...

[LoRd_MuldeR]

blackspawn, please just to learn: what is the advantage of using core AVC to decode HD media?
Sorry for the noob question ...

There is no advantage, except that CoreAVC may be faster than libavcodec's H.264 decoder.

I did a speed comparison a while ago:
http://forum.doom9.org/showpost.php?p=1347162&postcount=179

Note that "ffdshow" uses the same H.264 decoder that MPlayer uses by default (that is: libavcodec).

[roozhou]

There is no advantage, except that CoreAVC may be faster than libavcodec's H.264 decoder.

I did a speed comparison a while ago:
http://forum.doom9.org/showpost.php?p=1347162&postcount=179

Note that "ffdshow" uses the same H.264 decoder that MPlayer uses by default (that is: libavcodec).
It seems you are biased against payware. Don't forget CUDA and level correction.

[ElQuia]

It seems you are biased against payware. Don't forget CUDA and level correction.

In english please? :)

[LoRd_MuldeR]

It seems you are biased against payware. Don't forget CUDA and level correction.

Huh? This statement is nonsense: My comparison shows the decoder throughputs as measured on my system, nothing else. So that comparison is 100% unbiased. Also CoreAVC with "CUDA" decoding was included in my test and it performed very poorly. Probably because the hardware H.264 decoder is intended for real-time playback, not for maximum decoder throughput. I guess they designed the decoder chip to decode 1080p footage at real-time speed, but they didn't waste any transistors or power consumption for even faster decoding speed. The average user simply doesn't need a hardware decoder that decodes 1080p faster than real-time. Furthermore the fastest decoder on my system was DiAVC, which is payware -- that makes your statement completely absurd. Last but not least luminance "levels" are irrelevant for a decoder comparison, as that is a display issue. It's the job of the renderer (in combination with the display driver) to display the decoded video with correct levels...

[blackspawn]

blackspawn, please just to learn: what is the advantage of using core AVC to decode HD media?
Sorry for the noob question ...

One of the advantages imo is CPU usage, Mplayer for Windows using the default decoder uses about 20-30% CPU while coreavc offloads most of the processing to the GPU (with coreavc CPU usages stays at <5%).

Normally (at least for me) 20-30% CPU usage isn't such a big deal (the content plays fine) however with "heavy" 1080p content I can't be running anything else "moderately" intensive or the video will lag and drop a lot of frames (I have a E6600 Core 2 Duo overclocked to 3.2Ghz so although not the "best of breed" it's no slacker either..)

Other than the processing advantage I honestly don't know any other "must have" feature, in terms of video I haven't noticed anything significant (but I never bothered with a side-by-side analysis either)

As for my problem has anyone been able to make Mplayer for Windows work with coreAVC (2.0) ?

[LoRd_MuldeR]

As for my problem has anyone been able to make Mplayer for Windows work with coreAVC (2.0) ?

MPlayer doesn't "officially" support CoreAVC. There is a patch for CoreAVC support and Sherpya does include it, yes. But that patch probably was written for CoreAVC 1.9.x and would need update for CoreAVC 2.0. Anyway, since we now have FFmpeg-MT builds, the need for such "workarounds" has decreased much. CoreAVC isn't significant faster than FFmpeg-MT (on my system).

Normally (at least for me) 20-30% CPU usage isn't such a big deal (the content plays fine) however with "heavy" 1080p content I can't be running anything else "moderately" intensive or the video will lag and drop a lot of frames (I have a E6600 Core 2 Duo overclocked to 3.2Ghz so although not the "best of breed" it's no slacker either..)

Most likely that's because you used a non-multithreaded build of MPlayer, which cannot use more than 25% CPU on a Quadcore machine for H.264 decoding.

If you had used a FFmpeg-MT build, there wouldn't be any framedrops. Well, unless the CPU really hits 100% load...

[roozhou]

MPlayer doesn't "officially" support CoreAVC. There is a patch for CoreAVC support and Sherpya does include it, yes. But that patch probably was written for CoreAVC 1.9.x and would need update for CoreAVC 2.0. Anyway, since we now have FFmpeg-MT builds, the need for such "workarounds" has decreased much. CoreAVC isn't significant faster than FFmpeg-MT (on my system).

The patch sherpya uses just adds CoreAVC's clsid in codec.conf and only works on AVC in avi. There is a fork named mplayer-ww (http://www.sourceforge.net/projects/mplayer-ww) which includes a working patch. Besides fixing mplayer's crappy dshow loader, we also have to hack the video output drivers.

Since CUDA also works in mplayer, CoreAVC IS significant faster than FFmpeg-MT on systems with CUDA-capable cards.

[LoRd_MuldeR]

Since CUDA also works in mplayer, CoreAVC IS significant faster than FFmpeg-MT on systems with CUDA-capable cards.

Nope it isn't. CUDA (or more correct the VP2 decoder chip, which is accessible through the "CUDA Video API") may be able to decode the video with less CPU usage - well, of course. But if you look at the raw decoder performance (which is measured as "frames decoded per second" and not as "CPU load in percent"), it is slower than a multi-threaded software decoder running on a decent Quadcore CPU. At least my test showed that! And in the aforementioned test FFmpeg-MT was roughly 2x faster than CUDA! Other (proprietary) software decoders were even faster, including CoreAVC (s/w mode). Now you can argue that if we offload the decoding to the "hardware" decoder, we can use the CPU time for other things. That is true, of course. And for some tasks it may make sense to use CUDA decoding, indeed. But we are talking about the pure decoder speed/throughput. And there CUDA definitely isn't the fastest. In fact it was the slowest in my test! On some "low end" CPU that may look completely different, I know. But I always said that my test was done only on my Q6600. Last but not least CoreAVC 1.9 is only marginally faster than FFmpeg-MT. It should be noted that I can't test CoreAVC 2.0. So maybe CoreAVC is faster nowadays...

[roozhou]

Now you can argue that if we offload the decoding to the "hardware" decoder, we can use the CPU time for other things.
I have a single-core Sempron 2500+(754) + GF8500. Even if I OC the CPU from 1.4G to 2.5G, it is still unable to play 1080i/p HDTV/BD streams in real-time with any SW decoder, but CoreAVC CUDA does it perfectly.

P.S. your test was totally unrelated to mplayer.
Last but not least CoreAVC 1.9 is only marginally faster than FFmpeg-MT. I can't test CoreAVC 2.0.
AFAIK CUDA performance has been improved in CoreAVC 2.0.

[ElQuia]

OK guys, let see. First: thanks to everyone for your answers. Those and some internet reading are giving me a better knowledge of how all this works.
I can only tell you what have my results been, first; my system: AMD Athlon 64 X2 6000+, 5 GB of DDR800, 1.5 Terabytes HDD in RAID 0 (nvidia), nvidia GForce 8600 GT 512 MB, 20" Samsung LCD @ 1600x900 (native). OS is windows 7 Ultimate x64 - Using Ubuntu x64 and Mint x64 in VBox.
I have tried the following media players for video (I am sold on jriver media center for audio and quick video browsing):
Windows Media Player both x64 and x86, VLC 1.0.5, Media Player Classic HomeCinema (x86 & x64) svn 1597, Cyberlink PowerDVD 9, And now Mulders SMPlayer package. Sharks's Codec Pack x86 & x64 for those players that don`t "contain all" codecs & stuff.
Till I "discovered" mulders my choice was Power DVD + MPC x64 for those formats that powerdvd would not open. Powers dvd video's quality was the best. Now that I "discovered" mulder, my prime choice is mulder ;-). I get quality, very good performance (does not lose frames on HD 1080 on my system), VERY "tweakable", it´s EASY to use and one thing: It "remembers" my color, brightness, etc settings for each movie!!!!! (Im a sticker for color, contrast, etc calibration).
I can get some of these qualities in other players, but NOT all together and easy to use in the same player.

MULDER: GREAT WORK, thanks a bunch bro!!!!

[LoRd_MuldeR]

I have a single-core Sempron 2500+(754) + GF8500.

It's not surprising at all that such a low-end CPU will benefit most from "hardware" (CUDA) decoding.

However on a decent Quadcore machine you'd get roughly 4x the speed from a "software" decoder (including FFmpeg-MT), while the speed of the "hardware" decoder is still the same.

This can give completely contrary results in a speed comparision!

P.S. your test was totally unrelated to mplayer.

It tested the same decoder that is used by MPlayer (MT builds), namely "FFmpeg-MT". And it was tested against CoreAVC (including CUDA mode) as well as other relevant decoders.

So I'd say it is related, although MPlayer wasn't involved directly ;)

[blackspawn]

Most likely that's because you used a non-multithreaded build of MPlayer, which cannot use more than 25% CPU on a Quadcore machine for H.264 decoding.

If you had used a FFmpeg-MT build, there wouldn't be any framedrops. Well, unless the CPU really hits 100% load...

Humm I'm using your 23.01.2010 build, I'm assuming you didn't include the multithreaded version of mplayer... If I wan't to try that out, should I just download the corresponding mplayer and replace mplayer.exe with the ffmpeg-mt one?

[LoRd_MuldeR]

Humm I'm using your 23.01.2010 build, I'm assuming you didn't include the multithreaded version of mplayer... If I wan't to try that out, should I just download the corresponding mplayer and replace mplayer.exe with the ffmpeg-mt one?

Yes, you can simply replace the 'MPlayer.exe' with a FFmpeg-MT build from here:
http://sourceforge.net/projects/mplayer-win32/files/MPlayer%20MT/revision%2030369

But make sure that you configure enough decoding threads in SMPlayer preferences in order to take advantage of the "MT" builds.
And note that the "MT" builds are broken with MPEG-2 decoding with more than 1 thread, unless you enforce "libmpeg2" as decoder.

[blackspawn]

Thanks LoRd_MuldeR, I'll try that.

[roozhou]

It tested the same decoder that is used by MPlayer (MT builds), namely "FFmpeg-MT". And it was tested against CoreAVC (including CUDA mode) as well as other relevant decoders.

So I'd say it is related, although MPlayer wasn't involved directly ;)
MPlayer uses an architecture totally different from DirectShow. If you need to test decoding speed on MPlayer, use "mplayer -nosound -vo null -benchmark input.xxx" (sometimes you have to use -vo yuv4mpeg:file=NUL).

[Xiaopang]

Just checked out this mplayer package and was turned off by it immediately and here's why:

1. Splash screen of the installer. I know what I'm installing, so I don't need to be reminded of it, especially not for several seconds.

2. Full screen installer. This is something I haven't seen since the 90s. What makes you think that people want to exclusively watch the installation, especially since it claims that it can take several minutes thanks to upx? I have created several installers myself and I know about the temptation to present your work as pushy as possible, but things like these are instantly annoying. Keep it small and simple and don't interfere with desktop work by using a useless fullscreen presentation. Don't forget that you even warn people that their antivirus-software might interfere with the installer. Ever thought about the fullscreen hiding possible messages by said programs?

3. Uninstallation doesn't remove all registry-entries that were created upon installation. Inexcusable...

4. Why the hell did you think that forcing those terrible streaming radio stations down people's throat upon starting SMPlayer would be a good thing? Thanks by the way for not giving out a warning. My speakers were turned up by a good amount.... I guess those on slow internet connections or even dial-up like this too.

5. SMPlayer doesn't work out of the box on Windows 7 x64. Starting an audio-file works, but doing so with a video file only gives me a message that the font cache needs to be updated and that this will only take a few seconds, but nothing happens.

All these things made me kick out the whole mess after approximately a minute. However, I do give you credit for including the option of restoring file associations and using upx-compression, even though upack would have been more efficient. Also, your claim that loading compressed executables is faster is just wrong. Just because they are smaller doesn't mean that they're executed faster. They have to be extracted first and that always takes longer than loading an uncompressed executable. Even your compressed mplayer.exe shows a significant delay during startup compared to the uncompressed version. If at all you can claim that compressed exes need less space, but they will also need more RAM. Your compressed mplayer.exe eats 20MB more RAM than the uncompressed one (52MB vs 32MB with my test video). Anyway, keep up your work.

[LoRd_MuldeR]

1 + 2) The design of the installer is a question of taste. It's impossible to satisfy everybody, so I won't change it for you. Sorry. Furthermore "fullscreen" installers are extremely common, even nowadays. And you can minimize the installer window (including the background!) at any time, so there's absolutely no limitation for the user here. About the A/V warning: There are buggy A/V products that reliably prevent my legitimate installer form working properly. Hence I implemented a simple check that will detect buggy A/V software and display a warning in case legitimate actions are blocked.

3) While that is a very minor problem, I may be able to fix it, if you were so kind to tell me what registry entries aren't removed...

4) Because I want to promote my favorite web-radio station. Plain and simple. Hit the "stop" button, if it doesn't suite your taste. 'You can lead a horse to water, but you can't make it drink' ;)

5) Nonsense. It works perfectly fine on Windows 7 x64. I'm on Windows 7 x64 too. MPlayer (or "fontconfig" to be precise) updates its "font cache" on the very first launch. That's right. And it's absolutely not related to Windows 7. Furthermore the installer now updates the font-cache during the install process, so the delay for the font-cache update is avoided afterwards. However you should use the OpenGL or Direct3D video renderer on Vista/Win7, because the Overlay renderer will (temporarily) disable Aero Glass. The installer suggests pre-configuring MPlayer to use the OpenGL renderer on the "Tewaks" page...

(About UPX: Of course the code is NOT executed faster. But it starts up faster! Uncompressing the code inside the RAM takes additional time, yes. But it saves much more time - at least at the first launch - because fewer data needs to be read from the HDD. Remember that the HDD is slower than the RAM by several orders of magnitude and UPX' decompression algorithm is really fast. However if you still don't like UPX, you can simply uncheck that option in the installer and be happy without it. UPX compression has been made optional for a reason)

(About Upack: Unfortunately it's almost impossible to use Upack for release software, because 9 out of 10 A/V products will blindly raise ALARM for any Upack-compressed EXE *sigh*)

[Xiaopang]

1 + 2) The design of the installer is a question of taste. It's impossible to satisfy everybody, so I won't change it for you. Sorry. Furthermore "fullscreen" installers are extremely common, even nowadays. And you can minimize the installer window (including the background!) at any time, so there's absolutely no limitation for the user here.

It's certainly true that design is a question of taste. However, I beg to differ on how widespread fullscreen installers are. Almost all well-known software-packages use window-sized installers. Anyway, I'm not trying to convince you to revamp the installer. I was just stating my opinion.

Being able to minimize the installer is of little value if you want to monitor the installation. So there is in any case a waste of time, which I would consider a limitation.




3) While that is a very minor problem, I may be able to fix it, if you were so kind to tell me what registry entries aren't removed...

I may be able to be so kind to tell you that, if you were so kind as to supply me with a list of reg entries that your installer creates. After all, you should know best and I hope you don't expect me to guess which entries you may have created...

Here are some that a quick search for mplayer.exe revealed:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\MPlayer2

HKEY_CLASSES_ROOT\MPlayer* <<<< this one covers a whole bunch of remnants...

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{DB9E4EAB-2717-499F-8D56-4CC8A644AB60}

I suggest using Advanced Registry Monitor to find unremoved entries. I would have used it myself if I just hadn't re-installed my system...ah well, serves me right to trust installers other than my own...





4) Because I want to promote my favorite web-radio station. Plain and simple. Hit the "stop" button, if it doesn't suite your taste. 'You can lead a horse to water, but you can't make it drink' ;)

Yeah, thanks for the extra spam. A single link in the start menu entry would have also done the job without adding to the annoyance... You'd think that it's common knowledge that blatant advertising does the exact opposite of what it's supposed to, or when was the last time you ordered Viagra from that nice but pesky spam mailer?




5) Nonsense. It works perfectly fine on Windows 7 x64. I'm on Windows 7 x64 too. MPlayer (or "fontconfig" to be precise) updates its "font cache" on the very first launch.

I worded that wrong. I didn't mean to imply that it was a Win7 issue, but only that the issue existed and I was sporting Win7.




That's right. And it's absolutely not related to Windows 7. Furthermore the installer now updates the font-cache during the install process, so the delay for the font-cache update is avoided afterwards.

Well, that's not what happened.The message vanished and no video was played. Also, the message always appeared every time I tried to play a video, so something was borked.




(About UPX: Of course the code is NOT executed faster. But it starts up faster! Uncompressing the code inside the RAM takes additional time, yes. But it saves much more time - at least at the first launch - because fewer data needs to be read from the HDD. Remember that the HDD is slower than the RAM by several orders of magnitude and UPX' decompression algorithm is really fast.

Have you actually tried your "theory" on a not so well-equipped computer? Sure an hdd is a thousand times slower than RAM. Still, with reading rates of 100MB/s it doesn't matter whether you load the uncompressed file in about 0.15 s or the compressed one in 0.05s. However, the delay to decompress the file is much slower than 0.1s, so using the compressed exe is slower in any case. If you want to argue against that, then I suggest running both versions on a more dated machine where you can clearly see the difference. I'm sporting a 4200+ X2 and there's a delay of at least 250ms between both versions... Not that I mind the delay - I use upack-compressed executables all the time - but your statement is outright wrong. If you lack the ability (or a slow enough platform) to measure the difference visually, then use timing software before claiming something that is well known to be false.




However if you still don't like UPX, you can simply uncheck that option in the installer and be happy without it. UPX compression has been made optional for a reason)

I know, I know. I actually made it clear in my last post that I compared the compressed with the uncompressed version. Both came from your installer. I'm also not arguing against compression. It's great that I'm not the only one who uses it. In fact, it's a shame that so many devs don't use it. It's great that you made it optional.




(About Upack: Unfortunately it's almost impossible to use Upack for release software, because 9 out of 10 A/V products will blindly raise ALARM for any Upack-compressed EXE *sigh*)

Ah I see. Well I use upack exclusively due to its superior compression. I didn't have many problems with A/V-software though. That might be thanks to the fact that I don't use these performance hogs.

[LoRd_MuldeR]

It's certainly true that design is a question of taste. However, I beg to differ on how widespread fullscreen installers are. Almost all well-known software-packages use window-sized installers. Anyway, I'm not trying to convince you to revamp the installer. I was just stating my opinion.

Being able to minimize the installer is of little value if you want to monitor the installation. So there is in any case a waste of time, which I would consider a limitation.

Installers by NVIDIA and Realtek user "full screen" (background) windows. Those aren't exactly small/mediocre companies.

Either I keep the installer focused and follow the status or I bring another application to the front in order to do something else. In the latter case I can minimize this installer.

Stacking/cascading the windows is of very limited use, as most applications like Web-Browser or Office are more useful when maximized...

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\MPlayer2

HKEY_CLASSES_ROOT\MPlayer* <<<< this one covers a whole bunch of remnants...

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{DB9E4EAB-2717-499F-8D56-4CC8A644AB60}

The first one is not created by my installer (it doesn't even exist on my system!), the last one contains user choices that are kept intentionally for a future (re)install.

Yeah, thanks for the extra spam. A single link in the start menu entry would have also done the job without adding to the annoyance... You'd think that it's common knowledge that blatant advertising does the exact opposite of what it's supposed to, or when was the last time you ordered Viagra from that nice but pesky spam mailer?

That comparison is completely absurd! You decided to installer MPlayer for Windows and you decided to launch it after the setup was completed. Furthermore it's common practice to open a "sample" media or document at the first launch of an application, so the user will see the application works properly. I choose my favorite web-radio as that sample. Comparing this 100% legitimate and normal behavior to the racketeering of SPAM senders is pure nonsense! Those criminals are sending millions of mails to random/unrelated people, trying to steal their money. I don't do anything like that! I offer valuable software for free. But I don't contact random people to force my software on their computers or to take their money. I certainly make no money with this project. Take that into account when you complain!

Well, that's not what happened.The message vanished and no video was played. Also, the message always appeared every time I tried to play a video, so something was borked.

That issue doesn't appear here. Anyway, that would be something to report to the SMPlayer developer. It wouldn't be related to the installer...

Have you actually tried your "theory" on a not so well-equipped computer? Sure an hdd is a thousand times slower than RAM. Still, with reading rates of 100MB/s it doesn't matter whether you load the uncompressed file in about 0.15 s or the compressed one in 0.05s. However, the delay to decompress the file is much slower than 0.1s, so using the compressed exe is slower in any case. If you want to argue against that, then I suggest running both versions on a more dated machine where you can clearly see the difference. I'm sporting a 4200+ X2 and there's a delay of at least 250ms between both versions... Not that I mind the delay - I use upack-compressed executables all the time - but your statement is outright wrong. If you lack the ability (or a slow enough platform) to measure the difference visually, then use timing software before claiming something that is well known to be false.

100 MB/s is a bit optimistic for HDD throughput. It's more like a theoretical peak value. My S-ATA drive does ~60 MB/s in average.

At the same time UPX decompresses at ~200 MB/sec, on and old AthlonXP machine. Modern machines should even decompress a few times faster than that.

Anyway, a lot can be argued for or against EXE packers. That's why it has been made optional after all ;)

[roozhou]

@Lord_MuldeR
It seems you forgot the discussion on UPX in this thread last year. Leak did give a detailed explanation (http://forum.doom9.org/showthread.php?p=1238179#post1238179). The fact is you have to load more data from HDD and consume more memory with a runtime packer compared to an uncompressed exe. I guess you passed your operating system class, didn't you?

[Xiaopang]

Installers by NVIDIA and Realtek user "full screen" (background) windows. Those aren't exactly small/mediocre companies.

Realtek isn't exactly top of the line. They give little thought to their presentation and their installer reflects that. Try installing their crappy drivers on a virgin machine that runs in vga-res while their stupid installer is limited to a minimum size of 800x600. You can't reach the effin buttons at the bottom! A windowed installer wouldn't have had these problems.

Nvidia does use fullscreen and shame on them for doing that. However, they do not use a complete fullscreen. The taskbar still stays available and you find window controls in the upper right corner. Your installer completely covers the screen. Also the lack of a minimizing button in the upper right corner goes against any user instinct. No one looks for the window controls in the middle of the screen.

Anyway, just because a select few companies are so full of themselves to occupy the whole desktop during a lengthy installation doesn't mean it's a good idea. I remember ATI's installer covering its own question windows that popped up during setup. Nvidia doesn't have that problem, but that doesn't make this whole issue much better... and either way, fullscreen installers are outnumbered by window-sized installers...by far

You can defend your fullscreen installer all you want. It's your right and it's your choice, though a poor one and I think I gave enough reasons as to why that is.




Either I keep the installer focused and follow the status or I bring another application to the front in order to do something else. In the latter case I can minimize this installer.


or you can just move the installer into a corner of the screen and keep on working in your other windows... There are people on this earth who concentrate on more than just a single window at a time.




Stacking/cascading the windows is of very limited use, as most applications like Web-Browser or Office are more useful when maximized...

That is so true for people with 20 year old VGA-displays. As for modern folks with widescreen monitors in HD-resolutions and beyond, this is bs. Ever stretched a browser window on a screen with a 5 megapixel resolution? There's hardly enough content to fill the screen and if there was, then it would be hard to focus. It makes a lot of sense NOT to maximize browser windows, especially on widescreen monitors due to reasons of readability. Some websites are smart enough to limit their display width regardless of window width so in those cases a fullscreen window would be a waste too (google and youtube to name two major examples). Also, don't forget that not everybody uses only a single window at a time. Bringing a dozen windows back on top just because someone needs some attention by shouting LOOK AT MY INSTALLER by using a fullscreen display is annoying to the max.




The first one is not created by my installer (it doesn't even exist on my system!), the last one contains user choices that are kept intentionally for a future (re)install.


Well thanks for not informing the user about that. Every proper installer asks the user whether they want to keep the settings or not. And honestly, most of the times the application is uninstalled the chances that this is only temporary are pretty small, or else you wouldn't uninstall it in the first place. I still request a list of all reg-entries from you so that I can clean up my system.




That comparison is completely absurd! You decided to installer MPlayer for Windows and you decided to launch it after the setup was completed. Furthermore it's common practice to open a "sample" media or document at the first launch of an application, so the user will see the application works properly. I choose my favorite web-radio as that sample. Comparing this 100% legitimate and normal behavior to the racketeering of SPAM senders is pure nonsense! Those criminals are sending millions of mails to random/unrelated people, trying to steal their money. I don't do anything like that! I offer valuable software for free. But I don't contact random people to force my software on their computers or to take their money. I certainly make no money with this project. Take that into account when you complain!

My god...you're German and can't grasp the simple concept of sarcasm? Go and watch some Harald Schmidt and chill out. Regardless of what you think, your advertisement was unwanted just like spam. It doesn't matter whether the sender earns money with it or not, but only whether the receiver is being pestered by it. That's the German law's definition of "Unterlassungsanspruch" by the way and your way of using a freeware app to promote whatever you think is cool falls just under this legal construct.

Anyway, going hog wild on my little spam analogy isn't really dealing with the criticism that this way of pushing advertising is questionable at best (apart from the legal point of view which is not in your favor). Take my suggestion: Place a link in the start menu and people have to click on it themselves. Then no one can complain and you can sell it as showing off a cool feature of SMPlayer. Either way, that would be the smarter way both from a legal and psychological point of view.




That issue doesn't appear here. Anyway, that would be something to report to the SMPlayer developer. It wouldn't be related to the installer...


If SMPlayer is a standalone app that doesn't rely on an installer to function properly then yes, otherwise there's still the chance that the installer is screwing something up. However, I'm not really interested in using SMPlayer anyway, so that's that.




100 MB/s is a bit optimistic for HDD throughput. It's more like a theoretical peak value. My S-ATA drive does ~60 MB/s in average.

If you defrag your drive with a program that allows you to store your files in specific parts of the HDD then you can reach this easily (granted you use a capable HDD). If the file is stored on the inner rings of the HDD then of course the reading speed will be slower. My program files folder though is located on the outer rim to speed up start up times of programs. I only used 100MB/s as an example value anyway. The formula is always the same: startup time = loading time + decompression time and that's always slower than loading the uncompressed exe. The only reason why a compressed executable would indeed start faster than an uncompressed one would be if the media was extremely slow. This usually only occurs when loading executables off of CD-ROM and also only if the size discrepancy is in the several megabytes. Harddrives are far too fast so that compression does nothing to loading times other than to delay them.




At the same time UPX decompresses at ~200 MB/sec, on and old AthlonXP machine. Modern machines should even decompress a few times faster than that.

Yeah it's pretty fast. Kind of like the zip-compression for executables.




Anyway, a lot can be argued for or against EXE packers. That's why it has been made optional after all ;)

Yes and that's certainly a great feature. I think you should also add an option to remove all registry stored settings to make the installer even better ;)

[LoRd_MuldeR]

Realtek isn't exactly top of the line. They give little thought to their presentation and their installer reflects that. Try installing their crappy drivers on a virgin machine that runs in vga-res while their stupid installer is limited to a minimum size of 800x600. You can't reach the effin buttons at the bottom! A windowed installer wouldn't have had these problems.

Nvidia does use fullscreen and shame on them for doing that. However, they do not use a complete fullscreen. The taskbar still stays available and you find window controls in the upper right corner. Your installer completely covers the screen. Also the lack of a minimizing button in the upper right corner goes against any user instinct. No one looks for the window controls in the middle of the screen.

Anyway, just because a select few companies are so full of themselves to occupy the whole desktop during a lengthy installation doesn't mean it's a good idea. I remember ATI's installer covering its own question windows that popped up during setup. Nvidia doesn't have that problem, but that doesn't make this whole issue much better... and either way, fullscreen installers are outnumbered by window-sized installers...by far

You can defend your fullscreen installer all you want. It's your right and it's your choice, though a poor one and I think I gave enough reasons as to why that is.

Since you apparently are the kind of person who argues that every choice that doesn't suite your own personal preferences is "poor" by definition, I won't continue this pointless discussion...

My god...you're German and can't grasp the simple concept of sarcasm? Go and watch some Harald Schmidt and chill out.

This board has rules. Insulting people won't be tolerated. I recommend you re-read the rules or it will be a short visit for you...

Regardless of what you think, your advertisement was unwanted just like spam. It doesn't matter whether the sender earns money with it or not, but only whether the receiver is being pestered by it. That's the German law's definition of "Unterlassungsanspruch" by the way and your way of using a freeware app to promote whatever you think is cool falls just under this legal construct.

No, it certainly not related to "Spam" at all. Stop spreading nonsense! Repeating your inappropriate and insulting comparison doesn't make it any more valid...

If SMPlayer is a standalone app that doesn't rely on an installer to function properly then yes, otherwise there's still the chance that the installer is screwing something up. However, I'm not really interested in using SMPlayer anyway, so that's that.

Then I wonder why you don't have anything better to do than complaining about the installer for an application that you aren't interested in :rolleyes:

If you defrag your drive with a program that allows you to store your files in specific parts of the HDD then you can reach this easily (granted you use a capable HDD). If the file is stored on the inner rings of the HDD then of course the reading speed will be slower. My program files folder though is located on the outer rim to speed up start up times of programs. I only used 100MB/s as an example value anyway. The formula is always the same: startup time = loading time + decompression time and that's always slower than loading the uncompressed exe. The only reason why a compressed executable would indeed start faster than an uncompressed one would be if the media was extremely slow. This usually only occurs when loading executables off of CD-ROM and also only if the size discrepancy is in the several megabytes. Harddrives are far too fast so that compression does nothing to loading times other than to delay them.

60 MB/s is the (average) access speed on a freshly defragmented SATA drive. It's a pretty common model (Samsung), by the way. Not some old archaic device.

Based on your "startup time = loading time + decompression" formula we can some straight forward calculation:

Uncompressed:
startup time = 16 MB / 60 MB/s = 266 ms

Compressed:
startup time = (6 MB / 60 MB/s) + (6 MB / 400 MB/s) = 100 ms + 15 ms = 115 ms

(Here we leave out roozhou's theory, for simplicity and for lack of facts)

@Lord_MuldeR
It seems you forgot the discussion on UPX in this thread last year. Leak did give a detailed explanation (http://forum.doom9.org/showthread.php?p=1238179#post1238179). The fact is you have to load more data from HDD and consume more memory with a runtime packer compared to an uncompressed exe. I guess you passed your operating system class, didn't you?

No, I didn't forget about that theory. But it's still only a theory. A theory that is based on two assumptions: The first assumption is that the OS only loads parts of the executable to RAM when they are accessed first - e.g. no pre-fetching happens at all. We can do a lot of speculation here, but after all we cannot look inside the Windows kernel. The second assumption is that MPlayer only uses a very small part of its code on each run. Something that is highly doubtful, as the individual decoders share a lot of common functions, for example. I'm not aware of any objective analysis that showed how much (in percentage) of the executable code is "visited" in a typical run. Furthermore I'm not going to argue for or against UPX here. I say it again: It's optional. Everybody can decide what he/she prefers...

[ElQuia]

Xiaopang:
Being polite: If you don´t like it don´t use it. If you can´t do it better your self don't bitch. If you CAN do it better, DO IT, and don´t bitch.

Just my humble opinion.

[roozhou]

I agree with you that UPX should be optional, but your theory on runtime packers and operating system are misleading.
The first assumption is that the OS only loads parts of the executable to RAM when they are accessed first - e.g. no pre-fetching happens at all. We can do a lot of speculation here, but after all we cannot look inside the Windows kernel.
I don't need to debug into windows kernel:
1) You can easily build a 100M+ exe with very large code and data sections. One of the products i am working on has a ~70M exe. They all start immediately without having to read the whole image(it must be SLOW). And don't forget static-linked DLLs.
2) Press CTRL+ALT+DEL and look at memory usage of the process.
3) There is no reason to load the whole image before starting the process since it gives hardly any benefit. If M$ Windows runs in this way, it cannot even finish startup on an old computer because the size of system processes plus their dependencies are much larger than total memory.

This argument looks like:
roozhou -- Hey, there is no bomb in your laptop.
mulder -- It is only a theory. The theory is based on the assumption that the manufacturer did not accidentally hide a bomb in it, but after all we cannot separate my laptop into pieces and check every piece.

The second assumption is that MPlayer only uses a very small part of its code on each run. Something that is highly doubtful, as the individual decoders share a lot of common functions, for example. I'm not aware of any objective analysis that showed how much (in percentage) of the executable code is "visited" in a typical run.
Again 3 points:
1) Common code consists of:
(a) C runtime: mingw mainly uses msvcrt.dll so it's small. (less than 200k)
(b) Main control flow: try building an MPlayer w/o any demuxers, decoders or filters and w/ only one video output driver and one audio output driver. They will be small. (less than 1M)
(c) Common routines and tables shared among decoders, such as idct, fft and bitstream reader. They are also small. (less than 1M)
2) Again, CTRL+ALT+DEL.
3) Look at the source code, it's GPL and written in C, and there's nothing "doubtful". If you are a CS student with basic knowledge in C, it's not difficult to understand. Most common code can be found in libavutil and a lot of them are macros and inline functions. You can also find Makefile in libavcodec showing common code among decoders.

P.S. UPXed binary may become even worse if you are running anti-virus software. Some AV software will try to unpack runtime packers in a virtual machine and scan whether it is malware. Again it is much slower than a normal executable. Once Norton took ~1 minute to scan a packed exe with only 10kb in size.

[mariush]

1. Full screen install sucks.

2. UPX no longer brings any real advantages.
In the past it was great for disk space and to create smaller downloads (as UPX compresses executables better than archivers - but it's not lossless!).
The operating system does not load the whole executable in memory. However, most people would have an antivirus which would read the whole executable to scan it before it's executed. The disk cache would already cache it. If the user needs memory, what's not used goes into the page file (swap).
UPX shouldn't be used anymore (unless you do it from the start to reduce installer size which I'm all for it) as it just slows down antivirus programs, it confuses some and gives false positives and users don't care anymore about disk space.

3. Mulder it would be nice if smplayer would default at the first install to OpenGL renderer or something better than the default, as I installed it one day and the first playback was horrible quality. Switching to full screen would cause all sorts of flickering and forcing several apps to redraw themselves.

[LoRd_MuldeR]

1. Well, we already had that :)

2. As there are good points against EXE packers (as well as good points for EXE packes), this has been made optional already. So everybody can get what he/she prefers. Anyway, the aggravating slowness of some A/V products isn't my fault. And I'm certainly not going to remove legitimate functionality, just because there's buggy A/V software out there...

3. MPlayer's default renderer is the Overlay renderer, which cannot work with Aero Glass. So Aero Glass will be (temporary) disabled, as soon as some application uses the Overlay renderer. My installer already suggests to configure the OpenGL renderer, which will avoid the Overlay renderer and its "problematic" side effects for Vista/Win7. However not any system does support OpenGL 2.0.

[mariush]

Fair enough for 1 and 3, I didn't really check it thoroughly.

However for 2, i noticed that it's optional when I last installed it but I believe you should put a bit more effort in it by prechecking the executables that actually CAN be packed. If you run the installer, you'll see right now there are a lot of dll's and exes for which UPX will trigger an error and say they can't be packed... The user should not see those and the installer shouldn't even try to pack those executables. You can do a small batch file or a small application that would retrieve the error level upx returns and mark the executables it can't compress and packing these files should be avoided during the setup phase.
And... this makes the full screen setup even worse, as the user would spend a lot of time looking at that long list of packing and have no clue how much does he have to wait... it shouldn't be that hard to write a small app that would show a progress bar for the user.

On Windows, setup applications should follow the User Interface Guidelines (though I admit not even Microsoft follows them all the time): http://msdn.microsoft.com/en-us/library/ee915058.aspx

People expect to see this layout and it's familiar to them, it makes no sense to just confuse or annoy them. well, that's my 2 cents anyway.

[LoRd_MuldeR]

You are right. The installer will use a FindFile() method to find all DLL files in the "Codecs" subfolder and call UPX on all files that are found. Some won't compress and thus show an error. That isn't really a problem. But we shouldn't show it to the user, indeed. I could of course use a "whitelist" of DLL's that compress correctly and only call UPX on those. I could even write a small script to generate that list "on the fly" when the installer is compiled. However for now I will use the KISS (keep it simple stupid) method and simply reduce the verbosity of UPX. There's no point in showing the complete UPX console output in the installer log anyway. That was more a "debug" feature when I implemented that part of the installer. It's not needed anymore, so I will remove it...

[roozhou]

However not any system does support OpenGL 2.0.

-vo gl:yuv=1 or 2 does not require OpenGL 2.0.

[ElQuia]

mulder, please help. With some HD (1080) *.ts files I am getting video and audio totally out of sync. Same files in MPC (x86, mpc x64 won´t play them) and power dvd play with audio in sync ok.
Ideas?

[LoRd_MuldeR]

Where are those TS files from? Do they contain MPEG-2 or H.264 video? What is the CPU load during playback? And what build (FFmpeg-MT -vs- Normal) do you use?

Maybe you can try enforcing the "lavf" or "lavfpref" demuxer instead of the default "mpegts" demuxer.

Last but not least you may try running your TS files through ProjectX (http://www.oozoon.de/main_en.html) (for MPEG-2 video) or TS-Doctor (http://www.cypheros.de/dvb_e.html) (for H.264 video) and then try again with the "fixed" file...

[ElQuia]

Where are those TS files from? Do they contain MPEG-2 or H.264 video? What is the CPU load during playback? And what build (FFmpeg-MT -vs- Normal) do you use?

Maybe you can try enforcing the "lavf" or "lavfpref" demuxer instead of the default "mpegts" demuxer.

Last but not least you may try running your TS files through ProjectX (http://www.oozoon.de/main_en.html) (for MPEG-2 video) or TS-Doctor (http://www.cypheros.de/dvb_e.html) (for H.264 video) and then try again with the "fixed" file...

OK lets, see:
1. How do I find out if they are mpeg or h264
2. How do I find out whqat ffmpeg I have? (I thought mplayer was self contained)
3. How do I enforce lavf or lavfpref?

files are videoclips recorder from american hdtv, 1080, downloaded them to try out

I repeat: powerdvd and mpc home cinema play them in sync.