Media Player .NET (MPDN) - D3D HQ GPU Video Renderer [v2.49.0/v1.31.0 27 Dec 2018]

[pirlouy]

Unless its using up CPU/GPU to the point of causing resource problems on your system (where you can't do other tasks or watch video on your system successfully) I don't see why that is a problem. If the GPU and CPU aren't being used that could mean that their workload may be getting dumped off to slower parts of the system for handling (like system memory - which can be slower than video memory, or the disk drive - which can be slower than memory - SSD can be excluded from this occasionally).
If CPU and GPU are more used, there are less resources for more demanding operations. Simple.
If a program uses 15% CPU more and 10% GPU more with no differences in the end, it's a drawback. If you call it a feature, you'll have a hard time convince others.

Are you talking about when it says: "optimizing extensions", or are you talking about something else? You could always turn off extensions (and delete that directory to speed things up), but then you'd loose out on features.
It's easy. I double click on a file, I count the time it needs to have the video started.
On a computer, it's 5 seconds for MPC-HC, 7 seconds for MPDN.

Do you plan on watching entire videos on a regular basis with with OSD on the entire time? I doubt it, so what does it matter if OSD uses a few resources when you aren't going to have that active normally?
It's better for comparisons ? Maybe I though there were no more resources with madVR so maybe it's a bug in MPDN. Is this forbidden to report a strange behavior compared to another application ?

Are you saying your system is dropping frames (where you notice on screen problems)? If not what is the problem? If its not dropping frames that is a good thing.
Dude, you really took me for an idiot until the end. But I'll answer anyway because I'm a nice guy. Let's say I take Jinc 64 taps in chroma/Luma upscalind/downscaling. I have dropped frames, visible on screen, which are displayed in OSD when in windowed mode. As soon as I enter fullscreen, dropped frames are not displayed in OSD (I mean the number does not raise) whereas they are clearly visible.

Not all settings can be configured identical for both, so they can't be compared apples to apples.
Well it's obvious there are similarities between madVR and MPDN options. There are at least 20 options which does the same thing (or are supposed to). And since they do the same (display images), it is logical to try to compare both. Do you tell me you did not even compare them ? You just chose MPDN without comparison ?

I think you're getting too wrapped up in insignificant things. The most important things is: Which is giving you better image quality? Which has the features you want to use?
They might be insignificant things for you, not for me, and I'm quite sure I'm not alone. And since I can't tell the differences about quality (I'm not even able to see a difference between bilinear and lanczos or NNEDI), I compare what I can compare: performance graph.

As they both stand I feel MPDN is currently providing the superior video picture on my system, and is why that is my default video program.
I'm very happy for you. I'm happy too, but when I wrote my post, it was to give a review and help the development. But as I said, Zach is free to ignore it or to tell me to stop posting here.

[Zachs]

@pirlouy

I think the comparisons are only suitable where GPU costs are concerned. Even then, MPDN does things very differently to madVR. For example, the algorithms for dithering are completely different. MPDN also uses 2 separate graphs for audio and video - and pre-buffering etc. are all different to MPC/madVR. As you've found out, even GPU costs have to be taken with a grain of salt - different drivers will give you different results. CPU usage wise, the only difference you've pointed out was that MPDN uses more CPU when it had OSD turned on. On my 2nd gen i5, if it rises, it's only by a non-measurable amount. However you have to keep in mind that MPDN refreshes the OSD a LOT more frequently than madVR. The quality of font used also affects the CPU (yes, not GPU) usage. Again, can't compare the two - as Anime Viewer puts it, not an apple-to-apple comparison. MPDN also shows info that madVR doesn't (e.g. 2 or 5 seconds avg/max durations etc while madVR shows a long term average and is much less accurate when GPU clock changes).

I have not seen the dropped frames not increasing problem on my end. Hmm it makes no sense if it would do it in windowed mode and not FSE though. They rely on the same piece of code for dropping frames and counting them. What does your average frame rate show when the frames are visibly dropped? Did it drop at all?

[ryrynz]

@pirlouy
On my 2nd gen i5, if it rises, it's only by a non-measurable amount.

I was curious about this so I tested on my i5 3570. The moving average was 1% higher with the OSD enabled.

[Zachs]

I was curious about this so I tested on my i5 3570. The moving average was 1% higher with the OSD enabled.

Yeah on my 4Ghz i5, it was less than 1% so it was barely showing up as anything at all.

