MPlayer for Windows (2019-10-15)

[LoRd_MuldeR]

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?

Ever heard of the swap file :rolleyes:

And please do me a favor: Stop flooding this thread.

The requested feature (make UPX optional) has been implemented already. No need to discuss UPX any further in the scope of the MPlayer thread...

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.

Stop trolling. Really.

BTW: It's quite possible (although I have not checked this in particular) that the MP3 and the h.264 decoder call the very same utility functions...

[roozhou]

Ever heard of the swap file :rolleyes:
Read all its code into memory and swap unused part into swap file?

BTW: It's quite possible (although I have not checked this in particular) that the MP3 and the h.264 decoder call the very same utility functions...
That's true, but they are quite small.

[avih]

LoRd_MuldeR, I don't think he was trolling. It's a legitimate discussion about the various aspects of the effectiveness of exe compression, especially when you considered it to have advantages only. The bottom line is that it isn't black and white. There are advantages for exe compression, as well as some disadvantages, and the performance gain/loss is dependent upon various functional, system and media aspects. Other than that, I'd also consider compressed exe to be generally more desirable (been using UPX in my own commercial releases BTW).

I found the discussion interesting and also appreciate the fact that you added the option to control the UPX stage. Good for mplayer :)

[LoRd_MuldeR]

LoRd_MuldeR, I don't think he was trolling. It's a legitimate discussion about the various aspects of the effectiveness of exe compression, especially when you considered it to have advantages only.

The discussion itself was/is legitimate indeed. But some of the personal comments were simply superfluous.

And, as you said, there is no black and white. Also I was already convinced to make UPX optional numerous posts ago and I even uploaded a build with that new feature.

At this point we need no further discussion about executable packers. At least not in the MPlayer for Windows thread...

[Eragon4ever]

Great you made UPX optional. The last few versions I downloaded I always got "Could not optimize file: mplayer.exe" (or something along those lines). Now the installer doesn't fail anymore, however it still does with UPX enabled.
Anyone else experiencing this? Maybe it's just a problem on my machine.

[LoRd_MuldeR]

Anyone else experiencing this? Maybe it's just a problem on my machine.

It's the first report I get. And it works fine on my machines.

My installer won't care whether UPX succeeds to pack a file or not. In fact it will always fail to pack a few of the files in the "codecs" folder.

So you get that error message not because UPX failed to pack, but because NSIS failed to create the UPX process! No idea why this can happen.

Are you sure that it isn't your antivirus software which is preventing the installer from working property?

[Eragon4ever]

Are you sure that it isn't your antivirus software which is preventing the installer from working property?
Interesting... I turned it off and now installation has no problem. Normally I get a message if anything is blocked.
Whatever, problem solved. Thanks!

[LoRd_MuldeR]

Interesting... I turned it off and now installation has no problem. Normally I get a message if anything is blocked.
Whatever, problem solved. Thanks!

Uhm, with "turned it off" you mean the UPX feature or your antivirus software ???

BTW: What a/v software do you use?

[Eragon4ever]

With UPX turned off it worked before already. I was referring to my antivirus software. It's Kaspersky Internet Security.

[LoRd_MuldeR]

With UPX turned off it worked before already. I was referring to my antivirus software. It's Kaspersky Internet Security.

Okay, thanks for the info. I will add a warning about that problem with Kaspersky's software ...

(as if all these false positives weren't enough already)

[LoRd_MuldeR]

MPlayer for Windows 2009-01-18 :)

[2009-01-18]
* SMPlayer updated to Version 0.6.6 (SVN-r2697)
* Add an option to enable/disable UPX to the installer
* Minor installer improvements

[Danilux]

Thank Lord Mulder, Using it right now, great app better performance than MPC in my Computer.

[LoRd_MuldeR]

Thank Lord Mulder, Using it right now, great app better performance than MPC in my Computer.

Thanks should go out to the MPlayer team and to RVM first :D

[0edipus]

Got a strange problem here:

Mplayer freezes everytime I try to play any file. (MP3 / AVI / MKV..)

