madVR - high quality video renderer (GPU assisted)

[yok833]

Fantastic news!!!
Madshi, have you also noticed an improvement of the performance as reported by qduaty (around 20%)?

Envoyé de mon GT-I9300 en utilisant Tapatalk

[TheShadowRunner]

That's probably the "show black screen when playback is stopped" change. Seems that the VSFilter type subtitle renderers stop the graph when the user changes the subtitle tracks. I'm not sure if there's anything I can do about that without removing the "show black screen when playback is stopped" feature - which I think is useful. But I'll see if I can detect the situation somehow...
Yes, that has to be "show black screen when playback is stopped".. thanks for looking into it.

[kalston]

I follow a rigorous testing protocol. All my results are based on the madVR dropped frames counter, not from watching the video.


I only gave that example to illustrate how much I care and worry about the issue. But I saw this phenomenon AFTER reading your posts and for a second I was just worried I might be having the same issue (but thankfully it's unrelated) :)

Anyway good luck on your bug hunting but even though I'm unaffected this really puzzles me. I even occasionally watch high fps files (50-60) and I've yet to encounter any issue with those. Although that's usually videos and not full length films...

[madshi]

Thank you. Quite frankly, I've been doing tests for days on multiple hardware and software platforms and "bug in madVR" is the only reasonable explanation I can come up with. Problems with hardware or the OS have been ruled out so many times I lost count.

I came to the same conclusion as you while examining the log (with my limited understanding of it) - it looks like madVR just decides to drop a frame for no reason, while the underlying hardware is doing just fine.
Ok, I completed the analyzation of the situation and found a bug. It should (hopefully) be fixed in the next build.

Fantastic news!!!
Madshi, have you also noticed an improvement of the performance as reported by qduaty (around 20%)?
I've not done any performance tests. It will run as fast as it will. Nothing I can do about that, anyway.

[madshi]

madVR v0.87.8 released

http://madshi.net/madVR.zip

* added workaround for NVidia OpenCL <-> D3D9 interop driver bug
* fixed: #158: NNEDI3 chroma upscaling + DXVA deint + NVidia -> green image
* fixed: DirectCompute rendering resources weren't properly released
* fixed: some multi monitor problems introduced in v0.87.7
* fixed: smooth motion frc sometimes incorrectly dropped frames
* fixed: toggling subtitle "trade quality" option required restart
* some DirectCompute stability improvements
* added vendor based OpenCL device filtering
* non-DX11-GPUs: error diffusion now falls back to ordered dithering
* improved Windows 8.1 FSE mode refresh rate hack
Extra thanks to qduaty for providing the workaround for the NVidia OpenCL driver bug.

[e-t172]

Wow, that was fast, thanks! I'll get on testing right away to verify the bug fix.

[GCRaistlin]

added workaround for NVidia OpenCL <-> D3D9 interop driver bug

Does it mean that we can use GeForce drivers newer than 327.23?

[nevcairiel]

Does it mean that we can use GeForce drivers newer than 327.23?

Yes, I verified it works on 335.23
GTX 660 in my HTPC can only do 32 neurons for 720 -> 1080, and only at 24/25p (32ms rendering with OD, 37ms with ED1), but hey, the 660 isn't the most glamorous card under the sun. ;)

Should performance test my GTX 780. :)

[madshi]

GTX 660 in my HTPC can only do 32 neurons for 720 -> 1080, and only at 24/25p (32ms rendering with OD, 37ms with ED1), but hey, the 660 isn't the most glamorous card under the sun. ;)
D'ya still have a Maxwell? Would be interesting to hear how that fares compared to the 660, considering that Maxwell seems to have noticeably improved compute performance over Kepler.

[nevcairiel]

D'ya still have a Maxwell? Would be interesting to hear how that fares compared to the 660, considering that Maxwell seems to have noticeably improved compute performance over Kepler.

Yeah, i bought the 750 for testing the new architecture, its still around.

Important to note is that the 750 is like 30% slower than the 660 in raw performance, but it might still give a bit of insight for the compute side. I'll try to do it tomorrow.

[leeperry]

Mucho Thanks for the new build but I don't get any picture in FS(whatever FSE or FSW), all I get is a black screen. Windowed mode works fine. Previous builds work fine in FS, I'll happily provide logs if you can't reproduce the problem.

