MPC-HC vs. TMT3 comparison pictures [Archive]

View Full Version : MPC-HC vs. TMT3 comparison pictures

THX-UltraII

11th October 2009, 09:31

Kurtnoise

11th October 2009, 10:17

you compare oranges and peaches, I'd say : not the same decoder, are you sure that TMT3 uses the same renderer ?...

and the last but not least, pictures don't show the same frames.

shiloto

11th October 2009, 16:42

diffrence is very small. Only way to see it is to compare directly images. I dont see any problem. You should concetrate more on the movie,and less on the pixels

THX-UltraII

12th October 2009, 06:37

the screenshot comes from my projector but youre right that people with wrong /not cal. monitors may get wrong information.

However, I found out something last night:

I made some more screenshots and found out that it all has something to do with bt.601/bt.709. When I use Haali renderer in MPC-HC or TMT3 I get the exact same results. When I use VMR9 or EVR as renderer in MPC-HC I get the 'other' result. By accident I enabled the BT.601 -> BT.709 shader in MPC-HC. After enabling this shader I get the exact same result as in TMT3 and MPC-HC/Haali. I also see that in the Haali renderer you can choose Auto,bt.601 and bt.709 in the YUV Colorspace settings of the renderer. The default settings .601 gives the same result as TMT3. However, switching to auto or .709 gives the same result as MPC-HC/EVR or VMR-9 WITHOUT the use or the shader.
So which one off the settings is right......

Jong

12th October 2009, 13:03

As soon as I read your first post colorspace conversions came to mind. Well done for finding it.

If you let the renderer resize as required you do not need to do any special conversions - Haali set to "auto". if you upscale before the renderer sees it eg. in ffdshow then you have to explicitly convert bt.601 -> bt.709 IF you are upscaling SD to HD. You can do this with ffdshow "presets".

Basically SD uses a different colorspace to HD. The renderer normally (always in the case of EVR/VMR, in "auto" mode for Haali) decides if a conversion is needed based on the resolution of the input it receives. If you upscale before it gets to the renderer and have not performed colorspace conversion at the same time it makes the wrong choice - it thinks it has an HD source, in fact it is an SD source.

THX-UltraII

12th October 2009, 13:17

Jong, I don t really understand what your saying :stupid:

You talk about resize, but I don t do resizing (I only did this in the standard def. era where it was good to resize x2). Also I don t use ffdshow for video anymore and I use the interal
H264/AVC decoder of MPC-HC.

What I would like to know is which one is right:

SCREENSHOT 1:
http://img44.imageshack.us/img44/1196/btmt1.png

OR

SCREENSHOT 2:
http://img515.imageshack.us/img515/7241/ampc1.png

Screenshot 1 seems a little greenish and screenshot 2 more blue. I already found out that it all has something to do with the .601 and .709 settings but I don t know which screenshot is 'right'.

Here are the results (all with the same 1080p .mkv file):
- Total Media Theater 3: SCREENSHOT1
- MPC-HC EVR with BT.601 -> BT.709 shader: SCREENSHOT1
- MPC-HC VMR9 with BT.601 -> BT.709 shader: SCREENSHOT1
- MPC-HC EVR without shader: SCREENSHOT2
- MPC-HC VMR9 without shader: SCREENSHOT2
- MPC-HC with Haali Renderer and YUV Colorspace on the Default BT.601: SCREENSHOT1
- MPC-HC with Haali Renderer and YUV Colorspace on BT.709: SCREENSHOT2

Jong

12th October 2009, 17:50

Of course I did not know the source file has 1080p when replying before. The most common cause of problems is upscaling, as I described, but clearly not in this case!

TMT and MPC-HC using EVR/VMR9 with no tweaks should agree.

It is impossible to say from a screen shot which is "right" or why the two do not agree.

- Most likely MPC-HC has some other tweak being applied that is messing things up

