Media Player Classic - Home Cinema (MPC-HC) - v1.7.13

[Motenai Yoda]

Request time: can someone sometime add a sw bicubic resizer (not ps)? Maybe -0.75 or -1.00?
My laptop's (arrandale) gpu load increase from 12% to 70% when using a ps resizers, but bilinear is so smooth!!!

[hello_hello]

Yes, I know mate, but I'm just curious if the same advice could apply on my PC. I mean, does he think software decoding is for any reason better? Better image? Lower voltage or resources in general?

Unless he simply recommends software decoding just because the Nvidia 540 isn't enough... In this case my curiosity is off the table.

I wondered the same thing when I read that post. Why the rule of thumb stating CPU decoding should be used in preference to hardware decoding if possible?
Surely if I'm doing something CPU intensive for which the GPU can't lend a hand (ie video encoding) it makes sense to use the GPU for decoding/watching video?

Now I've got everything working correctly again (see my previous post #880) my old Nvidia 8600GT is happily decoding everything I throw at it. Everything up to and including High Profile, Level 4.1, at least. Why not let it?

[the_weirdo]

No one prevents you from using hardware decoding. They just say that you should use software decoding if possible, because it's more stable than hardware decoding.

[jkauff]

Nev has pointed out in the past that a fast CPU can decode many more frames per second than either CUDA or QuickSync. That's one reason why he recommends software decoding. QuickSync outputs more FPS than CUDA, so when I'm doing a Handbrake encode (eating up most of my CPU resources) I use QuickSync decoding to play a movie. My old eyes can't see the difference between software and QS anyway, frankly, with most of the sources I'm watching.

[nevcairiel]

My old eyes can't see the difference between software and QS anyway, frankly, with most of the sources I'm watching.

The video quality is exactly the same.

[jkauff]

The video quality is exactly the same.
Interesting. The rate at which you can feed the renderer (in my case madVR) doesn't affect rendering quality in any way? Didn't realize that.

[nevcairiel]

Not at all. The only difference is speed, which can influence file opening speed and seeking speed.
Software decoding is also not influenced by bugs in your GPUs decoder or your GPU driver, which is why I prefer it when possible.

[kasper93]

MPC-BE nightlies already support decoding HEVC. Is that planned for MPC-HC nightlies "soon™" as well?

Starting from nightly 1.7.0.118 MPC-HC has support for HEVC and VP9 :) Thanks to LAV Filters and ffmpeg.

[Damien147]

If I put an autoload path subtitles of the same folder as the movie stop being read.Tried resetting settings and clean install but I still get the same thing,any ideas?

[sneaker_ger]

Were there any changes to the LAV building process? It does not crash anymore when used with EMET for me.

[betaking]

Were there any changes to the LAV building process? It does not crash anymore when used with EMET for me.

https://github.com/mpc-hc/mpc-hc/commit/959c6fb0ebe56b5701dea16778380f0bf488315f
Switch back to GCC 4.7.3 due to issues with EMET.

[nevcairiel]

Note that the switch will most likely not be permanent, and in the future GCC 4.8 will most likely be used again.

[mindbomb]

is there a way to show frame number?

[LigH]

ffdshow has On-Screen Display overlays if you use that as decoder filter.

[Carpo]

Has anyone got the nightlies to build with VS2013?

I get these errors repeated many many times, these are just a small sample

7> Unknown Option Build
7>
7> ------------------------------
7> [ERROR] 'sh build_ffmpeg.sh x86 Build' failed!
7> ------------------------------
7>
7>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.MakeFile.Targets(38,5): error MSB3073: The command "build_lavfilters.bat Build x86 Silent Nocolors" exited with code 1.

20>c:\mpc-hc\include\qt\fp.h(122): warning C4005: 'NAN' : macro redefinition (ShaderEditorDlg.cpp)
20> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(106) : see previous definition of 'NAN'
20>c:\mpc-hc\include\qt\fp.h(122): warning C4005: 'NAN' : macro redefinition (ShaderCombineDlg.cpp)
20> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(106) : see previous definition of 'NAN'
20> TunerScanDlg.cpp
20>c:\mpc-hc\include\qt\fp.h(122): warning C4005: 'NAN' : macro redefinition (SubtitleDlDlg.cpp)
20> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(106) : see previous definition of 'NAN'
20>c:\mpc-hc\include\qt\fp.h(122): warning C4005: 'NAN' : macro redefinition (TextPassThruFilter.cpp)
20> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(106) : see previous definition of 'NAN'
20>c:\mpc-hc\include\qt\fp.h(122): warning C4005: 'NAN' : macro redefinition (TunerScanDlg.cpp)
20> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(106) : see previous definition of 'NAN'
20> UpdateChecker.cpp
20> UpdateCheckerDlg.cpp
20> vkCodes.cpp
20> VMROSD.cpp
20> VolumeCtrl.cpp
20> WebClientSocket.cpp
20> WebServer.cpp
20>c:\mpc-hc\include\qt\fp.h(122): warning C4005: 'NAN' : macro redefinition (VMROSD.cpp)
20> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(106) : see previous definition of 'NAN'
20>c:\mpc-hc\include\qt\fp.h(122): warning C4005: 'NAN' : macro redefinition (WebServer.cpp)
20> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(106) : see previous definition of 'NAN'
20> WebServerSocket.cpp
20> WinHotkeyCtrl.cpp
20>c:\mpc-hc\include\qt\fp.h(122): warning C4005: 'NAN' : macro redefinition (WebClientSocket.cpp)
20> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(106) : see previous definition of 'NAN'
========== Build: 16 succeeded, 2 failed, 25 up-to-date, 2 skipped ==========

the issue with building lavfilters seems to be because of

