madVR - high quality video renderer (GPU assisted)

[nand chan]

Well, I would be happy if there was a new external subtitle renderer available. That would save me from writing my own. I have to say, though, if I do feel the need to write my own subtitle renderer, at some point in the future (due to lack of available alternatives), then I will definitely make it a fixed part of madVR.

Then we have the same issue of “re-implement VSFilter's bugs” vs “implement the specification accurately”, though. Doesn't libass currently follow the spec which results in “incorrect” subtitles since they're made against the quirks of VSFilter? And instead of starting from scratch, it would certainly make sense to continue development of libass instead, unless it has any immediate jarring issues I'm not aware of that would require a redesign to fix.

Ps. madshi why aren't you on IRC?

[TheShadowRunner]

0.76 corrects the OSD issues from 0.75, thanks.
I reported my findings regarding the slow ZP/seeking-freeze-bug-after-frequency-switch to Blight.
The crash in madVR.ax is now always at address 000047a0 with 0.76 (4770 with 0.74 / 47b0 with 0.75), if it gives any hints as to which part of the code doesn't interact well with ZP.
Unfortunately, no easy way to recreate the issue.
Btw, do you still plan to enhance madVR's internal frequency switcher taking media height into account?

[dansrfe]

Hi madshi,

Just wanted to make sure saving frames to image format (png/jpg) is still on your list of things to do. It's a pretty handy feature... Thanks.

[jmonier]

The comma operator in C++ just ignores the value on the left and returns the value on the right. arr[0,0] is the same as just writing arr[0].

That's actually a case where the comma is not intended to be used. The real use of the comma in C++ is to separate expressions:

x = (y = 3, y + 1)

sets y = 3 and then sets x = (y + 1). Put another way, the comma separated expressions are executed one by one and the value of x is the value of the last expression.

It actually originated in 'C' and is very useful in 'for' statements but I can see how confusing it is when coming from another language that has a totally different use for it. C and C++ are very rich languages and that's why they've been around for so long, but nobody ever said they were easy to understand.

[Budtz]

Seems for a long time there has been a small bug where madvr ether crashes or exclusivemode fails. This happens if I switch to the next file in the folder in exclusivemode, but only if I have the mouse at the bottom of the screen so the search bar is showing. If there is no search bar then it works just fine switching video files. I have a setup where I press page-up or down to switch to the next video. It is when I press these buttons, it happens.

[nand chan]

That's actually a case where the comma is not intended to be used. The real use of the comma in C++ is to separate expressions:

x = (y = 3, y + 1)

sets y = 3 and then sets x = (y + 1). Put another way, the comma separated expressions are executed one by one and the value of x is the value of the last expression.

It actually originated in 'C' and is very useful in 'for' statements but I can see how confusing it is when coming from another language that has a totally different use for it. C and C++ are very rich languages and that's why they've been around for so long, but nobody ever said they were easy to understand.

A perfect example of a completely useless, counter-intuitive, unexplained and error-prone syntax “feature” that is only useful to code golfers. This is something I'd expect to see in perl, not C++.

[Boltron]

The latest madVR has additional info with ^J. Among other things I see a "limited range (says upstream/bitstream)". Is this referring to RGB output levels 16-235 v.s. 0-255?

Also, I am in the process of doing 10 bit encoding of some of my movies. I noticed that movies I ripped with Clown_BD (uses eac3to) show "limited range (says upstream)" and once I re-encode with 10bit x264 I see "limited range (says bitstream)". If my assumption that by limited range refers to 16-235, is there a setting in the x264 encoder that will 0-255? Am I just hopelessly confused??

Can anyone please enlighten me :)

I use MPC-HC, LAV Video, madVR. LAV and madVR set to 0-255 levels.

[nand chan]

The latest madVR has additional info with ^J. Among other things I see a "limited range (says upstream/bitstream)". Is this referring to RGB output levels 16-235 v.s. 0-255?

No, it's referring to the input levels. The output levels are always what you specified for your display in the settings.

Also, I am in the process of doing 10 bit encoding of some of my movies. I noticed that movies I ripped with Clown_BD (uses eac3to) show "limited range (says upstream)" and once I re-encode with 10bit x264 I see "limited range (says bitstream)". If my assumption that by limited range refers to 16-235, is there a setting in the x264 encoder that will 0-255? Am I just hopelessly confused??

Don't worry, you generally want to encode 16-235. Also, about the “upstream” vs “bitstream” issue I'm guessing upstream means the filter guessed it, and bitstream means it's written into the file headers itself. Either that, or it's the other way around.

[Boltron]

OK, so my 10bit 16-235 encode should be fine then. It just takes soooo long and I have already done several encodes this week to work out settings, I was scared I messed up rgb range.

