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 5th June 2011, 19:06   #7901  |  Link
e-t172
Registered User
 
Join Date: Jan 2008
Posts: 568
Many thanks madshi for this huge changelog

Anyway, I have some questions too:
- In "properties", "the display itself is calibrated to the following primaries / gamut", there is no sRGB option. Why? Some displays are calibrated for sRGB (e.g. PC monitors), not video standards.
- How do I know what the "native display bitdepth" is? I have a PC monitor with a TN panel, I'm assuming it is something like 6-7 bit, is there any way to know for sure? Also, what difference does it make?
- If I use an external 3dlut file for calibration, how does it interact with the options in the "properties" tab? Are the options in this tab disabled when using a 3dlut file? If they are, it would probably be best to make it known to the user, as it is quite confusing.
- In "color & gamma", "desired display gamma / transfer function", the default is "pure power curve". Wouldn't "BT.709/601 curve" be a better option, considering that's how video files are supposed to be encoded?

Last edited by e-t172; 5th June 2011 at 19:10.
e-t172 is offline   Reply With Quote
Old 5th June 2011, 19:16   #7902  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,463
Quote:
Originally Posted by madshi View Post
madVR v0.62 now let's you specify what color standard your display was calibrated to (default is BT.709, leave it at that if you're not sure).
If you mean primaries, it might be a good idea to rename them IMHO(and provide a hotkey to swap between them on the spot ):
BT.709(HD) = HDTV gamut
BT.601(SD) = SMPTE-C gamut
PAL = EBU gamut

Dumbing down those names will only make things more confusing to everyone I think...as we're talking about gamuts, and there's no 601/PAL gamut.

We'd still need BT.601 transfer function coeffs instead of the default BT.709 for upscaled SD(and that's where the automatic detection from ffdshow would rock). Still, you may wanna clear all this up IMHO...as the ppl who'll be messing w/ these options know what they're dealing w/.

Last edited by leeperry; 5th June 2011 at 19:20.
leeperry is offline   Reply With Quote
Old 5th June 2011, 19:24   #7903  |  Link
oddball
Registered User
 
Join Date: Jan 2002
Posts: 1,262
The seekbar still appears on the display showing the video when moving the mouse pointer to the bottom of the display NOT showing the video. Can we please have that fixed in 0.63? Pretty please?
oddball is offline   Reply With Quote
Old 5th June 2011, 19:25   #7904  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by fairchild View Post
I messed around with 3dlut for a bit since I own an i1Display2 LT and calibrated my plasma with colorHCFR, but since my meter is not the most accurate and the values/readings can vary a bit, I figured the benefit will not be that worthwhile in my case. The main reason I wanted to use it was for gamma boost, since my display has no gamma adjustment options and with yCMS I could boost the gamma closer to 2.22 from my sets 1.87

So basically with the new changes we only need to setup an hd 3dlut file and that will handle both the SD and HD conversions?
You will only need one 3dlut file, anymore. The one 3dlut file will cover NTSC, HD and PAL, with video and PC levels. The most comfortable way would be to let madVR create that 3dlut file for you. For that just on the "calibration" tab tell madVR to calibrate your display by using yCMS, then in the new "yCMS" tab edit the gamut and grayscale measurements and copy&paste the sections from your 3dlut configuration script there. The madVR settings dialog should accept the copy&paste directly.

Quote:
Originally Posted by Plutotype View Post
if my display is 16.7 million (6-bit + AFRC), then 8-bit should be chosen?
If your display is less than 8bit then configuring madVR accordingly should improve image quality for you. Practically it should noticeably reduce banding artifacts. I'd suggest using the "madTestPatternSource" filter with the supplied test patterns (especially colors.ytp) to find out which bitdepth settings works best for you. Set it as low as necessary to make the test patterns look good. Don't go lower than necessary, though, because that will increase visible noise.

Quote:
Originally Posted by Plutotype View Post
- display calibration. Gamut BT.709(HD), looks like a default
- display calibration. Gamma / transfer function - pure power curve / 2.20? Is this again a default setting ( correct setting )?
- color and gamma. Desired pure power curve / 2.20? Default?
These are the default settings. If you don't know what your display is calibrated to then simply leave the settings in the "properties" page at default. You can play with the "desired xxx" values, though. Maybe modifying them will improve image quality for you, depending on which kind of gamma response your display has. The "desired xxx" settings can also be switched via keyboard shortcuts (see changelog).

Quote:
Originally Posted by noee View Post
For some reason, my SD rips look better, even my wife noticed!
Interesting! Can you describe in which way it looks better? There should be a small improvement due to "gamut correction" (see my post with that title for more information), but I wouldn't have expected the improvement to be noticeably by "the wife"...

