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 17th May 2016, 15:26   #38041  |  Link
_rEuTeL_
Registered User
 
Join Date: Jan 2004
Location: .be
Posts: 16
Hi madshi,

First of all thanks for all the good work
But could you please fix the bug with italic subs that breaks the 'move subs to bottom of the screen' option? It's the only issue I have with MadVR after months of use

Cheers
_rEuTeL_ is offline   Reply With Quote
Old 17th May 2016, 15:42   #38042  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 5,879
Quote:
Originally Posted by ionutm80 View Post
ReClock is only possible in x86 chain where indeed it allows me to have 1 frame drop every 4.xy hours, however I'm using everything in x64 ...

I know about smooth motion but that is frame blending and not frame interpolation. I kinda like SVP effect but this is a matter of taste.

My question towards more skilled people here is how close NVidia can be to 59.94? Because for me is 59.937. If I force everything at 1080p60 only in madVR I get 59.974 so I'm either below or above the target of 59.94. With Intel HD4400 I'm close to perfection 59.94006.
getting close to 59.94 is a waste of time you are still off to the audio clock.

if you want to stop repeating/dropping frames you have to match the audio clock.

the reason why intel has a "perfect" clock comes most likely from sharing the system clock with the video clock so they may have the same clock generator.

in the end it doesn't matter if the audio clock is different.

there are 3 clock in a system (maybe a lot more).
the system clock, the video clock and the audio clock.
the system clock is not really important in this case.

the clock deviation in madVR is important not the shown HZ.
huhn is offline   Reply With Quote
Old 17th May 2016, 15:54   #38043  |  Link
XMonarchY
Registered User
 
Join Date: Jan 2014
Posts: 489
Damn, the new De-Ringer is quite heavy on my GPU. I had to lower SuperRes to 1 in both Image Refinement and in Chroma Upscaling for 21:9 content when using NNEDI3 Image Doubling. Still, I think it is worth it. I assume these specific ringing stuff in mostly in older films that were upscaled from SD to HD?
__________________
8700K @ 5Ghz | ASUS Z370 Hero X | Corsair 16GB @ 3200Mhz | RTX 2080 Ti @ 2100Mhz | Samsung 970 NVMe 250GB | WD Black 2TB | Corsair AX 850W | LG 32GK850G-B @ 165Hz | Xonar DGX | Windows 10 LTSC 1809
XMonarchY is offline   Reply With Quote
Old 17th May 2016, 16:06   #38044  |  Link
ionutm80
Registered User
 
Join Date: May 2012
Posts: 57
Quote:
Originally Posted by huhn View Post
getting close to 59.94 is a waste of time you are still off to the audio clock.
if you want to stop repeating/dropping frames you have to match the audio clock.
Quote:
Originally Posted by Razoola View Post
Although reclock will make madvr report a better framedrop interval the value reported by madVR becomes invalid because reclock is constantly adjusting the audio so the framedrop never actually happens. Pity you are using x64, I keep 32bit just for reclock.
Ok, thanks for clarifying ... in fact what you both are saying is that w/o ReClock (only possible on x86 chain) I have no chance of having an accurate playback of 23.976 material on 60Hz screen even if I try to interpolate frames with SVP as close as possible to video clock because audio clock will not be synchronized, isn't it?
Are there any other methods except ReClock that would allow me to match the audio clock and still use everything in x64?
ionutm80 is offline   Reply With Quote
Old 17th May 2016, 16:24   #38045  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 5,879
Quote:
Originally Posted by ionutm80 View Post
Ok, thanks for clarifying ... in fact what you both are saying is that w/o ReClock (only possible on x86 chain) I have no chance of having an accurate playback of 23.976 material on 60Hz screen even if I try to interpolate frames with SVP as close as possible to video clock because audio clock will not be synchronized, isn't it?
Are there any other methods except ReClock that would allow me to match the audio clock and still use everything in x64?
creating an custom resolution that is close to the audio clock.

madVR smoothmotion will take care of this too.

the sanear audio renderer has a planned feature like reclock.
huhn is offline   Reply With Quote
Old 17th May 2016, 16:45   #38046  |  Link
ionutm80
Registered User
 
