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. |
14th May 2009, 19:58 | #1021 | Link |
Registered User
Join Date: Jun 2005
Posts: 630
|
Regarding these 601/709 colormatrices, I have already suggested an option to override the matrix chosen over automatic detection. The reason is that the resolution-based condition is not always correct (I think one such sample from Apple has been posted here already, and there are some other cases as well, let's say there are plenty of encoders in the world and not all of them adjust colourmatrix as required :P)
Last edited by Egh; 15th May 2009 at 03:52. |
15th May 2009, 02:01 | #1022 | Link |
Registered User
Join Date: May 2009
Posts: 212
|
The stream demuxer or the video decoder often knows the video output's color space. (Of course, only if appropriately encoded)
To make it more accurate to handle the decoded video frame's "color space", there are two methods: 1. If there is such MetaData embedded in the decoded video frame, the video post-processor / renderer can handle this by itself. 2. If it is not embedded in the decoded video frame, this relies on the player program to grab video stream's color space info from stream demuxer or video decoder, and instruct the video post-processor/renderer to do the right conversion. Of course the video processor needs to provide an API for the player to adjust the setting dynamically. |
15th May 2009, 11:30 | #1023 | Link |
Registered User
Join Date: Jun 2008
Posts: 8
|
I invested a lot of time to undderstand pros and contras of all the colorapaces (in the PC area not in the TV area).
I do not understand why YV12 (as a 4:2:0 color subsampling) is better in quality than YUY2 (or UYVY) that has twice as much color information from the original source than YV12 (or NV12). Is generally more information from the source not better than less? MPEG-4 and H.264 (not the studio and high quality profiles) use 4:2:0 internally so the information in the source (file, RTP stream) is already lost. But there are also formats like MJPEG that use higher quality color subsampling internally (4:2:2) and some formats also use 4:4:4 color subsampling. My attemt was alwas to avoid any color conversion if possible. That is the reason why YUY2 would have been nice. You are right that FFDSHOW raw filter can be used for conversion (that is in most cases lossy). But in a multiinstance application the use of an additional filter is bad for the performance. |
15th May 2009, 11:47 | #1024 | Link |
And so it begins...
Join Date: Nov 2005
Location: Hannover, Germany
Posts: 64
|
There is no more information. The source (DVD/Blu-ray) is subsampled in 4:2:0. When outputting YUY2 the decoder itself does the upsampling to 4:2:2 which is usually much worse than the upsampling madVR does. YV12 ensures that the decoder outputs the data as decoded. This is the reason why YV12 is better in this case.
|
15th May 2009, 11:50 | #1025 | Link | |||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
Edit: Seems I was too slow in replying... |
|||
15th May 2009, 13:00 | #1026 | Link |
Registered User
Join Date: Sep 2006
Posts: 2,197
|
got my new HD 4770 (only have a PCIe 1.0 slot though), this is for the US sin city BD:
display 1 estimate: 62.XXXXXHz display 2 estimate: 60.0XXXXHz display 3 estimate: 60.0XXXXHz display 60.03804Hz movie 23.976 fps frame queue 16/16 movie res 1920, 1080 target rectangle 0, 152, 1280, 872 movie frame interval 41.71ms avrg gpu rendering time 6-14ms (depending on scene) max gpu rendering time 8-20 I'd say arg present wait 'till 14ms seems like the HD 4770 is not yet listed under the cards to choose new drivers for at ati/amd.com? btw. is installing that avivo video thing good for anything? |
15th May 2009, 14:34 | #1027 | Link | |
3 eyed CRT supporter
Join Date: Jan 2008
Location: Or-strayl-ya
Posts: 563
|
Quote:
As someone who uses an Interlaced resolution, very successfully (1080i 95.904hz, which is 47.952hz in Powerstrip with the interlaced box ticked)... I'm obviously freaking out at that statement. Does it really make that much difference to the renderer? How does it know if the 96hz it is detecting is 96 progressive or 48 interlaced? I assure you, interlaced resolutions work very, very well. Currently I have very smooth playback with Haali + Reclock, or MPC EVR custom. All I'm asking is that interlaced resolutions are not precluded from smooth playback. I, at least, can live without fancy refresh rate changes. |
|
15th May 2009, 16:04 | #1029 | Link |
Registered User
Join Date: May 2009
Posts: 212
|
Although madshi does not plan to support "deinterlace" capability, I still would like to explain some rules to deal with the interlaced contents here.
For interlaced contents to be "vertically" scaled, it needs to be deinterlaced first no matter the output device is progressive-scan (most LCD, regular PDP) or interlaced-scan one (regular CRT, Hitachi ALIS PDP, special LCD monitor for broadcasting 1080i content inspection). For interlaced-scan output device, it can be chosen to do the separate vertical field-scaling on interlaced contents to avoid the deinterlacing process. But the good motion-adaptive deinterlacing + frame scaling mode still produce better video quality, especially in the static scenes. For progressive-scan output device, there is no choice. "deinterlacing" process must be done for interlaced contents before the horizontal + "required" vertical scaling processes. |
15th May 2009, 18:51 | #1030 | Link | |
Registered User
Join Date: Dec 2006
Posts: 523
|
Quote:
I'm lucky, in that I purchased the first 1080p DLP produced. My set works equally well with 1080i/1080p output from my HD-DVD players. |
|
16th May 2009, 00:06 | #1031 | Link | ||
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
@madshi
Quote:
|
||
16th May 2009, 00:46 | #1032 | Link | |
3 eyed CRT supporter
Join Date: Jan 2008
Location: Or-strayl-ya
Posts: 563
|
Quote:
Did you get my uploaded vysnc.dat file? I think I'm the only one who did it - and it was pages and pages ago now. |
|
16th May 2009, 22:21 | #1034 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Those vsync.dat files I got indicated that sometimes your graphics cards report flat out incorrect scanline information. That confused madVR's display refresh rate calculation formulas. That should be worked around in the next madVR build.
|
16th May 2009, 22:49 | #1035 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
madVR 0.10 released
http://madshi.net/madVR.zip Code:
* added first (buggy) version of smooth motion rendering * added uploading queue (up to 8 frames) * added rendering queue (up to 8 frames) * added information about dropped and delayed frames to OSD * removed GPU rendering times from OSD * added (buggy) frame stepping support * modified DVD / macrovision handling slightly * display refresh rate detection should no longer produce incorrect results * added separate controls for luma upscaling and downscaling * fixed: image was sometimes offset in 1:1 mode in ZoomPlayer Unfortunately I've found that it's next to impossible to get things *perfectly* smooth in windowed mode (at least on my PC). So perfection will have to wait until madVR is able to do fullscreen exclusive mode. However, my current development PC is not the fastest/best, so maybe you can get good enough results with madVR even in windowed mode, if your PC works better than mine. At least madVR 0.10 should be a lot smoother than older versions (I hope). Technically the problem is that whenever you tell the GPU to display a rendered frame during the next vsync blank, the GPU stalls and stops doing anything else until the next vsync blank finally occurs. That means that if madVR asks the GPU very early to display a rendered frame during the next vblank, there's not enough GPU time left to do the actual rendering, cause the GPU is stalled most of the time waiting for the next vblank. On the other hand, if madVR tries to display the rendered frame as late as possible (in order to gain more GPU processing time), the danger of missing the target vblank period grows. A missed target vblank means judder or tearing or both. Argh, isn't that fun? AFAIK, these problems should go away in fullscreen exclusive mode, fortunately. madVR 0.10 now uploads the video data to the GPU in a separate thread. Also rendering and displaying the images is also done in separate threads. That all means that retrieving correct and meaningful GPU rendering times is more difficult. So I've simply removed GPU rendering time information from the OSD now. However, I've added information about uploading and rendering queues. Generally, if the upload and rendering queues stay over at least 4/8, your GPU seems to be fast enough to handle the madVR settings you've activated. Also I've added information about dropped and delayed frames to the OSD. During startup of movie playback it's acceptable to get a few dropped or delayed frames. But 3-5 seconds after the movie starts the number of dropped/delayed frames should not increase, anymore. Every time you see motion judder on screen, probably either the dropped or delayed frame count increases. If the number of dropped/delayed frames does not increase for you after 3-5 seconds of runtime, you should get perfect playback quality. Well, I mean: As perfect as the ratio of display refresh rate and movie frame rate permits, of course. Display refresh rate calculation should work correctly now. If it doesn't, you will probably not get smooth motion playback. So make sure you double check (especially those of you for which display refresh rate calculation failed to work with older madVR versions). I've also slightly worked on DVD playback ("macrovision failure"). For me it works. However, I've noticed that the DScaler decoder doesn't always work with madVR when playing back DVDs while the Cyberlink MPEG2 decoder always works. Frame stepping is now implemented, but buggy. Generally madVR has gone a bit buggy/unstable due to the many deep changes. As long as you don't pause/stop/resize etc, things should be stable. If you do anything madVR has to react to you might get funny results, or maybe it will work just fine. If you run into problem that is reliably reproducable please let me know. |
16th May 2009, 23:21 | #1036 | Link |
Registered User
Join Date: May 2009
Posts: 23
|
how do you open the detailed osd in 0.10? ctrl+j twice doesnt seem to do it any more.
also going a bit off topic but how should the dynamic range be set on nvidia hardware full(0-255) or limited (16-235)? either seems to result in a differant image with madvr and HR compared to evr custom Last edited by wayland; 16th May 2009 at 23:26. |
17th May 2009, 00:15 | #1037 | Link |
Guest
Posts: n/a
|
madshi, awesome work, thanks! Tested it again on the Iron Man BD w/ the 4770, refresh rate was correctly detected at 60.00071 Hz (and stayed there for the whole 250s I tested), decoder queue 16/16 fixed, upload queue 4/8 fixed, render queue 8/8 fixed, 10 dropped frames, 2 delayed, all during first few seconds. Playback "feels" almost perfectly smooth, the very tiny stuttering could also be the effect of 23.976@60Hz playback. Feels definitely as smooth as the best iteration of Beliyaal's EVR CP.
One tiny request: Could you make the OSD position toggle between the top and bottom? Might come in handy for us plasma users. |
17th May 2009, 00:28 | #1038 | Link |
3 eyed CRT supporter
Join Date: Jan 2008
Location: Or-strayl-ya
Posts: 563
|
Madshi, this new version, well...
YEA HAR!! display 95.90368Hz (397s) perfect, time just keeps growing movie fps 23.976fps (says source filter) decoder queue 16/16 upload queue 4/8 render queue 8/8 movie res 1920,1080 target rectangle 0,0,1920,1080 v sync interval 10.43ms movie frame interval 41.71ms dropped frames 3 Just from startup, stable after that delayed frames 3 Just from startup, stable after that Playback is smooth, so far. I need to watch a whole movie to be certain. I am using Reclock, but disabled (original speed locked, slaved). The HD2600XT seems capable for watching 1080p material at 1080i 96hz. Was it the interlaced res that causes the scanline reporting issue? Because an interlaced res has a half scanline at the bottom, or somesuch, to form the offset between fields (it has an early V-sync once per frame). A small feature request: A tearing/smoothness test. Using Zoomplayer, with Reclock "bypassed", I have no tearing bar test, which is very handy for checking issues. And that raises the Reclock issue...are you using Reclock? If so, what settings? Active or bypassed? If not, will Reclock bypassed, just a WASAPI renderer, cause any issues? It doesn't seem to. I'm slightly concerned about the need for Fullscreen Exclusive for "perfect" playback. I understand why (I think), but it's a bit clunky - and there goes the UI on Zoomplayer. Oh well, smooth playback and gamma are my number one priorities. Once this renderer has subtitles, it will replace Haali Renderer on my system for all material. The GPU rendering stats in the OSD are missed. Thank you very much Madshi, honai is right, it "feels" smooth. With Haali Renderer it always "feels" like it is about to throw a little stutter party. Beliyaal EVR custom has this smooth feel too, but I get a glitch after an hour. I will test a full movie tonight. Last edited by Mark_A_W; 17th May 2009 at 01:07. |
17th May 2009, 00:38 | #1039 | Link |
Registered User
Join Date: Sep 2006
Posts: 2,197
|
just to nitpick, does it have to be 0.10 or 1.0? 10 comes after 9, yes, but just from the looks after 0.9 I'd expect to get 1.0. I'd rather say that 0.10 follows after 0.09 :P
for the same movie as a bit above, with 0.10 & HD 4770: display estimate: 60.037XXHz movie 23.976 fps decoder queue 16/16 upload queue 4-5/16 renderer queue 8/8 movie res 1920, 1080 target rectangle 0, 152, 1280, 872 vsync intervall 16.66ms movie frame interval: 41.71ms dropped frames: usually none, ~3 when skipping through delay frames: usually none, 1-2 when skipping through whats a bit anyong is that flicker when you hover over the playback bar with the mouse in fullscreen mode, then there is a flickering each time. but I guess thats still part of the buggy phase. Last edited by Thunderbolt8; 17th May 2009 at 00:40. |
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
|
|