New release of Media Player 6.4

[LightningFire]

Today I experienced a strange effect in Media Player Classic 6.4.8.4 in Windows Server 2003 (hardware acceleration to max), with directx8 installed.
When playing a AVS file, containing a resize (bilinearresize, lanczos4resize and bicubicresize tested) to a vertical resolution of 384 (it does not occur when resizing to 382), and setting the video frame to double size heavy ringing shows. Edges all have a purple (to the left) or green (to the right) halo around them. In the saved image, this effect does not show,only when viewing. It occurs with overlay renderer, and with vmr7 (windowed), resizing set to bilinear. Source is 720 by 576 dvd, with dgindex to create the d2v.

It is not a problem for further processing, but I would be very intrested to know of a cause or a solution, or maybe something I overlooked about color sampling.

Greetings.

[LigH]

Try to avoid YV12 Overlay, some graphic cards (like my GeForce2 GTS) don't work well with this mode, I need YUY2 output for example.

[LightningFire]

I did a convert to YUY2 at the end of my avs and I also disabled YUV planar media types in the MPEG decoder of MPC but that didn't seem
to do the trick, the halos still show.
Thanks for the tip nevertheless.

[LigH]

Hm ... sorry, just read half of your post, I'm afraid.

You wrote it appears with several output modes. So it indeed must be related to something inside MPC.

[kallekill]

I've been trying to get rid of the pixels that is visable especially on bright red areas because of bad colour conversion. I am using a xvid file and the only option that works is forcing the xvid codec to output YV12 instead of YUY2. I have heard that by doing this the video card is doing the color upsamling instead of the codec. The only problem is that in media player classic the renderer is always set to "video renderer" when I do this. Even though I have chosen VMR9. It seems to work fine in other players. Is this a bug?

[Liisachan]

This is CPU-intensive, but the output is converted to RGB anyway using ffdshow like this:

in mpc, hit [O] go to Playback|Output select VMR9 (renderless) for DirectShow Video.

in ffdshow, open the Video decoder configuration box, and go to output, uncheck everything but RGB32.

make sure you have the newest dx9 and ffdshow installed.
if the above doesn't work, probably i can't help you.
as another note, the above settings would be too cpu-intensive for some of new codecs that are already quite cpu-intensive.

[kallekill]

This is CPU-intensive, but the output is converted to RGB anyway using ffdshow like this:

in mpc, hit [O] go to Playback|Output select VMR9 (renderless) for DirectShow Video.

in ffdshow, open the Video decoder configuration box, and go to output, uncheck everything but RGB32.

make sure you have the newest dx9 and ffdshow installed.
if the above doesn't work, probably i can't help you.
as another note, the above settings would be too cpu-intensive for some of new codecs that are already quite cpu-intensive.

It does work, but the ultimate thing would be if the YV12 output worked with the VMR9 renderer. It does in zoom player and it works in media player 6.4 with the VMR7 renderer. That way the graphic card does the RGB conversion which doesn't take any or much CPU and it looks really good. At least on my Geforce 6600GT. The default setting in ffdshow and Xvid codec seem to be YUY2 output. Why would anyone want that? That means that the picture has to be converted from YV12 to YUY2 to RGB.

[Liisachan]

It does work, but the ultimate thing would be if the YV12 output worked with the VMR9 renderer.
No, as already discussed in this thread, Gabest thinks "yv12 -> rgb conversion looks horribly bright compared to the result of yuy2 -> rgb" and it seems that MPC refuses to use YV12 in the negotiation.
http://forum.doom9.org/showthread.php?p=635430#post635430

Technically this is by design, not a bug but what Gabest did on purpose.

The default setting in ffdshow and Xvid codec seem to be YUY2 output.
As you mentioned ZP naively works with YV12.
Personally I agree with you in the sense MPC should accept YV12, since today's filters/hw should be able to handle YV12 decently, and if you don't like YV12, you can disable manually YV12 in ffdshow.

