Media Player Classic Home Cinema (MPC-HC) - DXVA!

[Reino]

We're talking about http://xhmikosr.1f0.de (http://xhmikosr.1f0.de), aren't we?

[nevcairiel]

We're talking about http://xhmikosr.1f0.de (http://xhmikosr.1f0.de), aren't we?

Indeed we are.

[Underground78]

@ Underground78: I know about the About-dialog, but this is before downloading. At Github you can only see the hash-code and at XhmikosR's website (which appears to be offline atm :() only the build-code. If Github would show both, you would actually know what kind of MPC-HC build you're downloading.

XhmikosR can probably put the hash in the filename of the nightlies.

PS: It also works for me.

[Reino]

Well, call me crazy, but all I see is a white screen with h5ai 0.22-dev-9 (http://larsjung.de/h5ai) at the bottom.

[nevcairiel]

Well, call me crazy, but all I see is a white screen with h5ai 0.22-dev-9 (http://larsjung.de/h5ai) at the bottom.

Sounds like he updated to some broken version of that directory index script. I let him know.

[HoP]

Well, call me crazy, but all I see is a white screen with h5ai 0.22-dev-9 (http://larsjung.de/h5ai) at the bottom.

it works.you need to have JavaScript enabled in your browser
http://xhmikosr.1f0.de/mpc-hc/

[ryrynz]

I had an Adblock Plus issue like that a week or so ago, I disabled it on that site and that fixed it.

[betaking]

pls put mpc-hc sourcecode to code.google.com some chinese user can not visit and download sourcecode form github! thanks

[JEEB]

pls put mpc-hc sourcecode to code.google.com some chinese user can not visit and download sourcecode form github! thanks
And there are some Chinese who can't access Google Code (see: xy-vsfilter's developer).

Anyways, anyone is free to clone the git repository and push it wherever they want to mirror it. Every clone of a git repository is equal. That's the magic of distributed systems (just remember to grab all branches if you want them).

That said, if vBm or someone wants to set it up, mirroring to the official Google Code project should be possible (a simple script to check for new content and pushing it to the mirrors run every X minutes).

[Tom Keller]

I have a strange problem with the MPC-HC since build 1.6.3.5803:

I'm using WinXP SP3, running on a Core2Duo E6600 @2,4Ghz with an Asus Xonar DX soundcard and a NVIDIA 9600GT GPU (forceware driver 275.27) with a dual monitor setup. The "Fullscreen monitor" option in MPC-HC is set to "DISPLAY 2" (= the tv) while the player app runs all the time on the first display. So the playback controls are on the monitor and the video is on the tv, mostly using madVR with the "D3D fullscreen" option.
Till 1.6.3.5783 it was possible to open the MPC-HC options dialog (via "O" key or "View" => "Options") while playback was running - but since 1.6.3.5803 the dialog won't open. The dialog opens, while playing a file in window mode or playing no file at all - but the options dialog won't show with ANY video renderer (VMR/EVR/madVR) while playing a video using "D3D fullscreen" on display 2, with the player app on display 1. Even if i pause or stop the fullscreen-playback the dialog won't open... i always have to close and restart MPC-HC to change its options.

Is this a bug or is it on purpose ( <= maybe a stupid question... but you'll never know if some changes requested a specific behaviour ;) )?

[ryrynz]

I'm merely posting this for the curious. Any questions or comments you might have regarding MPC-BE should not be posted here. Enjoy.

MPC-BE build 802

Link removed for GPL reasons, new version stable release due out shortly, keep an eye out in the next few weeks.

[alexins]

I'm merely posting this for the curious. Any questions or comments you might have regarding MPC-BE should not be posted here. Enjoy.

MPC-BE build 802.

... and this message here should not be, you violates the GPL!
:devil:

p.s.
This building has several problems, which may adversely affect the operation of your computer. :D

[bozek]

Right.

[Anonymous9377]

is there a way to undock the controls and be able to drag them around the screen separate from the video like vlc?
cause i play video outside of the player and vlc 1.x cuts off video at the end, and vlc 2.x resizes the video when a new 1 is played instead of the fixed size selected
mpc doesn't have this problem but i need to undock and drag the controls independent of the screen.. seems like every video player has an achilles heel
i know its a customize niche but hey

some suggestions i have for mpc-hc
or "make mpc more like vlc"

1. option to undock controls separate from the video
need to move the controls away from the video
2. have playlist not appear in full screen like controls
when in full screen playlist is over the video
3. option to have controls appear in full screen mode
controls disappear in full screen unlike vlc
4. option to disable dragging video when you click on it
click the video for full screen etc. and accidentally moved

thank you very much

[keneo]

Calling all programmers!

I am a novice programmer with no experience in Windows programming.

My vision for a modification to mpc-hc is that the user could now add custom commands (consisting of a system commandline call and an associated hotkey to trigger that custom command) to the table on the "Keys" Option page. The commandline can include insertable paramaters such as <currently playing media full path name>, <the current media play position>, <the current media length>, etc...

I have made what I consider to be a lot of progress. But now I am at the point where I need to tell my new subroutine which hotkey was pressed. As far as I know it is not possible to call a message map function that uses parameters. Unfortunately, using a parameter was my entire plan A for passing along the hotkey info.

So now I need a plan B.

My thinking is that the function that gets called from the message map could some how find out what the latest hot key pressed was. So, is there a way to know what the last hotkey pressed was? if not, maybe I could insert some code somewhere to record the hotkey so that it can now remember? (I dont really like the idea of inserting code into someone elses routines, but if that's the only way, then so be it.)

Or plan C

Bypass the message map completely. Insert code to intercept the hotkey and branch off from there if any of the custom command hotkeys are pressed. That sounds like the the most horrible idea of them all. But I am totally open to any help!

[jos99]

Is there any way to set the size of the window in pixels when you open MPC HC?

[Anonymous9377]

Is there any way to set the size of the window in pixels when you open MPC HC?

not an expert on this but since its slow;

1. select option to make player adjust to video size
2. get or make a video the size you want
3. open video thats the size you want
4. unselect option to make player adjust to video size

or

1. if you know how do the same thing in vlc
2. stretch the screen so its the same as vlc's window

i dont remember how i did it exactly but good luck

[betaking]

https://github.com/mpc-hc/mpc-hc/commit/d78ea81f39e5b6c8d3c8bfa69a37e03f409ef9bf
why remove .dat extension?
If you remove the MPC-HC will not play .dat files on the VCD discs form CD-ROM OR DVD-ROM!
http://forum.doom9.org/showthread.php?p=1178911#post1178911

[jos99]

not an expert on this but since its slow;

1. select option to make player adjust to video size
2. get or make a video the size you want
3. open video thats the size you want
4. unselect option to make player adjust to video size

Thanks, that option doesn't really work as if you unselect it, it just reverts to the default small opening size & if you select it, it just saves whatever variable size of the video you just played. Any experts have any idea about how to change the default window size?

In case people didn't see the thread, there are two really nice toolbar skins from jinsk8r http://archangelx2.deviantart.com/ that I reposted

http://forum.doom9.org/showthread.php?p=1587541#post1587541

they didn't work originally as they only posted jpgs, they have now posted BMPs & they look great

can someone add to the toolbar skin wiki page as I don't have permissions:

https://sourceforge.net/apps/trac/mpc-hc/wiki/Toolbar_images

[73ChargerFan]

I'd like a right-click option to lock the window size, that holds only until the player is closed.

I often have a playlist of short cartoons of varying resolutions, off to one side of my screen while I'm reading a web browser on the other side (gotta love wide screens!) Every 5 minutes, when the next cartoon starts, the player resizes and I have to fix it.

This would be VERY handy.

[VipZ]

I'd like a right-click option to lock the window size, that holds only until the player is closed.

I often have a playlist of short cartoons of varying resolutions, off to one side of my screen while I'm reading a web browser on the other side (gotta love wide screens!) Every 5 minutes, when the next cartoon starts, the player resizes and I have to fix it.

This would be VERY handy.

I think disabling auto zoom in options should do this for you.

[jos99]

I think disabling auto zoom in options should do this for you.
Yeah that does work, you'd need to keep re-enabling it if you wanted to watch in full size but not full screen tho'. It would be nice if you could have various window size presets you could select by right clicking i.e. auto zoom, default, preset 1, preset 2, preset 3 etc that are remembered even on restart.

[VipZ]

Yeah that does work, you'd need to keep re-enabling it if you wanted to watch in full size but not full screen tho'. It would be nice if you could have various window size presets you could select by right clicking i.e. auto zoom, default, preset 1, preset 2, preset 3 etc that are remembered even on restart.

Disabling auto zoom and then using alt+2 (100% zoom, there are other presets as well) if you want to set video to 100% size. Personally I like to set my own window size at let media fill that size so I can do similar to you, watch and read stuff at same time.

[jos99]

Disabling auto zoom and then using alt+2 (100% zoom, there are other presets as well) if you want to set video to 100% size. Personally I like to set my own window size at let media fill that size so I can do similar to you, watch and read stuff at same time.
Thanks:), it was mainly for aesthetic reasons though that I wanted MPC-HC to start at a certain size each time, if I resize at all it just remembers that setting. Anyway, I've worked out what I want to do now, default starting size is simply determined by the size of the logo, I wanted mine about 535 pixel square, the top controls are about 50px, bottom 95px, sides 7px each on Windows 7 so the logo needs to 521 x 390 px.

[v0lt]

https://github.com/mpc-hc/mpc-hc/commit/d78ea81f39e5b6c8d3c8bfa69a37e03f409ef9bf
why remove .dat extension?
If you remove the MPC-HC will not play .dat files on the VCD discs form CD-ROM OR DVD-ROM!
http://forum.doom9.org/showthread.php?p=1178911#post1178911

I've seen a real VideoCD only once. He did not impress me compared to DivX 3.11. Most users do not know what a VideoCD.

.dat extension of very often used to store anything, but not for video. We have suffered for almost ten years. Now we are well, we're happy.


.dat playback nowhere gone. If you want the association, then it is done manually (added manually to "Other" group) or by means of Windows ("Open as...").
You can also rename the .mpg.

[tetsuo55]

VideoCD is still really popular in asian countries.
New VideoCD's get released about as often as DVD/Bluray.

There are even many videos that where only ever released on VideoCD ( i have a 100 disks myself)

I agree that it is unfortunate mpeg chose a common extention like .dat

My preference would be for your reverting the .dat part of the commit.

[jos99]

Modified MPC logo that was on jinsk8r's (http://archangelx2.deviantart.com) screenshot (http://forum.doom9.org/showthread.php?p=1587541#post1587541) to MPC-HC

http://dl.dropbox.com/u/35202345/mpchclogogreenmask.png

you can paste that as a layer onto any image and save as a bmp or png (merge/flatten layers if asked) & use any image as the MPC-HC logo background.

[jos99]

Cleaned up the text a bit

http://dl.dropbox.com/u/35202345/mpchclogogreenmask3.png

logo on black

http://dl.dropbox.com/u/35202345/mpchclogogrnonblk.png
(http://dl.dropbox.com/u/35202345/mpchclogogrnonblk.png)
MPC-HC on mars

http://dl.dropbox.com/u/35202345/mpchcmarscurios.png

[ney2x]

This (http://x33d.deviantart.com/art/MPC-HC-logo-244258311) is the logo I am using :)

[Liisachan]

I'm experiencing a strange incompatibility about how VSFilter handles the advanced SSA tag {\frx}.

In VSFilter 1.6.3.5818, for example {\frx-10} works like {\frx+10} in 1.6.2.4902, at least sometimes. As if the sign of the parameter had been reversed between v1.6.2 and v1.6.3.

Samples:
"{\fnVerdana\fs32\b1\frx+30}Test frx+30" with 1.6.2
http://ffdshow.faireal.net/tmp/v162+30.png
"{\fnVerdana\fs32\b1\frx-30}Test frx-30" with 1.6.3
http://ffdshow.faireal.net/tmp/v163-30.png

***

"{\fnVerdana\fs32\b1\frx-30}Test frx-30" with 1.6.2
http://ffdshow.faireal.net/tmp/v162-30.png
"{\fnVerdana\fs32\b1\frx+30}Test frx+30" with 1.6.3
http://ffdshow.faireal.net/tmp/v163+30.png

***
Well, though it may be just me, this could be a serious problem for SSA/ASS typesetters. Did I do anything wrong? I'm still on Windows XP if that's a sin...

EDIT: I'm using VSFilter from the standalone_filters package, via Avisynth.

EDIT2: Maybe a problem in Transform_SSE2, enabled in Revision 5569, as opposed to the classic Transform_C?

[Liisachan]

This happened between 5555 and 5572; the revision 5569 by XhmikosR on July 19, 2012 should be the culprit.

This SSE2 optimization from VSFilterMod (i.e. Transform_SSE2) is obviously broken, where they're rotating font-x in the wrong (negative) direction. I just confirmed that VSFilterMod does really rotate font to the opposite direction. This "bug" should be something trivial, where they typed "+" when they should have typed "-" or something like that, when handling sin or cos.
The original rotation by Gabest agrees with MPC-HC 1.6.2 and before; with ffdshow, VLC, and probably with libass too (which I cannot test directly since I'm sadly on Windows). The latest version of MPC-HC is practically the only one that is not compatible.

See for yourself: font_rotation_x.mkv (http://ffdshow.faireal.net/tmp/font_rotation_x.mkv) (~50 kB)

MPC rev. 114
http://ffdshow.faireal.net/tmp/mpc114.jpg

ffdshow rev. 4483
http://ffdshow.faireal.net/tmp/ffdshow4483.jpg

VLC v2.0.3
http://ffdshow.faireal.net/tmp/vlc203.jpg

MPC-HC rev. 5555
http://ffdshow.faireal.net/tmp/mpc5555.jpg

MPC-HC rev. 5572 (Broken!)
http://ffdshow.faireal.net/tmp/mpc5572.jpg

If you guys are not interested in \frx at all, will you at least revert to the non-SSE2 version before many typesetters start rotating fonts to the opposite direction, creating a lot of confusion? Like I said, VSFilterMod should be fixed too if someone is still working on it.

Thanks again for your wonderful jobs!

[sneaker_ger]

VLC is using libass...

xy-vsfilter seems to be unaffected.

[Keiyakusha]

Why would anyone import something from vsfiltermod anyway? Its not meant for playback! Better revert everything and just integrate xy-vsfilter if you need optimizations.

[nevcairiel]

This SSE2 optimization from VSFilterMod (i.e. Transform_SSE2) is obviously broken, where they're rotating font-x in the wrong (negative) direction.

Should be fixed. It was a simple mistake in the SSE2 code, two operands flipped.

Why would anyone import something from vsfiltermod anyway? Its not meant for playback! Better revert everything and just integrate xy-vsfilter if you need optimizations.

Not much was added from VSFilterMod, only stuff that seemed harmless at the time, like this SSE2 optimization.

[Liisachan]

Should be fixed. It was a simple mistake in the SSE2 code, two operands flipped.
Thank you very much, nevcairiel, for trying to fix the problem, and thank you very much for working for MPC-HC in general too! Your efforts are really appreciated.

The obvious problem you mentioned has been surely fixed, but as it turned out, something (like the rotation origin, the nature of rotation...) is still wrong, suggesting the SSE2 optimizations in VSFilterMod are not well-tested, not compatible with the unoptimized code, and this problem is more subtle than I first thought.

The following images show the +70-degree x-rotation of "Èj" in the {\pos} (position) (0,0) with the {\an7} style (upper-left corner is the origin), that is the {\org} (origin) is (0,0) too. The original letters that are not rotated are shown in pale green. The results of the rotation are shown in red.

1) This is the good one, rendered by old, reliable 1.6.2, compatible with Gabest and with ffdshow, and almost compatible with VLC.
http://ffdshow.faireal.net/tmp/frx_samp2good.png

2) The next image shows what we have now, using 1.6.4.5887 (698e56d) taken from http://xhmikosr.1f0.de/mpc-hc/ (thanks to XhmikosR).
http://ffdshow.faireal.net/tmp/frx_samp2bad.png
As you can see, the general direction of the rotation is more or less better now, but this is far from being compatible.

See for yourself:
font_rotation_x2.mkv (http://ffdshow.faireal.net/tmp/font_rotation_x2.mkv) (~50 kiB): hardsubbed in blue, softsubbed in red.

Also note that, although I said that this was borked in 5569 by XhmikosR, the code was not written by XhmikosR. It was already there, already imported, and conditionally commented out. He/she (XhmikosR) simply enabled it. It's not his/her fault that this SSE2 code is broken.

[cyberbeing]

I remember these \frx \fry \frz bugs. It's why we disabled the Transform_SSE2 code in xy-VSFilter a long time ago.

Should be fixed. It was a simple mistake in the SSE2 code, two operands flipped.

As Liisachan mentioned, it's unfortunately still not fixed. The problem affects more than just \frx.

Here is a better sample which was initially created to track down this bug in xy-VSFilter last year:
http://www.mediafire.com/?j9ota09016rt2yb

The video is hardsubbed with a reference VSFilter 2.39 \frx \fry \frz rendering.
The external script subtitles with opposite color should match up identically through all the rotations.

[Liisachan]

The external script subtitles with opposite color should match up identically through all the rotations.
Confirmed here. \fry is wrong too. \frz seems okay (not buggy).

The bug officially came to MPC-HC in the v1.6.3 release like 10 days ago, which I first tried like 2 days ago, when I noticed the incompatibility. So this was a new problem for me. (Btw, xy-VSFilter seems really promising. Like, \fscx/fscy + float is what I've always wanted. I'll look into xy-VSFilter too when I have time.)

[Liisachan]

I looked into the inside of RTS.cpp, and this is my first impression. If you're watching __pointx in Transform_SSE2:

__pointx = _mm_add_ps(__xx, __yy); // xx = x * caz + y * saz; //#1
__xx = _mm_mul_ps(__pointx, __cay); // x * cay //#2
__pointx = _mm_add_ps(__xx, __zz); // xx = x * cay + z * say //#3
__xx = _mm_mul_ps(__pointx, __say); // x * say //#4

#1 Now __pointx is the vectorized version of "xx" from the C code.
#2 is wrong: you're using __pointx as "x" but it's "xx" since #1.
#3 makes __pointx "xx" again.
#4 is wrong: you're using __pointx as "x" but it's "xx" since #3.

Similarly, for __pointy:

__pointy = _mm_add_ps(__yy, __zz); // y = yy * cax + zz * sax //#5
__yy = _mm_mul_ps(__pointy, __sax); // yy * sax //#6

#5 __pointy is "y".
#6 is wrong. You're using __pointy as "yy" but it's "y" since #5.

[nevcairiel]

You're right, i really should've seen that when i documented the calls. I didn't actually change them except flipping the one operand there, just added the docs, but apparently didn't pay enough attention.
No matter, i gave it another try and refactored the whole function to use variable names matching the C ones very closely, no changes of meaning in the variables anymore. ;)

The test videos you and cyberbeing posted are working fine now.

[JanWillem32]

Well, you chose quite a monster of a function to work on there. (I'll try to explain it mostly to the public that knows at least basic programming, but hasn't seen this function yet.)
I disabled Transform_SSE2() when I was fixing the issues with scaling to the video area on the window area and aspect ratio correction with the frx, fry and frz functions a while ago. I marked Transform_SSE2() with: "TODO: The methods here are very wrong (the C function does work as it should), fix this with decent code, or delete this function." As resolving the list of issues of Transform_SSE2() plus fixing the scaling and aspect ratio bugs seemed to be too much work at the time, I chose to only edit Transform_C().
As the variables are prefixed with "_", I was already wondering who would write such code. That prefix is generally reserved for the global compiler-specific functions, constants and variables. Renaming would indeed be a good start.

A quick review of the function shows that:
-None of the typecasts between single- and double-precision floating points and 32-bit signed integers used in this function is properly handled with SSE.
-"static_cast<LONG>(x + 0.5)" is used to do rounding casts to integer in both the C and the SSE functions. SSE has native rounding casts to do this, which also handles negative values properly. (Vertices stored as integers is one of the most retarded design choices of the subtitle renderer. Using floating-point vertices would eliminate these type casts and provide decent sub-pixel precision.)
-No intrinsic to generate a native load data to register is used. "_mm_set_~" is used everywhere, where "_mm_load_~" should have been used.
-The basic cos() and sin() functions are not handled with SSE. (I'll ignore the horribly truncated PI in these lines for now.)
-4 lines of code feature access to member variables of the __m128 union. That's illegal if you take it strictly, but the compiler will probably bend over backwards and do a lot of register shuffles to output the correct values.
-"__m128 __pointz = _mm_set_ps1(0);"; this functionality is provided properly by _mm_setzero_ps().
-_mm_rcp_ps() (reciprocal approximation) is used. That's reasonably okay, but the output precision with only this instruction is low (12 bits). It could use a Newton-Raphson iteration to improve that (to about 22 bits, out of the full 24 bits). Else, a regular floating-point division to get the reciprocal would work fine.

The design choice of using single-precision instead of double-precision for this function is okay. (Transform_C() uses doubles.) The lower precision isn't significant. Handling this function with SSE2 vectorized doubles would have been just as easy, though.
I don't think that the author of the Transform_SSE2() function had any experience working with SSE intrinsics or ever wrote assembly before. The function is marked with "// speed up ~1.5-1.7x", but I doubt that to be true. Pretty much all the code for the subtitle renderer's SSE2 functions have issues, although most are less severe than this one.
Unfortunately, this function illustrates the state the subtitle renderer is in rather well. Refactoring the functions with these kinds of issues isn't easy, but any effort on getting proper, efficient routines in the subtitle renderer is very welcome indeed.

[nevcairiel]

I just fixed the math in it to match the C math, nothing else. :p

[cyberbeing]

On that note, xy-VSFilter rewrote the Transform_C code for better performance a couple weeks ago. Though from what I remember hearing, the transform code was never really a bottleneck for VSFilter in the first place.

[Liisachan]

The fix itself is awesome. Thank you very much, Nevcairiel. (I've not yet got a binary, though.)

However...

-_mm_rcp_ps() (reciprocal approximation) is used. That's reasonably okay, but the output precision with only this instruction is low (12 bits).
That's a very good point. And I'm not sure if it's okay. If x=1000, the possible error is roughly 1000/(2^12) = 0.25. But what if the true value is x=90.5 and we got x=90.4 because of this? Like this, a few points (maybe 1 out of 100) in the path will be off by 1 unit (1/8-pixel?) after rounding and slight distortion is possible, compared to the C version. Just divide, and the result is 10000 times more accurate:

__xx = _mm_mul_ps(__xx, __20000); // xx * 20000
__pointx = _mm_div_ps(__xx,__zz); // x = (xx * 20000) / (zz + 20000)
__yy = _mm_mul_ps(__yy, __20000); // yy * 20000
__pointy = _mm_div_ps(__yy, __zz); // y = (yy * 20000) / (zz + 20000);


Or use _mm_rcp_ps a la Newton.

//__zz = _mm_rcp_ps(__zz); // 1 / (zz + 20000)
__m128 z0 = _mm_rcp_ps(__zz);
__zz = _mm_sub_ps( _mm_add_ps(z0,z0), _mm_mul_ps(z0,_mm_mul_ps(z0,__zz)) );


-"static_cast<LONG>(x + 0.5)" is used to do rounding casts to integer in both the C and the SSE functions. SSE has native rounding casts to do this, which also handles negative values properly.
I don't think they are compatible for x=...-2.5, -1.5, 0.5, 1.5, 2.5, 3.5... (Cast vs. Round to nearest even). And I think x=1 means 1/8-pixel in VSFilter (it's already subpixel). Although it's a fact that VSFilter code is kind of insane in a good sense or a bad sense, it was not the original authors (Avery Lee/Gabest) who wrote this SSE2 function.

[nevcairiel]

the easiest solution would obviously be to use _mm_div_ps, but no idea how speed comparison is there.
Considering the C version also uses a real division, its probably not going to be slower then C at least.

Edit:
I pushed a patch to use _mm_div_ps and another small cleanup.

[JanWillem32]

I don't think they are compatible for x=...-2.5, -1.5, 0.5, 1.5, 2.5, 3.5... (Cast vs. Round to nearest even). And I think x=1 means 1/8-pixel in VSFilter (it's already subpixel). Although it's a fact that VSFilter code is kind of insane in a good sense or a bad sense, it was not the original authors (Avery Lee/Gabest) who wrote this SSE2 function.Subpixel rendering is very useful for anti-aliasing. (Something the subtitle renderer scores really badly at, and it isn't even configurable for the degree of anti-aliasing.) The best solution to render curvy shapes is to have their vertices stored as floating-point throughout the entire pipeline (like any normal image renderer). There are multiple casts back and forth to integer and floating point for various objects, this is just one of the functions that does that. Oh well, it could be a lot worse. The functions that take care of subtitle color rendering for instance...

I took a peek at the latency and throughput table (Intel® 64 and IA-32 Architectures Optimization Reference Manual, edition june 2011):
Given for a Sandy Bridge model (06_2AH) and an older Merom (06_0FH):
divps: 14/14, <21, <16
rcpps: 5/1, 3/1
mulps: 5/1, 4/1
addps: 3/1, 3/1
subps: 3/1, 3/1

I certainly can also look it up for AMD, but I think it won't matter much. Straight divisions are always expensive in both latency and throughput, no matter for integer or floating point.
The rcpps and a Newton-Raphson iteration method is mostly a lot faster if the pipeline can be reordered easily. If the µops are crammed together, the pipeline will stall for a little bit.
Of course, divps outputs with full 24 bits of precision, and the approximate routine with about 22. That's probably the main reason that there's no rcppd or rcpsd for doubles.

[cyberbeing]

On that note, xy-VSFilter rewrote the Transform_C code for better performance a couple weeks ago.

I was just emailed the following from Yu Zhuohuang (xy-VSFilter dev):
Nevcairiel may still want to look into our commit bac768e02081317ae17cf19e496ca3a3a1e5f7af (http://repo.or.cz/w/xy_vsfilter.git/commit/bac768e02081317ae17cf19e496ca3a3a1e5f7af), in which the Transform_C function was rewritten. This one is well documented, in comparison to other changes I've made. That commit reduces the number of multiplication to 1/3 of the original function. It is likely faster than a "1.7x - 2.x" speed up SSE code.

@Nevcairiel

He's basically suggesting that xy-VSFilter's Transform_C code be used as a base if any proper Transform_SSE2 function is ever going to be written.

If xy-VSFilter's rewritten Transform_C really is faster than the 'fixed' VSFilterMOD Transform_SSE2, that may be a good reason for MPC-HC to just scrap it and start over.

[JanWillem32]

I took a peek at that commit.
PI is still truncated to 3.1415. DSUtil (linked in) has M_PI with enough digits to fill a double.double scalex = style.fontScaleX/100;Right-hand side is implicitly an integer, the intent is a double. Luckily, only it's only esthetic in this case, but the same is done over and over again in the subtitle renderer's code, while it doesn't have to be like that at all.
(long)(x + org.x + 0.5);Is the org struct still made of integers? If so, two lines incur a useless cast to double and a cast back to long. Also, in many cases, org.x and .y are implicitly cast to double. Casting them to a temp double value before the loop would probably be better for those cases. Otherwise it looks like a good improvement overall, and a lot better to use than the current SSE2-ish function.

[Liisachan]

Tested 1.6.4.5895 (0235e5b), and the bug was finally fixed. Yay! Since I don't have a binary with the fix AND _mm_rcp_ps, I can't tell how _mm_rcp_ps is bad in a real-world sample.

The SSE2 version of CWord::Transform was originally committed on May 13, 2010:
https://code.google.com/p/vsfiltermod/source/detail?r=76
The log message says, "is this good and correct?" So the author was not sure themself if they were doing this right. But hey, everyone has the right to enjoy experimenting :D It's part of what free-software is all about. Let's stop blaming this function. It was unfortunate that this was just imported to MPC-HC without being tested properly.

Similarly, things should be tested properly before imported from xy-VSFilter, even though I'm willing to support xy-VSFilter too. I read somewhere that xy-VSFilter crashed just because you used a negative value between {\p1}...{\p0}, showing it's not very stable yet, though promising.

Subpixel rendering is very useful for anti-aliasing. (Something the subtitle renderer scores really badly at, and it isn't even configurable for the degree of anti-aliasing.)
If you're implying VSFilter is not handling subpixels or it's not doing anti-aliasing, that is incorrect. The following images show, left to right: 1) Not anti-aliased; 2) Anti-aliased, pixel-accuracy; 3) Half-pixel accuracy; 4) Quarter-pixel accuracy; 5) VSFilter (I think this is 1/8-pixel accuracy).
http://ffdshow.faireal.net/tmp/aou_antialias_demo.png

Compare the 4th and 5th images, and you'll see the quality gain by going from qpel to 8th-pel is marginal. Probably the algorithm of anti-aliasing itself could be improved, but you wouldn't gain much here by just using (float) or (double).
A subtitle renderer has to render things quickly, like 24 times a second. When Subtitler (the parent of VSFilter) was created about 10 years ago by Avery Lee (the same author of VirtualDub), 0.125-pixel accuracy stored as integer was probably an optimal choice - considering the CPUs used back then. And no one is going to say that Avery Lee didn't use float because he didn't know the best solution. That's too disrespectful! Today we have better hardware, and probably someone will create something even better eventually, like libass. But even if the font rendering quality of VSFilter is not perfect, maybe the "limited subpixelness" (8x8 subpixels per pixel) is not the reason. Rendered text looks solid to me, if not perfect. Correct me if I'm wrong.

There are multiple casts back and forth to integer and floating point for various objects.
I agree with you about this one. For one thing, I've been always unhappy about \fscx, where VSFilter does (double)wcstol, which doesn't make sense to me. If only it was wcstod... then you could use 99.5% or 100.5% font size easily. Technically, though, that would break the compatibility of a tag like {\fscx99.5}.

It seems better to me not to change 3.1415, even though it's weird. Changing it might break existing ASS scripts that depend on this weirdness. But then again, {\blur} broke the compatibility of {\b} too...

[nevcairiel]

All i did was to make the SSE2 function behave the same as the C function, i have no real interest in changing it any more.

If someone wants to still optimize the old and rather broken VSFilter, have fun. :p

[MasterNobody]

While you fixing subtitles renderer may be somebody can look at crash with this sample (http://www.mediafire.com/?r8aacdbna4b6beh):
http://i45.tinypic.com/20b25h1.png (http://i46.tinypic.com/28tkqiq.jpg)
To reproduce bug at least this conditions must be met:
1) Internal subtitles enabled and configured like this:
http://i45.tinypic.com/2iglzrm.png (http://i45.tinypic.com/2qv439g.png)http://i46.tinypic.com/2jg6jw5.png (http://i49.tinypic.com/29l1q28.png)
2) Desktop resolution is 1280x1024
3) Sample played in full screen from beginning to end

I checked with MPC-HC 1.6.4.5895 (0235e5b) x86 and it still happen. OS: Windows XP SP3.

P.S. Looks like final crash happen not inside subtitle renderer but caused by it (probably write outside of its memory).