C:\mpc-hc\src\thirdparty\LAVFilters>build_lavfilters.bat Build x86 Silent Nocolors
Unknown Option Build

------------------------------
[ERROR] 'sh build_ffmpeg.sh x86 Build' failed!
------------------------------


C:\mpc-hc\src\thirdparty\LAVFilters>build_lavfilters.bat
Unknown Option Build

[Raylan Givens]

Guys, Output Audio Renderer - What's the difference between "Speakers Realtek High Definition Audio 0020000" and the default direct sound device? In short, is there any meaningful difference?

Incidentally, if I set "Speakers Realtek High Definition Audio" with the default settings, I get no sound likely because the chip doesn't support floating point or something... If I uncheck the 32bit Floating in Lav output formats, it works normally... Meanwhile, the default direct sound device accepts floating point normally. Is this behavior the result of a bug?

[JanWillem32]

WaveOut and DirectSound outputs differ. WaveOut sends a buffer with rendering data to the sound adapter driver, regardless of compatibility. WaveOut also doesn't have decent sound mixing capabilities. DirectSound puts audio streams in a software renderer, mixes them, and outputs in the format configured for the audio output, causing it to be more compatible with various combinations of audio input streams and hardware than WaveOut. The cost of the DirectSound method is high latency.
There are other audio output options, such as WASAPI methods and ASIO, but these are not (decently) available for MPC-HC. These are mostly intended for low-latency access to the hardware and are especially demanding on the driver and rendering format (compatibility worse than WaveOut).
The rules for these types of audio outputs differ greatly by operating system. The most dramatic changes were in Windows Vista: http://en.wikipedia.org/wiki/Technical_features_new_to_Windows_Vista .

[Raylan Givens]

Thank you!

Incidentally, waveout you mean this, right? Because this is what I'm talking about. You must 'cause it acts the same as "Default Waveout Device"

http://i1.minus.com/ibai8fagNauE3L.png

Now I get it. If I connect my XFi do you think would be better to connect via default waveout device or still better let it as is, on default direct sound device? Keep in mind that I don't care about latency issues and I let the card's CMSS3D do the sound mixing ( surround 50% ).

[JanWillem32]

WaveOut is old. It's only there to work with old or exotic stuff. In terms of buffering and stability DirectSound is a lot better. Those that really care about latency issues should not use WaveOut nor DirectSound.

[Raylan Givens]

Right, thanks again. I let it on Default Direct Sound Device and I'm done with it.

One last question... Is there any difference between Bilinear and Bilinear PS 2.0? In terms of quality, efficiency and whatnot...

[JanWillem32]

The plain Bilinear resizer is done by StretchRect() on linear interpolation and doesn't allow rotation. The pixel shaded version allows rotation and is made using a typical drawing call. If the GPU has dedicated hardware to handle StretchRect() with linear interpolation, it will cost less resources. If not, the cost will be about the same. The quality should be equal for both.

[renq]

How can I play WMV videos in Win8.1 Pro N?
MPC crashes as I open one of them.

[James Freeman]

Anyone can help me to write a little Brightness Shader for MPC-HC?

My plan is to write a small Brightness shader only for custom steps x1-x2 (x1 and x2 are variables) out of 0-255.
The point is to make the blacks (or any custom range) brighter/darker but leave all the other steps alone.

This to prevent black crush, and have more control of only the lower darker black levels without changing all the other steps.

Many thanks.

EDIT:
@JanWillem32, I see you are an expert.
Can you help me to write this shader?

[Octo-puss]

Is seeking broken in any way? I noticed the player gets completely locked if I play a video consisting of extremely low amount of frames, say two, and try to seek around a few times. Not only no picture shows up when the file is played (I have to click somewhere in the seek bar to actually see anything), but only one of the frames can actually be seen (the second, I believe). If I click somewhere again, the whole program completely locks up about 90% of the time.

[JanWillem32]

James Freeman, do you mean multi-stage gamma controls, like the those used in studios? It's not a complicated filter. I just wrote a prototype. It still needs to be properly vectorized, but it somewhat works. For smoother transitions I could also try applying higher-order function fitting, but that would mean that the operating values would become much more complicated.
Be careful with these kinds of filters. Most settings will cause a ton of banding and may cause weird coloration with the altered mixes of red, green and blue. Do not try to mix colors (such as with the filter below) within R'G'B', use RGB or an absolute color space.// multi-stage gamma controls, prototype

sampler s0 : register(s0);

#define rxgamma .9
#define gxgamma .8
#define bxgamma 1.3
// xgamma must be higher than 0
#define rxpoint .3
#define gxpoint .2
#define bxpoint .1
// xpoint must be higher than 0
#define rygamma 2.1
#define gygamma 2.3
#define bygamma 2.7
// ygamma must be higher than 0
#define rypoint .5
#define gypoint .4
#define bypoint .6
// ypoint may be set equal to xpoint to disable the stage
// ypoint must be higher than xpoint to work
#define rzgamma 2.4
#define gzgamma 2.2
#define bzgamma 2.6
// zgamma must be higher than 0

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float4 s1 = tex2D(s0, tex);
float3 sb = sign(s1.rgb);

if (s1.r < rxpoint) {
s1.r = pow(abs(s1.r/float(rxpoint)), rxgamma)*rxpoint;
} else if (s1.r < rypoint) {
float segmentsize = rypoint-rxpoint;
s1.r = pow(abs(s1.r/segmentsize-rxpoint/segmentsize), rygamma)*segmentsize+rxpoint;
} else {
float segmentsize = 1.-rypoint;
s1.r = pow(abs(s1.r/segmentsize-rypoint/segmentsize), rzgamma)*segmentsize+rypoint;
}