I'm hoping when Ivy Bridge comes along and I upgrade, x264 will be able to take advantage of QuickSync... Looking forward to watching my first 10bit encode tomorrow night.

[jmone]

Can you cross check this with a different media player? What happens if you turn Aero on/off? Currently I don't see how madVR could be responsible for this. madVR does not have any special code in it for 23.976/24.000Hz handling. It doesn't really matter to madVR whether the refresh rate is 24Hz or 240Hz. So I don't see how there could be a lipsync problem with 24Hz when there is none with higher refresh rates.
Turning Aero Off blows the present queue out by 100x times (I end up with 15 to 25ms times compared to 0.15ms) had results in lots of dropped frames with 50/60p material, though the Lip Sync looked better (but still not as good as Exclusive Mode). I'll upgraded the files in the MC plugin directory to the latest version so I'll see how that runs. The other issue I get in Windowed mode from time to time is that lots of dropped frames (very low present queues) but oddly one fix is to bring up the madVR GUI. As a last resort I'll try another player to see if that eliminates it but my HTPC is a minimal install.

About the exclusive mode problem: I'd need a way to reproduce this, without having to wait hours or even days for the problem to appear. Once it happens it tends to stay till the player is restarted. Is it possible to enable logging between plays and would this give you what you need. This is one that a few have commented on (incl nevcairiel).

FYI - Exclusive mode is my preferred mode and I was only investigating various Windowed mode setting due to the "exclusive mode failure" dropping me back to this.

[nevcairiel]

Then we have the same issue of “re-implement VSFilter's bugs” vs “implement the specification accurately”, though. Doesn't libass currently follow the spec which results in “incorrect” subtitles since they're made against the quirks of VSFilter?

There are some minor differences between the rendered output, and i'm sure there will be some OCD people that complain, but alot of cases libass tried to behave similar to VSFilter, as long as it was not 100% obvious that VSFilter was just plain wrong.

The main point is that libass is faster, and still under active development (and actually quite easy to use), so writing a sub renderer with it is just a matter of figuring out how to blend the subs on a DX surface.

Maybe i feel like venturing into that land some day when i have the "major" blockers in LAV Filters taken care of.
I like a challenge, and to learn something new, and this would fit the bill perfectly. ;)

[nand chan]

There are some minor differences between the rendered output, and i'm sure there will be some OCD people that complain, but alot of cases libass tried to behave similar to VSFilter, as long as it was not 100% obvious that VSFilter was just plain wrong.

The main point is that libass is faster, and still under active development (and actually quite easy to use), so writing a sub renderer with it is just a matter of figuring out how to blend the subs on a DX surface.

Well, the straightforward way would be to draw onto a buffer in RAM, copy that to VRAM, and do the blending on-GPU. I suppose the limiting factor here might just be available bandwidth. What would you suggest, only uploading smaller fragments (the parts you need to render?). The renderer would have to take care of positioning etc that way but it would probably be much more efficient.

[nevcairiel]

I have not all that much experience with Direct3D stuff, thats the real problem there. :)
Its probably more efficient to track a "dirty region" and only copy that over to a texture for blending. Positioning shouldn't be that problematic, thats good old math.

[nand chan]

I have not all that much experience with Direct3D stuff, thats the real problem there. :)
Its probably more efficient to track a "dirty region" and only copy that over to a texture for blending. Positioning shouldn't be that problematic, thats good old math.

The problem would be having every renderer respect it ;)

Do you know if libass is capable of using an alpha channel whatsoever?

[nevcairiel]

The way the subtitle interface works right now is simple. You get the surface with the video image from the renderer, and you paint your subtitles on there. The renderer doesn't have to do anything.

libass is a rendering library, it just provides you with the info where to paint which pixel in which RGBA color (including alpha).

Edit:
http://code.google.com/p/libass/source/browse/libass/ass.h

See the ASS_Image structure. From the looks of it, i assume you get one structure for every color required, equiped with a 1bpp alpha map specifying where to paint the pixel in the specified RGBA color, and where not.

[nand chan]

The way the subtitle interface works right now is simple. You get the surface with the video image from the renderer, and you paint your subtitles on there. The renderer doesn't have to do anything.

libass is a rendering library, it just provides you with the info where to paint which pixel in which RGBA color (including alpha).

Edit:
http://code.google.com/p/libass/source/browse/libass/ass.h

See the ASS_Image structure. From the looks of it, i assume you get one structure for every color required, equiped with a 1bpp alpha map specifying where to pain the pixel in the specified RGBA color, and where not.

Oh, I see what you mean now. Basically passing the entire subtitle image in one go, then detecting the dirty regions (or using the included 1bpp map) inside the renderer itself, just to save upload bandwidth. I thought what you were suggesting was basically rewriting libass to output a list of small textures and their positions directly.

