MPlayer for Windows (2019-10-15)

[Alante]

Well, the "dsnative" wrapper is supposed to work with ffdshowdxva already. At least according to the project page.

However I have not been able to get "dsnative" working with MPlayer on my system, so far...




The MPlayer project is pretty active. Look at the SVN log! There usually are several commits per day:
http://pastie.org/850728

However you shouldn't forget that MPlayer originates from the Linux community and it seems most MPlayer developers don't focus on Windows ;)

Well that's just it, Mplayer used to be real capable in the old days beating any alternative, both Windows and Linux. But now, runs beter on Windows as a fronted the it those in Linux and even lost popularity on most distros, since videolan seems to be more stable then Mplayer.

When I said Mplayer project stopped evolving, was referring to Linux not Windows. :) Didn't say they don't update it anymore, just that it doesn't evolve. :)

[LoRd_MuldeR]

MPlayer for Windows 2010-03-02 :)

[2010-03-02]
* MPlayer binaries updated to SVN-r30815
* SMPlayer updated to Version 0.6.8 (SVN-r3468)
* "Generic" (RTM) build is up-to-date again

[Gusar]

Well, the "dsnative" wrapper is supposed to work with ffdshowdxva already. At least according to the project page
Look again. It says "not working" in the status column.

FFmpeg has DXVA support, mplayer could use that. VLC already does. But Alante is right, mplayer development is a lot slower than it used to be. Reimar is pretty much the only active developer.

[lasuocera]

@ LoRd_MuldeR

Hi, new mplayer builds from Tiesi are not working with SMPlayer. I'm on windows xp sp3, ATI Radeon 3870 Cat 10.2

[Reimar]

FFmpeg has DXVA support, mplayer could use that. VLC already does.

Well, the theory was that FFmpeg would provide support for full hardware decoding including read-back instead of everyone having to duplicate the same code (of course, for maximum performance you might not want to read back, but that is IMO a secondary consideration). Unfortunately there seems to be no work on this.

But Alante is right, mplayer development is a lot slower than it used to be. Reimar is pretty much the only active developer.

It's not quite that bad. Thing is that most of the important/interesting stuff has moved to FFmpeg, which on the plus side means everyone profits from it, which also means MPlayer has less of an advantage.
Also it definitely is a big matter of what OS you are using. Just to highlight the absurdity of the situation: We have someone working actively on improving support for OS/2. We don't have anyone seriously working on Windows (there are a small few patches, but no-one pushing hard enough and doing to extra effort to get them to a sufficient quality level to be included).

[LoRd_MuldeR]

@ LoRd_MuldeR

Hi, new mplayer builds from Tiesi are not working with SMPlayer. I'm on windows xp sp3, ATI Radeon 3870 Cat 10.2

Definitely works here. Instead of making wild claims, give us some useful details about the problems you are experiencing...

[lasuocera]

Ok sorry, i'll try to explain. Well wrong aspect ratio, cannot select output video and sound driver, no information on info and properties and the controls (play,pause,seek) are disabled. SMPlayer is working ok with mplayer version SVN-r30369.

[LoRd_MuldeR]

Ok sorry, i'll try to explain. Well wrong aspect ratio, cannot select output video and sound driver, no information on info and properties and the controls (play,pause,seek) are disabled. SMPlayer is working ok with mplayer version SVN-r30369.

http://i49.tinypic.com/2d92qlz_th.jpg (http://i49.tinypic.com/2d92qlz.jpg)

:confused:

[Alante]

Also it definitely is a big matter of what OS you are using. Just to highlight the absurdity of the situation: We have someone working actively on improving support for OS/2. We don't have anyone seriously working on Windows (there are a small few patches, but no-one pushing hard enough and doing to extra effort to get them to a sufficient quality level to be included).