if (s1.g < gxpoint) {
s1.g = pow(abs(s1.g/float(gxpoint)), gxgamma)*gxpoint;
} else if (s1.g < gypoint) {
float segmentsize = gypoint-gxpoint;
s1.g = pow(abs(s1.g/segmentsize-gxpoint/segmentsize), gygamma)*segmentsize+gxpoint;
} else {
float segmentsize = 1.-gypoint;
s1.g = pow(abs(s1.g/segmentsize-gypoint/segmentsize), gzgamma)*segmentsize+gypoint;
}

if (s1.b < bxpoint) {
s1.b = pow(abs(s1.b/float(bxpoint)), bxgamma)*bxpoint;
} else if (s1.b < bypoint) {
float segmentsize = bypoint-bxpoint;
s1.b = pow(abs(s1.b/segmentsize-bxpoint/segmentsize), bygamma)*segmentsize+bxpoint;
} else {
float segmentsize = 1.-bypoint;
s1.b = pow(abs(s1.b/segmentsize-bypoint/segmentsize), bzgamma)*segmentsize+bypoint;
}

s1.rgb *= sb;// restore sign bits
return s1;
}

[James Freeman]

James Freeman, do you mean multi-stage gamma controls, like the those used in studios?

Yes, exactly.


EDIT:
I don't seem to grasp how to use this RGB Point/Gamma/XY system.

EDIT2:
Got It.
Its a 3 section Gamma changer.


EDIT3:
PERFECT !!!
MadVR + This shader = no banding (smooth).

Does exactly what I wanted.

Many thanks JanWillem32.


EDIT4:

The Default should be:
* I also added descriptions how to use.

// Multi-Stage Gamma Controls Filter

// This filter divides the greyscale to 3 separate individually controlled gamma sections.

// XPoint & YPoint determine the two cut points (0.333 & 0.666 giving exactly 3 equal thirds).
// XGamma controls whats Before XPoint.
// YGamma controls whats Before YPoint.
// ZGamma controls whats After YPoint.

// Default gamma is 1, lower = brighter, higher = darker.

// R.G.B should be the same to retain the greyscale without odd hue and color changes.

sampler s0 : register(s0);

#define rxgamma 3
#define gxgamma 3
#define bxgamma 3
// xgamma must be higher than 0
#define rxpoint 0.333
#define gxpoint 0.333
#define bxpoint 0.333
// xpoint must be higher than 0
#define rygamma 2
#define gygamma 2
#define bygamma 2
// ygamma must be higher than 0
#define rypoint 0.666
#define gypoint 0.666
#define bypoint 0.666
// ypoint may be set equal to xpoint to disable the stage
// ypoint must be higher than xpoint to work
#define rzgamma 0.5
#define gzgamma 0.5
#define bzgamma 0.5
// zgamma must be higher than 0

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float4 s1 = tex2D(s0, tex);
float3 sb = sign(s1.rgb);

if (s1.r < rxpoint) {
s1.r = pow(abs(s1.r/float(rxpoint)), rxgamma)*rxpoint;
} else if (s1.r < rypoint) {
float segmentsize = rypoint-rxpoint;
s1.r = pow(abs(s1.r/segmentsize-rxpoint/segmentsize), rygamma)*segmentsize+rxpoint;
} else {
float segmentsize = 1.-rypoint;
s1.r = pow(abs(s1.r/segmentsize-rypoint/segmentsize), rzgamma)*segmentsize+rypoint;
}

if (s1.g < gxpoint) {
s1.g = pow(abs(s1.g/float(gxpoint)), gxgamma)*gxpoint;
} else if (s1.g < gypoint) {
float segmentsize = gypoint-gxpoint;
s1.g = pow(abs(s1.g/segmentsize-gxpoint/segmentsize), gygamma)*segmentsize+gxpoint;
} else {
float segmentsize = 1.-gypoint;
s1.g = pow(abs(s1.g/segmentsize-gypoint/segmentsize), gzgamma)*segmentsize+gypoint;
}

if (s1.b < bxpoint) {
s1.b = pow(abs(s1.b/float(bxpoint)), bxgamma)*bxpoint;
} else if (s1.b < bypoint) {
float segmentsize = bypoint-bxpoint;
s1.b = pow(abs(s1.b/segmentsize-bxpoint/segmentsize), bygamma)*segmentsize+bxpoint;
} else {
float segmentsize = 1.-bypoint;
s1.b = pow(abs(s1.b/segmentsize-bypoint/segmentsize), bzgamma)*segmentsize+bypoint;
}

s1.rgb *= sb;// restore sign bits
return s1;
}


Without Filter:
http://i557.photobucket.com/albums/ss18/ilya-v/Other/original_zpsb884901a.jpg

With Filter (Default settings):
Extreme Changes to show the effect of the filter.
http://i557.photobucket.com/albums/ss18/ilya-v/Other/3patrsgamma_zps7c196493.jpg



For a BT.1886 curve:
// Multi-Stage Gamma Controls Filter

// This filter divides the greyscale to 3 separate individually controlled gamma sections.

// XPoint & YPoint determine the two cut points (0.333 & 0.666 giving exactly 3 equal thirds).
// XGamma controls whats Before XPoint.
// YGamma controls whats Before YPoint.
// ZGamma controls whats After YPoint.

// Default gamma is 1, lower = brighter, higher = darker.

// R.G.B should be the same to retain the greyscale without odd hue and color changes.

sampler s0 : register(s0);

#define rxgamma 0.5
#define gxgamma 0.5
#define bxgamma 0.5
// xgamma must be higher than 0
#define rxpoint 0.2
#define gxpoint 0.2
#define bxpoint 0.2
// xpoint must be higher than 0
#define rygamma 1
#define gygamma 1
#define bygamma 1
// ygamma must be higher than 0
#define rypoint 0.666
#define gypoint 0.666
#define bypoint 0.666
// ypoint may be set equal to xpoint to disable the stage
// ypoint must be higher than xpoint to work
#define rzgamma 1
#define gzgamma 1
#define bzgamma 1
// zgamma must be higher than 0

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float4 s1 = tex2D(s0, tex);
float3 sb = sign(s1.rgb);