Join Date: May 2012
Posts: 57
Quote:
Originally Posted by huhn View Post
the sanear audio renderer has a planned feature like reclock.
Isn't this the backend for MPC-HC Internal Audio Renderer?
ionutm80 is offline   Reply With Quote
Old 17th May 2016, 16:50   #38047  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 5,879
Quote:
Originally Posted by ionutm80 View Post
Isn't this the backend for MPC-HC Internal Audio Renderer?
it is the new internal audio renderer in MPC-HC.
but this is a planned feature it is not implemented yet.
huhn is offline   Reply With Quote
Old 17th May 2016, 16:58   #38048  |  Link
Werewolfy
Registered User
 
Join Date: Feb 2013
Posts: 135
Quote:
Originally Posted by madshi View Post
Oh well, I suppose I'll have to check where the artifact is coming from. Maybe I can fix it. I don't think modifying the thresholds it very promising. Maybe as a last resort, if everything else fails. But I'd much prefer not having a strength setting. The visible difference would be very small and users wouldn't know which setting to use.
It would be great if you can get rid of this kind of artifact This issue happens each times a character smiles in this video.
__________________
Windows 8.1 x64 - Intel Core i5-4670K (4.2 GHz) - 8 GB DDR3 - MSI Geforce GTX 1080 8 GB - Sony KD-55A1
Werewolfy is offline   Reply With Quote
Old 17th May 2016, 18:28   #38049  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 1,130
Quote:
Originally Posted by huhn View Post
if you want to stop repeating/dropping frames you have to match the audio clock.

the reason why intel has a "perfect" clock comes most likely from sharing the system clock with the video clock so they may have the same clock generator.

in the end it doesn't matter if the audio clock is different.
The R9 380 in my HTPC outputs the /1.001 framerates very accurately. I effectively don't get dropped or repeated frames from that. madVR generally shows somewhere >4 hours for the time per drop/repeat. It drifts around a little, but I don't have any issues. So, it's not just Intel.
Stereodude is offline   Reply With Quote
Old 17th May 2016, 18:31   #38050  |  Link
ionutm80
Registered User
 
Join Date: May 2012
Posts: 57
Quote:
Originally Posted by Stereodude View Post
The R9 380 in my HTPC outputs the /1.001 framerates very accurately. I effectively don't get dropped or repeated frames from that. madVR generally shows somewhere >4 hours for the time per drop/repeat. It drifts around a little, but I don't have any issues. So, it's not just Intel.
Then only the green team has a problem in achieving a very accurate clock ???
ionutm80 is offline   Reply With Quote
Old 17th May 2016, 18:34   #38051  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 5,879
Quote:
Originally Posted by Stereodude View Post
The R9 380 in my HTPC outputs the /1.001 framerates very accurately. I effectively don't get dropped or repeated frames from that. madVR generally shows somewhere >4 hours for the time per drop/repeat. It drifts around a little, but I don't have any issues. So, it's not just Intel.
this is luck because the audio clock can be totally different from system to system.

my r9 270 has an pretty good looking clock too but it doesn't match the audio clock what so ever.
huhn is offline   Reply With Quote
Old 17th May 2016, 18:41   #38052  |  Link
DragonQ
Registered User
 
Join Date: Mar 2007
Posts: 930
Quote:
Originally Posted by madshi View Post
When that happens, simply drag & drop the new ID entry of the newly detected display to the original display. Afterwards you can remove the empty shell of the new display.
Thanks, I've done that for all 3 detected display IDs. We'll see if it happens again.
__________________
HTPC Hardware: Intel Celeron G530; nVidia GT 430
HTPC Software: Windows 7; MediaPortal 1.19.0; Kodi DSPlayer 17.6; LAV Filters (DXVA2); MadVR
TV Setup: LG OLED55B7V; Onkyo TX-NR515; Minix U9-H
DragonQ is offline   Reply With Quote
Old 17th May 2016, 23:54   #38053  |  Link
Warner306
Registered User
 
Join Date: Dec 2014
Posts: 1,122
Quote:
Originally Posted by Betroz View Post
@madshi, is there a way to compare super-xbr to NNEDI3 settings? Like super-xbr 100 gives the same image quality as NNEDI3 *** neurons?

It would be really nice to have some sort av list that compares the different settings, so people could have a general template to aim for according to the hardware capabilities their computers have.
All of the algorithms will give you a different image. There is no value of super-xbr that looks exactly like NNEDI3.