I run W7SP1/HD7850 with the latest WHQL drivers/A4 mono-static/64x NNEDI for 720p@1080p/low debanding/gamut rolling PS script.

[cca]

Testing with my AMD Radeon 5850 gives weird results with the latest build. NEEDI rendering times seem lower for some reason, but scaling 720p to 1080p produces a very dark image, video is unwatchable. 480p to 1080p works though.

EDIT: Actually the rendering times are way too low, I doubt it even works properly anymore.

EDIT2: Even weirder, if I close MPC-HC and reopen the video, NEEDI works for a few secs then turns dark and rendering times fall. Something is clearly failing.

[seiyafan]

Could someone with 770/780 test to see how much improvement there is with the latest driver?

[madshi]

Mucho Thanks for the new build but I don't get any picture in FS(whatever FSE or FSW), all I get is a black screen. Windowed mode works fine. Previous builds work fine in FS, I'll happily provide logs if you can't reproduce the problem.

I run W7SP1/HD8750 with the latest WHQL drivers/A4 mono-static/64x NNEDI for 720p@1080p/low debanding/gamut rolling PS script.
Testing with my AMD Radeon 5850 gives weird results with the latest build. NEEDI rendering times seem lower for some reason, but scaling 720p to 1080p produces a very dark image, video is unwatchable. 480p to 1080p works though.

EDIT: Actually the rendering times are way too low, I doubt it even works properly anymore.

EDIT2: Even weirder, if I close MPC-HC and reopen the video, NEEDI works for a few secs then turns dark and rendering times fall. Something is clearly failing.
Argh. Seems the NVidia fix partially broke NNEDI for AMD and Intel users. Does this build fix the problem?

http://madshi.net/madVR878b.rar

[noee]

Yup, that fixed it here (HD6570)

[Asmodian]

I can confirm NNEDI3 in madVR 87.8b works on Nvidia 335.23, nice job on the workaround madshi & qduaty. :)

[biggerpapi]

Has anybody with an optimus laptop gotten any nnedi3 features to work? Even after the 0.87.8 update and clean installs of my drivers and forcing my 640m to be used with mpc-hc I still get a green screen on the chroma upscaler and a black/red screen with image doubling.

[leeperry]

Yup, that fixed it here (HD6570)
Same here :)

[JonnyRedHed]

Having now just experienced image doubling for the first time with my NV GTX670, I must say I'm pretty impressed. Set just luma NNEDI3 to 32neruons with Lanczos3 AR, it doesn't tax the GPU and set the fans off too high. But 64/128 neruons does set the card right off, making too much noise.


Any advice would be good for working with image doubling.



i5 2500k@4.8
16GB Muskin 2133 DDR3
Nvidia GTX 670 PE/OC (MSI) driver 331.82 will try a newer one soon on the next branch from current.
HDMI>50inch LG Plasma@71.928xx custom res.

[Fadeout]

Have you disabled Desktop Composition (Aero) or made a global change to your driver's V-Sync settings? (such as using adaptive v-sync)

Yeah, I was able to fix the problem by enabling the vsynch in the program settings within Nvidia control panel.

[Asmodian]

@madshi would it be possible to blank/standby all other screens when madvr goes into FSE mode? For dark room viewing experience.

Or is that something the player should do?

IMO This is something the player should do. I know Zoom Player, for example, has this option.

[Farfie]

Oh man, this is so exciting! With all the new stuff, and using newest WHQL nvidia drivers in sig, my 680 is just so close to being able to do 720->1440 at 64 neurons + ED2 while changing dither every frame. But it's just a TAD BIT too slow! Argh! I'm talking 1 frame drop per 30-60 seconds close.

One thing about that though, which I had realized in this past but it did not bother me, but now it is because it is affecting whether or not I can use these high end functions...
http://puu.sh/7QgEo.jpg
Why is a 720p video being upscaled to 2560x1520 on my 1600p monitor instead of 1440p? Is there something I don't know about? I have video frame set to "Touch Window From Inside," and I just don't see why it wouldn't go to 2560x1440? This is making it so that after the image doubling, it is using Jinc3 for these few extra (seemingly useless) vertical pixels, which is making me unable to use the aforementioned settings. By switching image upscaling to Lanczos4 though, it becomes doable. But isn't this wrong, or am I missing something?

Either way, this is exciting as hell. Great work to madshi and qduaty!

[kasper93]

1080p WEB-DL being my preferred TV format