Yeah, that way it should work fine with all renderers.

[6233638]

That's like saying you want to master audio in the next room. Simply silly/stupid, no offense intended. You *NEVER* want to tweak the no-dither results, since those results will be wrong. Tweaking those until they're right will end up with a LUT that's completely off. You're shooting yourself in the foot. And if you calibrate against these faulty procedures, of course madVR is going to give you undesirable results.I took the time to measure the results I get with madVR and the built-in yCMS calibration, when giving it accurate data. (no hand-tweaking to try and control the results)

On the left are the automatically calculated madVR/yCMS results, on the right are hand-tweaked values (outside of madVR) to show what the display is capable of.
http://img638.imageshack.us/img638/7114/madvr.th.png (http://img638.imageshack.us/img638/7114/madvr.png) http://img847.imageshack.us/img847/3586/35hhl.th.png (http://img847.imageshack.us/img847/3586/35hhl.png)

http://img5.imageshack.us/img5/1251/madcms.th.png (http://img5.imageshack.us/img5/1251/madcms.png) http://img20.imageshack.us/img20/8852/bjeo5.th.png (http://img20.imageshack.us/img20/8852/bjeo5.png)

Pay particular attention to the scale of the error charts for gamut. The only errors that remain in the hand-tweaked data are caused by the display's limited gamut.

It should be possible to get these results, the tools just don't seem to be there for it.


10, 20 points? ArgyllCMS which you've previously denounced can calibrate using up to 2400 points. And yes, these are better calibrated than your rounded “hand-crafted” LUT.I disagree. 2400 points is too much data and you will actually be introducing errors into the LUT as the meter & display drift over the length of time it takes to make that many measurements with consumer-grade equipment. (even the higher-end stuff)

It's not that I am against using interpolated data in LUTs, but I want to have proper control over at least some of the points to shape the results.

Would you mind testing multiple scaling algorithms to see how much each of them ring when in linear light? I'm guessing Lanczos might be too extreme in this mode. What about Catmull-Rom and friends?Lanczos and Spline are out, far too much ringing even at their lowest settings. (interestingly, spline seemed worse)
Personally, I have never liked the results from either Mitchell-Netravali or Catmull-Rom. Initially, MN was my choice for luma upscaling when I first used madVR, but I soon found that there was too much aliasing being introduced into the image.
SoftCubic is just too soft for downscaling, which leaves Bicubic.

I haven't done extensive testing, but I could see almost no difference whatsoever between Bicubic 50 and 75 with the material I tried.

Bicubic 50 in linear light, didn't seem too different from Lanczos 3 without it, except it is now gamma-correct, so that would be my choice for now.


Haven't had any time to test linear light upscaling yet, so it's still on SoftCubic 70 for now.

[nand chan]

I took the time to measure the results I get with madVR and the built-in yCMS calibration, when giving it accurate data. (no hand-tweaking to try and control the results)

On the left are the automatically calculated madVR/yCMS results, on the right are hand-tweaked values (outside of madVR) to show what the display is capable of.
http://img638.imageshack.us/img638/7114/madvr.th.png (http://img638.imageshack.us/img638/7114/madvr.png) http://img847.imageshack.us/img847/3586/35hhl.th.png (http://img847.imageshack.us/img847/3586/35hhl.png)

http://img5.imageshack.us/img5/1251/madcms.th.png (http://img5.imageshack.us/img5/1251/madcms.png) http://img20.imageshack.us/img20/8852/bjeo5.th.png (http://img20.imageshack.us/img20/8852/bjeo5.png)

Pay particular attention to the scale of the error charts for gamut. The only errors that remain in the hand-tweaked data are caused by the display's limited gamut.

