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. |
14th July 2016, 14:19 | #38701 | Link |
Registered User
Join Date: Sep 2009
Posts: 43
|
Yes but that assumes the hue angle is obtainable at the desired saturation location. This may not always be the case if for example you are mapping P3 primaries down to Rec709 primaries. In that case you have to vary all three to find the best dE-based compromise, because out-of-gamut now can involve the wrong hue, saturation and luminance.
|
14th July 2016, 14:23 | #38702 | Link | |
Registered User
Join Date: Jan 2014
Posts: 216
|
Quote:
Any idea why it does the same thing in D3D11 FSE after pausing the video and Windows screen saver activates? This happens with all files not just 30 fps. Should I just ignore the stats as long as I don't visually see stuttering? Last edited by StinDaWg; 14th July 2016 at 14:25. |
|
14th July 2016, 14:42 | #38703 | Link | |
Registered User
Join Date: Apr 2016
Posts: 17
|
Quote:
Ok, just did a quick test again with display modes turned off for tv and monitor resolution dropped down to 1080p when using dp or hdmi connection to make it more fair comparison. Now I'm not sure what to make of it. With display modes turned off for TV and using hdmi or display port with monitor, FSE produces no issues and all ques are filled up with presentation times looking normal. turning display modes on for TV produces above mentioned glitch. Next thing I did is left only 1080p60 in display modes plus turned them on for monitor. Having display modes on or off for monitor produced no issues with FSE using either hdmi or display port connection. Meanwhile TV even with display mode of 1080p60 produces glitches in FSE but with it turned off and running at same 1080p60 has no issues. To make sure there is no bandwidth limitation or multi-monitor issues, I had one device connected at a time to video card and used same cable for hdmi connection. This is really weird and I'm not sure this is even same issue StinDaWg experiencing, if this is an issue at all and nothing more then just random amd driver glitches Last edited by ShiftyFella; 14th July 2016 at 14:48. |
|
14th July 2016, 15:16 | #38704 | Link | |
Registered User
Join Date: Sep 2014
Posts: 280
|
Quote:
Is there a player which supports madvr fse mode while using a gui osd? If so, which one is it? A player with support for madvr fse d3d11 (for 10 bit output) and a good skinnable gui would be great...
__________________
Intel i5 6600, 16 GB DDR4, AMD Vega RX56 8 GB, Windows 10 x64, Kodi DS Player 17.6, MadVR (x64), LAV Filters (x64), XySubfilter .746 (x64) LG 4K OLED (65C8D), Denon X-4200 AVR, Dali Zensor 5.1 Set |
|
14th July 2016, 15:42 | #38705 | Link | |
Registered User
Join Date: Jun 2015
Posts: 25
|
Quote:
So for example: madvr gets frame packed 3d material at 47.952 Hz. What I would like to be able to do is: split the right and left frames and send them one after the other at 95.904 Hz to the TV as conventional 2d frames. |
|
14th July 2016, 15:55 | #38706 | Link | |||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
Quote:
Quote:
It's also not really all that simple to implement this feature. If audio and video run out of sync, I'll need to drop a frame. Usually I only drop one frame. But with frame sequential output I'd have to make sure I always drop 2 frames, so the eye order doesn't swap. Why do you need this? Does your TV not support frame packed 3D? |
|||||
14th July 2016, 18:27 | #38707 | Link | |
Registered User
Join Date: Dec 2002
Posts: 1,022
|
Quote:
Same source, GPU etc. but with EVR: plays perfectly, CPU usage 2-5% EVR doesn't support HDR output to HDR TV either. |
|
14th July 2016, 19:00 | #38708 | Link | |
Registered User
Join Date: Jun 2016
Posts: 39
|
Quote:
https://drive.google.com/file/d/0By8...ew?usp=sharing And if you don't mind may I also upload another log file later for you to take a look? I cannot seem to play frampacked 3d properly either. My TV detects the 3D signal but the image output is still in 2D |
|
14th July 2016, 20:52 | #38709 | Link | |
Registered User
Join Date: Jan 2008
Posts: 589
|
Quote:
(Generating that 3DLUT in a reasonable amount of time, on the other hand, could prove challenging. collink for example can take a while to run. Waiting such a long time on playback start could be annoying. However it might be possible to make the process much faster by making a few reasonable performance tradeoffs. Graeme would probably know a lot more about this, since he wrote this stuff.) By the way, I see we've come full circle in this discussion, we're back to discussing the use of DeltaE which I already suggested 7 pages back. There was some talk about using CAM02-SCD as well. I believe the main reason why you were not very enthusiastic about this idea was because calculating dE94 or dE2000 is done in CIELAB, which goes against the ICtCp trend that you mentioned. Maybe there is a robust color difference formula that can be used in ICtCp somewhere? (By the way: if you look at the DeltaE formulas themselves, you might notice that the problem of minimizing dE94 can be rephrased in 3D space as finding the closest point that is within the gamut volume in the CIELAB system of coordinates. Maybe that could help, especially considering this is done on a GPU? My math skills are not good enough to allow me to elaborate I'm afraid.) Last edited by e-t172; 14th July 2016 at 21:03. |
|
14th July 2016, 21:22 | #38710 | Link | |||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
> DXGI_STATUS_OCCLUDED if you request full-screen mode > and it is unavailable Whatever that means. I don't think there's much I can do about it. Quote:
I suspect all these problems are caused by Optimus. I don't really know how to help there, unfortunately. Quote:
Quote:
We're now discussing using dE just to find a decent compromise between losing saturation vs losing luminance, while keeping the hue angle constant. That significantly simplifies the math. Although I'm still not sure how to do the math right now. |
|||||
14th July 2016, 21:54 | #38711 | Link | ||
Registered User
Join Date: Jan 2008
Posts: 589
|
Quote:
Quote:
Last edited by e-t172; 14th July 2016 at 21:56. |
||
14th July 2016, 22:08 | #38712 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
|
|
14th July 2016, 22:34 | #38714 | Link | |
Registered User
Join Date: Jan 2008
Posts: 589
|
Quote:
I agree that still doesn't address the issue of calculation time though. However, I would still argue that decreasing 3DLUT accuracy would be a good tradeoff for solving that problem. After all, every color-managed application does this, and they don't suffer from accuracy problems. Argyll even has a tool, profcheck, that verifies the agreement between interpolated values from an ICC profile's cLUT and the original, full-precision measured values. If you can verify that the difference is less than 1 dE, it's unlikely anyone would be able to notice the difference. |
|
14th July 2016, 22:43 | #38715 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Granted, doing it in YCbCr or ICtCp would be more reasonable. But I still think calculating the 3dlut offline would take much too long. And I don't really see the advantage right now: The math I'm using now works just fine. Except for this one specific problem, and I'm not sure right now how to solve it mathematically, either offline or online. Once I know how to solve it, it's probably possible to do it online, too. So why do it offline? It would cost many hours extra work, delay playback start, have less precision. I simply see no reason why I should do that.
|
14th July 2016, 22:55 | #38716 | Link |
Registered User
Join Date: Jan 2008
Posts: 589
|
Sure, this is all mostly speculation It's a matter of processing budget, though. Say you have an algorithm or some math formula that, given an input color X, gives you the best output color Y to map to. Say this algorithm takes 4µs to complete for each color. There's no way to do this in realtime for every pixel of every frame, but it would only take 1 second to generate a 64x64x64 3DLUT using that algorithm.
|
14th July 2016, 23:04 | #38717 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Ok, but GPUs are massively parallel, while CPUs are not. If the algo takes 4µs per color per thread on the CPU, then with a quad core CPU it would actually only take 0.25 seconds to calculate a 64^3 3dlut. However, a GPU doesn't calculate just 4 colors at once, but hundreds or thousands at once (not sure how many). So even if the GPU needs 4µs per color, because of the massive parallel calculation, the algo would still run in real time without any problems. But I'd say 4µs on the CPU is very optimistic. It'd probably be much slower than that.
|
14th July 2016, 23:11 | #38718 | Link | |
Registered User
Join Date: Dec 2013
Posts: 753
|
Quote:
|
|
14th July 2016, 23:16 | #38719 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Good question. I was thinking of using either CIEDE2000 with all the hue stuff removed (which should bring it near to CIE94, I think), or straight CIE94. Alternatively, there's a dE formula available in the first google link for the search term "de color difference ipt". In any case, my plan was to stick to constant hue.
|
14th July 2016, 23:49 | #38720 | Link |
Registered User
Join Date: Jun 2011
Posts: 288
|
Anyone else having problems with Pascal GPU (1070,1080) getting the proper P-state when using Madvr in mpc-hc or mpc-be? I can't seem to make it happen actually. I've observed this by using several programs, and GPU-z confirms the speeds are reduced.
Setting "Prefer maximum power" in the Nvidia control panel doesn't make any difference. I've tried to use DDU and reinstall the latest drivers without any effect. Could anyone else test the built-in graphics test in GPU-z and watch the clock speeds, and then compare it to when you run a full screen video with madvr? Noticeably the RAM speed is reduced.
__________________
SETUP: Win 10/MPC-HC/LAV/MadVR HARDWARE: Fractal Design Node 804 | Xeon E3-1260L v5 | Supermicro X11SSZ-TLN4F | Samsung 2x8GB DDR4 ECC | Samsung 850 EVO 1TB | MSI GTX 1650 Super | EVGA G2 750 |
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
Thread Tools | Search this Thread |
Display Modes | |
|
|