MPlayer for Windows (2019-10-15)

[RunningSkittle]

Think we can get some sort of sharpening added to the filters?

[LoRd_MuldeR]

Think we can get some sort of sharpening added to the filters?

Try "-vo gl:yuv=2:lscale=4" or "-vo gl:yuv=2:lscale=5" ;)

[LoRd_MuldeR]

MPlayer for Windows 2009-07-24 :)

[2009-07-24]
* SMPlayer updated to Version 0.6.8 (SVN-r3213)
* NSIS updated to Version 2.45
* Now using the UAC Plugin for NSIS
* UMUI updated to 2009-06-14
* QT Runtime Libs updated to Version 4.5.2

[LoRd_MuldeR]

For what would you need that? To quickly go back to the page where you left it would be handy, but since the last read page is remembered, you even get faster to where you were before.

Also you can click on the page down in the list of pages. If you read a document with hundreds of pages, this will not get you there right away, but usually it only takes you a couple of clicks....

I cannot imagine right now, where you would need it for really.

I really have no idea what you are talking about :confused:

Wrong thread?

[roozhou]

Hi Lord_mulder, why don't you use kovensky's latest mplayer build?

[LoRd_MuldeR]

Hi Lord_mulder, why don't you use kovensky's latest mplayer build?

...because it's not as "stable" as the Sherpya builds. I encountered some problems that weren't present in the Sherpya builds.

If you really need ffmpeg-MT, you can replace the MPlayer.exe at any time. The only "real" advantage is the multi-threaded H.264 decoding.

Anyway, most 1080p H.264 streams play just fine with the "normal" build on my system, which certainly isn't the fastest one ;)

[roozhou]

...because it's not as "stable" as the Sherpya builds. If you really need ffmpeg-MT, you can replace the MPlayer.exe at any time ;)

The only thing I need in ffmpeg-mt is frame-level multithreading of H264 decoder. It is as stable as in ffdshow. Multithreaded MPEG1/2 decoders are unstable but we can set libmpeg2 as default.

And latest kovensky build also introduced an improved version of libass, which fixes a lot of bugs and supports drawing commands in ass subtitles.

[LoRd_MuldeR]

The only thing I need in ffmpeg-mt is frame-level multithreading of H264 decoder. It is as stable as in ffdshow. Multithreaded MPEG1/2 decoders are unstable but we can set libmpeg2 as default.

Unfortunately I encountered other (none H.264 related) problems with Kovensky's build, so I'm just not going to include it yet.

Advanced users can always put Kovensky's multi-threaded MPlayer.exe (e.g. as "MPlayer-MT.exe") into the MPlayer for Windows directory.

Then they can switch between the "normal" and the ffmpeg-MT build easily via SMPlayer preferences :)

[Leak]

I really have no idea what you are talking about :confused:

Wrong thread?
Wrong forum for SPAM, anyway - take a look at it's signature and the link therein...

np: Death Cab For Cutie - Company Calls (We Have The Facts And We're Voting Yes)

[avih]

Hi, I'd appreciate some (yet more) help regarding mplayer/win32 (latest mulder's MPUI.2009-07-24.Full-Package.exe).

I'd appreciate some help in finding a configuration which will:
- Display subtitles in screen resolution and not in video resolution (is there a name for this behavior?), with ASS/SSA enabled.
- Without tearing (at full screen)
- "Normal" CPU usage (seems to be mostly affected by output type and options, decoding itself uses low CPU)
- I prefer not to use directshow (preferred: gl/2/direct3d/others)

On my previous mplayer installation I had it configured properly, but for some reason, sometime during the installation of the recent package, my config was lost (although I didn't uninstall previous package as muler's suggested, and also unchecked "reset mplayer's settings" when installing the new one, whatever..). I do remember it was OpenGL based.

Anyway, my system is relatively modern now: E8400/4G(3.3 effective)/GTX260+/XP32(SP3)/Latest NVidia drivers (191.03 beta at default settings), so theoretically it shouldn't have CPU issues, but it does. Not sure if related, but I have 2 monitors connected: 24" DVI LCD (1920x1200) and 42" VGA Plasma (1280x720), arranged at a DualView config, both set to 60Hz refresh rate, both seem to behave the same when used for the test clip display.

My main test clip is a native NTSC live captured sports video, deinterlaced before encoded (to double frame rate =~ 60FPS). mplayer info: 720 x 400, aspect 1.8, H264, 1612 kbps, 59.940 (FPS), ffh264, mp3 audio, subtitles (unrelated to the video but nevertheless loaded for the tests).

