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

[ageback]

S.Chinese update
https://dl.dropbox.com/u/132862/mplayerc.sc.rc.txt

[LigH]

Congratulations for "The thread of thousand pages"

assuming a board default of 20 posts per page

[ryrynz]

I was wondering if someone was going to say something.. I thought about posting IT'S OVER 1000!! earlier today but decided against it

[patch1]

Originally Posted by ryrynz

Track it here at github. As usual, development builds available at http://xhmikosr.1f0.de/mpc-hc/

Is there a reasonably simple way to correlate build number with commit history entry. I find it useful to see what changes I should watch out for when loading a new version of mpc-hc

[ryrynz]

yup the hash is right beside the build number in Help -> About...

For example listed in my MPC-HC copy in Help -> About...

1.6.3.5713 (3a1c0fa)

Matches with build number

3a1c0fad69

[v0lt]

Originally Posted by ryrynz

Matches with build number

3a1c0fad69

This is a mockery.

[Underground78]

Originally Posted by v0lt

See audio decoder settings.

It can probably be useful, I think it makes sense to add it.

Originally Posted by ryrynz

yup the hash is right beside the build number in Help -> About...

For example listed in my MPC-HC copy in Help -> About...

1.6.3.5713 (3a1c0fa)

Matches with build number

3a1c0fad69

If you are just interested in seeing the last few changes, http://github.com/mpc-hc/mpc-hc/commit/<shorthashhere> (e.g. http://github.com/mpc-hc/mpc-hc/commit/3a1c0fa) and then click on the parent hash to go to the previous commit.

I'm considering doing a simple log viewer for people that prefer using the old fashioned build number.

[v0lt]

Originally Posted by Underground78

It can probably be useful, I think it makes sense to add it.

mpc-hc_audiomixer_3.7z
Yet another test build. And then see what happens.

[Underground78]

Originally Posted by v0lt

mpc-hc_audiomixer_3.7z
Yet another test build. And then see what happens.

It seems to work fine for me, I tested it with my channel order samples.

Originally Posted by GrofLuigi

In Options>Subtitles>Delay Interval, I can't enter - (minus sign). mpc-hc64.exe 1.6.3.5696 on Win7 x64.

GL

That's because putting a negative number here doesn't really make sense. If you press F1/F2 (default key bindings but you can change them in Options > Keys), it will subtract/add the value you set in "Delay interval".

[Mosley]

Originally Posted by v0lt

See audio decoder settings.

Sorry but.... where? In "MPC Audio Decoder" (during playback) there isn't nothing. And I don't see any menu option related to the audio decoder settings. Not even in the the menu page with the internal filters. What's exactly the path to find it?

Many thanks...

[Underground78]

Originally Posted by Mosley

Sorry but.... where? In "MPC Audio Decoder" (during playback) there isn't nothing. And I don't see any menu option related to the audio decoder settings. Not even in the the menu page with the internal filters. What's exactly the path to find it?

Many thanks...

In the audio decoder settings you have a combobox that lets you choose the channels configuration (stereo, etc).

[ryrynz]

Originally Posted by Underground78

I'm considering doing a simple log viewer for people that prefer using the old fashioned build number.

Sounds like a good idea.

[betaking]

S.Chinese update
http://www.mediafire.com/?udt1imv5mm8bdd5

[v0lt]

mpc-hc_audiomixer_6.7z
redid the audio decoder settings window

[TheCatcher]

I modified a recent pull of MPC-HC source code to support SBS 3D on older DLP TVs, that require the right and left screen data to be pixel interleaved.

I did it with a couple of DX9 (ps_2_0) Post-Resize Pixel Shaders (one for right side first, and the other for left side first). And a change to the DX9RenderingEngine.cpp, to add 4 additional parameters to the fConstant array that is passed to the Post-Resize Pixel Shaders.

The 4 additional parameters are the offset and width of the video data relative to the m_TemporaryScreenSpaceTextureSize. And the position of the MPC-HC Window relative to the screen. The offset to the video data was necessary to make sure when I interleaved the pixels, I didn't mix in any surrounding non-video data. The position of the window relative to the screen was necessary so that, in windowed mode, I would know whether to pull the first pixel of each line from the right or left side of the frame.

Since this requires additional parameters to be passed to the Pixel Shaders, I wasn't sure if this is a change that the people responsible for the source repository would be interested in. I plan on keeping it in the versions of MPC-HC that I run. If it is something that someone would like to add to the source repository, here is the source code modification, that I am using...