[Magik Mark]

Slight pause is happening from time to time. Its like you are running out of buffer. Any thoughts?

[ryrynz]

Slight pause is happening from time to time. Its like you are running out of buffer. Any thoughts?

My thoughts would be monitor CPU and GPU whilst observing the OSD to determine what it could be, then reset everything to defaults and see if it still does it.
Too many variables to know for sure..

[Belphemur]

Slight pause is happening from time to time. Its like you are running out of buffer. Any thoughts?

I had the same when I was asking too much to my GPU using NNEDI3.
In the end, I discover if the average render time is higher than 42-43 ms, MPDN start "eating" the buffer faster than filling it. It leads to a drop of frame.

Try to tweak the different Renderer you are using.

[Anime Viewer]

And an anomaly to finish this boring post: dropped frames are not reported on FullScreen Exclusive (I use D3D9).



As Zachs has written in other posts different drivers can run better in different D3D modes. With one driver version D3D9 may work better, and with the next driver release D3D10.1 or D3D11 might run better. Have you tried with with the other D3D presentation modes in MPDN to see if they make a difference? Just because you choose to use D3D9 in madVR it doesn't mean that D3D9 is the best choice for you in MPDN.

[Shiandow]

WARNING, do not update to the latest renderscripts. There might be a bug with Script Chain again. I'll remove this warning when I'm sure it's safe again.

Okay, renderscripts should be safe again.

[pirlouy]

http://i.imgur.com/XrOJFFr.jpg

Indeed it depends on files and shaders used. If I used harder shaders, dropped frames counter will increase. But in this example, counter does not raise whereas it should.

[Belphemur]

http://i.imgur.com/XrOJFFr.jpg

Indeed it depends on files and shaders used. If I used harder shaders, dropped frames counter will increase. But in this example, counter does not raise whereas it should.

Those number seems fine to me. From my understanding (but I can be wrong), dropped frame or not, the rendering time won't change.

Because first the image get pass through the renderer and then feeded to the player that decide if the delay between audio and video is too big to keep the frame, in that case it drops it.

The time to render a frame won't be impacted by the dropped frame.

Btw you should test also by keeping the player in window mode with the resolution of your video compared to fullscreen.

[Magik Mark]

Is there a website that would compare images from different chroma & luma scaling options? This is handy when making our choices. Maybe other rendering scripts as well

[Zachs]

http://i.imgur.com/XrOJFFr.jpg

Indeed it depends on files and shaders used. If I used harder shaders, dropped frames counter will increase. But in this example, counter does not raise whereas it should.

It's behaving correctly - it shouldn't be dropping in the FSE mode because your average render time is less than 41.67ms (video frame interval), and render queue is thus filled up fully. If you see dropped frames visibly, it's a problem outside of what is detectable by MPDN.

[Magik Mark]

Zach

Can you help us classify which are heavy, medium & light shaders / renderers? This could help us choosing better configurations. Thanks

[Zachs]

This is a very hard question to answer, mainly because it really depends on the GPU / driver / source content / shader settings / renderer settings etc.

Generally though, the following should be true (from least costly to most expensive), using default settings.

MPDN hardware scalers
MPDN pixel shader scalers
NEDI
NNEDI3

The SuperRes filter augment the scalers and adds more costs to it depending on its settings.

You'll have to try it for yourself - the player statistics OSD is the tool to let you decide which settings to pick for a particular source content.
Different source contents (fps, resolution, etc.) will require different scalers and will put different loads on the GPU.

[Belphemur]

This is a very hard question to answer, mainly because it really depends on the GPU / driver / source content / shader settings / renderer settings etc.

Generally though, the following should be true (from least costly to most expensive), using default settings.

MPDN hardware scalers
MPDN pixel shader scalers
NEDI
NNEDI3

The SuperRes filter augment the scalers and adds more costs to it depending on its settings.

You'll have to try it for yourself - the player statistics OSD is the tool to let you decide which settings to pick for a particular source content.
Different source contents (fps, resolution, etc.) will require different scalers and will put different loads on the GPU.

Could you make the render time change color when going higher than 41.67ms ?

It would help people to understand when the frame start dropping and that new render settings are needed :)

[Zachs]

It's not always higher than 41.67ms. In fact, you could have a source clip that delivers variable frame rates and MPDN will still be able to cope (yes it supports variable fps). Not to mention that you can change this output rate via render script too.

