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 March 2014, 00:47   #24261  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by huhn View Post
new 120 fps test file looks with and without SM terrible.
I don't find it terrible with SM FRC on. But I find it hard to judge. While this sample is nicely long (thanks!) the movements in the video are often very sudden and non-smooth, which makes it hard to judge overall smoothness. Do you have a racing game, maybe? That might be better suited to judge motion smoothness.

FWIW, it seems that VMR9 and EVR-Custom handle this relatively nicely, while madVR doesn't handle it well with SM FRC turned off. madVR is not optimized for showing videos with a frame rate higher than the refresh rate, with SM FRC turned off. I guess I could work on that, but to be honest I don't find it very important atm. I guess for now you could compare VMR9 or EVR-Custom to madVR's SM FRC to compare which you like better.

Quote:
Originally Posted by iSunrise View Post
For some reason I can´t play that file at all here when I enable smooth motion. All I get is a still picture and a lot of dropped frames are showing up in the OSD.
Which is the first queue (from top to bottom) in the OSD which is empty? Probably the upload queue? Try again when v0.87.5 is released (probably in the next 1-2 days).

Quote:
Originally Posted by huhn View Post
sounds ike a bug for the bug tracker.
At this point it makes sense to wait for v0.87.5 before posting new bugs to the tracker.

Quote:
Originally Posted by Shiandow View Post
I just confirmed that it also happens when smooth motion is disabled and only when dithering is dynamic. So indeed it seems that I was wrong that the blinking was caused by dithering and smooth motion using different gamma curves. It also seems to happen on places that don't even change colour which also suggests that smooth motion can't be the cause. Something doesn't seem to be as random as it should be.
The blinking seems to occur if the movie framerate isn't identical to the display refresh rate. I think the blinking comes from seeing the dither pattern change in unregular intervals. If you make sure that the movie framerate and display refresh rate match, the blinking goes away. Which proves (I believe) that there's no problem with the randomness.

Quote:
Originally Posted by Shiandow View Post
Code:
#define depth pow(2,8)
sampler s0 : register(s0);

float4 f(float4 x)
{
	return pow(x,1/0.45);
}

float4 main(float2 tex : TEXCOORD0) : COLOR
{
	float4 c0  = tex2D(s0, tex);
	float4 low = floor(depth*c0)/depth;
	float4 hi  = ceil (depth*c0)/depth;
	float4 c1  = (f(c0)-f(low))/(f(hi)-f(low));
	return low+(c1/depth);
}
the value 'depth' should be 2^8 if the final output is 8 bits, 2^6 for 6 bits etc. This shader shouldn't change the behaviour of the dithering algorithms much, beyond correcting the colours. In particular the error diffusion algorithms still diffuse errors in gamma light (more or less).
Your algorithm might work for ordered dithering, but not for error diffusion. Let me explain why: Error diffusion consists of 2 different parts:

(1) When the target value is between two shades, part 1 of the algorithm decides which shade to draw for the current pixel.
(2) Part 2 takes the pixel drawn by part 1, calculates the error to the original floating point pixel value and spreads the error to the surrounding pixels.

Now it's important to understand that for a big image area Part 2 is really the part which decides about the overall brightness of that image area. While part 1 only decides how the dither pattern looks like (worm artifacts or not etc). Practically that means that for error diffusion your shader only changes the look of the dithering pattern, but it doesn't change the overall image area brightness. So it does not actually do any gamma correction. If you want to do error diffusion gamma correction, you *have* to calculate the error in linear light. There's no way around it.

Let me show this with an example: Let's say in gamma light error diffusion would like to draw 50% of the pixels in shade 1 and 50% in shade 2. Now your linear light algorithm decides to draw shade 1 80% of the time. Initially it will work alright. But doing this will result in the cumulated error growing, because the error calculation is still done in gamma light. At some point the error will flow over so that it's no longer shade 1 and shade 2, but instead it will be shade 2 and shade 3. So basically all your linear light algorithm does for error diffusion is to have more noise because you'll have lots of shade 1 pixels, a few shade 2 pixels and a few shade 3 pixels. Without your linear light algorithm there would only be shade 1 and 2 pixels, so less noise. The overall image brightness would be the same in both cases.

Quote:
Originally Posted by XMonarchY View Post
I subbmited OpenCL <-> D3D9 interop bug to the 3 possible places I could. I think everyone here should do the same! If at least 10-15 people do the same - I bet we'll get a fix in the next driver release.
Well, that would be nice! But I somehow doubt it. But let's wait and see...
madshi is offline   Reply With Quote
Old 5th March 2014, 00:48   #24262  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
@XMonarchY
The regression was introduced in the R331 driver branch (black screen + driver hangs).