Here are my findings thus far regarding output types:

DirectX(Fast):
- OK: no tearing, virtually no jitter
- BAD: ~50% CPU (2 cores used equally), no native res subs

DirectX(Slow):
- OK: CPU (18-25%) - yes, it should be "slow".. still
- BAD: Tearing, no native res subs, pixelated output (as in nearest-neighbor resize)

Direct3D:
- OK: CPU (18-25%), no tearing, virtually no jitter
- BAD: no native res subs

GL2/fast:
- OK: no tearing, virtually no jitter
- BAD: CPU (~90%), no native res subs

GL("1") (all modes: fast/slow/gl:yuv=2, etc):
- OK: CPU (18-25%), native res subs
- BAD: tearing


So it seems only GL (not 2) supports subtitles at native screen resolution (otherwise, Direct3D output is perfect), so I kept playing with GL options:

- Only double buffering checked: All OK except CPU at 100% (*), very smooth playback, virtually no jitter
- Double buffering + direct render: All OK except CPU (90%)
- Any combination without double buffering: ALL OK except tearing

So it seems double buffering is my ticket to smooth playback (and apparently Direct3D, DirectX(fast) and GL2 also use double buffering (or vSync on?) even when not checked as config), yet it seem to consume 100% CPU on GL, and it doesn't use native resolution for subs in all other output types.

(*) GL modes + double buffering have strange CPU usage pattern which I haven't figured out yet. Mostly it's at 100%, but once I saw the CPU usage "crawl" in quite a linear fashion from about 30% to 100% in about 15 seconds of playing my test clip. Other times (at least twice) I saw it settle to low CPU usage (18-25%) , But after I stopped and played the clip again it was on 100%. When pausing the video for various durations (few seconds to few minutes) and then continue playback, the CPU mostly gets directly to 100%, sometimes directly crawls up to 100%, sometimes stays low, and sometimes stays low and then jumps/crawls to 100%. I'm really lost here.

Help? :)

[LoRd_MuldeR]

I highly recommend using MPlayer's GL renderer, not the GL2 one. And you should use the YUV mode ("-vo gl:yuv=2"), so the YUV -> RGB conversion is done by the GPU too ;)

The GL2 renderer is an experimental renderer that supports video resolutions higher than the maximum supported texture size. But it isn't developed any more and now misses many of the advanced features of the "normal" GL renderer. And yes, if you disable "Double Buffering" then tearing is expected. That's exactly what the "(Disable) Double Buffering" option is good for ^^

From the MPlayer documents:
−nodouble
Disables double buffering, mostly for debugging purposes. Double buffering fixes flicker by storing two frames in memory, and displaying one while decoding another.

BTW: The ATI developers did a good job in breaking the GL renderer with each new Catalyst driver update. Since I switched to NVidia, the GL renderer works perfectly fine for me :)

Needless to say that you should keep your video drivers up-to-date anyway...

[avih]

I highly recommend using MPlayer's GL renderer, not the GL2 one. And you should use the YUV mode ("-vo gl:yuv=2"), so the YUV -> RGB conversion is done by the GPU too ;)

The GL2 renderer is an experimental renderer that supports video resolutions higher than the maximum supported texture size. But it isn't developed any more and now misses many of the advanced features of the "normal" GL renderer. And yes, if you disable "Double Buffering" then tearing is expected. That's exactly what the (disable) Double Buffering option is good for ^^

From the MPlayer documents:


BTW: The ATI developers did a good job in breaking the GL renderer with each new Catalyst driver update. Since I switched to NVidia, the GL renderer works perfectly fine for me :)

Needless to say that you should keep your video drivers up-to-date...
Is there a suggestion here that I've missed (or that I haven't related to on my previous post)? or an explanation for the CPU usage in GL with double buffering on? Or other solution for no-tearing + subs at native resolution + normal CPU usage?

Basically, to me it looks as if GL + no-tearing (via double buffering at least) is broken. IMHO it shouldn't use 100% CPU, and IIRC it didn't, but unfortunately I'm unable to revert to my previous settings...

[LoRd_MuldeR]

Is there a suggestion here that I've missed (or that I haven't related to on my previous post)? or an explanation for the CPU usage in GL with double buffering on? Or other solution for no-tearing + subs at native resolution + normal CPU usage?