[Belphemur]

It's not always higher than 41.67ms. In fact, you could have a source clip that delivers variable frame rates and MPDN will still be able to cope (yes it supports variable fps). Not to mention that you can change this output rate via render script too.

What is the formula used to drop a frame ? It could help to create a "optimization" guide for MPDN :)

[Zachs]

There's a few things that could cause a dropped frame, but the most common one would be caused by the frame timestamp being earlier than current reference clock. Your render queue tends to run low when that happens.

Btw some GPUs/drivers don't like running at over 90% load. When that happens, you'll find frame deliveries start to get choppy even when the driver tells MPDN everything is fine.

The trick is to back off enough to give the GPU a bit of headroom to do what's important - presenting the frames smoothly.

On my nvidia cards I've got no problem running them at 40ms for 23.976fps materials. Fans would scream but it's smooth as.

[Zachs]

@AnimeViewer, do you still get the lockup problem when you go into of FSE mode?

[Anime Viewer]

@AnimeViewer, do you still get the lockup problem when you go into of FSE mode?

I installed the the most recent version (v2.26.3) on top of my previous version (using the new installer), and still had the problem. I wiped out (uninstalled) MPDN from control panel, and then went into my MPDN profile settings (in C:\Users\Myname\AppData\Local and deleted the MediaPlayerDotNet directory (to reset everything). It worked in that default state (D3D 9Ex), but when I try either of the other (D3D 10.1 or D3D 11) its back to freezing the window/screen (except sometimes I can hear audio still playing).

On another note XYSubFilter seems to be a problem in the new version. When subtitles are on the screen the rest of the screen (aside from the subtitles) turns black. When characters stop talking (thus no subtitles) the video appear back on the screen, but the minute the subtitles appear again the screen turns black again until the subtitles disappear off the screen.

[Magik Mark]

Zach

What happened? All I get is black screen & audio

[Zachs]

Did you guys use the installer? I suspect it may be due to a bad XySubFilter version. I'll investigate later when I get done time. In the meantime, try downloading another version of the filter and install that instead.

@animeviewer did you manage to get the dump file when it locked up? It should crash on purpose when it detects a lockup after about 5 seconds. You'll then get a dump file. Check my post a few pages back.

[Magik Mark]

Zach

It wasn't the xysubfilter. Its something else. Reverted back to its predecessor. Everything is ok now

[Zachs]

Well then it's certainly something I'm not experiencing on my end. Is the OSD showing?

Anyway I'll investigate.

[Magik Mark]

Yes OSD is fine

[Zachs]

So just to confirm, 2.26.2 was fine?

Can you also zip up your MPDN config folder so I could use the same settings to try and replicate the problem?

[Magik Mark]

So just to confirm, 2.26.2 was fine?

Can you also zip up your MPDN config folder so I could use the same settings to try and replicate the problem?

Yes! Working perfectly for now

[Zachs]

You might wanna upload the file on a file upload website, that way I don't have to wait for the attachment to be approved.

[japa]

2.26.2 -> works great
2.26.3 -> turn on any render script even blank one=no video only audio and xysubfilter blinking picture as explained by Anime Viewer

By blank one I mean you can select image processor with no shaders and the moment you press apply blank picture.

Great player BTW :-)

[Zachs]

Thanks for the report. Appreciate it.

In the meantime, I'd recommend just to use 2.26.2 for now until I sort out the issues with the latest version.

[Anime Viewer]

@animeviewer did you manage to get the dump file when it locked up? It should crash on purpose when it detects a lockup after about 5 seconds. You'll then get a dump file. Check my post a few pages back.

It doesn't appear to create any dump file (I'm not sure that it detects a crash). Since it locks the screen (keyboard still works for capslock, numlock , ctrl+alt+delete, alt-tabing (even though it will not switch to anything else. Unless you choose ctrl+alt+del and choose log-off. At that time you can alt-tab between windows, but can't interact or navigate on any of them. The MPDN app shows in the taskbar, but right-clicking on it and choosing close all windows will not do anything (it doesn't react). The only way to shut out of it is to tell it to switch users (or restart). As far as I can tell it didn't create any file in the user config folder, nor the install location of MPDN.

[Zachs]

Was the mouse cursor showing a wait cursor or was it a normal pointer cursor? The next time it happens, could you wait for 30 seconds and see if it manages to detect that it's locked up?

[ryrynz]

So my TV accepts 12 bit input at <24hz but Nvidia's drivers don't remember the previous setting at that refresh rate.
Any chance of having MPDN be able to set the bit depth output of the graphics card via the display changer?

[burfadel]

2.26.2 -> works great
2.26.3 -> turn on any render script even blank one=no video only audio and xysubfilter blinking picture as explained by Anime Viewer

By blank one I mean you can select image processor with no shaders and the moment you press apply blank picture.

Great player BTW :-)

