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 4th June 2013, 17:23   #18981  |  Link
callannn
Registered User
 
Join Date: Apr 2013
Posts: 6
Hi, I seem to be having a slight problem. Usually on playback I get no dropped/delayed frames at all, but sometimes I can watch the exact same video again (that I've previously had no dropped/delayed frames) on a different day and receive a significant amount of delayed frames (usually ranging from around 70-130 I've noticed). Does anybody know why this is?

If it helps, here are my specs: Samsung NPC700G7C, 16.0GB RAM, Intel Core 17 3610QM @ 2.30GHz, GTX 675M
I'm also using Niyawa's Guide and use it exclusively for anime playback. I'm also using his 'highest settings' for the scaling algorithm's.

If anyone could help that would be great!
callannn is offline   Reply With Quote
Old 4th June 2013, 19:46   #18982  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by cyberbeing View Post
Not that that 23.97605 Hz really helps much when the clock deviation is so high at 0.00472% with a dropped frame every 14.84 minutes like their screenshot.
Well, the article text did mention that they got an estimate of one frame drop/repeat every couple of hours, IIRC. Not sure why the screenshot doesn't match that.

Quote:
Originally Posted by cyberbeing View Post
If you do implement a high CPU queue like 128, you may want to consider adding an additional slider for the Subtitle queue and/or have it match the GPU queue size instead. Setting the Subtitle queue smaller than than CPU queue I would actually expect would improve reliability in cases of CPU bottlenecks, similar to how setting the CPU queue slightly higher than the GPU queue does.
Why would setting the Subtitle queue *smaller* have a similar effect compared to having the CPU queue *bigger*. Both subtitle rendering and decoding are CPU tasks. So I would expect a *bigger* subtitle queue to be benefical for reliability. Of course CPU consumption will be higher while filling the queue. But once it's filled it doesn't matter how large it is. CPU consumption should go back to the same value. So I don't see any problem with a large subtitle queue.

Quote:
Originally Posted by e-t172 View Post
Wait. If I understand this correctly, if you use the same HDMI port for audio *and* video, they should be governed by the same clock (since, AFAIK, in HDMI audio is transferred during the blanking interval between two frames).
In theory this sounds right. But in real life it doesn't always seem to work that way. I'm not sure, maybe they still use different clocks somehow. But what do I know...

Quote:
Originally Posted by Buckster View Post
I did some more viewing with Smooth Motion rendering on tonight - watching snippets of films I've watched over and over again (you know those AV demo worthy parts that are worth watching over and over again )

what has really shocked me is how with Smooth Motion on - I'm noticing details I've never noticed before - when I say details I don't mean as in it looks sharper, or there is more detail on screen so to speak, but just that there seems to be so much more content in any shot with motion

genuinely leagues better - ok there is the odd very minor additional artefact - but perfectly acceptable

I'm not normally one for "post-processing" - but whatever Smooth Motion is doing it works for my setup - so thanks !

I'm comparing 24p from MadVR as 24p input into TV (my Panasonic plays 24p at 23.976hz which is quite unusual) - you get noticeable flicker in Windows Desktop - but no obvious flicker whilst watching films

to 60p from MadVR as a 60p input into TV

in theory the Panasonic playing 24p content with near to no processing without Smooth Vision should be the ideal setup - but with Smooth Vision on its leagues better
Good to hear. FWIW, there have been multiple Panasonic plasma owners now saying similar things. It seems that the 24Hz implementation of Panasonic plasmas is severely lacking.

Quote:
Originally Posted by callannn View Post
Hi, I seem to be having a slight problem. Usually on playback I get no dropped/delayed frames at all, but sometimes I can watch the exact same video again (that I've previously had no dropped/delayed frames) on a different day and receive a significant amount of delayed frames (usually ranging from around 70-130 I've noticed). Does anybody know why this is?

If it helps, here are my specs: Samsung NPC700G7C, 16.0GB RAM, Intel Core 17 3610QM @ 2.30GHz, GTX 675M
I'm also using Niyawa's Guide and use it exclusively for anime playback. I'm also using his 'highest settings' for the scaling algorithm's.
We don't have enough information to help. Without any more info all I can do is give general hints like:

(1) Make sure you disable tools/applications which might eat GPU performance. E.g. newer Firefox/Chrome/IE versions might use the GPU for rendering tasks. Or recently it has been reported that the "f.lux" and "GpuZ" tools can also result in video playback problems. So close them before watching a movie.

(2) Make sure your GPU doesn't clock down. This has happened to some users. I think some tweak tools allow to fix the clock to some specific value.

If these hints don't help, make a screenshot of the madVR OSD (Ctrl+J) in the moment when those frame drops occur. If you can't make a screenshot (FSE mode?), please at least write down the state of the queues and report them here. Then we can go from there...
madshi is offline   Reply With Quote
Old 4th June 2013, 19:49   #18983  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
madVR v0.86.2 released

http://madshi.net/madVR.zip

Code:
* fixed: refresh rate changing didn't always work correctly in Windows 8
* fixed: MPC-BE title bar didn't handle unicode characters correctly
* fixed: IVideoWindow::putBorderColor() had swapped colors (RGB -> BGR)
* fixed: #18: decoder queue sometimes exceeded limits
* fixed: #19: blank screenshots when Smooth Motion FRC is turned on
* fixed: #23: video didn't follow overlay window position when paused
* fixed: #34: smooth motion FRC was sometimes incorrectly turned on
* fixed: #35: framerate tag was not working
* fixed: #37: when no video duration was known, seekbar was not shown
* fixed: #42: memory leak with certain OSD elements
* fixed: #44: GraphStudioNext "Performance Test" Crash
* fixed: #46: xy-vsfilter: 3DLUT was not applied to frames with subtitles
* fixed: #47: xy-vsfilter: subtitles weren't rerendered after scaling change
* fixed: #48: xy-vsfilter: incorrect positioning after downscaling
* fixed: #49: xy-vsfilter: incorrect PGS subtitle positions
* fixed: #50: xy-vsfilter: smooth motion FRC caused subtitles flicker
* fixed: #51: settings dialog now mentions both ReClock and VideoClock
* fixed: #52: xy-vsfilter: incorrect ASS subtitle positions
* fixed: #55: FSE seek bar resulted in inaccurate seeking for DVDs
* fixed: #60: all kinds of artifacts with smooth motion FRC
* fixed: #62: crash when external 3dlut file with long filename was missing
* fixed: #65: film refresh rate was used with dxva decoding -> deinterlacing
* fixed: #66: Cineform decoder v210 (10-bit 4:2:2) corruption
* smooth motion FRC should be back to v0.86.0 performance levels
* increased max CPU queue size to 128 frames
* added support for DCI-P3 and BT.2020 primaries and BT.2020 matrix
* added support for "matrix=2020" and "primaries=2020|DCI" tags
* added resolution based auto detection for BT.2020 (UHD) and DCI-P3
* added explicit detection for non PS3.0 capable GPUs
* added IMadVRInfo interface which makes all sorts of info available
* added a couple workarounds for weird crashes that were reported
As you can see, the new release contains a multitude of bug fixes. Hope nothing new got broken in the process.

Please test and report whether the Smooth Motion FRC related bugs have been fixed in this build.

Btw, Smooth Motion FRC performance should hopefully be back up to v0.86.0 levels (which was faster than v0.86.1). I hope that this performance improvement didn't bring back problems. Let me know...
madshi is offline   Reply With Quote
Old 4th June 2013, 19:59   #18984  |  Link
raul31
Registered User
 
Join Date: Dec 2012
Posts: 5
lav filters/madvr!

Hi madshi,

congratz on the new version that u hav JUST released.
Looking forward to using it very soon.
btw, i'm a newbie so i'm going to ask the following:

what i want to know is, what exact options should i choose within LAV video with regards to the following to get the possible image:
> (hardware acceleration) -> hardware decoder to use: none, nvidia cuvid, intel quicksync, DXVA2 (native), or DXVA2 (copy-back) ? & why
> RGB Output Levels: TV, PC, or UNTOUCHED ? & why
> Dithering Mode: Ordered or Random ? & why
> there are other options as well which i haven't mentioned such as deinterlacing which can be configured within LAV video... what should i choose here for the rest of the options?

i also wanted to know:
i have a 2nd gen I7 [2670] processor & 1GB nvidia GT 525m... all within a beautiful dell xps l502x (WISH i went for the model with 2GB GT 540m )
how am i able to configure MPC-HC so that ALL the decoding & work that needs to be performed by the LAV filters etc is done completely by the I7 processor {CPU} & not touched at all by the nvidia card?
the ONLY thing that should use the nvidia card is MadVR, but how can i exclusively make sure that the nvidia card isn't spending it's power on other decoding? i ONLY want the nvidia card for MadVR & NOTHING else, but can this setup be done where one can choose what processes what etc.

thanks madshi!!!

looking forward to your guidance.
raul31 is offline   Reply With Quote
Old 4th June 2013, 20:03   #18985  |  Link
mark0077
Registered User
 
Join Date: Apr 2008
Posts: 1,055
thanks madshi!
mark0077 is offline   Reply With Quote
Old 4th June 2013, 20:40   #18986  |  Link
6233638
Registered User
 
Join Date: Apr 2009
Posts: 1,019
Quote:
Originally Posted by madshi View Post
fixed: refresh rate changing didn't always work correctly in Windows 8
This switches to 24Hz and 60Hz correctly now, but still restores to 59Hz when exiting fullscreen mode. (when previously set to 60Hz on the desktop)

I have also noticed another issue, that may not be madVR's fault.
In JRiver Media Center, if you have their display mode switcher disabled, stopping playback without exiting fullscreen view first, does not attempt to restore the display mode at all. (so stopping a 24Hz video leaves my display at 24Hz)


Seems like a good release otherwise. I appreciate the BT.2020 support being ready for when 4K content is (largely) available.

EDIT: And I'm quite sure that you are aware of it, but using a decoder queue size of 128 takes rather a long time for the image to update when switching between fullscreen and windowed modes, even with "delay playback start until render queue is full" disabled.

Last edited by 6233638; 4th June 2013 at 20:48.
6233638 is offline   Reply With Quote
Old 4th June 2013, 20:54   #18987  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 3,683
Quote:
Originally Posted by raul31 View Post
what i want to know is, what exact options should i choose within LAV video with regards to the following to get the possible image:
> (hardware acceleration) -> hardware decoder to use: none, nvidia cuvid, intel quicksync, DXVA2 (native), or DXVA2 (copy-back) ? & why
> RGB Output Levels: TV, PC, or UNTOUCHED ? & why
> Dithering Mode: Ordered or Random ? & why
> there are other options as well which i haven't mentioned such as deinterlacing which can be configured within LAV video... what should i choose here for the rest of the options?

i also wanted to know:
how am i able to configure MPC-HC so that ALL the decoding & work that needs to be performed by the LAV filters etc is done completely by the I7 processor {CPU} & not touched at all by the nvidia card?
I'll give some answers to keep madshi free to keep up the good work. These have been covered many times in this thread and I don't think madshi needs to keep answering.

(hardware acceleration):
It sounds like you want "none" to me. This is what I use as well, all the other options use the GPU. The "hardware" doing the acceleration is on the GPU.

RGB Output Levels:
Untouched, leave converting color spaces to MadVR.

Dithering Mode:
Random unless you plan to re-encode the output. Random is visually higher quality but it does not encode as well.

You can turn on Yadif in LAV for software deinterlacing, I use video mode for real interlaced video (30i in my case).

All you need to do in LAV to keep the GPU free is to use "none" for hardware acceleration and don't use any shader scripts in MPC-HC.
Asmodian is offline   Reply With Quote
Old 4th June 2013, 20:57   #18988  |  Link
noee
Registered User
 