Quote:
Originally Posted by noee View Post
Two bugs from before...
- dual mon, playback on second mon, if I drag the mouse down to the bottom on the first mon, the seek bar shows
- dual mon, playback on second mon, Windows Key takes madVR out of FSE.
Yes, I'm aware of that. Didn't want to delay v0.62 any longer, the changelog was already so big...

Quote:
Originally Posted by leeperry View Post
OMG, the changes list is giving headaches
There should be several things in there you should like...

Quote:
Originally Posted by leeperry View Post
I'll run many tests again, but I'm afraid to really need that "upload frames in render thread" option on my XPSP3/8800GS combo
I'm still waiting for some clarifications on that topic. But your emails weren't very helpful in that regard.

Quote:
Originally Posted by noee View Post
I'm getting a crash with MC16. It is reproducible, but I think it might be jRiver's issue....

DUal mon
Play movie on second mon, using the Windows Task bar, using the MC icon hover control, stop the movie.
MC crashes in module madVR_unload

Can't get MPC-HC working right now, will try with it too.
That sounds like a crash in MC. Which doesn't necessarily mean it's MC's fault. But since the crash is in their module, they're in a better position to debug it.

Quote:
Originally Posted by robpdotcom View Post
It's really about time I get my display calibrated, so maybe this will press me to get that done.
Not sure if I would hire a calibrator right now. Maybe it would make sense to wait for madVR v1.0. There might still be bugs right now. Or there might come new features helping with calibration.

Quote:
Originally Posted by robpdotcom View Post
I recently started using an HTPC on my 1280x720 plasma in the bedroom, and was wondering if someone could recommend an algorithm for luma downscaling? I know everyone has their own preferences, but I'm just not sure where to start.
It's all a matter of taste. Trust your eyes.

Quote:
Originally Posted by e-t172 View Post
- In "properties", "the display itself is calibrated to the following primaries / gamut", there is no sRGB option. Why? Some displays are calibrated for sRGB (e.g. PC monitors), not video standards.
I'll ask yesgrey about that, he's the "expert" in that area.

Quote:
Originally Posted by e-t172 View Post
- How do I know what the "native display bitdepth" is? I have a PC monitor with a TN panel, I'm assuming it is something like 6-7 bit, is there any way to know for sure? Also, what difference does it make?
Telling madVR that your display is 7bit means that madVR applies a twice as high dither strength to make sure you get no banding artifacts. See this post a couple comments above for some recommendations about this topic.

Quote:
Originally Posted by e-t172 View Post
- If I use an external 3dlut file for calibration, how does it interact with the options in the "properties" tab? Are the options in this tab disabled when using a 3dlut file? If they are, it would probably be best to make it known to the user, as it is quite confusing.
Yes, if you calibrate with an external 3dlut file or with the integrated yCMS GUI the gamut and gamma options in the "properties" tab are ignored. I should probably gray them out in this situation.

Quote:
Originally Posted by e-t172 View Post
- In "color & gamma", "desired display gamma / transfer function", the default is "pure power curve". Wouldn't "BT.709/601 curve" be a better option, considering that's how video files are supposed to be encoded?
This has been a long standing discussion. My personal opinion is that by far most ISF calibrators are calibrating displays to a pure power curve. CRTs have a pure power curve, too. Poynton agrees with this. One common opinion is that the BT.709 gamma curve was used mainly to hide sensor noise and that the display is not *supposed* to use a BT.709 gamma curve, too. I believe that makes a lot of sense since BT.601 and BT.709 were created when we only had CRTs which always had a pure power response. Some people have a different opinion, though. So the choice is yours. But the default is the same for the "properties" and "color & gamma" tabs so that with the default settings madVR doesn't do any gamma changes. I think it would be a bad idea to have the default settings make madVR modify gamma in any way.

Anyway, play around with the "desired" gamma settings and let me know which you prefer. There are keyboard shortcuts to change these settings on the fly (see changelog).
madshi is offline   Reply With Quote
Old 5th June 2011, 19:27   #7905  |  Link
alph@
Replicant
 
alph@'s Avatar
 
Join Date: Jan 2007
Location: strasbourg
Posts: 49
madshi, i have this,in avi uncompressed ,I hope it's good. http://www.mediafire.com/?4bx1xlx668r6kza
leepery,we will wait for OLED technology.i have a sony 46hx 700,the contrast is very good for a lcd display.

Last edited by alph@; 5th June 2011 at 20:34.
alph@ is offline   Reply With Quote
Old 5th June 2011, 19:31   #7906  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by leeperry View Post
If you mean primaries, it might be a good idea to rename them
The settings read "the display itself is calibrated to the following primaries / gamut". I think that's as clear as it can get. I don't see a need to rename that.