It's strange you say that, cause honestly (as mentioned above) - so far, Mplayer runs smother on Windows then Linux. Back in the old days, the main reason I tried/used/learned Linux was cause Mplayer, since the Windows alternatives sucked big time. Remember Ace Mega Codec Pack - now that was a traumatizing experience (conflicts, OS crashes, bugs....etc). Back then, the best Windows video player where codecs relates and since it was the beginning of Windows multimedia, so many video formats and so many encoders emerged that you always end up with a movie that needs some unknown decoder. Was such a hassle and Mplayer fixed all my video problems, even played smother but guess Linux had some influence with that part. :)

[lasuocera]

http://i49.tinypic.com/2d92qlz_th.jpg (http://i49.tinypic.com/2d92qlz.jpg)

:confused:

OK, I see that you are using QT 4.6.2 (compiled with QT 4.5.1) while on my installation i have QT 4.5.1 (compiled with QT 4.5.1). Could be this the problem?

[rvm]

Ok sorry, i'll try to explain. Well wrong aspect ratio, cannot select output video and sound driver, no information on info and properties and the controls (play,pause,seek) are disabled.

This happens if smplayer can't read the output from mplayer. Maybe you have a really-quiet option in mplayer\config?

[LoRd_MuldeR]

OK, I see that you are using QT 4.6.2 (compiled with QT 4.5.1) while on my installation i have QT 4.5.1 (compiled with QT 4.5.1). Could be this the problem?

Nope, that shouldn't be the problem. In fact SMPlayer should 100% work with the Qt version that it was compiled with.

However if you installed my package (which I assume, as you are posting in this thread), it should say "using Qt 4.6.2", because I have included the latest Qt and not found any problems with it so far...

[lasuocera]

I must admit that I downloaded SMPlayer from the official project page and then manually updated mplayer. After your post I have downloaded your package and actually I can play .avi files, but .mkv (h264+aac) files don't work. Strange thing is that with your package I can select output drivers (video & audio), info and properties page works.

I've tested original and your package on 2 different machines and the result is the same.

[LoRd_MuldeR]

...actually I can play .avi files, but .mkv (h264+aac) files don't work.

Strange. But "don't work" isn't a very helpful problem description. What happens? What does the MPlayer log say ???

[lasuocera]

After further investigation I have to say that your package is working ok. Let me explain: I've tested .mkv on old computer with an hercules 3d prophet 4500 and this is mplayer log :

Movie-Aspect is 1.77:1 - prescaling to correct movie aspect.
ID_VIDEO_ASPECT=1.7750
VO: [directx] 848x480 => 852x480 Planar YV12
<vo_directx><ERROR>hardware can't do overlay
<vo_directx><FATAL ERROR>can't use overlay mode: please use -vo directx:noaccel
FATAL: Cannot initialize video driver.

FATAL: Could not initialize video filters (-vf) or video output (-vo).

Exiting... (End of file)
ID_EXIT=EOF

setting video driver to -vo directx:noaccel or gl solved the problem. On my new computer with ati radeon 3870 there are no problems.

I'm moving now to the SMPlayer official forum to try to find out where is the problem with the official package.
Thank you very much for your support

Gilberto

[LoRd_MuldeR]

It is highly recommended to use either the OpenGL renderer ("-vo gl" / "-vo gl:yuv=2") or the Direct3D renderer ("-vo direct3d") instead of the Overlay renderer ("-vo directx") anyway!

[Reimar]

It is highly recommended to use either the OpenGL renderer ("-vo gl" / "-vo gl:yuv=2") or the Direct3D renderer ("-vo direct3d") instead of the Overlay renderer ("-vo directx") anyway!

directx is likely to be faster for anyone who considers it good enough...
Anyway in case you haven't noticed you shouldn't really need the yuv=2, it should be auto-detected since around 30489 - only currently known "problem" is that some software OpenGL renderers suport fragment programs and this makes those even more horribly slow.
Edit: there is also a -vo gl_nosw that will fail to initialize when only software rendering is available - detection probably only works on Linux though so far.
Might be possible it could be improved so much that "-vo gl_nosw," or something like that could be made the default - but that kind of thing needs heavy testing.