I first presumed it could be in realation to the fontconfig cache problem, but I already deleted my fontconfig cache / mplayer settings and reinstalled everything with clean settings. still freezing.
(It's not like I changed anything before - it just stopped working over night)

I already tried leaving mplayer alone for like an hour but nothing changed. Nearly 0 cpu cycles used, no file input / output.

The logfiles just show the message "Starting playback..." but there is no output ~.~ no difference in using MPUI, SMPlayer or Commandline.

Below a log:
C:/Program Files/MPlayer für Windows/MPlayer.exe -noquiet -nofs -nomouseinput -sub-fuzziness 1 -identify -slave -vo gl2 -ao dsound -nokeepaspect -priority abovenormal -framedrop -nodr -double -wid 5048286 -monitorpixelaspect 1 -noass -font C:/Program Files/MPlayer für Windows/mplayer/subfont.ttf -subfont-autoscale 1 -subfont-text-scale 5 -subcp ISO-8859-1 -subpos 100 -cache 2000 -osdlevel 1 -nocorrect-pts -vf-add screenshot -slices -channels 2 -af equalizer=0:0:0:0:0:0:0:0:0:0 -sws 9 -noslices D:\Incoming\Gonzo\GOBCB3~1.MP3

MPlayer Sherpya-SVN-r28311-4.2.5 (C) 2000-2009 MPlayer Team
CPU: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz (Family: 6, Model: 23, Stepping: 6)
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2
Setting process priority: abovenormal

Playing D:\Incoming\Gonzo\GOBCB3~1.MP3.

Cache fill: 0.00% (0 bytes)
ID_AUDIO_ID=0
Audio only file format detected.
ID_FILENAME=D:\Incoming\Gonzo\GOBCB3~1.MP3
ID_DEMUXER=audio
ID_AUDIO_FORMAT=85
ID_AUDIO_BITRATE=320000
ID_AUDIO_RATE=44100
ID_AUDIO_NCH=0
ID_LENGTH=242.00
ID_SEEKABLE=1
ID_CHAPTERS=0
==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 44100 Hz, 2 ch, s16le, 320.0 kbit/22.68% (ratio: 40000->176400)
ID_AUDIO_BITRATE=320000
ID_AUDIO_RATE=44100
ID_AUDIO_NCH=2
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
AO: [dsound] 44100Hz 2ch s16le (2 bytes per sample)
ID_AUDIO_CODEC=mp3
Video: no video
Starting playback...


Help appreciated :P

[LoRd_MuldeR]

1. Try passing "-nofontconfig", just to be sure.
2. Any particular reason you use "-vo gl2" instead of the much advanced "-vo gl" renderer?
3. Do you get more useful information from MPlayer when passing the "-v" switch?
4. Did you try any other MPlayer builds than Sherpya's? (try Yong's build (http://y0ngc6.googlepages.com/Mplayer-r28096-mt.7z) for example)

[0edipus]

1. -nofontconfig didn't change anything
2. changing to gl render didn't change anything too. I used gl2 because it procuded less Tearing articats on my crappy notebook display
3. more information: yes, usefull: not really
4. no. I used the builds you included in MPfW32 for a loooooooong time and experienced any problems so far :> links?

[LoRd_MuldeR]

2. changing to gl render didn't change anything too. I used gl2 because it procuded less Tearing articats on my crappy notebook display

From MPlayer docs:
gl2 - Variant of the OpenGL video output driver.
Supports videos larger than the maximum texture size, but lacks many of the advanced features and optimizations of the "gl" driver and is unlikely to be extended further.

Make sure "Double Buffering" is checked to avoid tearing.

no. I used the builds you included in MPfW32 for a loooooooong time and experienced any problems so far :> links?

http://y0ngc6.googlepages.com/Mplayer-r28096-mt.7z

http://kovensky.project357.com/#releases

[0edipus]

strange.. while trying to copy the kovensky build into my mpui directory my pc froze completely. after a fix reboot i just reinstalled mpui and voilá everything works again.
maybe i should consider rebooting more often then just every 1-2 months :O

so far thanks for your help :D

i'm still kinda confused about the double buffering.
I enabled the checkbox, though i can clearly see artifacts in 720p or 1080i when horizontal movements occurr. using my 60Hz tft and 120Hz crt. when playing back the video frame by frame the artifacts are gone. maybe there is another option to enable synchronization of video and screen framerate?

[LoRd_MuldeR]

strange.. while trying to copy the kovensky build into my mpui directory my pc froze completely. after a fix reboot i just reinstalled mpui and voilá everything works again.
maybe i should consider rebooting more often then just every 1-2 months :O

Check your system stability with Prime95 and Memtest86 ;)

i'm still kinda confused about the double buffering.
I enabled the checkbox, though i can clearly see artifacts in 720p or 1080i when horizontal movements occurr. using my 60Hz tft and 120Hz crt. when playing back the video frame by frame the artifacts are gone. maybe there is another option to enable synchronization of video and screen framerate?

Tearing isn't visible in frame-by-frame view. It's the result of the video memory being overwritten with the next picture, while the screen is still reading the current picture.
So parts of the screen will show the "old" picture, while other parts already show the "next" picture. This results in those nasty "tearing" artifacts.

Double buffering is supposed to fix that! Also make sure that "V-Sync" is set to "always enabled" or at least "enabled by default" in your graphics driver configuration...

[0edipus]

I forced vsync in driver preferences - no real difference. maybe the test sample I use is just not suited for human eyes or 24 fps in general. could you try this 5 second scene?
http://rapidshare.com/files/190350986/_Zero-Raws__Toradora__-_16_RAW__1280x720_x264_.m4v.html
(http://rapidshare.com/files/190350986/_Zero-Raws__Toradora__-_16_RAW__1280x720_x264_.m4v.html)
I got the most fluid playback when using the d3d-render. But recognized that the picture looks a bit desatified in comparison to the gl-render. Did anyone ever make a full comparison of all those available renders, maybe even based on implementation specific characteristics?

[LoRd_MuldeR]

I got the most fluid playback when using the d3d-render. But recognized that the picture looks a bit desatified in comparison to the gl-render. Did anyone ever make a full comparison of all those available renders, maybe even based on implementation specific characteristics?

Once again :rolleyes:

http://forum.doom9.org/showthread.php?t=143689


BTW: I can't see any tearing with your clip on my 60 Hz LCD screen suing the "gl:yuv=2" renderer (ATI hardware)

[0edipus]

vielen dank für deine geduld ;)

the mentioned thread fixed the saturation problem.
great work :D

[Reimar]

I think some of you might be interested to hear that the ATI 9.1 drivers finally fix PBOs, which means you no longer need ati-hack for -vo gl.
This also improves performance greatly (30% -> 13 % vo CPU usage at 1280x720 for my system with HD4850, Athlon64 X2 3800+, for comparison -vo directx needs 3%, -vo direct3d about 18 %).
The latest SVN version of MPlayer (e.g. r28461) autodetects your driver version and sets the right settings if you don't override it.
So if you own an ATI card, I recommend to updated to a MPlayer build of r28461 or later, update to 9.1 drivers and remove any ati-hack or force-pbo options you have set (to allow auto-detection).

[LoRd_MuldeR]

I think some of you might be interested to hear that the ATI 9.1 drivers finally fix PBOs, which means you no longer need ati-hack for -vo gl.
This also improves performance greatly (30% -> 13 % vo CPU usage at 1280x720 for my system with HD4850, Athlon64 X2 3800+, for comparison -vo directx needs 3%, -vo direct3d about 18 %).
The latest SVN version of MPlayer (e.g. r28461) autodetects your driver version and sets the right settings if you don't override it.
So if you own an ATI card, I recommend to updated to a MPlayer build of r28461 or later, update to 9.1 drivers and remove any ati-hack or force-pbo options you have set (to allow auto-detection).

That is great news! :)

