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 18th July 2015, 16:34   #31921  |  Link
Shiandow
Registered User
 
Join Date: Dec 2013
Posts: 752
Quote:
Originally Posted by madshi View Post
Technically not possible, I think. SuperRes works by comparing the upscaled image to the original. In Image Enhancement this comparison would result in zero differences, so SuperRes would not have anything to do. Would you could do is upscale, then apply SuperRes, then downscale again. But that would consume *A LOT* of resources.
In principle you could just blur the image, instead of downscaling it. This basically means that SuperRes will assume that the original image is a blurred version of the 'actual' image, and SuperRes will then try to recover the 'actual' image. Not too sure if this is any better than a normal sharpener though.
Shiandow is offline   Reply With Quote
Old 18th July 2015, 16:34   #31922  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,494
Quote:
Originally Posted by madshi View Post
Are you by any chance using the "old windowed mode" (meaning you have present several frames in advance unchecked in the windowed mode settings)?
Quote:
Originally Posted by sneaker_ger View Post
No, all my settings are at the defaults. No exceptions.

I just tested with and without "present several frames in advance" (windowed mode) but the problem happens in both modes.
Wait, with or without "present several frames in advance" it says "D3D9 windowed (old path)" in the OSD. I assume because I have Aero off or something like that? Is it relevant?
sneaker_ger is offline   Reply With Quote
Old 18th July 2015, 17:13   #31923  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by TheLion View Post
Who cares about resources? That's exactly our pipe dream! And how could we do that? (I am guessing at some point you will get really annoyed by these "internal over-/supersampling" questions... )
Yes, maybe I'll add supersampling at some point, but if you look at the current sharpening options, they're a mess, much too many options. We first need to clean that up. Then maybe we can think about supersampling afterwards. I don't want to make the options any more complicated right now.

Quote:
Originally Posted by 6ari8 View Post
The issue only happens in D3D11 so by using D3D9 it played normally in previous versions. "use a separate device for presentation" doesn't seem to have any effect as far as I can see.
The issue seems to be reduced by a bit in v0.88.19 but still very obvious so I went and did some testing.

First, I activated debug mode and I was surprised because the issue was completely gone in all builds that had it. So maybe debug mode is doing something to prevent the stuttering?
Anyway, I then went and reset everything to defaults and it played normally. I then activated my settings one by one to see which one is causing the stuttering and ended up with the culprit.

It was the GPU/Present queues.
More specifically, whenever the present queue is less than the GPU queue by a certain amount, the stuttering happens. As you saw in my screenshots before, my GPU queue was set to 10 and my present was set to 6.

When I keep the present queue as 6 and decrease my GPU queue to 8, the stuttering is gone. When I then decrease the present queue to anything less than 6 it comes back.
Similarly, when I increase my present queue to 8 and keep my GPU queue at 10, the stuttering is gone. However, when I go and increase the GPU queue to anything more than 10, the stuttering comes back.

When I put madVR in debug mode, the stuttering goes away regardless of whatever queues I set.
That sounds quite interesting. I don't really have an explanation for that, unfortunately. Looking at my code, I seem to be doing everything correctly. Also on my PC I can't reproduce these issues. As a test I've setup GPU queues to 16 and the present queue to 8, and playback is mooth with D3D11 in both windowed and FSE mode, regardless of whether the OSD is on or off.

It seems there are some odd problems out there atm, with v0.88.17+, but it seems to affect only few users, and every of them seems to have different problems, and I can't reproduce any of them. So it's really hard for me to do anything about it. Of course I could simply revert all changes I did, but then we would lose some important improvements that several media player devs have been wishing for and been quite happy to see introduced in v0.88.17 (like low latency OSD, smooth and low GPU power paused mode rendering etc).

Quote:
Originally Posted by mogli View Post
You asked me to do the same when I reported better performance with D3D11 some pages ago.
Checking that option does almost gain nothing here.
Does it say "(new windowed path)" when you do that with D3D9?

Quote:
Originally Posted by Ver Greeneyes View Post
I can't say for sure what's going on, but this is what it looks like to me: the queues are full, and there are no presentation glitches, but the stream occasionally sends fewer frames than its advertised frame rate, thus causing madVR to repeat a frame. I assume madVR has already accounted for this missing frame, since the queues are full, but somehow it, or the DWM, ends up showing a much older frame briefly instead of repeating the most recent one.
That sounds weird. And this is a new problem with the recent builds, I suppose? If the madVR queues are full and neither frame drops nor presentation glitches are reported, then this could be a GPU driver bug, or a bad flush setting (are you using defaults?), or a bug in madVR.

Quote:
Originally Posted by Siso View Post
I watch only 1080p rarely some 720p mkv files, and it happens with everyone of them in Overlay mode.
Do you get a madVR crash box? If so, I'd like to see the crash report.