[lych_necross]

Hey LoRd_MuldeR,

How do you invoke UPX in your installer? What options do you use (--best?)? I'm asking because I was bored one afternoon and I decided to use upx on vlc's files for the heck of it. I don't have much experience with upx and hope I didn't mess anything up (it seems to work alright).

[LoRd_MuldeR]

Hey LoRd_MuldeR,

How do you invoke UPX in your installer? What options do you use (--best?)? I'm asking because I was bored one afternoon and I decided to use upx on vlc's files for the heck of it. I don't have much experience with upx and hope I didn't mess anything up (it seems to work alright).

Look at this part of the installer:

DetailPrint "$(PackingEXE) $0"
nsExec::Exec /TIMEOUT=180000 '"$PLUGINSDIR\upx.exe" --compress-icons=0 "$0"'
Pop $1

So I use default compression, which as far as I know, equals the "-8" option. I could use "--best" to squish out some more compression, but at the cost of increased install time. If the files were pre-UPX'd then I'd use "--brute" or even "--ultra-brute". But for "on the fly" UPX'ing files, I stay with the default. Also it's useful to use "--compress-icons=0", because this way no icons are compressed. By default only the 'main' icon is not compressed. That will result in problem as soon as the EXE contains more than just one icon and if you want to use those 'additional' icons for file associations...

[lych_necross]

I'll give that a try. Thanks for the info :D

[mariush]

Brute and Ultra-Brute is not recommended because it compresses executables that may not function correctly compressed.

As I said before, it's best to either compress them before the setup is made (to reduce the size of the setup as upx often compresses better than whatever nsis uses - because it's NOT lossless) or leave them uncompressed... the benefits of compressing are less than the risk of getting files detected as viruses.

[LoRd_MuldeR]

Brute and Ultra-Brute is not recommended because it compresses executables that may not function correctly compressed.

Huh? As far as I know, the "--brute" mode simply tests several compressor settings (instead of just one) and finally picks the settings that gave the smallest file.

And "--ultra-brute" additionally considers LZMA compression. I use it for all my 'release' binaries and did not encounter any problem with my binaries so far.

As I said before, it's best to either compress them before the setup is made (to reduce the size of the setup as upx often compresses better than whatever nsis uses - because it's NOT lossless) or leave them uncompressed...

Problem is that if you have several huge binaries in an installer, then UPX'ing them beforehand makes the installer much bigger. That's because after UPX'ing the binaries, the installer's compressor (MakeNSIS) cannot compress the files any further. Also UPX cannot leverage redundancy across the filer border, while MakeNSIS can -- but only if the binaries are still uncompressed and if "solid" compression is enabled. Therefore I decided to UPX the files at install time (i.e. after the files have been extracted from the installer). And it's optionally, so the user can skip the step.

...because it's NOT lossless

Indeed, UPX is not lossless in the sense that the file you get after decompression may not be bit-identical to the original file. But the decompressed binary is (or at least should be ^^) functionally equivalent to the original binary. That's all we need. However there is a mode in UPX the will preserve the original file in a bit-identical way ("--exact"). Just in case you need that.

the benefits of compressing are less than the risk of getting files detected as viruses.

FALSE POSITIVES are a problem, indeed. Some A/V programs blindly suspect all "packed" binaries, which is nonsense, of course! Just because Malware may use "EXE packers", you can't conclude that legitimate software never uses EXE packers. So I certainly won't constrain my installer or software, just because some A/V developers did a bad job :rolleyes:

Whenever I encounter a FALSE POSITIVE, I submit the file to my A/V developer and ask them to fix it. And I urge everybody to do the same...

[lych_necross]

The only problem I've noticed is that upx'd exes (done after installation) sometimes break the program's uninstaller (requiring a reinstall to uninstall). I've only noticed this with NSIS programs (I guess it depends on the options used in NSIS).

[LoRd_MuldeR]