Why would anyone want that? That means that the picture has to be converted from YV12 to YUY2 to RGB.
- Obviously Gabest wanted that.
- Some people do want to disable YV12. Even if you are a ZP user, you can force the filter not to use YV12, and some people recommend that, probably because of the same reason as Gabest mentioned. One noticeable example is CCCP aka Compack, supported by several anime-related groups. Its current version uses ZP by default with Overlay Mixer, but it disables YV12. It's not that I'm recommending CCCP here, but the point is, some people (still) think that YV12 is not generally safe, probably because upsampling is not properly done in the downstream.
- Just in case you didn't know, this is an old problem as you can read in The Unofficial XviD FAQ: Why do red areas in my clip look blocked or pixelated? (http://ronald.vslcatena.nl/docs/xvidfaq.html#D12)
It says 'A third method is to try to use the "VMR 9 Renderless" mode in MPC.
This will make MPC use another type of playback, possibly using proper upsampling.' and that means, avoiding YV12 may help to solve the problem.

[Wilbert]

Why would anyone want that? That means that the picture has to be converted from YV12 to YUY2 to RGB.
This shouldn't matter, ie it shouldn't be slower. Also AviSynth, for example, does the YV12->RGB conversion via YUY2.

[yaz]

are the internal subtitle renderer and vsfilter different or not ? the only difference i've noticed is that using vsfilter burdens my system more. is there any other ?

just ask because more and more ppl suggest (here on doom9 but on other forums too) to use vsfilter within mpc. i've thought that gabest always implemented the latest vsfilter into mpc.

would someone illuminate me ?

thx
y

[Liisachan]

Hit Alt+3 and set your video size 200% then subs by MPC's internal renderer should be clearer than subs by VSFilter.

MPC algo is like: resize the video, then render subs that are optimized for the video display size. Actually you can set the Maximum texture resolution in MPC (Options|Subtitles)

VSFilter algo is like: render subs that are optimized for the 100% video size, then resize the video (so subs are blurred if enlarged)

That aside, one of the biggest difference between MPC and VSFilter is, in the full-screen mode, sub positioning by MPC is relative-to-screen by default (*) whereas VSFilter is always relative-to-frame.
If the video is 'wider' i.e. the aspect ratio is larger then the aspect ratio of the screen, like 640x360, this results in the different sub positioning, as you can see this pic:
http://ssa.subforge.net/test.html

If the aspect ratio of the video is (nearly) equal to the aspect ratio of the screen, VSFilter and MPC's internal renderer are (nearly) the same, positioning-wise. But generally, the two use different coordinate systems, and that makes it difficult for softsubbers (typesetters) to position things like a logo precisely (absolute positioning). VSFilter respects PlayResX/Y in SSA, but MPC doesn't. This is, honestly, a bit annoying. I guess that's one of the reasons why they want you to use VSFilter. (**)

EDIT
(*) MPC 6.4.8.4 can do that relative-to-frame too, by an option, but not by default.
(**) Purely quality-wise, MPC is better at least in full-screen. The problem is positioning, not sub quaity.

[yaz]

thx for the explanation ! now i know why not to use vsfilter within mpc ;)

thx
y

[yaz]

Purely quality-wise, MPC is better at least in full-screen. The problem is positioning, not sub quaity.yep ... positioning, as we've discussed yet.

i've just tested some mp4 files packed w/vobsub subts (nero way) and i noticed :
- this kinda subtitles are always off by default. must be always selected w/the stream switcher (even if subtitles is on by default !)
- this kinda subtitles is always placed to the edge of the frame either in full screen or when switched to that. override placement is not accepted unless the option window's popped up and 'ok'd.

are these 'features' intentional ? not a big deal but must be kept in mind when playing such files.

i've just noticed an mpc compilation in the cccp pack from somewhat round june. does it implement any new feature or improvement ? has anyone ever tested it ? (i haven't found the reason(s) of this new compilation on ComPak)

thx
y