if (s1.r < rxpoint) {
s1.r = pow(abs(s1.r/float(rxpoint)), rxgamma)*rxpoint;
} else if (s1.r < rypoint) {
float segmentsize = rypoint-rxpoint;
s1.r = pow(abs(s1.r/segmentsize-rxpoint/segmentsize), rygamma)*segmentsize+rxpoint;
} else {
float segmentsize = 1.-rypoint;
s1.r = pow(abs(s1.r/segmentsize-rypoint/segmentsize), rzgamma)*segmentsize+rypoint;
}

if (s1.g < gxpoint) {
s1.g = pow(abs(s1.g/float(gxpoint)), gxgamma)*gxpoint;
} else if (s1.g < gypoint) {
float segmentsize = gypoint-gxpoint;
s1.g = pow(abs(s1.g/segmentsize-gxpoint/segmentsize), gygamma)*segmentsize+gxpoint;
} else {
float segmentsize = 1.-gypoint;
s1.g = pow(abs(s1.g/segmentsize-gypoint/segmentsize), gzgamma)*segmentsize+gypoint;
}

if (s1.b < bxpoint) {
s1.b = pow(abs(s1.b/float(bxpoint)), bxgamma)*bxpoint;
} else if (s1.b < bypoint) {
float segmentsize = bypoint-bxpoint;
s1.b = pow(abs(s1.b/segmentsize-bxpoint/segmentsize), bygamma)*segmentsize+bxpoint;
} else {
float segmentsize = 1.-bypoint;
s1.b = pow(abs(s1.b/segmentsize-bypoint/segmentsize), bzgamma)*segmentsize+bypoint;
}

s1.rgb *= sb;// restore sign bits
return s1;
}

BT.1886 V2:
Brightens a little below 10%, but leaves below 1% untouched.
// Multi-Stage Gamma Controls Filter

// This filter divides the greyscale to 3 separate individually controlled gamma sections.

// XPoint & YPoint determine the two cut points (0.333 & 0.666 giving exactly 3 equal thirds).
// XGamma controls whats Before XPoint.
// YGamma controls whats Before YPoint.
// ZGamma controls whats After YPoint.

// Default gamma is 1, lower = brighter, higher = darker.

// R.G.B should be the same to retain the greyscale without odd hue and color changes.

sampler s0 : register(s0);

#define rxgamma 1
#define gxgamma 1
#define bxgamma 1
// xgamma must be higher than 0
#define rxpoint 0.01
#define gxpoint 0.01
#define bxpoint 0.01
// xpoint must be higher than 0
#define rygamma 0.7
#define gygamma 0.7
#define bygamma 0.7
// ygamma must be higher than 0
#define rypoint 0.1
#define gypoint 0.1
#define bypoint 0.1
// ypoint may be set equal to xpoint to disable the stage
// ypoint must be higher than xpoint to work
#define rzgamma 1
#define gzgamma 1
#define bzgamma 1
// zgamma must be higher than 0

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float4 s1 = tex2D(s0, tex);
float3 sb = sign(s1.rgb);

if (s1.r < rxpoint) {
s1.r = pow(abs(s1.r/float(rxpoint)), rxgamma)*rxpoint;
} else if (s1.r < rypoint) {
float segmentsize = rypoint-rxpoint;
s1.r = pow(abs(s1.r/segmentsize-rxpoint/segmentsize), rygamma)*segmentsize+rxpoint;
} else {
float segmentsize = 1.-rypoint;
s1.r = pow(abs(s1.r/segmentsize-rypoint/segmentsize), rzgamma)*segmentsize+rypoint;
}

if (s1.g < gxpoint) {
s1.g = pow(abs(s1.g/float(gxpoint)), gxgamma)*gxpoint;
} else if (s1.g < gypoint) {
float segmentsize = gypoint-gxpoint;
s1.g = pow(abs(s1.g/segmentsize-gxpoint/segmentsize), gygamma)*segmentsize+gxpoint;
} else {
float segmentsize = 1.-gypoint;
s1.g = pow(abs(s1.g/segmentsize-gypoint/segmentsize), gzgamma)*segmentsize+gypoint;
}

if (s1.b < bxpoint) {
s1.b = pow(abs(s1.b/float(bxpoint)), bxgamma)*bxpoint;
} else if (s1.b < bypoint) {
float segmentsize = bypoint-bxpoint;
s1.b = pow(abs(s1.b/segmentsize-bxpoint/segmentsize), bygamma)*segmentsize+bxpoint;
} else {
float segmentsize = 1.-bypoint;
s1.b = pow(abs(s1.b/segmentsize-bypoint/segmentsize), bzgamma)*segmentsize+bypoint;
}

s1.rgb *= sb;// restore sign bits
return s1;
}

[JanWillem32]

The compiler went easy on me this time. It actually took me more effort to add comments than to optimize this function.// (C) 2013 Jan-Willem Krans (janwillem32 <at> hotmail.com)
// This file is part of Video pixel shader pack.
// This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
// This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
// You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

// multi-stage gamma controls
// This shader can be run as a screen space pixel shader.
// This shader requires compiling with ps_2_0, but higher is better, see http://en.wikipedia.org/wiki/Pixel_shader to look up what PS version your video card supports.
// This shader is meant to work with linear RGB input and output. Regular R'G'B' with a video gamma encoding will have to be converted with the linear gamma shaders to work properly.
// Use this shader to control up to three stages of gamma curves.

