madVR - high quality video renderer (GPU assisted)

[DragonQ]

Probably. AFAIK, MadVR is only 32-bit.

[SamuriHL]

If you're using a 64 bit player, you're not using madVR.

[leeperry]

Mirroring is extremely easy:

sampler s0 : register(s0);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
return tex2D(s0, float2(1 - tex.x, tex.y));
}
Would flipping be just as easy for you please? JanWillem made a flipping script but it also does psychedelic chroma effects :o

and would you know what values I would need to input in order to add 1 and 2 TV>PC conversions in this script(on top of mVR's default one) please:
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);
}

:thanks:

[kasper93]

@leeperry
You have everything just think :P
flipping:
sampler s0 : register(s0);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
return tex2D(s0, float2(tex.x, 1 - tex.y));
}

[Sneals2000]

If i read correctly BT.470, BT.1700 and BT.801 then active video is between those two "pulses" i.e. this correspond to 52.3us i.e. 706 pixels .


Looking at BT 1700 then that clearly states that the line blanking period is 12us and the total line period is 64us. That gives a non-blanked (i.e. active) line period of 52us. Not 52.3? Where are you getting longer active lines than 52us from in a video standard doc? (There is potentially some +/- tolerance I guess?)


Thus 702 is same correct as 720 pixels, 704 or 708,710 etc

for 700 pixels in line, +-2% geometric distortions are equal to +-14 pixels - knowing fact that not many of us watching video with some ruler on screen i doubt that there is sense to have huge dispute about aspect distortions for normal view when most of TV (in past and nowadays) anyway doing strange processing and typical average Joe don't care even for geometric distortions +-5 - 7%.

If all you're doing is final display - you're right - it's unlikely to be noticed by many.

If you're using this stuff upstream in production - then it's much more significant. If two different bits of kit or software don't do the same thing - but are in different routes in a production chain - you can't switch between them invisibly. This is important in some areas.

[leeperry]

@leeperry
You have everything just think :P
flipping:
sampler s0 : register(s0);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
return tex2D(s0, float2(tex.x, 1 - tex.y));
}
ah, sweet :thanks:

I tried "1 - tex.y, tex.x" but that was a no-go :o