Join Date: Jan 2007
Posts: 530
Quote:
Originally Posted by 6233638 View Post
...
I have also noticed another issue, that may not be madVR's fault.
In JRiver Media Center, if you have their display mode switcher disabled, stopping playback without exiting fullscreen view first, does not attempt to restore the display mode at all. (so stopping a 24Hz video leaves my display at 24Hz)
I see the same thing, but when I then exit jrMC, the display switches back. It's almost like MC is the holdup like it's not "releasing" madVR or madVR not picking up that playback has stopped for some reason.

I'm on Win7 Ult, however. Curious what happens when you close MC.
noee is offline   Reply With Quote
Old 4th June 2013, 20:59   #18989  |  Link
Danat
Registered User
 
Join Date: May 2013
Posts: 10
Thank you madshi !
Just tried out the 128 CPU queue - and yes it works just like I hoped it would ! Guess I can still count on my PC for this video .
First 4 heavy fragments play like there never have been any stuttering on them. The 5-th fragment, which is the longest (23 secs), has some stuttering at the end (decoder queue empty). I've noticed that RAM usage per decoded frame is lower than I expected (6.5 MB) which leaves me with 1 GB free RAM, so if you ever gonna be in the mood to return to this feature, please add some more ticks after 128 (btw I like your solution with 56,64,96,128), like 192, 256. I understand that it's a bit awkward workaround for a slow CPU, but who needs RAM for smth else when watching HD movies anyway .

Good job on update.
Danat is offline   Reply With Quote
Old 4th June 2013, 21:08   #18990  |  Link
6233638
Registered User
 
Join Date: Apr 2009
Posts: 1,019
Quote:
Originally Posted by noee View Post
I see the same thing, but when I then exit jrMC, the display switches back. It's almost like MC is the holdup like it's not "releasing" madVR or madVR not picking up that playback has stopped for some reason.

I'm on Win7 Ult, however. Curious what happens when you close MC.
Ah, you're right - though I had to close Media Server as well, which is why closing Media Center alone didn't seem to work.

Last edited by 6233638; 4th June 2013 at 21:17.
6233638 is offline   Reply With Quote
Old 4th June 2013, 21:23   #18991  |  Link
e-t172
Registered User
 
Join Date: Jan 2008
Posts: 568
Quote:
Originally Posted by cyberbeing View Post
I have no idea what you consider as "video clock", but the "audio clock" is what DirectShow uses as a reference clock as interpreted by the "system clock". The clock deviance shown by madVR, multiplied by and added to the video frame rate is the "real" playback rate in DirectShow before anything ever gets passed over HDMI or other output. For example, in Anandtech's screenshot with 0.00472% clock deviance, the "real" video & audio playback rate is equivalent to ~23.97715 fps, which is higher than his display refresh rate of ~23.97605 Hz.
What I mean is, the way audio over HDMI works is that audio is transferred during the blanking interval between two frames. The simplest way to make it work from the point of view of the GPU manufacturer is to make sure the number of audio samples transferred between two frames is equal to the frame duration. So, for example, if the refresh rate is 24Hz, then 2000 audio samples (assuming 48kHz sampling rate) of audio will be sent between each frame. As long as the hardware (driver, GPU, whatever) enforces that (which is very easy: just push 2000 samples between each frame, no more, no less), then everything should be fine and no clock deviation should occur, ever, because there's nothing to deviate from: there's only one clock, and it's the video clock (i.e. the clock that controls the refresh rate). Sure this one clock might not be perfectly accurate, but that doesn't matter: the device at the other end of the cable is slaved to the clock of the sending side anyway, so that's not an issue.

