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. |
5th June 2013, 06:20 | #19003 | Link |
Anime Otaku
Join Date: Oct 2002
Location: Somewhere in Cyberspace...
Posts: 437
|
You assume correctly. 60Hz is almost double of 29.97, and using ReClock or something similar will make it exactly double.
__________________
AMD FX8350 on Gigabyte GA-970A-D3 / 8192 MB DDR3-1600 SDRAM / AMD R9 285 with Catalyst 1.5.9.1/ Asus Xonar D2X / Windows 10 pro 64bit |
5th June 2013, 06:54 | #19004 | Link |
Registered User
Join Date: Sep 2009
Location: Sydney, Australia
Posts: 1,073
|
From what I understand, before smooth motion was unintentionally enabled in this situation. (29.97fps vs ~60Hz)
Even if you don't use ReClock, it's probably close enough. My current computer does about 1 frame drop every 2.5 mins which I haven't noticed during watching... yet. For the people who asked about 23.976fps material on a 60Hz screen with smooth motion, it should noticeably improve the smoothness of camera scene panning. Or at least for me, I don't bother changing to my 48Hz screen mode any more. I think it's about as smooth as you can get it without doing anything crazy like frame interpolation. Last edited by namaiki; 5th June 2013 at 07:06. |
5th June 2013, 08:10 | #19005 | Link | |||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
Quote:
Quote:
Yes, definitely. But in order to have a real benefit, you need to make sure that for movie content you get the movies converted to proper 24fps/25fps first. If you use DXVA deinterlacing the output will be 30fps or 60fps, with baked in 3:2 pulldown judder. For interlaced movie content, forcing madVR into film mode is the only way to get smooth motion. |
|||||
5th June 2013, 08:31 | #19006 | Link | |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
Quote:
|
|
5th June 2013, 08:50 | #19007 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
@cyberbeing,
according to the log the key problem is that the GPU render queue doesn't fill up. So it seems that the subtitle rendering somehow affects GPU rendering performance in your case. I find that a bit weird, to be honest, seeing that rendering is mostly limited by the GPU and subtitle rendering should be strictly CPU. However, looking at the log, I'm having a wild guess why this might occur: The renderer asks the subtitle item about the "yuvMatrix". And my impression is that this simple information retrieval often blocks for a looooong time. Is it possible that asking a subtitle item about its yuvMatrix internally runs into some critical sections? And this could stop the renderer from proceeding while the subtitle thread is busy rendering subtitles? If my guess is right, this is not a problem with the size of the subtitle/decoder queue at all. Instead it indicates a design flaw in xy-vsfilter: Asking a simple property like yuvMatrix should not need critical sections, because it's a static information field which never changes (for one subtitle frame). xy-vsfilter should be double checked to limit the use of critical sections to where it is absolutely needed. Also xy-vsfilter shouldn't use just one critical section for everything. That's a sure way to slow multi-threading down. There should be dedicated critical sections to protect specific things. That allows different threads to hold different critical sections while accessing different resources, without negatively affecting each other. Of course the whole design must be perfectly thread safe. But it is very important to also write the code in a way that doesn't slow multi-threading down to a crawl... |
5th June 2013, 10:07 | #19009 | Link | |
Registered User
Join Date: Jul 2011
Posts: 57
|
Quote:
|
|
5th June 2013, 10:10 | #19010 | Link | |
Registered User
Join Date: Jul 2011
Posts: 57
|
Quote:
I noticed today that if I just leave the player the file can begin to play after several minutes but it's very choppy. Dropped frames are in the thousands and the render/presentation queues don't fill up only the decoder queue. |
|
5th June 2013, 11:00 | #19011 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
@ajp2k11, there's no need to try to understand frame drops. The simple reality is that the very first and most important thing madVR needs is reliable information about the vsync scanline information from the GPU. If that already fails, as it seems to in your case, then all hope is lost to get smooth playback with madVR. So don't bother looking at anything other than the refresh rate. Only when that problem is fixed (by changing GPU drivers, GPU BIOS or maybe even GPU hardware), it makes sense to look at anything else.
|
5th June 2013, 11:55 | #19012 | Link |
Registered User
Join Date: Dec 2012
Posts: 68
|
With 0.86.2, seeking (through an x264 encoded file in an .AVI container) seems more choppy. The seek-bar takes longer to update its position. I'm assuming it's not LAV Filter's fault since I've used the same version for a while. This isn't a gamebreaker or anything, but it is less performant than 0.86.1 was.
Also, MadVR decoders are not used in my case. |
5th June 2013, 13:02 | #19013 | Link |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
First, a head-up once again that the name of new subtitle interface filter is XySubFilter.
XySubFilter = New Subtitle Interface (XySubFilter.dll) xy-VSFilter = Legacy Filter (VSFilter.dll) If you could fix madVR's changelog in the next release, and always refer to it as XySubFilter when talking about the new subtitle interface filter in the future, I would be grateful. It's rather confusing when you refer to xy-VSFilter along with new subtitle interface stuff. I'll pass this along, but I'm not sure what you are talking about. Are you saying that madVR will drop frames when it hasn't yet received a response from the subtitle render about the yuvMatix? That seems like a bad design in this particular scenario, considering madVR just flushed its subtitle queue which had a known yuvMatrix, and is requesting the exact same subtitle bitmaps for a new window resolution. You shouldn't be blocking GPU rendering until after all 128 entered the GPU queue and been color corrected and alpha blended with the already known yuvMatrix. In any case, I don't think this is what's going on here. Our own logs indicate that updating yuvMatrix is the first thing XySubFilter does within a few milliseconds of madVR's request, and we render and send new bitmaps a few milliseconds after that. madVR's logs on the other hand, show that the render queue refuses to fill with constant dropped frames until the subtitle queue is 100% full, without any indication of why madVR is refusing to render them. But to put things into perspective, we are talking about ~20-40 subtitle bitmaps per frame here for ~3500+ total bitmaps for all 128 frames. Though as you already know, neither madVR or XySubFilter has been fully optimized for things like this yet, so we don't need to discuss it here if you don't see an immediate solution. I would counter this that you shouldn't design madVR's consumer in a way that it behaves sub-optimally with a single-threaded subtitle provider. |
5th June 2013, 13:10 | #19014 | Link | |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Quote:
Now that Graeme Gill is working on 3DLUT's for mVR, it's only a matter of time until I'll switch back to a LUT file anyway, as he seems to finally put the concept to the full extent of what's technically possible I'll run more tests and will report back. |
|
5th June 2013, 13:11 | #19015 | Link | |
black stain
Join Date: Apr 2013
Posts: 46
|
Quote:
|
|
5th June 2013, 13:38 | #19016 | Link |
Registered User
Join Date: Mar 2009
Posts: 3,650
|
Watched a few episodes tonight, everything played back beautifully. I like how you've nailed the overlay positioning, nice one. I've mentioned this next thing a few times and I know it's not 1.0 yet.. but
When progressing to the next file in the playlist there's that flash of a smaller window, it only happens on the second file to playback all subsequent files keep with a full black screen transition. The window flash was smaller this time (maybe something to do with a code change) considering this window appearance doesn't occur when transitioning beyond the third file I can't help but feel it's likely a simple fix. |
5th June 2013, 14:12 | #19017 | Link | ||||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
That said, I'm not 100% sure that this (meaning XySubFilter getting stuck when I ask it about yuvMatrix) is really what is happening. It is just my best guess, based on what I could see in your log. Quote:
Quote:
Quote:
Quote:
Quote:
|
||||||||
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
Thread Tools | Search this Thread |
Display Modes | |
|
|