Exact same issue here!

[Anime Viewer]

Was the mouse cursor showing a wait cursor or was it a normal pointer cursor? The next time it happens, could you wait for 30 seconds and see if it manages to detect that it's locked up?

No, the mouse cursor does not show during the MPDN freeze. I've waited longer than 30 seconds (a few minutes with nothing changing).

[Zachs]

Exact same issue here!

Fixed in v2.26.4.

[Zachs]

No, the mouse cursor does not show during the MPDN freeze. I've waited longer than 30 seconds (a few minutes with nothing changing).

OK try this when you have the chance. When it locks up, double click the full screen windows a few time. Then wait for 30 seconds. If it still doesn't auto-terminate, it probably means something terminal has occurred...

[Anime Viewer]

OK try this when you have the chance. When it locks up, double click the full screen windows a few time. Then wait for 30 seconds. If it still doesn't auto-terminate, it probably means something terminal has occurred...

Edit:
It froze again, and I double clicked (when there is a nonexistent mouse cursor during the initial freeze), and nothing ever happened). After I did switch user to were it is still running, and I double clicked on it on the taskbar (again with no change, and it not switching to it) I again waited 30+ seconds but nothing ever happened. Task Manager in that state reports it as not responding, but it never times out (and just like how I can't interact with MPDN I can't interact act with any other programs except to switching to them with alt-tab, but I can't do anything other than display their windows - for example I can't scroll or type anything on this forum), and can't close out of them during that non-responsive MPDN state.

Edit:
Odd. It doesn't appear to occur with one file I have tested (with the following properties).

Unique ID : 0
Complete name : (file name omitted)
Format : Matroska
File size : 157209197
Duration : 1452199
Overall bit rate : 866048
Encoded date : 2/22/2010 9:41:29 PM
Writing application : no_variable_data
Writing library : no_variable_data

Video
ID : 1
Format : AVC
Format profile : Main@L3.1
Format settings : CABAC / 6 Ref Frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1452202
Bit rate : 0
Width : 848
Height : 480
Display aspect ratio : 1.006
Frame rate mode : CFR
Frame rate : 23.976
Chroma subsampling : 4:2:0
Bit depth : 8
Scan type : Progressive
Bits/(Pixel*Frame) : 0
Stream size :
Writing library : x264 - core 120 r2120 0c7dab9
Encoding settings : cabac=1 / ref=6 / deblock=1:1:1 / analyse=0x1:0x111 / me=umh / subme=8 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=768 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=1536 / vbv_bufsize=3840 / nal_hrd=none / ip_ratio=1.40 / aq=1:0.60
Language :

Audio
ID : 2
Format : AAC
Codec ID : A_AAC
Duration : 1452199
Bit rate mode :
Bit rate : 0
Channel(s) : 2
Sampling rate : 44100
Bit depth : 0
Compression mode : Lossy
Stream size : 0
Language :

Subtitle
ID : 3
Format : ASS
Muxing Mode :
Codec ID : S_TEXT/ASS
Language :


But appears to occur with every other file I test. (For example):

Unique ID : 199100304361845660068191694678274133701
Complete name : (file name ommited)
Format : Matroska
File size : 474810722
Duration : 1440000
Overall bit rate : 2637837
Encoded date : 5/17/2015 11:53:54 AM
Writing application : mkvmerge v7.7.0 ('Six Voices') 32bit built on Feb 28 2015 23:23:00
Writing library : libebml v1.3.1 + libmatroska v1.4.2

Video
ID : 18041449390369659311
Format : AVC
Format profile : Main@L4.1
Format settings : CABAC / 6 Ref Frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1439982
Bit rate : 0
Width : 1280
Height : 720
Display aspect ratio : 1
Frame rate mode : CFR
Frame rate : 23.976
Chroma subsampling : 4:2:0
Bit depth : 8
Scan type : Progressive
Bits/(Pixel*Frame) : 0
Stream size :
Writing library : x264 - core 142 r2479 dd79a61
Encoding settings : cabac=1 / ref=6 / deblock=1:1:1 / analyse=0x1:0x111 / me=hex / subme=7 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=5 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=2432 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=50000 / vbv_bufsize=62500 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:0.60
Language : ja

