Search options (Page 12 of 55)

Basically the tone that I am interpreting from certain things you say feels close to FUD at times - fear, uncertainty, and doubt.

The way I see it, if I wanted to fully explain framerates and drop frames and fractional refresh rates and the like then I would have done so.  However, the purpose of this thread was never about matching your refresh rate exactly exactly to your framerate because then that gets into the mess of whether your "60.00Hz" is actually 60.000 and not 60.006Hz and the like.

My overall point that I was targeting was a general understanding that working with non-fractional multiple for your framerates works better than if you didn't, that is all.  The 24, 25, and 30fps examples were just that - examples to easily convey this idea.  If I were to cover a more complete explaination then I would have included things 20fps and HFR framerates like 48fps, 50fps, and yes the various drop-frame framerates like 30000/1001.

This statement of yours is really not clear at all to me; what are you referring to when you say that SVP will ask you to convert?  I say this because I've never had SVP ask me anything outside of the initial performance assessment - it just does whatever the according video profile is configured as.

Well then we'll just have to agree to disagree.  I already acknowledged that many TVs don't support custom resolutions, but even without them the EDID is a standardized function across any sort of digital display (TVs, monitors, projectors, etc).

Or are you trying to say that the user should not actually trust the EDID?

I point to my earlier statement in this post - this thread was never intended to get into the nitty-gritty because I wanted to provide the most bang-per-buck that I could among users.  In other words, if I typed up a term paper, then this would only benefit a small minority as the kind of person that would read and/or understand it would very likely already be familiar with everything I was already stating.

To use a business term, I was trying to reach the "blue ocean", and yes this did involve what some would call "dumbing it down", but you can't expect to have a toddler understand calculus, and teaching that toddler something a bit more than just basic addition or subtraction was my goal going in.

EDIT: I have edited the beginning of my opening post in an attempt to make it more clear what I was trying to convey with this thread.

EDIT 2: See the updated thread here:
http://www.svp-team.com/forum/viewtopic.php?pid=61595

I realize that it's not your intention, but I just want you to know that some of the things your saying are a bit too close to FUD-like, so you may want to be a bit more careful with what you're trying to convey in the future; the last thing any PC enthusiast would want to happen is to scare someone from tinkering with their own PC seeing how that's how many of us got to where we are with our PC enthusiasm in the first place.

But this is simply not true - 29.97fps content turns into 59.94 while 30.00fps content turns into 60.00, and this occurs regardless of whether your refresh rate is 59.94Hz or 60.00Hz; SVP does not use 59.94 for both 29.97 and 30.00fps.

But any flat panel TV that doesn't support 60.00fps is in fact out of spec because both ATSC and DVB specs list support for not only 59.94Hz but 60.00Hz as well.

This to me sounds like you're saying that 60.00Hz doesn't exist on TVs, which is completely wrong considering that even old pre-color black and white content was broadcast in 60.00fps interlaced.

A TV's EDID wouldn't list 60.00Hz if it didn't work - that's the point of an EDID after all!

The result is literally as I state it to be - something like 25fps--to->60Hz feels faster but less smooth than 25fps--to->50fps.