// fractions, either decimal or not, are allowed
// RedxGamma, GreenxGamma and BluexGamma, bottom segment gamma, interval (0, 10], default 1
#define RedxGamma 1.4
#define GreenxGamma .8
#define BluexGamma 1.3
// RedyGamma, GreenyGamma and BlueyGamma, middle segment gamma, interval (0, 10], default 1
#define RedyGamma 21/5.
#define GreenyGamma 4.3
#define BlueyGamma 4.7
// RedzGamma, GreenzGamma and BluezGamma, top segment gamma, interval (0, 10], default 1
#define RedzGamma 3.7
#define GreenzGamma 5.2
#define BluezGamma 17/7.
// RedxPoint, GreenxPoint and BluexPoint, cutoff point of the first segment, interval (0, 1]
#define RedxPoint .3
#define GreenxPoint .2
#define BluexPoint .1
// RedyPoint, GreenyPoint, and BlueyPoint, cutoff point of the second segment, interval [{RedxPoint, GreenxPoint, and BluexPoint}, 1]
// Setting a value for these three equal to the value in RedxPoint, GreenxPoint or BluexPoint respectively will disable the stage.
#define RedyPoint .5
#define GreenyPoint 8/9.
#define BlueyPoint .6

sampler s0 : register(s0);
static const float3 xGamma = {RedxGamma, GreenxGamma, BluexGamma};
static const float3 yGamma = {RedyGamma, GreenyGamma, BlueyGamma};
static const float3 zGamma = {RedzGamma, GreenzGamma, BluezGamma};
static const float3 xPoint = {RedxPoint, GreenxPoint, BluexPoint};
static const float3 yPoint = {RedyPoint, GreenyPoint, BlueyPoint};
static const float3 ySegmentsize = yPoint-xPoint;
static const float3 zSegmentsize = 1.-yPoint;

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float3 s1 = tex2D(s0, tex).rgb;// original pixel
float3 sb = sign(s1);// preserve sign bits
// transform gamma inside the three segments
float3 xstage = pow(abs(s1/xPoint), xGamma)*xPoint;
float3 ystage = pow(abs(s1/ySegmentsize-xPoint/ySegmentsize), yGamma)*ySegmentsize+xPoint;
float3 ret = pow(abs(s1/zSegmentsize-yPoint/zSegmentsize), zGamma)*zSegmentsize+yPoint;
// select from the correct segment depending on the cutoff points
if (s1.r < RedyPoint) {
ret.r = ystage.r;
}
if (s1.g < GreenyPoint) {
ret.g = ystage.g;
}
if (s1.b < BlueyPoint) {
ret.b = ystage.b;
}
if (s1.r < RedxPoint) {
ret.r = xstage.r;
}
if (s1.g < GreenxPoint) {
ret.g = xstage.g;
}
if (s1.b < BluexPoint) {
ret.b = xstage.b;
}
ret *= sb;// restore sign bits
return ret.rgbb;// gamma-altered color output
}

[James Freeman]

JanWillem32,

Any difference between the two versions?

[JanWillem32]

55 instructions versus 40.

[James Freeman]

Instructions = lines of code?
Less is better?
Newer has less instructions?

Any Quality difference?

What are these gamma values: 17/7 = 2.4285 ???

Any benefits having separate RGB's instead a single value?

Is this going to be in the Pixel Shader Pack so that everyone will benefit from this?


Anyway.
This Shader is just perfect for lifting the shadows a little (at a specific bandwidth) without effecting the rest of the picture.
I can't believe we did not have this sooner.

Thanks again, Jan.

[JanWillem32]

The final shader takes about 25% less compile time (32 to 37 ms versus 41 to 51 ms for the prototype), compiles to 40 instructions versus 55 for the prototype and has the usual set of comments inserted. The final shader can be compiled with the PS 2.0 compiling level, while the prototype can't. The actual code being executed is the same. It's just optimization plus adding comments.

17/7. is a totally normal fractional value with full precision. (I never round values to less than the point of satisfying full precision in 128-bit IEEE quadruple precision floating-point values, so I usually set my calculator to 50 significant decimal digits.) Notation of 17./7., 17./7, 17.0/7.0 and such are fine as well. Just include a dot in the notation so that the compiler recognizes it as a single-precision floating-point value.

Red, green and blue values are separated for the simple reason that it's possible, and it doesn't really take extra code to handle them separately.

The Pixel Shader Pack v1.5 will need quite a lot of extra work. I don't like the blocks of comments below the title of the shaders. It still mentions "screen space pixel shader" and such, which is just outdated. I also want to split the entire set of shaders per rendering color space+format. I'll have to add a 'readme' to properly document what to use in what renderer for that. Most of the pixel shaders are already available as multi-version (see the last few pages of the shader thread for examples).
Some shaders need to be scrapped for the simple reason that they should never be used (or I'll just put them in the junk folder called 'development'). I also wrote new shaders and corrected some wrong methods in older ones.
My main problem is actually the set of newly developed shaders. These hardly contain any comments, and some of them are just not user-friendly. I just don't have time to edit and test over 350 files.

[Milardo]

hi does anybody know how to get a usb 2.0 hdmi capture device to work in mpc-hc such as the one i have which is roxio game capture hd pro?

[betaking]

can not use TortoiseGit download submodule "qsdecoder"
in 1fo.de is ad4c50072dedfbd1cf5939a9317782b2f4d3e051
but on https://github.com/Underground78/lavfilters
is qsdecoder @ d7678f1

[Motenai Yoda]

@James Freeman only two notes:
1- why not add a gamma aware correction?
2- instead of this multi-stage gamma correction, use a s curve to increase contrast without loss detail, like photoshop brightness/contrast new one?
this does exactly the same as ps (in avisynth and in yv12 but most of the formula is it, change 109.5 to 127.5 and remove 16 +/-...)
#Contrast with an 'S' curve (like photoshop's Contrast/ Brightness new mode)
s=15 #contrast strength, it's the merge factor, value from -100 to 100
mt_lut(yExpr="x 100 "+String(s.float())+" - 100 / * x 16 - 109.5 / 1 - 1.5 * sin 1 + 109.5 * 16 + "+String(s.float())+" 100 / * +",chroma="copy")

[JanWillem32]

This is quite interesting...

1 - I already mention counteracting the problems with gamma during rendering in the shaders that mix colors. See: "This shader is meant to work with linear RGB input and output. Regular R'G'B' with a video gamma encoding will have to be converted with the linear gamma shaders to work properly."
The RGB, XYZ, LMS or sometimes even xyY color spaces will generally work fine. The shaders that include the aforementioned statement do not expect to receive R'G'B' input, so that these can do a gamma-correct operation.

2 - There are indeed better options to multi-stage variable color controls, I just wrote one that was easy to operate.
Stating "does exactly the same as ps" is plain wrong though.

Any decent brightness, contrast, gamma and other colorimetric controls should never be attempted in Y'CbCr color spaces such as used in YV12. The basic Y'CbCr format is only a color space modeled to be mostly compatible with the 1953 NTSC analog color television standard, and is as such completely worthless as a rendering format. Even R'G'B' (the initial conversion format from Y'CbCr) is a bad rendering format for most operations.