DX9RenderingEngine.cpp -> Line 451-453
From:
float fConstData[][4] = {
{(float)m_TemporaryScreenSpaceTextureSize.cx, (float)m_TemporaryScreenSpaceTextureSize.cy, (float)(counter++), (float)diff / CLOCKS_PER_SEC},
{1.0f / m_TemporaryScreenSpaceTextureSize.cx, 1.0f / m_TemporaryScreenSpaceTextureSize.cy, 0, 0},
};

To:
CWnd *pMainWnd = AfxGetApp()->m_pMainWnd;
WINDOWPLACEMENT Place;
Place.length = sizeof(WINDOWPLACEMENT);
EXECUTE_ASSERT(GetWindowPlacement(pMainWnd->m_hWnd,&Place));

float fConstData[][4] = {
{(float)m_TemporaryScreenSpaceTextureSize.cx, (float)m_TemporaryScreenSpaceTextureSize.cy, (float)(counter++), (float)diff / CLOCKS_PER_SEC},
{1.0f / m_TemporaryScreenSpaceTextureSize.cx, 1.0f / m_TemporaryScreenSpaceTextureSize.cy, (float)destRect.left, (float)( destRect.right + 1 ) - destRect.left },
{(float)Place.rcNormalPosition.top, (float)Place.rcNormalPosition.left, (float)0, (float)0 },
};

If anyone is interested, let me know, and I will post the code for the Post-Resize Pixel Shaders.

[Anarchitektur]

Originally Posted by v0lt

mpc-hc_audiomixer_6.7z
redid the audio decoder settings window

"mixer" checkbox does not stay ticked

[JanWillem32]

@TheCatcher: If it's useful to add the top and left monitor-relative window coordinates as variables for the pixel shaders, I don't mind helping out a bit. Your code needs a lot of refining, though.
The usage of GetWindowPlacement() is wrong for when your window is a layered item: http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx .
Use GetWindowRect() to get desktop-relative coordinates (and if more info is required, use GetWindowInfo() to retrieve the full window class info).
Using the coordinates 'raw' is wrong as well. For a multi-monitor setup of 4 1920×1080 monitors in a 2×2 setup with the top left monitor set as main monitor, the desktop interval for the bottom-right monitor will be [(1920, 1080), (3840, 2160)). Use GetMonitorInfo() and offset the desktop-relative coordinates with top-left point of the monitor rectangle to get monitor-relative coordinates.
Using "pMainWnd->m_hWnd" is wrong as well, as that's the main player's window (which can even be on another monitor). We have "m_hWnd" available in the renderer classes themselves for the video window.
For the Post-Resize pass, "(float)destRect.left, (float)( destRect.right + 1 ) - destRect.left" is useless. "destRect.left" is 0, and "destRect.right" is equal to "m_TemporaryScreenSpaceTextureSize.cx", which is already available. (The Post-Resize pass does no re-positioning, that's only done in the resizer pass before it.) For integer coordinates on Windows, it's already custom to have the left and top items inclusive and the right and bottom items exclusive: http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx . You simply do right minus left and bottom minus top to get the size of a RECT.
If you need any more info or help, please just ask me.

[v0lt]

Interesting observation.
If you have a stereo track, in which the left and right channels are identical. Then when mixing 2.0 to 5.1, you will not hear the rear speakers.
With ordinary stereo tracks no such problem.

[v0lt]

Originally Posted by Anarchitektur

"mixer" checkbox does not stay ticked

It fixed.
r5597+

[JanWillem32]

Mixing audio indeed works like that; the simple mono center is a per sample left+right and the simple width is a left-right (actually also mono, the same output is sent to all surround channels). If the data in the left and right is the same, left-right will be zero. Note that the interval of the output samples increases from a base interval of [-1, 1] to [-2, 2] for both equations (there's a clipping risk, just as with other mixing options).
When the phase of left and right are off by even a µs, the samples won't align, and doing a per-sample left+right and left-right won't work. You need to do continuous Fourier transforms on the tracks to correlate them spectrally in such a case. Such filters are much more expensive in processing but benefit greatly from single-precision floating point optimizations in SSE and AVX code. Such filters can also do more advanced extractions of channels, but are prone to artifacts. (For once, Fourier transforms on audio data won't let very low bass sounds through because of a limit in the sampling window. You need to add a low-pass filter to output those to the LFE channel.)
It's been a while since I worked with audio filters, but those are pretty much the basics of what I can remember about channel expansion filters.