Media Player Classic (patched build) [Archive] - Page 7

clsid

8th March 2008, 17:13

Fresh build is available:
http://sourceforge.net/project/showfiles.php?group_id=205650&package_id=245753

Changelog:
##### 2008-03-08 (SVN revision 44) #####

* MPC: Added subtitle delay function for the internal subtitle renderer. It can be controlled with the F1 (decrease delay) and F2 (increase delay) buttons. The default delay interval is 500ms, but can be changed in the options. Patch by MatMaul.
* MPC: Automatically block DirectVobSub filter (VSFilter) when the internal subtitle renderer will be used.
* MPC: (SubResync) Save to .srt subtitle fix concerning italics
* MPC: YUV mixing option is now hidden on Vista (because it does not work on Vista).
* MPC: Added CSS classes in WebInterface.
* MPC: Fixed buffer overrun in VobSub code.
* MPC: Show proper error message when trying to use the "Save Image" function together with Overlay Mixer renderer.

wyrd

8th March 2008, 17:50

Fresh build is available:
http://sourceforge.net/project/showfiles.php?group_id=205650&package_id=245753
Thank you very much for fresh build and VSFilter.:)

chros

8th March 2008, 19:19

Thanks clsid for the subfixes !!!

fastplayer

8th March 2008, 20:49

Why is the default half a second here? Shouldn't it be 0ms?
Guess I'm missing something here... :o

Yong

8th March 2008, 20:54

actually yuv mixing mode work on vista, tried with my nv6150 and 2600xt,
but its only work if the video decoder are using packed yuv output colorspace, and force bob(not very sure about this) :confused:
eg ffdshow, and some mpeg2 decoder:p

clsid

8th March 2008, 22:09

Why is the default half a second here? Shouldn't it be 0ms?
Guess I'm missing something here... :o
It is not the default delay, it the default delay interval. So each time you press F1/F2 the current delay changes with half a second.

fastplayer

8th March 2008, 22:17

It is not the default delay, it the default delay interval. So each time you press F1/F2 the current delay changes with half a second.
I should read more carefully... :o
Anyway, :thanks: for the build!

fastplayer

9th March 2008, 00:35

fixed

9th March 2008, 00:57

How can I set "Position subtitles relative to the video frame" option enabled by default for all styles? Now I can enable it only for Default Style.
Some effects work incorrectly without this option.

clsid

9th March 2008, 15:46

I have Store settings to .ini file enabled and MPC still writes to the registry when I make changes to the filters by double-clicking them in the options. Why? I thought those filters are internal and can't be shared resp. accessed like their standalone counterparts, can they?The internal filter have always used the registry. They work and operate pretty much exactly the same as their standalone versions. The only difference is that they aren't registered to the system and thus are only used by MPC.
It is not a trivial fix to allow the filters to use the ini file. You could ask Casimir666 if he can take a look at it. If it results in a useful change, I don't mind backporting it into the regular MPC build.
How can I set "Position subtitles relative to the video frame" option enabled by default for all styles? Now I can enable it only for Default Style.
Some effects work incorrectly without this option.Use "Overrride placement". If that doesn't work, then you are out of luck.

fastplayer

9th March 2008, 19:15

It is not a trivial fix to allow the filters to use the ini file.
I thought this was a small oversight in the MPC code but since the "error" is "by design", I'm not sure if a "fix" is worth the effort.
I can live with my current solution: Export filter settings to .reg file and apply it right before running MPC from a flash stick. :)

twipley

2nd April 2008, 03:02

Here is a suggestion for a new build of Media Player Classic:

is there a reason the large-jump forward and backward keys are by default left unbinded? I'd kinda see them automatically mapped to the alt+left/right keys upon installation.

EDIT: like the idea?

wyrd

15th April 2008, 02:34

@clsid, Thanks for new build. :)
mplayerc_20080414(20080402) (http://sourceforge.net/project/showfiles.php?group_id=205650)

jdpal

7th May 2008, 22:16

Hi guys,
A minor detail and I know it sounds a little bit like "Can I get the icon in cornflower blue?", but if someone went all the way as to change the application's icon - and did quite a good job at it btw -, can't you change the ugly win98 Mute/unmute icon(s) to something that has more than 16 colors, e.g. the winXp Mute icon(s)?
Just a wild suggestion. ;)
Or in case needed I could probably do the job myself. But it's easier for me to bug you about it.

