MPlayer for Windows (2019-10-15)

[Clobon]

MPlayer for Windows 2011-05-25 :)

Hi,

I'm having major slowdowns and apphangs. MP doesn't react anymore.
CPU usage beyond 50% with not critical files. With previous version everythings fine.

Am I the only one?

Regards, Clobon

PS: No logs, can't get to them. Does MPlayer save these logs anywhere else?

[LoRd_MuldeR]

PS: No logs, can't get to them. Does MPlayer save these logs anywhere else?

In SMPlayer goto "Options" -> "View Logs" -> "MPlayer". Or run MPlayer from the command-line via "MPlayer.exe [parameters] > log.txt"

[LoRd_MuldeR]

MPlayer for Windows 2011-06-09 :)

[2011-06-09]
* MPlayer binaries updated to SVN-r33574
* Removed 'float' decoders from codecs.conf

Download #1: http://code.google.com/p/mulder/downloads/detail?name=MPUI.2011-06-09.Full-Package.exe&can=2&q=
Download #2: http://code.google.com/p/mulder/downloads/detail?name=MPUI.2011-06-09.Light-Package.exe&can=2&q=

[WSC4]

In the config file,

## You can use the DirectX or OpenGL video output, default is directx.
#vo=directx
vo=gl

Is this a typo? OpenGL seems to be the default, and it ran my videos in slow motion. This was in Mplayer and MPUI, not with smplayer_portable. I changed config to...

## You can use the DirectX or OpenGL video output, default is directx.
vo=directx
#vo=gl

...and it fixed it. I'm using an older video card, so I don't know if that is the cause. Anyone else have this problem?

[LoRd_MuldeR]

Nope, it's intended.

Using the old "directx" (Overlay) renderer is not a good idea on modern Windows systems (Vista and later), as it will force Aero Glass off and thus will make the user complain ;)

So a better choice is "gl" or "direct3d" nowadays, as they should work okay on all systems. The GL renderer should work on all halfway decent graphic cards, the Direct3D renderer is more experimental.

Last but not least: The default renderer in the config file is only used when you run MPlayer from the console and don't use the "-vo" switch. GUI's, like SMPlayer, will overwrite the renderer...

[Reimar]

Nope, it's intended.

Using the old "directx" (Overlay) renderer is not a good idea on modern Windows systems (Vista and later), as it will force Aero Glass off and thus will make the will complain ;)

So a better choice is "gl" or "direct3d" nowadays, as they should work okay on all systems. The GL renderer should work on all halfway decent graphic cards, the Direct3D renderer is more experimental.

Last but not least: The default renderer in the config file is only used when you run MPlayer from the console and don't use the "-vo" switch. GUI's, like SMPlayer, will overwrite the renderer...

Should you use some more reasonable default?
Like
vo=gl_nosw,
Some S3/SiS cards have only (horrible) direct3d and no OpenGL support, on Windows XP vo=gl will use the software renderer.
You could also try
vo=gl_nosw,direct3d,
however it has the issue that I think vo_direct3d will happily try to run in software emulation mode.

[WSC4]

I copied across "Mencoder.exe" (same build) to the folder where is "Mplayer for Windows" is: C:\Program Files\MPlayer for Windows. Mencoder still seems to work OK there, but I was wondering if it was just a waste of time? Would it use the codecs and dll's there?

[LoRd_MuldeR]

I copied across "Mencoder.exe" (same build) to the folder where is "Mplayer for Windows" is: C:\Program Files\MPlayer for Windows. Mencoder still seems to work OK there, but I was wondering if it was just a waste of time? Would it use the codecs and dll's there?

It certainly doesn't hurt to have MEncoder.exe in your 'MPlayer for Windows' folder.

And I think it should be able to use the "binary Codecs", as it uses the same codebase as MPlayer.

However you won't need the binary Codecs for the great majority of all input formats...

(Only for same rare/proprietary ones)

[rogerdpack]

Nope, it's intended.

