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. |
12th December 2012, 17:52 | #16221 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
madVR v0.85.3 released
http://madshi.net/madVR.zip Code:
* fixed: when using DXVA2 scaling, colors were too bright by "257/256" * fixed: freeze when disabling DXVA2 processing in the middle of playback * fixed: green screen when disabling DXVA2 proc. in the middle of playback * fixed: a non-default source rect made DXVA processing fail * hopefully fixed: freezes with some DXVA decoders (MS, MPC-HC) * hopefully fixed: incorrect colors when using DXVA2 decoding/processing * added auto correction if FPS upstream info is wrong by 2x or 0.5x factor * added code to silently suppress crashes in internal MPC-HC sub renderer * added code to silently suppress decoder crashes during graph destruction * added support for IVideoWindow::put_BorderColor() * added double/triple expanded TV range to "source levels" toggle |
12th December 2012, 18:24 | #16224 | Link |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
For that Toradora DVD screenshot, it definitively appears to be ITU, but that Aspect Ratio Calculator is incorrect here.
That DVD seems to have used ITU based on a 720x486 frame (not 711.85x486), and was encoded with vertical cropping. So basically what you end up with is a 1920x1069 DVD frame when upscaled, where the bottom was cropped off during encoding compared to the BD (which itself was a cleaned-up upscale from the same SD master as the DVD). Last edited by cyberbeing; 12th December 2012 at 18:27. |
12th December 2012, 19:31 | #16227 | Link |
Registered User
Join Date: Jul 2011
Posts: 83
|
With v0.85.3 DXVA native (LAV) works with my ATI 2600, before it almost never worked.
For some reason in Zoomplayer with some files that work in MPC-HC it falls back to software decode... Last edited by Prinz; 12th December 2012 at 19:42. |
12th December 2012, 19:33 | #16228 | Link | |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Quote:
but could you please change the order of the hotkey OSD and make it PC > TV > 2X > 3X? It would be a lot more convenient when deciding what is best for the current movie. and I don't mean to bother you, but would you know what levels I would need to input in that levels conversion PS script I mentioned earlier in order to do 1X and 2X please? Because I really only have one available button for hotkeys on my mouse and I currently have it set for matrix rolling, so it's fantastic that mVR supports it but until filenames can be tagged I'd prefer to enable a PS script than being forced to use a keyboard hotkey....or give up on my matrix rolling mouse button Last edited by leeperry; 12th December 2012 at 21:35. |
|
12th December 2012, 21:26 | #16230 | Link | |
Registered User
Join Date: Nov 2005
Posts: 85
|
Quote:
|
|
12th December 2012, 23:07 | #16231 | Link |
Registered User
Join Date: Mar 2002
Location: Sofia, Bulgaria
Posts: 661
|
Guys,
I just saw that there is a new stat in madVR's OSD labeled "split". Does anybody know what does it represent? I guess it's somehow connected with the deinterlacing because it's only visible when I watch interlaced content.
__________________
Z370M Pro4 | i3-8100 | 16GB RAM | 256GB SSD + 40TB NAS NVIDIA GTX 1060 6GB (385.28) | LG OLED65B7V Win 10 64bit 1803 + Zoom Player v14 |
13th December 2012, 00:03 | #16232 | Link | |||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
Quote:
Quote:
This is for splitting the DXVA NV12 output into separate Y and CbCr textures for the madVR rendering pipeline. Splitting is done via "copyback", but only on NVidia and Intel GPUs, and only if you have an SSE 4.1 capable CPU. This "split" item in the debug OSD will only be visible if you use DXVA decoding or DXVA deinterlacing, but *not* DXVA scaling, with the above mentioned GPU and CPU configuration. |
|||||
13th December 2012, 00:11 | #16233 | Link |
Registered User
Join Date: Mar 2007
Posts: 934
|
Madshi, it looks like 0.85.3 fixes the issue with my interlaced MKVs (muxed from TV recordings using MKVMerge) not being deinterlaced correctly, thanks!
Obviously it doesn't fix the issue in EVR though so I'm hoping Nev can come up with a fix for that.
__________________
TV Setup: LG OLED55B7V; Onkyo TX-NR515; ODroid N2+; CoreElec 9.2.7 Last edited by DragonQ; 13th December 2012 at 00:14. |
13th December 2012, 00:26 | #16234 | Link | ||||
Registered User
Join Date: Dec 2011
Posts: 54
|
You guys might want to check out my earlier post again regarding NTSC DVDs, maybe I didn't explain what I wanna say well enough earlier (just went back to edit it a little).
anyway, here some points... Quote:
I would say those samples just confirm my finding even more. As I mentioned, in production they use the same width for both full 720-pix-DVD and BD, almost all the time (except for really old DVDs 199X-early 2000s). This is true regardless of some black areas/unclean edges present on the sides. For example, If you look at those Planetes, Kannagi comparisons you'll see that these DVDs have just the same width as Blu-rays. Those 'Non-ITU black areas' are just like they paste black colour upon original picture*. Not squishing the picture within active area, or cropping vertically to the point that match ITU AR → then leave side black borders, methods you would see in good ol' ITU first gen DVDs. Planetes is especially a good example because it's quite old (2003). In terms of aspect ratio (which is usually the real concern for ITU guys as I've seen), errors often purely comes from vertical cropping. If there isn't any cropping NTSC would be BD-like with non-ITU scaling, just like PAL. Now consider these: 1. PAL DVDs (576 vertical resolution) production has no vertical cropping or very little cropping (usually in very old ones). See samples mr.6233638 has posted, for quick example. 2. NTSC has quite low vertical resolution of only 480, combine with not so good DVD compression and poor transfer technique of the old times. 3. Based on NTSC samples I've found, newer DVDs (superbit version for example) tend to have less vertical cropping than old DVDs. Also even old DVDs need only tiny cropping in case tons of picture got cropped off on all 4 sides already (mean they chose smaller area than original for DVD presentation). Very old 1999 R1 US & R4 Brazil DVDs of Shawshank Redemption film even have none vertical cropping. 4. NTSC version of the same titles got cropped off vertically (to different degrees) while PAL remains the same as BD since ages. Hence my speculation is that they apply vertical cropping in case of NTSC to improve image resolution/quality, 480 pix is too low to contain full original height for them. They also get the benefit of Aspect Ratio compensating for both ITU and non-ITU. Another logical thought is that NTSC production is based on 720x486 frame. But I think this is unlikely after seeing various samples, e.g. this practice appears in PAL too for very old DVD transfers, NTSC cropping vary too much for this. Moreover, It made no sense that studios wouldn't just adjust their scaling to 720x480. One thing for sure is that this is not production error/badly produced DVDs something like that. They clearly do it on purpose. •In terms of picture information (those black areas) consider these: 1. Movie content (including anime movie), e.g. Hollywood ones usually have clean side edges, at least much better than older anime series especially in USA (R1) from what I've seen. 2. *(continue from above) When transfer to DVD those 'Non-ITU black/dark areas' or crappy edges can normally appear from various reasons, e.g. scanning master source, some hardware filters, oldschool hardware devices in studios that adhere to ITU. So you can often see crappy edges on top/bottom too. They have to revision and fix it in the processes untill the pic is as clean as possible though, still there usually are dirty edges left on any of the 4 sides. 3. Anime series are longer and require much more work than just 2 Hrs long movie. Moreover, Anime audience outside Japan is not quite dominant as movie audience. So I wouldn't be surprise if they treat anime series content differently from movie content. Actually for both anime and movie they scaling picture to full DVD width the same as BD already and they could just treat them the same way, but I guess for anime series they didn't care of the side edges as much as they do for movie, and just left it like that while maybe thinking "nah, there is still ITU to save our asses, those few consumers won't notice with hardware overscan&scaling anyway" I believe Keiyakusha's opinion about animes is quite right as what he found are consistent with my finding too; doesn't contradict with what mandarinka has provided here also. He also lives in R2 Japan, the homeland of anime. @mandarinka, aside from 4:3 content, those samples you provided are mostly R1. And I bet my money that the R2 of Ghibli's "Only Yesterday" is just normal 'non-ITU NTSC DVD standard' I've described with area compensating for Overscan of all 4 sides. It is well known that some Ghibli movie DVDs have this overscan issue which DVD reviewers really dislike. As you can see, it seems Ghibli really fear the loss of their precious picture information and ITU would do no good for their full width DVDs. ------------ •In conclusion, this is the obvious practice that I've found of DVD. The trend is that from year ~2005-2006 on they are mostly like this, and pretty much like this nowadays. - Most PAL DVDs are real non-ITU (BD-like with non-ITU scaling). - Most NTSC DVDs have vertical cropping so aspect ratio is not right for both methods. But picture width is non-ITU. Also side edges of picture have been cleaner as time has gone by. Even if AR favors ITU more, it's still very tiny, hence you'll much more likely have to decide on whether cropping the sides off is beneficial (valid image would be lost). But of course there are always some discrepancies out there and little more specific details for some content type, e.g. I found few real ITU PAL anime DVDs with ITU black borders in the age where movie are mostly real non-ITU, somewhat different practice for (old?) 4:3 content. Quote:
Quote:
Scaling using ITU PAR without cropping will be a mess. No benefit and 16:9 would not be 16:9 then you get smaller overall picture with black bars at top&bottom displaying it on FullHD screen, that's definitely bad. Quote:
All that aside, Side black areas are not that good of an indication anyway from my experience, there are even few PAL DVDs that image are truly based on 720 but have ITU blanking areas for example. Hence non-ITU if you ask me. But if it is actually a true ITU image, then the BD is really badly+lazy produced in this case (They left the picture ITU squish with black borders on all sides). @madshi, thanks for the new version, madVR rocks. Last edited by pururin; 13th December 2012 at 21:07. |
||||
13th December 2012, 00:33 | #16235 | Link |
Registered User
Join Date: Dec 2012
Posts: 6
|
Does madVR officially support screenshots/image capture as of latest? I know the MPC guys hacked together compatibility.
Because I'm using Potplayer and the output for every image I try to capture is roughly 5-7 frames ahead of what should be captured. Just wondering and hoping if this is something that can be looked at or if it's something that's still unsupported. Thanks Last edited by SyrupBuccaneer; 13th December 2012 at 03:16. |
13th December 2012, 00:59 | #16236 | Link |
Registered User
Join Date: Jul 2008
Posts: 60
|
I've read through a lot here, but I just wanted to make sure I have my settings right. Under CCC I have pixel format to RGB Full, and on my panasonic plasma, HDMI is set to non-standard which it says is 0-255. Under Madvr, I have it set to PC Levels. With test patterns, blacks and whites are clipped below 16 and above 235. Is that how everything should be set up?
|
13th December 2012, 01:01 | #16237 | Link | |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Quote:
Code:
sampler s0 : register(s0); #define const_1 (16.0/255.0) #define const_2 (255.0/219.0) float4 main(float2 tex : TEXCOORD0) : COLOR { // original pixel float4 c0 = tex2D(s0,tex); return((c0 - const_1) * const_2); } PS: ah well, Seb.26 actually says on HCFR that this levels conversion script is "low quality" "incorrect" and "buggy", hurray! Gonna seek a way to use your conversions instead(that look very impressive BTW ) And do you think it would be preferable to use the gamut mapping PS script before or after scaling? And what's your take on scripts that would be better used in either of those two positions(apart from deinterlacing, that should obviously be used before)? I guess this kind of info would do good in the OP and in the future manual. Anyway I now slightly strech my ITU compliant VHS rips horizontally in order to become true FS and that feels good PPS: having more thoughts about it, a PS script that would really be useful would be a 4:3 placeholder/helper so you could easily stretch your 4:3 video horizontally in order to reach perfect 4:3 width, because when running a 16/9 resolution it seems pretty much impossible to find out the ideal 4:3 width Would that be possible to simply draw a 4:3 rectangle using a MPC PS script? You could also assign it to a hotkey and the endless ITU whining would be over: just stretch the damn thing ya'self = fixed Last edited by leeperry; 13th December 2012 at 06:06. |
|
13th December 2012, 04:03 | #16238 | Link |
Audiophile
Join Date: Oct 2006
Posts: 353
|
When you first released madVR with DXVA2 support(decoding and scaling), you mentioned a chroma blur that happens with native and not with copyback. I have no idea if that's still the case. Many changes have been made to the code since then, including the SSE4.1 copyback speedup(which I can't take advantage of) as well as various fixes. I don't know the tradeoffs that are made today when using DXVA2 scaling/decoding. Well, other than DXVA2 scaling is useless on nvidia hardware.
|
13th December 2012, 09:48 | #16240 | Link | |
Registered User
Join Date: Dec 2011
Posts: 54
|
Quote:
The point is that for NTSC a bit complicated ones, those aspect ratio discrepancies are too low (less than ~0.9% of the real AR) to be worry about already. Most, if not all, human can't tell small difference (even 2% or more) anyway without side-by-side comparisons. And If you live in Europe or watch many PAL DVDs you don't have much to worry already. Others than those should be quite straightforward to see and choose one way over the other. Having users manually adjust frame scaling/cropping would be too troublesome, it's more like an encoder work. Just having few options that suitable for real-world situation would be much more practical IMHO. Only which scaling algorithms and color level should be used topics are confusing enough for many people (but not techie like you ). Also how many average people know about this ITU specific stuffs? I guess more than 95% didn't know. Just have few presets for them would be confusing enough. Last edited by pururin; 13th December 2012 at 10:18. |
|
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
Thread Tools | Search this Thread |
Display Modes | |
|
|