The only problem I've noticed is that upx'd exes (done after installation) sometimes break the program's uninstaller (requiring a reinstall to uninstall). I've only noticed this with NSIS programs (I guess it depends on the options used in NSIS).

That makes no sense to me :confused:

Maybe your installer didn't wait for UPX to complete? So UPX was still running and locking the binary, so the Uninstaller couldn't delete it ???

[mariush]

you're right Mulder, my apologies... i confused the --brute flag with the -f flag which forces compression even when upx feels the executable won't work compressed.

[lych_necross]

That makes no sense to me :confused:

Maybe your installer didn't wait for UPX to complete? So UPX was still running and locking the binary, so the Uninstaller couldn't delete it ???
Here is a screen shot of the error.
http://i46.tinypic.com/x25lk4.jpg
EDIT: I tried using --exact and --strip-relocs=0, but it doesn't work. Skipping the offending file works just fine (the savings wasn't that great anyways).

[kypec]

The only problem I've noticed is that upx'd exes (done after installation) sometimes break the program's uninstaller (requiring a reinstall to uninstall). I've only noticed this with NSIS programs (I guess it depends on the options used in NSIS).
Make sure that you don't apply UPX to Uninstall.exe itself. Installers and most likely also uninstallers created with NSIS do always perform internal integrity check (CRC or hash or whatever) to ensure that EXE file has not been altered.

[LoRd_MuldeR]

Here is a screen shot of the error.
http://i46.tinypic.com/x25lk4.jpg
EDIT: I tried using --exact and --strip-relocs=0, but it doesn't work. Skipping the offending file works just fine (the savings wasn't that great anyways).

Did you try to manually UPX the final (un)installer EXE or what? This won't work, because UPX appends a data section ("Overlay") to the end of the installer EXE file. UPX will remove the overlay or at least change it's position within the file. That breaks the installer! If you want your (un)installer to be UPX'd, then MakeNSIS must call UPX or whatever "EXE Packer" you use, so the Packer is applied only on the EXE Header and before the data (plus CRC value) is appended! MakeNSIS has a special compile-time command that can be used to call an EXE Packer. That's what you need...

Please see:
http://nsis.sourceforge.net/Docs/Chapter5.html#5.1.10

[lych_necross]

I'm a noob at UPX, so I made the mistake of manually using upx --best *.exe in the vlc directory (which as Mulder & kypec said, compressed uninstall.exe and killed it). After reading upx's manual a little closer and seeing your posts, I know now not to do that. I ended up manually running upx in the plugins directory on the dlls only (saved a lot of disk space). I would like to make a custom installer ultimately that does this automatically (just for kicks), but I need to read up on nsis a little more.

[PatchWorKs]

Just a question guyz: why Mplayer/Mencoder x64 builds (for win) are so rare ?

FFmpeg64 (http://ffmpeg.arrozcru.org/autobuilds/) works great, so why Mplayer shouldn't ?

It would be great to have x64/MT builds for windows !

[LoRd_MuldeR]

MPlayer for Windows 2010-03-17 :)

[2010-03-17]
* MPlayer binaries updated to SVN-r30886

[ElQuia]

Just a question guyz: why Mplayer/Mencoder x64 builds (for win) are so rare ?

FFmpeg64 (http://ffmpeg.arrozcru.org/autobuilds/) works great, so why Mplayer shouldn't ?

It would be great to have x64/MT builds for windows !

Nice question PatchWorks. I would LOVE a pure x64 build
Windows 7 is great, but I'm sort of tired of "hybrid" x86/x64 "bloatware" ... It's about time windows learned something of the linux community ... GO 64Bits WITHOUT LOOKING BACK!

Mulder? Is it feasible ? Can do?

[LoRd_MuldeR]

Mulder? Is it feasible ? Can do?

a) I currently don't make any MPlayer builds. Instead I include the (patched) builds provided by Sherpya. I don't intend to change that procedure anytime soon ;)