Using the old "directx" (Overlay) renderer is not a good idea on modern Windows systems (Vista and later), as it will force Aero Glass off and thus will make the user complain ;)

So a better choice is "gl" or "direct3d" nowadays, as they should work okay on all systems. The GL renderer should work on all halfway decent graphic cards, the Direct3D renderer is more experimental.

Last but not least: The default renderer in the config file is only used when you run MPlayer from the console and don't use the "-vo" switch. GUI's, like SMPlayer, will overwrite the renderer...


I had a problem recently where running with -vo gl in windows uses like tons of cpu for no reason, whereas the others don't, so you may want to take that into consideration. This is with a new'ish graphics card with updated drivers, and windows 7, so I almost doubt it's hardware fault...

[rogerdpack]

Hello, and thanks for providing what seems to be the only updated builds of smplayer+mplayer out there :)

Ex: it has updated mplayer so dvdnav:// doesn't crash anymore on seeking [phew] I have no idea why the author of smplayer doesn't release it with newer versions of mplayer, but anyway...

I do notice after downloading/installing and choosing "my cpu"

this output from mplayer:

SSE supported but disabled
SSE2 supported but disabled

I assume this is expected?

Thanks again! I am using smplayer builds from here to power an editing/upconverting software DVD player I am making :) http://rogerdpack.t28.net/sensible-cinema/

Also after prompting for update it says "possible malicious download detected, aborting" instead of doing anything useful.

Thanks so much!
-roger-

[WSC4]

Yes, I just got the same message. It actually reads:

Signature seems to be invalid. Download may be malicious. Aborting! :eek:

It comes from the "AutoUpdate.exe" file.

I'm running XP Pro, SP 3.

[cweb]

Yes, I just got the same message. It actually reads:

Signature seems to be invalid. Download may be malicious. Aborting! :eek:

It comes from the "AutoUpdate.exe" file.

I'm running XP Pro, SP 3.
I have the same thing here. Running Win7 64-bit.

[LoRd_MuldeR]

Yes, I just got the same message. It actually reads:

Signature seems to be invalid. Download may be malicious. Aborting! :eek:

It comes from the "AutoUpdate.exe" file.

I'm running XP Pro, SP 3.

The old web-site (domain) is down. So instead of the update info, the updater will now download a stupid "dummy" site (parked domain).

Instead of sending a proper "404 Not Found" these morons redirect to a site full of advertising - for every URL requested from that domain.

Fortunately I prepared for this case an added the signature check. Of course the signature check will fail now!

...because both, the update info itself and the signature file, are just random HTML documents now.

With the next update (which you will have to download and install manually) I will change the domain used for the update check.

this output from mplayer:

SSE supported but disabled
SSE2 supported but disabled

I assume this is expected?

For AMD CPU's it is! For newer AMD's we can choose between the SSE/SSE2 enabled build and the 3DNow! enabled build.

I was told that in this case 3DNow! probably is the better choice...

(It is impossible to include an "optimal" build for every single CPU in existence in the installer, as there are far too many combinations)

[Reimar]

For AMD CPU's it is! For newer AMD's we can choose between the SSE/SSE2 enabled build and the 3DNow! enabled build.

I was told that in this case 3DNow! probably is the better choice...


At best for very, very old AMD CPUs. On anything from at least Athlon2 you definitely do _not_ want SSE and SSE2 forced of.
Also remember that AMD intends to remove 3DNow from its CPUs in the future.
My guess is that for anything starting from the first Athlon the order of preference would be:
1) Build with SSE, SSE2, 3DNow
2) Build with runtime cpudetection
3) Build with SSE, SSE2 but no 3DNow
4) Build with only 3DNow

With the difference between the first 3 hardly relevant.

[rogerdpack]

The old web-site (domain) is down. So instead of the update info, the updater will now download a stupid "dummy" site (parked domain).

...

For AMD CPU's it is! For newer AMD's we can choose between the SSE/SSE2 enabled build and the 3DNow! enabled build.