Starting with 334.89 from the R334 driver branch, the symptoms have changed (green tint? + driver hangs?, I've not tested this driver).

All branches prior to R331 are unaffected, it's not limited to 327.23 & 326.80.

It's worthwhile to make such a distinction between branch-wide driver bugs/symptoms, and release-specific driver bugs/symptoms.

Last edited by cyberbeing; 5th March 2014 at 00:56.
cyberbeing is offline   Reply With Quote
Old 5th March 2014, 00:56   #24263  |  Link
XMonarchY
Registered User
 
Join Date: Jan 2014
Posts: 489
Quote:
Originally Posted by cyberbeing View Post
@XMonarchY
The regression was introduced in the R331 driver branch (black screen).

Starting with 334.89 from the R334 driver branch, the symptoms have changed (green tint).

All branches prior to R331 are unaffected, it's not limited to 327.23 & 326.80.

It's worthwhile to make such a distinction between branch-wide driver bugs/symptoms, and release-specific driver bugs/symptoms.
Thank you for the info - I didn't know!
XMonarchY is offline   Reply With Quote
Old 5th March 2014, 00:58   #24264  |  Link
Shiandow
Registered User
 
Join Date: Dec 2013
Posts: 752
Quote:
Originally Posted by madshi View Post
Let me show this with an example: Let's say in gamma light error diffusion would like to draw 50% of the pixels in shade 1 and 50% in shade 2. Now your linear light algorithm decides to draw shade 1 80% of the time. Initially it will work alright. But doing this will result in the cumulated error growing, because the error calculation is still done in gamma light. At some point the error will flow over so that it's no longer shade 1 and shade 2, but instead it will be shade 2 and shade 3. So basically all your linear light algorithm does for error diffusion is to have more noise because you'll have lots of shade 1 pixels, a few shade 2 pixels and a few shade 3 pixels. Without your linear light algorithm there would only be shade 1 and 2 pixels, so less noise. The overall image brightness would be the same in both cases.
You seem to assume that you would still calculate the error using the original image. Otherwise you're suggesting that changing the values of the image somehow doesn't change the resulting brightness. I do agree that the shader I suggested has some odd effects due to the fact that the error isn't distributed in linear light, but on average it should at least have the right values.
Shiandow is offline   Reply With Quote
Old 5th March 2014, 01:02   #24265  |  Link
iSunrise
Registered User
 
Join Date: Dec 2008
Posts: 497
Quote:
Originally Posted by madshi View Post
Which is the first queue (from top to bottom) in the OSD which is empty? Probably the upload queue? Try again when v0.87.5 is released (probably in the next 1-2 days).
Edited my original post, which probably was too late for you to see it, while you were writing yours. It was caused by the backbuffer queue that went down to 0-2/4 or 0-2/8, when smooth motion was active. I solved it by increasing the general CPU queue and the GPU queue, while also increasing the backbuffers for both of the respective modes (windowed/exclusive) to 8, while I had them at 4 before.

It seems smooth motion and 1080p120 requires the queues to be (a lot) higher in general, while I could get away with relatively very low queues until now. But with 1080p120, this was just too much. Then again, 1080p120 content or even higher are not really a common thing (even though the iPhone 5s does 720p120), but I will just keep them for now to be safe. At least now I know why cyberbeing always went with the higher queues, because he wanted to avoid possible ill effects like that happening in the first place.

Last edited by iSunrise; 5th March 2014 at 01:11.
iSunrise is offline   Reply With Quote
Old 5th March 2014, 02:43   #24266  |  Link
seiyafan
Registered User
 
Join Date: Feb 2014
Posts: 161
Just want to double check, in MPC under LAV video decoder, what's a good hardware decoder to use? Is it none?

I found out that with deinterlacing enabled, there's massive frame drop when the rendering time is actually less than the time when I disabled deinterlacing with a more difficult upscaling algorithm but noticed no frame drop. What's happening?

Last edited by seiyafan; 5th March 2014 at 02:49.
seiyafan is offline   Reply With Quote
Old 5th March 2014, 05:18   #24267  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 3,763
I prefer none for hardware decoding, software can handle almost anything while the various hardware options all have their different issues. Keep the GPU free for madVR.

deinterlacing is probably doubling the frame rate so you require one half the max rendering times before you get dropped frames. Compare "movie frame interval" and average rendering times in madVR's OSD.
Asmodian is offline   Reply With Quote
Old 5th March 2014, 05:33   #24268  |  Link
seiyafan
Registered User
 
Join Date: Feb 2014
Posts: 161
This is what I experienced:



Not sure why I was dropping flies with half of the rendering time.
seiyafan is offline   Reply With Quote
Old 5th March 2014, 06:50   #24269  |  Link
jkauff
Registered User
 
Join Date: Oct 2012
Location: Akron, OH
Posts: 436
Quote:
Originally Posted by Asmodian View Post
I prefer none for hardware decoding, software can handle almost anything while the various hardware options all have their different issues. Keep the GPU free for madVR.
There's one use case where hardware decoding makes sense. If you have an Intel iGPU as well as an NVIDIA/AMD dGPU, you can have LAV using the iGPU while madVR is using the dGPU (this is assuming you have a motherboard/BIOS that allows simultaneous use).

When I'm doing a Handbrake encode, the CPU is at or near 100%. If I want to watch a movie at the same time, off-loading the decoding to QuickSync works great. No dropped frames.
jkauff is offline   Reply With Quote
Old 5th March 2014, 08:13   #24270  |  Link
yok833
Registered User
 
Join Date: Aug 2012
Posts: 73
I would be happy to participate and send your message to the Nivdia developers.... Could you post 2 or 3 addresses where we can contact them ?

"Envoyé depuis mon GT-I9300 avec Tapatalk"
yok833 is offline   Reply With Quote
Old 5th March 2014, 09:07   #24271  |  Link
THX-UltraII
Registered User
 
Join Date: Aug 2008
Location: the Netherlands
Posts: 850
Quote:
Originally Posted by madshi View Post
This question is asked a lot, and there's no simple answer. It all depends on which algorithms you want to use, which input/output resolutions need to be supported and which movie framerate and display refresh rate etc. Just as an example: If you need support for 60p, the GPU has to be almost 2.5x as fast as it would have to be if you limited yourself to 24p. So that shows clearly how much all of this depends on your exact requirements
My setup is a 4K projector and 99% of the content I use is 23,976fps Blu-Ray content.

I m running madVR with:
- OpenCL option in general settings disabled
- Image doubling disabled
- Luma and Chroma Upscaling @JINC 4taps with AR enabled.
- All trade quality for performance boxes disabled.
- Dithering option 2 with the 2 checkboxes disabled.
- Debanding at 'MID+HIGH'.
- GPU hardware decoding disabled (my CPU takes care of this because you want your GPU free for all other madVR options as much as possible)

My GPU is a AMD 280X oc-ed pretty heavy with the latest 14.2 beta driver. Besides this I m running a i7 2600K

With all these settings my OC-ed 280X (which is basically a HD7970 with a little more power) run @65% GPU usage.

Last edited by THX-UltraII; 5th March 2014 at 13:10.
THX-UltraII is offline   Reply With Quote
Old 5th March 2014, 09:17   #24272  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Quote:
Originally Posted by THX-UltraII View Post
- GPU hardware decoding disabled (my CPU takes care of this because you want your GPU free for all other madVR options as much as possible)
If I'm not mistaken, with Nvidia cards there is a separate Video Engine (PureVideo) decoder processor on the GPU for that.
So everything madVR uses as GPU processing is done on the main processor of the GPU and not on the Video Engine decoder.
Isn't that the case with ATI also?

On the other hand CPU decoding is "less buggy" and is constantly updated.
Maybe nevcairiel can clarify how it works.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 5th March 2014 at 09:26.
James Freeman is offline   Reply With Quote
Old 5th March 2014, 09:27   #24273  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by Shiandow View Post
You seem to assume that you would still calculate the error using the original image.
"newError = originalPixel + cumulatedErrors - drawnPixel". How else would you do it?

Quote:
Originally Posted by Shiandow View Post
Otherwise you're suggesting that changing the values of the image somehow doesn't change the resulting brightness.
You're only changing the pattern, but not the overall brightness. I'm sure about this - unless you also change the way the error is calculated.

Quote:
Originally Posted by iSunrise View Post
It was caused by the backbuffer queue that went down to 0-2/4 or 0-2/8, when smooth motion was active. I solved it by increasing the general CPU queue and the GPU queue, while also increasing the backbuffers for both of the respective modes (windowed/exclusive) to 8, while I had them at 4 before.

It seems smooth motion and 1080p120 requires the queues to be (a lot) higher in general
Yes, smooth motion does often require higher queues values. To be honest, I don't really see any benefit (worth mentioning) of using short queues.

Quote:
Originally Posted by seiyafan View Post
I found out that with deinterlacing enabled, there's massive frame drop when the rendering time is actually less than the time when I disabled deinterlacing with a more difficult upscaling algorithm but noticed no frame drop. What's happening?
Quote:
Originally Posted by Asmodian View Post
deinterlacing is probably doubling the frame rate so you require one half the max rendering times before you get dropped frames. Compare "movie frame interval" and average rendering times in madVR's OSD.
I agree with Asmodian.

Look at your OSD screenshots: With deinterlacing disabled you have rendering times of 39.57ms, with 25fps. Now if you do the math (1000 / 25fps = 40ms), the rendering times are just small enough. With deinterlacing enabled you have combined rendering times + deinterlacing times of 21.95ms, and you get 50fps out of the deinterlacer. Do the math (1000 / 50fps = 20ms) and you'll see that the rendering times are too high. The deinterlacer doubles the framerate which means rendering times must be half as high to avoid dropped frames.
madshi is offline   Reply With Quote
Old 5th March 2014, 09:42   #24274  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
madshi,
The greater the rendering time, the more the video will lag behind the audio?
Is there synchronization between them even with higher rendering time?

Or is it how much time it takes for a single frame to be rendered, and if the time is longer than the video's single frame (1000/24 = 41.7ms), there will be dropped frame?
(as understood from your last post).
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 5th March 2014 at 09:50.
James Freeman is offline   Reply With Quote
Old 5th March 2014, 10:07   #24275  |  Link
iSunrise
Registered User
 
Join Date: Dec 2008
Posts: 497
Quote:
Originally Posted by madshi View Post
Yes, smooth motion does often require higher queues values. To be honest, I don't really see any benefit (worth mentioning) of using short queues.
I kind of liked it when the media player felt snappier (also the madVR OSD reacted way faster), that´s why I went with lower queues before, but I agree that after re-visiting the queue settings yesterday, the difference is almost non-existent now, because even though I upped the queues, I didn´t overdo it, so the OSD still reacts almost instantly when I enable/disable it and that test file should be a good worst case scenario to test against. Of course, I could probably just use the defaults and be done with it. Because that´s what I do when I do my bug reports, anyway.

And while we´re at it, I just got an answer from Blaire (current state of the NV madVR driver fix), who wrote me that NV is currently working on the fix. The exact phrase is "Yes. We are still working on it", so this seems to be good news for an upcoming fix in the next 1-2 driver releases hopefully.
iSunrise is offline   Reply With Quote
Old 5th March 2014, 10:21   #24276  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by James Freeman View Post
The greater the rendering time, the more the video will lag behind the audio?
Is there synchronization between them even with higher rendering time?
As long as it's not a total slide show audio/video sync should always be maintained. If the rendering times are too high, this will just result in frames being dropped.

Quote:
Originally Posted by iSunrise View Post
And while we´re at it, I just got an answer from Blaire (current state of the NV madVR driver fix), who wrote me that NV is currently working on the fix. The exact phrase is "Yes. We are still working on it", so this seems to be good news for an upcoming fix in the next 1-2 driver releases hopefully.
Great - thanks!
madshi is offline   Reply With Quote
Old 5th March 2014, 10:37   #24277  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Quote:
Originally Posted by iSunrise View Post
And while we´re at it, I just got an answer from Blaire (current state of the NV madVR driver fix), who wrote me that NV is currently working on the fix. The exact phrase is "Yes. We are still working on it", so this seems to be good news for an upcoming fix in the next 1-2 driver releases hopefully.
High hopes, fingers crossed, let it be true.

Quote:
Originally Posted by madshi View Post
As long as it's not a total slide show audio/video sync should always be maintained. If the rendering times are too high, this will just result in frames being dropped.
Thanks.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.
James Freeman is offline   Reply With Quote
Old 5th March 2014, 11:14   #24278  |  Link
Shiandow
Registered User
 
Join Date: Dec 2013
Posts: 752
Quote:
Originally Posted by madshi View Post
You're only changing the pattern, but not the overall brightness. I'm sure about this - unless you also change the way the error is calculated.
There seems to be some kind of misunderstanding. The shader is meant to change the input of the dithering algorithm, it would be very odd if this didn't affect the output.

It would be nice if we could agree on a way to make the shader 'correct' since it then gives a way of estimating how 'wrong' the dithering algorithm currently is. If the shader, as I posted it, is correct then the mistakes caused by dithering in gamma light are almost insignificant (i.e. not noticeable with 16 bits) except in some very rare cases where a pixel value is inbetween two colours that are almost black.
Shiandow is offline   Reply With Quote
Old 5th March 2014, 11:23   #24279  |  Link
Aikibana
Registered User
 
Join Date: Aug 2012
Posts: 12
Quote:
Originally Posted by iSunrise View Post
And while we´re at it, I just got an answer from Blaire (current state of the NV madVR driver fix), who wrote me that NV is currently working on the fix. The exact phrase is "Yes. We are still working on it", so this seems to be good news for an upcoming fix in the next 1-2 driver releases hopefully.
Now let's start the same initiative at AMD for fixing the OpenCL-D3D9 Interop lag

Although I have high hopes a D3D9 > D3D10/11 > OpenCL routing might improve this, when Madshi finds the time.
Aikibana is offline   Reply With Quote
Old 5th March 2014, 12:00   #24280  |  Link
toniash
Registered User
 
Join Date: Oct 2010
Posts: 116
What to look for if my render queues don't fill up completely?
toniash 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 15:59.


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