Quote:
Originally Posted by James Freeman View Post
After reading your posts, I confirm.

D3D11, FSE, there are may unreported skipped/dropped/repeated frames. The video is stuttering.
*Present a frame for every Vsync, enabled or disabled.
That is not something anybody else has reported yet (unless it only occurs if any sort of OSD in on). If you reliably have this issue, I'd need more information. E.g. OS, GPU, which exact madVR build introduced it, whether you're using default flush settings or not, whether the problem only shows if any sort of OSD is visible or whether it always shows etc.

Quote:
Originally Posted by Shiandow View Post
In principle you could just blur the image, instead of downscaling it. This basically means that SuperRes will assume that the original image is a blurred version of the 'actual' image, and SuperRes will then try to recover the 'actual' image. Not too sure if this is any better than a normal sharpener though.
Ok, good idea. Something to try in the future, maybe.

Quote:
Originally Posted by sneaker_ger View Post
Wait, with or without "present several frames in advance" it says "D3D9 windowed (old path)" in the OSD. I assume because I have Aero off or something like that? Is it relevant?
Yes, it's relevant. I think the "new path" can only be used if Aero is on, IIRC, but I'm not 100% sure right now. Also, the new path can only be used if it's also enabled in the FSE settings.
madshi is offline   Reply With Quote
Old 18th July 2015, 17:16   #31924  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,494
I have the new path for FSE so that's not it (like I said: default settings). Must be the Aero off thing, then.
sneaker_ger is offline   Reply With Quote
Old 18th July 2015, 17:27   #31925  |  Link
Siso
Registered User
 
Siso's Avatar
 
Join Date: Sep 2013
Location: Bulgaria
Posts: 410
Quote:
Originally Posted by madshi View Post
Do you get a madVR crash box? If so, I'd like to see the crash report.

No crashes so far. It seems that something is wrong with Overlay mode after version 0.88.17
Siso is offline   Reply With Quote
Old 18th July 2015, 17:40   #31926  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Quote:
Originally Posted by madshi
Quote:
Originally Posted by James Freeman
After reading your posts, I confirm.

D3D11, FSE, there are may unreported skipped/dropped/repeated frames. The video is stuttering.
*Present a frame for every Vsync, enabled or disabled.
That is not something anybody else has reported yet (unless it only occurs if any sort of OSD in on). If you reliably have this issue, I'd need more information. E.g. OS, GPU, which exact madVR build introduced it, whether you're using default flush settings or not, whether the problem only shows if any sort of OSD is visible or whether it always shows etc.
Please download from here a 24fps judder test video:
Judder test videos 24fps
I use the 10s 30 one.

Just look at the line to see if it stutters.

D3D11, FSE, = Stutter (All P states).
D3D11, FS Window, Youtube, = Stutter (P8 only).
D3d11, FS Window, Youtube paused, = No Stutter.
*All stutters are unreported by madVR.

Can anyone please confirm?

EDIT:
Windows 7 64bit, Nvidia GTX660.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 18th July 2015 at 17:52.
James Freeman is offline   Reply With Quote
Old 18th July 2015, 17:56   #31927  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by Siso View Post
No crashes so far. It seems that something is wrong with Overlay mode after version 0.88.17
Ok, I'll have a look.

Quote:
Originally Posted by James Freeman View Post
D3D11, FSE, = Stutter (All P states).
D3D11, FS Window, Youtube, = Stutter (P8 only).
D3d11, FS Window, Youtube paused, = No Stutter.
*All stutters are unreported by madVR.
[...] which exact madVR build introduced it, whether you're using default flush settings or not, whether the problem only shows if any sort of OSD is visible or whether it always shows etc.
madshi is offline   Reply With Quote
Old 18th July 2015, 17:58   #31928  |  Link
Ver Greeneyes
Registered User
 
Join Date: May 2012
Posts: 445
Quote:
Originally Posted by madshi View Post
That sounds weird. And this is a new problem with the recent builds, I suppose? If the madVR queues are full and neither frame drops nor presentation glitches are reported, then this could be a GPU driver bug, or a bad flush setting (are you using defaults?), or a bug in madVR.
I think the problem has been around ever since the new windowed mode was introduced, I just never made the connection before. I see it on both my laptop (with an old AMD GPU, legacy drivers) and my desktop (with a GeForce GTX 580, latest drivers), but there's probably something about the way livestreamer connects with MPC-HC that causes it. I definitely don't see it on every stream though, so I think I'll have to wait for a 'low quality' stream to get a debug log. I'll also try it with smooth motion disabled in case it makes a difference.

Edit: Oh, and flush settings are |flush, flush & wait (sleep), don't flush, don't flush|, which I believe is the default. I have it set to present 8 frames in advance, with a CPU queue size of 48 and a GPU queue size of 24, and "use a separate device for presentation" is checked.