You should go for 720p. 1080p WEB-DL lacks details. They have little bit too low bitrate. Many people were comparing this and 720p with proper upscaling looks just better.


Tapatalk 4 @ GT-I9300

[huhn]

Oh man, this is so exciting! With all the new stuff, and using newest WHQL nvidia drivers in sig, my 680 is just so close to being able to do 720->1440 at 64 neurons + ED2 while changing dither every frame. But it's just a TAD BIT too slow! Argh! I'm talking 1 frame drop per 30-60 seconds close.

One thing about that though, which I had realized in this past but it did not bother me, but now it is because it is affecting whether or not I can use these high end functions...
http://puu.sh/7QgEo.jpg
Why is a 720p video being upscaled to 2560x1520 on my 1600p monitor instead of 1440p? Is there something I don't know about? I have video frame set to "Touch Window From Inside," and I just don't see why it wouldn't go to 2560x1440? This is making it so that after the image doubling, it is using Jinc3 for these few extra (seemingly useless) vertical pixels, which is making me unable to use the aforementioned settings. By switching image upscaling to Lanczos4 though, it becomes doable. But isn't this wrong, or am I missing something?

Either way, this is exciting as hell. Great work to madshi and qduaty!
just take a closer look:
target, rectangle 0, 80, 2560, 1520

it is 1440 but just moved in the middle of the screen.
if nnedi3 is used for 720 -> 1440 image scaling is only used to to the last part of chroma scaling i guess. that's why lanczos and jinc make the difference it is not used for luma in this case

[cca]

Argh. Seems the NVidia fix partially broke NNEDI for AMD and Intel users. Does this build fix the problem?

http://madshi.net/madVR878b.rar

Sorry for the late reply, went to sleep last night. Yes, it works perfectly fine now.

[StinDaWg]

You should go for 720p. 1080p WEB-DL lacks details. They have little bit too low bitrate. Many people were comparing this and 720p with proper upscaling looks just better.
With the exception that 1080p is usually better for animated shows/cartoons.

[Farfie]

just take a closer look:
target, rectangle 0, 80, 2560, 1520

it is 1440 but just moved in the middle of the screen.
if nnedi3 is used for 720 -> 1440 image scaling is only used to to the last part of chroma scaling i guess. that's why lanczos and jinc make the difference it is not used for luma in this case

No see, the rendering time still goes down when I change the Luma(image) upscaling from Jinc to Lanczos even though it should be a perfect doubling from 720 to 1440 with nnedi3... at least, that's how I understand it.

Also, I thought those numbers meant:
0 (position from left side (x)), 80 (position from top (y)), 2560 (size of video (x)), 1520 (size of video(y))

[vivan]

Also, I thought those numbers meant:
0 (position from left side (x)), 80 (position from top (y)), 2560 (size of video (x)), 1520 (size of video(y))Those are coordinates of target (output) rectangle.
First 2 are right, while last two are coordinates too, not size. If you want to calculate size you need to subtract them. 2560 - 0 = 2560, 1520 - 80 = 1440.

[Asmodian]

No see, the rendering time still goes down when I change the Luma(image) upscaling from Jinc to Lanczos even though it should be a perfect doubling from 720 to 1440 with nnedi3... at least, that's how I understand it.

"Image Scaling" is used to scale the chroma if needed. In your case the luma is doubled to 1440 and the chroma needs some way to get to 1440 too. "Chroma Scaling" is only used to take the chroma to 4:4:4 (640x360 -> 1280x720 in your case).

This is not obvious but it makes sense once you understand the steps that need to happen.

Do you dislike ordered dither? If you can almost do NNEDI3 64 luma doubling with ED2 switching to ordered dither seems like a good idea.

Also, I thought those numbers meant:
0 (position from left side (x)), 80 (position from top (y)), 2560 (size of video (x)), 1520 (size of video(y))

1520 - 80 = 1440 ;)

They really mean:
0 (position from left side (x)), 80 (position from top (y)), 2560 (position from left side (x)), 1520 (position from top (y))

Think of them as coordinates for the top left corner and the bottom right corner.

edit: yes, as vivan said. :)

[truexfan81]

Wow man I'm shocked, i would not have believed that my gtx650 could use nnedi3 at all, but i have it doing the chroma upscailing with 32neurons, using spline36 for everything else, works quite well. Depending on the content gpu usage is anywhere from 45% to 80%. If it gets above 80% the render queue empties and starts dropping tons of frames. if not for that i would push it a little harder.