b) Even if somebody did provide up-to-date 64-Bit builds of MPlayer with the same functionality (fontconfig, dvdnav, etc.) as Sherpya's builds, I probably wouldn't include them into my package (yet). That's because 64-Bit builds require a 64-Bit CPU and a 64-Bit OS, while 32-Bit builds run perfectly fine on both, 32-Bit and 64-Bit, systems. And the majority of Windows users is still are on 32-Bit OS.

c) Unless the 2 GB per process limit becomes a problem, going 64-Bit doesn't give that much benefit. And I doubt MPlayer eagerly needs more than 2 GB of memory.

[ElQuia]

Mulder: downloaded the new build. 2 bugs: a- when playing high def movies (ts, mkv, wmv, etc) full screen, floating bar does NOT show up on mouse move on the bottom of the screen, also with hdef on full screen right clic menu does not apppear . b- when playing high def movies (happens with ts and mkv, have not tried other formats) the progress indicator on bottom bar does not move even if movie is playing, and can not be moved with mouse ("by hand" )
Edit: I'm talking of SMplayer interface, NOT MPUI. MPUI does not have the "b" problem, but its jerky with high def

Ideas? Going to revert to previous build.

[LoRd_MuldeR]

Mulder: downloaded the new build. 2 bugs: a- when playing high def movies (ts, mkv, wmv, etc) full screen, floating bar does NOT show up on mouse move on the bottom of the screen, also with hdef on full screen right clic menu does not apppear . b- when playing high def movies (happens with ts and mkv, have not tried other formats) the progress indicator on bottom bar does not move even if movie is playing, and can not be moved with mouse ("by hand" )
Edit: I'm talking of SMplayer interface, NOT MPUI. MPUI does not have the "b" problem, but its jerky with high def

Ideas? Going to revert to previous build.

That would indicate a SMPlayer bug, that needs to be reported to the SMPlayer developer.

But: I did not change the SMPlayer version between the latest and the previous release, so this doesn't really make sense to me.

Also both, fullscreen mode and the seeking bar, seem to work fine for me :confused:

[ElQuia]

Mulder, OK sorry got it working. Option add black bars generates bugs: stutering when changing to full screen, non present floating bar and non present context menu in hd full screen. I have nearly everything working ok now, if you are interested I could send you how I have my options setted. (tell me how to show all info please)

BUT: I can´t get 1080 HD playing with out jerking. I have an x2 AMD 6000, 6 GB RAM, SATA RAid 0, screen 1600x900 on aGForce 8600 GT w/512mb video card, windows 7 x64. MPC Home Cinema and Power DVD play 1080 OK, J. River Media Center nearly ok, (drops some frames) buy mplayer wont. 720 plays ok. Maybe internal post processing is to much for my pc?. smplayer has the beauty of being able to adjust video (color, hue, contrast, etc) for each movie (in a perfect world it would not be needed but .... ) playback quality is superb, etc.

I was thinking that my PC is lacking for 1080 HD, but why power dvd and MPC can play them without dropping A LOT of frames?

Ideas ?????

[ElQuia]

Mulder, OK sorry got it working. Option add black bars generates bugs: stutering when changing to full screen, non present floating bar and non present context menu in hd full screen. I have nearly everything working ok now, if you are interested I could send you how I have my options setted. (tell me how to show all info please)

BUT: I can´t get 1080 HD playing with out jerking. I have an x2 AMD 6000, 6 GB RAM, SATA RAid 0, screen 1600x900 on aGForce 8600 GT w/512mb video card, windows 7 x64. MPC Home Cinema and Power DVD play 1080 OK, J. River Media Center nearly ok, (drops some frames) buy mplayer wont. 720 plays ok. Maybe internal post processing is to much for my pc?. smplayer has the beauty of being able to adjust video (color, hue, contrast, etc) for each movie (in a perfect world it would not be needed but .... ) playback quality is superb, etc.

I was thinking that my PC is lacking for 1080 HD, but why power dvd and MPC can play them without dropping A LOT of frames?