There have also been a few films I've come across from a particular group that, rather than being black and white, are encoded with a blue tint, that saturation controls can easily fix:
Before (http://www.abload.de/img/blueexi88.jpg),After (http://www.abload.de/img/bwz1i9s.jpg)
Or you can just use the grayscale PS script :cool:

[khanmein]

can any of u guys explained to me that y i can only get matrix BT.609 when playing BD-RMVB with my mobility HD5650 whereas GT640M able to get BT.709?? thanks~

[bugmen0t]

When using native DXVA2 (active) in Lavfilters, Potplayer resizes itself to the movie resolution and just sits there not playing the file (the total time and chapters will be loaded but it just sits on the potplayer background skin) then even after I close Potplayer its process remains running in taskmanager.

This only occurs with Madvr 0.85.2, I do not have this problem with Madvr 0.85.1, It happens with all Dxva compatible files, does not occur if I use DXVA2 copy-back mode only happens under native. My card is an HD3850.

[pandy]

Looking at BT 1700 then that clearly states that the line blanking period is 12us and the total line period is 64us. That gives a non-blanked (i.e. active) line period of 52us. Not 52.3? Where are you getting longer active lines than 52us from in a video standard doc? (There is potentially some +/- tolerance I guess?)



Yes - tolerance which is used for sure, also i've provided excerpt from datasheet that cover aspect how video is produced in digital encoder - this shows that HW vendor can produce non-standard signal to provide full 720 pixels on active video and still provide useful video signal - this is possible due fact that all those standards are 50 - 60 yrs old - where analog timing need to have much wider tolerance, nowadays where video is produced in digital way we can assume that 720 pixels is displayed without change and insisting to keep 52us time as active video time is simply wrong - IMHO 75 - 90% consumer electronic use non standard i.e. longer active video time which provide capability to display all 720 pixels.


If all you're doing is final display - you're right - it's unlikely to be noticed by many.

If you're using this stuff upstream in production - then it's much more significant. If two different bits of kit or software don't do the same thing - but are in different routes in a production chain - you can't switch between them invisibly. This is important in some areas.

Perhaps however as a customer i will be more happy if instead geometric distortions 2% , broadcaster or producer will keep correct field order to avoid video stutter ...
It is hard to express words i have on mind when i see in Europe, US content displayed with European field order or some misuse of the Final Cut or similar tool with European video but with US field dominance...


@all voices about HDMI vs real life - i know reality however i've expressed this much earlier - some software guys should be blamed - if they don't understand HW spec then we can observe spec violations...

@madshi - my point is - there is no sense to change anything or if You decide to change aspect ratio processing then freely configurable solution is the only one - there is many unique cases where something between 702 and 720 pixels is possible - horizontal resizer should have subpixel accuracy (i can imagine someone that claim 575 lines visible on screen).

[nx6]

can any of u guys explained to me that y i can only get matrix BT.609 when playing BD-RMVB with my mobility HD5650 whereas GT640M able to get BT.709?? thanks~

I hope you mean .bdmv and there really isn't someone out there encoding bluray to Real Media files.. :scared:

[mandarinka]

Call for test: Anyone who has DVDs and Blu-Rays of the same movie, please upscale the DVD to Blu-Ray resolution and check whether madVR shows the correct AR or whether the image is slightly squeezed.

Hmm, I remembered that I often saw an aspect ratio discrepancy in the screenshot comparisons on this site (http://www.mania.com/aodvb/showpost.php?p=2004787&postcount=12).

The guys there make comparisons of NTSC dvds and blurays. Now for 4:3 material, the bluray tends to have 1440x1080 of image. For the DVD, they don't use ITU scaling (since they probably never heard of it) and naively scale to plain 4:3, ie 1440x1080.

I actually noticed a lot of times that the bluray version is a bit more wide (stretched horizontally), while the upscaled DVD is more tall. I think that the perfect explanation is that the DVD was instead supposed to be upscaled using ITU.

The link has one such comparison (Giant Robo), I'll try to remember more such cases and post them...

Edit: Okay, here Berserk Bluray (http://www.mania.com/aodvb/showpost.php?p=1974614&postcount=27) - again, when not using ITU scaling, the DVD is more 'tall' than bluray, so ITU probably should ahve been used to scale the DVD.
Ninja Scroll (http://www.mania.com/aodvb/showpost.php?p=1988508&postcount=6) (not sure, the zoom makes it nontrivial - I was not sure but it seems the DVD is again taller if you align the frames, so probably this one is ITU too)
Kannagi (http://www.mania.com/aodvb/showpost.php?p=1986217&postcount=25)(this is actually a modern CG show, yet the bluray is again wider, suggesting that the DVD is supposed to be scaled in ITU way)
Planetes (http://www.mania.com/aodvb/showpost.php?p=1807170&postcount=37) - again ITU - bluray is wider than naively scaled DVD. Note that this is a 2003 show supposedly made in HD and dvd would be authored from that source. So clearly the dudes knew to use ITU.
Toradora (http://www.mania.com/aodvb/showpost.php?p=1971133&postcount=49) - series from 2008 IIRC, SD upscale bluray. Again, bluray is wider, so another case for ITU?
Giant Robo (http://www.mania.com/aodvb/showpost.php?p=2004787&postcount=12) as already mentioned, to make it more orderly. Again bluray is wider, so DVD probably should have been scaled using ITU.
Only Yesterday (http://www.mania.com/aodvb/showpost.php?p=2008831&postcount=3) - again, this one is zoomed, so trickier to spot - but if you crop and scale the DVD, it is again taller, suggesting that ITU would have been the right approach.

P.S. People play a lot of dvd rips, and in those it is tricky to try to compensate for itu. You never know if the rip is using naive DAR computation, or if the creator knew what he was doing and actually did it right. Moreover, many dvd encodes were scaled some prior to encoding, and you often have no idea what sort of cropping/scaling actually happened. So imho ITU should only be used for actual DVD footage. IMHO, cropping shouldn't be done - many, especially remastered DVDs have valid image in the supposedly inactive space (while still having ITU-valid SAR) - many dvds have about 713-714 pixels of horizontal resolution, and even more happens too, including full 720x480.

[Keiyakusha]

People play a lot of dvd rips, and in those it is tricky to try to compensate for itu. You never know if the rip is using naive DAR computation, or if the creator knew what he was doing and actually did it right. Moreover, many dvd encodes were scaled some prior to encoding, and you often have no idea what sort of cropping/scaling actually happened. So imho ITU should only be used for actual DVD footage.

I don't know what exactly happens with DVD, but with rips it shouldn't be a problem. They all have whatever display ar in mkv or sar in stream and there is only one pretty straightforward way of displaying them - by applying specified ar.

But anyway if you going to change anything, make madvr check system locale then and apply ITU for US and non itu for JP... otherwise I personally will stop use madvr and will have to recommend everyone to do so too...

[mandarinka]

But anyway if you going to change anything, make madvr check system locale then and apply ITU for US and non itu for JP... otherwise I personally will stop use madvr and will have to recommend everyone to do so too...

Why? As far as I can tell, japan uses ITU too. See my links above, if you don't accept my anecdotal experience (based all on anime BTW, and specifically R2J dvds).

[Keiyakusha]

Why? As far as I can tell, japan uses ITU too. See my links above, if you don't accept my anecdotal experience (based all on anime BTW, and specifically R2J dvds).

Give me some time eh? You expect me to see your links when you added them 7 mins after my post? ^__^
Anyway what I should see there?
Kannagi - if you remove black bar from the top, it will be exactly non-ITU.
Planetes - I can't tell. Not the same frames compared
Toradora - non-ITU
Black borders can make some difference. But they all different in every dvd so shouldn't be taked into account and assumed like "possible allowed error". If you'll crop them and then resize - pictures will match better.

If you'll resize 720x480 to 1920x1080 and it will look right - its non-ITU. Unless I'm wrong here. Very sorry if I confused what is ITU.

[mandarinka]

This is not about black bars at all. Look at the proportions of the image (aspect ratio of the objects onscreen). Since the non-ITU scaled DVD sources look more tall than on bluray, the conclusion is that this non-ITU scaling is wrong, because ITU scaling would result in less tall image (whether it would precisely match those bluray shots, that is a different question).

And Toradora scaled non-ITU way as they did it *doesn't match* bluray, so it can't be non-itu. Not the same frames compared in Planetes is irelevant, because there is not going to be an aspect ratio change in the middle of the footage. More importantly, you have huge ammount to frames to check, there.

If you'll resize 720x480 to 1920x1080 and it will look right - its non-ITU. Unless I'm wrong here. Very sorry if I confused what is ITU.
Yes, that is correct (for widescreen footage). However as you can see, that does not happen in those comparisons. The bluray ends up being more wide than the DVD versions (scaled non-ITU there).

[Keiyakusha]

Yes, that is correct (for widescreen footage). However as you can see, that does not happen in those comparisons. The bluray ends up being more wide than the DVD versions (scaled non-ITU there).
Here (http://dl.dropbox.com/u/110558786/Comparison/toradora_R1DVD_08.jpg) is how Totadora 08 ITU looks like. You say it looks closer to BD?
I haven't measured anything precisely, but simply visually for me its not.

And this IS about blackborders. AR scaling only modifies width. So if image was squished before by adding black bar at top or bottom (have no idea why or how they do it), you can't compensate for that. You always apply fixed ar for DVD. Bit this is exactly where fixed ITU ar is bad IMO.

[mandarinka]

Actually, yes, to me it looks right that way...
Compare with teh non-itu from that site (here (http://acacallis.com/toradora/toradora_R1DVD_08.png)) which is more tall, and the BD (http://acacallis.com/toradora/toradora_BD_08.png).
BTW, here is the DVD pic from there rescaled to the correct 1969x1080 (http://sadpanda.us/images/1287806-ZTSD982.png) (correct according to the calculator (http://ps-auxw.de/cgi-bin/ar-calc.pl?source_type=ntsc&source_ar=widescreen&transform_type_1=scale&transform_x_1=1920&transform_y_1=1080&transform_type_2=none&transform_x_2=&transform_y_2=&transform_type_3=none&transform_x_3=&transform_y_3=&transform_type_4=none&transform_x_4=&transform_y_4=&transform_type_5=none&transform_x_5=&transform_y_5=&transform_type_6=none&transform_x_6=&transform_y_6=&transform_type_7=none&transform_x_7=&transform_y_7=&transform_type_8=none&transform_x_8=&transform_y_8=&keep=true&calculate=Calculate)), dunno how you calculated it, since you were cropping.

And this IS about blackborders. AR scaling only modifies width. So if image was squished before by adding black bar at top or bottom (have no idea why or how they do it), you can't compensate for that. You always apply fixed ar for DVD. Bit this is exactly where fixed ITU ar is bad IMO.

For ITU scaling, black bars don't matter as far as I can tell. The desired aspect ratio 'of the image' can be expressed as a SAR value of the DVD video (4320/4739 for fullscreen NTSC and 5760/4739 for widescreen NTSC), and this SAR value is the same for all pixels in the frame as far as I can tell. Of course, cropping doesn't change the SAR.

[Keiyakusha]

Actually, yes, to me it looks right that way...
Compare with teh non-itu from that site (here (http://acacallis.com/toradora/toradora_R1DVD_08.png)) which is more tall, and the BD (http://acacallis.com/toradora/toradora_BD_08.png).
BTW, here is the DVD pic from there rescaled to the correct 1969x1080 (http://sadpanda.us/images/1287806-ZTSD982.png) (correct according to the calculator (http://ps-auxw.de/cgi-bin/ar-calc.pl?source_type=ntsc&source_ar=widescreen&transform_type_1=scale&transform_x_1=1920&transform_y_1=1080&transform_type_2=none&transform_x_2=&transform_y_2=&transform_type_3=none&transform_x_3=&transform_y_3=&transform_type_4=none&transform_x_4=&transform_y_4=&transform_type_5=none&transform_x_5=&transform_y_5=&transform_type_6=none&transform_x_6=&transform_y_6=&transform_type_7=none&transform_x_7=&transform_y_7=&transform_type_8=none&transform_x_8=&transform_y_8=&keep=true&calculate=Calculate)), dunno how you calculated it, since you were cropping.
I calculated it just right. and cropped after i scaled it to match the frame. When I'll be playing it for real, I don't want to have something like 1969x1080
If you do close comparison and match images as good as possible with something like photoshop (overlayed difference or something), you'll see that yes, BD looks (a bit) wider than non-ITU within the margin of error for DVDs, they are never perfect. but ITU is even wider than BD. So in case when there is 100% non-ITU DVD, it will be totally off. The ones in this comparison not even Japanese dvds.

[madshi]

Haha, didn't i predict that no decoders obeyed the buffer requests? :)
I think EVR does the copy as well, because it doesn't really require any extra buffers. But you can always avoid the copy with LAV.
I've decided to simply always copy, to not complicate my code even more. It's a bit sad losing performance for this, but what can I do...

can any of u guys explained to me that y i can only get matrix BT.609 when playing BD-RMVB with my mobility HD5650 whereas GT640M able to get BT.709?? thanks~
Not sure what you mean. Can you clarify?

When using native DXVA2 (active) in Lavfilters, Potplayer resizes itself to the movie resolution and just sits there not playing the file (the total time and chapters will be loaded but it just sits on the potplayer background skin) then even after I close Potplayer its process remains running in taskmanager.

This only occurs with Madvr 0.85.2, I do not have this problem with Madvr 0.85.1, It happens with all Dxva compatible files, does not occur if I use DXVA2 copy-back mode only happens under native. My card is an HD3850.
Please try again with v0.85.3, when it's out. If it still occurs, please let me know. You may also want to try different decoders, e.g. LAV.

@all voices about HDMI vs real life - i know reality however i've expressed this much earlier - some software guys should be blamed - if they don't understand HW spec then we can observe spec violations...
It's not that easy for computer stuff, though. The problem is that the Windows desktop is always renderes in Full Range. So if you GPU has to output Limited Range, it has to post-process the Windows output. And that costs image quality, especially if it's done without dithering (and I think it usually is done with dithering). That's why having the GPU output limited range over HDMI is actually a bad thing for us HTPC users.

@madshi - my point is - there is no sense to change anything or if You decide to change aspect ratio processing then freely configurable solution is the only one - there is many unique cases where something between 702 and 720 pixels is possible - horizontal resizer should have subpixel accuracy (i can imagine someone that claim 575 lines visible on screen).
But still the question remains: Maybe any resolution between 702 and 720 is *possible*, but which is used most often in real life? If 90% of the ITU scaled content is using 702, then it would be worth it offering an option for that exact aspect ratio. But if ITU scaled content is all over the place, then it doesn't make sense to offer such an option. So what we need is not necessarily a proper interpretation of the specs, but instead we need to check how this is done in real life.

[moshmothma]

When using native DXVA2 (active) in Lavfilters, Potplayer resizes itself to the movie resolution and just sits there not playing the file (the total time and chapters will be loaded but it just sits on the potplayer background skin) then even after I close Potplayer its process remains running in taskmanager.



Unfortunately, I have the same issue. Been trying to troubleshoot it myself but looks like it could be systemic. The player simply freezes when I use madvr 85.2 with lavfilters 54.1 and mpc-be native filters as well. I am using Windows 7 Sp1 - 64bit and Radeon 6450..Drivers 12.10, AMD FX 8150, 8GB Memory, PotPlayer 1.5.34821, Reclock.

thx for the great work.

[madshi]

madVR v0.85.3 released

http://madshi.net/madVR.zip

* 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
This is just an intermediate build. There'll probably be another build in the next 1-2 days with some more changes. This intermediate build is not especially well tested by me, but it might fix problems with some of the DXVA decoders out there, so I'd thought I'd release it now for you to play with. Let me know how it works for you...

[baii]

Do running 10-bit Displays (instead of natural 8 bit) have any benefit when using madvr to playback?

[madshi]

Not at the moment. True 10bit output is planned for a future madVR build, but I don't know how many GPUs will actually support it. Maybe none. Maybe some. Probably not all.

[cyberbeing]

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 (http://imageshack.us/a/img84/9140/toradorar1dvd08itu.png) compared to the BD (http://acacallis.com/toradora/toradora_BD_08.png) (which itself was a cleaned-up upscale from the same SD master as the DVD).

[dansrfe]

madVR is crashing on me with the latest release. Using latest MPC-HC and LAV with DXVA2 native decoder.

Steps to reproduce crash:

1 -> Resize window up/down

2 -> Drag to second screen.

[kasper93]

@madshi: No freeze on seek with v0.85.3. Thanks.

[Prinz]

With v0.85.3 DXVA native (LAV) works with my ATI 2600, before it almost never worked. :cool:

For some reason in Zoomplayer with some files that work in MPC-HC it falls back to software decode...

[leeperry]

* added double/triple expanded TV range to "source levels" toggle
amazing, :thanks:

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 :o

[aufkrawall]

Sometimes madVR crashes for me with this build when entering FSE and changing display mode.
Debug log:
http://www.mediafire.com/?c330yb82plip6ig

[moshmothma]

Unfortunately, I have the same issue. Been trying to troubleshoot it myself but looks like it could be systemic. The player simply freezes when I use madvr 85.2 with lavfilters 54.1 and mpc-be native filters as well. I am using Windows 7 Sp1 - 64bit and Radeon 6450..Drivers 12.10, AMD FX 8150, 8GB Memory, PotPlayer 1.5.34821, Reclock.

thx for the great work.

Problem cured in 85.3. thx

[pankov]

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.

[madshi]

madVR is crashing on me with the latest release. Using latest MPC-HC and LAV with DXVA2 native decoder.

Steps to reproduce crash:

1 -> Resize window up/down

2 -> Drag to second screen.
Do you get a madVR exception box? If so, can you please make the bug report available to me?

For some reason in Zoomplayer with some files that work in MPC-HC it falls back to software decode...
With LAV? A madVR debug log might help.

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.
Sure.

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?
I posted the correct levels (in floating point) and the math how to achieve them in one of my previous posts.

Sometimes madVR crashes for me with this build when entering FSE and changing display mode.
Debug log:
http://www.mediafire.com/?c330yb82plip6ig
Unfortunately a debug log doesn't help if madVR crashes. Did you get a madVR crash box? If so, please make the bug report available to me.

I just saw that there is a new stat in madVR's OSD labeled "split".
Does anybody know what does it represent?
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.

[DragonQ]

Madshi, it looks like 0.85.3 fixes the issue with my interlaced MKVs (muxed from TV recordings using MKVMerge) not being deinterlaced correctly (http://forum.doom9.org/showthread.php?p=1597085#post1597085), thanks! :D

Obviously it doesn't fix the issue in EVR though so I'm hoping Nev can come up with a fix for that. ;)

[pururin]

You guys might want to check out my earlier post (http://forum.doom9.org/showthread.php?p=1605050#post1605050) 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...
Because NTSC DVD production has little black magic about AR. ;)
...
You'll notice that neither 720 nor 704 display is the right "true" aspect ratio.

In terms of picture information, it's quite clear that full 720 pixel DVD use the same width as full frame BD, i.e. Non-ITU DVD is usually BD-like.
...

The DVD above has 0.87% aspect ratio error for non-ITU display, 1.35% error for ITU display.
The difference in AR error between the two is only 0.48% (too low to deem which one is better) but with non-ITU you'll get full (or nearly) picture information as BD, OTOH with ITU you'll always get less picture.


=> As you can see, for NTSC DVD it's not much about width (as they are usually the same as BD) but height, as they have the practice of cropping original picture off vertically, but not for PAL. (reason analysis for this production practice later)

==> Of all 21 NTSC DVDs (9 are animes) I did measure, the average AR error of Non-ITU display = ~1.126%, only 50.67% of 2.222...%.
That is pretty even between 720 vs 704...

As for PAL DVDs, most of them are actual non-ITU (BD-like with non-ITU scaling) since almost 8-10 years ago from what I've found.
...
Also the situation for 4:3 content is somewhat different to WS content as I've said, they have different reason behind doing it...

@mandarinka, big thanks for sharing the site as it is really a useful source for anime DVDs screenshots. As I want to gather as much DVDs as possible to confirm the trend in DVD production world.

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.


when not using ITU scaling, the DVD is more 'tall' than bluray, so ITU probably should ahve been used to scale the DVD.
...
it is again taller, suggesting that ITU would have been the right approach.
...
So imho ITU should only be used for actual DVD footage.
Of course DVD is more 'tall' as I've said before, it's exclusively normal for NTSC. But it's not an indication that ITU is right, and picture width would indicate the opposite of your opinion.

IMHO, cropping shouldn't be done - many, especially remastered DVDs have valid image in the supposedly inactive space (while still having ITU-valid SAR) - many dvds have about 713-714 pixels of horizontal resolution, and even more happens too, including full 720x480.
That's the point! which is consistent with my finding. We have to consider that with ITU, we would lose valid image for majority of DVDs. If you look at movie content you will be even more sure on this.
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.

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...

For this DVD there are black borders on all edges not just sides, more like picture underscan than ITU. Black side areas are ~1 third of ITU blanking area, you can find something like this on DVDs originated from HD content also. And these kind of Aspect Ratio is very normal regardless of side edges appearance (which can be vary, also depends on content type and its age)
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.

[SyrupBuccaneer]

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

[corporalgator]

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?

[leeperry]

I posted the correct levels (in floating point) and the math how to achieve them in one of my previous posts.
Yep, I got that but IIRC Seb.26 told me ages ago that you couldn't just fill those two lines with the levels you wanted to achieve in the end:
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);
}
I believe these two very lines are supposed to process a TV>PC conversion actually..

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 :cool:)

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 :p

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 :o

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 :D

[Mangix]

Which exact peculiarities are you interested in? DXVA2 processing in madVR should behave mostly similar to other renderers.

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.

[bugmen0t]

Problem cured in 85.3. thx
We indeed must have had the same issue, 85.3 fixed it for me as well.
Thanks madshi!

[pururin]

because when running a 16/9 resolution it seems pretty much impossible to find out the ideal 4:3 width :o

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 :D

The DVD non-ITU practice have been quite firm, especially nowadays. It's not that impossible to find suitable preset.

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 :D). 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.

[madshi]

Does madVR officially support screenshots/image capture as of latest?
Yes.

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.
Is that while the video is running? Or while the video is paused? While the video is running it is possible that the capture is a bit ahead of what is currently on screen. But while the video is paused you should really get the frame which is visible on screen. At least that's how it's supposed to be.

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?
Sounds good to me. You do lose the values < 16 and > 235 this way, but these values are not supposed to be seen on screen, anyway, so it's not a big loss. You could also set your plasma to standard HDMI range and madVR to 16-235. That should be roughly identical in image quality for madVR playback, while preserving < 16 and > 235 data. But if you do that, your desktop and photos etc will have wrong black/white levels.

ah well, Seb.26 actually says on HCFR that this levels conversion script is "low quality" "incorrect" and "buggy", hurray!
Why is he saying that? Ok, MPC-HC performs shaders in 8bit by default, I think, and cuts BTB and WTW. But that does not apply to madVR. The formula used by that script looks alright to me on a quick look. It converts TV to PC, though, so it's the opposite of what you want.

And do you think it would be preferable to use the gamut mapping PS script before or after scaling?
It doesn't matter at all, IMHO.

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)?
Removing source artifacts (de-ring, de-noise, de-band) before scaling. Sharpening and detail enhancement etc after scaling.

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.
Well, that's all kinda a moving target since I'm still shifting the code around atm, and things could change in the near future again. But I can write up the current situation as part of the next release (so it's easier to find).

The point is for NTSC a bit complicated ones, those aspect ratio discrepancies are too low (less than 1% of the real AR) to be worry about already. Most, if not all, human can't tell that very small difference 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.

Have users 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 I think.
But what options would that be exactly?

[aufkrawall]

Unfortunately a debug log doesn't help if madVR crashes. Did you get a madVR crash box? If so, please make the bug report available to me.

I see one, but just for a short moment, somehow the box disappears very quickly. No chance to click anything. :(

[madshi]

Even simpler, display the seekbar whenever a video is paused in FSE?
That's not possible currently cause that would confuse the MPC-HC internal subtitle renderer. I'm already blocking MPC-HC's "Pause" OSD message so subtitles don't disappear if video is paused. These problems should go away when using the new subtitle interface, but we're not there yet...

madVR is crashing on me with the latest release. Using latest MPC-HC and LAV with DXVA2 native decoder.

Steps to reproduce crash:

1 -> Resize window up/down

2 -> Drag to second screen.
Sometimes madVR crashes for me with this build when entering FSE and changing display mode.
Debug log:
http://www.mediafire.com/?c330yb82plip6ig
I found a bug which could result in crashes when using native DXVA decoding in certain situations. The fix for that might solve these two crashes.

[Prinz]

With LAV? A madVR debug log might help.

Found the reason. In Zoomplayer DirectVobSub will be loaded with the non-working files and that courses the fall back to software decode. Files that don't have a subtitle track work in Zoomplayer too.

[hannes69]

(1) Use software decoding and e.g. Bilinear scaling.
(2) Use native DXVA2 decoding and e.g. Bilinear scaling.
(3) Use software decoding and DXVA2 scaling.
(4) Use native DXVA2 decoding and DXVA2 scaling.

Redone the test with 0.85.3:
Same behaviour like 0.85.2.
(1), (3) and (4) are the same, (2) is different (oversaturated green). So using native decoding without dxva scaling is still broken (at least for my setup).

[alizard]

Madshi, levels are now incorrect using 85.3 with dxva scaling and mpc-hc internal decoder and splitter. Blacks are now grey. Other scaling methods provide proper levels. I'm using the old path exclusive without overlay on an Amd card.

[chros]

I have accidently realized that there's a huge performance issue since v0.85.2 (v0.85.1 is OK) when I using post resize pixel shader (sharpen complex 2) in mpc-hc on my laptop (720p content upscaled to 1680*xxx).

test (using nvidia inspector):
- v0.85.1: MCU usage: 19%, GPU usage: 53%
- v0.85.3: MCU usage: 30%, GPU usage: 78% (!!!!)

If I disable post resize shaders in mpc-hc, everything is the same between the 2 builds (or 0.85.3 is even slightly better).

I you need more info, just ask ... :)

Thanks

[toniash]

@leeperry

There's only very slight issue, though...it's that post-scaling PS scripts seem to be processed pre-


So pre and post are interchanged or all run in pre?

[pandy]

It's not that easy for computer stuff, though. The problem is that the Windows desktop is always renderes in Full Range. So if you GPU has to output Limited Range, it has to post-process the Windows output. And that costs image quality, especially if it's done without dithering (and I think it usually is done with dithering). That's why having the GPU output limited range over HDMI is actually a bad thing for us HTPC users.


Then signal Full Quantization Range in AVI InfoFrame - HDMI Sink shall understand this and shall use 0 - 255 quantization range. Only RGB colorspace shall be used for Full Quantization Range. Or perhaps force HDMI to DVI mode then only 0 - 255 RGB is allowed.


But still the question remains: Maybe any resolution between 702 and 720 is *possible*, but which is used most often in real life? If 90% of the ITU scaled content is using 702, then it would be worth it offering an option for that exact aspect ratio. But if ITU scaled content is all over the place, then it doesn't make sense to offer such an option. So what we need is not necessarily a proper interpretation of the specs, but instead we need to check how this is done in real life.

If we use digital sources (i mean MPEG-2, H.264) then choice is quite simple 704 and 720 pixels, 702 - 716 problem affect only analog capture sources and knowledge about capture device is required to understand real number of pixels in captured source. This purely source/display dependable relation - to be precise we need to know what timing is used by grabber and what timing is used by display. Without this everything will be educated guess.

[hannes69]

Some experience with calibration:
I use a ColorMunki Display colorimeter to calibrate my Infocus X9 720p DLP projector. First I used the parameters inside the projector for basic calibration. "Nice": my projector has brightness/contrast/gamma setting in menu but no color gain/offset controls. I had to construct a serial 9pin to 3pin cable to get to the "hidden" greyscale controls by using a com console... So first setting white and black point with AVS test patterns. Bar 17 barely visible. Then I set greyscale with projector settings, readjusted blackpoint. Then I used Argyll/dispalGUI to build an ICC file. I get perfect 2.2 gamma, flat RGB niveau (< 2 deltaE for IRE>20) says HCFR. But now bar 17 and 18 are lost in black point test pattern. To see them again I have to lower gamma setting in madvr to 2.0. The outcoming is consistent to my viewing experience: I watch Breaking Bad series , there are many "dark scenes" like camera viewing from inside back of a car direction front to the dashboard. The instruments there are black, black detail is lost with gamma 2.2. And that in a scene with daylight. Thats not real life experience, sitting in a car with daylight you see the instruments. By lowering gamma to 2.0 it is a little bit better but not completely realistic. Many recommend a gamma of 2.4 for homecinema. I watch in a dim room (no light), with gamma 2.4 there´s a great loss of shadow detail. What´s the reason behind that experience? Probably poor contrast (my Infocus gets 900:1 in HCFR)?
Furthermore I tried yCMS capabilities. I think it does what it is supposed to do: the corners of my CIE lay on the 709 CIE triangle sides. So there are no more outofgamut colors, but the price to pay is a srewed up greyscale. It´s not totally screwed but getting worse (greyscale steps pattern is tinted). I think I´ll stay with perfect greyscale, primaries/secondaries stay within <15 deltaE, that´s not ideal but ok for me. I´m not perfectly into that materia, maybe yesgrey can improve that (he´s working on yCMS 2.0 regarding his thread).
I tried different methods, typing in my measured values to madvr-ycms setting, gamut alone or gamut+greyscale, and I tried the method of building a 3dlut file out of the icc. All methods work (cutting out of gamut colors) but influence negatively greyscale.
Beside that a calibrated picture looks great, it was worth the effort.:D