View Full Version : Haali Renderer
chros
20th May 2008, 08:50
Thanks Lee for the info, I will be chewing this ... :)
leeperry
20th May 2008, 11:07
no probs ;)
actually there's also a pstrip rule.
if you multiply the horizontal lines X vertical lines X refresh rate, you need to achieve no more than 3 digits after the coma(major Kudos to Seb.26 for this one :D )
that's your ramdac freq., if it's not roundable you're screwed as well.........which makes it difficult to find perfectly rock stable timings >50Hz
anyhow, your goal is to have a rock solid frame rate in MPC HC with EVR(or VMR9?), that ensures that HR will go smoooooooooth on ya :D
that's 48Hz with 23.976@24fps in Reclock :
http://pix.nofrag.com/3/7/2/f98f1346879d82dbb61dd7ab4eca8tt.jpg (http://pix.nofrag.com/3/7/2/f98f1346879d82dbb61dd7ab4eca8.html)
that's 50Hz with 25fps in Reclock :
http://pix.nofrag.com/7/7/5/7493d1d07b953e4e2d18f12fb935ftt.jpg (http://pix.nofrag.com/7/7/5/7493d1d07b953e4e2d18f12fb935f.html)
that's 60Hz with 23.976@30 fps in Reclock ( didn't have any 29.97 material around) :
http://pix.nofrag.com/5/0/f/b3d98ca920fcaa842da046432726btt.jpg (http://pix.nofrag.com/5/0/f/b3d98ca920fcaa842da046432726b.html)
as long as your frame rate oscillates(even slightly), it won't be as smooth in HR...
wozio
20th May 2008, 13:31
I have a question guys:
Do you use vsync? Fullscreen or windowed?
Asking because if you use fullscreen with vsync then jitter at the renderer less than one refresh period will not be visible anyway.
I often watch 50Hz tv on 50Hz LCD and motion is very smooth without any glitch. But I use vsync in fullscreen exclusive. In that mode rendering is bind to refresh of the screen so movie frame waits for screen anyway.
Of course display refresh rate must be equal or multiply of movie frame rate.
Regards
Piotr
leeperry
20th May 2008, 13:51
I don't use the D3D fullscreen mode, but I've got VSYNC forced in the ATi drivers(HR enforces it anyway).
these screenshots were taken in windowed customized EVR in MPC HC.
actually in D3D FS mode in MPC HC, I never get a rock stable frame rate :eek:
anyhow, in whatever mode/renderer MPC HC always loses A/V sync after 45/60 mins
it's been witnessed on many different computers, using different components....some major incompatiblity with Reclock I guess.
but when you get perfectly stable results in MPC HC, then it's the same story with HR :
http://pix.nofrag.com/2/3/d/ebd27048710629a8696f0b160a1c7tt.jpg (http://pix.nofrag.com/2/3/d/ebd27048710629a8696f0b160a1c7.html)
http://pix.nofrag.com/8/5/7/1322aad279fc807b06d0d0f419847tt.jpg (http://pix.nofrag.com/8/5/7/1322aad279fc807b06d0d0f419847.html)
http://pix.nofrag.com/f/9/b/81dd8c12bef74f9e318a9b9c55398tt.jpg (http://pix.nofrag.com/f/9/b/81dd8c12bef74f9e318a9b9c55398.html)
this is 25 and 50 fps 720p material in 50Hz(same timings as above with MPC HC)
leeperry
26th May 2008, 19:00
anyone knows what the jitter figure in the OSD actually measures ?
I mean I can start some movies and seek several times to achieve 0.01 ms, then 90 minutes later being at 2/3 ms
and sometimes I end at 10 ms(mostly with full bitrate DTS), and still no dropped frames ?
OTOH, with very high bitrate 1080p in RGB32HQ with resizing/sharpening in ffdshow, it quickly grows >300ms, so obviously I'm getting lot of dropped frames.
what's the acceptable jitter limit ? is it always linked with dropped frames ?
TIA,
Mercury_22
26th May 2008, 20:52
Any chance for a 64-bit version ?
wozio
27th May 2008, 06:55
@leeperry
What I think jitter stands for difference between time when frame should be displayed to time when it is actually displayed. So if you play 24 fps source each frame must be displayed every 41,6 ms so jitter of 10 ms will not lead to dropped frames. It depends of many things when frame will be dropped, as far as I can see in your case ffdshow drops frames when its jitter is more than 300 ms (it can be adjusted in ffdshow AFAIR).
leeperry
27th May 2008, 09:15
well I've checked "drop frame on delay : 1 ms" in ffdshow, it smoothes things up a lot...mostly it avoids hiccups when seeking.
and I guess the HR jitter is based on the original framerate data(e.g 23.976fps), but Reclock is changing it(23.976@24)........so how accurate is that figure ?! :D
on the last screenshot I posted above, you can see that HR says "25fps specified" >> "24 achieved"......yet I get 0.01ms jitter :D
wozio
28th May 2008, 06:57
Jitter is calculated for one frame not for whole file. Framerate is specified at connection between decoder and renderer and this is specified framerate. But each frame has its own time when it should be shown on screen and jitter is calculated for one current frame. For example you can have formats where variable frame rate is used (I have one such rmvb file, where when nothing changing on screen framerate drops to zero) and still have low jitter. This is common for tv broadcasts to have pal/ntsc framerate specified but inside 25 or 23,976 fps progressive frames and the you will also have mismatch between specified and achieved framerate.
Reclock as name suggests, changes clock thus changes times when frames should be presented. It doesn't change specified stream framerate.
neoufo51
29th May 2008, 10:09
Does anybody know the general parameters for changing the settings on the Haali Renderer properties page?
For example, I have a Core 2 @2ghz w/ 2GB of RAM and a 128mb 8400GS card on my laptop.
How do I know from my specs what the frames and buffer size settings should be?
leeperry
29th May 2008, 10:15
Reclock as name suggests, changes clock thus changes times when frames should be presented. It doesn't change specified stream framerate.
it does change the frame rate.
look at the above screenshot.
25 specified, 24 achieved.
I've slowed down this accelerated NTSC to normal speed.
and HR seems to get its infos from HMS, which doesn't "know" Reclock is changing the timestamps :D
wozio
29th May 2008, 11:57
This is exactly what I wrote. By changing clock reclock changes timestamps of the frames (when frame should be presented). Specified framerate is taken from connection media type to renderer.
kutjong
29th May 2008, 14:05
Does anybody know the general parameters for changing the settings on the Haali Renderer properties page?
For example, I have a Core 2 @2ghz w/ 2GB of RAM and a 128mb 8400GS card on my laptop.
How do I know from my specs what the frames and buffer size settings should be?
The buffer in HR uses RAM of your graphics card. I have 256 MB on mine, so I've set the buffer to 128 MB and 120 frames. You could set yours to about 64 MB and frames to 60.
neoufo51
30th May 2008, 00:49
The buffer in HR uses RAM of your graphics card. I have 256 MB on mine, so I've set the buffer to 128 MB and 120 frames. You could set yours to about 64 MB and frames to 60.
Done and I now notice slightly more improved playback! Thanks!
kutjong
31st May 2008, 18:11
Hm, I've come up with a strange incompatibility with HR and Reclock. Specifically it only concerns DVDs... Using MPC (clsid), ffdshow video decoder (libmpeg2), AC3filter, Reclock (1,7 beta4) and HR results in the player locking up if I try to play back a dvd. If I use the default directsound renderer with HR everything's fine, also if I use VMR9 renderless instead of HR with Reclock there is no trouble either.
So clearly there's an incompatibility using HR with Reclock for DVDs. HR and Reclock work completely fine with other video files, e.g. xvid, x264 mkv...
Does anybody else have this problem?
For now I'm using VMR9 for dvds, it would be fine if it just had an OSD like HR. :) VMR9's scaling is fine since I run my crt at 800x600@120 HZ for dvds, so there's minimal scaling.
...Does anybody else have this problem?
I have the exact same playback chain that your do, except I use JRiver's Media Center 12 for playback, I have no problems with DVDs, either ripped or from the tray.
leeperry
1st June 2008, 11:22
@kutjong : try with another player, like KMPlayer.
there's a few things I've never really managed to do in MPC HC :
-read .ts properly
-read h264 .mov
-read mpeg2 program files
-get smooth playback >60 mins with Reclock
I registered the filters and stuff, but it never really worked flawlessly for some reason.
anyhow I've got many movies that randomly stutter with Haali Media Splitter+HR, and they play perfectly smoothly with KMP Matroska Reader
this issue has been observed by several ppl on another major forum......a simple fix was to demux their primary elements and remux them with the latest MKVtoolnix.
but well, it's not like Haali cares about bug reports..
neoufo51
1st June 2008, 12:17
I've always thought about using KMPlayer instead but the interface turns me off. However, if it plays files even better than MPC-HC and HR I might jump ship for that.
kutjong
1st June 2008, 13:08
but well, it's not like Haali cares about bug reports..
But he did add "autodetection" for colorimetry and for that I'm grateful. :) Anyway, I don't think there's much improvement to be made in HR anymore, except for DVD compatibility. It would be great if there was a way to use buffering when watching the movie itself. Deinterlacing is currently making my system drop frames because of the low buffer, but if I just manually open a specific .vob file, the buffer works normally and I get no dropped frames. :) But I think I already know that this seems impossible... How will HR be able to know if you're currently in the menu or watching the film?
Since I'm coming with suggestions here I believe HR's hardware "bobbing" could also use some interpolation, something like VLC's "linear" deinterlacer, which doubles framerate and adds linear interpolation for smoothing. :cool:
If these improvements would be made, HR would become the de facto renderer for the HTPC community. :) EVR could then GTFO. :devil:
leeperry
1st June 2008, 13:20
But he did add "autodetection" for colorimetry and for that I'm grateful. :)
yeah, I asked him about that feature like 6 months ago :
http://forum.doom9.org/showthread.php?p=1081395#post1081395
well, HR gives ghost lines with ATi cards when its built-in PS resizer is used, and its BT709 matrix is wrong(too blue).
maybe someday we'll see fixes for that ?
for the time being I output RGB32HQ from ffdshow and I make sure that upscaling is not done by HR(downscaling is done with AF and is perfectly fine).
gotta love being a beta-tester :p
kutjong
1st June 2008, 16:28
well, HR gives ghost lines with ATi cards when its built-in PS resizer is used, and its BT709 matrix is wrong(too blue).
I don't get any ghostlines with my Radeon X800 XT, but I'm using drivers from january 2006 (no improvements for R420 thereafter), so I don't know if your ghostlines are because of newer drivers or the Radeon R600 generation. PS 3.0 bicubic scaling has been removed in newest version so it can't be the difference in PS 3.0 and 2.0 scaling...
As for BT.709, are you sure that ffdshow's representation is correct and Haali's incorrect? I mean it seems that ffdshow's BT.709 just has more green, how do you know which representation is correct? :)
As for the DVD buffer problem, as clsid suggested earlier in this thread, is it possible to add some hotkey that would enable normal buffering when you start watching the actual movie? As I posted earlier, if you open .vobs manually buffering is normal but I think it's because the DVD navigator filter isn't used if you do that.
Bottom-line: Does the DVD navigator filter require the 4 frame buffer when watching the film, or is the 4 frame buffer only necessary for menus? :confused:
On-the-fly changing of the buffer with DVDs doesn't work (when I watch the film), seems that HR doesn't allow it as long as the DVD navigator is in the graph. :(
leeperry
1st June 2008, 17:30
well yeah, it's related to a bug in the ATi drivers.....still it needs to be fixed :(
yes, if you care to look at the previous pages, ffdshow in RGB32HQ outputs the same colorspace as the ATi drivers..........yet HR is too blue and not green enough :(
kutjong
1st June 2008, 18:28
well yeah, it's related to a bug in the ATi drivers.....still it needs to be fixed :(
Have you tried any older drivers? If the bug appeared in a specific driver version, then I think it's clearly up to AMD to fix the bug, not Haali. If we want this bug to be fixed then it should be presented to AMD in a properly manner so that it stands out from the other poorly made support tickets...
yes, if you care to look at the previous pages, ffdshow in RGB32HQ outputs the same colorspace as the ATi drivers..........yet HR is too blue and not green enough :(
Ok, but how do we know that ffdshow and AMD have the correct matrix? :p I mean, we can't be sure for 100 %, right? ffdshow's and AMD's BT.709 matrix is probably created on basis of an official paper on the standard, but I don't think Haali drew the code out of his magic hat... :p
I agree the changes (bugs, requests) from Haali are not quick but well it's free so...
leeperry
1st June 2008, 19:34
AMD is close to bankruptcy at this point, they don't give a damn about this issue.
I've got a HD2600XT, I'm not gonna run 10 year old drivers :D
well all my displays are carefully D65 calibrated, and I can tell you that the ATi/ffdshow matrix are perfectly fine.
apparently, HR does some rounding............that screws with the BT.709 coeffs :(
Shinigami-Sama
1st June 2008, 21:05
send haali 500$ and see how fast he fixes some of these bugs leeperry :P
leeperry
1st June 2008, 21:07
well I already sent him emails and PM's, how would $500 make a difference :D
kutjong
1st June 2008, 21:11
AMD is close to bankruptcy at this point, they don't give a damn about this issue.
AMD is going to own nvidia with the coming R700, so no worries of bankruptcy. :sly:
I've got a HD2600XT, I'm not gonna run 10 year old drivers :D
I didn't mean that you should keep running with those old drivers 24/7, just test if the bug is in all the driver versions for R600. If the bug isn't present in a certain catalyst version, we'll have something to base our support ticket with and hopefully get this issue resolved. :)
My next gfx card will probably a Radeon 4870 so I wouldn't mind having this bug resolved until that. :D
@Peuj: I would gladly donate to Haali if I could, but I can't find this possibility on his site..
Lantis
2nd June 2008, 01:20
Whenever I use Haali to bob the interlaced video the jitter increases (around 5 ms of jitter por 1 second of video) and never decreases. No a big problem for SD video, where I can use VMR9 or ffdshow to deinterlace. However, with 1080i content, VMR9 and ffdshow can't pump out the 60 fps and the video in unwatchable (10 or 15 fps). Only Haali can bob deinterlace HD video in relatime (the video is very fluid) but the jitter increments constantly making the video to be out of sync with the audio.
So I ask: Is there any way to fix the jitter when Haali's bob deinterlacing the video? If the answer is no, is there any other way to achieve realtime bob deinterlacing with HD stuff?
I have a Athlon 64 X2 4400+ and a GeForce 7600GT by the way.
wozio
2nd June 2008, 06:58
@Lantis
Your hardware should be perfectly capable of deinterlacing any content with VMR9. Are you sure it is a matter of renderer? Mine hardware is much less powerfull and I don't have any problem with deinterlacing.
Deinterlacing in VMR9/drivers is much better quality than HR.
Regards
Piotr
Lantis
2nd June 2008, 17:15
Thanks for the reply wozio.
ffdshow + VMR9 can handle interlaced SD content all right, with or without renderer deinterlacing. The problem surfaces with 1080i where it can't even play it interlaced at 30fps.
ffdshow + HR gives very good fps (even when bobbing 1080i at 60 fps) but there's the jitter problem.
Then I tried using CyberLink MPEG decoder instead of ffdshow to play the 1080i file.
CyberLink + VMR9 looks fine, even when set to 60fps.
CyberLink + HR doesn't correct the AR (where ffdshow + HR does) and does not bob.
It seems that the problem's solved! However, VMR9 is set to PC scale and the source is TV. And I couldn't find any switches to change the scale (neither on VMR9 nor the decoder).
So now reformulate my question: Is there any way to fix the jitter when Haali's bob deinterlacing the video? If the answer is no, is there any other way to change VMR9's output RGB levels without ffdshow?
kutjong
2nd June 2008, 23:44
is there any other way to change VMR9's output RGB levels without ffdshow?
If you're using MPC, there should be a 16-235->0-255 shader if you search in the shader list that you can find if you right-click on the video surface.
I'm currently also experiencing trouble with deinterlacing... With bob deinterlacers I can only reach 40 fps, regardless of which one I use! There is no difference if I use VMR9 renderless or HR. In ffdshow I have the interlace flag set to bob. But even with ffdshow's built-in software bob deinterlacer's I also only get 40 fps.
My graphics card is a Radeon X800 XT PE so I think it's clear that it should be well capable of HW deinterlacing... :confused: My processor is a P4 3,2E GHz so it shouldn't be too old for this stuff either.
FYI, I have AA and AF and the like on application preference.
Lantis
3rd June 2008, 00:28
Thanks, that did the trick! Now I can watch 1080i at 60 fps properly. Although I'm still interested if the jitter in HR can be fixed, I prefer using zplayer (I like the interface better) and HR (that colorimetry autodetect is nice) but well, beggars can't be choosers.
And as for your problem, try using another decoder, that solved the low FPS yield of VMR9 for me.
kutjong
3rd June 2008, 02:21
It seems that the 40 fps problem was because of scaling! If Haali outputs the resolution as is, HW bob works fine @ steady 50 fps.
http://i6.photobucket.com/albums/y249/Mara-23/smooth.jpg
But as soon as I go full-screen everything goes downhill:
http://i6.photobucket.com/albums/y249/Mara-23/notsmooth.jpg
Does this just mean that my X800 XT PE isn't fast enough to perform both deinterlacing and bicubic scaling?
wozio
3rd June 2008, 06:43
Although I'm still interested if the jitter in HR can be fixed, I prefer using zplayer (I like the interface better) and HR (that colorimetry autodetect is nice) but well, beggars can't be choosers.
So you mean you have TV range in video output? Sorry I have ATI card and it's drivers are really mess in this area (extending HD to PC and don't SD, but can be triggered via regfix for SD also).
What you can do also for correcting TV->PC range is to set fixed brightness/contrast adjustment in drivers video settings. It will work only for VMR9/EVR but in any player using one of these renderers. AFAIR you should set brightness to -16 and contrast to 116 or something similar and you will get PC range. You should adjust it to your liking and/or calibrate display.
At least this trick works for undoing PC range in ATI cards so it should work with doing PC range in nvidia.
Regards
wozio
Lantis
3rd June 2008, 17:17
@wozio: No, I meant the colorimetry matrix autoselect of HR (ITU-R BT.601/709). And thanks for the tip.
@kutjong: I had a around 280 frame drops when resizing (upsizing to fullscreen) high motion h264 720p60 (around 3 minutes duration) content while without resizing it only dropped 46 frames. So I guess you could right, probably the video card that can't keep up.
Also, you don't get jitter problems when using HR to bob deinterlace? Could I ask for your used filters and settings?
wozio
3rd June 2008, 18:03
VMR9 automatically switch between 601/709 since I remember, at least for ATI cards (or to be precise, drivers switch). For me color conversion in ATI drivers is exactly the same from quality point of view than in ffdshow RGB HQ conversion.
One problem with ATI drivers is that them switch between matrixes basing on vertical size (less than 720 lines - use 601, otherwise use 709) which leads to problem when playing material which is 720p with AR 2.35:1 so their real size is something about 540 lines. Then 601 matrix is used incorrectly. In HR it is better solved basing on horizontal size.
kutjong
3rd June 2008, 21:59
Also, you don't get jitter problems when using HR to bob deinterlace? Could I ask for your used filters and settings?
If you want to have low jitter, you should use reclock and set your display refresh rate to a multiple of the video's framerate. In my case I'm watching a PAL dvd (25fps) so I've set my refresh rate to 100 Hz. :)
FYI, to get accurate refresh rates you should use powerstrip. Windows discrete timing refresh rates are not usually accurate and this'll result in reclock having a hard time syncing.
Shinigami-Sama
3rd June 2008, 23:29
maybe I'm an idiot but where are these renderer settings?
kutjong
4th June 2008, 00:13
maybe I'm an idiot but where are these renderer settings?
If you use MPC: Right-click on video surface->filters->haali video renderer.
Shinigami-Sama
4th June 2008, 00:51
If you use MPC: Right-click on video surface->filters->haali video renderer.
that'd explain why I never noticed it
I almost never use the context menu
thanks
Lantis
4th June 2008, 23:48
@wozio I couldn't find anything like that for nVidia. And changing the overlay brightness/contrast settings doesn't seem to affect VMR9. Don't worry, I have HR's problem solved.
@kutjong Wow, you're right. I set the refresh rate to 75Hz and HR's constant increasing jitter problem is solved! Thank you!
leeperry
5th June 2008, 01:13
well it still increases for me in 48 Hz with Reclock in 24 fps
I usually start at 0.25 and 90 mins later I'm at 9 ms
cyberbeing
5th June 2008, 02:18
On my system I don't have an issue with increasing jitter but more of an issue with getting it to lock in at a low jitter. With Reclock and a multiple of the video framerate refresh, whatever the jitter is at the beginning, it will say within 0.5ms throughout the whole video.
Sometimes I have to seek like 10-15 times to get a low jitter of 0-2ms and other times I can't seem to get it below 3-4ms. It makes me wonder if Haali could add some sort of automatic jitter correction to sync it as close as possible to the expected refresh for the lowest jitter. The seeking jitter workaround seems to tell me that whenever the first frame is displayed, the subsequent frames will always be displayed at an even distance apart maintaining the jitter of the first frame displayed. For all I know Haali renderer already has something like that but ReClock breaks it...
I've also had an issue where when viewing in Windowed mode with a 0.5ms jitter and then switch to fullscreen the jitter will increse to something like 3ms even if the video resolution is my screen resolution (no resizing). When I go back to Windowed mode the jitter drops back down to 0.5ms.
Reclock seems very picky with Haali Renderer+MKVs and sometimes won't detect the video stream which when that is the case Reclock seems to be designed to disable framerate changes and resampling rendering it useless. Oddly enough I have found that renaming the directory the file is in will sometimes fix it (but not always).
wozio
5th June 2008, 06:55
@wozio I couldn't find anything like that for nVidia.
What you could not find? Automatic color conversion matrix switch? It is automatic so it is supposed to be hidden and you will not find it ;) Try to do some tests: run some SD material via ffdshow without any resizing, make screenshot in fullscreen, then set ffdshow to resize to HD resolution, 1920x1080 for example, go to the same frame, make screenshot and compare with previous one, they should be little defferent in colors.
And changing the overlay brightness/contrast settings doesn't seem to affect VMR9.
You mean this settings? They should affect VMR9.
http://images.anandtech.com/reviews/video/nvidia/drivers/forceware91xx/videocolor-standard.png
Don't worry, I have HR's problem solved.
I'm not worry I just don't know why you use HR, when there is no benefit from it at all comparing to properly configured VMR9.
Regards
Piotr
leeperry
5th June 2008, 09:10
Sometimes I have to seek like 10-15 times to get a low jitter of 0-2ms and other times I can't seem to get it below 3-4ms. It makes me wonder if Haali could add some sort of automatic jitter correction to sync it as close as possible to the expected refresh for the lowest jitter. The seeking jitter workaround seems to tell me that whenever the first frame is displayed, the subsequent frames will always be displayed at an even distance apart maintaining the jitter of the first frame displayed. For all I know Haali renderer already has something like that but ReClock breaks it...
you need to catch the VSYNC, as simple as that....prolly due to Reclock that doesn't offer VSYNC correction with HR.
I had the same problem with MPC HC in EVR.
I also seek a number of times to catch it the best I can.
sometimes I even get 0.01ms jitter
I'm not worry I just don't know why you use HR, when there is no benefit from it at all comparing to properly configured VMR9.
When you start using HR with Reclock with a multiple refresh rate, I can assure you that nothing's as smooth as HR.
but yeah if you watch all your videos in 60Hz, there's no point in using HR and/or Reclock :p
cc979
5th June 2008, 09:57
50hz sync, i have seen before with some drivers you can add custom refresh rates = 50hz Pal, 60hz NTSC
pirlouy
5th June 2008, 12:09
I'm not worry I just don't know why you use HR, when there is no benefit from it at all comparing to properly configured VMR9.
Can you explain what are the right settings for WMR9 (with MPC HC for example) ?
I use Haali Video Renderer because (ok, I'm a noob on this) he allows me to have a real "black" and not a grey (Luma Range: TV: 16->235) and because he can resize source to the right resolution.
kutjong
5th June 2008, 13:11
I'm not worry I just don't know why you use HR, when there is no benefit from it at all comparing to properly configured VMR9.
Regards
Piotr
I think VMR9 will only use BT.709 colorimetry if the video's vertical resolution is at least 720 pixels. This is not good since there are many videos that simply have the black bars cropped from the video resulting in vertical resolution that is under 720 pixels. VMR9 will then incorrectly use BT.601 colorimetry.
Haali's automatic colorimetry goes by horizontal resolution and this is always 1280 or 1920 in HD. If you have problems, you can manually specify. :)
wozio
5th June 2008, 13:21
@leeperry
I often watch 50Hz TV broadcasts on 50 Hz LCD TV does it qualify? For me smoothest motion is when using VMR9 fullscreen exlusive in any player supporting it. On my system HR in such scenario is jerky.
@pirlouy
Resizing:
Each renderer can resize picture to right resolution. One do it better than the others. On my setup (ATI x1650 pro) HR scaling is very bad quality, MPC VMR9 renderless with bicubic is much better. Or even normal bilinear, I don't like very sharp/oversharpened picture.
Luma range:
On my setup VMR9 properly extends luma range from tv to pc with registry tweak to force this on SD. I don't see any quality difference between this and ffdshow's HQ YUV->RGB conversion but is VMR9 much faster since it does it on hardware. I don't know what about nvidia though. Using driver control panel adjustment you can undo this range extension to get tv range and calibrate display to preserve blacker-than-black and whiter -than-white information.
In MPC HC in output set VMR9 renderless, yuv mixing mode, direct3d texture with bicubic rendering, A parameter set to taste.
Only one big issue with VMR9 is that all video processing is done in graphic card drivers so you rely on drivers developers. On ATI it leads to many problems with properly configuring drivers. HR is only better in this area, it is mostly independent on drivers so it is very easy to just work. But you loose DXVA, deinterlacing, fullscreen exclusive support, driver enhancements.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.