[rotflol]

Hi,

There's been some changes in the CVS since last build available. Would it make sense to ask someone (CD ;)) to compile a new build or are the changes too insignificant?

[celtic_druid]

Only real changes that I noticed were for MSVC 2005.

[LigH]

- Some people do want to disable YV12.
Me too: My GeForce 2 GTS is not able to use YV12 overlay correctly, the chrominance is tilted against the luminance (a few pixels to the left). YUY2 overlay instead looks well.

[Liisachan]

Celtic_Druid has kindly built a new binary.
http://m17n.cool.ne.jp/freeware/mpc/
http://ffdshow.xrea.jp/

[mOOb]

That latest binary is crashing for me every time in vmr9 renderless even with the Aug5 DirectX 9c. Anyone else having problems with it?

[Palikrovol]

That latest binary is crashing for me every time in vmr9 renderless even with the Aug5 DirectX 9c. Anyone else having problems with it?

me too

[celtic_druid]

Actually that is the setting that I use and therefor the one that I checked.
Does that come with d3dx9_24.dll? Because I think if you check back a few pages, it needs it.

should be in system32.

[Liisachan]

2005-02 d3dx9_24.dll
2005-04 d3dx9_25.dll
2005-06 d3dx9_26.dll
2005-08 d3dx9_27.dll
...so, if d3dx9_24.dll is needed, try directx_9c_Feb05sdk_redist.exe (http://download.microsoft.com/download/1/e/5/1e5135a7-552b-42a6-a7ff-7646522f9277/directx_9c_Feb05sdk_redist.exe)

[celtic_druid]

So the newer SDK's don't include the older dll's? Maybe I should just update my SDK.

[Liisachan]

maybe there is no word 'compatible' in their dictionary ;)


C:\dxsdk_aug2005>dir /s | find /i "d3dx9"
2005-07-22 07:59p 5,335,248 d3dx9d_27.dll
2005-07-22 07:59p 3,988,688 d3dx9d_27.dll
2005-07-22 05:00p 1,933 d3dx9.h
2005-07-22 05:00p 43,369 d3dx9anim.h
2005-07-22 05:00p 23,722 d3dx9core.h
2005-07-22 05:00p 42,261 d3dx9effect.h
2005-07-22 05:00p 58,152 d3dx9math.h
2005-07-22 05:00p 45,124 d3dx9math.inl
2005-07-22 05:00p 125,379 d3dx9mesh.h
2005-07-22 05:00p 41,634 d3dx9shader.h
2005-07-22 05:00p 7,943 d3dx9shape.h
2005-07-22 05:00p 61,793 d3dx9tex.h
2005-07-22 05:00p 12,012 d3dx9xof.h
2005-07-22 05:15p 80,994 d3dx9.lib
2005-07-22 05:44p 81,328 d3dx9d.lib
2005-07-22 05:09p 87,226 d3dx9.lib
2005-07-22 05:02p 87,560 d3dx9d.lib
2005-07-22 08:14p 1,351,430 Aug2005_d3dx9_27_x64.cab
2005-07-22 08:14p 1,078,532 Aug2005_d3dx9_27_x86.cab
2005-07-15 11:25a 3,054 d3dx9dbg.cpp

[celtic_druid]

No baseclasses either which means using the d3d from that and the baseclasses from a previous SDK.

Ok, re-compiled linking against the august 2k d3d9 lib.

[Liisachan]

Unofficial Changelog for 2005-08-13 celtic_druid version
libfaad: FAAD2 Licensing (http://www.hydrogenaudio.org/forums/index.php?showtopic=35535) Techinically now GPL Incompatible :eek:
libdirac: cvs 2005-08-13
anything else?

[Egh]

ORLY?!!! And where's fancy XP theme controls?!!!111!!! (crying aside)

(checking/unchecking the checkbox in Tweak section *and* restart didn't solve t3h problem!!!)

Btw amongst minor changes I noticed -- the URL for subs site changed, is it not? The previous one wasn't working anyway... ^^

[Egh]

Also, which is fun, it seems that ffdshow accessed from new build of mpc also has XP theme controls disabled :) Same of AC3Filter.

Playing old .exe -- all is ok, fancy XP theme :)

