View Full Version : Renderer image quality
somy
6th February 2010, 13:42
Hi,
Recently I did some comparison among different renderers WRT image quality, the results are as follows:
FFDShow+MadVR: Top quality, but 24P playback is not supported well, I got lip sync problem all the time (sometimes too fast and sometimes to slow)
FFDShow(high YUC/RGB convertion+dethering)+EVR CP: Image quality looks very close to MadVR, 24P playback is a bit laggy and lip sync problem can be corrected by set a audio delay.
FFDShow with dethering disabled+EVR CP: very bad quality, I'll not choose this combination.
PowerDVD decoder DXVA+EVR CP: The same as above
PowerDVD decoder DXVA+Overlay: superising good image quality which is slightly worse than MadVR but very close. 24P Movie playback is smooth and lip sync problem is gone,and it's even now able to output WTW and BTB in YUC output mode.
To conclude: overlay seems to offer a far better upchorma algorithm(that's probably why PowerDVD uses Overlay in windows 7 even though EVR is available), so why image quality in EVR looks much worse than overlay?
FOr 24P smooth playback, you can give a try of overlay, and I actually think the quality is similar to MadVR with ATI 9.12 driver.
edigee
6th February 2010, 14:06
If you'd test that combinations in 2 players ,MPC-HC and KMPlayer ,you will notice the results are slightly different. For example in KMPLayer: Cyberlink H264 PDVD9 decoder(DXVA)+ overlay=bad ,bad quality
In MPC-HC the same combination is not that bad.
In both players using EVR Cp gives the best image for me(with the same decoder)
Another observation: Cyberlink H264 PDVD9 decoder performes better than PDVD8 version(in terms of image quality and decoding capabilities)
ffdshowH264 decoder+EVR Cp gives the best image quality for me.
Arcsoft TotalMedia Theatre3 uses overlay renderer in Vista. That is interesting because that happened only after I upgrade it to 140 patch. Same thing for 160 patch.
somy
6th February 2010, 14:11
Hi edigee,
Thanks for your experience.
I did all tests with the latest build of MPC-HC. Also please be aware that the ATI 9.12 driver seems to change the overlay behavior so that the black level issue is fixed and image quality is improved a lot IMO.
I'm using Windows 7, and PowerDVD 9 by default use overlay instead of EVR in windows 7, does it suggest that Overlay provides better image quality?
edigee
6th February 2010, 14:21
Can you use Cyberlink H264 PDVD9 decoder out of the box? I coudn't manage to do that when I tested PowerDVD 9 on my system. That's why I purchased ArcSoft Player instead. Power DVD9 decoder I use it from HDPack 2.2 (not 2.3!!!-be carefull).
Unfortunately my system is not strong enough to carry all HD videos in software mode ,so i prefer DXVA despite the amount of quality loss.
pirlouy
6th February 2010, 14:39
One advantage with Overlay mixer: you don't have tearing at all.
It's not the case with EVR or madVR (for now).
Motenai Yoda
6th February 2010, 14:41
FFDShow with dethering disabled+EVR CP: very bad quality, I'll not choose this combination.
with catalist 10.1/9.12 the output stream from ffdshow sould be in yuy2 to be rendered right by evr.
u can also try evr-sync
somy
6th February 2010, 15:38
One advantage with Overlay mixer: you don't have tearing at all.
It's not the case with EVR or madVR (for now).
Hi,
I also noticed this. I'm annoyed by lip sync issue with MadVR, so I'm considering to change renderer.
Also pls notice that powerdvd9 by default use overlay for blu-ray playback, and the image quality looks very good.
somy
6th February 2010, 15:40
Can you use Cyberlink H264 PDVD9 decoder out of the box? I coudn't manage to do that when I tested PowerDVD 9 on my system. That's why I purchased ArcSoft Player instead. Power DVD9 decoder I use it from HDPack 2.2 (not 2.3!!!-be carefull).
Unfortunately my system is not strong enough to carry all HD videos in software mode ,so i prefer DXVA despite the amount of quality loss.
I used something called powerdvd 9 video decoder, you can add it to your external fillter in MPC-HC.
somy
6th February 2010, 16:21
with catalist 10.1/9.12 the output stream from ffdshow sould be in yuy2 to be rendered right by evr.
u can also try evr-sync
I tried YUY2, and it's not at the same quality as Overlay+DVXA.
I tried the grey scale test patter, only MadVR, FFDShow with dethering and Overlay mixer do NOT produce any noticable colour blocks.
somy
6th February 2010, 19:21
One advantage with Overlay mixer: you don't have tearing at all.
It's not the case with EVR or madVR (for now).
For dual screen setup, Overlay seems to be the only mode that works without lagging/judder and syncronization issue. Plus you get BTB and WTW in overlay :)
roozhou
6th February 2010, 21:40
Overlay, VMR7/9 and EVR all use bilinear scaling by default. They should all look close to each other if the same frame are rendered.
P.S. NV cards + Overlay has problem in chroma scaling with some samples.
pirlouy
6th February 2010, 22:06
But you can use ffdshow to do upscaling, don't you ?
Ok, from madVR thread, ffdshow upscaling is less good, but tearing is more problematic than upscaling.
When EVR Sync and MadVR will be updated, I'll try again, but for now, overlay mixer + ffdshow (upscaling + subtitles) with reclock is the best solution in my case.
But I admit I'm not not an expert who can detect differences between images quality.
somy
7th February 2010, 01:24
Overlay, VMR7/9 and EVR all use bilinear scaling by default. They should all look close to each other if the same frame are rendered.
P.S. NV cards + Overlay has problem in chroma scaling with some samples.
It seems to me that overlay has dithering by default and you do NOT need YUC/RGB in overlay mode. It looks very close to MadVR if you see try the grey scale video. If you use EVR you need to have dethering enabled in FFDshow in order to get similar quality, in which case YUC/RGB convertion is required and you will not get WTW and BTW.
flanger216
7th February 2010, 04:16
Oh boy...
First off, what video card were you testing!?
You're using two different decoders, so how is this an isolated test of renderer quality?
It's dIthering.
Whether or not overlay, or EVR, preserves BTB and WTW information is entirely dependent on the video card and how it's set up. Plenty of cards do not preserve BTB/WTW in overlay mode, and plenty do in EVR.
Almost all remotely modern video cards, when fed an NV12 colorspace, operate just fine in EVR mode.
Overlay is so manifestly inferior to EVR (and even VMR) that I can't believe it's coming up. Overlay is restricted to bilinear scaling, whereas in EVR, you get vastly superior bicubic resizing. Many overlay pipelines operate at 6-bits/channel. In EVR, 8-bits is the minimum, and you can potentially go up to 10-bits. Advanced spatial/temporal deinterlacing is only available through EVR in an NV12 colorspace, whereas in overlay, you're stuck with good old bob 'n' weave. Jesus, you might as well use a $50 set-top player.
The only likely difference you'd ever spot between these renderers, apart from the differing scalers, is the quality of chroma upsampling. If your card does have issues with chroma upsampling, and many ATIs do, then you need to enable an MPC-HC shader called 'YV12 Chroma Upsampling.' Bingo bango, problem solved.
And good god almighty, PowerDVD is not a standard of correctness. I, and many others, would claim the opposite.
roozhou
7th February 2010, 09:00
Many overlay pipelines operate at 6-bits/channel.
Can you provide an example? Which video card uses 6bit?
pirlouy
7th February 2010, 12:34
For upscaling and deinterlacing, you can use software, don't you ?
Apart that, I'm not an expert, I don't understand what "Many overlay pipelines operate at 6-bits/channel" means, but I have to admit I don't understand anything at all options which offer xx bits operations (madVR or EVR Custom). Maybe one day, I'll google this... :/
somy
7th February 2010, 13:22
Oh boy...
First off, what video card were you testing!?
You're using two different decoders, so how is this an isolated test of renderer quality?
It's dIthering.
Whether or not overlay, or EVR, preserves BTB and WTW information is entirely dependent on the video card and how it's set up. Plenty of cards do not preserve BTB/WTW in overlay mode, and plenty do in EVR.
Almost all remotely modern video cards, when fed an NV12 colorspace, operate just fine in EVR mode.
Overlay is so manifestly inferior to EVR (and even VMR) that I can't believe it's coming up. Overlay is restricted to bilinear scaling, whereas in EVR, you get vastly superior bicubic resizing. Many overlay pipelines operate at 6-bits/channel. In EVR, 8-bits is the minimum, and you can potentially go up to 10-bits. Advanced spatial/temporal deinterlacing is only available through EVR in an NV12 colorspace, whereas in overlay, you're stuck with good old bob 'n' weave. Jesus, you might as well use a $50 set-top player.
The only likely difference you'd ever spot between these renderers, apart from the differing scalers, is the quality of chroma upsampling. If your card does have issues with chroma upsampling, and many ATIs do, then you need to enable an MPC-HC shader called 'YV12 Chroma Upsampling.' Bingo bango, problem solved.
And good god almighty, PowerDVD is not a standard of correctness. I, and many others, would claim the opposite.
Sorrt I forgot to mention my video card is ATI HD4850.
I agree with you that the scaler comes with overlay is not as good as EVR. However I think overlay provide the following benifits:
1. In dual display setup when you play video on 2nd display which is in different refresh rate, overlay does NOT cause any judder or lag.
2. Overlay doesn't introduce any tearing when aero is turned off.
3. You do NOT need YUC/RGB convertion in FFDShow, and you preserve BTB and WTW in overlay. EVR doesn't preserve BTB and WTW for ATI graphics card when an ATI HDMI dongle is used
4. Auto refresh rate changer works with overlay (not with MadVR)
5. No annoying lip sync problem with overlay.
5.
somy
7th February 2010, 14:24
See the attched screen shots:
1) EVR CP with YV12 input. You can easily see that the transition from white to black isn't smooth at all.
2) EVR CP with RGB32 input, dithering and high quality YUC/RGB conversion enabled in ffdshow. The transition from white to black is much smoother, and the result is close to MadVR.
3) With regards to overlay, I cannot take a screenshot, but the result looks exactly the same as 2) and MadVR.
Can somebody explain why YV12/NV12 (I tried both) looks so bad in EVR CP???
somy
7th February 2010, 15:46
Oh boy...
First off, what video card were you testing!?
You're using two different decoders, so how is this an isolated test of renderer quality?
It's dIthering.
Whether or not overlay, or EVR, preserves BTB and WTW information is entirely dependent on the video card and how it's set up. Plenty of cards do not preserve BTB/WTW in overlay mode, and plenty do in EVR.
Almost all remotely modern video cards, when fed an NV12 colorspace, operate just fine in EVR mode.
Overlay is so manifestly inferior to EVR (and even VMR) that I can't believe it's coming up. Overlay is restricted to bilinear scaling, whereas in EVR, you get vastly superior bicubic resizing. Many overlay pipelines operate at 6-bits/channel. In EVR, 8-bits is the minimum, and you can potentially go up to 10-bits. Advanced spatial/temporal deinterlacing is only available through EVR in an NV12 colorspace, whereas in overlay, you're stuck with good old bob 'n' weave. Jesus, you might as well use a $50 set-top player.
The only likely difference you'd ever spot between these renderers, apart from the differing scalers, is the quality of chroma upsampling. If your card does have issues with chroma upsampling, and many ATIs do, then you need to enable an MPC-HC shader called 'YV12 Chroma Upsampling.' Bingo bango, problem solved.
And good god almighty, PowerDVD is not a standard of correctness. I, and many others, would claim the opposite.
I would really want some examples of 6-bits pipelines, thanks!
pirlouy
7th February 2010, 16:10
@Somy: use an external images host site; I'm not sure your images will be approved one day. ;-)
somy
7th February 2010, 16:18
@Somy: use an external images host site; I'm not sure your images will be approved one day. ;-)
Can you see them?? :thanks:
pirlouy
7th February 2010, 16:33
No: nobody can before an admin approves them, and when they are approved, a lot of people forget to read the updated post again.
namaiki
7th February 2010, 17:38
2. Overlay doesn't introduce any tearing when aero is turned off.
More like Overlay will force disable Desktop Composition.
One advantage with Overlay mixer: you don't have tearing at all.
You might be surprised, one of my laptops experiences tearing when using Overlay, but not with EVR.
flanger216
8th February 2010, 00:17
Sorrt I forgot to mention my video card is ATI HD4850.
I agree with you that the scaler comes with overlay is not as good as EVR. However I think overlay provide the following benifits:
1. In dual display setup when you play video on 2nd display which is in different refresh rate, overlay does NOT cause any judder or lag.
2. Overlay doesn't introduce any tearing when aero is turned off.
3. You do NOT need YUC/RGB convertion in FFDShow, and you preserve BTB and WTW in overlay. EVR doesn't preserve BTB and WTW for ATI graphics card when an ATI HDMI dongle is used
4. Auto refresh rate changer works with overlay (not with MadVR)
5. No annoying lip sync problem with overlay.
5.
I don't think you're getting it. Overlay possibly provides those benefits to you. The issue here is that doom9 is a widely-read forum indexed by search engines. Type in 'EVR and overlay' into google, and this thread comes up on the first page of results. Passers-by looking for HTPC info are going to stumble on this and see a bunch of grand declarations being made as if they were actual, informed analyses. But they're not. They're conjectures that are completely specific to your set up. Here, I'll do exactly what I just did in my last post:
It's not a matter of agreement. The bilinear scaler in overlay is manifestly inferior to those available in either EVR or VMR.
1. "Overlay does NOT cause any judder or lag" FOR YOU! I always watch videos on my second display... with a different refresh rate and resolution... in EVR... and it does not introduce judder.
2. That's great, except you're implying that EVR always has tearing when AERO is turned off. But it doesn't. It might happen on your computer, but it's not an inherent quality of EVR.
3. You do not "need" RGB32 conversion in ffdshow, ever. As I've said, NV12 in EVR (w/ a chroma upsampling shader on ATI hardware) gives very similar results. And hooray! You accurately assessed that on your system, EVR doesn't preserve WTW/BTB because you're using an ATI dongle. See, you don't always have to phrase things as if they're universally true.
4. And it also works with EVR. That sounds like a complaint against madVR.
5. Yes, because everyone on the planet who uses EVR is having lip-sync issues. See, I just never noticed it before :rolleyes:
It's the solipsism that's driving me nuts. Ideally, you would've posted your observations pertaining to your system, and you could've asked for observations and advice from people with similar hardware. Instead, you've busted in acting like you've reinvented the wheel, as if none of us have ever taken the time to look into these things, and it's ridiculous.
As of a few generations ago, ATI hardware overlays bypassed the main RAMDAC and operated in, essentially, a legacy VGA mode @ 6bits/color. I have neither the time nor the inclination to unearth the white papers to that effect, as having to defend EVR against overlay remains a preposterous endeavor. Overlay is a legacy renderer, period. If you're having issues that force you to use it, then oh well, but seriously trying to claim that overlay is an ideal choice is unacceptable.
pirlouy
8th February 2010, 00:52
- Upscaling: ffdshow can do this instead of Overlay, so I don't see the problem
- tearing: In me configuration, Overlay has no problem at all (it's not the case of EVR and madVR for now)
- judder: reclock works well with Overlay, there is no conflict since Overlay does nothing to avoid judder
- image quality: I guess there are better renderer, but I think image quality is not as noticable as tearing or judder.
I don't think Overlay is that deprecated. It just needs tools to work better (ffdshow and reclock for example).
namaiki
8th February 2010, 01:38
...but why would someone want to use Overlay instead of EVR? (not EVR-Custom, though that is more fully featured)
Stephen R. Savage
8th February 2010, 04:29
Well, on my Intel GMA X3100, EVR standard produces a very visible chroma shift when scaling as well as blocking on blue-colored objects. Also, Overlay is pretty much guaranteed to have 0 overhead and 0 vsync problems.
namaiki
8th February 2010, 04:34
Also, Overlay is pretty much guaranteed to have 0 overhead and 0 vsync problems.
My GMA 950 (piece of crap) @ 1920x1080 will tear when using overlay but not with EVR.
somy
8th February 2010, 09:31
I don't think you're getting it. Overlay possibly provides those benefits to you. The issue here is that doom9 is a widely-read forum indexed by search engines. Type in 'EVR and overlay' into google, and this thread comes up on the first page of results. Passers-by looking for HTPC info are going to stumble on this and see a bunch of grand declarations being made as if they were actual, informed analyses. But they're not. They're conjectures that are completely specific to your set up. Here, I'll do exactly what I just did in my last post:
It's not a matter of agreement. The bilinear scaler in overlay is manifestly inferior to those available in either EVR or VMR.
1. "Overlay does NOT cause any judder or lag" FOR YOU! I always watch videos on my second display... with a different refresh rate and resolution... in EVR... and it does not introduce judder.
2. That's great, except you're implying that EVR always has tearing when AERO is turned off. But it doesn't. It might happen on your computer, but it's not an inherent quality of EVR.
3. You do not "need" RGB32 conversion in ffdshow, ever. As I've said, NV12 in EVR (w/ a chroma upsampling shader on ATI hardware) gives very similar results. And hooray! You accurately assessed that on your system, EVR doesn't preserve WTW/BTB because you're using an ATI dongle. See, you don't always have to phrase things as if they're universally true.
4. And it also works with EVR. That sounds like a complaint against madVR.
5. Yes, because everyone on the planet who uses EVR is having lip-sync issues. See, I just never noticed it before :rolleyes:
It's the solipsism that's driving me nuts. Ideally, you would've posted your observations pertaining to your system, and you could've asked for observations and advice from people with similar hardware. Instead, you've busted in acting like you've reinvented the wheel, as if none of us have ever taken the time to look into these things, and it's ridiculous.
As of a few generations ago, ATI hardware overlays bypassed the main RAMDAC and operated in, essentially, a legacy VGA mode @ 6bits/color. I have neither the time nor the inclination to unearth the white papers to that effect, as having to defend EVR against overlay remains a preposterous endeavor. Overlay is a legacy renderer, period. If you're having issues that force you to use it, then oh well, but seriously trying to claim that overlay is an ideal choice is unacceptable.
First of all, I'm not saying overlay is much better than EVR, instead I just presented some of my observation.
Secondly, the reason why I'm discussing this here is I do NOT even believe overlay can be better than EVR, but the result is obvious, so I'm wondering why in my setup EVR produce worse result than overlay.
I agreed in the very beginning that EVR is a more advanced renderer in windows 7, and every HTPC users should try EVR first before overlay. However for ATI users who have to use the official HDMI dongle, choose YCrCb pixel format and let overlay to draw YUC is simply a much better idea because:
1). it reduces the number of RGB/YUC conversion as well as luma conversion (0-255/16-235). Luma conversion introduces floating numbers and to avoid banding you need to dither (which introduces noise).
2). BTB and WTW is reserved in overlay so that if the movie contains WTW, it will be captured and displayed by some TV/projectors.
If you're so kind, would you please share your setting of decoder, renderer and player so that we can give a try? Thanks.
iSeries
8th February 2010, 17:47
@flanger216 - sorry to go off topic for a minute, if using NV12 is the chroma upsampling shader you talk about the 'YV12 Chroma Upsampling' shader in MPC HC? And this gives similar results to high quality RGB conversion with dithering in ffdshow? I've thought about using this shader before, but the name implies its for use with YV12, not NV12 (not that I really understand the difference between the two).
roozhou
8th February 2010, 18:31
@flanger216 - sorry to go off topic for a minute, if using NV12 is the chroma upsampling shader you talk about the 'YV12 Chroma Upsampling' shader in MPC HC? And this gives similar results to high quality RGB conversion with dithering in ffdshow? I've thought about using this shader before, but the name implies its for use with YV12, not NV12 (not that I really understand the difference between the two).
AFAIK 'YV12 Chroma Upsampling' shader in MPC-HC is just doing bilinear interpolation when the hardware does nearest neighbor upscale on chroma.
somy
9th February 2010, 21:23
OK, I have done some more tests with EVR and Overlay, and I want to annoy flanger216 once again:
1) EVR with NV12 input, YV12 chroma shader enabled in MPC: No WTW/BTB and serious banding due to luma conversion. When calibrating with AVSHD disk, the red colour is way off. Bicubic scaler works fine but still produces noticable banding (again due to luma conversion I think).
2) Overlay with YV12 input+YCrCb 4:4:4 pixel format output: WTW/BTB is sent over to my projector, no banding since no luma conversion is needed (input 0-255 and output 0-255, my projector cuts WTW and BTB).The colour is much more accurate, almost perfect on my projector, I only increased colour by 1 and decrease hue by 1 on my projector (BTW my projector comes with waveform monitor so I didn't use the blue/red/green filters at all). Scaling works fantastic! I used test pattern from MadVR, and the final result looks almost identical to MadVR, no banding when I resize the Video.
OK, all the above observations are made based on my setup, I would suggest people who has ATI graphics card upgrade to CCC 9.12 or 10.1 and try overlay renderer. It definately works for me!
iSeries
9th February 2010, 23:47
I have an ATI card (4550) and I've just gone from 9.12 to 10.1. Absolutely no issues with EVR, EVR CP or Sync Renderer, so no reason at all for me to use a legacy renderer.
And doesn't Madshi believe the ATI drivers first convert to RGB before converting again to YCrCb (first page of MadVR thread) - if this is the case choosing YCrCb 4:4:4 would certainly result in less than optimal output.
somy
10th February 2010, 09:46
I have an ATI card (4550) and I've just gone from 9.12 to 10.1. Absolutely no issues with EVR, EVR CP or Sync Renderer, so no reason at all for me to use a legacy renderer.
And doesn't Madshi believe the ATI drivers first convert to RGB before converting again to YCrCb (first page of MadVR thread) - if this is the case choosing YCrCb 4:4:4 would certainly result in less than optimal output.
Hi iSeries,
I agree if EVR works for you should stick with it. Just curious, do you use ATI's HDMI dongle to output HDMI? If so would you mind to share your settings of ffdShow, MPC-HC and EVR? Have you tried any greyrump test video such as the one made by Madshi (http://forum.doom9.org/showthread.php?t=146203)? That gave me banding when EVR converts NV12 to RGB32 and I believe banding is introduced due to 16-235/0-255 conversion without dithering. Thanks a lot in advance!
For me, I believe ATI made some some shortcut for YCrCb so that:
1) It now give BTB and WTW (before it wasn't possible if you use ATI's dongle)
2) RGB content is still compressed to 16-235 and video content in overlay renderer seems untouched, so no luma conversion and hopefully no RGB/YUC conversion, however chroma resampling (4:2:0 - 4:4:4) is still required, and I'm not sure if that damages the image quality. I'd like to test the quality of chroma resampling in the graphics card, but don't know how :(
somy
10th February 2010, 14:38
No: nobody can before an admin approves them, and when they are approved, a lot of people forget to read the updated post again.
You should be able to see the images now :)
It's clear that the first picture introduces banding due to luma resampling, and EVR does NOT apply dither to it.
pirlouy
10th February 2010, 19:34
Yes, I can see them, but I think it breaks layout of the page (I have my own style to prevent this). People prefer thumbnail in general. ;)
However, I can't help you for explanation for RGB or YUC or things like that, as I don't understand these things ! :D
somy
11th February 2010, 12:50
Yes, I can see them, but I think it breaks layout of the page (I have my own style to prevent this). People prefer thumbnail in general. ;)
However, I can't help you for explanation for RGB or YUC or things like that, as I don't understand these things ! :D
:eek::eek::eek:
Now RGB/YUC topic any more :)
Just check the image, and you'll see banding in EVR.
namaiki
2nd March 2010, 03:59
Curiously, Haali's Renderer and EVR have banding with YV12, though Haali's renderer seems to like YUY2 (no banding).
http://www.avsforum.com/avs-vb/showthread.php?t=948496
Tested with CoreAVC and ffdshow video separately + MPC-HC (32-bit) + Windows 7 64-bit
My 4500MHD's Overlay has banding with YV12, but not Overlay with GeForce 9600M GT.
edit: in fact, I have no idea what scaler 4500MHD uses for overlay.. looks like a mix of everything bad from bilinear, bicubic and nearest neighbour.. blurry and blocky all over..
edit2: just to clarify, I was checking for banding with the video at 100%/1:1 pixel
Astrophizz
2nd March 2010, 05:43
I tend to convert YV12 from a given decoder to RGB with ffdshow (dithering) and then send that to Haali's Renderer, but if I can skip that with YUY2 that would be great. Do you think that would be appropriate?
namaiki
2nd March 2010, 05:54
derp. I just checked again.. Haali's renderer doesn't connect to YV12.
...but I don't seem to get banding with YUY2 in Haali's renderer.
download the mp4 version from http://www.avsforum.com/avs-vb/showthread.php?t=948496 and open Section-A.mp4 so you can check for yourself. Make sure the video is open at 1:1. THe resolution is 1920x1080, so generally in Haali's Renderer you will have to set video resolution to 2x if the file resolution is reported to MPC-HC as 960x540.
Astrophizz
2nd March 2010, 09:17
Looks like I'm staying with YV12->RGB32(dithered) for Haali's Renderer. I'm seeing dithering in YUY2 when I compare it to YV12->RGB32(dithered). I can upload captures if you'd like, namaiki.
tetsuo55
2nd March 2010, 09:29
Sorry for being late, but can we keep things as scientific as possible?
Alle renderers should be compared, not only on anecdotal basis but with real evidence.
the renderers unfortunately cannot be compared with screenshots, so we need someone to use a hd camera to show the differences.
Also results with different os's and videocards will vary too
My goal is to find each and every difference when compared to "EVR-CP" and then put all those differences on the evr-cp to-do list
-----
Things to look for:
* smoothness of playback (according to the statistics and your interpretetation of the image)
* RGB conversion quality
* chroma scaling quality
* luma scaling quality
* all tests with and without videocard postprocessing enabled
for the last 3 madvr should be the benchmark
namaiki
2nd March 2010, 10:05
RGB conversion I can say nothing about. However, regarding scaling quality, do you meant to compare bilinear/bicubic with MadVR's algorithms, because for instance, bicubic should be bicubic no matter in which renderer(same for bicubic). So in terms of scaling quality, EVR and Haali's Renderer should kind of be about the same.
Regarding smoothness, I would say that EVR-Custom is the smoothest, and Haali's Renderer is like EVR-Custom with Aero enabled for the screen, but with V-sync disabled for MPC-HC. (My screen is 62Hz, so it's easy to tell when things go wrong.)
I'm seeing dithering in YUY2 when I compare it to YV12->RGB32(dithered).
This is a bit of a mouthful. Sorry, but I don't understand it, so I guess I would appreciate screenshots (better than nothing).
Astrophizz
2nd March 2010, 11:30
Link to mediafire "folder" with two captures from mpc-hc: http://www.mediafire.com/?sharekey=35576ac448e47d88931c7453395df025db8b1f9aabfb8c6b947708e37b913e74
I don't know how using a camera would be useful to show differences... If you did that you'd have to control for all sorts of things and the specs of the camera would play a strong role. And besides the image from a camera would be an integration of pixels from the monitor. I thought the better renderers weren't effected by the graphics card so using captures would work?
namaiki
2nd March 2010, 12:11
Yup.. I see YUY2 looks a bit rainbowy (in bars) but still better than EVR + YV12.
tetsuo55
2nd March 2010, 12:39
RGB conversion I can say nothing about. However, regarding scaling quality, do you meant to compare bilinear/bicubic with MadVR's algorithms, because for instance, bicubic should be bicubic no matter in which renderer(same for bicubic). So in terms of scaling quality, EVR and Haali's Renderer should kind of be about the same.
Regarding smoothness, I would say that EVR-Custom is the smoothest, and Haali's Renderer is like EVR-Custom with Aero enabled for the screen, but with V-sync disabled for MPC-HC. (My screen is 62Hz, so it's easy to tell when things go wrong.)
This is a bit of a mouthful. Sorry, but I don't understand it, so I guess I would appreciate screenshots (better than nothing).RGB conversion has to be tested with screenshots or "scientifically correct" photographs (basically measuring the difference between both images)
luma and chroma should be scaled independently, and this already occurs to some extent om most renderers.
A well known issue is that ati has terrible hardware chroma scaling.
and finally, although you might thingk bicubic is bicubic that's actually not true, if you do a close inspection and ssim/psnr check you will find that many implementations vary in image quality
Link to mediafire "folder" with two captures from mpc-hc: http://www.mediafire.com/?sharekey=35576ac448e47d88931c7453395df025db8b1f9aabfb8c6b947708e37b913e74
I don't know how using a camera would be useful to show differences... If you did that you'd have to control for all sorts of things and the specs of the camera would play a strong role. And besides the image from a camera would be an integration of pixels from the monitor. I thought the better renderers weren't effected by the graphics card so using captures would work?screenshots cannot capture all the post processing done by videocards
The camera should be used to find differences between the images. when compared to a static image also filmed or photographed by the camera
Starting with screenshots, and then evaluating any differences with a camera later is also a good way to start.
MadVr had a good comparison to show of its chroma scaling when compared to other renderers
somy
2nd March 2010, 14:01
Hi tetsuo55,
Thank you for your help!
The problem is when a renderer tries to expand video luma to PC luma (from 16-235 to 0-255), it introduces banding unless dither is implemented.
For PC users, the output is normally RGB 0-255, therefore both Halli and EVR need to expand luma from 16-235 to 0-255:
1) it cuts BTB 0-16 and WTW 235-255 first
2) then it map each value in 16-235 to 0-255 range, and this step introduces fractional numbers which are then rounded up by renderer. And the banding is normally introduced in this step.
There are two solutions to this problem:
1) Implement dither for each renderer, but this solution is not optimal because BTB and WTW are still cut and dither introduces noise. This requires to implement a dither shader for EVR, and it's optimal option for PC monitor.the
2) Make renderer draw on YUV surface to get 0-255 YUV output without doing any change to luma, this is best when using TV or projector as display device. My experience shows ATI HD4850 works in this way if choosing overlay mixer as renderer as the image shows:
http://forum.doom9.org/showthread.php?p=1371829#post1371829
Somehow HD5XXX also support YUV full range output, see my photos:
http://www.avsforum.com/avs-vb/showthread.php?p=18229182#post18229182
They still have problems with colour, but all in all it's worth a try.
The temp solutions for now are:
1) Use MadVR because dither is enabled by the renderer
2) Use FFDshow HQ RGB conversion with dither enabled.
3) If you have HD4XXX graphics card and uses your TV as display, try YCrCb 4:4:4 pixel format and feeding YV12 directly to Overlay mixer.
Jong
2nd March 2010, 14:26
There is no problem with ATI 5xxx YCbCr colour when the renderer writes directly to a YCbCr overlay surface, as does TMT3 and PDVD and banding is eliminated.
Of course the colour bug may be fixable, but the banding issue is less easy to resolve. In fact probably not resolveable when using DXVA unless an overlay surface is used.
Generally mpc-hc seems to have the best possible chance of giving optimal video quality if it is able to write to a YCbCr overlay surface, but still using EVR to do any necessary resizing. Then the original YCbCr data (chroma upsampled of course) can be written without any colour or level translation YCbCr -> RGB (-> YCbCr [optionally]) as at present and the player is more resilient to the, ever present, driver bugs!
namaiki
2nd March 2010, 14:33
and finally, although you might thingk bicubic is bicubic that's actually not true, if you do a close inspection and ssim/psnr check you will find that many implementations vary in image quality
All I meant was, the video renderer using only bilinear or bicubic isn't going to look as good as, say, MadVR.
In my opinion, bilinear is generally too soft and bicubic introduces artifacts (ringing) but the former are probably good enough for most users (i.e. people would complain if nearest neighbour was default).
Anyways, tetsuo55, I reckon you are doing a great thing here with the MPC-HC suggestion threads. Thanks for the work, really. m(_ _)m
somy
2nd March 2010, 15:09
There is no problem with ATI 5xxx YCbCr colour when the renderer writes directly to a YCbCr overlay surface, as does TMT3 and PDVD and banding is eliminated.
Of course the colour bug may be fixable, but the banding issue is less easy to resolve. In fact probably not resolveable when using DXVA unless an overlay surface is used.
Generally mpc-hc seems to have the best possible chance of giving optimal video quality if it is able to write to a YCbCr overlay surface, but still using EVR to do any necessary resizing. Then the original YCbCr data (chroma upsampled of course) can be written without any colour or level translation YCbCr -> RGB (-> YCbCr [optionally]) as at present and the player is more resilient to the, ever present, driver bugs!
Hi Jong,
Although there is no major banding, my test (see image: http://www.maimuzi.com/HTPC/1.JPG) still shows that the transition from black to white isn't smooth (see the red box marked with 1) and the curve isn't a straight line. Also the BTB between 0-6 is cut by graphics card (see the red box marked with 2). All in all I think some post processing is still applied.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.