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. |
6th June 2011, 13:22 | #7961 | Link | |
Registered User
Join Date: May 2004
Posts: 5,351
|
Quote:
On that one file it is. I checked a couple other DVD->MKV's that I have and they don't do it. Just Empire Strikes Back. This wasn't happening before. Let me know what I can do to help on this one and I'll see if I can find some time.
__________________
HTPC: Windows 11, AMD 5900X, RTX 3080, Pioneer Elite VSX-LX303, LG G2 77" OLED |
|
6th June 2011, 13:41 | #7963 | Link | |||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Can you send another log where madVR actually manages to switch from a different mode to 1080i59? Quote:
Quote:
Can you try cutting this file down to a very small sample? If the crash still occurs with the small sample, it might help me reproduce & fix the problem. |
|||
6th June 2011, 13:44 | #7964 | Link | |
Registered User
Join Date: Jan 2007
Posts: 530
|
Quote:
|
|
6th June 2011, 13:47 | #7965 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Use the default settings, but change the "gamut / primaries" setting on the display "properties" page to "something else". That will make madVR not touch the RGB32 output. IMHO doing that is not correct, though. You will not get correct colors this way if you e.g. play SD video on your HD display. |
|
6th June 2011, 13:48 | #7966 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Unfortunately for crashes the madVR debug log usually doesn't help much (though if we're extremely lucky maybe this is an exception, you never know). Much better would be for me to get a sample with which the crash is 100% reproducable.
|
6th June 2011, 13:53 | #7967 | Link |
Registered User
Join Date: Jan 2010
Posts: 479
|
If I tell madVR that these are my supported display modes: 1080p23, 1080p24, 1080p25, 1080p29, 1080p30, 1080p50, 1080p59, 1080p60, 1080i29, 1080i59 then it switches to 1080p29 for 1080i30 BD materials (it could be correct if there would be a deinterlace filter in the graph which produces 29.97 progressive frames). And the result is very bad as madVR doesn't really deinterlace anything (yes, I know that it's not a bug but a missing feature with very low or zero priority witch I understand...)
If I disable auto-switching and manually set 1080i30Hz from the AMD CCC (which is interlaced 60.00Hz according to the madVR OSD) then the TV seems to understand it and correctly deinterlace it. Well, at least for a few seconds until something looses the sync and the video starts to jag like hell. It gets back to work if I pause the playback for some seconds. So I tried to fill my display modes line with this: 1080i29, 1080i59 and madVR now switches to interlaced 59.941Hz (said by madVR OSD) for 1080i30 materials (29.970fps according to the source filter). And the TV still understand it and apply deinterlace. But it didn't solve the sync problem, it still starts to jag after a few seconds. I am not sure if it's madVR or the TV which looses the sync but I guess it's madVR (why the pause/play cycle would help the TV? and the TV streams from coax work well...). I am using the D3DFS mode and I tried to tick the DX11 presentation and a very strange thing happened: madVR switches to interlaced 50.00Hz now (for the same 1080i30 material). So, I removed anything but 1080i59 from madVR's list and it still switches to interlaced 50Hz (and the same thing happens if I keep 1080i29 only)! Last edited by janos666; 6th June 2011 at 14:13. |
6th June 2011, 13:53 | #7968 | Link |
Registered User
Join Date: May 2004
Posts: 5,351
|
Yea, it might take a little bit. I've got some video editing to do on that machine. I'll try to get you a sample later today. Knowing my luck, cutting the file down will fix it and not repro it.
__________________
HTPC: Windows 11, AMD 5900X, RTX 3080, Pioneer Elite VSX-LX303, LG G2 77" OLED |
6th June 2011, 13:58 | #7969 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,348
|
If all you do is check media types, then that information is sadly not present. There are the "dwInterlaceFlags" in VIH2, however many decoders always set them even on progressive content, and set the actual type of the frames on the sample properties.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
6th June 2011, 14:06 | #7970 | Link | |||||||||||
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
Quote:
Edit: As I noted below, it may be nice to have a "Custom" option which you could specify arbitrary values as well. Quote:
If "Something Else" means disabled in the properties page, could you add a "Something Else" to the Color & Gamma page as well. That would be less confusing (when you plan to set input=output), even if it does nothing different than setting Pure-power 2.2 there. Just to confirm, the following both imply gamma correction is disabled and will have identical behavior? Properties (pure-power 2.2) -> Color & Gamma (pure-power 2.2) Properties (something else) -> Color & Gamma (pure-power 2.2) Properties (inverse 2.2) -> Color & Gamma (inverse 2.2) Properties (pure-power 2.35) -> Color & Gamma (pure-power 2.35) Edit: Does madVR assume the 3dlut is a 2.2 power-curve, meaning these last two will do something? Would this have different behavior with shaders-only vs using a 3dlut? Edit2: Thinking about this a bit, it may make sense to link changes to the Property page gamma to the Color & Gamma page. In other words, default to input=output gamma when a change is made to the Property page. At which point if someone wanted to apply a gamma adjustment, they could make the necessary change in the Color & Gamma page. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
I see it as a bug as well, but yesgrey doesn't. He purposefully clips input to limited-range in his presets since fullrange videos are rare. You needed to explicitly specify input is full-range when creating a 3dlut. With the previous YUV->RGB 3dluts, you needed three different ones to support all types of videos. YUV (16-235 clipped) -> RGB (0-255) Input_Format HD YCbCr 8 Output_Format HD RGB_PC 16 YUV (16-235 clipped) -> RGB (16-235) Input_Format HD YCbCr 8 Output_Format HD RGB_Video 16 YUV (0-255) -> RGB (0-255) Input_Format HD YCbCr 8 Input_Range 0 255 Output_Format HD RGB_PC 16 Quote:
The problem still remains that you can create a 3dlut which conflicts with the madVR shaders. If a user is used to creating a 3dlut manually and doesn't realize this, they could make similar assumptions as I did, causing madVR to apply gamma corrections both with the 3dlut and shaders. Optimally madVR should support 3dlut only, shaders only, and 3dlut + shaders. Maybe adding a drop-down menu to pick your desired mode would be the best solution. Quote:
Supporting all these things is all well and good, but it should be more obvious how to make madVR meet your needs, especially for someone unfamiliar with such things and aren't very tech-savvy. That gamma itself is relative could lead to trouble for users. Unless you are fully aware of the properties of your display and set everything correctly, the output gamma specified in madVR would never match the output gamma you actually see. A common example is if a display has a flawed power-curve gamma or an arbitrary gamma which doesn't match the scaling of the Rec709/601 shader logic. Changing gamma with in such cases will cause undesired behavior, since madVR would be making inaccurate assumptions about the properties of the display. On another note, if you can now do Rec709/Rec601/PAL gamut adjustments in madVR, how difficult would it be to add custom gamut measurements to by applied by shaders? That would allow someone with a meter to take advantage of this new shader functionality more accurately, when not using a 3dlut. I imagine it would be trivial to support if you already have the framework in place. Quote:
Last edited by cyberbeing; 6th June 2011 at 14:55. |
|||||||||||
6th June 2011, 14:06 | #7971 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Can I have a log from that, too? |
|
6th June 2011, 14:13 | #7972 | Link |
Registered User
Join Date: Jan 2010
Posts: 479
|
I filled the modes line with this: 1080p23, 1080i50, 1080i59 (It covers all my need after all...)
BD with 1080p24 works (of course, they always worked from the bigging of the auto-switch) HDTV streamrip with 1080i25 works without any deinterlace or sync problems (well, I let it run for a minute) BD with 1080i30 works for a few seconds Ok, I will try to capture a log. |
6th June 2011, 14:14 | #7973 | Link |
Registered User
Join Date: Sep 2004
Posts: 1,295
|
Some possible bugs:
-after activating and selecting the external 3DLUT file for one of the displays, when activating the external 3DLUT file for the other it by defaults uses the same file from the other display. IMHO it should appear blank. -In the calibration->yCMS tab the grayscale measurements edit button is disabled. It only is enabled after filling up the gamut measurements. I think both should be enabled. -The Gamut_Measurements are not being accepted through copy/paste. The save button keeps disabled. |
6th June 2011, 14:45 | #7974 | Link |
Registered User
Join Date: Jan 2010
Posts: 479
|
I used these settings: 1080p23, 1080i50, 1080i59 and the situation is the same with DX11: 1080i30_madvr_log.rar
|
6th June 2011, 15:18 | #7975 | Link | |||||||||||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
Quote:
Ok, I can see that this might be confusing overall. I'll try to improve on that. Maybe I can add an option "don't process" or something like that to the "color & gamut" option and use that as default. Quote:
I think the new concept is good and I don't really see any disadvantage in having the 3dlut input side strictly defined. If you see any disadvantages of that (in real life), please let me know. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
What exactly do you understand as "Input" in this context, btw? It is not clear to me. Why would the "Properties" page be "Input"? Do you mean input into the display? Or input into madVR? Or input into yCMS? Or input into the 3dlut? I don't think marking the "Properties" page as "input" would be of any help. It wouldn't help myself, at least, because I don't see the connection between "Properties" and "input". Quote:
Quote:
Works for me. Can you post the exact text you've copy/pasted here for me to test with? |
|||||||||||||||
6th June 2011, 15:27 | #7976 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
|
|
6th June 2011, 15:44 | #7977 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,348
|
IMS2::GetProperties
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
6th June 2011, 16:26 | #7978 | Link | ||
4:2:0 hater
Join Date: Apr 2008
Posts: 1,302
|
Quote:
What you call "the truth" is what ffdshow RGB32 outputs, or what Fraps lossless outputs, for example. These 2 decoders output RGB32. Why do I think that this output should not be touched? Because both of them compute the RGB32 frames using the correct matrices for 601/709, SD/HD, levels, etc. They do (in ffdshow you can configure it, Fraps is always 709/PC range) what you do in madVR when feeded with YV12, so their RGB32 output is comparable to the RGB32 output of madVR to the graphics card. Processing in madVR is a bad idea, because it'll redo everything, messing up colors, levels, gamma, etc. as it does right now. The most interesting effect happens with the levels setting. My monitor is a PC monitor, so 0-255 of course. When PC levels is selected in madVR the videos are double expanded: by ffdshow/fraps (because they assume no further conversions will be done) and then by madVR, yet I'm telling madVR the truth, my monitor is PC range. This option doesn't have a "something else" setting, so I have to lie to madVR and tell it my monitor uses TV range to get proper levels. RGB32 is a format that is intended to be displayed as-is, unless video renderers do something to the image that I'm not aware of before displaying it. Yet again, RGB32(ffdshow)->EVR and YV12->madVR look the same here (not counting the difference in processing quality of course) in both SD and HD. So I really think your processing should be disabled for RGB32/24, or at least you should offer an option to do so. On a side note, in MPC-HC you can tell EVR your monitor's output range, and it does work when EVR itself does the YCbCr->RGB conversion. However, if you feed EVR with RGB32 the setting will have no effect, like it should be. Quote:
|
||
6th June 2011, 17:34 | #7980 | Link |
Registered User
Join Date: May 2011
Posts: 16
|
madVR works great, not sure if already mentioned. But a few feature requests.
1) an option to disable reinit on display, this way i can drag between dual monitors without it glitching. 2) an option to set the amount of seconds that it goes in to exclusive mode, from four to any number. 3) dxva support, but only if the seek remains as good as it is now. 4) volume control to go with the cool seekbar. |
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
|
|