Last edited by Ver Greeneyes; 18th July 2015 at 18:02.
Ver Greeneyes is offline   Reply With Quote
Old 18th July 2015, 18:16   #31929  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Quote:
Originally Posted by madshi View Post
Unreported Stutter,
[...] which exact madVR build introduced it, whether you're using default flush settings or not, whether the problem only shows if any sort of OSD is visible or whether it always shows etc.
88.17 introduced it; 88.16 is fine.
Only when something on the screen besides the video (Stats menu, volume, time marks, etc...).
Flushes are at default.
Quote:
Originally Posted by 88.17
* added automatic OSD low latency logic
I guess this one is to blame

Also 88.17 (and on) makes my rendering times faster in D3D11, from 23ms to 16ms.
With 88.16 rendering times are the same as d3d9, 23ms.

Anyone else can confirm?
Try videos with smooth pans.
D3D11, FSE, stats menu On (ctrl+j).
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 18th July 2015 at 18:28.
James Freeman is offline   Reply With Quote
Old 18th July 2015, 18:35   #31930  |  Link
Siso
Registered User
 
Siso's Avatar
 
Join Date: Sep 2013
Location: Bulgaria
Posts: 410
Quote:
Originally Posted by James Freeman View Post
88.17 introduced it; 88.16 is fine.
Only when something on the screen besides the video (Stats menu, volume, time marks, etc...).
Flushes are at default.

I guess this one is to blame

Also 88.17 (and on) makes my rendering times faster in D3D11, from 23ms to 16ms.
With 88.16 rendering times are the same as d3d9, 23ms.

Anyone else can confirm?
Try videos with smooth pans.
D3D11, FSE, stats menu On (ctrl+j).

All kinds of panning shots are somehow problematic in the latest builds etc 0.16, 0.17, 0.18, 0.19. I'm on Dell ud2913wm @ 72 hz+reclock. Also I lowered my dpc latency a lot, around 40-50-60 nanoseconds.

Last edited by Siso; 18th July 2015 at 18:39.
Siso is offline   Reply With Quote
Old 18th July 2015, 18:50   #31931  |  Link
mogli
Registered User
 
Join Date: May 2015
Posts: 71
Quote:
Originally Posted by madshi View Post
Does it say "(new windowed path)" when you do that with D3D9?
New path, yes, but I'm only testing FSE since I don't use windowed mode. (I restart MPC-HC after switching between D3D9/11.)
Quote:
Originally Posted by James Freeman View Post
Also 88.17 (and on) makes my rendering times faster in D3D11, from 23ms to 16ms.
With 88.16 rendering times are the same as d3d9, 23ms.
I reported the speed increase with v88.12. However I don't remember if it started earlier.

Note that D3D11 also about halves my presentation timings. Using 'separate device' has no effect on this at all, only on rendering.

Last edited by mogli; 18th July 2015 at 19:51.
mogli is offline   Reply With Quote
Old 18th July 2015, 18:54   #31932  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Quote:
Originally Posted by mogli View Post
I restart MPC-HC after switching between D3D9/11.

I reported the speed increase with v88.12. However I don't remember if it started earlier.
You can simply ctrl+c without restarting mpc-hc when changing between d9 and d11 or any other operation that requires closing madVR.

Apparently my speed up is because of the new OSD low latency logic from 88.17 on.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 18th July 2015 at 19:01.
James Freeman is offline   Reply With Quote
Old 19th July 2015, 03:56   #31933  |  Link
Akeno
Registered User
 
Join Date: Jul 2015
Location: Seattle, Washington
Posts: 53
Base Image / No image sharpening

SuperRes Strength: 1
SuperRes Strength: 4
SuperRes Strength: 4 + Radius: 1.00

The source I used actually has aliasing already in it. NNEDI3 miraculously anti-aliases the image and SuperRes brings back the aliasing. Anyone know why that is?

For fun, I set image upscaling to softcubic 100 and doubled the image.
Base Image / No image sharpening

SuperRes Strength: 1
SuperRes Strength: 4
SuperRes Strength: 4 + Radius: 1.00

And added fun, I compared Adaptive Sharpen set to 1.5 and SuperRes Strength: 1 and Strength: 4 + Radius: 1.00. There's a lot less ringing in SuperRes and the lines are closer to what you would expect (i.e. not horrendously thick). There's still aliasing regardless of settings though. Upping the radius only provided a marginal decrease in aliasing at the cost of marginal blurring.

Last edited by Akeno; 19th July 2015 at 05:54.
Akeno is offline   Reply With Quote
Old 19th July 2015, 06:07   #31934  |  Link
har3inger
Registered User
 
Join Date: Feb 2014
Posts: 139
If the source has aliasing, presumably SuperRes is interpreting that aliasing as meaningful information and is trying to reproduce the lost aliasing in the final result.
har3inger is offline   Reply With Quote
Old 19th July 2015, 09:02   #31935  |  Link
nijiko
Hi-Fi Fans
 