Audio
ID : 15032933852594981766
Format : AAC
Codec ID : A_AAC
Duration : 1440000
Bit rate mode :
Bit rate : 0
Channel(s) : 2
Sampling rate : 48000
Bit depth : 0
Compression mode : Lossy
Stream size : 0
Language : ja

Subtitle


Edit:
On the frozen video screen if I have CTRL+J active it shows the Render queue at 0/12 at the point it switched and froze. Running with "Use new windowed mode rendering path when possible" unchecked the problem doesn't appear to occur in the second video - that normally freezes. **edit: scratch that...it still occurred with new mode unchecked, but for some reason that one time it didn't.

Edit:
Anyone else noticing Fluid Motion fluctuating on and off almost every second when watching 23.976Hz files on 59/60Hz screens? (Its actually causing Judder (and tons of dropped and delayed frames - probably as a result of the constant switching on and off) on my screen as opposed to the same video running smoothly with it turned off).

[Magik Mark]

Hey Zach

Do you know where I can download denoise shader for your player? Maye other shaders as well too? Thanks a lot

[Anime Viewer]

Hey Zach

Do you know where I can download denoise shader for your player? Maye other shaders as well too? Thanks a lot

MPDN users shaders with the extension HLSL. If you already have them on your system from another video player (Ex: MPHC/MadVR) then you just need to copy if from one location to another. (EX: E:\Program Files\KCP\MPC-HC\Shaders to E:\Program Files\MediaPlayerDotNet\Extensions\RenderScripts\ImageProcessingShaders). From there you'd go into Options, Render Scripts, select Image Processor (if that is where you copied it to), click the +, and add it inside the shader chain there.
Be aware that it may not have been tested in combination with other scripts/shaders you may use in MPDN, so it may not give you the effect you are looking for. From what I recall MPDN had a Denosie script a while back (that may be named something else now), so you may not have to do all this to begin with...

Edit: Anyone have a theroy on what is causing the distortion to the image shown below? Both are running at their native resolution, so scaling is not at play. Both have the same dithering (ordered) selected, and both are using Shiandow's debanding at the same strength, so those shouldn't be the issue.

Image on the left side is with madVR. Image on the right side is with MPDN. (http://s12.postimg.org/q7av6vm6j/what_is_the_cause.jpg)
http://s12.postimg.org/q7av6vm6j/what_is_the_cause.jpg

[Magik Mark]

Can somebody test this flickering issue in d3d 11 16bit:

When I switch to d3d window full screen, screen flickers. Looks like refresh rate changes without consent
d3d windowed (not full screen) - ok
d3d FSE - ok

Nvidia v352.86, GTX 550ti, Pioneer Kuro

[Zachs]

just like how I can't interact with MPDN I can't interact act with any other programs except to switching to them with alt-tab, but I can't do anything other than display their windows - for example I can't scroll or type anything on this forum), and can't close out of them during that non-responsive MPDN state.


This sounds more like a system wide failure than just MPDN failing. No wonder the detection mechanism failed to pick up anything - it's probably locked up like the rest of the system too.

Just run me through how you cause the problem to occur again - particularly, do you use double-click or alt+enter to enter FSE mode? Does it happen every time and immediately when you go FSE?


Anyone else noticing Fluid Motion fluctuating on and off almost every second when watching 23.976Hz files on 59/60Hz screens? (Its actually causing Judder (and tons of dropped and delayed frames - probably as a result of the constant switching on and off) on my screen as opposed to the same video running smoothly with it turned off).

The only thing that could cause fluid motion to turn off is when your render queue goes below 2 - it needs one frame rendered in advance for fluid motion to function.


Edit: Anyone have a theroy on what is causing the distortion to the image shown below? Both are running at their native resolution, so scaling is not at play. Both have the same dithering (ordered) selected, and both are using Shiandow's debanding at the same strength, so those shouldn't be the issue.