This seems to be a result of yCMS inaccuracies, not the methodology. I assume you recorded these values through madVR itself? (Ie. not using some bastardized test program which doesn't dither)

It should be possible to get these results, the tools just don't seem to be there for it.

I disagree. 2400 points is too much data and you will actually be introducing errors into the LUT as the meter & display drift over the length of time it takes to make that many measurements with consumer-grade equipment. (even the higher-end stuff)

I said up to 2400, and ArgyllCMS even includes drift compensation support (by monitoring how much the known values change).

It's not that I am against using interpolated data in LUTs, but I want to have proper control over at least some of the points to shape the results.

Then again, use ArgyllCMS. Or create your own table and interpolate it, it doesn't really matter.

Lanczos and Spline are out, far too much ringing even at their lowest settings. (interestingly, spline seemed worse)
Personally, I have never liked the results from either Mitchell-Netravali or Catmull-Rom. Initially, MN was my choice for luma upscaling when I first used madVR, but I soon found that there was too much aliasing being introduced into the image.
SoftCubic is just too soft for downscaling, which leaves Bicubic.

I haven't done extensive testing, but I could see almost no difference whatsoever between Bicubic 50 and 75 with the material I tried.

Bicubic 50 in linear light, didn't seem too different from Lanczos 3 without it, except it is now gamma-correct, so that would be my choice for now.


Haven't had any time to test linear light upscaling yet, so it's still on SoftCubic 70 for now.

I don't think downscaling is actually important, unless you have some magical access to 4k masters. Blu-ray resolution is only 1920×1080 which basically every display encompasses by now.

[6233638]

This seems to be a result of yCMS inaccuracies, not the methodology. I assume you recorded these values through madVR itself? (Ie. not using some bastardized test program which doesn't dither)Yes, through madVR.

I don't think downscaling is actually important, unless you have some magical access to 4k masters. Blu-ray resolution is only 1920×1080 which basically every display encompasses by now.Lots of people are still using 720p projectors, Sony are just about to launch this (http://store.sony.com/webapp/wcs/stores/servlet/ProductDisplay?catalogId=10551&storeId=10151&langId=-1&partNumber=HMZT1&SR=sony_search_seo&SQS=hmz%20t1) in a few weeks, which is 720p native. It's still relevant.

I can't imagine the upscaling results being too different from downscaling, though I'm curious to see if there's the same amount of ringing introduced with some algorithms. (that said, most already introduce a lot of ringing as it is)

[6233638]

OK, I've done some preliminary testing with linear light upscaling.

The short answer is that the only settings it should be used with are SoftCubic 80/100. (possibly only 100)
It does really bad things with everything else.

Here's a very quick upscaling comparison taken from a low resolution, highly compressed video upscaled considerably. (one of my standard tests)

Lanczos 3:
http://img17.imageshack.us/img17/7928/lanczos3.th.png (http://img17.imageshack.us/img17/7928/lanczos3.png)

SoftCubic 70 (my current preferred choice)
http://img600.imageshack.us/img600/8120/softcubic70.th.png (http://img600.imageshack.us/img600/8120/softcubic70.png)

SoftCubic 70 with linear light scaling enabled:
http://img819.imageshack.us/img819/3681/softcubic70l.th.png (http://img819.imageshack.us/img819/3681/softcubic70l.png)


I'd go as far as saying that the option probably shouldn't even be available with anything other than the higher levels of SoftCubic when upscaling, and disabled on Lanczos/Spline when downscaling.


I've yet to test it on DVDs or 720p videos, but I doubt that the results will change.


And as a side-note, it would be really nice if selecting madVR from the filters list brought up the preferences right away as it used to do, rather than it being a two-step process. It really slows things down when trying to do a comparison like this.

[pirlouy]

Maybe i feel like venturing into that land some day when i have the "major" blockers in LAV Filters taken care of.
I like a challenge, and to learn something new, and this would fit the bill perfectly. ;)
Start today please ! :D

[nand chan]

I think SoftCubic is just too blurry to use properly. When you watch a lot of Anime, the sharpness matters 100x as much. The blurring makes anime basically unwatchable.

[Budtz]

I have copied settings from hdtvtest. These are calibrated settings. Witch options should i choose in madvr when i have a calibrated set?

[markanini]

'Scale in linear light' looks great on the right sources, bringing out faint details. Oversharpened sources might need a softer kernel though.

[madshi]

Ps. madshi why aren't you on IRC?
Why would I be?

Unfortunately, no easy way to recreate the issue.
That's too bad, it makes it very hard for me to fix the problem.

Btw, do you still plan to enhance madVR's internal frequency switcher taking media height into account?
Remind me, what was this about?

Just wanted to make sure saving frames to image format (png/jpg) is still on your list of things to do. It's a pretty handy feature... Thanks.
Sure, it's somewhere on my list.

Seems for a long time there has been a small bug where madvr ether crashes or exclusivemode fails. This happens if I switch to the next file in the folder in exclusivemode, but only if I have the mouse at the bottom of the screen so the search bar is showing. If there is no search bar then it works just fine switching video files. I have a setup where I press page-up or down to switch to the next video. It is when I press these buttons, it happens.
Which media player are we talking about? Can anybody else reproduce this?

The latest madVR has additional info with ^J. Among other things I see a "limited range (says upstream/bitstream)". Is this referring to RGB output levels 16-235 v.s. 0-255?
No, it's referring to the input levels. The output levels are always what you specified for your display in the settings.
Correct.

about the “upstream” vs “bitstream” issue I'm guessing upstream means the filter guessed it, and bitstream means it's written into the file headers itself. Either that, or it's the other way around.
Oh, I should have explained that. There are 3 new items in the Ctrl+J OSD:

(1) "matrix" - this is the source's decoding matrix
(2) "primaries" - this is the source's gamut/primaries
(3) "full/limited range" - this is the source's range

madVR tries to autodetect the correct values. The OSD shows in brackets how madVR autodetected the specific value. There are various different ways that madVR can autodetect these things (sorted by priority):

(a) "says ffdshow" - madVR has detected that ffdshow is sending RGB and madVR has found out which range/levels ffdshow is sending
(b) "says upstream" - the upstream filter has officially informed madVR
(c) "says bitstream" - madVR has read the info from the compressed video bitstream (h264, MPEG2 or VC-1)
(d) "best guess" - madVR has guessed, based on resolution (matrix/primaries) or color space (range)

Once it happens it tends to stay till the player is restarted. Is it possible to enable logging between plays and would this give you what you need. This is one that a few have commented on (incl nevcairiel).
I don't really know if I can fix this without being able to reliably reproduce it.

The way the subtitle interface works right now is simple. You get the surface with the video image from the renderer, and you paint your subtitles on there. The renderer doesn't have to do anything.

libass is a rendering library, it just provides you with the info where to paint which pixel in which RGBA color (including alpha).
I'm wondering right now, if you did create a new external subtitle renderer, how much of your development time would go into:

(1) creating and maintaining the DShow framework
(2) finding the best way to forward the subtitles to the renderers
(3) actual work on implementing libass etc

I'm thinking right now that you'd probably spend 90%+ of your time on (1) and (2), would you agree with that? If so, I'm wondering whether it really makes sense. If I would implement libass directly in madVR (without support for other renderers, of course), I could probably get along with 20% of the time you'd need to invest. Or do you think my estimates are off?

I took the time to measure the results I get with madVR and the built-in yCMS calibration, when giving it accurate data. (no hand-tweaking to try and control the results)

On the left are the automatically calculated madVR/yCMS results, on the right are hand-tweaked values (outside of madVR) to show what the display is capable of.
Ouch. I would say that yesgrey has some work to do to get this right. I'm convinced that this is a problem with yCMS, though, and not a problem with the 3dlut technique.

Have you tried nand chan's tools? Doesn't he have a "competeting" solution to yCMS? Maybe his tools create better 3dlut files?

I'd go as far as saying that the option probably shouldn't even be available with anything other than the higher levels of SoftCubic when upscaling, and disabled on Lanczos/Spline when downscaling.
Yeah, I have my doubts about the use of linear light scaling, too. It's just that in another thread a user claimed that I would be taking shortcuts because I'm not doing linear light scaling. So I added it now, but I don't think it's all that useful, except maybe for downscaling. That said, maybe it will be more useful when I implement some better scaling algorithms.

And as a side-note, it would be really nice if selecting madVR from the filters list brought up the preferences right away as it used to do, rather than it being a two-step process. It really slows things down when trying to do a comparison like this.
That is technically not possible, because the new madVR settings dialog is not created by madVR.ax, anymore, but by the external madHcCtrl.exe process. That said, I'm usually changing settings through the madVR tray icon menu. That works faster for me.

[Budtz]

The Mediaplayer i use is MPC-HC.

[nevcairiel]

I'm wondering right now, if you did create a new external subtitle renderer, how much of your development time would go into:

(1) creating and maintaining the DShow framework
(2) finding the best way to forward the subtitles to the renderers
(3) actual work on implementing libass etc

I'm thinking right now that you'd probably spend 90%+ of your time on (1) and (2), would you agree with that? If so, I'm wondering whether it really makes sense. If I would implement libass directly in madVR (without support for other renderers, of course), I could probably get along with 20% of the time you'd need to invest. Or do you think my estimates are off?

1) will certainly require some work, but i don't think its that much, since i already have some good basis and experience to start with from my other decoders.
2) Is something actually wrong with the subtitle interface you use for MPC-HC? I thought all the issues we are having were due to bugs in the sub renderer, not in the interface.
3) Will certainly be fun! ;)