Basically, to me it looks as if GL + no-tearing (via double buffering at least) is broken. IMHO it shouldn't use 100% CPU, and IIRC it didn't, but unfortunately I'm unable to revert to my previous settings...

The suggestion is to use the recommended video renderer "-vo gl:yuv=2" instead of one of the experimental/slow renderers and to not enforce tearing by disabling the double buffering.

Furthermore, as said before, the GL renderer works perfectly fine for me. That is with NVidia hardware, Windows 7 and the latest video drivers. It used to work fine for me under Windows XP too.

http://img402.imageshack.us/img402/143/mplayerglasscpu.th.png (http://img402.imageshack.us/img402/143/mplayerglasscpu.png)

So if you think there are any bugs with the OpenGL render in MPlayer, you should talk to the MPlayer developers by using the MPlayer mailing list or by PM'ing Reimar (http://forum.doom9.org/member.php?u=79288) directly.

But don't expect too much support for the Windows port of MPlayer :D

[avih]

The suggestion is to use the recommended video renderer "-vo gl:yuv=2" instead of one of the experimental/slow renderers and to not enforce tearing by disabling the double buffering.

Furthermore, as said before, the GL renderer works perfectly fine for me. That is with NVidia hardware, Windows 7 and the latest video drivers. It used to work fine for me under Windows XP too.

So if you think there are any bugs with the OpenGL render in MPlayer, you should talk to the MPlayer developers using the MPlayer mailing list.

But don't expect too much support for the Windows port of MPlayer :D
Apparently, I fail to understand your help.

- I did note I've also tried gl:yuv=2 (so I fail to understand why you mentioned it, twice)
- I did note I have the latest drivers.
- I did note I want to eliminate tearing (so I don't understand why you suggest to disable double buffering if no other option to prevent tearing is offered)

Again, did anyone notice high CPU usage with double-buffering using GL (normal/fast/gl:yuv=2/etc)? Would anyone be able to guess why do I see these CPU usage patterns? Is it more probable to be an mplayer bug? or a GFX driver bug?

Is there another method to prevent tearing using GL (other than double-buffering)?

Can non-GL output types display subtitles at native screen resolution?

Mulder, sorry if you did answer one of my questions but I've failed to see it. If you did, I'd appreciate if you could rephrase it. I guess I'm thicker than usual today.

[LoRd_MuldeR]

Apparently, I fail to understand your help.

- I did note I've also tried gl:yuv=2 (so I fail to understand why you mentioned it, twice)

I mentioned it to make clear what the recommended renderer for MPlayer on Win32 is :)

In your first post you also mentioned a lot of renderers that are known to be either slow or experimental/outdated.

- I did note I want to eliminate tearing (so I don't understand why you suggest to disable double buffering if no other option to prevent tearing is offered)
Is there another method to prevent tearing using GL (other than double-buffering)?

I certainly did NOT suggested to disable double buffering! There is NO option to enable double buffering, because double buffering is already enabled by default. That's for a good reason, as it avoids tearing. So there only is an option to disable double buffering ("-nodouble") and I told you to NOT use that option, because by doing so you would explicitly tell MPlayer that tearing/flickering is desired.

Last but not least, if you have to report a bug in MPlayer itself, my suggestion is to do this at the appropriate place, the MPlayer mailing list. I doubt the MPlayer developers follow this thread ;)

[avih]

I mentioned it to make clear what the recommended renderer for MPlayer on Win32 is ;)

In your first post you also mentioned a lot of renderers that are known to be either slow or experimental/outdated.
...
I see. I did start with gl:yuv=2, but then tried all other options to cover the possibilities.


...
I certainly did NOT suggested to disable double buffering! There is NO option to enable double buffering, because double buffering is already enabled by default. That's for a good reason, as it avoids tearing. So there only is an option to disable double buffering ("-nodouble") and I told you to NOT use that option, because by doing so you would explicitly tell MPlayer that tearing/flickering is desired.
...


My apologies, I must have misread your post. SMplayer offers a "double buffering" checkbox so I thought it's off by default (at mplayer.exe). I just watched the arguments sent by SMPlayer, and when checked, it sends the argument "-double" (redundant?). When unchecked, it sends "-nodouble" instead.

The issue remains though, when there's no tearing and using GL based output, the CPU usage is strangely high.