Ideas ?????

Ideas :?: :confused:

[ffmpeg]

MPlayer for Windows 2010-03-17 :)

This version should be upgraded or dropped ASAP because mplayer has broken HUGE codecs (such as WMV7/8, FLV1.....) decoding due to SSE instruction crash on Windows

Please check my local patch on how to fix this issue:


Index: libmpcodecs/mp_image.c
===================================================================
--- libmpcodecs/mp_image.c (revision 30945)
+++ libmpcodecs/mp_image.c (working copy)
@@ -31,13 +31,15 @@

#include "libvo/fastmemcpy.h"

+#define av_memalign(a,b) av_malloc(b)
+
void mp_image_alloc_planes(mp_image_t *mpi) {
// IF09 - allocate space for 4. plane delta info - unused
if (mpi->imgfmt == IMGFMT_IF09) {
- mpi->planes[0]=memalign(64, mpi->bpp*mpi->width*(mpi->height+2)/8+
+ mpi->planes[0]=av_memalign(64, mpi->bpp*mpi->width*(mpi->height+2)/8+
mpi->chroma_width*mpi->chroma_height);
} else
- mpi->planes[0]=memalign(64, mpi->bpp*mpi->width*(mpi->height+2)/8);
+ mpi->planes[0]=av_memalign(64, mpi->bpp*mpi->width*(mpi->height+2)/8);
if (mpi->flags&MP_IMGFLAG_PLANAR) {
int bpp = IMGFMT_IS_YUVP16(mpi->imgfmt)? 2 : 1;
// YV12/I420/YVU9/IF09. feel free to add other planar formats here...
@@ -65,7 +67,7 @@
} else {
mpi->stride[0]=mpi->width*mpi->bpp/8;
if (mpi->flags & MP_IMGFLAG_RGB_PALETTE)
- mpi->planes[1] = memalign(64, 1024);
+ mpi->planes[1] = av_memalign(64, 1024);
}
mpi->flags|=MP_IMGFLAG_ALLOCATED;
}
Index: libmpcodecs/mp_image.h
===================================================================
--- libmpcodecs/mp_image.h (revision 30945)
+++ libmpcodecs/mp_image.h (working copy)
@@ -24,6 +24,8 @@
#include <string.h>
#include "mp_msg.h"

+#include "libavutil/mem.h"
+
//--------- codec's requirements (filled by the codec/vf) ---------

//--- buffer content restrictions:
@@ -221,9 +223,9 @@
if(!mpi) return;
if(mpi->flags&MP_IMGFLAG_ALLOCATED){
/* becouse we allocate the whole image in once */
- if(mpi->planes[0]) free(mpi->planes[0]);
+ if(mpi->planes[0]) av_free(mpi->planes[0]);
if (mpi->flags & MP_IMGFLAG_RGB_PALETTE)
- free(mpi->planes[1]);
+ av_free(mpi->planes[1]);
}
free(mpi);
}

[LoRd_MuldeR]

This version should be upgraded or dropped ASAP because mplayer has broken HUGE codecs (such as WMV7/8, FLV1.....) decoding due to SSE instruction crash on Windows

Please check my local patch on how to fix this issue:


Index: libmpcodecs/mp_image.c
===================================================================
--- libmpcodecs/mp_image.c (revision 30945)
+++ libmpcodecs/mp_image.c (working copy)
@@ -31,13 +31,15 @@

#include "libvo/fastmemcpy.h"