Image on the left side is with madVR. Image on the right side is with MPDN. (http://s12.postimg.org/q7av6vm6j/what_is_the_cause.jpg)
http://s12.postimg.org/q7av6vm6j/what_is_the_cause.jpg

Does this happen when you have no render scripts running?

Can somebody test this flickering issue in d3d 11 16bit:

When I switch to d3d window full screen, screen flickers. Looks like refresh rate changes without consent
d3d windowed (not full screen) - ok
d3d FSE - ok

Nvidia v352.86, GTX 550ti, Pioneer Kuro

Windowed full screen mode is just like any other windowed mode except its window size is the same as your display resolution. In fact, MPDN doesn't treat it any differently. I've also just tested it out on 3 different machines with different GPUs and none have this problem.

[huhn]

Edit: Anyone have a theroy on what is causing the distortion to the image shown below? Both are running at their native resolution, so scaling is not at play. Both have the same dithering (ordered) selected, and both are using Shiandow's debanding at the same strength, so those shouldn't be the issue.

Image on the left side is with madVR. Image on the right side is with MPDN. (http://s12.postimg.org/q7av6vm6j/what_is_the_cause.jpg)
http://s12.postimg.org/q7av6vm6j/what_is_the_cause.jpg

looks like the right screen has the wrong levels and is clipping all dark details. it's not the same screens so hard to judge.

open the same Scene in madVR press alt + control + shift + i until you see TV double expanded. if this give you the same artefacts i guessed right.

[Shiandow]

Edit: Anyone have a theroy on what is causing the distortion to the image shown below? Both are running at their native resolution, so scaling is not at play. Both have the same dithering (ordered) selected, and both are using Shiandow's debanding at the same strength, so those shouldn't be the issue.

Image on the left side is with madVR. Image on the right side is with MPDN. (http://s12.postimg.org/q7av6vm6j/what_is_the_cause.jpg)
http://s12.postimg.org/q7av6vm6j/what_is_the_cause.jpg

Looks like the kind of artefacts the chroma limiter can cause, try disabling "Improve chroma reconstruction".

[Anime Viewer]

Looks like the kind of artefacts the chroma limiter can cause, try disabling "Improve chroma reconstruction".

Right you were, it was the Improve Chroma Reconstruction that was at fault. :thanks:

it's not the same screens so hard to judge.

It was the same scene in that both were taken from 18 minutes and 30 seconds into the video, and the video (and others) had it those large parts of their playback when it came to dark blue/black backgrounds (space, air, etc). Regardless Shiandow was right and the "improve chroma reconstruction" wasn't improving things, but hurting instead.

This sounds more like a system wide failure than just MPDN failing. No wonder the detection mechanism failed to pick up anything - it's probably locked up like the rest of the system too.

Just run me through how you cause the problem to occur again - particularly, do you use double-click or alt+enter to enter FSE mode? Does it happen every time and immediately when you go FSE?

The only thing that could cause fluid motion to turn off is when your render queue goes below 2 - it needs one frame rendered in advance for fluid motion to function.



I double click to enter FSE (I'll try using ALT+Enter to see if it has the same effect). It does happen every time (except for the one file I previously noted) I enter FSE with Direct3D 11 or 10.1 selected (it doesn't seem to happen with 9Ex). It happens immediately once full screen occurs it doesn't appear a single frame plays in fullscreen before the freeze. *Edit: odd ; my tests today don't seem to be freezing. I'm not sure what to attribute the problem going away to, but its nice that the problem is gone (hopefully it will stay that way)...

I can't seem to recreate the fluid motion on/off issue. If it reoccurs again I'll pay attention to what the queues do.

[ryrynz]

Looks like the kind of artefacts the chroma limiter can cause, try disabling "Improve chroma reconstruction".

Without having a black or white list for use with this option so that the artefacts hopefully won't appear the option isn't very useful.

[Zachs]

Yeah there's a reason why it's not enabled by default and comes with a warning that says it's not compatible with all sources. :)

[madshi]

Right you were, it was the Improve Chroma Reconstruction that was at fault. :thanks:
Can we have a small sample of this scene, please? It's always useful to have samples which make problems like this.

[ryrynz]

Can we have a small sample of this scene, please? It's always useful to have samples which make problems like this.

Apparently there's quite a few videos out there with out of range chroma values, if that's what indeed caused that issue above. I encountered it straight away on a 720 H.264 rip and mentioned it to Zach.
It appears there's nothing that can be done in this instance, which kinda makes that chroma reconstruction option useful for videos you know don't have that issue.