Contrast this with the traditional situation where you have a video output and an analog sound card output: in this case you're dealing with the video (refresh rate) clock and the audio (sample rate) clock, which won't be perfectly in sync. In other words, instead of sending 2000 audio samples during a vsync interval (assuming 24p and 48kHz), sometimes you'll send 1998 samples, or 2002 samples (or something else), in other words the two clocks will deviate from each other, and that's why you can't prevent frame drops (unless you use ReClock and/or FRC of course). If instead the video output is also taking care of sending the audio, then the issue goes away completely: one component (the GPU) has control over everything, so it just has to make sure it uses the same clock for everything and just send the correct, constant amount of samples each time. In the case of 24p and 48kHz, it just knows it has to send 2000 samples between each frame, because 48000 / 24 = 2000. That's it. It's that simple. There's no clock deviation, because the audio is now slaved to the vsync.

At least that's the theory. In practice we're still seeing clock deviation when playing both audio and video over HDMI, which, I must say, puzzles me. That would mean that GPU manufacturers are using two clocks for video and audio, which doesn't make any sense because that's actually harder than just doing the right thing and using one single clock.

Last edited by e-t172; 4th June 2013 at 21:29.
e-t172 is offline   Reply With Quote
Old 4th June 2013, 21:50   #18992  |  Link
ajp2k11
Registered User
 
Join Date: Jul 2011
Posts: 57
Black screen

Madshi,

any idea why I get a black screen when trying to play some files? If I switch to exclusive mode it says the refresh rate is 0 Hz. Ctrl-J in windowed mode doesn't display...

I've had this problem for a long time, think it might have appeared when switching to Win8. My laptop display is capable of 60/120Hz. Using AMD graphics and I've tried resetting all settings to default.

You've looked at a debug log once but couldn't find anything, could the 0 Hz thing be a clue?

Grateful for any help...
ajp2k11 is offline   Reply With Quote
Old 4th June 2013, 22:27   #18993  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by ajp2k11 View Post
any idea why I get a black screen when trying to play some files? If I switch to exclusive mode it says the refresh rate is 0 Hz. Ctrl-J in windowed mode doesn't display...
If the refresh rate reads 0Hz that means that your GPU driver doesn't inform madVR reliably enough about the VSync scanline position. That is required by madVR to do proper presentation. This is a rare problem, but some people have it. It's mostly a problem on XP, though, so I'm surprised you have this with win8. I'd suggest that you update to the latest drivers, to make sure. You could also try updating your GPU BIOS, maybe that helps...
madshi is offline   Reply With Quote
Old 4th June 2013, 22:34   #18994  |  Link
ajp2k11
Registered User
 
Join Date: Jul 2011
Posts: 57
Quote:
Originally Posted by madshi View Post
If the refresh rate reads 0Hz that means that your GPU driver doesn't inform madVR reliably enough about the VSync scanline position. That is required by madVR to do proper presentation. This is a rare problem, but some people have it. It's mostly a problem on XP, though, so I'm surprised you have this with win8. I'd suggest that you update to the latest drivers, to make sure. You could also try updating your GPU BIOS, maybe that helps...
Thanks, but isn't it weird that I get this problem only with some files and never with others? Also, it much more common when the files are 1080p and not 720p. It's always the same files too, some files never work...ever. They work fine with EVR-CP though...
ajp2k11 is offline   Reply With Quote
Old 4th June 2013, 22:37   #18995  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
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...
madshi is offline   Reply With Quote
Old 4th June 2013, 23:09   #18996  |  Link
callannn
Registered User
 
Join Date: Apr 2013
Posts: 6
Quote:
Originally Posted by madshi View Post
We don't have enough information to help. Without any more info all I can do is give general hints like:

(1) Make sure you disable tools/applications which might eat GPU performance. E.g. newer Firefox/Chrome/IE versions might use the GPU for rendering tasks. Or recently it has been reported that the "f.lux" and "GpuZ" tools can also result in video playback problems. So close them before watching a movie.

(2) Make sure your GPU doesn't clock down. This has happened to some users. I think some tweak tools allow to fix the clock to some specific value.

If these hints don't help, make a screenshot of the madVR OSD (Ctrl+J) in the moment when those frame drops occur. If you can't make a screenshot (FSE mode?), please at least write down the state of the queues and report them here. Then we can go from there...
Ah sorry, what additional info would you need? I don't have f.lux installed on my laptop anymore as it was messing with playback and giving me a huge amount of frame drops, and I never have GPU-Z open or in use in the background when watching a video. I don't actually have anything in use at all when watching videos.