Offloading operations to the CPU by for example Avisynth is indeed a good idea for those that don't have a decent GPU.
Use RGB or an absolute color space with good quantization in both storage (16-bit integer or 32-bit floating point minimum) and calculation format (only floating point, 32-bit (maybe 24-bit for legacy stuff) minimum) during rendering and it should work fine.

S-curves are higher-order math. I can work with them, but most people can't. Higher-order curves don't take simple nodes (such as RedxPoint, GreenxPoint and BluexPoint I used in the script), but change the bends on the first- and onward-order mathematical derivatives of the function. Higher-order curves are certainly better for creating smooth transitions, though.

[vood007]

This is Curves Shader of SweetFX for MPCHC:



/* --- Curves settings --- */
#define Curves_contrast 0.30 //[-1.0 to 1.0] The amount of contrast you want

// -- Advanced curve settings --
#define Curves_formula 3 //[1 to 7] The constrast s-curve you want to use.
/* --- End of settings --- */

/* --- Defining Constants --- */

sampler s0 : register(s0);


/* --- Curves --- */
/*
by Christian Cann Schuldt Jensen ~ CeeJay.dk

Curves, uses S-curves to increase contrast, without clipping highlights and shadows.
*/

float4 CurvesPass( float4 colorInput )
{
float3 color = colorInput.rgb; //original input color
float3 lumCoeff = float3(0.2126, 0.7152, 0.0722); //Values to calculate luma with
float Curves_contrast_blend = Curves_contrast;
float PI = acos(-1); //3.14159265

//calculate luma (grey)
float luma = dot(lumCoeff, color);

//calculate chroma
float3 chroma = color - luma;

//Apply curve to luma

// -- Curve 1 --
#if Curves_formula == 1
luma = sin(PI * 0.5 * luma); // Sin - 721 amd fps, +vign 536 nv
luma *= luma;
#endif

// -- Curve 2 --
#if Curves_formula == 2
luma = ( (luma - 0.5) / (0.5 + abs(luma-0.5)) ) + 0.5;
#endif

// -- Curve 3 --
#if Curves_formula == 3
//luma = smoothstep(0.0,1.0,luma); //smoothstep
luma = luma*luma*(3.0-2.0*luma); //faster smoothstep alternative
#endif

// -- Curve 4 --
#if Curves_formula == 4
luma = 1.1048 / (1.0 + exp(-3.0 * (luma * 2.0 - 1.0))) - (0.1048 / 2.0); //exp formula
#endif

// -- Curve 5 --
#if Curves_formula == 5
luma = 0.5 * (luma + 3.0 * luma * luma - 2.0 * luma * luma * luma); //a simple catmull-rom (0,0,1,1)
Curves_contrast_blend = Curves_contrast * 2.0; //I multiply by two to give it a strength closer to the other curves.
#endif

// -- Curve 6 --
#if Curves_formula == 6
luma = luma*luma*luma*(luma*(luma*6.0 - 15.0) + 10.0); //Perlins smootherstep
#endif

// -- Curve 7 --
#if Curves_formula == 7
luma = ((luma-0.5) / ((0.5/(4.0/3.0)) + abs((luma-0.5)*1.25))) + 0.5;
#endif


//Add back the chroma
color = luma + chroma;

//Blend by Curves_contrast
colorInput.rgb = lerp(colorInput.rgb, color, Curves_contrast_blend);

//Return the result
return colorInput;
}

/* --- Main --- */

float4 main(float2 tex : TEXCOORD0) : COLOR {
float4 FinalColor = tex2D(s0, tex);

FinalColor = CurvesPass(FinalColor);

return FinalColor;
}

[Motenai Yoda]

@JanWillem32 my apologizes I read too quickly..
1- I notice that there isn't a correction 'cause test patterns posted by James Freeman hasn't.

2- I didn't write that to reproduce photoshop's one, but was an experiment to use a simple sin function to contrast chroma planes, I later adapted it for luma, and looks exactly the same, also is simple to manage for low mid and light part separately 'cause the nodal point in sin(0). Finally that was a merely example.

btw u said stuff like 16bit, 32bit (I think are for channel), but 24 bit... there is something that works in 24bit float? I hope u didn't mean 24bit RGB 'cause that are integers, 3 channels @8bit (while 32bit RGB add another channel, alpha). For luminosity stuff, YV12 as video content generally are, is good enough, u only need to work on Y, also masktools works only in yv12 (maybe the lastest in YV16 and YV24 too) but all calculation are done in 32bit float.

