[madshi]

Originally Posted by nand chan

Ps. madshi why aren't you on IRC?

Why would I be?

Originally Posted by TheShadowRunner

Unfortunately, no easy way to recreate the issue.

That's too bad, it makes it very hard for me to fix the problem.

Originally Posted by TheShadowRunner

Btw, do you still plan to enhance madVR's internal frequency switcher taking media height into account?

Remind me, what was this about?

Originally Posted by dansrfe

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.

Originally Posted by 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.

Which media player are we talking about? Can anybody else reproduce this?

Originally Posted by 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?

Originally Posted by nand chan

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

Correct.

Originally Posted by nand chan

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)

Originally Posted by jmone

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.

Originally Posted by 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).

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?

Originally Posted by 6233638

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?

Originally Posted by 6233638

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.

Originally Posted by 6233638

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.