Like mentioned before, one blocking factor for me is the time spend trying to figure out Direct3D, as i haven't done much with it.
I would probably add it to 3), but i would take longer with it then you would, for example, as you have the D3D experience.

I just think that the benefit of being able to use it with other renderers (and possibly without renderer support as a last resort, painting on the image, or for transcoding) outweights the extra efforts in this case, because the only alternative is VSFilter or ffdshow (which really are based on the same code), and those projects are really long dead, and unlikely to receive much love.

[nevcairiel]

I don't really know if I can fix this without being able to reliably reproduce it.


This is Re: "Exclusive Mode Failed"

I can't "reliably" reproduce it, but i can reproduce it.
What i usually do:

Watch a file, let it run to the end (or seek close to the end). MPC-HC goes to Window mode.
I click my mouse thumb button, which goes to the next file in the folder, playback resumes.
Go back to FSE mode.

Now repeat that procedure above until it fails. *Maybe* there are some other circumstances, i'll try some things and see if i can make it break more reliably.

[madshi]

2) Is something actually wrong with the subtitle interface you use for MPC-HC? I thought all the issues we are having were due to bugs in the sub renderer, not in the interface.
Well, the interface is working reasonably well, but there are a couple of things I don't like:

(1) the D3D work is done by the subtitle renderer, I'd prefer to get simple bitmaps with an alpha channel and do the drawing myself; e.g. I would run into big trouble if I wanted to use a full D3D11 rendering path, that simply wouldn't work with the current subtitle interface
(2) alpha blending on 16bit textures doesn't work with older GPUs, making it hard for me to have the subtitles run through 3dluts
(3) I'm not sure the current interface will work for 3D content

