Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 13th December 2012, 10:11   #16241  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by SyrupBuccaneer View Post
Does madVR officially support screenshots/image capture as of latest?
Yes.

Quote:
Originally Posted by SyrupBuccaneer View Post
Because I'm using Potplayer and the output for every image I try to capture is roughly 5-7 frames ahead of what should be captured.
Is that while the video is running? Or while the video is paused? While the video is running it is possible that the capture is a bit ahead of what is currently on screen. But while the video is paused you should really get the frame which is visible on screen. At least that's how it's supposed to be.

Quote:
Originally Posted by corporalgator View Post
I've read through a lot here, but I just wanted to make sure I have my settings right. Under CCC I have pixel format to RGB Full, and on my panasonic plasma, HDMI is set to non-standard which it says is 0-255. Under Madvr, I have it set to PC Levels. With test patterns, blacks and whites are clipped below 16 and above 235. Is that how everything should be set up?
Sounds good to me. You do lose the values < 16 and > 235 this way, but these values are not supposed to be seen on screen, anyway, so it's not a big loss. You could also set your plasma to standard HDMI range and madVR to 16-235. That should be roughly identical in image quality for madVR playback, while preserving < 16 and > 235 data. But if you do that, your desktop and photos etc will have wrong black/white levels.

Quote:
Originally Posted by leeperry View Post
ah well, Seb.26 actually says on HCFR that this levels conversion script is "low quality" "incorrect" and "buggy", hurray!
Why is he saying that? Ok, MPC-HC performs shaders in 8bit by default, I think, and cuts BTB and WTW. But that does not apply to madVR. The formula used by that script looks alright to me on a quick look. It converts TV to PC, though, so it's the opposite of what you want.

Quote:
Originally Posted by leeperry View Post
And do you think it would be preferable to use the gamut mapping PS script before or after scaling?
It doesn't matter at all, IMHO.

Quote:
Originally Posted by leeperry View Post
And what's your take on scripts that would be better used in either of those two positions(apart from deinterlacing, that should obviously be used before)?
Removing source artifacts (de-ring, de-noise, de-band) before scaling. Sharpening and detail enhancement etc after scaling.