I was told that in this case 3DNow! probably is the better choice...


I have an AMD something something so I guess that's expected then.
Hope you can get your domain back :)

Also I noticed the checkbox to use lanczos, however...it doesn't actually end up using lanczos unless a specific -vf scale is specified (though I could be mistaken)?

Thanks and keep up the good work.
-roger-

[WSC4]

I had a problem recently where running with -vo gl in windows uses like tons of cpu for no reason, whereas the others don't, so you may want to take that into consideration. This is with a new'ish graphics card with updated drivers, and windows 7, so I almost doubt it's hardware fault...

After reading the replies to my last post about this, I had a good look at the drivers for the card I'm using, and found they were well out of date. Went back and changed to vo=gl after I updated the drivers, and the slow-motion problem disappeared. Moreover, video colours are more vibrant and the resolution appears sharper than Directx.

Testing with either gl, gl2, sdl or directx, CPU usage was about 40% max for all of them on my machine. This was with a 6000 kbps, 720x480, (4:3) MPEG-PS on my HD.

[LoRd_MuldeR]

Also I noticed the checkbox to use lanczos, however...it doesn't actually end up using lanczos unless a specific -vf scale is specified (though I could be mistaken)?

Yes, the "-sws" options sets the software scaling method. But it does not force software scaling. And you generally don't want that.

Software scaling needs more CPU time than "hardware" scaling and thus may result in slow (stuttering) playback, depending on the power of your CPU.

However the quality of software scaling may be better than the (hardware) scaling of the MPlayer renderers, especially in Lanczos or Spline modes.

In SMPlayer front-end there is an option in "Video" -> "Filters" to enable software scaling, if wanted...

[rogerdpack]

...
Went back and changed to vo=gl after I updated the drivers, and the slow-motion problem disappeared.
...


Watching (at least) MPEG streams for me here, Geforce 6500 LE with latest drivers, mplayer uses 100% of one core *always* whereas with -vo directx or -vo direct3d it uses like 10% cpu. No obvious error messages to explain it in the output.

It's probably nvidia's fault, but it does still occur here, FWIW.


Yes, the "-sws" options sets the software scaling method. But it does not force software scaling. And you generally don't want that.


I guess what I was saying is more that "newbies might think they are getting something by just having that checked, but in reality they're not." One suggestion might be to add a disclaimer note "(you must use a hard-coded resize for this to have effect)" or the what not.

In reality what would be even better from my view would be an option with smplayer for "scale to screen width" or "scale to several times screen width" as this seems to upscale quite well, but as smplayer dev. per se feels dead I guess it might be a long time in coming....

Thanks!
-roger-

[rogerdpack]

Could I make a humble request for a new release at some point for "mplayer for windows"? I just ran into a freaky bug in ffmpeg [1] that is present in the latest "mplayer for windows" but seems fixed in the latest mplayer builds from sherpya. Also a new build might avoid that "download appears corrupted" message et al :) for my users.

Thanks!
-roger-
[1] http://avcodec.org/trac/ffmpeg/ticket/265

[LoRd_MuldeR]

I will make a new package soon. Not today though ;)

[rogerdpack]

I will make a new package soon. Not today though ;)

Cool thanks for your work on this.

Re: AMD SSE

Apparently it once used to crash (might not anymore), and then this message

http://permalink.gmane.org/gmane.comp.video.mplayer.cygwin/2605


> SSE/SSE2 are disabled for Windows @ runtime due to historical reasons.
> You can modify cpudetect.c to turn them on. However, even you leave
> this off you are't losing much because
> 1. libavcodec can still use SSE/SSE2 regardless of mplayer's settings.
> 2. SSE are only used for some audio, and SSE2 isn't much faster than MMX.

So I guess that having 3dnow+MMX is about as good as having SSE turned on or something like that. Maybe that's sherpya's rationale behind having the builds that disable it for AMD.
Thanks again.
-roger-

