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 7th October 2014, 12:31   #121  |  Link
Zachs
Suptitle, MediaPlayer.NET
 
Join Date: Nov 2001
Posts: 1,721
Quote:
Originally Posted by huhn View Post
it's broken with directx 10.1 too but it's fine in full screen mode.



so with a UHD source on a FHD screen madVR does.

chroma upscales FHD to UHD (2 channels to UHD) chroma position correction and RGB conversation and now scaling the hole UHD RGB frame (3 channel) down to FHD.


MPDN has a option for chroma up and down so I guess it's not working like madVR that creates always 48 bit RGB first.

by just scaling the luma channel (1 channel) to 1080p, correct chroma position and by doing a RGB conversation in just 1080p it has to be a lot faster or not?

not sure about the quality through.
I do exactly the same thing in FSE mode vs windowed mode. I am not sure why it would stutter in windowed mode but not FSE. The D3D9 render path I get it (not really, since it doesn't make much sense why increasing back buffer count would cause it to stutter) but definitely not D3D10. Anyway, I've changed the backbuffer count of D3D10 to 2 (as the recommended minimum from MSDN docs). Please let me know if stuttering issue still occurs in either rendering paths in the next release.

Scaling luma and chroma just once should yield better quality if all else is equal, otherwise it would defy logic wouldn't it?

For example, you wouldn't have to upscale chroma once to luma size, and then scale it again from there. Human eyes aren't very sensitive to chroma though, so you may not notice the loss of quality the way madVR does it.

Not to mention I just can't get madVR to play 4K movies properly on any of the systems I own!

E.g. Softcubic 50, no dithering, no smooth motion, 560 GTX.
Test clip: Interstellar-TLR-F2-5.1-4K-HDTN.mp4

Render times:
MPDN: 11.7ms
madVR: 44.4ms

madVR also constantly racks up presentation glitches (~5 per second).

EDIT: Just realised my 560GTX was running at lowest power state with MPDN since it didn't need the extra clock speed. MPDN's time was in the 7ms range at max power state. So this explains the difference Shiandow was seeing with his 560ti vs my 560.

Last edited by Zachs; 8th October 2014 at 01:34.
Zachs is offline   Reply With Quote
Old 7th October 2014, 13:41   #122  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 8,157
still not working fine it works sometime and sometimes not. don't forget i'm on windows 10 who knows what Microsoft has broken in this preview so please don't take it to serious.

about UHd downscaling.

i can easily use madVR to downscale with dithering using spline 3 ar for a 60 fps UHD source to FHD with about 11 ms at max powerstate using a gtx 760.
when i use MPDN I get about 14 ms and the powerstate is min running at ~135 mhz so it is about 6-10 times faster and there must be a reason for that.

are you using a 16 bit frame buffer like madVR? is the chroma position corrected at all?
huhn is offline   Reply With Quote
Old 7th October 2014, 13:46   #123  |  Link
Zachs
Suptitle, MediaPlayer.NET
 
Join Date: Nov 2001
Posts: 1,721
No its 32 bit all the way. No 16 bit crap until the final output where it is 8, 10 or 16 bits.

Chroma position correction is free as in it doesn't affect render time.
Zachs is offline   Reply With Quote
Old 7th October 2014, 14:47   #124  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Zachs View Post
Scaling luma and chroma just once should yield better quality if all else is equal, otherwise it would defy logic wouldn't it?
Actually upscaling the image, then doing some processing (e.g. detail enhancement/sharpening), then downscaling again can be beneficial sometimes. There are several AviSynth sharpening scripts which internal upscale first, then process, then downscale to reduce aliasing. Furthermore, the chroma channel was downscaled by the studio. It might make sense to use a different algorithm to try to restore the original chroma resolution again, and then a different algorithm for image up/down scaling. Finally, for high downscaling factors using linear light downscaling can improve the image quality, which is only possible if you restore the original chroma resolution first. Whether the final result looks better or worse depends on the exact algorithms that were used.

Quote:
Originally Posted by Zachs View Post
Not to mention I just can't get madVR to play 4K movies properly on any of the systems I own!
Well, you probably could, by using DXVA downscaling, or Bilinear downscaling, but obviously that's not a good idea for image quality. I guess I could add a different rendering path to madVR to skip chroma upsampling under specific circumstances to speedup downscaled 4K playback. It would be quite a lot of extra work, though...
madshi is offline   Reply With Quote
Old 7th October 2014, 21:49   #125  |  Link
Shiandow
Registered User
 
Join Date: Dec 2013
Posts: 753
Quote:
Originally Posted by Zachs View Post
E.g. Softcubic 50, no dithering, no smooth motion, 560 GTX.
Test clip: Interstellar-TLR-F2-5.1-4K-HDTN.mp4

Render times:
MPDN: 11.7ms
madVR: 44.4ms

madVR also constantly racks up presentation glitches (~5 per second).
That doesn't sound right, if I play back that file on a resolution of 1920x1080 I get render times of ~23 ms using Bicubic 75 AR chroma doubling, Mitchell AR LL downscaling, debanding, ordered dithering and smooth motion on a GTX 560 Ti.

Edit: Turns out that MPDN only needs 5 ms (using default settings) so it seems that the performance difference remains relatively the same. Apparently there's a larger difference between the GTX 560 Ti and the GTX 560 than I thought.

Last edited by Shiandow; 7th October 2014 at 22:48.
Shiandow is offline   Reply With Quote
Old 8th October 2014, 00:59   #126  |  Link
Zachs
Suptitle, MediaPlayer.NET
 
Join Date: Nov 2001
Posts: 1,721
Quote:
Originally Posted by madshi View Post
Actually upscaling the image, then doing some processing (e.g. detail enhancement/sharpening), then downscaling again can be beneficial sometimes. There are several AviSynth sharpening scripts which internal upscale first, then process, then downscale to reduce aliasing. Furthermore, the chroma channel was downscaled by the studio. It might make sense to use a different algorithm to try to restore the original chroma resolution again, and then a different algorithm for image up/down scaling. Finally, for high downscaling factors using linear light downscaling can improve the image quality, which is only possible if you restore the original chroma resolution first. Whether the final result looks better or worse depends on the exact algorithms that were used.


Well, you probably could, by using DXVA downscaling, or Bilinear downscaling, but obviously that's not a good idea for image quality. I guess I could add a different rendering path to madVR to skip chroma upsampling under specific circumstances to speedup downscaled 4K playback. It would be quite a lot of extra work, though...
I wouldn't take AviSynth scripts as the de facto standards on how things should be done, they are usually written to utilize what's readily available from AviSynth core functions when there are other ways to achieve the same quality or better (esp in the reducing aliasing department) in a much less expensive way.

Correct me if I'm wrong but are you saying luma is scaled by a third party and chroma is scaled separately by the studio? My thinking was that they were both scaled by the studio?? e.g. Production company shoots footage in IMAX res, studio scales both luma and chroma to 4:2:0 for Bluray/DVD release. Or in the consumer space, video cams record straight to 4:2:0. TBH I can't see how upscaling chroma twice in that regard could be beneficial as opposed to detrimental in any way.

Personally I have not seen the benefits of scaling in linear light so I haven't done much research into that. However, my thinking is linear light scaling could be done on the individual YUV planes too, couldn't it?
Zachs is offline   Reply With Quote
Old 8th October 2014, 01:02   #127  |  Link
Zachs
Suptitle, MediaPlayer.NET
 
Join Date: Nov 2001
Posts: 1,721
Quote:
Originally Posted by Shiandow View Post
That doesn't sound right, if I play back that file on a resolution of 1920x1080 I get render times of ~23 ms using Bicubic 75 AR chroma doubling, Mitchell AR LL downscaling, debanding, ordered dithering and smooth motion on a GTX 560 Ti.

Edit: Turns out that MPDN only needs 5 ms (using default settings) so it seems that the performance difference remains relatively the same. Apparently there's a larger difference between the GTX 560 Ti and the GTX 560 than I thought.
Your settings are too unfair for madVR. If you really want to compare the relative performance of MPDN vs madVR, you should really set them up so they are on a level playing field - e.g. debanding and smooth motion cost quite a bit of rendering time.

EDIT: Turns out my GTX 560 was running at lowest power state when I took the measurement because it could with MPDN. At max power state, I got 7ms, so it is quite close to your 560ti, which it should be (384 vs 336 cores). As with madVR, it seems that its performance was affected by presentation glitches. I will try swapping drivers and report back. In the meantime, try comparing with madVR settings Softcubic 50 no AR chroma doubling, softcubic 50 no AR no LL downscaling, no debanding, no dithering and no smooth motion. And set MPDN's dithering to none as well.

Last edited by Zachs; 8th October 2014 at 01:58.
Zachs is offline   Reply With Quote
Old 8th October 2014, 01:44   #128  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 8,157
first of all rendertimes are hard to judge. the GPU powerstate is a huge problem in these cases and can easily make rendertimes miss leadering at least.

it's not rare that I see way higher rendertime with a lot easier content.

this usually happens with 1080p23 and 1080i30 60 fields.
it's not rare that the rendertimes of GPU deinterlaced 1080i 60 fields is way lower than the rendertimes of 1080p23 and the reason is the gpu powerstate.
huhn is offline   Reply With Quote
Old 8th October 2014, 02:01   #129  |  Link
Zachs
Suptitle, MediaPlayer.NET
 
Join Date: Nov 2001
Posts: 1,721
Quote:
Originally Posted by huhn View Post
first of all rendertimes are hard to judge. the GPU powerstate is a huge problem in these cases and can easily make rendertimes miss leadering at least.

it's not rare that I see way higher rendertime with a lot easier content.

this usually happens with 1080p23 and 1080i30 60 fields.
it's not rare that the rendertimes of GPU deinterlaced 1080i 60 fields is way lower than the rendertimes of 1080p23 and the reason is the gpu powerstate.
Yes that's absolutely correct.

It's especially difficult when one is maxing out the GPU while the other was going over leisurely.

Is there a way of forcing the GPU to run at constant power state for testing purposes?
Zachs is offline   Reply With Quote
Old 8th October 2014, 02:42   #130  |  Link
Zachs
Suptitle, MediaPlayer.NET
 
Join Date: Nov 2001
Posts: 1,721
OK this is on an old 8400GS card that has constant clock (i.e. there's only two power states: card is on, or it's off, there's nothing in between) to rule out any difference in power states

Downscaling from 1920x1080 23p video to a 1280x1024 (1280x720 after scaling with aspect ratio) screen in FSE mode for both, all settings equal (Softcubic 50 no AR no LL for all scaling modes with madVR smoothmotion debanding off, MPDN and madVR dithering set to None). Consider this a poor man's UHD 3K to FHD comparison

MPDN: 32.8ms (max 35.8ms)
madVR: 90ms (max 133ms) ** average rendering time keeps crawling up non-stop even after 5 mins into the video

Using the max stats (madVR's max is more consistent vs its avg time hovering around the 130ms mark), it's again a ~4 times difference.

This time around, madVR does not suffer too many presentation glitches (only the occasional ones when stopping and playing video from the start). MPDN on the other hand has zero presentation glitches.

Last edited by Zachs; 8th October 2014 at 02:56.
Zachs is offline   Reply With Quote
Old 8th October 2014, 05:08   #131  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 8,157
madVRT creates usually presentation glitches when it is not in focus. and there where always problem when a program like gpu-z was running when madVR was used. and madVr has a lot of presentation mode. for exsample windows 7 overlay does a good job for me.

but the more important part is that when upscaling MPDN is not faster. so it is simply the way madVr handles 4:2:0 downscaling.

it is pretty hard to force a newer GPU in highest powerstate because that is not the highest powerstate anymore. all new card overclock them self.

you can disable this in most cases and forcing the gpu in highest power mode is possible too. should be in the driver settings.

i took a 848x480p23 file for upsacling tests the rendertimes are in the 1-2 ms range with high powerstate and bicubic 75. it's a bad comparison there is simply nothing to do for the gpu.

848x480 at 858x480 has there values:
MPDN chroma bicubic 75 directx 10.1
3.46 ms at 135 mhz ~10 % GPU usage

madVR chroma bicubic 75 windows 7 overlay
3.57 ms at 135 mhz ~11% GPU usage

madVR chroma bicubic 75 window mode (new path)
9.10 ms at 135 mhz ~20% GPU usage

madVR chroma bicubic 75 window mode (old path)
2.67 ms at 135 mhz ~10% GPU usage

what did we learn new path is pretty slow. on this PC.
huhn is offline   Reply With Quote
Old 8th October 2014, 07:37   #132  |  Link
Zachs
Suptitle, MediaPlayer.NET
 
Join Date: Nov 2001
Posts: 1,721
@huhn

Can you let me know if the latest version is better in terms of stuttering and if Lanczos and Jinc work without problems this time?
Zachs is offline   Reply With Quote
Old 8th October 2014, 08:39   #133  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Zachs View Post
I wouldn't take AviSynth scripts as the de facto standards on how things should be done, they are usually written to utilize what's readily available from AviSynth core functions when there are other ways to achieve the same quality or better (esp in the reducing aliasing department) in a much less expensive way.
I'm not sure if I would upscale (luma) first, then process, then downscale again myself. It could be beneficial, but I suppose the benefits could be too small to make it worth it. But there are some arguments to be made for doing some processing in the original video resolution.

If you look at scientific image scaling papers, often upscaling to a higher resolution, then later downscaling again can provide better PSNR (or similar) results. The differences are usually minor, though.

Quote:
Originally Posted by Zachs View Post
Correct me if I'm wrong but are you saying luma is scaled by a third party and chroma is scaled separately by the studio? My thinking was that they were both scaled by the studio?? e.g. Production company shoots footage in IMAX res, studio scales both luma and chroma to 4:2:0 for Bluray/DVD release. Or in the consumer space, video cams record straight to 4:2:0. TBH I can't see how upscaling chroma twice in that regard could be beneficial as opposed to detrimental in any way.
99.99% of all movie content is available in at least 4:2:2, maybe 4:4:4 to the studios. The studio provides a master to the encoding facility. This master could be the original data the studio has, or already some conversion (e.g. it could be a 2K version of the studio's 4K master). The encoding facility then does any further conversions. I didn't mean to say that luma is scaled by a differently party then chroma. This *could* be the case, but it doesn't have to be, and it wasn't the point I was trying to make, anyway.

One point I'm trying to make is that we have luma available in a higher resolution than chroma. This means that there's a certain chance to use the luma information to guide in chroma upscaling. This method is currently not used in madVR, but it might be in the future. If we downscale chroma to the target resolution first, we're giving away the chance to use the luma information to guide with chroma restauration. But since I'm not using this method yet, this is probably a moot point right now.

A more important point might be that using a somewhat softer algorithm for chroma upscaling can sometimes bring benefits (some studios use rather bad/aliased chroma subsampling algorithms), while for image up/downscaling usually a rather sharp algorithm is what most users would prefer. If you scale chroma directly to the target resolution, you can only use one algorithm: Either a softer one or a sharper one.

Originally madVR used to do the same you're doing: Namely scaling chroma directly to the target resolution. This proved to be suboptimal in some situations, e.g. because when using a softer algorithm for chroma upsampling, the final image got overly soft when using large scaling factors. Just try this with a test pattern: Use a somewhat soft chroma upscaling algorithm (e.g. SoftCubic), and a sharp image upscaling algorithm (e.g. Lanczos), then upscale a small chroma test image by 400% and you'll see that chroma will be blurred a lot. Using a combination of SoftCubic + Lanczos would achieve better results. Some users argue for using a sharp chroma upscaling algorithm, anyway, so for those it might make no difference, though.

Quote:
Originally Posted by Zachs View Post
Personally I have not seen the benefits of scaling in linear light so I haven't done much research into that. However, my thinking is linear light scaling could be done on the individual YUV planes too, couldn't it?
No, that would produce incorrect results. The only proper way to convert the video to linear light is to do Y'CbCr -> R'G'B' -> RGB. You can then convert RGB back to YCbCr if you like. But you *have* to go through R'G'B' -> RGB.
madshi is offline   Reply With Quote
Old 8th October 2014, 10:32   #134  |  Link
Tacio
Registered User
 
Join Date: Jul 2005
Posts: 51
@Zachs

Do you have any plan to implement DXVA scaling? I found out that MadVR's DXVA scaler is quite good for me using Intel HD3000.
Tacio is offline   Reply With Quote
Old 8th October 2014, 12:04   #135  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 8,157
Quote:
Originally Posted by Zachs View Post
@huhn

Can you let me know if the latest version is better in terms of stuttering and if Lanczos and Jinc work without problems this time?
scaling looks fine. i don't see an obvious issue at the moment.

jincs looks pretty good but very unsharp even 8 tabs maybe linear light helps in this case like it helps with catmull-rom.

playback is still not working well this time it didn't work well in fullscreen and windowed.

i guess the issue has something to do with this:
http://abload.de/img/issue4nskk.png

edit: forget that screen happens with very stable numbers too.

Last edited by huhn; 8th October 2014 at 12:08.
huhn is offline   Reply With Quote
Old 8th October 2014, 12:38   #136  |  Link
Zachs
Suptitle, MediaPlayer.NET
 
Join Date: Nov 2001
Posts: 1,721
Quote:
Originally Posted by madshi View Post
Originally madVR used to do the same you're doing: Namely scaling chroma directly to the target resolution. This proved to be suboptimal in some situations, e.g. because when using a softer algorithm for chroma upsampling, the final image got overly soft when using large scaling factors. Just try this with a test pattern: Use a somewhat soft chroma upscaling algorithm (e.g. SoftCubic), and a sharp image upscaling algorithm (e.g. Lanczos), then upscale a small chroma test image by 400% and you'll see that chroma will be blurred a lot. Using a combination of SoftCubic + Lanczos would achieve better results. Some users argue for using a sharp chroma upscaling algorithm, anyway, so for those it might make no difference, though.
Yes I notice it wasn't that long ago that madVR switched to the new algo. The thing about chroma is that our eyes aren't very sensitive to it which is why 4:2:0 exists in the first place. And making every user pay for the extra processing (and power bill) just to satisfy a few vocal ones isn't what I would do. I have plans (longer term) to allow scripting to add stages to the rendering pipeline (such as doubling chroma) via pixel shaders and a script file. It actually isn't that hard to do.

Quote:
Originally Posted by Tacio View Post
@Zachs

Do you have any plan to implement DXVA scaling? I found out that MadVR's DXVA scaler is quite good for me using Intel HD3000.
Yes I noticed that on my Intel HD 3000 too. However, MPDN isn't written with using DXVA at any stage in mind (hence no support for deinterlacing), so supporting it would be quite a massive rewrite. Besides, you *should* be getting DXVA scaling if you were using EVR on every other media player on Windows.

Quote:
Originally Posted by huhn View Post
scaling looks fine. i don't see an obvious issue at the moment.

jincs looks pretty good but very unsharp even 8 tabs maybe linear light helps in this case like it helps with catmull-rom.

playback is still not working well this time it didn't work well in fullscreen and windowed.

i guess the issue has something to do with this:
http://abload.de/img/issue4nskk.png

edit: forget that screen happens with very stable numbers too.
Jinc generally gives a very smooth appearance even when used in upscaling. To get sharper images you could try Lanczos.

If playback stutters this time even in FSE mode, then it is definitely to do with backbuffer count (that's the only thing I changed in regards to playback - D3D9 backbuffer count to 4, D3D10 to 2). Are you still testing on Windows 10 preview? Can you try D3D9 path to see if it is better this time?

From the stats, if the present time is low and delayed frame count doesn't go up, then it's outside of MPDN's control (it'll be Windows or drivers from the moment you call Present()).

Last edited by Zachs; 8th October 2014 at 12:56.
Zachs is offline   Reply With Quote
Old 8th October 2014, 13:03   #137  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Zachs View Post
Yes I notice it wasn't that long ago that madVR switched to the new algo. The thing about chroma is that our eyes aren't very sensitive to it which is why 4:2:0 exists in the first place. And making every user pay for the extra processing (and power bill) just to satisfy a few vocal ones isn't what I would do.
Downscaling is rather the exception than the rule, though. Today most displays are either 1080p or higher, and 99.9% of all content available today is 1080p or lower. So in most cases you need to upscale. Sure, if you have 4K content, there's a chance you need to downscale instead today. But that won't be the norm for long, either. 4K displays are soon going to be everywhere. Handling chroma separately is a very big performance advantage when downscaling 4K to 1080p, but in most other cases, the performance benefit of scaling chroma separately is much smaller.
madshi is offline   Reply With Quote
Old 8th October 2014, 13:25   #138  |  Link
Zachs
Suptitle, MediaPlayer.NET
 
Join Date: Nov 2001
Posts: 1,721
Quote:
Originally Posted by madshi View Post
Downscaling is rather the exception than the rule, though. Today most displays are either 1080p or higher, and 99.9% of all content available today is 1080p or lower. So in most cases you need to upscale. Sure, if you have 4K content, there's a chance you need to downscale instead today. But that won't be the norm for long, either. 4K displays are soon going to be everywhere. Handling chroma separately is a very big performance advantage when downscaling 4K to 1080p, but in most other cases, the performance benefit of scaling chroma separately is much smaller.
Not that soon as most people would've just bought new big screen LCDs in the past few years. I certainly won't be upgrading until my current LCDs kick the dust.

Not to mention a lot of the laptops sold today still spot a 1366x768 screen! In which case, even 1080p videos need to be downscaled. 4K Blu-rays are coming in April 2015. It'll take some time before 4k panels are ubiquitous, definitely not in half a years time!

My point is, pick any given point in time, you'll find that downscaling is a necessity -- 1080p on 1280x1024 or 1366x768 screens, 4K on 1080p screens, and in the future, where 4k screens are ubiquitous (long way yet), 8k on 4k screens and so on.

I'd say it is just as important as upscaling -- you could argue that we should all be watching 1080p contents now, which means you will never need to upscale, only downscale in windowed mode. Or even at 720p, you will never need to upscale chroma to 400%, hence there's no benefits for chroma doubling. In fact, a couple of years back, I threw away my entire DVD collection because I bought a 1080p TV! Even my wife couldn't bare to watch DVDs on a 55" HDTV, regardless of upscaling algo used.

Last edited by Zachs; 8th October 2014 at 13:34.
Zachs is offline   Reply With Quote
Old 8th October 2014, 13:33   #139  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Who is going to buy 4K media for an 1080p display? In my experience the majority of madVR users are asking about upscaling algorithms. Some are asking about downscaling, but it seems to be the minority, at least that's my subjective impression.

BTW, April 2015 appears to be a bit too optimistic for 4K Blu-Ray:

http://www.techradar.com/news/televi...s-2015-1264317
madshi is offline   Reply With Quote
Old 8th October 2014, 13:36   #140  |  Link
dukey
Registered User
 
Join Date: Dec 2005
Posts: 560
Over here there are a lot of 4k tvs on sale.
dukey is offline   Reply With Quote
Reply

Tags
direct3d, mpdn, nnedi3, opencl, reclock

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 10:29.


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