Quote:
Originally Posted by Mangix View Post
When you first released madVR with DXVA2 support(decoding and scaling), you mentioned a chroma blur that happens with native and not with copyback. I have no idea if that's still the case. Many changes have been made to the code since then, including the SSE4.1 copyback speedup(which I can't take advantage of) as well as various fixes. I don't know the tradeoffs that are made today when using DXVA2 scaling/decoding. Well, other than DXVA2 scaling is useless on nvidia hardware.
Well, that's all kinda a moving target since I'm still shifting the code around atm, and things could change in the near future again. But I can write up the current situation as part of the next release (so it's easier to find).

Quote:
Originally Posted by pururin View Post
The point is for NTSC a bit complicated ones, those aspect ratio discrepancies are too low (less than 1% of the real AR) to be worry about already. Most, if not all, human can't tell that very small difference without side-by-side comparisons. And If you live in Europe or watch many PAL DVDs you don't have much to worry already. Others than those should be quite straightforward to see and choose one way over the other.

Have users adjust frame scaling/cropping would be too troublesome, it's more like an encoder work. Just having few options that suitable for real-world situation would be much more practical I think.
But what options would that be exactly?
madshi is offline   Reply With Quote
Old 13th December 2012, 10:32   #16242  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
Quote:
Originally Posted by madshi View Post
Unfortunately a debug log doesn't help if madVR crashes. Did you get a madVR crash box? If so, please make the bug report available to me.
I see one, but just for a short moment, somehow the box disappears very quickly. No chance to click anything.
aufkrawall is offline   Reply With Quote
Old 13th December 2012, 10:40   #16243  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by 6233638 View Post
Even simpler, display the seekbar whenever a video is paused in FSE?
That's not possible currently cause that would confuse the MPC-HC internal subtitle renderer. I'm already blocking MPC-HC's "Pause" OSD message so subtitles don't disappear if video is paused. These problems should go away when using the new subtitle interface, but we're not there yet...

Quote:
Originally Posted by dansrfe View Post
madVR is crashing on me with the latest release. Using latest MPC-HC and LAV with DXVA2 native decoder.

Steps to reproduce crash:

1 -> Resize window up/down

2 -> Drag to second screen.
Quote:
Originally Posted by aufkrawall View Post
Sometimes madVR crashes for me with this build when entering FSE and changing display mode.
Debug log:
http://www.mediafire.com/?c330yb82plip6ig
I found a bug which could result in crashes when using native DXVA decoding in certain situations. The fix for that might solve these two crashes.
madshi is offline   Reply With Quote
Old 13th December 2012, 10:44   #16244  |  Link
Prinz
Registered User
 
Join Date: Jul 2011
Posts: 83
Quote:
Originally Posted by madshi View Post
With LAV? A madVR debug log might help.
Found the reason. In Zoomplayer DirectVobSub will be loaded with the non-working files and that courses the fall back to software decode. Files that don't have a subtitle track work in Zoomplayer too.
Prinz is offline   Reply With Quote
Old 13th December 2012, 11:04   #16245  |  Link
hannes69
Registered User
 
Join Date: Nov 2012
Posts: 99
(1) Use software decoding and e.g. Bilinear scaling.
(2) Use native DXVA2 decoding and e.g. Bilinear scaling.
(3) Use software decoding and DXVA2 scaling.
(4) Use native DXVA2 decoding and DXVA2 scaling.

Redone the test with 0.85.3:
Same behaviour like 0.85.2.
(1), (3) and (4) are the same, (2) is different (oversaturated green). So using native decoding without dxva scaling is still broken (at least for my setup).
hannes69 is offline   Reply With Quote
Old 13th December 2012, 11:41   #16246  |  Link
alizard
Registered User
 
Join Date: May 2012
Posts: 9
Madshi, levels are now incorrect using 85.3 with dxva scaling and mpc-hc internal decoder and splitter. Blacks are now grey. Other scaling methods provide proper levels. I'm using the old path exclusive without overlay on an Amd card.
alizard is offline   Reply With Quote
Old 13th December 2012, 12:01   #16247  |  Link
chros
Registered User
 
chros's Avatar
 
Join Date: Mar 2002
Posts: 2,323
Huge performnace bug with pixel shaders from v0.85.2

I have accidently realized that there's a huge performance issue since v0.85.2 (v0.85.1 is OK) when I using post resize pixel shader (sharpen complex 2) in mpc-hc on my laptop (720p content upscaled to 1680*xxx).

test (using nvidia inspector):
- v0.85.1: MCU usage: 19%, GPU usage: 53%
- v0.85.3: MCU usage: 30%, GPU usage: 78% (!!!!)

If I disable post resize shaders in mpc-hc, everything is the same between the 2 builds (or 0.85.3 is even slightly better).

I you need more info, just ask ...

Thanks
__________________
Ryzen 5 2600,Asus Prime b450-Plus,16GB,MSI GTX 1060 Gaming X 6GB(v398.18),Win10 LTSC 1809,MPC-BEx64+LAV+MadVR,Yamaha RX-A870,LG OLED77G2(2160p@23/24/25/29/30/50/59/60Hz) | madvr config
chros is offline   Reply With Quote
Old 13th December 2012, 12:11   #16248  |  Link
toniash
Registered User
 
Join Date: Oct 2010
Posts: 131
@leeperry
Quote:
There's only very slight issue, though...it's that post-scaling PS scripts seem to be processed pre-
So pre and post are interchanged or all run in pre?
toniash is offline   Reply With Quote
Old 13th December 2012, 12:37   #16249  |  Link
pandy
Registered User
 
Join Date: Mar 2006
Posts: 1,049
Quote:
Originally Posted by madshi View Post
It's not that easy for computer stuff, though. The problem is that the Windows desktop is always renderes in Full Range. So if you GPU has to output Limited Range, it has to post-process the Windows output. And that costs image quality, especially if it's done without dithering (and I think it usually is done with dithering). That's why having the GPU output limited range over HDMI is actually a bad thing for us HTPC users.
Then signal Full Quantization Range in AVI InfoFrame - HDMI Sink shall understand this and shall use 0 - 255 quantization range. Only RGB colorspace shall be used for Full Quantization Range. Or perhaps force HDMI to DVI mode then only 0 - 255 RGB is allowed.

Quote:
Originally Posted by madshi View Post
But still the question remains: Maybe any resolution between 702 and 720 is *possible*, but which is used most often in real life? If 90% of the ITU scaled content is using 702, then it would be worth it offering an option for that exact aspect ratio. But if ITU scaled content is all over the place, then it doesn't make sense to offer such an option. So what we need is not necessarily a proper interpretation of the specs, but instead we need to check how this is done in real life.
If we use digital sources (i mean MPEG-2, H.264) then choice is quite simple 704 and 720 pixels, 702 - 716 problem affect only analog capture sources and knowledge about capture device is required to understand real number of pixels in captured source. This purely source/display dependable relation - to be precise we need to know what timing is used by grabber and what timing is used by display. Without this everything will be educated guess.
pandy is offline   Reply With Quote
Old 13th December 2012, 13:02   #16250  |  Link
hannes69
Registered User
 
Join Date: Nov 2012
Posts: 99
Some experience with calibration:
I use a ColorMunki Display colorimeter to calibrate my Infocus X9 720p DLP projector. First I used the parameters inside the projector for basic calibration. "Nice": my projector has brightness/contrast/gamma setting in menu but no color gain/offset controls. I had to construct a serial 9pin to 3pin cable to get to the "hidden" greyscale controls by using a com console... So first setting white and black point with AVS test patterns. Bar 17 barely visible. Then I set greyscale with projector settings, readjusted blackpoint. Then I used Argyll/dispalGUI to build an ICC file. I get perfect 2.2 gamma, flat RGB niveau (< 2 deltaE for IRE>20) says HCFR. But now bar 17 and 18 are lost in black point test pattern. To see them again I have to lower gamma setting in madvr to 2.0. The outcoming is consistent to my viewing experience: I watch Breaking Bad series , there are many "dark scenes" like camera viewing from inside back of a car direction front to the dashboard. The instruments there are black, black detail is lost with gamma 2.2. And that in a scene with daylight. Thats not real life experience, sitting in a car with daylight you see the instruments. By lowering gamma to 2.0 it is a little bit better but not completely realistic. Many recommend a gamma of 2.4 for homecinema. I watch in a dim room (no light), with gamma 2.4 there´s a great loss of shadow detail. What´s the reason behind that experience? Probably poor contrast (my Infocus gets 900:1 in HCFR)?
Furthermore I tried yCMS capabilities. I think it does what it is supposed to do: the corners of my CIE lay on the 709 CIE triangle sides. So there are no more outofgamut colors, but the price to pay is a srewed up greyscale. It´s not totally screwed but getting worse (greyscale steps pattern is tinted). I think I´ll stay with perfect greyscale, primaries/secondaries stay within <15 deltaE, that´s not ideal but ok for me. I´m not perfectly into that materia, maybe yesgrey can improve that (he´s working on yCMS 2.0 regarding his thread).
I tried different methods, typing in my measured values to madvr-ycms setting, gamut alone or gamut+greyscale, and I tried the method of building a 3dlut file out of the icc. All methods work (cutting out of gamut colors) but influence negatively greyscale.
Beside that a calibrated picture looks great, it was worth the effort.
hannes69 is offline   Reply With Quote
Old 13th December 2012, 13:07   #16251  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by hannes69 View Post
(1) Use software decoding and e.g. Bilinear scaling.
(2) Use native DXVA2 decoding and e.g. Bilinear scaling.
(3) Use software decoding and DXVA2 scaling.
(4) Use native DXVA2 decoding and DXVA2 scaling.

Redone the test with 0.85.3:
Same behaviour like 0.85.2.
(1), (3) and (4) are the same, (2) is different (oversaturated green). So using native decoding without dxva scaling is still broken (at least for my setup).
Thanks, will double check here. Could you upload a short debug log, nevertheless, just in case I can't reproduce it here?

Quote:
Originally Posted by alizard View Post
Madshi, levels are now incorrect using 85.3 with dxva scaling and mpc-hc internal decoder and splitter. Blacks are now grey. Other scaling methods provide proper levels. I'm using the old path exclusive without overlay on an Amd card.
Which exact OS, GPU and driver version? Can you please also upload a short debug log?

Quote:
Originally Posted by chros View Post
I have accidently realized that there's a huge performance issue since v0.85.2 (v0.85.1 is OK) when I using post resize pixel shader (sharpen complex 2) in mpc-hc on my laptop (720p content upscaled to 1680*xxx).

test (using nvidia inspector):
- v0.85.1: MCU usage: 19%, GPU usage: 53%
- v0.85.3: MCU usage: 30%, GPU usage: 78% (!!!!)

If I disable post resize shaders in mpc-hc, everything is the same between the 2 builds (or 0.85.3 is even slightly better).
v0.85.1 stored custom pixel shader results in 16bit integer video levels. That's the internal data format madVR uses for temp buffers in its render pipeline, so I didn't have to do any funny conversions. However, VMR9 and EVR always ran pixel shaders in PC levels. So v0.85.3 now converts the internal madVR data to PC levels before running the custom pixel shaders. And since I don't want to lose BTB and WTW, I can't use 16bit integer textures, either, so the pixel shader passes are stored to 32bit float textures. The levels conversions and the 32bit float textures are probably causing the higher load on your GPU. I guess I could add another "trade quality for performance" option to only use 16bit float textures instead of 32bit float. That might restore *some* of the lost performance, on the cost of ever so slightly less precision. But it will most probably not get back to v0.85.1 performance levels.

Quote:
Originally Posted by pandy View Post
Then signal Full Quantization Range in AVI InfoFrame - HDMI Sink shall understand this and shall use 0 - 255 quantization range. Only RGB colorspace shall be used for Full Quantization Range. Or perhaps force HDMI to DVI mode then only 0 - 255 RGB is allowed.
Yes, that would be the ideal solution.

Quote:
Originally Posted by pandy View Post
If we use digital sources (i mean MPEG-2, H.264) then choice is quite simple 704 and 720 pixels, 702 - 716 problem affect only analog capture sources and knowledge about capture device is required to understand real number of pixels in captured source. This purely source/display dependable relation - to be precise we need to know what timing is used by grabber and what timing is used by display. Without this everything will be educated guess.
FWIW, I've just accidently looked at my h264 header parser. It has a few custom aspect ratios. E.g. there is "16:11 720x576 16:9 frame with horizontal overscan". If I do the math, this specific aspect ratio ends up with 1047x576. Which happens to be the exact resolution 704 pixels would end up with. So I guess 704 pixels seems to be the "magic" number here for ITU scaling? If I follow the ARs defined in the h264 spec, I would end up with the following resolutions:

PAL 4:3 - 785x576
PAL 16:9 - 1047x576
NTSC 4:3 - 655x480
NTSC 16:9 - 873x480


I could offer this as an "ITU Aspect Ratio" option, in case madVR gets PAL/NTSC content with non-ITU 4:3 or 16:9 Aspect Ratios. Objections, anyone?
madshi is offline   Reply With Quote
Old 13th December 2012, 13:46   #16252  |  Link
omarank
Registered User
 
Join Date: Nov 2011
Posts: 187
for adding the double/ triple expanded source levels toggle. I have two questions regarding the way madVR handles video levels:

1. If I increase say Black Level of source from 0 to +1, madVR changes the video levels by 0.5 (I guess) for regular content. Now if I change the Black level to +1 in case of a 10 bit content, will madVR change the video levels by 0.5 only or by 2 (=0.5*1023/255)?

2. If I switch to double expanded source levels while playing a 10 bit content, what levels are considered then?
omarank is offline   Reply With Quote
Old 13th December 2012, 13:52   #16253  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
The black/white level controls always change exactly one step in 8bit. The visible change is the same for 8bit and 10bit sources, so for 10bit sources, increasing source black level from 0 to +1 results in a change of 4.
madshi is offline   Reply With Quote
Old 13th December 2012, 13:54   #16254  |  Link
TheShadowRunner
Registered User
 
TheShadowRunner's Avatar
 
Join Date: Feb 2004
Posts: 399
I notice something strange with the screenshot feature.
Not using DXVA at all and playing a movie, when I take a screenshot it's much darker than what's on the screen,
My TV expects 16-235 so that's what I set in madVR. The movie is also encoded in limited range and the decoder outputting in YV12.
But it seems the screenshot feature expands to PC levels? (black crush)
I'm pretty sure old builds didn't have this issue..
I don't use color controls either on the player (ZP) or in madVR.
__________________
XP SP3 / Geforce 8500 / Zoom Player
TheShadowRunner is offline   Reply With Quote
Old 13th December 2012, 14:02   #16255  |  Link
omarank
Registered User
 
Join Date: Nov 2011
Posts: 187
Quote:
Originally Posted by madshi View Post
The black/white level controls always change exactly one step in 8bit. The visible change is the same for 8bit and 10bit sources, so for 10bit sources, increasing source black level from 0 to +1 results in a change of 4.
OK, thanks for the clarification.
omarank is offline   Reply With Quote
Old 13th December 2012, 14:03   #16256  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by TheShadowRunner View Post
I notice something strange with the screenshot feature.
Not using DXVA at all and playing a movie, when I take a screenshot it's much darker than what's on the screen,
My TV expects 16-235 so that's what I set in madVR. The movie is also encoded in limited range and the decoder outputting in YV12.
But it seems the screenshot feature expands to PC levels? (black crush)
I'm pretty sure old builds didn't have this issue..
I don't use color controls either on the player (ZP) or in madVR.
BMP, JPG, PNG etc are usually always 0-255, so that's what madVR produces for screenshots.
madshi is offline   Reply With Quote
Old 13th December 2012, 14:09   #16257  |  Link
TheShadowRunner
Registered User
 
TheShadowRunner's Avatar
 
Join Date: Feb 2004
Posts: 399
Quote:
Originally Posted by madshi View Post
BMP, JPG, PNG etc are usually always 0-255, so that's what madVR produces for screenshots.
Oh.. could we have a feature to grab exactly the source color range then?
When I use the ffdshow grab feature, or change madVR to VMR9 and use also ZP to make a screenshot, the resulting image is exactly what's on screen (PNG).
It's strange, I could have sworn madVR used to take exactly what's on screen in previous builds. ^^;
__________________
XP SP3 / Geforce 8500 / Zoom Player
TheShadowRunner is offline   Reply With Quote
Old 13th December 2012, 14:14   #16258  |  Link
iSunrise
Registered User
 
Join Date: Dec 2008
Posts: 496
Quote:
Originally Posted by madshi
FWIW, I've just accidently looked at my h264 header parser. It has a few custom aspect ratios. E.g. there is "16:11 720x576 16:9 frame with horizontal overscan". If I do the math, this specific aspect ratio ends up with 1047x576. Which happens to be the exact resolution 704 pixels would end up with. So I guess 704 pixels seems to be the "magic" number here for ITU scaling? If I follow the ARs defined in the h264 spec, I would end up with the following resolutions:

PAL 4:3 - 785x576
PAL 16:9 - 1047x576
NTSC 4:3 - 655x480
NTSC 16:9 - 873x480


I could offer this as an "ITU Aspect Ratio" option, in case madVR gets PAL/NTSC content with non-ITU 4:3 or 16:9 Aspect Ratios. Objections, anyone?
IMHO, the whole ITU and non-ITU topic is already confusing the hell ouf of the majority of people which are using madVR. It will be used very rarely, if at all.

It certainly wouldn't hurt to offer it as an option, since I own about 800 DVDs (the majority is in NTSC format) I would like to give this a try myself. But I am not sure if I can even see a huge difference and if I want to go into the settings every time to change it.

Last edited by iSunrise; 13th December 2012 at 14:27.
iSunrise is offline   Reply With Quote
Old 13th December 2012, 14:55   #16259  |  Link
hannes69
Registered User
 
Join Date: Nov 2012
Posts: 99
Originally Posted by hannes69
(1) Use software decoding and e.g. Bilinear scaling.
(2) Use native DXVA2 decoding and e.g. Bilinear scaling.
(3) Use software decoding and DXVA2 scaling.
(4) Use native DXVA2 decoding and DXVA2 scaling.

Redone the test with 0.85.3:
Same behaviour like 0.85.2.
(1), (3) and (4) are the same, (2) is different (oversaturated green). So using native decoding without dxva scaling is still broken (at least for my setup).

Here the debug log: http://netload.in/dateixaiGwJat9z/madVR-log.rar.htm
Log created by using case (2). Hoping that helps

Last edited by hannes69; 13th December 2012 at 15:17.
hannes69 is offline   Reply With Quote
Old 13th December 2012, 16:16   #16260  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by madshi View Post
Why is he saying that? Ok, MPC-HC performs shaders in 8bit by default, I think, and cuts BTB and WTW. But that does not apply to madVR. The formula used by that script looks alright to me on a quick look. It converts TV to PC, though, so it's the opposite of what you want.
Yep, I would guess that the major issue with VMR9/EVR is indeed that BTB/WTW aren't preserved as you said

But I've got quite a lot of work ahead of me creating a dozen automatic gamut mapping profiles in PotP, so I don't plan on bothering with this script when a mere hotkey in mVR can do exactly what I want

Quote:
Originally Posted by pururin View Post
Having users manually adjust frame scaling/cropping would be too troublesome
Well, I've got many different kinds of sources: VHS encodes, old and new PAL and NTSC DVD's, sloppy uncropped encodes....it's very easy when using a 4:3 display to stretch the picture horizontally in order to completely fill the screen, but it's a whole different story with 16/9 coz you never know where the 4:3 width actually stands and I'm afraid there will never be a "one size fits all" magic bullet to this issue

madshi didn't seem to like my idea of a 4:3 placeholder so I'll try to look into my options writing my own script, yay....no more whining, actions

I just want something like yellow rectangles in the 16/9 outer portions so I could clearly see the 4:3 limits =)

MPC provides hotkeys for pan & scan and I made my own pan & scan helper in PotP, so horizontal stretching really only takes me a few clicks:

Quote:
Originally Posted by toniash View Post
pre and post are interchanged or they all run in pre?
they're all pre atm, a bugfix is in the works

Last edited by leeperry; 13th December 2012 at 16:19.
leeperry is offline   Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 06:19.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.