Quote:
Originally Posted by leeperry View Post
and provide a hotkey to swap between them on the spot
No. We're talking about telling madVR how your display *itself* is calibrated. That's an information that will not change between movies, because movies have nothing to do with how your display is calibrated by itself. What you may want is a hotkey to swap/toggle the *source detection*, and in case you missed it, that hotkey was just introduced in v0.62. Maybe you should try v0.62 before making further suggestions.

Quote:
Originally Posted by leeperry View Post
We'd still need BT.601 transfer function coeffs instead of the default BT.709 for upscaled SD
Start testing v0.62. Come back after you tested it. Please no further comments until you tested v0.62.
madshi is offline   Reply With Quote
Old 5th June 2011, 19:32   #7907  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,949
Quote:
Originally Posted by SamuriHL View Post
madshi, are there any commercial decoders out there that support proper 16bit FourCC that will work with the next version of madVR?
i know @ least 1 you can get for free that supports v210 Cineforms Decoder

Edit: Ahh sorry 10 bit not 16 at least i didn't have any v216 material to test :P
__________________
all my compares are riddles so please try to decipher them yourselves :)

It is about Time

Join the Revolution NOW before it is to Late !

http://forum.doom9.org/showthread.php?t=168004

Last edited by CruNcher; 5th June 2011 at 19:38.
CruNcher is offline   Reply With Quote
Old 5th June 2011, 19:36   #7908  |  Link
noee
Registered User
 
Join Date: Jan 2007
Posts: 530
Quote:
Interesting! Can you describe in which way it looks better?
Sharper image, more subtle color detail. I'm using a rip of Jeremiah Johnson for comparison, it's a nasty source (but a great movie!). There is a scene where Redford is helping put the door back on a cabin after an attack and you see it in the color of his trousers.

Also, in Star Wars (a new hope), in the hangar scene with the Falcon, the little lights in the background on the wall by the door are clearer, more vivid.
noee is offline   Reply With Quote
Old 5th June 2011, 19:38   #7909  |  Link
SamuriHL
Registered User
 
SamuriHL's Avatar
 
Join Date: May 2004
Posts: 4,269
Quote:
Originally Posted by CruNcher View Post
i know @ least 1 you can get for free that supports v210 Cineforms Decoder
Hmm. Maybe I'll check it out at some point. Thanks.

Quote:
Originally Posted by CruNcher View Post
Edit: Ahh sorry 10 bit not 16 at least i didn't have any v216 material to test :P
Oh sure.
__________________
HTPC: Windows 10, I9 9900k, RTX 2070 Founder's Edition, Pioneer Elite VSX-LX303, LG C8 65" OLED
SamuriHL is offline   Reply With Quote
Old 5th June 2011, 19:42   #7910  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by alph@ View Post
madshi, i have this,in avi uncompressed ,I hope it's good.
Yes - thanks!

Quote:
Originally Posted by noee View Post
Sharper image, more subtle color detail. I'm using a rip of Jeremiah Johnson for comparison, it's a nasty source (but a great movie!). There is a scene where Redford is helping put the door back on a cabin after an attack and you see it in the color of his trousers.

Also, in Star Wars (a new hope), in the hangar scene with the Falcon, the little lights in the background on the wall by the door are clearer, more vivid.
Interesting, thanks for the description. I think it's probably caused by the change in chroma upsampling. Older versions upsampled chroma with the soft algorithm directly from source resolution to target resolution. madVR v0.62 now upsamples chroma always by 2x with the soft algorithm, then uses the Luma algorithm to scale the whole RGB (luma + chroma) to the target resolution. That might help color resolution for SD content a bit, while still keeping aliasing down.
madshi is offline   Reply With Quote
Old 5th June 2011, 19:52   #7911  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,949
so the next release gonna support the 4 letters ?
__________________
all my compares are riddles so please try to decipher them yourselves :)

It is about Time

Join the Revolution NOW before it is to Late !

http://forum.doom9.org/showthread.php?t=168004
CruNcher is offline   Reply With Quote
Old 5th June 2011, 20:02   #7912  |  Link
janos666
Registered User
 
Join Date: Jan 2010
Posts: 460
Quote:
Originally Posted by nevcairiel View Post
First we would need material thats actually encoded like this. 99.9% of all content is 8 bit these days.
Wouldn't the 10/16 bit connection (between the decoder and renderer) be useful with 8-bit source materials too (like it is theoretically useful to output float32 from the DTS decoder, even though it's a 16-bit track)?
Aren't there any rounding(/dithering?) steps during the decoding?
janos666 is offline   Reply With Quote
Old 5th June 2011, 20:02   #7913  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by CruNcher View Post
so the next release gonna support the 4 letters ?
Of course. I'll name v0.63 "LOVE", just for you. Or is that not the 4 letters you meant?
madshi is offline   Reply With Quote
Old 5th June 2011, 20:03   #7914  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,949
DXVA Surface speed test:
__________________
all my compares are riddles so please try to decipher them yourselves :)