The chart below was made some time ago to compare the different algorithms. I have no idea if it is still accurate today. It compares each algorithm using its default settings:

Warner306 is offline   Reply With Quote
Old 18th May 2016, 00:06   #38054  |  Link
baii
Registered User
 
Join Date: Dec 2011
Posts: 180
There is not much reason to use x64 except you have problem with decoding performance, especially when reclock is needed. Madvr still does not benefit from x64 performance wise iirc?

Sent from my 306SH using Tapatalk
baii is offline   Reply With Quote
Old 18th May 2016, 00:41   #38055  |  Link
QBhd
QB the Slayer
 
QBhd's Avatar
 
Join Date: Feb 2011
Location: Toronto
Posts: 463
When I made the switch to Windows 10, I also made the switch to an x64 workflow (since AMD now has that nice Custom Resolution section). There was a nice little boost in performance and I could bump a setting or two up. Now was that a Windows thing or an x64 thing? If I get a chance late tonight I will test this since I'm considering going back to using Re-Clock.

QB
__________________
QBhd is offline   Reply With Quote
Old 18th May 2016, 01:41   #38056  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,213
Quote:
Originally Posted by XMonarchY View Post
Damn, the new De-Ringer is quite heavy on my GPU.
With just the first option ticked? It didn't make much of an impact on my 960 at all. What are you using?
ryrynz is offline   Reply With Quote
Old 18th May 2016, 02:43   #38057  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,213
Quote:
Originally Posted by aufkrawall View Post
Well, looking forward to your grain detection.
I think that would be a nice addition, but I have to wonder if perhaps some content might be slightly better served with a lower power dehaloing or perhaps a variation a little kinder to animation.
ryrynz is offline   Reply With Quote
Old 18th May 2016, 03:03   #38058  |  Link
zvans18
Registered User
 
zvans18's Avatar
 
Join Date: Jun 2015
Posts: 22
Quote:
Originally Posted by ryrynz View Post
With just the first option ticked? It didn't make much of an impact on my 960 at all. What are you using?
with 1080 movieed content on 1080 screen (nnedi3 16), it took a 12.xms average to ~15 with only first option on my 970

~33 to ~36 on 720 doubled and down to 1080, i could see needing to turn something lower if you're close to the edge
__________________
Windows 10 // i7-8700k + GTX 1080 SLI // MPC-BE x64 + LAV + XySubFilter

Last edited by zvans18; 18th May 2016 at 04:31.
zvans18 is offline   Reply With Quote
Old 18th May 2016, 08:41   #38059  |  Link
Betroz
Is this for real?
 
Betroz's Avatar
 
Join Date: Mar 2016
Location: Norway
Posts: 160
Quote:
Originally Posted by Warner306 View Post
All of the algorithms will give you a different image. There is no value of super-xbr that looks exactly like NNEDI3.

The chart below was made some time ago to compare the different algorithms. I have no idea if it is still accurate today. It compares each algorithm using its default settings:

Thanks for reply, but that was known to me
__________________
My HTPC : i7 6900K @ 4.2 | nVidia GTX 1080Ti | TV : Samsung 75Q9FN QLED
Betroz is offline   Reply With Quote
Old 18th May 2016, 09:03   #38060  |  Link
QBhd
QB the Slayer
 
QBhd's Avatar
 
Join Date: Feb 2011
Location: Toronto
Posts: 463
Quote:
Originally Posted by baii View Post
There is not much reason to use x64 except you have problem with decoding performance, especially when reclock is needed. Madvr still does not benefit from x64 performance wise iirc?

Sent from my 306SH using Tapatalk
So as I mentioned above, I just tested this out. I ran both the x64 and x86 workflows for playback to test this out. I used the same version of PotPlayer with the same settings, the same GPU Driver, the only difference between the workflows being ReClock on the x86.... I also used a file that was 720p60 ==> 1024x768 with maxed out settings, which pushes my GPU to 93% (so close to the edge that even enabling a chroma supres of 1 pushes it over the edge).

Both workflows were able to keep up without dropped frames. So in conclusion, with the playback pushing the GPU to the very edge, there is no difference between x86 and x64 workflows. One caveat, this does not take into consideration decoding of any 4k files. I understand that x64 helps in that regard, but madVR does not benefit from it from what I see.

QB
__________________
QBhd 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 14:36.


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