[QBhd]

No see, the rendering time still goes down when I change the Luma(image) upscaling from Jinc to Lanczos even though it should be a perfect doubling from 720 to 1440 with nnedi3... at least, that's how I understand it.

Also, I thought those numbers meant:
0 (position from left side (x)), 80 (position from top (y)), 2560 (size of video (x)), 1520 (size of video(y))

If you are not image doubling chroma, Jinc/Lanczos will be used... that is why they are affecting your times as well.

QB

[madshi]

Yup, that fixed it here (HD6570)
Same here :)
Sorry for the late reply, went to sleep last night. Yes, it works perfectly fine now.
I can confirm NNEDI3 in madVR 87.8b works on Nvidia 335.23, nice job on the workaround madshi & qduaty. :)
Good to hear, thanks.

Has anybody with an optimus laptop gotten any nnedi3 features to work? Even after the 0.87.8 update and clean installs of my drivers and forcing my 640m to be used with mpc-hc I still get a green screen on the chroma upscaler and a black/red screen with image doubling.
Hmmmm... Optimus seems to always be a bit troublesome for some reason. Could you upload a (zipped) debug log?

Also, I thought those numbers meant:
0 (position from left side (x)), 80 (position from top (y)), 2560 (size of video (x)), 1520 (size of video(y))
No, the definition of a rectangle in Windows is usually "left, top, right, bottom".

[omarank]

Yes I have a DCP sample, but the problem with playing the real DCI-P3 video is that LAV video decoder converts it from XYZ space to sRGB, which madVR receives as content with BT.709 primaries. In this case whether or not I force DCI-P3 primaries, colour cast is there.

Ouch, I don't like that!! @nevcairiel, you there? Why is LAV doing that? FWIW, madVR interprets VIDEOINFOHEADER2 primary index 9 as BT.2020 and index 10 as DCI-P3. So there's really no reason to convert the gamut when sending data to madVR.

I think if LAV does the conversion to DCI-P3 RGB, colours will not look correct with most other renderers. So in my opinion, LAV should provide an option to output XYZ (for madVR) and madVR should do all the conversions. If this can't be done for technical reasons, LAV should provide an option to output DCI-P3 RGB (but then gamma conversion from 2.6 to 2.2 should be done by LAV decoder).

@ Nevcairiel: What do you suggest?



So, in order to check whether madVR is doing the gamut conversion correctly, I used a 100% white pattern clip (BT.709) and forced the primaries as DCI-P3. If the gamut conversion is done correctly with white point matching, 100% white should appear the same for any primaries being forced.

I'm confused. If the white point is different and DCI-P3 is encoded with R=235, G=235, B=235, then after gamut conversion to BT.709, the data can't be 235/235/235, anymore, or am I wrong?

If the gamut conversion is done with white point matching, the data should be 235/235/235 in that case. My understanding of colorimetry is limited though, so maybe someone else can correct me here. Anyway, the point is that if the white point matching is done, there should not be any colour cast with any content being played and this can be best seen with a 100% white pattern.



From what I've read, the conversion from DCI-P3 XYZ to Rec709 RGB should be done using a LUT as this is not a simple colour space conversion. The LUT should take input as XYZ content encoded with gamma 2.6 with DCI white point and peak white at 48 cd/m2, and output Rec709 RGB encoded with gamma 2.2 with D65 white point and peak white at 120 cd/m2.

Is that so? Where did you read that? I'm not really an expert on this, and I'm getting headaches every time I work on this stuff...

I have been reading about this stuff on several forums. I have shared with you the collated information. It will be difficult to provide all the links, but on a quick search I could find these:

See Table 11 in page 67 here -
http://www.dcimovies.com/archives/spec_v1_1/DCI_DCinema_System_Spec_v1_1.pdf

Other links:
http://forum.blackmagicdesign.com/viewtopic.php?f=3&t=18465
http://www.knuterikevensen.com/

(I will share more when I come across the good ones.)

The info which I assimilated was:

1. As DCI-P3 gamut is bigger than Rec709 RGB gamut, outside gamut colours are clipped in the conversion and may lead to artifacts. So a LUT should be used as it gently handles this conversion, as compared to a matrix conversion.
2. In DCI specification, gamma, white point and target peak white luminance are different from the standard Rec709 calibration targets.
3. The DCI white point appears slightly greenish on a D65 monitor. Therefore, relative colorimetric rendering should be used for gamut conversion so that the white point of the source is matched to the target.