[4P_Bulldozer]

The old web-site (domain) is down. So instead of the update info, the updater will now download a stupid "dummy" site (parked domain).
...
I will make a new package soon. Not today though.

Thank you for providing a wonderful Player, we look forward to the Update.

:)

When you do a rewrite perhaps the Updater could access whichever Primary Site you will be using and when the Signature does not check out it could try a Secondary Site.

The second Site could be a 'go.to' Site (which you could change remotely) so whenever your Primary looses it's Domain the Updater would head to the Secondary and get the new Download (with a new Primary Address); thus this could never happen again.

[Lincoln Burrows]

I Prefer ! Vlc Media Player =)

[LoRd_MuldeR]

I Prefer ! Vlc Media Player =)

While you are free to express your personal opinion, I urge you to respect rule #11 (http://forum.doom9.org/forum-rules.htm)!

[rogerdpack]

Any way to send small donation? Any new build? :P
Cheers!
-roger-

[LoRd_MuldeR]

Any way to send small donation? Any new build? :P
Cheers!
-roger-

Not yet. Other thins kept me busy. But it's on my TODO list ;)

[WSC4]

************************************************
**** Your system is too SLOW to play this! ****
************************************************

Possible reasons, problems, workarounds:
- Most common: broken/buggy _audio_ driver
- Try -ao sdl or use the OSS emulation of ALSA.
- Experiment with different values for -autosync, 30 is a good start.
- Slow video output
- Try a different -vo driver (-vo help for a list) or try -framedrop!
- Slow CPU
- Don't try to play a big DVD/DivX on a slow CPU! Try some of the lavdopts,
e.g. -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all.
- Broken file
- Try various combinations of -nobps -ni -forceidx -mc 0.
- Slow media (NFS/SMB mounts, DVD, VCD etc)
- Try -cache 8192.
- Are you using -cache to play a non-interleaved AVI file?
- Try -nocache.

----------------------------------------------------------------

Playing a standard DVD (not widescreen), I get this in MPlayer and MPUI. I have tried all those setting to no avail. I have not setup a log in SMPlayer yet, but I think it will be the same. Any ideas please?

[rogerdpack]

************************************************
**** Your system is too SLOW to play this! ****
************************************************
...Playing a standard DVD (not widescreen), I get this in MPlayer and MPUI.

I get those too, on fast machines, typically when the it goes to a new title. So I think the message is false :) Maybe you should tell the mplayer guys about it? Anyway you can tell if your system really is too slow by playing it with mplayer.exe. If the audio/video get out of sync, then your system may honestly be too slow to play it. If not, then you're ok.

[roozhou]

************************************************
**** Your system is too SLOW to play this! ****
************************************************

Possible reasons, problems, workarounds:
- Most common: broken/buggy _audio_ driver
- Try -ao sdl or use the OSS emulation of ALSA.
- Experiment with different values for -autosync, 30 is a good start.
- Slow video output
- Try a different -vo driver (-vo help for a list) or try -framedrop!
- Slow CPU
- Don't try to play a big DVD/DivX on a slow CPU! Try some of the lavdopts,
e.g. -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all.
- Broken file
- Try various combinations of -nobps -ni -forceidx -mc 0.
- Slow media (NFS/SMB mounts, DVD, VCD etc)
- Try -cache 8192.
- Are you using -cache to play a non-interleaved AVI file?
- Try -nocache.

----------------------------------------------------------------

Playing a standard DVD (not widescreen), I get this in MPlayer and MPUI. I have tried all those setting to no avail. I have not setup a log in SMPlayer yet, but I think it will be the same. Any ideas please?
Try increasing DVD speed by adding -dvd-speed 16 (means 16x). MPlayer does not use separate thread for file access, so on windows it has very bad file/disc read performance.

[Reimar]

MPlayer does not use separate thread for file access, so on windows it has very bad file/disc read performance.