New .exe -- old controls :)

Also, i noticed slight change in subs behaviour. Seems that outline & shadow of 1px in old build correspond to 2px in new build (i.e. to see same effect like in official build you need to increase those params by 1px)

Any ideas how to fix XP theme controls?

[Liisachan]

are the internal subtitle renderer and vsfilter different or not ? the only difference i've noticed is that using vsfilter burdens my system more. is there any other ?

just ask because more and more ppl suggest (here on doom9 but on other forums too) to use vsfilter within mpc. i've thought that gabest always implemented the latest vsfilter into mpc. These are known:

(1) MPC's renderer is more CPU-intensive, especially when you disable buffering. VSFilter is not so CPU-intensive even if you disabled buffering.

(2) in 100% video size, MPC's subs are blurred (or maybe "antialiased")

(3) in 200% / fullscreen, MPC's subs are higher-quality than VSFilter's

(4) MPC's subs are relative-to-screen by default whereas VSFilter's subs are always relative-to-frame.

I've just found yet another thing:

(5) I'm not 100% sure but in my test, MPC's subs are one frame too late compared with DirectVobSub--in other words, off by one frame.


Example @ 23.976fps, Frame # = 0-based

Dialogue: 0,0:01:20.07,0:01:28.08,,style,,0000,0000,0000,,Hello, subs!

Frame mm:ss DVobSub MPC
#1919 01:20.038 x x
#1920 01:20.080 o x
#1921 01:20.122 o o
...
#2111 01:28.046 o o
#2112 01:28.088 x o
#2113 01:28.130 x x




With Textsub.vdf or DirectVobSub, "Hello, subs!" starts at #1920, and goes on until #2111, and it is not on #2112.
With MPC, this sub seems to start at #1921, and obviously goes on until #2112, making an overrun by 1 frame.

This sub shouldn't be on #2112, because #2112 starts at 01:28.088--after the End Time (01:28.08) of the sub.
However, MPC renders it on #2112 (the sub will go before #2113).

Generally, the timeline for subs used by MPC's renderer seems to be one frame too late.
In my test, the same happens even if you change the above End Time 01:28.05. Similarly, the Start Time is one frame too late in MPC.

In short, the frame timing will be messed up.
Now I can see why softsubbers prefer VSFilter, even thought MPC's renderer is higher-quality in the fullscreen mode. "relative-to-screen" is not the only reason.

--EDIT--
I filed this bug in sf. But I'm not sure...I mean this problem is so critical that I can't believe it has been ignored until now, and perhaps something is wrong in my test, not in MPC.
Can anyone reproduce the above problems?

[LigH]

I'm not sure if it still makes much sense to post bug reports in this thread monster... anyway, I'll try:

