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 June 2013, 02:21   #19001  |  Link
karamancho
black stain
 
karamancho's Avatar
 
Join Date: Apr 2013
Posts: 46
Quote:
Originally Posted by Soukyuu View Post
A question though, which material does smooth motion work with, as I don't seem to see a difference with your regular 23,97fps anime?
I was wondering the same ting. Are there any benefits in using smooth motion with (torrented) DVD/BR/HD rips played on a laptop display?
karamancho is offline   Reply With Quote
Old 5th June 2013, 05:53   #19002  |  Link
mindbomb
Registered User
 
Join Date: Aug 2010
Posts: 576
i notice now smooth motion (on the "only if motion judder without it" setting) doesn't turn on now if 29.97 fps on 60hz.
is that because it's close enough?

Last edited by mindbomb; 5th June 2013 at 06:01.
mindbomb is offline   Reply With Quote
Old 5th June 2013, 06:20   #19003  |  Link
cca
Anime Otaku
 
Join Date: Oct 2002
Location: Somewhere in Cyberspace...
Posts: 437
Quote:
Originally Posted by mindbomb View Post
i notice now smooth motion (on the "only if motion judder without it" setting) doesn't turn on now if 29.97 fps on 60hz.
is that because it's close enough?
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
cca is offline   Reply With Quote
Old 5th June 2013, 06:54   #19004  |  Link
namaiki
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.
namaiki is offline   Reply With Quote
Old 5th June 2013, 08:10   #19005  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Soukyuu View Post
A question though, which material does smooth motion work with, as I don't seem to see a difference with your regular 23,97fps anime?
In theory it should "work" for any content. Is that anime content progressive or interlaced? If you deinterlace interlaced anime without forcing madVR into film mode, the output of the deinterlacer will be 59.940fps, so there's not much left for smooth motion FRC to do. Anime also isn't the best candidate for what smooth motion FRC does. FRC works best with smooth "soft" movements. Anime often has very "hard" movements. Such movements don't "blend" too well. But it should still work somewhat...

Quote:
Originally Posted by cyberbeing View Post
now with a queue of 128, I end up with ~80 dropped frames (i5-3570K @4.4Ghz) as the subtitle queue attempts to refill
Can you please upload a small log which shows those 80 frame drops?

Quote:
Originally Posted by TheShadowRunner View Post
A quick bug report (not due to this new build, as I tested with 0.86.1):
madvr has troubles rendering videos encoded with Cinepak/CVID, the display is all screwed up.
A sample file: here.
In the exact same graph, replacing madvr by the VMRs or EVR solves the issue.
I can't find this in the bug tracker?

Quote:
Originally Posted by leeperry View Post
but if PS scripts are limited to TV range in MPC by design, then how come
Quote:
Originally Posted by leeperry View Post
and I guess PS scripts applied on 0-255 source files(FRAPS for instance) will be a no-go as well
Is there a specific point to your questions? I thought the problem with your gamut PS script was solved? So why still asking weird follow up questions? Do you still have problems or not? I would have to re-study what MPC-HC's internal renderers do exactly to answer your questions, and if your questions are just about making a point, or about satisfying your curiosity, then I really have better things I can spend my time with...

Quote:
Originally Posted by karamancho View Post
I was wondering the same ting. Are there any benefits in using smooth motion with (torrented) DVD/BR/HD rips played on a laptop display?
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.
madshi is offline   Reply With Quote
Old 5th June 2013, 08:31   #19006  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Quote:
Originally Posted by madshi View Post
Can you please upload a small log which shows those 80 frame drops?
http://www.mediafire.com/?61l9bvs640sn1v7
cyberbeing is offline   Reply With Quote
Old 5th June 2013, 08:50   #19007  |  Link
madshi
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...
madshi is offline   Reply With Quote
Old 5th June 2013, 09:17   #19008  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,752
Quote:
Originally Posted by karamancho View Post
(torrented) DVD/BR/HD rips
... are no topic here (see FR6). Make copies of your purchased movies, but keep them for yourself (and few friends at most).
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is online now   Reply With Quote
Old 5th June 2013, 10:07   #19009  |  Link
ajp2k11
Registered User
 
Join Date: Jul 2011
Posts: 57
Quote:
Originally Posted by digitech View Post
Just to make sure... check if you are having another instance of your same video player running in the background, it has happened to me more than once that i already was having two mpc running at the same time thinking i was able to close the first one correctly, then a blank screen appears when i accidentally open the second time the same player and left the first one running, i hope you can understand my lingo-english.
Thanks for the suggestion but this happens on a freshly booted computer as well.
ajp2k11 is offline   Reply With Quote
Old 5th June 2013, 10:10   #19010  |  Link
ajp2k11
Registered User
 
Join Date: Jul 2011
Posts: 57
Quote:
Originally Posted by madshi View Post
EVR has a totally different presentation logic, it doesn't depend on vsync scanline information.