+#define av_memalign(a,b) av_malloc(b)
+
void mp_image_alloc_planes(mp_image_t *mpi) {
// IF09 - allocate space for 4. plane delta info - unused
if (mpi->imgfmt == IMGFMT_IF09) {
- mpi->planes[0]=memalign(64, mpi->bpp*mpi->width*(mpi->height+2)/8+
+ mpi->planes[0]=av_memalign(64, mpi->bpp*mpi->width*(mpi->height+2)/8+
mpi->chroma_width*mpi->chroma_height);
} else
- mpi->planes[0]=memalign(64, mpi->bpp*mpi->width*(mpi->height+2)/8);
+ mpi->planes[0]=av_memalign(64, mpi->bpp*mpi->width*(mpi->height+2)/8);
if (mpi->flags&MP_IMGFLAG_PLANAR) {
int bpp = IMGFMT_IS_YUVP16(mpi->imgfmt)? 2 : 1;
// YV12/I420/YVU9/IF09. feel free to add other planar formats here...
@@ -65,7 +67,7 @@
} else {
mpi->stride[0]=mpi->width*mpi->bpp/8;
if (mpi->flags & MP_IMGFLAG_RGB_PALETTE)
- mpi->planes[1] = memalign(64, 1024);
+ mpi->planes[1] = av_memalign(64, 1024);
}
mpi->flags|=MP_IMGFLAG_ALLOCATED;
}
Index: libmpcodecs/mp_image.h
===================================================================
--- libmpcodecs/mp_image.h (revision 30945)
+++ libmpcodecs/mp_image.h (working copy)
@@ -24,6 +24,8 @@
#include <string.h>
#include "mp_msg.h"

+#include "libavutil/mem.h"
+
//--------- codec's requirements (filled by the codec/vf) ---------

//--- buffer content restrictions:
@@ -221,9 +223,9 @@
if(!mpi) return;
if(mpi->flags&MP_IMGFLAG_ALLOCATED){
/* becouse we allocate the whole image in once */
- if(mpi->planes[0]) free(mpi->planes[0]);
+ if(mpi->planes[0]) av_free(mpi->planes[0]);
if (mpi->flags & MP_IMGFLAG_RGB_PALETTE)
- free(mpi->planes[1]);
+ av_free(mpi->planes[1]);
}
free(mpi);
}



You should post this on the MPlayer mailing list and/or contact Sherpya. I don't make any MPlayer builds, currently.

However I will update my package to the 2010-03-22 (http://oss.netfarm.it/mplayer-win32.php) builds as soon as possible. Which may (or may not) be this evening.

The new builds should contain some SSE-related fix. Not sure if that's the issue you are referring to...

[ffmpeg]

The SSE-related fix is not the same bug as my fix due to memalign() on Windows

I will notice Sherpya

[LoRd_MuldeR]

MPlayer for Windows 2010-03-23 :)

[2010-03-23]
* MPlayer binaries updated to SVN-r30945
* SMPlayer updated to Version 0.6.8 (SVN-r3478)

@ffmpeg:
Both, FLV1 and WMV2/3, work perfectly fine on my system with that build. Do you still encounter problem?

[ffmpeg]

MPlayer for Windows 2010-03-23 :)

@ffmpeg:
Both, FLV1 and WMV2/3, work perfectly fine on my system with that build. Do you still encounter problem?

Confirmed
The SSE crash is fixed in this version
Thanks

[Clobon]

Hi,

I'd really like to thank you for another great package... but I never got it:
Oops! (509)
This account's public links are generating too much traffic and have been temporarily disabled!

Seems you exceeded your traffic limit><"

Looking forward for your package of MPlayer for Windows... Clobon

[LoRd_MuldeR]

Hi,

I'd really like to thank you for another great package... but:


Seems you exceeded your traffic limit><"

Looking forward for your package of MPlayer for Windows... Clobon

Yes, my Dropbox mirror is currently down. They suspend accounts that cause a lot of traffic. Happens regularly to me :p

I can't really complain about this, because Dropbox is a free service and (in contrast to other "one click" file hosters) they allow direct download links.

Fortunately I have various mirrors and my PHP script will distribute the load among all mirrors. So try another mirror and it should work...

[ElQuia]

Mulder, OK sorry got it working. Option add black bars generates bugs: stutering when changing to full screen, non present floating bar and non present context menu in hd full screen. I have nearly everything working ok now, if you are interested I could send you how I have my options setted. (tell me how to show all info please)