I does use a separate thread unless you disabled the cache. Which some programs might do for dvdnav:// (but not for dvd://) since it has issues with cache. Not sure if any are significant though.

[roozhou]

I does use a separate thread unless you disabled the cache. Which some programs might do for dvdnav:// (but not for dvd://) since it has issues with cache. Not sure if any are significant though.
In 2008 I tried playing DVDs from DVD-ROM with MPlayer and both dvd:// and dvdnav:// gave me A/V desync. When I ripped the disc to an ISO on my HDD, MPlayer worked perfectly.

IIRC MPlayer works in a synchronized single-threaded way(tell me i am wrong). File reader->demuxer->decoder->filter chain->renderer use a single thread, at least under windows. A good example is when you are dragging MPlayer's video window, everything stops working.

It seems MPlayer's file reader has significant worse performance than DirectShow's Async. Filer Reader.

[Reimar]

IIRC MPlayer works in a synchronized single-threaded way(tell me i am wrong).

You are wrong. Cache runs in a different thread (or process, depends). Decode can run in multiple threads as well. The design is still generally single-threaded but the cases where this can cause issues are more limited than what you seem to assume.

A good example is when you are dragging MPlayer's video window, everything stops working.

After reading a lot I decided that is an unfixable defect in the Windows API, and threading can't fix it unless you violate the Windows API.
As I understood it, the thread handling the dragging operation must be the one that created the window.
At the same time, only the thread that created the window is allowed to draw into it.
It follows that more threads will not help, because it's sill only the one thread that created it that is allow to do anything relevant with the window.
The only half-way proper way to support it seems the way MPlayer supports embedding in SMPlayer: creating the main window by one thread that also handles the dragging and create a sub-window from a different thread where you handle the drawing. But even there I am not sure if that's actually allowed API-wise or just "happens to work". That kind of thing tends to break randomly depending on the video driver in use.
So at that point I decided to go back to dealing with some OS that at least slightly saner APIs. But if someone knows a solution that isn't a total mess I'd be happy to hear it.

[WSC4]

Thanks for all the suggestions. When using:

dvd://1
dvdnav://

The -dvd-speed options had no effect, but when you mentioned it could be an audio / sync problem, I tried it with -nosound. That stopped displaying that "system is too SLOW" message, and the video played smoothly. On the other hand, playing a video file directly from the DVD drive like "mplayer e:\video_ts\vts_01_2.vob" (with sound) also played OK.

Anyway, it doesn't matter. I think the system I'm using is far too old and slow, and I'm in the process of building a new machine with SATA on all drives.

[roozhou]

You are wrong. Cache runs in a different thread (or process, depends). Decode can run in multiple threads as well. The design is still generally single-threaded but the cases where this can cause issues are more limited than what you seem to assume.

I know ffmpeg has mt decoders, but it works differently from other mt decoders, e.g. MainConcept. MainConcept uses Callback functions. When a frame is decoded, the decoder delivers it through Callback function which eliminates the need of N-1 frames delay for N threads.

Another problem is when I am using video filters, all filters runs in the main thread. Ancient software like virtualdub could run each filter in different thread.


After reading a lot I decided that is an unfixable defect in the Windows API, and threading can't fix it unless you violate the Windows API.
As I understood it, the thread handling the dragging operation must be the one that created the window.
At the same time, only the thread that created the window is allowed to draw into it.
It follows that more threads will not help, because it's sill only the one thread that created it that is allow to do anything relevant with the window.
The only half-way proper way to support it seems the way MPlayer supports embedding in SMPlayer: creating the main window by one thread that also handles the dragging and create a sub-window from a different thread where you handle the drawing. But even there I am not sure if that's actually allowed API-wise or just "happens to work". That kind of thing tends to break randomly depending on the video driver in use.
So at that point I decided to go back to dealing with some OS that at least slightly saner APIs. But if someone knows a solution that isn't a total mess I'd be happy to hear it.
I made a patch for it two years ago. Unfortunately I am unable to compile the latest MPlayer under MinGW so I cannot test it now.