off topic closed for me.

@vood007 thanks, that stupid WolframAlpha don't give me 2Pi*n + Pi/2 but an "x~~0.5 (12.5664 n+3.14159)", precision for my curve is the curve 1

[JanWillem32]

vood007, that shader indeed includes indeed a set of common curve formulas, some polynomial, some non-polynomial. It unfortunately still tries to work on luma though. (The dot product of R'G'B' with the vector {.2126, .7152, .0722} yields the luma or Y' scalar for BT.1886/BT.709 (or so called 'HD') video.)
The curves can be altered to accept more user parameters, rather than just a contrast value, but won't be easy to configure.

1- I notice that there isn't a correction 'cause test patterns posted by James Freeman hasn't.Thave you tried the shader I posted? The color correction is extreme in that one. The shader should work as advertised. The settings used by James Freeman were mostly just conservative.2- I didn't write that to reproduce photoshop's one, but was an experiment to use a simple sin function to contrast chroma planes, I later adapted it for luma, and looks exactly the same, also is simple to manage for low mid and light part separately 'cause the nodal point in sin(0). Finally that was a merely example.The programming for the function itself is in a rather odd code format, but the base function should probably be fine.btw u said stuff like 16bit, 32bit (I think are for channel), but 24 bit... there is something that works in 24bit float? I hope u didn't mean 24bit RGB 'cause that are integers, 3 channels @8bit (while 32bit RGB add another channel, alpha).Older DirectX 9.0 compliant ATi GPUs had 24-bit floating point units for the pixel processing stages. For color processing in that era, the lower quantization didn't matter, as the buffers were generally poor quality anyway. All other DirectX 9.0 compliant (and onward) GPUs have standard 32-bit floating point units. Some even have 64-bit floating-point capabilities for special cases.For luminosity stuff, YV12 as video content generally are, is good enough, u only need to work on Y, also masktools works only in yv12 (maybe the lastest in YV16 and YV24 too) but all calculation are done in 32bit float.YV12 is already an abysmally poor quality format to begin with. Many videos still output 8-bit, 4:2:0 chroma down-sampled Y'CbCr color, so getting a buffer in the YV12 format isn't that odd. The main problem I have is with filters operating on the ancient Y'CbCr parts like as it contains a somewhat decent representation of color. I also find it inexcusable to implement filters that output on the common, but poor quality 8-bit per channel formats, unless the hardware really can't process any better. Good rendering means keeping quantization at at least good levels from the first operation up to the output stage. Also don't forget that the output stage itself is often times a negotiable format, too.off topic closed for me.Don't worry too much about slightly off-topic stuff. As long as it's audiovisual and/or software development related, it's good enough.

[madshi]

FWIW, madVR's "contrast" control already works by applying an S-curve to the gamma curve in linear light. However, James Freeman wanted something like an adjustable BT.1886 curve, which is quite a bit different (basically it takes into account the exact black level of the display).

[James Freeman]

James Freeman wanted something like an adjustable BT.1886 curve, which is quite a bit different (basically it takes into account the exact black level of the display).

All I wanted is a simple way to control the first few steps of the Greyscale without affecting the other steps above a certain threshold.

I got way more than what I wanted.

As for BT.1886 emulation,
I just lower the gamma for the first few steps, and add a little more to everything else.
The result is a nice deep image without crushed blacks.

Its not exactly a calibrated BT.1886 curve (I have an ICC for that),
but most of the time, it is a lot faster & more comfortable to change things "on the fly" than re-calibrate the display.
Besides, for low contrast displays the BT.1886 can be over-done, and have too elevated blacks.

I use the "Black Steps" from the AVS709HD disc, and tweak JanWillem32 gamma shader till I see the first steps (17-19) clearly,
without affecting steps 25 and above.

[leeperry]

Hi Jan, TYVM for the 3 section Gamma changer :)