clsid

7th May 2008, 23:36

If someone would provide some nice icons of the correct size, then I don't think it would be much of a trouble to replace the existing resources.

These are the resources that are currently used:
http://guliverkli2.svn.sourceforge.net/viewvc/guliverkli2/src/apps/mplayerc/res/

leeperry

12th May 2008, 15:06

is there a way to assign the -/+ Zoom keys to the mouse wheel, like in KMPlayer ?

or at least the pan & scan presets ?

my logitech drivers are very versatile(I've put CTRL+J on one button, and ALT+F4 on another one....but they can't assign keystrokes to the mouse wheel :(

and assigning the windows "zoom" to the mousewheel doesn't change the zoom in MPC.

TIA,

crlorentzen

15th May 2008, 04:13

@clsid, would it be possible to commit the current MS Detours.h file to the mplayerc builds? I use a product called Cisco Security Agent as my HIPS (Host Intrusion Prevention System) and the developers indicate that the failure of it to run is because of the old detours it is compiled with. Latest version of detours (2.1) can be downloaded here: http://research.microsoft.com/sn/detours/.

I am trying to compile with the current detours.h myself but am unable to get past errors in the compile processes for openning steams.h which appears to be in the SVN checkout I downloaded
Error is
c:\svn\guliverkli2\src\apps\mplayerc\stdafx.h(62) : fatal error C1083: Cannot open include file: 'streams.h': No such file or directory

clsid

15th May 2008, 13:23

You need to install the DirectX SDK in order to compile. You also need to update detours.lib.

Linking MPC fails for me with detours 2.1

crlorentzen

15th May 2008, 22:48

You need to install the DirectX SDK in order to compile. You also need to update detours.lib.

Linking MPC fails for me with detours 2.1

Thanks for looking at this, let me give a try installing the DirectX SDK. Sorry if that is a stupid mistake but, I don't program daily and have never worked on a project larger than like 3 source files, so I don't know how to do most of this stuff.

Liisachan

13th June 2008, 03:54

Thank you for the revision 55.

I'm afraid the sub-sync problem (http://forum.doom9.org/showthread.php?p=1135601#post1135601) in VMR9 (renderless)+VMR9 mixer mode, when used with ffdshow's Queue output sample option, has not been fixed yet. Is it a hard problem, like, mysterious and difficult to spot? I don't want to nag you, but imho subtitles out of sync by about 0.5 seconds are not something one can accept, not just for a cosmetic reason, but for the very practical reason.

The last version without this bug seems to be mplayerc_20080127. Personally I can just disable the mixer mode option, so it's okay, but this problem is kind of disturbing because innocent users may use that combination of the options without knowing the problem...

Thank you again for your great job, not only MPC, but updating VSFilter etc. I really appreciate your efforts! Thank you!

clsid

13th June 2008, 11:52

If Casimir666 ever fixes this problem, then I will backport it. I have looked at the changes since 20080127 and couldn't find anything that may have cause the problem. So maybe the bug has been introduced by using a newer DirectX SDK. But I don't remember which version I have used in januari. Maybe someone is able to deduce that from the binary?

CiTay

19th June 2008, 11:57

Resizing - in 3D mode you MPC can use different filters when scaling the image. The most simple and fast is Nearest Neighbor but it gives the worst quality. Bilinear is quite quick and gives good quality, there is variant which uses pixel shaders. Bicubic method has the best quality, but for realtime image processing requires powerful enough video card. There are three variants of bicubic interpolation, the difference is sharpness level (0,6 - the most sharp one).[/i]

That's incorrect, -1.0 is the sharpest one, -0.6 is the softest one.

BTW, the artifact lines when using EVR Custom with Bilinear or Bicubic PS 2.0 resizer are fixed in the latest MPC HC. I'm only mentioning this because earlier posts of this thread come up in Google search when you're looking for info on EVR vs. EVR custom, so i thought i'd mention it for those people.

Concerning the different resizers, the Bicubic ones have the best quality for me. Sharper than normal EVR and EVR Custom Bilinear.

Liisachan

19th June 2008, 12:44

If Casimir666 ever fixes this problem, then I will backport it.

Just tested a thing called mplayerc.558.x86, and it has the same bad behavior, unfortunately.

I have looked at the changes since 20080127 and couldn't find anything that may have cause the problem. So maybe the bug has been introduced by using a newer DirectX SDK.

That's quite possible. MS is very good at breaking compatibility...

PS: I don't know how to check the SDK version from the binary. Both old MPC and the new one load d3d9.dll d3d8thk.dll d3dx9_24.dll, but maybe calling different functions in the DLLs.

clsid

19th June 2008, 13:55

It uses d3dx9_24.dll by default instead of newer ones because that is the last version that supports Pixelshader 1.x. So that is not the SDK version that was used.

Liisachan

20th June 2008, 01:13

If fixing is not easy, I'd suggest you tentatively add a text "Subtitles may be out of sync." to the tooltip help for the "VMR9 mixer mode" checkbox, to discourage people to use this mode with no real reason. I don't know myself what this mode is good for, but somehow I checked it on before.

Like I said first, even though the problem may be in DirectX itself, the bug might be triggered by ffdshow, not by MPC, because the problem only appears when "Queue output samples" is enabled in ffdshow, and if it is disabled the problem is gone. I fully agree with you anyway, that there were no changes in the source code at all which could cause such a radical b0rk like this.

Btw, MPC experienced a somewhat similar problem before, in 2005. [ 1280326 ] MPC's sub renderer is 1 frame too late (http://sourceforge.net/tracker/index.php?func=detail&aid=1280326&group_id=82303&atid=565649) The sample clip Hard_vs_Softsubs.mkv was created back then. Gabest explained "The problem is dshow does not return the exact stream
position of the currently rendered image. Turn on the
subresync toolbar and watch the time as you frame step this
video. It should say 0.000, 0.100, 0.200, ... but instead you
will see something much crazier happening there." and fixed the problem "by a nasty
but elegant hack :P"

thuan

27th July 2008, 07:30

Bug report: With 2008-07-26 (SVN revision 66) version, it does not remember subtitle Default Style settings.

betaking

27th July 2008, 07:36

Bug report: With 2008-07-26 (SVN revision 66) version, it does not remember subtitle Default Style settings.
Yes,DirectVobSub 2.39 also has this bug!

clsid

27th July 2008, 14:26

Things will only be fixed if someone submits a working patch for a problem. Nobody is actively developing MPC anymore. So if you want things to be fixed, head over to the MPC-HC topic and post your bugreports there. Simple fixes will get backported into the regular MPC.

fixed

27th July 2008, 18:50

Similar bug:
http://forum.doom9.org/showpost.php?p=1163567&postcount=3453

thuan

28th July 2008, 12:08

Looks like there's a fix now, can you compile the new revision clsid?

Liisachan

28th July 2008, 12:39

clsid: Thank you so much for your great work esp. on VSFilter!!! That vmr9 mixer problem aside, this is so exciting.

clsid

28th July 2008, 14:24

The changes are thanks to people from Aegisub and someone else who submitted a useful patch.

Fresh builds will be available shortly.

Liisachan

28th July 2008, 15:42

Yeah, I saw the author name. Some of the fixes are actually based on (or related to) my old reports in an old Aegisub thread here. They are really great people.

But I'm really thankful to YOU too for this guliverkli2 project. I think everyone else is too.

edit: Some of the problems->I meant "Some of the fixed problems", reworded

Sir Didymus

30th July 2008, 13:20

...But I'm really thankful to YOU too for this guliverkli2 project. I think everyone else is too.

Just want to second the kind works of Liisachan and state the maximum respect and admiration for your excellent work on MPC, clsid!

Reino

1st August 2008, 21:00

I thought only mono IMA4 was still a problem (http://forum.doom9.org/showthread.php?p=794824#post794824) (how long will it be still anyway?), but it now seems I have even found a MOV[H.264+IMA(stereo!)] (http://www.wingsofdarkness.net/videos/Tarot_Ashestothestars.mov) that won't work with the up to date MP4 Splitter.
The "QuickTime Movie Parser" (quartz.dll) has no problems with the stereo IMA soundtrack, but obviously can't handle H.264 video.

clsid

1st August 2008, 21:16

Post it in the MPC-HC topic. Nobody is doing any active development on the regular version of MPC.

Reino

2nd August 2008, 00:07

I thought MPC-HC was just another project...
Will it eventually replace MPC then?

clsid

2nd August 2008, 10:19

That is a choice that the user has to make. For me and many others, MPC still works good enough. I don't use the internal Matroska/MP4/Ogg splitters.

MPC-HC is this patched MPC plus some new features. New developments take place in MPC-HC project. I occasionally apply small patches, that were created by others, to both this project and MPC-HC. And useful fixes in MPC-HC that can easily be ported back to MPC are applied as well.

plugh

13th August 2008, 16:57

Been doing some experimenting with h264 playback on an old P4. Installed latest coreavc and mpc and tried playing an 8GB x264+ac3 2 hour movie. Audio is 640Kb/s and as I figure it, video works out to 8+Mb/s average bitrate.

When I turn on statistics, the bitrate is labeled Kb/s, but it seems the values are off by a factor of 8. For example, the bitrate value for the audio is shown as 80 Kb/s.

On the other hand, I tried an MPEG2 TS cap (using mpc internal filters) and values shown make sense as bits/sec. (For example AC3 audio is '384')

Comments? mpc buglet?

cyberbeing

26th August 2008, 20:40

Just a heads up. If anybody was having a major slowdown (huge 30-35% CPU usage spike) when using the \be command which was introduced for me in guliverkli2 VSFilter_20080726, jfs made a new build which possibly could fix it. It is built off guliverkli2 and has all the recent patches but it was compiled/optimized differently and somehow it was able to make the extremely slow (30-35% CPU increase) \be issue become non-existent (1-2% CPU increase) which is how it was in VSFilter_20080612 and prior.

You can download it here: www.animereactor.dk/aegisub/vsfilter-2.39c.rar

If you don't notice a slowdown with \be, it would probably be best to just stick with the sourceforge build.

clsid

26th August 2008, 20:59

Those changes have already been committed to Guliverkli2 repository by the Aegisub developer. So future releases will contain the fix.

And before people start whining about new builds: go make them yourself, or be patient...

cyberbeing

26th August 2008, 21:27

Those changes have already been committed to Guliverkli2 repository by the Aegisub developer. So future releases will contain the fix.

I think you misunderstood, no changes to the code or fixes were made in the above build and it should be identical to VSFilter_20080728 code wise. It was just by chance compiled slightly differently and for some reason it fixed my problem.

Even jfs has no idea why the one I linked (www.animereactor.dk/aegisub/vsfilter-2.39c.rar) works for me but eariler one he built previously http://www.animereactor.dk/aegisub/vsfilter-2.39b.rar does not considering they were using the same source, patches, and compiling method/settings but for some reason came out different (2.39c was 4KB smaller). It's like some odd compiler optimization fluke that was causing an issue on my machine with both your builds and jfs's recent VSFilter builds.

jfs wasn't having the issue and it seems most other people weren't as well since I was the only one who reported it. I'm just posting the build here in case there is someone else out there who was running into the same problem I was.

fastplayer

26th August 2008, 21:44

cyberbeing

26th August 2008, 21:50

There's no misunderstanding here. Fixes were made to the VS project files. Particularly one build parameter was added (WholeProgramOptimization).
See for yourself: http://guliverkli2.svn.sourceforge.net/viewvc/guliverkli2?view=rev&revision=77
The misunderstanding is both http://www.animereactor.dk/aegisub/vsfilter-2.39c.rar and http://www.animereactor.dk/aegisub/vsfilter-2.39b.rar used the same source patches and WholeProgramOptimization.

According to jfs, between 2.39b and 2.39c the source was identical, patches were identical, the compiling method and settings were identical yet they came out differently for some reason.

2.39b had a massive slowdown with \be.
2.39c worked perfectly.

In other words it's possible when CLSID makes a new VSFilter build I still could have an issue if it turns out like 2.39b instead of 2.39c if there is really some inconsistency in compiling like jfs ran into.