[Farfie]

Those are coordinates of target (output) rectangle.
First 2 are right, while last two are coordinates too, not size. If you want to calculate size you need to subtract them. 2560 - 0 = 2560, 1520 - 80 = 1440.

"Image Scaling" is used to scale the chroma if needed. In your case the luma is doubled to 1440 and the chroma needs some way to get to 1440 too. "Chroma Scaling" is only used to take the chroma to 4:4:4 (640x360 -> 1280x720 in your case).

This is not obvious but it makes sense once you understand the steps that need to happen.

Do you dislike ordered dither? If you can almost do NNEDI3 64 luma doubling with ED2 switching to ordered dither seems like a good idea.



1520 - 80 = 1440 ;)

They really mean:
0 (position from left side (x)), 80 (position from top (y)), 2560 (position from left side (x)), 1520 (position from top (y))

Think of them as coordinates for the top left corner and the bottom right corner.

edit: yes, as vivan said. :)

Ooookay I see now. You guys are great, :thanks:


So what I think the best way to do this would be: nnedi3 luma doubling at 64 neurons, ed2 with option 2, and putting lanczos 4 for image upscaling, so that gets used for the chroma. I was so close to being able to use nnedi3 @64 with ED2 that just switching the image scaling from Jinc3 to Lanczos 4 did the trick :eek: (720p is virtually all I watch, so I won't have to worry about 1080p not being Jinc'd, OR I could just make a profile for >720 srcHeight to use Jinc3)

I chose these, because I think what I've learned from the thread is that for best image quality, computing resources should be spent like so: luma>dithering>chroma. So I figured I would choose ed2 over Jinc3 in image scaling, for 720p video.

Anyway, thanks again!

[andybkma]

Has anybody with an optimus laptop gotten any nnedi3 features to work? Even after the 0.87.8 update and clean installs of my drivers and forcing my 640m to be used with mpc-hc I still get a green screen on the chroma upscaler and a black/red screen with image doubling.

Ya same, mVR 87.8b still doesn't work with Optimus laptops and I have my media player (Zoom Player) forced to use Nvidia instead of Intel.

With a video paused, as soon as I select use NNEDI3 to double Luma the video turns black

[Asmodian]

I chose these, because I think what I've learned from the thread is that for best image quality, computing resources should be spent like so: luma>dithering>chroma. So I figured I would choose ed2 over Jinc3 in image scaling, for 720p video.

Anyway, thanks again!

Well those two tradeoffs are both very minor IMO. Chroma doesn't need Jinc3 and ordered dithering looks very good. I would probably switch to ordered dithering myself but it is close. :)

[nevcairiel]

Ouch, I don't like that!! @nevcairiel, you there? Why is LAV doing that? FWIW, madVR interprets VIDEOINFOHEADER2 primary index 9 as BT.2020 and index 10 as DCI-P3. So there's really no reason to convert the gamut when sending data to madVR.


We've been over this topic before, and back then you even agreed that this is the best course of action to take for compatibility with other renderers.
XYZ will be converted to RGB BT.709 with 2.2 gamma, and even explicitly flagged BT.709 in the media type to stop madVR from assuming wrong things.

The conversion to RGB is implemented by ffmpeg, and if its doing the conversion "wrong" for the defined output of RGB BT.709, we should report it to the ffmpeg developers.
FWIW, ffmpeg does generate a LUT for this conversion.

I do not plan to implemented any special conversions for madVR and for a fringe format like XYZ. If you want, you can get the raw XYZ data, because thats easy, but thats about it.

[aufkrawall]

Ha, now .8, GPU usage is only at ~50% when playing 4k with Error Diffusion on GK110.
Seems it's not that slow with Compute afterall. :D

[madshi]

We've been over this topic before, and back then you even agreed that this is the best course of action to take for compatibility with other renderers.
XYZ will be converted to RGB BT.709 with 2.2 gamma, and even explicitly flagged BT.709 in the media type to stop madVR from assuming wrong things.

The conversion to RGB is implemented by ffmpeg, and if its doing the conversion "wrong" for the defined output of RGB BT.709, we should report it to the ffmpeg developers.
FWIW, ffmpeg does generate a LUT for this conversion.

