madVR - high quality video renderer (GPU assisted)

[rack04]

I'm planning to upgrade my current 8800GT video card with a GTX650ti after the holidays. They have 2 variants of this card, 1GB and 2GB. Will I see any benefit going with the 2GB version of card if I strictly use it for HTPC (madVR, LAV Filters, Reclock)?

[dansrfe]

I'm planning to upgrade my current 8800GT video card with a GTX650ti after the holidays. They have 2 variants of this card, 1GB and 2GB. Will I see any benefit going with the 2GB version of card if I strictly use it for HTPC (madVR, LAV Filters, Reclock)?

The more the better. Go for the 2GB, definitely.

[Heuer]

I have a GTX650Ti with 1GB GDDR5 and it handles everything I can throw at it with LAV+madVR+Re-clock running. Jinc and anti-ringing are set and GPU load rarely goes above 10% and temperatures, on the hybrid active/passive cooled MSI card, are never higher than 45C with the most challenging of upscaling. With 1080p it is just ticking over. Can't think why you wopuld need 2Gb unless you are gaming, in which case a GTX660 would be more appropriate.
http://i5.photobucket.com/albums/y186/q-max/General/b333.jpg

[leeperry]

I have a GTX650Ti with 1GB GDDR5 and it handles everything I can throw at it with LAV+madVR+Re-clock running. Jinc and anti-ringing are set and GPU load rarely goes above 10%
what kind of load do you get with Jinc3 AR for both luma and chroma when upscaling 30fps SD to 1080p please?

2GB is already overkill for most games FWIR..

[JEEB]