The key is: start a new thread, create the video window and run message loop in that thread. The extra API you need are CreateThread, CreateEvent, SetEvent and WaitForSingleObject. It works on directx, opengl and d3d output drivers.

[Reimar]

I know ffmpeg has mt decoders, but it works differently from other mt decoders, e.g. MainConcept. MainConcept uses Callback functions. When a frame is decoded, the decoder delivers it through Callback function which eliminates the need of N-1 frames delay for N threads.

It's completely impossible to decode N frames in parallel unless you have corresponding delay. A callback function doesn't change a bit there.
It probably has other advantages, if they are worth it is another question.


Another problem is when I am using video filters, all filters runs in the main thread. Ancient software like virtualdub could run each filter in different thread.


Yes, that is one case where it shows. However a lot of filters are light-weight and the benefit of slice rendering and thus being able to keep the video data in L1 cache can give more advantage than the parallelism.
Since with frame multithreading at least the decoding happens in a different thread the pressure to change it stayed quite low from my point of view.


The key is: start a new thread, create the video window and run message loop in that thread. The extra API you need are CreateThread, CreateEvent, SetEvent and WaitForSingleObject. It works on directx, opengl and d3d output drivers.


If your new thread created the Window you're not allowed to draw into it from the main thread, going by what I read back then. That it usually happens to work I don't really consider good enough.
You definitely could move all of libvo into a separate thread then at least audio/decoding would run on, but I still don't know how to redraw while the window is moved - there are some hacks with WM_TIMER but none works properly.
The "intended" (in the days of Windows 3 probably) way of reimplementing the movement code is not really an option, too many hacks accumulated there that it's really impossible to reimplement faithfully.
So left with no proper solution my motivation to do anything about it went all the way down to nothing.

[roozhou]

It's completely impossible to decode N frames in parallel unless you have corresponding delay. A callback function doesn't change a bit there.
It probably has other advantages, if they are worth it is another question.

The decoder can deliver decoded frame as soon as possible. Why on earth should the decoder wait for data of the next frame?


Since with frame multithreading at least the decoding happens in a different thread the pressure to change it stayed quite low from my point of view.
The best deinterlacer in MPlayer mcdeint cannot run in real-time on a 4GHz CPU.


The "intended" (in the days of Windows 3 probably) way of reimplementing the movement code is not really an option, too many hacks accumulated there that it's really impossible to reimplement faithfully.
So left with no proper solution my motivation to do anything about it went all the way down to nothing.
Here is my patch for vo_directx. It's a bit dated but I hope it would help.


Index: libvo/vo_directx.c
===================================================================
--- libvo/vo_directx.c (revision 30256)
+++ libvo/vo_directx.c (working copy)
@@ -525,12 +525,6 @@

static void check_events(void)
{
- MSG msg;
- while (PeekMessage(&msg, NULL, 0, 0,PM_REMOVE))
- {
- TranslateMessage(&msg);
- DispatchMessage(&msg);
- }
}

static uint32_t Directx_ManageDisplay(void)
@@ -1047,20 +1041,28 @@
mplayer_put_key(MOUSE_BTN6_DBL);
break;
}
+ case WM_NCHITTEST:
+ if (!vo_fs) {
+ LRESULT ret = DefWindowProc(hWnd, WM_NCHITTEST, wParam, lParam);
+ return HTCLIENT == ret? HTCAPTION : ret;
+ }

}
return DefWindowProc(hWnd, message, wParam, lParam);
}

+static char *dxarg = 0;
+static HANDLE h_creation = 0;