BUT: I can´t get 1080 HD playing with out jerking. I have an x2 AMD 6000, 6 GB RAM, SATA RAid 0, screen 1600x900 on aGForce 8600 GT w/512mb video card, windows 7 x64. MPC Home Cinema and Power DVD play 1080 OK, J. River Media Center nearly ok, (drops some frames) buy mplayer wont. 720 plays ok. Maybe internal post processing is to much for my pc?. smplayer has the beauty of being able to adjust video (color, hue, contrast, etc) for each movie (in a perfect world it would not be needed but .... ) playback quality is superb, etc.

I was thinking that my PC is lacking for 1080 HD, but why power dvd and MPC can play them without dropping A LOT of frames?

Ideas :confused:

[LoRd_MuldeR]

Mulder, OK sorry got it working. Option add black bars generates bugs: stutering when changing to full screen, non present floating bar and non present context menu in hd full screen. I have nearly everything working ok now, if you are interested I could send you how I have my options setted. (tell me how to show all info please)

BUT: I can´t get 1080 HD playing with out jerking. I have an x2 AMD 6000, 6 GB RAM, SATA RAid 0, screen 1600x900 on aGForce 8600 GT w/512mb video card, windows 7 x64. MPC Home Cinema and Power DVD play 1080 OK, J. River Media Center nearly ok, (drops some frames) buy mplayer wont. 720 plays ok. Maybe internal post processing is to much for my pc?. smplayer has the beauty of being able to adjust video (color, hue, contrast, etc) for each movie (in a perfect world it would not be needed but .... ) playback quality is superb, etc.

I was thinking that my PC is lacking for 1080 HD, but why power dvd and MPC can play them without dropping A LOT of frames?

Ideas ?????

No need to repeat yourself. Double-posting is objectionable :readrule:

Anyway, playback performance is mainly limited by the decoder speed. And for a software-only decoder the speed is limited by your CPU. If you have a multi-core CPU, better performance can be reached by using a multi-threaded decoder (note: the MPlayer 'P4' and 'AthlonXP' builds in my package do have FFmpeg-MT enabled now) and setting up the appropriate number of decoding threads. There are even "faster" decoders than FFmpeg-MT, such as CoreAVC or DiAVC. I don't know what decoder you used in MPC-HC, but maybe you used one of those? In theory you should be able to use a DirectShow-based decoder (e.g. CoreAVC) in MPlayer now, thanks to "dsnative" support. However I couldn't get dsnative to work on my system yet. Furthermore the renderer may limit playback performance. You should use the GL renderer in MPlayer (-vo gl), but you can also try Direct3D (-vo direct3d). With the GL renderer you can try "-vo gl:yuv=2" or "-vo gl:yuv=3". Also you can try to disable double buffering, because in my experience on Windows 7 with Aero enabled you don't need it! Last but not least you can try to enabled/disable "Draw using slices" and/or "Direct rendering" and see whether it helps/hurts or does nothing...

[mariush]

Mulder, check your YM... I've sent you a couple of lines (or contact me and I'll repeat myself :)).

[sarmaee]

Audio playback is retarded for files containing 6ch. AAC audio :(

[ElQuia]

guys I cant get the floating control in full screen workin with HD video. Its not format or container dependent, happens in avi, mkv, etc but ONLY on high def

Any ideas please ?

[pr0fessor]

hi, i have noticed, that when playing stream (http://78.90.221.226:8000/alpha) mplayer create *.tmp file in the %tmp% folder (when this is videostream the temp file gets very big - about gb for hour). what's the point ot this - i can use wget for windows or flashget or dump stream with mplayer? i tested from old release mplayer-1.0rc2 to latest - the same problem. in latest releases switch "-lavdopts skiploopfilter=all" not working (i use it for slow computers and h264 720p)
p.s. it's strange - when play something from di.fm http://72.26.204.28:6384 - there is no tmp file...