I'm not actually sure how to prevent my GPU from clocking down, so if anyone could tell me I would appreciate it.

I've included this screenshot here taken at the end of an hour long video for you to have a look at if that is any help?
callannn is offline   Reply With Quote
Old 4th June 2013, 23:14   #18997  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
The OSD screenshot only helps if it's directly from the situation when the frame drops occur. The additional info we need is for example which queues are (near) empty when those frame drops occur.
madshi is offline   Reply With Quote
Old 5th June 2013, 00:03   #18998  |  Link
Soukyuu
Registered User
 
Soukyuu's Avatar
 
Join Date: Apr 2012
Posts: 169
The new version works flawlessly so far, and I can now take screenshots without having to disable smooth motion, thanks!
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?

Quote:
Originally Posted by callannn View Post
Hi, I seem to be having a slight problem. Usually on playback I get no dropped/delayed frames at all, but sometimes I can watch the exact same video again (that I've previously had no dropped/delayed frames) on a different day and receive a significant amount of delayed frames (usually ranging from around 70-130 I've noticed). Does anybody know why this is?

If it helps, here are my specs: Samsung NPC700G7C, 16.0GB RAM, Intel Core 17 3610QM @ 2.30GHz, GTX 675M
I'm also using Niyawa's Guide and use it exclusively for anime playback. I'm also using his 'highest settings' for the scaling algorithm's.

If anyone could help that would be great!
If you jump near a scene where the framedrop happens, it could be that the decoder queue doesn't fill up fast enough to not drop frames vs. having enough time if you watch the whole episode. I solved nearly all my buffering problems with LAV by just increasing the cpu queue to 64. I'm saying "problems with LAV" because on my test files I get no frame drops with haali, but I do with LAV. So it might be the same for you, I already notified nevcariel about it.
Soukyuu is offline   Reply With Quote
Old 5th June 2013, 00:07   #18999  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Quote:
Originally Posted by madshi View Post
So I don't see any problem with a large subtitle queue.
It's helpful to layer & stagger even different types of CPU queues in my experience. With the first/top queue in a display chain being the largest, while the ones which follow being progressively smaller but with higher CPU thread priority than the prior queues in an attempt to ensure they stay full in real-time under heavy load. The logic is that the largest fast-filling queue have enough of a buffer to prevent the slower-filling queues below from emptying below 100% full, if you temporarily become bottlenecked.

Though my main concern that I thought you'd catch on to, was cases where you need to re-request and re-alphablend your entire subtitle queue instantly because of that change you made in 0.86.2 to decrease update delay on resolution change. I already saw this as barely acceptable with a CPU queue of 24. But now with a queue of 128, I end up with ~80 dropped frames (i5-3570K @4.4Ghz) as the subtitle queue attempts to refill, which could take a couple seconds if something computationally heavy is being displayed for the entire queue size. It would only be worse with slower CPUs. With a smaller queue, this effect would be minimized or eliminated. If you don't want to separate the CPU and Subtitle queues, maybe you should consider expanding the "delay playback" option to wait for subtitle queue to be completely full for "playback start", "seek", and "window resizing".

IMHO, you need to make one change or the other, otherwise user experience will suffer with large CPU queue + Subtitle queue size.

Last edited by cyberbeing; 5th June 2013 at 09:00.
cyberbeing is offline   Reply With Quote
Old 5th June 2013, 01:15   #19000  |  Link
TheShadowRunner
Registered User
 
TheShadowRunner's Avatar
 
Join Date: Feb 2004
Posts: 399
Hi madshi,
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.
Unrelatedly, now on to test 0.86.2, thanks for this new build!

Edit: same bug with 0.86.2.
__________________
XP SP3 / Geforce 8500 / Zoom Player

Last edited by TheShadowRunner; 5th June 2013 at 02:07.
TheShadowRunner 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 17:15.


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