Not sure why it only occurs with specific video files. Makes no sense to me, unless you're using DXVA decoding and/or DXVA deinterlacing? Try with software decoding and try with deinterlacing turned off. But really, I simply don't have enough information to do anything about this...
I use software decoding already but I will try and turn off deinterlacing everywhere, thanks.

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.
ajp2k11 is offline   Reply With Quote
Old 5th June 2013, 11:00   #19011  |  Link
madshi
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.
madshi is offline   Reply With Quote
Old 5th June 2013, 11:55   #19012  |  Link
Schwartz
Registered User
 
Join Date: Dec 2012
Posts: 67
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.
Schwartz is offline   Reply With Quote
Old 5th June 2013, 13:02   #19013  |  Link
cyberbeing
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.

Quote:
Originally Posted by madshi View Post
@cyberbeing
...
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.

Quote:
Originally Posted by madshi View Post
But it is very important to also write the code in a way that doesn't slow multi-threading down to a crawl...
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.
cyberbeing is offline   Reply With Quote
Old 5th June 2013, 13:10   #19014  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by madshi View Post
why still asking weird follow up questions? Do you still have problems or not? I would have to re-study what MPC-HC's internal renderers do
OK my bad, I was under the impression that your HLSL was as fluent as your english

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.
leeperry is offline   Reply With Quote
Old 5th June 2013, 13:11   #19015  |  Link
karamancho
black stain
 
karamancho's Avatar
 
Join Date: Apr 2013
Posts: 46
Quote:
Originally Posted by madshi View Post
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.
what about 24fps progressive content? does any of this apply?
karamancho is offline   Reply With Quote
Old 5th June 2013, 13:38   #19016  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,646
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.
ryrynz is offline   Reply With Quote
Old 5th June 2013, 14:12   #19017  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Schwartz View Post
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.
I don't know which code change could have resulted in this problem. Are you sure there's really a slowdown in v0.86.2 compared to v0.86.1? If so, please create a bug tracker entry and upload a small sample with which you can reproduce the problem. Thanks.

Quote:
Originally Posted by cyberbeing View Post
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)
I'll try to remember. The names are not too intuitive to me, though, since the basic rendering code in XySubFilter is still based on the original VSFilter rendering code, and "XySubFilter" is a very generic name, which doesn't specifically contain anything point to the "new" subtitle interface, either. So basically both names would in theory work for both solutions. Anyway, I've modified the changelog and I'll try to remember in future...

Quote:
Originally Posted by cyberbeing View Post
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.
I'm not blocking *anything*. Part of the madVR rendering code is that I'm asking XySubFilter about the yuvMatrix used for the current subtitle frame. In theory it could be different for every frame. So I'm asking the yuvMatrix again for every rendered frame. That's a very simple "tell me your yuvMatrix, please" question which the madVR rendering thread asks XySubFilter. And this question seems to get stuck inside of the XySubFilter code for a very long time. So basically XySubFilter gets stuck, and this stalls the madVR rendering thread. There's nothing I can do about this because the rendering isn't stuck in my code, but in XySubFilter, it seems. There's no good reason (at all) for XySubFilter to get stuck when I ask it about yuvMatrix. So this is very very clearly a problem with XySubFilter. No offense, but if you say that this is a problem with madVR then you clearly don't know what you're talking about, from a software development point of view.

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:
Originally Posted by cyberbeing View Post
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.
Actually, there is an indication (but no proof) that madVR is not refusing anything, but that the render queue is getting stuck because XySubFilter gets stuck when madVR asks it about yuvMatrix.

Quote:
Originally Posted by cyberbeing View Post
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.
We don't need to discuss it, but if my guess is right, fixing this in XySubFilter should be rather easy.

Quote:
Originally Posted by cyberbeing View Post
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.
I have not designed it that way. It is of no consequence to me whether the subtitle provider is single threaded or multi-threaded. But I do expect the subtitle provider to not get stuck for a long time when I ask it a simple question for which the answer is already known.

Quote:
Originally Posted by karamancho View Post
what about 24fps progressive content? does any of this apply?
No.

Quote:
Originally Posted by ryrynz View Post
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.
From what I remember, something like this had been reported months ago and I had fixed it, and it was reported to be actually fixed. Not sure if what you're experiencing is a new problem, or if the fix doesn't work for you, or if the fix and unfixed itself at some point. Right now I'm not really feeling like looking into this, though.
madshi is offline   Reply With Quote
Old 5th June 2013, 14:42   #19018  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
P.S: @cyberbeing, I've double checked the rendering code. It's probably either ISubRenderProvider::GetString("yuvMatrix") or ISubRenderFrame::GetOutputRect() which stalls inside of XySubFilter.
madshi is offline   Reply With Quote
Old 5th June 2013, 15:04   #19019  |  Link
eXtremeDevil
Registered User
 
eXtremeDevil's Avatar
 
Join Date: Jul 2010
Posts: 164
I'm trying to use madVR with BSPlayer with I can't get it to work, it never shows up the video... do I need to do anything special? It works fine with MPC-HC with no extra configuration...
eXtremeDevil is offline   Reply With Quote
Old 5th June 2013, 15:17   #19020  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
That's a question you should probably ask the BSPlayer developer(s). Most people here use different media players, so there's not much experience here that could help you...
madshi 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 09:57.


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