Also, I don't know how BluRays handle SD content, is it encoded with ITU scaling instead of "pure Pixel Aspect Ratio" at all? Personally, I'd assume that since BD was created with Digital Video in mind, the SD content on BDs might just as well use "simple", non-ITU scaling.
Maybe (I doubt it, though), there could also be rules that only apply when the input is MPEG-2 and one of the 2 standard resolutions. Though, I believe that Aspect Ratio correction should actually be the Splitter's work...
As noted both in the blu-ray specification as well as at the SD parts of x264bluray.com (http://www.x264bluray.com/home/480p-ntsc), the simplified ITU aspect ratios (40:33/10:11 and 16:11/12:11) are to be used. Just like with DVDs as far as I know.

[Hwasin]

Can someone explain what is this new subtitle interface?

[sneaker_ger]

It allows subtitle filters to draw the subtitles with the full display resolution (and in 4:4:4) instead of just with the source video resolution (mostly 4:2:0). madVR will then overlay the subtitles itself onto the video image before output. This potentially increases quality and is compatible with native DXVA2 decoding. MPC-HCs internal subtitle filter already uses a similar interface.
Currently no subtitle filter supports this, but the xy-vsfilter team is working on it.

[jmonier]

It's covered in these two threads:

http://code.google.com/p/xy-vsfilter/issues/detail?id=40

http://code.google.com/p/xy-vsfilter/issues/detail?id=91

[DragonQ]

What is the point of 720x576 if only the 702x576 portion is meant to be the 16:9 area? Why not just use 704x576 for SD?

[Sneals2000]

What is the point of 720x576 if only the 702x576 portion is meant to be the 16:9 area? Why not just use 704x576 for SD?

A couple of reasons. It allowed a common total digital line length for both 50 and 60Hz standards, and allowed some wiggle room for analogue sourced content (which back in the early 80s was almost all content)

If you A/D and D/A sampled the analogue output of an analogue 1" VTR in 1985 you wouldn't want just 1 sample of latitude either side...

ITU 601 pre-dates modern digital compression and transmission systems by many, many years.

If you're asking why bother now - many do in fact use 704x576 for broadcast. However intermediate kit should pass the 18 samples outside 702x576 (for the same reason they are sampled in the first place)

[DragonQ]

I see. Yeah I think all non-BBC SD channels in the UK are 704x576 or 544x576. Not sure why the BBC persist with 720x576 when everything is sourced from HD anyway and thus there's no need for the extra columns.

[Sneals2000]

I see. Yeah I think all non-BBC SD channels in the UK are 704x576 or 544x576. Not sure why the BBC persist with 720x576 when everything is sourced from HD anyway and thus there's no need for the extra columns.

On terrestrial I think the former analogue channels have to broadcast at full resolution (i.e. 704 or 720x576 not 544x576) but that others can run at 544x576 to save bandwith.

Can't really comment on the 720x576 vs 704x576 issue, though I guess 18 samples of black each line aren't going to tax encoders too much.

And not everything is sourced HD - lots of daytime is still SD originated, as is most of the News until the New Year when it moves to HD studios in Central London. (Newsnight, The Andrew Marr Show and Sunday Politics have already moved and are HD)

So now SD-originated shows on BBC One are upconverted to HD and then downconverted back to SD for broadcast on SD platforms. (Previously BBC One HD and BBC One SD had slightly separate chains)

[Ryokurin]

I'm planning to upgrade my current 8800GT video card with a GTX650ti after the holidays. They have 2 variants of this card, 1GB and 2GB. Will I see any benefit going with the 2GB version of card if I strictly use it for HTPC (madVR, LAV Filters, Reclock)?

Whichever has the faster memory. I currently run a GT640 with 2gb of memory. It runs MadVR quite well, but it tends to struggle with some of the newer techniques, not because of processing, but because the memory is relatively slow DR3.

[Joniii]

madshi, on full screen madvr shows the seekbar when moving mouse to the bottom of the screen. Would it be possible to add an option for it to show when user presses the play button on remote? That's one of the nice features of WMC, when watching something it will show no UI items but when pressing play it will show seekbar and clock for couple of seconds so you can quickly check how much is left and what time it is.

Also is there any way to customize the seekbar overlay?

[pururin]

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.

P.S: Sneals2000, if you find anything else wrong in madVR, please let me know!

What a good timing.
I've been writing a thread on 704 vs. 720 issue with many DVD vs. Blu-Ray comparisons, both PAL and NTSC. (I even calculated aspect ratio differences)
Which sub-forum should I post the topic on? It isn't finished yet (due to wrist pain and other stuffs) but I'll try post it soon.


From my point of view, following the standards is very important. However, making the majority of content look right is even more important. So for me the key questions are:

(1) Do users today play more content which needs 720x576 -> 1024x576 scaling, or do they play more content which needs 720x576 -> 1050x576 scaling?
(2) What do the majority of DVD studios do today?
(3) What do the majority of broadcasters do today?

It seems to me that probably the majority of newly released DVDs these day probably need 720x576 -> 1024x576 scaling.

Not only newly DVDs are like that. From my little research, most widescreen PAL DVDs are like that since early 2000s, treating 720x576 exactly as full 16:9 picture.
NTSC version (even of the same title & studio) is a bit more complicated but still quite the same which non-ITU scaling should be more suitable.

I think I can answer question (2) now at least. (I try to cover DVDs since the old time also to see what they've been doing)
Almost every DVD studios now use about the same non-ITU standard for WS DVD (all over the world: Europe, Japan, US, etc.) for quite some time now. For 4:3 content I'm not very sure but I think it's the same now as well although much more late.

For DVD world, they seems to adhere to ITU only for the 1st generation DVDs (~1997-2000) so it's quite clear that they decided to change (especially WS content).
It's too difficult for me to get infos or samples of broadcasts over the world though.

It's seems that some real-world standards/practices ignore ITU. For them "correct" or not by the book may be not important as end result.
So overall if we have to choose one way over the other, I think it's a lot safer to left madVR as is, especially if you watch (PAL) DVDs.



DVDs mastered from broadcast SD video sources (rather than file-based downconversion of HD sources) should definitely be properly ITU 601 compliant though.

Certainly HD 1920x1080 broadcasts simulcast in SD should be converted to 702x576 - and as more and more broadcasters now originate in HD, there should be a lot of empty 9 samples either side! (Assuming downconversion is being done correctly...) As I've mentioned - lots of broadcasters use 704x576 rather than 720x576 for broadcast for this reason.
From at least few samples I've found (Japanese anime), DVDs mastered from SD video sources seems to follow their own non-ITU DVD standard.

As for broadcast, I'm not sure but according to this old thread here (http://forum.doom9.org/showthread.php?t=132378), the broadcast world seems to simply resampling 1920x1080 to 720x576. :confused:


I'd also not be surprised if some HD downconversion from 1920x1080 or 1280x720 to SD was incorrectly scaled to 720x576 rather than 702x576. Doesn't make it right...

At the end of the day it's going to be a very small geometric distortion, and I suspect there are significant numbers of DVDs mastered in both ways. However ITU 601 is really clear - and all SD digital video based on 720x576 should be ITU 601 compliant - and anything handling ITU 601 content should really follow the standards I would suggest. Just because others don't doesn't mean everyone shouldn't.

Maybe incorrect (from that point of view) but provide more compatible, less complaint from customers, etc. so they opt for non-ITU solutions. (and maybe a bit more quality gain over very small AR error)

Also as you know, things were a horrible mess at the time. Mass confusion on PAR, different committees came up with different standards, etc.
So in my opinion we can't fully blame them as "wrong" as there was no clear & unify standard/explanation at first and when things got settled down it was somewhat too late, unlike HD.

The results to date are evident in themselves, well established & messy :p even when we're moving to HD already.
So yeah the standard is important but if it's not fully compliant with real-world as it is now (blame the old mess?)...
I think at this point we should accept things as they are and find the most suitable way for them, not too strict on following ITU standard.

[madshi]

madVR doesn't work good with mpc and microsoft dxva decoder at least on HD5870 with 12.10 driver.

Playback starts fine, but madvr freeze after seek: see https://dl.dropbox.com/u/16282309/mad/madVR-freeze.report.mpc.dxva.7z
and log: https://dl.dropbox.com/u/16282309/mad/madVR.log.mpc.dxva.7z

ffdshow DXVA and LAV doesn't have seeking problem. MPC and Microsoft DTV-DVD Video Decoder have.
Hmmmm... What happens if you reduce the madVR queues to the minimum possible sizes? I'm not suggesting to actually use madVR this way for playback. Just as a test whether this "fixes" the freezes?

My best guess right now is that those decoders which cause a freeze might not allocate enough surfaces for decoding + filling the madVR queues. But it's only a guess right now...

Sorry if already discussed: When running on old video card (Radeon 550 PS2.0) just a black screen. No any errors. All interfaces are created without errors. How can I know that the video can not be played (black screen)?
madVR requires PS3.0 hardware support, unfortunately. I guess I should add a proper check and display an error if the GPU does not support PS3.0.

Love MadVR!
:)

madshi, on full screen madvr shows the seekbar when moving mouse to the bottom of the screen. Would it be possible to add an option for it to show when user presses the play button on remote? That's one of the nice features of WMC, when watching something it will show no UI items but when pressing play it will show seekbar and clock for couple of seconds so you can quickly check how much is left and what time it is.

Also is there any way to customize the seekbar overlay?
There is no way to customize the seekbar overlay at the moment. And I don't know when the user presses the play button on remote. Such events are handled by the media player. I don't think I can get easy access to that, but I'm not fully sure. It's not something I have time for at the moment, in any case. Maybe you can ask again when madVR has reached v1.0.

[madshi]

Ok, now to the tricky stuff:

Guys if You All trying to be so precise, pro and accurate then please check BT.1700 and BT.801 test signal No. 3. - there is 706 pixels in active video line.
Isn't BT 801 testing both the full 720 sample line and the 702 active line? I thought it was there to check whether full and 4:3/16:9 active were both being passed or not?

[...]

I don't think that test signal defines 4:3/16:9 active as 706 lines does it?
As noted both in the blu-ray specification as well as at the SD parts of x264bluray.com (http://www.x264bluray.com/home/480p-ntsc), the simplified ITU aspect ratios (40:33/10:11 and 16:11/12:11) are to be used. Just like with DVDs as far as I know.
Great. So we have 3 different possible ITU aspect ratios. The difference between them may be small. But I can only suport one of them.

I tried this myself several times (but in my case, I used NTSC DVDs of older anime). In my experiments, in all DVDs I tried (and where I found usable frames for checking) I discovered that they were most likely to have been created assuming ITU scaling. (Edit: Actually I think I found one case where it was inconclusive, too. I couldn't tell which was the right way there).

That is, for NTSC a 4/3 source looked right at 720x527, not at 720x540. A 16/9 source looked correctly at 875x480 and not at 853x480. Of course, it is still just anecdotal evidence, but I think that professional authoring teams do use ITU.
(The dvds were old anime material, but included both older releases from early 2000s and more recent remaster releases). Anyway, now I always assume that DVDs use ITU scaling. it might be an opinion, but I chose to err on the side of specifications :)
Not only newly DVDs are like that. From my little research, most widescreen PAL DVDs are like that since early 2000s, treating 720x576 frame as full 16:9 picture.
NTSC version (even of the same title & studio) is a bit more complicated but still quite the same which non-ITU scaling should be more suitable.

I think I can answer question (2) now at least. (I try to cover DVDs since the old time also to see what they've been doing)
Almost every DVD studios now use about the same non-ITU standard for WS DVD (all over the world: Europe, Japan, US, etc.) for quite some time now. For 4:3 content I'm not very sure but I think it's the same now as well although much more late.

For DVD world, they seems to adhere to ITU only for the 1st generation DVDs (~1997-2000) so it's quite clear that they decided to change (especially WS content).
It's too difficult for me to get infos or samples of broadcasts over the world though.

It's seems that some real-world standards/practices ignore ITU. For them "correct" or not by the book may be not important as end result.
So overall if we have to choose one way over the other, I think it's a lot safer to left madVR as is, especially if you watch (PAL) DVDs.
And one more conflict. mandarinka says NTSC (Anime) DVDs mostly use ITU. pururin more or less says the opposite.

-------

At this point we have 3 questions to answer. Could we please try to work all together on this?

(1) Should the current solution stay default? Or should ITU become default? Whatever we decide on, the "other" solution would then be an option in madVR.

(2) For PAL ITU, what exactly should madVR do?
(2a) Should madVR crop the outer pixels?
(2b) Which exact aspect ratio should be used?

(3) For NTSC ITU, what exactly should madVR do?
(3a) Should madVR crop the outer pixels?
(3b) Which exact aspect ratio should be used?

[Joniii]

There is no way to customize the seekbar overlay at the moment. And I don't know when the user presses the play button on remote. Such events are handled by the media player. I don't think I can get easy access to that, but I'm not fully sure. It's not something I have time for at the moment, in any case. Maybe you can ask again when madVR has reached v1.0.

I was thinking it could be really simple, like adding a function to show madvr seekbar for x seconds then adding a new keyboard shortcut option to madvr that launches it, also allowing to map media keys like "MEDIA_PLAY".

But yeah it might not be that simple. I'll ask again then :)

[madshi]

I was thinking it could be really simple, like adding a function to show madvr seekbar for x seconds then adding a new keyboard shortcut option to madvr that launches it, also allowing to map media keys like "MEDIA_PLAY".
Ah, ok, well that should not be too hard, I guess. I thought you wanted me to react to the user pressing a key on his remote control somehow (no idea how).

[ryrynz]

Nevermind. :D

[pandy]

That won't work in all cases. There's no requirement for correctly scaled ITU 601 to have black samples in the 9 samples either side of the 702x576 "4:3/16:9" frame. As more and more content is originated HD, then this is increasingly likely to be the case (16:9 1920x1080 or 1280x720 HD should be downconverted to fill the 702x576 centre section), however SD originated content can have content in the edges of frame (such as vision mixer mattes, DVE borders etc.)

Assuming that the presence of picture content outside the 702x576 central section implies non-ITU 601 compliance is not a safe assumption.

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 .

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

[6233638]

Ah, ok, well that should not be too hard, I guess. I thought you wanted me to react to the user pressing a key on his remote control somehow (no idea how).Even simpler, display the seekbar whenever a video is paused in FSE?

[pandy]

(1) Should the current solution stay default? Or should ITU become default? Whatever we decide on, the "other" solution would then be an option in madVR.

(2) For PAL ITU, what exactly should madVR do?
(2a) Should madVR crop the outer pixels?
(2b) Which exact aspect ratio should be used?

(3) For NTSC ITU, what exactly should madVR do?
(3a) Should madVR crop the outer pixels?
(3b) Which exact aspect ratio should be used?

I can only say:
For PAL (625 line systems based on ITU-R BT.1700) period that can be used for video is equal to 64-11.7=52.3us and for sampling 13.5MHz this give us exactly 706.05 pixels

For NTSC (525 line systems based on SMPTE 170M-2004)
this is 63.556-10.5=53.056us and for sampling 13.5MHz this give us exactly 716.256 pixels

Also based on definitions from above mentioned standards some additional tens of ns can be used for displaying visible and valid video (and have full conformance with standard), we can assume that 525 system is capable to display almost all 720 pixels, and 625 system is capable to display around 708 - 710 pixels or all 720 - this functionality is provided by some HW companies (like ST Microelectronics for example).
http://img254.imageshack.us/img254/80/5510.png


IMHO there is no sense to change current implementation - however if change anything then perfect size shall be arbitrary settable during for example calibration - then with help of ruler and after measurements final size should be applied especially that it will be display dependent type of settings.
Some comment to above - it will horrible and nasty to perform decent (performance vs quality and coding time) resizer with arbitrary settings and subpixel resolution.

[pururin]

And one more conflict. mandarinka says NTSC (Anime) DVDs mostly use ITU. pururin more or less says the opposite.

What method did mandarinka use to determine? Because NTSC DVD production has little black magic about AR. ;)
The method I use is compare them to HD version (Blu-ray) which is free from these confusing stuffs.
I found that trying to look for perfect shape or determine from picture edges area alone are not quite reliable. Especially in anime content, you can never be sure of the real shape. (what are "usable frames" that mandarinka mentioned?)


Actually I intend to go in details about NTSC later but I'll post some quick example I've wrote:

"1st, display full 720x480 DVD frame as 16:9 image (all software players do it like this) and compare it to Blu-ray disc:
(These animated comparisons with debug texts below is just for quick example. The pictures are from anime Steins;Gate)
http://s6.postimage.org/wu9eidoap/S_G_R2_J_DVD_vs_BD.gif

Notice the use of non-ITU 720-based PAR =1.185 (32/27) and sample width=720 pixels. Those texts are debug messages of Dither (http://forum.doom9.org/showthread.php?p=1386559#post1386559) which I use with AvsPmod+FFVideoSource for taking the screenshots.


2nd, display DVD according to Rec.601 spec by cropping 8 pixels off both sides and using the ITU Pixel Aspect Ratio =1.212 (40/33 for 16:9 NTSC) (Notice sample width=704)
Now BD pic are cropped off 2.22% equally on all four sides (no AR change) to accommodate with Rec.601 DVD width (1440x810 (http://img11.imageshack.us/img11/7139/blurayprecrop.jpg) cropped to 1408x792 to avoid rounding errors)

http://s6.postimage.org/rdqqnzuwx/S_G_DVD_rec_601_vs_BD_cropped.gif

You'll notice that neither 720 nor 704 (ITU) display is the right "true" aspect ratio.

In terms of AR, both is not right (which way is better is to be measured after this)
but the point for NTSC DVD is it's not that ITU must be correct and 720 is always 2.222% thinner (or 720 is correct and ITU must be 2.273% wider, on the contrary).

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

"Before you ask, no I didn't directly measure the difference in height between 2 versions because this method is not accurate enough (pics are much too small to do that).
What I do is edit the BD pic at native 1080p resolution (sometimes higher, or lower but not too much) to match the full frame DVD picture, like when they cropped off the Hi-res master before scaling to DVD resolution, then calculate the difference between original and edited BD to aspec ratio values."
= = = = = =

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. Even if AR favors 704 a bit more, you'll still much more likely have to decide on whether cropping the sides off is beneficial.

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.


I'm quite sure on this about Movies and newer animes (especially those with HD production), but I have only few real old anime samples as they are hard to find and match with BD re-releases.

Also the situation for 4:3 content is somewhat different to WS content as I've said, they have different reason behind doing it. 4:3 tends to be ITU, I suspect this is because consumers couldn't see annoying side black bars when displayed with non-ITU method on widescreen monitor, and the black bars is much thinner in this case.
So what mandarinka said might not contradict to mine as he said he mostly look at old animes (which many of them should be 4:3?).


At this point we have 3 questions to answer. Could we please try to work all together on this?

(1) Should the current solution stay default? Or should ITU become default? Whatever we decide on, the "other" solution would then be an option in madVR.

(2) For PAL ITU, what exactly should madVR do?...

(3) For NTSC ITU, what exactly should madVR do?...

I think this issue is not of high priority at all. Things are like this for ages and all software players have been doing like madVR for more than a decade and I've never seen anyone noticed or complained about it.
Or maybe I could say DVD studios have been doing a great job managing their products on software display ;)

So IMHO you could wait much longer for more information to carefully decide later. (also maybe you might want to look at my comparison thread which I've not yet finished :p it may help you to decide at least a little)

But if you are going at this now, my opinion is there is no need to change. Tons of DVDs are actually better with software method.

[madshi]

I think this issue is not of high priority at all.
It's not high priority, but it would be rather easy for me to implement, so there's no need to push it back.

So IMHO you could wait much longer for more information to carefully decide later.
Well, I'm not in a hurry with this, but it seems there are several people here right now with an opinion about this topic, so it's probably a good time to discuss it now. If I wait a couple more weeks/months, maybe those people won't happen to be around at that time.

[kasper93]

Hmmmm... What happens if you reduce the madVR queues to the minimum possible sizes? I'm not suggesting to actually use madVR this way for playback. Just as a test whether this "fixes" the freezes?

Yes, you are right. No freeze with minimum queues and trick with "delay playback start after seeking" also prevent freeze.

[pururin]

It's not high priority, but it would be rather easy for me to implement, so there's no need to push it back.

Well, I'm not in a hurry with this, but it seems there are several people here right now with an opinion about this topic, so it's probably a good time to discuss it now
That's really good news, easy to implement.

didn't mean to hold you back on this topic though :o, just mean you can take time discussing and gathering info and implementing it later. Because I feel there are a lot of details: Broadcasts, DVDs, various Cams, capture cards etc. Each has different proportion in following ITU, none of them are strictly all ITU.

I forgot to mention earlier that most anamorphic clip out there are non-ITU approach. Most encoders just crop few pixels off if they think the edges are too dirty, and have custom PAR specified (usually 720-based like decribed on the bottom of this page (http://seemoredigital.net/03_Video_Only_Info/What_is_an_anamorphic_encode.html)).
That happen to be somewhat best solution for NTSC DVD, better aspect ratios than both 720 or 704.


I would vote on keeping current solution as default and ITU can be turn on when needed. At least users can see whole image first before decide.
ITU always come with cropping so ITU as default could lead to undesirable result without knowing, pic got automatically cropped off before display. Average user that didn't know this will be automatically stuck with ITU.

About PAR, My understanding is as JEEB mentioned:
NTSC: 40.0/33.0 for 16:9, 10.0/11.0 for 4:3
PAL: 16.0/11.0 for 16:9, 12.0/11.0 for 4:3


p.s. You know, I really appreciate that there will be a user friendly and precise software solution for this matter.
I bet in the ~15 years history of those DVD software players many must had raised this topic before but I guess those companies deemed it unnecessary.

[Keiyakusha]

Just want to note that for all my DVDs whose sales started like few years ago, maybe 5 and newer, 720x480->853x480 is the only correct way of scaling. It may still not match to BD for example, because it is badly made and they cropped something for some reason, but its still the closest. And there is never any black bars, except maybe 2px at top or bottom (not always) and 1 semi-dark px at sides (can also be pixel that is brighter than needed but anyway it contains useful information). Still it happens there is no even single semi-dark one in some cases. It is actually valid for most older my dvd's too.
So the current madvr behavior seems to be alright. Except that I'm not really happy with stuff I reported before, when we have 1919x1080 resolution at the end (or was it fixed? didn't payed attention)

Edit: imho it is too late for enforcing any standard when the standard itself is almost dead. Whatever way will be chosen will leave some of the content "broken" and making more options will just confuse users further. Even if user will ask which option should be chosen for scaling, he won't get an answer until person he asks will see and check the actual content (there is not much content that contains perfectly round circles or something). You're not going to compare each dvd to bluray before watching it. Means it is useless. Just leave everything as it was for years and everyone is used to.

[fallengt]

Hi,
I have something unclear hope somebody can answer it..

I use my laptop (dual graphic cards - intel iGPU 3000 and ATI 6770M) as a HTPC, it connect to panny plasma ST50 via HDMI-HDMI cable. This TV is euro model and doesn't have black level control unlike NA model. I assume it's at Standard (16-235) so I set dymanic range inside Intel graphic properties to Limited (which is RGB 16-235 ??) and set both Madvr/Lav video decoder at PC level (0-255). Everything work fine but not sure if it's the best configuration for me
Changing anything makes my screen completely washed out.

[pandy]

Everything work fine but not sure if it's the best configuration for me
Changing anything makes my screen completely washed out.

Rule is quite simple - HDMI standard (and CEA861) cover this topic in strict way:
HDMI connection (HDMI mode) use always Limited Quantization Range (i.e. 16-235 for Y and 16-240 for Cx), Full Quantization Range is used only for DVI connection (over HDMI/DVI).

[DragonQ]

It still amazes me how the switches for full range (0-255) and limited range (16-235) sometimes do nothing. It's happened to me with 3 different TVs and 2 different PCs (one with Intel IGP, one with nVidia GPU). :rolleyes:

[HoP]

@madshi
does madvr support numpad??
i create shortcut "Ctrl+Alt+1", but if i press 1 in numpad(on my laptop) it doesn't work.
i should press 1 located at the top of keyboard for that shortcut.

[nevcairiel]

Rule is quite simple - HDMI standard (and CEA861) cover this topic in strict way:
HDMI connection (HDMI mode) use always Limited Quantization Range (i.e. 16-235 for Y and 16-240 for Cx), Full Quantization Range is used only for DVI connection (over HDMI/DVI).

Except thats nonsense, you can easily output full range over HDMI with all GPUs, and plenty TVs accept that just fine and even have options for that.
Written standards are not useful if the reality is just something else entirely.

[jmonier]

Rule is quite simple - HDMI standard (and CEA861) cover this topic in strict way:
HDMI connection (HDMI mode) use always Limited Quantization Range (i.e. 16-235 for Y and 16-240 for Cx), Full Quantization Range is used only for DVI connection (over HDMI/DVI).

This is certainly the standard for YCbCr (and MAYBE it's a standard for HDMI) but RGB can also be used over HDMI at either video (16-235) or PC (0-255) levels. Any HTPC and some other equipment (Oppo, for instance) can use YCbCr (16-235 only) OR RGB at either video or PC. Most (if not all) monitors and projectors can be used the same way.

In particular, madVR uses RGB (only) at either video or PC (and either works fine over HDMI), so it's not as simple as you seem to think.

(The difference between DVI and HDMI is only in the connectors and in the fact that HDCP is optional for DVI and mandatory for HDMI.)

[pandy]

Except thats nonsense, you can easily output full range over HDMI with all GPUs, and plenty TVs accept that just fine and even have options for that.
Written standards are not useful if the reality is just something else entirely.

Ask vendor about HDMI compliancy statement and ask HDMI organization about this - i have personal impression that HDMI and HDCP are poor standards, invented in rush without sense.

What is quite funny - AVI infoframe provide required information that source output video with Full or Limited Quantization Range and customer shall be not even bothered for such problem - however drivers are written sometimes by people without any HW experience - then you have problem and real headache...

This is certainly the standard for YCbCr (and MAYBE it's a standard for HDMI) but RGB can also be used over HDMI at either video (16-235) or PC (0-255) levels. Any HTPC and some other equipment (Oppo, for instance) can use YCbCr (16-235 only) OR RGB at either video or PC. Most (if not all) monitors and projectors can be used the same way.

In particular, madVR uses RGB (only) at either video or PC (and either works fine over HDMI), so it's not as simple as you seem to think.

(The difference between DVI and HDMI is only in the connectors and in the fact that HDCP is optional for DVI and mandatory for HDMI.)

Difference between DVI and HDMi is much bigger than only connector but this is irrelevant for this problem.

excerpt from HDMI specification:
"6.6
Video Quantization Ranges
Black and white levels for video components shall be either “Full Range” or “Limited Range.”
YCBCR components shall always be Limited Range while RGB components may be either Full
Range or Limited Range. While using RGB, Limited Range shall be used for all video formats
defined in CEA-861-D, with the exception of VGA (640x480) format, which requires Full Range."

This is quite straightforward definition or i misunderstood meaning of the word "shall"

[toniash]

@leeperry with support for PS in Madvr!

[jmonier]

It still amazes me how the switches for full range (0-255) and limited range (16-235) sometimes do nothing. It's happened to me with 3 different TVs and 2 different PCs (one with Intel IGP, one with nVidia GPU). :rolleyes:

Some TV's clip the output to the specified range so you can never see BTB and WTW even though the the blacks and whites are correct for the specified range.

There are a number of reasons for what you've seen and it depends on the setup at both ends, as well as the test pattern used, to explain it.

[DragonQ]

Some TV's clip the output to the specified range so you can never see BTB and WTW even though the the blacks and whites are correct for the specified range.

There are a number of reasons for what you've seen and it depends on the setup at both ends, as well as the test pattern used, to explain it.
What I mean though is that literally nothing happens when changing the setting. Not even a brief flash of the screen you'd see when changing the resolution or refresh rate, pressing the "OK" button in the settings window does bugger all; I have no idea if the output has actually changed or not! :D

[jmonier]

excerpt from HDMI specification:
"6.6
Video Quantization Ranges
Black and white levels for video components shall be either “Full Range” or “Limited Range.”
YCBCR components shall always be Limited Range while RGB components may be either Full
Range or Limited Range. While using RGB, Limited Range shall be used for all video formats
defined in CEA-861-D, with the exception of VGA (640x480) format, which requires Full Range."

This is quite straightforward definition or i misunderstood meaning of the word "shall"

I never denied that the spec MIGHT say that. If the spec does say that, then it is most often ignored (and ALWAYS for HTPC's).

If you try to give advice then you should be sure you understand what is done in the real world and give advice based on that, not just on a spec.

[jmonier]

What I mean though is that literally nothing happens when changing the setting. Not even a brief flash of the screen you'd see when changing the resolution or refresh rate, pressing the "OK" button in the settings window does bugger all; I have no idea if the output has actually changed or not! :D

You would certainly see a change if you were looking at a the proper test pattern. Since this change is just a level setting (one or two parameters and minor as far as the processing being done), it can be implemented without the flashing, etc. that occurs on a resolution or refresh rate change (which is a MAJOR reconfiguration in the video card). So, it's not at all surprising.

[madshi]

Yes, you are right. No freeze with minimum queues and trick with "delay playback start after seeking" also prevent freeze.
Thanks, good to know. It confirms that it's most probably a bug in the decoders. I think I should be able to workaround this problem then, on the cost of a surface copy (so ever so slightly slower performance).

does madvr support numpad??
Yes. E.g. "Ctrl+Alt+Numpad1".

I use my laptop (dual graphic cards - intel iGPU 3000 and ATI 6770M) as a HTPC, it connect to panny plasma ST50 via HDMI-HDMI cable. This TV is euro model and doesn't have black level control unlike NA model. I assume it's at Standard (16-235) so I set dymanic range inside Intel graphic properties to Limited (which is RGB 16-235 ??) and set both Madvr/Lav video decoder at PC level (0-255). Everything work fine but not sure if it's the best configuration for me
Changing anything makes my screen completely washed out.
My commendation would be to set your GPU to 0-255 and then let madVR do the conversion to 16-235. That makes sense only if you're only connecting your laptop to your Plasma to play video with madVR. If you only want to look at photos, use the PC for games and other stuff, then your current setup makes more sense, although it might introduce some banding.

What is quite funny - AVI infoframe provide required information that source output video with Full or Limited Quantization Range and customer shall be not even bothered for such problem - however drivers are written sometimes by people without any HW experience - then you have problem and real headache...
I think NVidia has a control panel option which might set/switch this information in the AVI infoframe, totally independent of what range *really* is sent, but I'm not 100% sure.

Difference between DVI and HDMi is much bigger than only connector but this is irrelevant for this problem.

excerpt from HDMI specification:
"6.6
Video Quantization Ranges
Black and white levels for video components shall be either “Full Range” or “Limited Range.” YCBCR components shall always be Limited Range while RGB components may be either Full Range or Limited Range. While using RGB, Limited Range shall be used for all video formats defined in CEA-861-D, with the exception of VGA (640x480) format, which requires Full Range."
Well, the HDMI spec may be saying that, but that doesn't mean this is true in real life at all. For example, I don't think the GPU can know for sure whether the connected display is truely a HDMI display, or whether an active or passive HDMI->DVI converter is involved anywhere. So the GPU can't know for sure whether it should send Full Range or Limited Range. Furthermore, AFAIK, both the PS3 and the Xbox have settings to switch RGB output between Full Range and Limited Range. And many display have matching input options, too. So the GPU can only guess which mode the display is currently set to. Finally, CEA-861-D defines only a handful of specific modes, IIRC. Now what happens if you take a CEA-861-D mode, and just change the pixel clock slightly? Is it then still considered a CEA-861-D mode? Or is it then a non-CEA-861-D mode?

I strongly believe that the GPUs should offer an option to let the user choose whether to output Limited or Full Range. AMD has such an option. Intel, too, I think, although I've been told that the Intel option doesn't always work as expected (it seems to be reversed or something like that). Only NVidia doesn't offer this functionality. But at least there's a registry hack available to make NVidia output Limited Range RGB over HDMI.

[6233638]

excerpt from HDMI specification:
"6.6
Video Quantization Ranges
Black and white levels for video components shall be either “Full Range” or “Limited Range.”
YCBCR components shall always be Limited Range while RGB components may be either Full
Range or Limited Range. While using RGB, Limited Range shall be used for all video formats
defined in CEA-861-D, with the exception of VGA (640x480) format, which requires Full Range."

This is quite straightforward definition or i misunderstood meaning of the word "shall"Who cares about the spec? What matters is what manufacturers are using.

The majority of new displays now support Full Range over HDMI, and some TVs like my Sony sets, even send the correct information to a PC to enable full range support without needing to change anything. (no driver/registry editing required here, it outputs 0-255 over HDMI automatically)

[nevcairiel]

Thanks, good to know. It confirms that it's most probably a bug in the decoders. I think I should be able to workaround this problem then, on the cost of a surface copy (so ever so slightly slower performance).

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.

[ThurstonX]

I'll throw in my anecdotal 2 cents.

I recently got an LED LG. I'd been running my Radeon HD 5670 with YCbCr 4:4:4 connected to an old LCD LG. madVR was set to defaults (except scaling). With the new TV, colors were horribly washed out watching US cable TV (Ceton InfiniTV 4, Windows Media Center).

I then set the 5760 to use Full RGB and TV viewing improved greatly. But when I played a few videos via MPC-HC, blacks were crushed. I poked around madVR, deleted the display device that was installed with it(?), and set the LG to "expects TV levels (16-235)" et voila! AVIs, mkvs, etc., all looked much better. The effect was similar to setting the LG's Black Level to High (which normally washes them out). But that's a PITA, as it has to be reset to Low for TV viewing.

So, in short, I love madVR, esp. running Jinc 3-taps with AR for chroma and image (software decoding in LAV via a Core i5) :D

[fallengt]

My commendation would be to set your GPU to 0-255 and then let madVR do the conversion to 16-235. That makes sense only if you're only connecting your laptop to your Plasma to play video with madVR. If you only want to look at photos, use the PC for games and other stuff, then your current setup makes more sense, although it might introduce some banding.



Banding is always an issue with plasma, manufacters use dithering to avoid it. I don't notice any banding/dithering on my set unless stay very close to it.

But I'll try your method to see any different anyway. Thanks

[DragonQ]

You would certainly see a change if you were looking at a the proper test pattern.
Nope. :)

[leeperry]

@leeperry with support for PS in Madvr!
Gotcha! And it also supports "=" for frame rate and movie dimensions automatic profiles conditions so my evil plan is bound to become reality http://forum-images.hardware.fr/images/perso/3/kazama.gif

There's only very slight issue, though...it's that post-scaling PS scripts seem to be processed pre-, that's build 34665 with EVR CP: http://thumbnails104.imagebam.com/22527/a518a4225269596.jpg (http://www.imagebam.com/image/a518a4225269596)

and now 34821, also with EVR CP: http://thumbnails101.imagebam.com/22527/7c8097225269598.jpg (http://www.imagebam.com/image/7c8097225269598)

same goes with mVR, but I've notified them about the issue and I'm not entirely sure whether gamut mapping should be processed before or after scaling.......yesgrey told me ages ago that it would be preferable to work on the right colors ASAP but madshi seemed to disagree, and I would guess that in 32fp/16int, it prolly wouldn't matter IRL anyway :o

JanWillem isn't very clear about what scripts would be better used pre- or post- either, so that doesn't really help.

PS: they've acknowledged the bug in PotP and it will be fixed http://forum.slysoft.com/images/smilies/agreed.gif

PPS: if you want the script to be used in PS 3.0, you need to add this on the very top of it:
// script=ps_3_0

[orangedude]

Hi,

Not sure if this is the right place to post this... but I'm currently trying to configure my videos to playback using madVR.

I'm using LAV splitters. I've tried both PotPlayer and MPC. Basically, I can select madVR as the video renderer and play the video with it in both players, but the madVR icon never appears in the taskbar during playback, thus I'm not able to configure any of the madVR settings. The default appears washed out and lacks processing.

My OS is Windows 8 Pro.

Any ideas about how to fix this?

Thanks!

[DragonQ]

Hi,

Not sure if this is the right place to post this... but I'm currently trying to configure my videos to playback using madVR.

I'm using LAV splitters. I've tried both PotPlayer and MPC. Basically, I can select madVR as the video renderer and play the video with it in both players, but the madVR icon never appears in the taskbar during playback, thus I'm not able to configure any of the madVR settings. The default appears washed out and lacks processing.

My OS is Windows 8 Pro.

Any ideas about how to fix this?

Thanks!

In MPC-HC: Play -> Filters -> MadVR -> Edit Settings (or Show Tray Icon).

[orangedude]

In MPC-HC: Play -> Filters -> MadVR -> Edit Settings (or Show Tray Icon).
Oh, that seemed to work in MPC-HC, but still not in PotPlayer for some reason. Could it have anything to do with the fact that I'm using the x64 version of PotPlayer?