When I play a video (e.g. AVI with XviD and MP3, or other content), and close MPC while it is playing, MPC seems not to be able to stop the playback correctly while quitting. I use ffdshow for most media types, and have it show its tray icon. Here I can see that (although the output window is closed for seconds) video and audio decoder are still active, the video decoder icon still provides format tooltips, and I still hear audio played. Then suddenly, when the buffer is finally empty, the playback stops, and the icons disappear (usually not before I move the mouse over them, but that's another story). Also I cannot move or delete the movie file while I still hear the audio being played (which may last for up to ~20 seconds!), just as if MPC closed its GUI, but did not yet release the file.

If I manually stop the playback, MPC quits immediately.

It would be nice if MPC took better efforts in stopping a currently playing media file, if it gets closed during playback.

[Leak]

It would be nice if MPC took better efforts in stopping a currently playing media file, if it gets closed during playback.
You wouldn't happen to have the "Make DirectShow graph available to graphedit" option on ffdshow's "Info & debug" page checked?

Since MPC does exactly the same, and DirectShow doesn't seem to be able to correctly handle the same graph being exposed twice, you're entering a world full of pain (like the DirectShow graph not being stopped when playing a second file) that way...

[LigH]

Of course this option is checked... You mean I shall better deactivate this option except for the case I really need it?

[Leak]

Of course this option is checked... You mean I shall better deactivate this option except for the case I really need it?
Yeah, that's what I meant - MPC already does expose the DS graph, so ffdshow does it again, and it seems like the graph can only be closed successfully once even when opened twice so it continues playing...

And you can't deactivate it in MPC AFAIK, so you have to deactivate it in ffdshow...

[LigH]

If only the tooltip popup was not so unreliable...

If I hover the mouse pointer over this checkbox right after the ffdshow window appears, I can read: "Use with care - can cause ffdshow to not unload after closing the movie." -- Indeed, that's right; unfortunately, the tooltip appears just for a second, and then never again (until I close and open the window again; the cite was copied out of the .ax file).

[Thomas_AR]

Is it planned to suport DSP WinAmp Plugins some time. Would be nice if for example DFX is suported.

[Leak]

Is it planned to suport DSP WinAmp Plugins some time. Would be nice if for example DFX is suported.
If you use ffdshow as your audio decoder instead of MPC's built-in ones you can use it to load WinAmp plugins...

np: Amorphous Androgynous - Rural Green (The Otherness)

[Peuj]

Is there something special to do to read a wma file with MPC ? It works well with WMP (I get a license file at the first play) but I get an error with MPC (failed to render the file).

thanks

[QQ]

it doesnt support drmed files

[Pug Crydee]

Unofficial Changelog for 2005-08-13 celtic_druid version
libfaad: FAAD2 Licensing (http://www.hydrogenaudio.org/forums/index.php?showtopic=35535) Techinically now GPL Incompatible :eek:
libdirac: cvs 2005-08-13
anything else?


Yes, DTS playback is broken :(
Anyone can confirm? I tried with "old" 6.4.8.4 from SF and that one worked with DTS files, but it has problems with AAC playback, so I had to update to teh CVS build.

Any chance to get a fixed release?
Thx
Pug

[OCedHrt]

(**) Purely quality-wise, MPC is better at least in full-screen. The problem is positioning, not sub quaity.

But to use MPC's internal sub, renderless mode is required. I dunno what reasons people have for using it, but the conversions (RGB->YV12 or the other way around or whatever, I don't really know where (overlay?) but I know it's there) are lossy and you get levels (255->235) problem. Obviously you could set MPC to expand it back to 255 or use ffdshow, but the result just isn't the same. I'm using the newest ATI Catalyst drivers on an Radeon 9800 Pro..not sure if this is fixed in the current/next gen cards or if this is simply a gpu limitation when using overlay.

Ignore me if I don't make any sense :P

[Liisachan]

We were talking about sub quality, and purely quality-wise, subs from MPC are finer than ones from default VSFilter because the max texture size can be the desktop size (softsubs in higher-definition resolution), but there are many other reasons why VSFilter is preferable. Personally tho, I still tend to use MPC's internal sub renderer.

About colors... afaik (correct me if i am wrong) there are 2 strategies:
(1) software-side true color
force ffdshow to output RGB32: generally this is easy, anyone can do that by just ticking some checkboxes. I'd recommend this if I was asked by unspecific people.
The problem is, this is a bit more cpu-intensive. No practical problem with MPEG-4 Part 2, but probably a bit hard for AVC, SNOW, Dirac etc..

(2) YV12 Output + Overlay + hardware-side tweaking
Fastest, but generally not very easy since you should do something hardware-specific.
*Example (NVidia ForceWare 78.01 WHQL)...
- Color Correction -> Apply color changes to: "Overlay" / Brightness "120%" / Contrast "101%"
- Video Overlay Settings -> Hue "0" / Saturation "102%"
The above settings give me almost the same colors (to my eyes) than software-side RGB32 conv. I still feel software-side RGB32 is more beautiful, but that may be just my imagination.

[kallekill]

I was comparing using ffdshow with force rgb32 (high quality) output versus using the hardware (geforce 6) do the color conversion, both using VMR9. I noticed that using ffdshow gives better colors which you clearly see on bright objects, especially red objects. Without using ffdshow the picture is also much brighter, which I have to compensate on my monitor. I also noticed that when using ffdshow to output rgb32 I lost details in very bright areas. Not much, but visible in some shots. I tried to brighten the picture using the monitor, but I couldn’t get that detail to show.

[yaz]

i've just found a new build on free-codecs (http://www.free-codecs.com/download/Media_Player_Classic.htm) dated to 2005.10.17. Notes state it's built by celtic-druid but i can't find it neither on celtic's site nor on the 'official' mirrors. does anyone know anything about this release ?
after some short tests it seems to work fine, anyway.

thx
y

[Liisachan]

In short, nothing new.

I can see Free-codecs ppl were confused when x264.nl posted this: "15-10-05: media player classic 6.4.8.4 xp by celtic_druid added"
This is not a new file but identical to mplayerc2005.08.13.2kxp.7z i.e. mplayerc.exe E80A514F.

[yaz]

mp4 support's round the corner ! see here (http://forum.doom9.org/showthread.php?t=101835)

the bests
y

[Liisachan]

Today Gabest officially admitted that MPC's internal sub renderer can't be as accurate as VSFilter, at least for the time being. Very sad, but it's not MPC's fault. DirectShow is to blame.
http://sourceforge.net/tracker/?func=detail&atid=565649&aid=1280326&group_id=82303
http://forum.doom9.org/showthread.php?p=729805#post729805

PS. So I thought... but Gabest fixed the problem using a special hack,
even tho he once said he couldn't :)
So, MPC's subtitler is not bad after all.

[StopD]

No baseclasses either which means using the d3d from that and the baseclasses from a previous SDK.

Ok, re-compiled linking against the august 2k d3d9 lib.


They moved the baseclasses into the Platform SDK package.... for whatever reason and afaik you can't even compile them with the Platform SDK because it doesn't include a complete MFC/ATL...

[xneo]

d3dx9_27.dll is a separate download now because it is longer needed to run mpc, however to use pixel shaders it has to be put in the dll path.
http://sourceforge.net/project/showfiles.php?group_id=82303&package_id=84358&release_id=368904

and we can display playing file in "Now Playing" MSN Messenger. :)

[rotflol]

Hi,

Since Gabest is in the mood for working on MPC, I'm going to report a couple of bugs, but first I want to find out if they happen to others as well.

Bug 1
Steps to reproduce:
1. Uncheck the built-in MPEG Audio transform filter in Options, set Playback to Play 1 time.
2. Open an MPEG clip, seek to the end, let it end.
3. Press Play to play the clip again.
4. The status bar says Playing, but nothing happens.

Bug 2
Steps to reproduce:
1. Let's assume that the 'jump' value is set to 5s (5000 ms) (Options -> Tweaks).
2. Add two files to the playlist.
3. Seek to to a point in the first file which is less than 5s from the end of the file.
4. Jump forward.
5. Playback stops, the playlist doesn't advance to the next file.

EDIT: Sorry, bug 2 seems to be gone from 6.4.8.6. Bug 1 is still there.

[locotus]

Hi all

I use MPC mostly for internet streaming, since version 6.485 the player couldn,t
handle the asf stream included in asx files. Prior versions works perfectly.

[Liisachan]

I don't think Gabest reads here often, so how about posting your bug report in this thread?
http://forum.doom9.org/showthread.php?t=101835
-and/or-
Project: guliverkli: Browse Bugs (http://sourceforge.net/tracker/?group_id=82303&atid=565649)

A simple sample file should be very appreciated :)