You mention a forthcoming new PS script pack, any chance it would offer a HQ denoiser/MPEG deblocker and some sort of dynamic contrast thingie(much like DNIE (http://forum.doom9.org/showpost.php?p=1600258&postcount=15433))?

When I run my Sammy TV in 4:4:4 mode, only 60Hz is allowed(luckily mVR's FRC comes to the rescue) but no more denoiser/DNIE for me and both looked great(sadly 4:2:2 only) on Jinc3AR upscaled SD :o

[Raylan Givens]

Can Windows 8.1 decode AC3 audio natively? I mean the DTV-DVD decoder. Currently I've set both, DTV-DVD audio and video decoders as 'preffered' and it plays .mkv files without strange filters ( line21 or something, if my memory serves me correct ) showing in the filter list...

http://i2.minus.com/izTx4LYK7jPO4.png

[jebediah]

Since no one has answer or my question"See post 888" (http://forum.doom9.org/showpost.php?p=1648601&postcount=888)

What kind of graphic card do need then if a GT 520 doesn't do the work?
Would a GeForce GT 630 4GB do the trick?

[JanWillem32]

leeperry, I wrote several general denoise/deband shaders (even two recently). These won't deblock, though. Deblock is pretty much an integer transform dependent on the source video (and encoding). For AVC and VC-1 it's part of the standards, and deblock patterns are in the video source. For older codecs that do block transforms but don't have deblock in the standard, it's much harder to get it right. These are still by all means integer transforms unsuitable for any video renderer stage, and probably video mixer stage. Given the difficulty of analyzing/guessing where block artifacts happen, I'd say that this filter would be even hard to pull off if deblock would be handled in the decoder stages. At a minimum, the pattern, size and intensity of blocking would be required for a filter. The decoder does 'know' most of that, but that information isn't really available in the mixer and renderer stages.

I'm not even going to try writing a dynamic contrast filter. It's not a complicated transform, but it would require renderer support for a custom stage and I just don't like this kind of filter at all.

DNIE isn't a single filter. I recognized a variable colorfulness filter (I already wrote two), a dynamic gamma/dynamic contrast filter, a simple unsharp mask filter (several of these pre-date even my programming work) and frame interpolation (a complicated set of filters, mine are not that great (yet)).
The colorfulness filter may be somewhat compensated to avoid typical discoloration on skin tones (by setting red-versus-yellow (angle) and red-versus-cyan (complement) balances differently).

I guess you could try some pixel shaders and other renderer features to apply most of these effects, but let's put it this way: there are not that many video sources that will actually improve from all of these types and this amount of filters.

jebediah, I worked with worse GPUs and IGPs that could (just barely) render 1080p (just don't expect anything fancy from interlaced or high-frame rate video). Could you test the basic EVR, VMR-9 and overlay renderers in full screen mode with both Aero enabled and disabled? There could indeed very well be a difference in efficiency between the Windows XP and the Windows 7 drivers. If even the most basic renderers are too heavy on Windows 7, then it's probably that.

[hello_hello]

Since no one has answer or my question"See post 888" (http://forum.doom9.org/showpost.php?p=1648601&postcount=888)

What kind of graphic card do need then if a GT 520 doesn't do the work?
Would a GeForce GT 630 4GB do the trick?

My 8600GT does the work, so I'd assume a GT520 should (although I don't know anything about that card). However I had to fiddle with the PCI Express speed in the BIOS to stop the stuttering. Even if you're not overclocking it might be worth setting the PCI Express frequency manually if you can.
http://forum.doom9.org/showpost.php?p=1648111&postcount=880
Mostly for me, the stuttering didn't start until srt subtitles were enabled, but one particular CPU BUS Speed/PCI Express Frequency combination wouldn't allow me to play 1080p video without stuttering even without subtitles. For whatever reason, my second PC with the same MB/OS and video card doesn't suffer from the problem, but maybe it's also driver/OS related in a way I don't understand. Or Aero related in your case. I'm running XP.

[jebediah]

jebediah, I worked with worse GPUs and IGPs that could (just barely) render 1080p (just don't expect anything fancy from interlaced or high-frame rate video). Could you test the basic EVR, VMR-9 and overlay renderers in full screen mode with both Aero enabled and disabled? There could indeed very well be a difference in efficiency between the Windows XP and the Windows 7 drivers. If even the most basic renderers are too heavy on Windows 7, then it's probably that.

Believe me, i've tried every possible solution. VMR-7 works best, but the quality looks worse then my old VHS tapes, and this is both with Aero enable and disable. I can't really notice any different in GPU usage.

My 8600GT does the work, so I'd assume a GT520 should (although I don't know anything about that card). However I had to fiddle with the PCI Express speed in the BIOS to stop the stuttering. Even if you're not overclocking it might be worth setting the PCI Express frequency manually if you can.
http://forum.doom9.org/showpost.php?p=1648111&postcount=880
Mostly for me, the stuttering didn't start until srt subtitles were enabled, but one particular CPU BUS Speed/PCI Express Frequency combination wouldn't allow me to play 1080p video without stuttering even without subtitles. For whatever reason, my second PC with the same MB/OS and video card doesn't suffer from the problem, but maybe it's also driver/OS related in a way I don't understand. Or Aero related in your case. I'm running XP.

Yeah i know. My old rig that was a AMD Athlon 64 6000+ and a old ATi GPu did the work way better in XP 32 bit.

The PCI ex. is in auto in bios, but i can give it s try later on as soon my kid does to sleep.
Drivers doesn't matter, i've tried all the way back to a year old drivers for the graphic card.
Also i've tried to overclocked it via Afterburned with no success.

[hello_hello]

The PCI ex. is in auto in bios, but i can give it s try later on as soon my kid does to sleep.

Maybe it'll be a wild goose chase, but it can't hurt to at least try. I'll be curious to find out if it makes a difference.

[leeperry]

leeperry, I wrote several general denoise/deband shaders (even two recently).
OK, thank you for the detailed explanations.

I only saw some sharpening scripts with denoising in your big script pack (http://forum.doom9.org/showthread.php?t=157634) and the OP of this thread hasn't been updated since 2011, so where could I get ahold of those new denoising scripts of yours please? I need a proper denoising PS script pretty badly, J3AR scaling in mVR being merciless with subpar sources :o

[JanWillem32]

In the last few pages of that thread are a few new pixel shaders that deband/denoise. I also wrote a few custom types for XRyche on request afterwards.
As for subpar sources, resizers are built for ideal signal precision (infinite color quantization, no artifacts) at certain input and output resolutions. Sharper resizers and other resizers that do surface and edge detection will only make images worse that do not quite have such ideal signal precision. Improving a video source is possible, but very difficult. Filters that try to deband and remove noise are some of the most complicated and processing-intensive types I've ever written. There are also no miracle filters/resizers that will improve the visual resolution of the video source or display device.

[Reino]

I'm facing a weird problem with MPC-HC:
Journaal_03112013-1200.7z (http://www.mediafire.com/download/145v5qq1g70b1h9/Journaal_03112013-1200.7z)
This archive contains the adaptive segmented stream of a Dutch news broadcast. POW_00556598-audio_eng=192000-video=900000.ts is actually a m3u8-playlist renamed to ts, because as a ts-file ffmpeg and LAV Splitter Source will see the broadcast as one stream instead of 38 different segments. The playlist contains dynamic links.
LAV Splitter Source (in GraphStudioNext) and MPC-BE together with LAV Splitter Source can render the "ts-playlist" perfectly, but not MPC-HC. Only when I change the dynamic links to full links will MPC-HC play it. How come?