Worth noting, I've also tried to invoke mplayer.exe manually from the command line (from C:\Program Files\MPlayer for Windows\). With the only argument other than the clip's file : -vo gl or -vo gl:yuv=2. On both cases I had 100% CPU usage and mplayer sent a notice to the terminal "**** Your system is too SLOW to play this! ****...".

Interestingly, although I thought I've linked the CPU issue to GL output with double-buffering enabled, I also read the notice which suggests using different audio output. And so I did (always with -vo gl:yuv=2), with the following results:

-ao dsound (or -ao win32) --> sounds ok, no tearing, 100% CPU

-ao null --> no sound, no tearing, 100% CPU (expected if 100% CPU is unrelated to audio)

but the most interesting and strange result:

-ao sdl (or any other -ao <uncompiled-mode-or-just-junk name>) --> no sound (obviously), no tearing, 18-25% CPU (!!!). Which obviously suggests that it CAN do GL with double buffering at normal CPU usage, and I also think it's very improbable that the standard mp3 audio causes any issues, especially when there are several modes at which it plays fine with low CPU, albeit with tearing.

So I really am lost now.

Also worth noting, that the 100% CPU issue with GL and double-buffering enabled only happens with my test clip (60 FPS, 720x400 H264, 1600kbps). With any other, more "standard" frame rate clips, it only uses 5-10% CPU, even with GL and double-buffering enabled.


...
Last but not least, if you have to report a bug in MPlayer itself, my suggestion is to do this at the appropriate place, the MPlayer mailing list...
But of course. Still, I first wanted to post my experience and see if I miss something, or if anyone knows a better config option, or if anyone else encountered such issues.

[LoRd_MuldeR]

My apologies, I must have misread your post. SMplayer offers a "double buffering" checkbox so I thought it's off by default (at mplayer.exe). I just watched the arguments sent by SMPlayer, and when checked, it sends the argument "-double" (redundant?). When unchecked, it sends "-nodouble" instead.

No idea. I was looking at the mplayer docs (http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.html#VIDEO OUTPUT OPTIONS (MPLAYER ONLY)) and I only found the "-nodouble" option there. Can't say for sure whether "-double" is always redundant.

Also worth noting, that the 100% CPU issue with GL and double-buffering enabled only happens with my test clip (60 FPS, 720x400 H264, 1600kbps). With any other, more "standard" frame rate clips, it only uses 5-10% CPU, even with GL and double-buffering enabled.

Are you sure your system is fast enough to play 60 fps H.264 video with pure software decoding?

Remember that MPlayer still uses the single-threaded ffmpeg decoders, unless you use on of the experimental MPlayer-MT builds, and doesn't use DVXA either...

Interestingly, although I thought I've linked the CPU issue to GL output with double-buffering enabled, I also read the notice which suggests using different audio output. And so I did (always with -vo gl:yuv=2), with the following results:

-ao dsound (or -ao win32) --> sounds ok, no tearing, 100% CPU

-ao null --> no sound, no tearing, 100% CPU (expected if 100% CPU is unrelated to audio)

but the most interesting and strange result:

-ao sdl (or any other -ao <uncompiled-mode-or-just-junk name>) --> no sound (obviously), no tearing, 18-25% CPU (!!!). Which obviously suggests that it CAN do GL with double buffering at normal CPU usage, and I also think it's very improbable that the standard mp3 audio causes any issues, especially when there are several modes at which it plays fine with low CPU, albeit with tearing.

So I really am lost now.

Does something like "−autosync 30" and/or "−framedrop" help ???

You can also try with the "−nosound" option to disabled the audio output. But it all sounds like a mplayer issue to me :rolleyes:

[avih]

...
Are you sure your system is fast enough to play 60 fps H.264 video with pure software decoding?

Remember that MPlayer still uses the single-threaded ffmpeg decoders, unless you use on of the experimental MPlayer-MT builds, and doesn't use DVXA either...
...

My build is the from your latest full package (2009-06-12), SVN 29355. I'm pretty sure it's able to decode this clip software only, both because it's a relatively modern system (Dual core E8400, 4G ram, GTX260+) and the clip is not THAT high-end, but also because on many other modes, GL output included, it uses ~25% CPU for this clip (when double buffering disabled), and with other outputs such as directx(fast) and direct3d (which offer double buffering but subtitles don't appear at native resolution).


...
Does something like "−autosync 30" and/or "−framedrop" help ???

You can also try with the "−nosound" option to disabled the audio output.
...