It is about Time

Join the Revolution NOW before it is to Late !

http://forum.doom9.org/showthread.php?t=168004
CruNcher is offline   Reply With Quote
Old 5th June 2011, 20:08   #7915  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by janos666 View Post
Wouldn't the 10/16 bit connection (between the decoder and renderer) be useful with 8-bit source materials too (like it is theoretically useful to output float32 from the DTS decoder, even though it's a 16-bit track)?
Aren't there any rounding(/dithering?) steps during the decoding?
Good question, but I think the video decoders work differently compared to lossy audio decoders. Lossy audio encoders convert to time domain which is a conversion which results in floating point data. That's why decoding lossy audio codecs results in floating point data. Video decoders work very differently, so I guess they don't produce floating point output by design. However, 10/16 bit connection can still make sense for professional use (studios, encoding houses etc). Furthermore, if you have some kind of processing before madVR (e.g. avisynth) it would definitely be beneficial to not have to downconvert the data to 8 bit in the middle of the processing chain.

Maybe someday someone will create a DirectShow splitter + decoder for www.RED.com content? That would be high bitdepth. They have a free SDK available, but I don't have the time to work on that, unfortunately.
madshi is offline   Reply With Quote
Old 5th June 2011, 20:20   #7916  |  Link
janos666
Registered User
 
Join Date: Jan 2010
Posts: 460
Why can I select 10-bit as native display bit depth if it doesn't really output 10-bit?
Is it there for later versions with 10-bit output capability or did you think that it changes anything with 8-bit output if the display is theoretically capable of more?
Or should it work and the problem is on my side?
janos666 is offline   Reply With Quote
Old 5th June 2011, 20:23   #7917  |  Link
e-t172
Registered User
 
Join Date: Jan 2008
Posts: 568
Quote:
Originally Posted by madshi View Post
Good question, but I think the video decoders work differently compared to lossy audio decoders. Lossy audio encoders convert to time domain which is a conversion which results in floating point data. That's why decoding lossy audio codecs results in floating point data. Video decoders work very differently, so I guess they don't produce floating point output by design.
Lossy audio decoders convert to time domain using the iDFT (inverse Discrete Fourier Transform), which is a floating point transform. AFAIK, lossy video decoders use the iDCT (inverse Discrete Cosine Transform) which is also a floating point transform. I don't see why one would benefit from floating point processing and not the other.
e-t172 is offline   Reply With Quote
Old 5th June 2011, 20:32   #7918  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,793
Video decoders often use fixed-point optimized iDCT approximations to increase speed at a minimal quality loss.
I'm sure some video decoder pro can explain it properly, but video decoders just don't work like that. They output the same pixel format that was fed in. If it would be beneficial to increase bitdepth on output, i'm sure someone would've come up with the idea before..
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 5th June 2011, 20:53   #7919  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by janos666 View Post
Why can I select 10-bit as native display bit depth if it doesn't really output 10-bit?
Is it there for later versions with 10-bit output capability or did you think that it changes anything with 8-bit output if the display is theoretically capable of more?
It was meant for future versions, I should probably remove it now and only allow 6bit, 7bit and "8bit or higher". The net effect if you switch this option to 9bit now is that the dithering noise will be cut in half, which will re-introduce a tiny amount of banding, since output is still at max 8bit. So setting it to more than 8bit is currently not a good idea.

Quote:
Originally Posted by nevcairiel View Post
Video decoders often use fixed-point optimized iDCT approximations to increase speed at a minimal quality loss.
I'm sure some video decoder pro can explain it properly, but video decoders just don't work like that. They output the same pixel format that was fed in. If it would be beneficial to increase bitdepth on output, i'm sure someone would've come up with the idea before..
I've been told that the h264 spec is so strict that decoders are expected to output bit identical results. Not bit identical to the original source, of course, but bit identical compared to other decoders. I don't have the knowledge to confirm or deny this information, but if it's true then that pretty much says that floating point output would not be an improvement for h264 at least. I've also heard that MPEG2 is different and there decoders seem to have slightly different output results. So maybe for MPEG2 having floating point output would make sense. I've no clue, though.
madshi is offline   Reply With Quote
Old 5th June 2011, 21:01   #7920  |  Link
JarrettH
Registered User
 
Join Date: Aug 2004
Posts: 838
So do you have to change the BT space depending on the video you playback now? I just use EVR-CP for DVDs, but everything else with madvr varies

Last edited by JarrettH; 5th June 2011 at 21:13.
JarrettH 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 17:26.


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