I think if you create an external filter, it would be better to create a new interface, which would just forward the subtitles in bitmap form with an alpha channel. That way you also wouldn't have to do any D3D stuff. At least not for madVR.

*Maybe* there are some other circumstances, i'll try some things and see if i can make it break more reliably.
That would be great.

[nevcairiel]

I think if you create an external filter, it would be better to create a new interface, which would just forward the subtitles in bitmap form with an alpha channel. That way you also wouldn't have to do any D3D stuff. At least not for madVR.

I suppose your reasoning makes sense. I would just create a RGBA image in subtitle rendering resolution, and let you deal with scaling and alpha blending.
I'll think some about it, but i don't have any immediate plans eitherway.

[madshi]

I would just create a RGBA image in subtitle rendering resolution, and let you deal with scaling and alpha blending.
Alpha blending: Yes. Scaling? Not sure. If you render in SD and ask me to scale to HD then the subtitles will look very blurry and low-res. It'd be better if the subtitles were rendered at target resolution. Then scaling should not be necessary.

[nevcairiel]

For performance reasons people might want to render in lower resolutions, or maybe a bitmap subtitle just is lower resolution. I can scale it as well, but it would be equally blurry. :)

[HeadlessCow]

Ouch. How can a compiler treat arr[0,0] as arr[0]? That doesn't make *any* sense to me whatsoever.


It's used for putting two statements into a spot that can only syntactically hold one.

For loops are the only place I ever see it used.

for(int i = 0, j = 10; i < 10; i++, j--) {
...
}

[pirlouy]

Why would you want to scale subtitles ?
People choose something like "Arial, 20", then you display the subtitle always in size "20", you put it in an image for madVR, and then no blur.

But I guess there's some stuff I don't understand at all, then sorry. :D

[nand chan]

Alpha blending: Yes. Scaling? Not sure. If you render in SD and ask me to scale to HD then the subtitles will look very blurry and low-res. It'd be better if the subtitles were rendered at target resolution. Then scaling should not be necessary.

Three factors here:

1. Performance as mentioned
2. 3D transformations and such will simply look wrong if not rendered at the correct resolution, or so I've been told
3. In some cases, blurry subtitles might be desired because they would fit into the scenery better (eg. softsubbed signs), whereas a noticeably too-HD sign would stand out too much.

Why would I be?

It makes communication like this a great deal faster when all involved parties are present.

Have you tried nand chan's tools? Doesn't he have a "competeting" solution to yCMS? Maybe his tools create better 3dlut files?

Unfortunately my tools are not capable of calibration, not by themselves nor do I have any plans to include such functionality. I rely on existing tools such as LittleCMS, yCMS, ArgyllCMS and ICC profiles to generate a 3dlut. It's just a “unification” engine, so to say - it unifies the color pipeline into a well-defined 64-bit space and allows you to mix any sorts of different stuff (.cal files, .3dluts at every bit depth imaginable, .icc profiles, custom logic) into the same pipeline then output that.

It is not intended for nor capable of any form of measurement-based display calibration.

[HeadlessCow]

Why would you want to scale subtitles ?
People choose something like "Arial, 20", then you display the subtitle always in size "20", you put it in an image for madVR, and then no blur.

But I guess there's some stuff I don't understand at all, then sorry. :D

Arial, 20 on a windowed 640x360 image might look fine, but once you upscale it (like going to full screen) you now have blurry subtitles that are 2 inches tall.

[madshi]

For performance reasons people might want to render in lower resolutions, or maybe a bitmap subtitle just is lower resolution. I can scale it as well, but it would be equally blurry. :)
True.

Unfortunately my tools are not capable of calibration, not by themselves nor do I have any plans to include such functionality. I rely on existing tools such as LittleCMS, yCMS, ArgyllCMS and ICC profiles to generate a 3dlut. It's just a “unification” engine, so to say - it unifies the color pipeline into a well-defined 64-bit space and allows you to mix any sorts of different stuff (.cal files, .3dluts at every bit depth imaginable, .icc profiles, custom logic) into the same pipeline then output that.