-nosound strangely "helps". Result is identical to -ao junksomething, i.e. no tearing, no sound, 25% CPU (reminder: -ao null disables sound but causes 100% CPU)

−autosync 30 or −framedrop don't help (sound is ok, no tearing, 100% CPU)


...
But it all sounds like a mplayer issue to me :rolleyes:
Unfortunately, by now, so it does to me.

Summary of this issue so far:

- 100% CPU (or strangely high and "random" CPU usage pattern) under the following conditions:

1. Only with my test clip (720x400, H264, 60 FPS, 1600 kbps, mp3 128 kbps audio)

1.1. Any other clip that I've tried with normal FPS (24-30) consumes normal CPU (~5%) under the same conditions.

2. Only when any GL output mode is selected (GL/GL(fast)/gl:yuv=2) AND double buffering is enabled (either explicitly with -double or implicitly without related directives)

2.1. If double buffering is disabled, CPU usage is normal (~20% CPU) and other than the expected tearing, the file plays fine.

2.2. Outputs other than GL (i.e. directx, direct3d) have ~25% CPU usage and no tearing (but they're not good enough to me since AFAIK, they don't allow subtitles at native screen resolution). GL2 uses 90+% CPU.

3. Only when using compiled audio support (i.e. -ao dsound or -ao win32 or or without any audio output directives results in 100% CPU)

3.1 -ao null starts with 100% CPU but after few seconds gets back to normal CPU.

3.2. If using -nosound or -au junk, it plays fine, no tearing, with 20% CPU (other than the obvious no sound "issue"). It also doesn't exhibit the 100% CPU for few secs as with -ao null.

Which, as much as I can tell, only appears on GL outputs AND double buffering enabled AND with sound AND the specific test clip. Drop any one of those and the CPU gets back to normal. Strange indeed as I just fail to see the connection between those elements (and especially the sound)...

BTW, preliminary tests using several older mplayer builds indicate it behaves the same.

Question: Does mplayer use some settings stored at different directories than the current one? (i.e. %APPDATA% system variable or similar ones?) maybe it affects older builds that I've tried?

Also important, I've recently updated the GFX driver to 190.03 (beta) NVidia driver. It could be related, but the symptoms (especially 3 and 3.1) suggests not necessarily.

[Reimar]

Also worth noting, that the 100% CPU issue with GL and double-buffering enabled only happens with my test clip (60 FPS, 720x400 H264, 1600kbps). With any other, more "standard" frame rate clips, it only uses 5-10% CPU, even with GL and double-buffering enabled.


Uh, to play 60 fps material your screen refresh rate must be at least 60 Hz. Since PC and screen usually don't agree how fast time goes, in practice that means the refresh rate must be > 60 Hz.
-framedrop should help in theory (no idea why it doesn't, try adding glfinish to the -vo gl options), but might look quite ugly.
You could use -vf framestep=2 to drop every second frame, or -vo gl:yuv=2:swapinterval=0 to disable vsync (you can try to force vsync and enable triple-buffering in the NVidia control panel, maybe that makes things work a bit differently, but I doubt it).
EDIT: and if by "CPU usage" you really mean actual CPU usage and not just what MPlayer shows, that is entirely NVidia's fault for using up all CPU while waiting for vsync.

[LoRd_MuldeR]

MPlayer for Windows 2009-10-12 :)

[2009-10-12]
* SMPlayer updated to Version 0.6.8 (SVN-r3286)
* QT Runtime Libs updated to Version 4.5.3

[Antonski]

Hello,

I have problems playing Musepack SV8 files (tagged), the player goes to endless loop at the EOF.
I've opened a ticket 1458 (http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1458) about mplayer, but their statement that the problem is related to ffmpeg and should be solved. However, the mplayer version you've compiled is r29355 while "the current revision is r29773 which means there were over 400 changes in MPlayer alone and probably a whole lot more in FFmpeg".
Would you make a new release with the latest svn please?

[LoRd_MuldeR]

Hello,

I have problems playing Musepack SV8 files (tagged), the player goes to endless loop at the EOF.
I've opened a ticket 1458 (http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1458) about mplayer, but their statement that the problem is related to ffmpeg and should be solved. However, the mplayer version you've compiled is r29355 while "the current revision is r29773 which means there were over 400 changes in MPlayer alone and probably a whole lot more in FFmpeg".
Would you make a new release with the latest svn please?