Join Date: Dec 2008
Posts: 222
MPEG2 deinterlacing is too SLOWLY (according to rendering time)
nijiko is offline   Reply With Quote
Old 19th July 2015, 09:27   #31936  |  Link
michkrol
Registered User
 
Join Date: Nov 2012
Posts: 167
Please provide more information:
Do you actually get dropped frames?
What decoder are you using (software/DXVA/CUVID/QuickSync)?
What OS and player are you using?
What GPU and drivers (version) are you using?
A screenshot of the OSD would also be helpful.
michkrol is offline   Reply With Quote
Old 19th July 2015, 09:43   #31937  |  Link
Warner306
Registered User
 
Join Date: Dec 2014
Posts: 1,126
Using the test build, the performance of SuperRes has degraded to the point I can no longer run Strength 1. Previously, my settings were as follows:

Profile: "720p"
  • Chroma: super-xbr150 + AR
  • Image: Jinc3 + AR
  • Luma Doubling: Off
  • Upscaling Refinement: SuperRes (passes: 1; strength: 1.0; algo: 2; alt color space: off)
  • Artifact Removal - Debanding: Medium/High
  • Image Enhancements: Off
  • Dithering: Ordered
No presentation glitches, rendering closer to 30ms than 38ms. This is with a Nvidia GTS 450.

Last edited by Warner306; 19th July 2015 at 09:45.
Warner306 is offline   Reply With Quote
Old 19th July 2015, 12:45   #31938  |  Link
KoD
Registered User
 
Join Date: Mar 2006
Posts: 552
Hi, I experience lots of dropped frames after switching between fullscreen and windowed modes, the way I describe below:

What I do is this: start playback-> all is fine, go fullscreen -> everything is still fine, then go back to windowed mode -> all still fine -> go back to full screen -> now lots of frames dropped, it does not recover itself unless I pause the video, and then resume. With 0.88.12 it was enough to pause once, and then playback would be smooth again after resuming; with 0.88.19 once is often not enough, I have to pause twice. It looks like the render queue does not recover staying at 1-3 or 2-3, even though the decoder, subtitle and upload queues fill up to their normal stats. The present queue also ends up with the same fill status as the render queue.

Some details: I'm using MPC, with its internal filters for h264 playback of mkvs, it happens on both 8 bit and 10 bit content, irrespective of whether I use software or hardware decoding. Happens only when using D3D11 and fullscreen exclusive mode. If I use full screen windowed mode, or I use the D3D9 renderer, all is fine.

I happen to have a Sony TV which accepts 12 bit color input. When using D3D11 and fullscreen exclusive mode, the TV receives 12bit per channel input (I can see this by pressing the Info key on the remote).

Have not changed the graphics drivers since a long time ago, it's still version 347.25 on a GTX980 for me.
KoD is offline   Reply With Quote
Old 19th July 2015, 13:21   #31939  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,226
Quote:
Originally Posted by KoD View Post
Hi, I experience lots of dropped frames after switching between fullscreen and windowed modes
I bothered to do a little further testing tonight on this issue I reported a month ago and came to post the exact same thing.. looks like I didn't need not bother..

Sometimes I've seen it recover while paused only to drop the queue to low values again once it's started playing. And yes it's generally when you do a "messy" (multiple switching, pausing etc) windowed to fullscreen switch.

Quote:
Originally Posted by madshi View Post
Does it only occur in 10bit output mode?
Yup.

Quote:
Originally Posted by madshi View Post
Does the screen refresh rate matter?
Nope.

Quote:
Originally Posted by madshi View Post
Please make sure you close everything else, even 3rd party background services, just to be safe.
Played it safe. No difference.
ryrynz is offline   Reply With Quote
Old 19th July 2015, 13:38   #31940  |  Link
tFWo
Registered User
 
Join Date: Apr 2011
Posts: 24
Quote:
Originally Posted by madshi View Post

you can create an empty file called "BilinearSuperRes" in the madVR folder. That means HQ turned off. I pretty much hate the look it produces, though, so use it at your own "risk".
I'll be using this too. HQ is the source of most of the problems I have with Superres. There is a new problem when using this. Strength 1 is too strong with HQ turned off . Maybe add strength 0 that halves the strength.

"Radius" option helps only a little when HQ is on. Turning it higher than 0.75-0.80 does remove most of the artifacts, but it also softens the image considerably. Again I fail to find a purpose for Superres with a trade-off like that.

With HQ off, "radius" is less important. It just has to be just above 0.5 (i set it at 0.7 just to be sure). When it's set below 0.5 aliasing/pixelization appears.

Last edited by tFWo; 19th July 2015 at 14:38.
tFWo 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 21:56.


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