I do not plan to implemented any special conversions for madVR and for a fringe format like XYZ. If you want, you can get the raw XYZ data, because thats easy, but thats about it.
To be honest, I don't remember our past discussion about this, but I'm sure you're right. Is DCI-P3 content decoded to XYZ? I wasn't aware of that (or forgot about it). Which bitdepth/format does the XYZ data have?

In any case, if the DCI-P3 output is BT.709 and there's a color cast, it can't be madVR's fault. So maybe it's a good solution because it's not my responsibility to fix. Haha... :devil:

[madshi]

If the gamut conversion is done with white point matching, the data should be 235/235/235 in that case. My understanding of colorimetry is limited though, so maybe someone else can correct me here. Anyway, the point is that if the white point matching is done, there should not be any colour cast with any content being played and this can be best seen with a 100% white pattern.
I'm not sure if that's correct. And I'm not sure if white point matching should be done. I simply don't know...

[jmone]

Great that it is now working with NVidia with NNEDI3! Q though on any suggestions on settings to try for a native 1920x1080p display for maximising quality for:
1) 1920x1080 AVC/264 @ 23.976p/50i/50p/60i Material (have been very happy with Jinc3+AR) then a long second
2) SD 576 PAL Material

Thanks
Nathan

[nevcairiel]

Is DCI-P3 content decoded to XYZ?

DCP uses JPEG2000 in XYZ at least, not sure if there are any other common sources of DCI-P3.

Which bitdepth/format does the XYZ data have?

XYZ is 12-bit data, not sure what "format" you mean, its in XYZ format of course! :)

[nevcairiel]

1) 1920x1080 AVC/264 @ 23.976p/50i/50p/60i Material (have been very happy with Jinc3+AR) then a long second
2) SD 576 PAL Material


Native 1080p content doesn't benefit from any of the new settings really, short of the dithering improvements.
Just stick to what you know, and try the error diffusion dithering modes - or stick to ordered dithering.

SD could use NNEDI image doubling for sharper images, if your GPU is up for it.
Try with 32 neurons, or maybe even 64 if your GPU has the power for it.

[DragonQ]

Yeah, i bought the 750 for testing the new architecture, its still around.

Important to note is that the 750 is like 30% slower than the 660 in raw performance, but it might still give a bit of insight for the compute side. I'll try to do it tomorrow.
Would be nice to see this! I'm pretty sure my desktop GPU is dying (caused PC to freeze 4 times last night; 3 whilst watching video for about a minute, 1 during gaming) and I'm considering a 750 Ti to replace it.

[e-t172]

I'm not sure if that's correct. And I'm not sure if white point matching should be done. I simply don't know...

I know I've been saying this for a while and at some point you'll probably start ignoring me each time I repeat this, but CMSes (e.g. LittleCMS, Argyll) *do* know how to handle the minute details of gamut mapping, rendering intent, and white point matching. Sorry to be blunt, but you're reinventing the wheel, and it's a *very* complicated wheel to reinvent in an area in which, by your own words, you seem to have limited expertise. Let CMS libraries take that burden off your chest. It would also take the burden of generating 3DLUTs off the chest of your users (since you would be able to support ICC quite easily).

I know you said you don't want to use CMSes or ICC because you find them confusing. I would be happy to answer any questions you might have to clear up any confusion (to the best of my knowledge, of course - in any case we can still ask Graeme). I guarantee you, no matter how confusing these might look to you, they are still way, way easier to understand than the complex color conversion challenges you're facing.

I'm sorry to always bring up this topic again, but it's frustrating to see that this technically superior solution is systematically dismissed with no reasonable explanation. It's your software though, and I know how to use 3DLUTs so it's not that big of a deal for me personally, but still.

[Incriminated]

* fixed: #158: NNEDI3 chroma upscaling + DXVA deint + NVidia -> green image

I still have this bug:
http://imageshack.com/a/img834/4126/zgr2.jpg

[jmone]

Thanks Nev

[biggerpapi]

Well hopefully i did this right and hopefully it helps.

[Damien147]

Do I still have image doubling working if I set lav video to dxva2(native)??? (got a hd4850)

[Incriminated]

Yeah doubling/quadrupling with NNEDID3 works for me both qrchoma and luma with 335.23 on gtx 670.

But that was working before already. :)

But chroma upsampling still does not work on Nvidia with LAV dxva-native, unlike the changelog of 0.87.8 tells. :(