- Also possible TMT has a bug (I don't use it)

- Also possible the file has been badly encoded and TMT is reacting to that ("normally" renderers ignore info in the file and instead go on the resolution of the video. I do not know what TMT does; I would expect the same but who knows!)

So first I would use a known source like AVS HD: http://www.avsforum.com/avs-vb/showthread.php?t=948496

- Do TMT and MPC-HC with no tweaks agree using one of the supplied color test bars? If they do it was the file that was the problem.

- If they still disagree try a player you have not tweaked, like VLC or even WMP (if you are sure no wacky filters are loading). If WMP and TMT agree but MPC-HC is different try deleting all the MPC-HC registry entries and restarting from scratch.

- Look in the TMT forums to see if others are having problems.

But basically TMT and EVR in MPC-HC should agree with no need to resort to shaders. Solve that problem and you will be there.

Mark_A_W

13th October 2009, 08:51

601 = SD

709 = HD

Use the right one.

Mercury_22

13th October 2009, 10:14

I ve made some comparison pictures between MPC-HC (1299) and TMT3 (.160) and found out that they let me view a movie different. It seems to me that TMT3 seems a little greenish while MPC-HC has more blue. Which one is giving me the correct picture and what causes this difference?

My setup:
Windows7 with latest DirectX
ATI HD4350 with 9.9 driver
no hardware acc. in both MPC-HC or TMT3
EVR Custom with MPC-HC
in MPC-HC the internal H264 / AVC (non-hardware acc.) decoder

The media used was a full, non quality lost, BR rip

Here are the links to the 24-bit images that I captured

MPC-HC:
http://img515.imageshack.us/img515/7241/ampc1.png

TMT3:
http://img44.imageshack.us/img44/1196/btmt1.png

MPC-HC:
http://img94.imageshack.us/img94/732/cmpc2.png

TMT3:
http://img44.imageshack.us/img44/7145/dtmt2.png

What do you mean by BR rip ? TMT it's known to have wrong "Black levels" ( e.g. http://www.arcsoft.com/forum/forum_posts.asp?TID=2987 )
(At least) for me TMT it's using different "Black levels" when I play a BR folder or disc than when I play the m2ts file inside !
On the other hand MPC-HC (EVR and EVR CP tested) it's clipping the whites and the blacks if I use ATI AVIVO's default settings ( = "Use Application Settings" ) BUT WITH DYNAMIC CONTRAST DISABLE !!!
What's strange is that with the AVIVO's defaults ( = "Use Application Settings" ) BUT WITH DYNAMIC CONTRAST DISABLEWindows Media Center it's NOT clipping
My settings in AVIVO'S "Basic Color" to avoid clipping in MPC-HC (EVR CP) are Brightness = 2 and Contrast = 97 !
You can find more info here http://www.videoessentials.com/dvehd/index.html ( Pluge w/ Gray Scale and Reverse Gray Ramp w/Steps chapters )

P.S. If I use "Dynamic Contrast" in avivo MPC-HC it's NOT clipping anymore ( with all the other settings to defaults = "Use Application Settings" ) BUT the black and white levels are very unstable and wrong = I can't calibrate them

Jong

13th October 2009, 10:26

The problem he is describing is a colorspace issue, not a black level/contrast issue.

Mark_A_W

13th October 2009, 10:51

But the debacle that is levels issues is the reason why you should not use DXVA.

Use madVR and take control of your levels. They should remain unmolested with black at 16 and white at 235.

Mercury_22

13th October 2009, 11:29

The problem he is describing is a colorspace issue, not a black level/contrast issue.

The media used was a full, non quality lost, BR rip so more likely it's a black level
But...

But the debacle that is levels issues is the reason why you should not use DXVA.

Use madVR and take control of your levels. They should remain unmolested with black at 16 and white at 235.

On a Solid state display you should be able to go beyond Video black ! It's your calibration that should be done at video black and white otherwise it's clipping Don't take my word for it read the doc from http://www.videoessentials.com/dvehd/index.html

Why is there dynamic range below black in the video signal?
Before we go on to additional test patterns, let’s address the issue of going below black and why
that capability should be on all source and video processing devices.
The idea of needing to go below black is centered on the capability of the CRT as a display
device. Its flat field uniformity wasn’t good. The broadcast specification for a standard
definition monitor was no more than a 25% difference in brightness over the entire surface of the
image. It has always been difficult to achieve that specification is a monitor larger than 20
inches diagonal. This is the reason broadcast monitors were never larger.
In the standard definition world of consumer sets, larger sizes meant even worse flat field
uniformity, often time being more than 50% different in one place versus another on the CRT.
With such large variation in light output, depending on where you were on the screen, it was
actually difficult to set black level. It’s part of the reason we decided the PLUGE had to be large
and be place in more than one area of the screen. You set black level for some average of the
picture area. There are still parts of the picture where information below black can be seen so
that part of the video signal is used in program production. If there is a hard clip at black, detail
around black will be cut out. It will suddenly go flat. If that area of the picture is above black on
the set it will look as if the detail is being cut out.

P.S. From my tests (MPC-HC with) DXVA decoder or nonDXVA it's not changing anything. See my "setup" below

Jong

13th October 2009, 11:43

so more likely it's a black level
Black level does not affect color. And he has done test that show changing the colorspace assumption makes the different players/renderers agree.

Mercury_22

13th October 2009, 12:02

Black level does not affect color. And he has done test that show changing the colorspace assumption makes the different players/renderers agree.
You're correct Black level does not affect color but from the images he posted and from my own experience (and others) with TMT the problem it's with the black levels . See my link and many other post in the arcsoft's forum about wrong black levels !

But if he has done test which are showing for sure it's the standard (BT.601 or BT.709) than ... I'm wrong

Jong

13th October 2009, 12:59

Just look at the images with something like Photoshop. Black is black in both images. If one or other were not expanding it would be clear.