It is not intended for nor capable of any form of measurement-based display calibration.
I thought your tools could be used to convert ICC profiles to 3dlut files? And I thought you implemented that with LittleCMS and not with yCMS. Guess I was wrong about that? So your something -> 3dlut conversions always end up using yCMS?

[pirlouy]

Arial, 20 on a windowed 640x360 image might look fine, but once you upscale it (like going to full screen) you now have blurry subtitles that are 2 inches tall.
Why upscale it ?
Let it at 20 in window mode, and 20 in Full Screen.

And if it's possible for the subtitle renderer to know if we're in Full Screen, then we can choose a size for window mode, and a size for Full Screen; like this, no upscale/downscale.

Any upscale/downscale will be uglier than a defined size.

[nand chan]

I thought your tools could be used to convert ICC profiles to 3dlut files? And I thought you implemented that with LittleCMS and not with yCMS. Guess I was wrong about that? So your something -> 3dlut conversions always end up using yCMS?

You're misunderstanding. The ICC profile in question here already exists, thus it's technically not a device calibration done by any part of my tools. You are correct, I use LittleCMS and not yCMS (yCMS is only used for generating .3dluts from .ti3 files since I haven't added Argyll support yet, but if anybody would be interested in continued development of the project that would be near the top of my todo list).

They can be used to convert ICC profiles to .3dlut files, but in this case, he doesn't even have an ICC profile - he's looking for software that will generate an ICC profile (either device or link) to his requirements. My software is not capable of generating ICC profiles whatsoever, just using them.

[TheShadowRunner]

That's too bad, it makes it very hard for me to fix the problem.
Yes sorry, wish I could make it easier for you ^^;
So the address reported when the crash occurs doesn't help at all I guess. :(
I think for now let's wait for Blight's view on the issue, from my testing the bug is due to ZP displaying its own OSD/Control bar while a frequency switch occurs. If I force ZP to never show OSD/Control bar, the bug never shows up..
What led me to believe it was a madVR issue is that it doesn't happen with the other renderers. Tough one!

Remind me, what was this about?
Simply to make madVR's internal frequency switcher as flexible as ReClock's so it's finally possible to ditch ReClock's RunEvent (http://videoff7.free.fr/RunEvent.txt) completely (no more need to switch freq. behind madVR's back!) :)
Currently madVR's switcher only takes framerate into account. The request is about having madVR's switcher also take media height into account. You seemed to be OK with it (http://forum.doom9.org/showthread.php?p=1522628#post1522628). ^^;

A related question: madVR doesn't currently "know" which frequency is used, does it?
Because I noticed a strange thing. If in the "list all display modes madVR may switch to" I input only "720p50" (omitting purposefully 720p60), and play a 29.97fps media while on 720p60, madVR switches to 720p50!?
It seemed strange to me. Of course it doesn't happen if I input 720p60 in the list too.

[ajp_anton]

And as a side-note, it would be really nice if selecting madVR from the filters list brought up the preferences right away as it used to do, rather than it being a two-step process. It really slows things down when trying to do a comparison like this.If you mean compare different scaling algorithms, madVR's settings can be modified in real-time.
Just pause at some screen, go to the settings, change the scaling algorithm and press "apply". The paused video in the background will immediately update.

[CHEF-KOCH]

I do not know if it was already discussed, but if i start a playlist with my mpc hc (build r3788 and lower) with more than one video file (e. g. mkv) with mpc hc in fullscreen, i get problems with it. After the first video was ended and will go to the next video, windows and mpc hc hangs completly. It's completly stuck and i only can kill the task via my taskmanager. This happens only if mpc hc are in fullscreen and i have a playlist with some videos. Maybe a MPC HC problem or madVR? Or some settings wrong here. I'm under Windows 7 x64 SP1 and nvidia graphics (latest drivers).

Thanks for help.

[madshi]

You're misunderstanding. The ICC profile in question here already exists, thus it's technically not a device calibration done by any part of my tools. You are correct, I use LittleCMS and not yCMS (yCMS is only used for generating .3dluts from .ti3 files since I haven't added Argyll support yet, but if anybody would be interested in continued development of the project that would be near the top of my todo list).

They can be used to convert ICC profiles to .3dlut files, but in this case, he doesn't even have an ICC profile - he's looking for software that will generate an ICC profile (either device or link) to his requirements. My software is not capable of generating ICC profiles whatsoever, just using them.
Ok, but there is different software out there that can create ICC profiles, right? So 6233638 could use that other software to create an ICC profile for his display, then use your tools (which use LittleCMS) to convert the ICC profile to a 3dlut. This way we would bypass yCMS, which would allow us to check if the bad results 6233638 got are caused by yCMS. So which software can 6233638 use to create an ICC profile? Maybe Argyll?

Simply to make madVR's internal frequency switcher as flexible as ReClock's so it's finally possible to ditch ReClock's RunEvent (http://videoff7.free.fr/RunEvent.txt) completely (no more need to switch freq. behind madVR's back!) :)
Currently madVR's switcher only takes framerate into account. The request is about having madVR's switcher also take media height into account. You seemed to be OK with it (http://forum.doom9.org/showthread.php?p=1522628#post1522628). ^^;
So I already commented on your request some time ago. Why then do you ask me the same thing again now?? Please don't do that. I have better things to do than commenting on each feature request multiple times. One time should do.

A related question: madVR doesn't currently "know" which frequency is used, does it?
Because I noticed a strange thing. If in the "list all display modes madVR may switch to" I input only "720p50" (omitting purposefully 720p60), and play a 29.97fps media while on 720p60, madVR switches to 720p50!?
It seemed strange to me. Of course it doesn't happen if I input 720p60 in the list too.
If you only have 720p50 in the mode switch edit box, then madVR will *always* switch to that mode. That's how it works by design.

I do not know if it was already discussed, but if i start a playlist with my mpc hc (build r3788 and lower) with more than one video file (e. g. mkv) with mpc hc in fullscreen, i get problems with it. After the first video was ended and will go to the next video, windows and mpc hc hangs completly. It's completly stuck and i only can kill the task via my taskmanager. This happens only if mpc hc are in fullscreen and i have a playlist with some videos. Maybe a MPC HC problem or madVR? Or some settings wrong here. I'm under Windows 7 x64 SP1 and nvidia graphics (latest drivers).
Are you using external refresh rate switching (e.g. in Reclock)?

Can anybody reproduce this?

[Hypernova]

Can anybody reproduce this?

Works fine on my setup.

On a not really related note, I'm on Windows Developer Preview (8) right now and looks like madVR will never switch to exclusive mode. Probably because of the Metro layer or something. I'm not asking for any fix here, just FYI.

[CHEF-KOCH]

Thanks for help madshi, but i'm not using Reclock.
If you need samples i can upload some.

[Peuj]

Hi,

I notice a lot of "dropped frames" from Ctrl-J stats.
It happens with all kind of videos.
I use the default madVR settings + the display switch mode to be on the "correct" refresh rate.

With an avi 608x306 I have:
My CPU is around 40%.
My GPU is around 40% with 212 MB used.
Dropped frame at the end: 58000
Delayed frames at the end: 469


With which parameters I shoud play to avoid too much dropped frames?

Thanks

madVR v0.76
Player: PotPlayer
GPU: nvidia 8600M GT with driver 280.26
OS: Vista
Aero: on
1920x1080 24Hz (TV)
Dual monitor PC/TV

[nevcairiel]

With that high amount of dropped frames, i would think that maybe the video you were watching was more then 24 fps, maybe 30?

[vivan]

2. 3D transformations and such will simply look wrong if not rendered at the correct resolution, or so I've been told
3. In some cases, blurry subtitles might be desired because they would fit into the scenery better (eg. softsubbed signs), whereas a noticeably too-HD sign would stand out too much.2. You can recalculate new values basing on resolution.
3. That's why there are blur functions \be and \blur.
So the only reason - perfomance. But it also not such big problem, since only really heavy subs require something more that just modern dualcore.

[nand chan]

2. You can recalculate new values basing on resolution.
3. That's why there are blur functions \be and \blur.
So the only reason - perfomance. But it also not such big problem, since only really heavy subs require something more that just modern dualcore.

2. So I've claimed as well but apparently nobody has the necessary mathematics know-how required to adapt the transformation matrix to the new resolution, *and* enough knowledge of C/C++ to patch it in

3. Is not a valid argument since that would be modifying the source file itself. I would certainly not want to demux all of my .mkv files, open the sub file, find all softsubbed signs, add \blur tags to them, and remux it back.

Ok, but there is different software out there that can create ICC profiles, right? So 6233638 could use that other software to create an ICC profile for his display, then use your tools (which use LittleCMS) to convert the ICC profile to a 3dlut. This way we would bypass yCMS, which would allow us to check if the bad results 6233638 got are caused by yCMS. So which software can 6233638 use to create an ICC profile? Maybe Argyll?

Yes, for example. That's what I recommended him as well, using Argyll with his raw device measurements to generate the device profile. He can hand-tweak those as well.

[Peuj]

With that high amount of dropped frames, i would think that maybe the video you were watching was more then 24 fps, maybe 30?

The video is a 25 fps and the refresh rate was 50Hz. Does it explain the dropped frames?