The latest MPlayer binary from Gianluigi Tiesi's site is still 2009-06-12 and he says that he can't make newer builds, because current GCC is "almost unusable" :(

I also tried the latest build from Kovensky's site, but it's completely broken for me. SMPlayer's site doesn't have newer MPlayer builds either. So we will have to be patient, I guess...

[Antonski]

I see, thanks for the info.
Cheers

[fxtech]

The build from kovensky work fine with the last svn smplayer , but is broken on ac3 playback :-(

[LoRd_MuldeR]

The build from kovensky work fine with the last svn smplayer , but is broken on ac3 playback :-(

Nope. On my system it crashes with every single file I tested. So it's unusable for me :(

[Kurtnoise]

Try this build (http://www.mediafire.com/file/yuwoifhmzwj/mplayer_r29777.7z)...

[LoRd_MuldeR]

Try this build (http://www.mediafire.com/file/yuwoifhmzwj/mplayer_r29777.7z)...

MPEG-2 playback is broken with that build. There's no useful error message on the log, it simply exits after playing sound for ~1 sec :(
http://pastie.org/659383

H.264, HuffYUV and FFV1 playback seems to work okay though. Why it's MPEG-2 always making trouble? :rolleyes:

[Antonski]

Try this build (http://www.mediafire.com/file/yuwoifhmzwj/mplayer_r29777.7z)...

BTW, this build plays (almost) fine Musepack SV8 files. Just the current playtime is broken,

[roozhou]

@Lord MuldeR,
How do you fix tearing problem on NV cards? I turned on triple buffering and VSync in NV control panel, but tearing is still there. Sometimes when I switch to VGA output and switch back to LCD panel, the tearing is gone(not always work). My laptop has 6150 Go. I have two desktop computers using 6600LE and 8500GT with latest driver installed. All of them have annoying tearing issue when using -vo gl.

My mplayer setting is
double=1
dr=1
vo=gl:yuv=2:lscale=1
slices=0

[LoRd_MuldeR]

I don't have any tearing problem with the GL renderer (-vo gl) on my system using a NV GFX260 card, as long as Doube Buffering is enabled.

Maybe Reimar has an idea?

[Mangix]

could try using d3doverride. but that probably only works on d3d applications.

[ajkessel]

I haven't been able to get ivtc to work with Mplayer for Windows -- it just crashes out. Is it supposed to be supported? Just wondering if I should work on troubleshooting or if it's hopeless. I haven't found any player for Windows that does ivtc -- it appears that vlc does not support it.

[roozhou]

ivtc works perfectly on windows for me. A simple "-vf ivtc=1" or "-vf pullup" is OK.

Post your command line.

[candela]

DVD playback from an actual disc with Mplayer is not working for me. I have noticed the following strange behaviour

MPlayer Sherpya-SVN-r28311-4.2.5: mplayer -dvd-device F: dvd://3 -> playback stutters, simply unwatchable
MPlayer Sherpya-SVN-r28311-4.2.5: mplayer -dvd-device F:\ dvd://3 -> playback is fine, changing F: to F:\ makes mplayer report "libdvdread: Couldn't find device name." yet DVD playback is fixed (wth?)

I found this out by looking at the mplayer log from MPUI and SMPlayer. MPUI sends F:\ and SMPlayer sends F:. In MPUI playback was fine, in SMPlayer it stutters.

However, now on the the new build MPlayer Sherpya-SVN-r29851-4.2.5 this "trick" doesn't work anymore. libdvdread always detects the device when I use f:\ and the playback is then always incredibly slow.

Anyone have any idea what is going on here or how to fix this?

I posted some logs on the SMPlayer forum (http://smplayer.berlios.de/forums/viewtopic.php?pid=6856#p6856)

[Reimar]

I found this out by looking at the mplayer log from MPUI and SMPlayer. MPUI sends F:\ and SMPlayer sends F:. In MPUI playback was fine, in SMPlayer it stutters.


I think you probably missed the more relevant messages, like
libdvdread: Error cracking CSS key for /VIDEO_TS/VIDEO_TS.VOB (0x0000013a)
or
libdvdnav:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VTS_04_0.IFO failed

Which makes it look like this is one of those broken-on-purpose DVDs.
The simplest way to fix it is most likely to rip the DVD with one of the tools for that (oh the irony... Sorry, just couldn't resist saying that).

[candela]

I think you probably missed the more relevant messages, like
libdvdread: Error cracking CSS key for /VIDEO_TS/VIDEO_TS.VOB (0x0000013a)
or
libdvdnav:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VTS_04_0.IFO failed

Which makes it look like this is one of those broken-on-purpose DVDs.
The simplest way to fix it is most likely to rip the DVD with one of the tools for that (oh the irony... Sorry, just couldn't resist saying that).

Well that doesn't really explain why the same thing happens on all my DVDs, even ones that do not have even CSS. And I don't think this DVD from my logs has any special protection (Frogs PAL R2 MGM/Sony released in 2005)

[LoRd_MuldeR]

MPlayer for Windows 2009-11-11 :)

[2009-11-11]
* MPlayer binaries updated to SVN-r29851
* SMPlayer updated to Version 0.6.8 (SVN-r3306)
* File permission workaround for UAC

[burro08]

hi guys

whats with the new time display in the top left of the screen in smplayer? and how do u disable it?

thanks

[LoRd_MuldeR]

You mean the OSD (On Screen Display) or what? Goto "Options" -> "OSD" and selected "Subtitles only" ;)

[Voltekka]

The latest version doesn't work on my pc. It won't play anything:confused: The earlier versions work but the latest doesn't:mad:

[LoRd_MuldeR]

The latest version doesn't work on my pc. It won't play anything:confused: The earlier versions work but the latest doesn't:mad:

"It doesn't work" isn't a useful error description. Give me some useful information, an I may be able to do something :rolleyes:

Why not start by posting your log file ???

[Voltekka]

I don't know where the log file is:( Well when i try to play something in SMPlayer it just freezes and if i try to shut it down it crashes but MPUI is working fine.

[LoRd_MuldeR]

I don't know where the log file is:( Well when i try to play something in SMPlayer it just freezes and if i try to shut it down it crashes but MPUI is working fine.

If MPUI is working fine, but SMPlayer isn't, then this clearly indicates a problem with SMPlayer.

In that case you should contact the SMPlayer author or use SMPlayer's bug tracker. I can't help you with SMPlayer-specific problems at all.

BTW: You find the log at "Options" -> "View logs" in SMPlayer ;)

[carnage_pl]

Same here. When You released 11.11.2009 version everything worked fine. Now i tried to play something (today) smplayer just don't want do load file. Weird...

[LoRd_MuldeR]

Same here. When You released 11.11.2009 version everything worked fine. Now i tried to play something (today) smplayer just don't want do load file. Weird...

You did wait for MPlayer to finish updating its font cache at the very first launch, did you ???

(This may take quite a few moments, but only needs to be done once)

[carnage_pl]

Very first launch yes. Ok it works now. He updated cache font again but i dont for what reason. I didnt change anything and wasnt any info.

[LoRd_MuldeR]

MPlayer for Windows 2009-12-06

[2009-12-06]
* SMPlayer updated to Version 0.6.8 (SVN-r3336)
* NSIS updated to Version 2.46
* QT Runtime Libs updated to Version 4.6.0
* UMUI updated to 2009-12-06

http://fc04.deviantart.net/fs23/f/2007/346/1/5/Santa_hat_Emoticon_by_CheddarMan.png

[Jong]

I've just been trying this for the first time, mainly because I need to set the User Agent to Quicktime when playing Apple Trailers. With MPC-HC you have to change the default user agent in the registry which on W7 is not possible without a UAC prompt.

I complete failed to get the command line options for user agent to work. I could not set it on the smplayer command line or using the mplayer command line settings configurable inside of smplayer. It would accept the command (no error), but it clearly was not setting the user agent. It was then trying to parse the user agent string as a queue entry (visible in the log). I ended up having to edit the mplayer configuration (ini? not on that PC at the moment) file. That worked fine, but its obviously a global setting. It would be better to do it just when needed. Any ideas what is going wrong?

[LoRd_MuldeR]

Why not download the trailer first with a tool like wget?

[Jong]

Because... why?

I have a plugin for my HTPC front-end that every night gets the URL's of new trailers and displays them with artwork. I can simply press play on any trailer and it streams @720p. There is really no need/point in downloading them. Either it would add delay to playback or I have to download them all just in case I want to watch one of them :eek:

Anyway the point is what brought me to mplayer is specifically its ability to define the user agent without escalated privileges ..... and it works! Just it seems the command line capability is broken (or I'm doing it wrong!). I can live with the .ini configuration I am using right now, but there might be another site in the future that insists I NOT use Quicktime! So getting the command line functionality working as it is meant to would be good.