-static int preinit(const char *arg)
+static void WINAPI dx_wnd_thread(int *param)
{
HINSTANCE hInstance = GetModuleHandle(NULL);
char exedir[MAX_PATH];
WNDCLASS wc;
- if(arg)
+ MSG msg;
+ if(dxarg)
{
- if(strstr(arg,"noaccel"))
+ if(strstr(dxarg,"noaccel"))
{
mp_msg(MSGT_VO,MSGL_V,"<vo_directx><INFO>disabled overlay\n");
nooverlay = 1;
@@ -1099,12 +1101,20 @@
wc.lpszClassName = WNDCLASSNAME_FULLSCREEN;
RegisterClass(&wc);

- if (Directx_InitDirectDraw()!= 0)return 1; //init DirectDraw
+ if (Directx_InitDirectDraw()!= 0){ //init DirectDraw
+ *param = 1;
+ SetEvent(h_creation);
+ return;
+ }

if(!vidmode)hWndFS = CreateWindow(WNDCLASSNAME_FULLSCREEN,"MPlayer Fullscreen",WS_POPUP,monitor_rect.left,monitor_rect.top,monitor_rect.right-monitor_rect.left,monitor_rect.bottom-monitor_rect.top,hWnd,NULL,hInstance,NULL);
mp_msg(MSGT_VO, MSGL_DBG3 ,"<vo_directx><INFO>initial mplayer windows created\n");

- if (Directx_CheckPrimaryPixelformat()!=0)return 1;
+ if (Directx_CheckPrimaryPixelformat()!=0){
+ *param = 1;
+ SetEvent(h_creation);
+ return;
+ }
if (!nooverlay && Directx_CheckOverlayPixelformats() == 0) //check for supported hardware
{
mp_msg(MSGT_VO, MSGL_V ,"<vo_directx><INFO>hardware supports overlay\n");
@@ -1115,10 +1125,26 @@
mp_msg(MSGT_VO, MSGL_V ,"<vo_directx><INFO>using backpuffer\n");
nooverlay = 1;
}
- mp_msg(MSGT_VO, MSGL_DBG3 ,"<vo_directx><INFO>preinit succesfully finished\n");
- return 0;
+ mp_msg(MSGT_VO, MSGL_DBG3 ,"<vo_directx><INFO>preinit succesfully finished\n");
+ SetEvent(h_creation);
+ while (GetMessage(&msg, NULL, 0, 0))
+ {
+ TranslateMessage(&msg);
+ DispatchMessage(&msg);
+ }
+ return;
}

+static int preinit(const char *arg)
+{
+ int ret_creation = 0;
+ dxarg = arg;
+ h_creation = CreateEvent(0,0,0,0);
+ CreateThread(0,0,dx_wnd_thread,&ret_creation,0,0);
+ WaitForSingleObject(h_creation,INFINITE);
+ return ret_creation;
+}
+
static int draw_slice(uint8_t *src[], int stride[], int w,int h,int x,int y )
{
uint8_t *s;

[WSC4]

In the config file, vo=gl is selected during the installation for Mplayer and MPUI. However, Directx is the default in SMPlayer. I decided to change it to OpenGL because videos display far better (my monitor / video card).

Using any of the deinterlacers to watch a video in MPlayer, MPUI or SMPlayer will not work and causes this in the logs:

Starting playback...
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
The selected video_out device is incompatible with this codec.
Try appending the scale filter to your filter list,
e.g. -vf spp,scale instead of -vf spp.

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

Anyone else have this problem?

[LoRd_MuldeR]

In the installer there is an option to make OpenGL the default renderer. DirectX (overlay) doesn't work well on Vista+, as it will disable Aero Glass.

Also YADIF works fine with the OpenGL renderer for me. However you may want to try "-vo gl:yuv=2" instead of "-vo gl" only.

[WSC4]

-vo gl:yuv=2 worked, but it showed videos in greyscale (with or without deinterlaces). I also tried all the numbers for yuv with no luck. The only thing that seems to work so far is what the error suggested; -vf-add scale. But is this normal?

I remember reading in other posts and MEncoder mailing lists that YADIF and MCDIENT are the deinterlaces to use; all others are depreciated. Do you agree?

[LoRd_MuldeR]

-vo gl:yuv=2 worked, but it showed videos in greyscale (with or without deinterlaces). I also tried all the numbers for yuv with no luck.

Sounds like your OpenGL driver is screwed up. What OS and graphics card do you use? And are your graphics drivers up-to-date?

I remember reading in other posts and MEncoder mailing lists that YADIF and MCDIENT are the deinterlaces to use; all others are depreciated. Do you agree?

I never got MCDeint to work properly here (did not try again for a longer time though). Anyway, YADIF does a pretty good job - for a fast CPU-only real-time deinterlacer.

(YadifMod+NNEDI3 or QTGMC give better results, but they are significant slower than YADIF. Probably too slow for real-time. However you may think about deinterlacing before playback)

[WSC4]

OS: Windows XP SP3
Graphics card: NVIDIA GeForce2 MX/MX 400. Ram: 64 MB (latest drivers installed)
CPU: Pentium 4 1.7 GHz
Memory: 1 GB

It is an old card and the latest (and probably the last) drivers are dated 2006. I did update the drivers "after" I in installed MPLayer For Windows. I was having problems with the old drivers then with OpenGL. I could re-install MPlayer For Windows over the new drivers if you think it would fix it?

Thanks anyway, but YadifMod + NNEDI3 or QTGMC need AviSynth. I haven't the time to learn a new program at the moment. I have enough on my hands learning to drive MEncoder.

[LoRd_MuldeR]

You might not be able to get the OpenGL renderer work with that old card/drivers.

I guess that card still uses AGP. Maybe you can get a cheap AGP card for little money that is less outdated... (unfortunately AGP cards have become rare these days)

Anyway, I found some drivers (apparently from 2008) for your GeForce2 MX 400 card:
http://www.siliconguide.com/drivers/device/370/

[WSC4]

Thanks for your hard work. I'll check those drivers out and let you know.

[Reimar]

Graphics card: NVIDIA GeForce2 MX/MX 400. Ram: 64 MB (latest drivers installed)


Register combiners were introduced already in the generation before (called GeForce 256), thus -vo gl:yuv=1 should work, though the oldest card it was tested on was a GeForce3 - it is possible the cut-down MX versions cannot do 3-times multitexturing (though that should result in some strange colours, not grey).
If it does not work you should check the output for errors.

[Reimar]

I am afraid for anything older than GeForce3 (well, for ATI actually cards from even earlier should work) the hardware can't do YUV->RGB in a reasonable way.
So you have to use plain -vo gl.
You need to add scale because the conversion has to be done in software then, _and_ it has to be done after yadif. MPlayer can't figure that out on its own currently, so you have to give it a hint manually.

[WSC4]

Thanks for the follow up, you just saved me typing many more questions. With "-vo gl:yuv=1", I get this (and I have the latest drivers):

VO: [gl] 720x576 => 768x576 Planar YV12
[gl] 3 texture units needed for YUV combiner support (found 2)

Time to get a new card, may even updated the whole machine. In the meantime, I'll use scale as you suggested.

[The Seeker]

Nowadays, with MPlayer for Windows using the Sherpya build, is there any need to add the -lavdopts threads=x parameter?

[LoRd_MuldeR]

Nowadays, with MPlayer for Windows using the Sherpya build, is there any need to add the -lavdopts threads=x parameter?

I think it is required to enable multi-threaded decoding, for those decoders in libavcodec that support it.

You can, of course, put a simple "lavdopts=threads=X" in your mplayer/config instead.

[The Seeker]

You can, of course, put a simple "lavdopts=threads=X" in your mplayer/config instead.

No need as 'lavdopts=threads=2' is already there. I may change it to 4 however as I'm using a Core i5.

[rogerdpack]

Would it be possible to request a "just smplayer" package? Currently I direct my users to download the "full" smplayer package, just so they can get an updated smplayer, but would love to be able to direct them to just an "updated smplayer" download, as it would be smaller et al.
Thanks!
-r