:thanks:

(Just lets hope they won't break it again with the next update ^^)

[rvm]

There's a interesing news in the mplayer homepage (http://www.mplayerhq.hu/design7/news.html):

2009-02-20, Friday :: Video Acceleration and You
posted by Compn

There are several ways to speed up the playback of 1080 H.264 files in MPlayer.

First is to use the newly added VDPAU (http://en.wikipedia.org/wiki/VDPAU) output. It allows the newer NVidia video cards (http://www.mythtv.org/wiki/VDPAU#Supported_Cards) to decode the video without using much CPU. It is in SVN MPlayer, you can find known bugs and report bugs HERE (http://www.nvnews.net/vbulletin/showthread.php?t=123819). (Linux only)

Second is to use MPlayer with the experimental multithreaded FFmpeg-mt (http://gitorious.org/projects/ffmpeg/repos/ffmpeg-mt) branch, which allows you to use multiple cores/CPU. (all OS and CPU supported)

To Install, copy and paste this line:
git clone git://repo.or.cz/mplayer && cd mplayer && git checkout origin/mt && git submodule init && git submodule update && ./configure && make && make install
To enable threading run mplayer -lavdopts threads=N file.mkv where N is the number of threads you want to use.

A Windows build of MPlayer using FFmpeg-mt can be found at http://kovensky.project357.com.

Third is to use the multithreaded CoreAVC (http://www.coreavc.com/) codec with the CoreAVC-for-linux (http://code.google.com/p/coreavc-for-linux/) project. The CoreAVC decoder costs $15 USD. (Linux (and Windows with this PATCH (http://oss.netfarm.it/mplayer/patches/99_coreavc.diff)))

FFmpeg (http://www.ffmpeg.org/) has also added some optimizations from the x264 (http://www.videolan.org/developers/x264.html) project. To fully utilize these you will need to make sure a recent version of YASM is installed and detected by the latest SVN MPlayer when compiling.
Using -lavdopts skiploopfilter=all:fast=1 will cause artifacts, but may allow you to play larger files in realtime.

There is also a rejected PATCH (http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2009-January/059868.html) which adds support for the new multithreaded binary VC-1/WMV3 codec.

[roozhou]

There is also a rejected PATCH which adds support for the new multithreaded binary VC-1/WMV3 codec.
I submitted that patch:(

[burro08]

I submitted that patch:(

How do you get it to work? / use patch?

[roozhou]

How do you get it to work? / use patch?

I submitted a more usable patch in the follow-ups. You need to patch and compile the source code. Of course i can make a binary batch since it only needs to remove some stupid debugging code.

[rankena]

still old version of MPlayer.

[LoRd_MuldeR]

MPlayer for Windows 2009-03-05 :)

[2009-03-05]
* QT Runtime Libs updated to Version 4.5.0
* SMPlayer updated to Version 0.6.6 (SVN-r2818)
* NSIS updated to Version 2.43
* UMUI updated to 2009-02-06

[roozhou]

Still no new build from sherpya?
It seems mplayer-devel are concentrating on VDPAU development and Windows users are being ignored. I submitted to mplayer-dev-eng mailing list quite a lot of bugfix/optimization patches for win32 but no one shows interest in them.

[LoRd_MuldeR]

Still no new build from sherpya?

Nope. But you can be sure that I'll update my package as soon as that happens...

In the meantime, you may have a look here:
http://kovensky.project357.com/

It seems mplayer-devel are concentrating on VDPAU development and Windows users are being ignored. I submitted to mplayer-dev-eng mailing list quite a lot of bugfix/optimization patches for win32 but no one shows interest in them.

Maybe you post your patch on Sherpya's tracker and/or try to contact Reimar (http://forum.doom9.org/member.php?u=79288) :)

[Reimar]

It seems mplayer-devel are concentrating on VDPAU development and Windows users are being ignored. I submitted to mplayer-dev-eng mailing list quite a lot of bugfix/optimization patches for win32 but no one shows interest in them.

This is not about being ignored, this is about (AFAIK) not a single developer running Windows, and my main "netbook" not being able to run Windows at all, so I can at most test via Wine. If you can make me remember them when I am right in front of my Windows VM I will probably take care of it.

[fxtech]

the kovensky build is great when launched via command line , but inside the smplayer 6.6 it have some fault. Smplayer did not recognize wich version is it and ask you (1.0 pre rc or posr rc1) , and when the movie start shuttering 2 second , with the video freezed and the sound looping

[LoRd_MuldeR]

Smplayer did not recognize wich version is it and ask you (1.0 pre rc or posr rc1)

I got that too. Guess that's because of the modified version line:
MPlayer GIT-6e54f40-4.2.1-sjlj-Kovensky-mt 20090304 (C) 2000-2009 MPlayer Team

and when the movie start shuttering 2 second , with the video freezed and the sound looping

No such problem here. Plays just fine inside SMPlayer...

[fxtech]

please could you post or send me your smplayer ini ?

the problem seam on the fast trak switch , smplayer restart the mplayer istance twice even if the fasttrack is set on auto or yer

[LoRd_MuldeR]

It works for me with defaults. So simply delete/rename your "smplayer.ini", launch SMPlayer, open some video and when SMPlayer asks for the MPlayer version choose "1.0rc3 or newer".

That's it. Works flawlessly for me...

[fxtech]

May be something strange , it restart media player two time before to play

[12:25:05] Core::finishRestart: --- start ---
[12:25:05] Core::newMediaPlaying: --- start ---
[12:25:05] Core::initializeMenus
[12:25:05] BaseGui::initializeMenus
.
.
.
.
.

[12:25:05] Core::newMediaPlaying: --- end ---
.
.
.
.
[12:25:05] Core::finishRestart: --- end ---
.
.
.
.

[LoRd_MuldeR]

MPlayer for Windows 2009-03-12 :)

[2009-03-12]
* SMPlayer updated to Version 0.6.7 (SVN-r2831)
* Installer updates

[avih]

MPlayer for Windows 2009-03-12 :)
Haven't updated for a while (been using 2008-10-15 IIRC) untill today, and mplayer seems to play jerky files which it used to play fine (both smplayer and mpui) and with high cpu usage.

I'm going back to my previous version..

FYI

PS.
The UPX option is nicely done.

[LoRd_MuldeR]

Haven't updated for a while (been using 2008-10-15 IIRC) untill today, and mplayer seems to play jerky files which it used to play fine (both smplayer and mpui) and with high cpu usage.

If you run MPlayer.exe from the command promt, does the problem exist too?

Did you try to replace your MPlayer.exe with the one from here (http://kovensky.project357.com/#downloads) before you downgraded?

[avih]

If you run MPlayer.exe from the command promt, does the problem exist too?

Did you try to replace your MPlayer.exe with the one from here (http://kovensky.project357.com/#downloads) before you downgraded?
My Apologies. Wanted to edit my post but you were faster :)

Anyway, It's related to the video output. I've already tested the mplayer.exe with a video file and it worked well. Then again from smplayer - jerky. Changed output to directx-fast --> ok.

It turned out that the default output was (IIRC) "user defined : gl2:yuv"

On installation it suggested openGL and noted that openGL 2.0 is required. Since I have the latest drivers I assumed I have GL2.

Anyway, after few more tests:

- direct3d/directx(/fast)/gl/gl2 seem to work smooth with varying levels of CPU usage. I guess that's ok.

- GL(fast) works well on some videos but jerky on others (like 1 FPS jerky). It seem to make smplayer UI sluggish as well. Strange.


And unrelated issues:

- Uninstallation of previous package (through add-remove programs) removed the installation directory completely although I had files there that weren't installed with your package (that I put there later)

- I've lost all my settings of smplayer although I explicitly unchecked "reset settings" on installation of the new package.

[LoRd_MuldeR]

Note that MPlayer's "gl2" renderer is a variant of the "gl" renderer that isn't developed anymore. It now lacks many of the advanced features of the "gl" renderer.

So you should prefer the "gl" renderer. Also you should use "gl:yuv=2" when possible to make sure that the YUV => RGB conversion happens in hardware.

BTW: Uninstall means uninstall. The MPlayer install directory will be removed from your HDD, including your SMPlayer.ini file, so your configuration is lost for obvious reasons.

Anyway, the installer is written in a way that you should be able to update without uninstalling first, so you won't loose your settings...


[EDIT]

From the MPlayer manual:

gl2
Variant of the OpenGL video output driver. Supports videos larger than the maximum texture size but lacks many of the advanced features and optimizations of the gl driver and is unlikely to be extended further.

[avih]

Note that MPlayer's "gl2" renderer is a variant of the "gl" renderer that isn't developed anymore. It now lacks many of the advanced features of the "gl" renderer.

So you should prefer the "gl" renderer. Also you should use "gl:yuv=2" when possible to make sure that the YUV => RGB conversion happens in hardware.

BTW: Uninstall means uninstall. The MPlayer install directory will be removed from your HDD, including your SMPlayer.ini file, so your configuration is lost for obvious reasons.

Anyway, the installer is written in a way that you should be able to update without uninstalling first, so you won't loose your settings...

- gl(fast), gl:yuv=2, gl(yuv) are similarly jerky on some/most videos. Other outputs work well, deprecated or not. On previous package at least gl(fast) was indeed.. fast and my default


- Yes, I understood the un/install thing.. alas.. too late. I would suggest 2 options (not mutually exclusive) in this regard:

1. When uninstalling, suggest to remove directory completely or remove only installed files, possibly while keeping the setup files. At least alert the user to the fact that all setup will be lost.

2. When uninstalling, display a bold message that if the intention is to install a newer version, then uninstall is unneeded and will be performed automatically with the new installer while optionally preserving setup.

Generally speaking, usually uninstallers don't delete by default user setup unless explicitly instructed to.

[LoRd_MuldeR]

Yes, uninstaller that don't clean up properly and leave files behind are a common problem.

It annoys me every time when I uninstall an application and still need to delete the application folder by hand, because the uninstaller failed to do so :rolleyes:

So I make sure that my uninstaller performs a clean uninstall. Also the uninstaller announces quite clearly what directory is going to be removed...

[avih]

Yes, uninstaller that don't clean up properly and leave files behind are a common problem.

It annoys me every time when I uninstall an application and still need to delete the application folder by hand, because the uninstaller failed to do so :rolleyes:

So I make sure that my uninstaller performs a clean uninstall. Also the uninstaller announces quite clearly what directory is going to be removed...
Must have missed that, maybe because I was expecting the setup to stay. I again suggest to enable to keep the setup, or at least make the user explicitly aware to the fact that setup will be lost and that uninstall is unnecessary before installation of a new version.

It is a welcome feature to allow complete removal of the directory, but not by not allowing the user to keep her setup, IMO.

BTW, I uninstalled the latest version just now and again didn't notice that it said the directory will be completely remove along with the setup. Might be a psychological thing, but I still didn't notice it.

[edit]
BTW, on 2008-10-15, gl(fast) does work. Just checked.

[avih]

Ok, I think I've found the cause to the jerky playback, and I think everything is ok afterall. It seems my setup doesn't support "Draw using slices" properly and therefore I should disable slices.

On smplayer 0.63 apparently there was a bug that caused it to add -slices AND -noslices to the cli args of mplayer when slices was enabled, and it's apparently enabled by default both in 0.63 and in 0.67, but in 0.63 it probably didn't actually cause mplayer to use slices. So when I disabled slices in 0.67 all plays smooth again, at the default gl:yuv=2, gl(fast), etc.

An interesting thing is that it had the same jerkiness in mpui also (in your latest package, but smooth on the 2008-10-15 package). when I added a custom switch "-noslices" on mpui, it became smooth again. Before I added the custom switch it didn't have neither -slices nor -noslices on the cli it sent to mplayer, which might imply that mplayer by default uses slices now, but was using noslices by default on my previous version.

But the strange thing is that when I drag the same jerky video directly over the mplayer.exe file (either in the installation root dir or onto the <install>/mplayer/mplayer.exe) it does play smooth, which suggest -noslices is the default behavior.

So while I do have perfectly smooth playback now using both smplayer and mpui with all GL modes, both with explicitly disabling slices, I'm confused about it because of the seemingly conflict playback with mplayer.exe to mpui without reference to slices at any of them.

Strange.

[LoRd_MuldeR]

Maybe the "default behavior" depends on whether MPlayer is running in "slave" mode (that is: The video is rendered to a window which belongs to another process) or not. It's also possible that there's some bug in the OpenGL driver which prevents slices from working properly in "slave" mode, while they do work okay in "normal" mode. Remember: Not too long ago then GL renderer didn't work at all in "slave" mode...

(About the uninstaller issue: Yes, in the English translation it doesn't explicitly say that directory will be "removed". Instead the word "uninstalled" is used, which is a bit more ambiguous, indeed)

[rvm]

But the strange thing is that when I drag the same jerky video directly over the mplayer.exe file (either in the installation root dir or onto the <install>/mplayer/mplayer.exe) it does play smooth, which suggest -noslices is the default behavior.

When you do this, mplayer uses its default vo, which I think it's directx. Didn't you say you only had this problem with gl?

[avih]

When you do this, mplayer uses its default vo, which I think it's directx. Didn't you say you only had this problem with gl?
I did and it is smooth using directx. That's probably the reason. Thanks.

Can you just confirm the bug in smplayer 0.63 where both -slices and -noslices were sent together?