PC monitors have supported multiple refresh rates for literally decades; 75Hz was/is actually quite common and only fell out of use around the late 2000s when CRTs become uncommon enough that it was assumed that the display was always LCD, and LCDs don't result in crazy flicker at 60Hz like CRTs do so 75Hz was no longer necessary leading to a lot of things only using 60Hz; by comparison an LCD monitor being capable of 75Hz in 2005 wasn't unheard of at all since 75Hz was much more common then due to CRTs.  This was all without the use of custom resolutions and simply selecting different refresh rates via the normal Windows "Monitor" tab under "Advanced settings" (which itself simply lists the values provided by the display's EDID).

Besides, never in my entire 10 years using custom resolutions have I actually damaged a display (CRT, LCD, laptop, and TV) even when running outside of the EDID's spec, so I'm not about to start telling people that changing their refresh rate to something that's already listed in their EDID is going to break their hardware.  But even when you're running outside of the display's EDID you should never be able to break anything because it's not like we're sending the display a non-standard video signal anyway - there's nothing about the digital video connections in use (internal or external) that restrict the ability to use a different refresh rate, otherwise you wouldn't be able to have TVs that support 24Hz, 50Hz, and 60Hz out-of-the-box (which is particularly important in Europe where all 3 refresh rates are common).

Only if the source content is 29.97fps rather than 30.00fps, but even then the difference is quite minor since it doesn't actually change anything with the interpolation unlike the difference between 24fps--to->60Hz and 24fps--to->72Hz.

I personally do not use DVBViewer, though I couldn't do so even if I wanted to as I don't live in a country that uses DVB... so I can't really help you with that specific program, only with more generic SVP-related things.

Sorry. :/

If you haven't done so already, try to manually set the amount of threads that SVP uses - it tends to be too conservative on fast CPUs thereby resulting in poor performance; with that CPU you could easily use like 19 threads if not more (see attached image).

You're not trying to play a native 60fps video by chance, are you?

If you are, then see this thread:
http://www.svp-team.com/forum/viewtopic.php?pid=56025

(that thread also mentions several optimizations for SVP on 144Hz monitors)

I don't know about Linux, but at least on Windows the short video clip attached to the following post is known to work perfectly with SVP:
http://www.svp-team.com/forum/viewtopic … 436#p52436

Considering that I ran SVP all the time on a 2.4GHz Core 2 Duo without any sort of GPU acceleration or hardware decoding, and SVP loves "moar cores", I don't think performance would be all that bad.

Really, the biggest thing is that the automatic settings would need some serious optimization, because last time I checked, the automatic settings used some pretty bad settings on low-end hardware:
http://www.svp-team.com/forum/viewtopic.php?id=2699

Is it jerky even with the copy of MPC-HC that is provided with SVP?

I haven't found a foolproof solution to the flickering issue, but I have figured out a lot about what it's deal is.

Simply put, at least on the NVS 3100m, the flicker goes hand-in-hand with SVP using more GPU utilization than it should, and unfortunately this seems to occur almost randomly (seemingly triggered by specific video files or something that don't really always have anything in common).

I had a situation where the flicker was occurring on a specific video, I only changed SVP to "repeat frame", relaunched the video, and the flicker was gone; GPU utilization was around 50%.  I changed SVP back to "blend adjacent frames", relaunched the video, and the flicker was back; GPU utilization was around 85%.  So I set SVP to "repeat frame" again, launched the very same video one more time, and the flicker was still there; GPU utilization was still around 85%.

Normally I'm able to do x3 interpolation on 20fps videos...though definitely not with the flicker/high-GPU-load issue.  Now what was interesting is that, when the flicker/high-GPU-load issue was occurring, I was able to greatly reduce the flickering by setting SVP to do only x2 interpolation which, as we all now know, reduces the GPU utilization; sure enough, the resulting GPU utilization was only around 80% (was ~95% with the flicker issue @ x3, no idea what GPU load at x3 without the flicker issue is).  To add weight to this theory, reducing my GPU's shader clock not only increased the GPU load resulting from SVP but also increased the amount of flickering.

This makes me wonder if people with powerful GPUs never notice this issue of higher-than-normal GPU utilization because on something like a Fury X it could simply be the difference between 10% and 12% GPU utilization; this could very well explain why I seem to be on my own here even though I've ran into this issue on two very different combinations of PC hardware...though now that I think of it, both PCs have one thing in common - relatively weak GPUs.

EDIT: Haha, seemingly random is right.  The above-attached "problematic" MP4 that was always triggering the flicker issue when I made my previous post is working perfectly fine.  However I've now run into another video that keeps having the issue, but I think I've found a repeatable method of making it go away for at least a single video-playback session:

hit "stop" in MPC-HC, close MPC-HC; re-open the video - assuming resume is enabled, it should resume playing right where it was stopped but without any flickering and with normal GPU utilization.

EDIT 2: I think I may have finally solved the flicker issue once and for all, but before I say what it is that I did, I would prefer to give it a few days worth of testing before we jump to any final conclusions.

Nevertheless, I would recommend to any SVP devs to not bother spending any time on this issue and/or with my bug reports until after I can confirm/deny whether or not I have in fact finally figured out what solves it - otherwise you devs may very well just be wasting your time chasing a dead end.

Well it's got to be connected in some way if not indirectly.

As I mentioned before, muxing the above-linked MP4 into an MKV via mkvtoolnix and doing nothing else still results in the seizures, but doing the same muxing process and specifying a framerate of 15p eliminates the seizures.

EDIT: Hmmm... it seems my above download link is broken.  Let me see if I can reupload or maybe even attach a copy...

It was just odd to me that I saw you replying to others and the like during that time period, so I started to think that maybe you were not able to replicate the problem and therefore simply ignored it as not being SVP-related.

EDIT 2: I have attached the video clips.  Oddly enough, muxing the attached MP4 via mkvtoolnix into a new MKV without even manually specifying the framerate still results in constant 15fps and therefore a good result.

EDIT 3: OK maybe you're right about it having nothing to do with variable framerate - I just found a case of it occurring on a video with a constant framerate and have attached it (even though the video length says 16+ minutes it's only about 10 seconds).

Perhaps it might just be a case that variable framerates reliably trigger the issue.

EDIT 4: Well isn't this interesting - after disabling "Use Direct3D 11 for presentation" in madVR, the attached constant bitrate VP9/WebM video seems to no longer gives me the juddery flicker issue (it's 2am here; I will test more in-depth later).  However, the attached MP4 still results in the issue, and the screen recording that I used in my bug report used EVR CP rather than madVR on a PC that had no traces of Nvidia graphics, so it's clearly not completely a madVR nor an Nvidia thing.

It's very possible that it was actually a case of two different issues resulting in similar symptoms.