madVR - high quality video renderer (GPU assisted)

[Gleb Egorych]

When I try to run Zoom Player 8 RC3 with madVR 0.69 as a video renderer ZP says there is an error in ntdll.dll. 0.67 is OK.

[Luv]

Surprise,surprise,Powerdvd h.264 (While coreavc 2.0 does not) and mpeg2 decoders do convert from 4:2.0 to 4:2:2 ! The wmp vc-1 decoder is fine.
Now,how do I get to use the embedded madvr decoders with Zoomplayer,please ?

[alph@]

madVR is giving black screen if color/gamma correction is enabled with RGB32 video input.
yes, me too, core avc rgb 32 out ffdshow rgb 32 black screen, solved by passing the output in yv12.

[Blight]

v0.69 bug report:
Instantly seeking after the graph is built (used by the 'automatically restore last media position on replay' function) causes a crash:

Access violation at address 77C52D37 in module 'ntdll.dll'. Read of address 05E23EB4.

Here's the MadVR debug log file:
http://t.inmatrix.com/madVRlog.zip

It doesn't happen 100% of the time. For example, it happens with (multiple) MP4 files split by the MPC MP4 splitter and FLV files split with either the LAV or MPC Splitters.
All contain H264 video, which is decoded by FFDShow (latest build).
However, no crashes when playing+seek a Matroska MKV file, split with LAV Splitter containing H264 video or AVI files with microsoft splitter and XVID video.

Switching the video renderer to EVR eliminates the crash.

[JarrettH]

Bad news is : it won't read DVDs. I didn't touch anything on my filters settings, I uninstalled madVR 0.66, intalled 0.68, kept all settings to default and when trying to launch a DVD it is set to pause and can't be played. I reverted back to 0.66 and DVDs launch fine.

See that's my problem too!!! It goes straight to set to pause with a blank screen. (Your solution may have worked so far Wile.)

[JarrettH]

YESSSSSSSS went back to 0.66 and DVDs work :devil::devil::devil:

Seek bar does not work when put in full screen mode fyi

Using LAV Splitter, LAV Audio, and Microsoft DTV-DVD

[Luv]

Blight,since you are there,would you mind explaining me what I have to do to use madVR internal decoders (I have ZP 5.02)? Thanks.

[italospain]

Surprise,surprise,Powerdvd h.264 (While coreavc 2.0 does not) and mpeg2 decoders do convert from 4:2.0 to 4:2:2 ! The wmp vc-1 decoder is fine.
Now,how do I get to use the embedded madvr decoders with Zoomplayer,please ?

Set madVR as h264/mpeg2/vc1 decoder in smart play

[leeperry]

:thanks: for the new version!

ffdshow RGB output levels are now automatically detected and handled properly
I've run a comparison between 0.67/0.69/HR in 0-255 RGB32/YV12: http://www.mediafire.com/?5zw7z5ra6gzs6px

<PS: It's 0.67, not 0.66!>

AFAIK HR speaks the truth, 0.67 is wrong in YV12(but OK in RGB32) and 0.69 is fubar :o

if you could also fix the levels/gamma in YV12, I'd greatly appreciate it....as I'm forced to use RGB32 atm to get the right colors when feeding PC levels content.

[Luv]

Set madVR as h264/mpeg2/vc1 decoder in smart play

Thanks for your answer but I can't find them in the list plus the extension is ".mvr".What should I do from there ?

[madshi]

Thanks Madshi for your response. But still what is the need in internal decoder if we use ffdshow or other decoders :\ I am confused .
I second that
I have my reasons. But it's very simple for you: If you don't see a need for the internal decoders, then don't use them. No harm done.

madVR is giving black screen if color/gamma correction is enabled with RGB32 video input.
yes, me too, core avc rgb 32 out ffdshow rgb 32 black screen, solved by passing the output in yv12.
I can reproduce that, will be fixed in the next build.

Old Bug: The frozen black screen when using the refresh rate changer and the internal decoders still exists in 0.69.
Will look into that (really).

Other: madVR [benchmark] is still 0.67.
Yeah, planned to update it, but found no time.

Status Update: It appears the MPC-HC internal subtitle renderer is what is causing the madVR render queue (upload queue as well in cases of high CPU load) to fluctuate and produces a high number of delayed frames using 1920x1080 @120hz. Anything you can do about that?
Unfortunately there's not much I can do there. All madVR does is notify MPC-HC about that subtitles need to be drawn, the rest is up to MPC-HC. I'd have to dig into the MPC-HC subtitle rendering code to fix this issue, and I don't have the time for that.

When I try to run Zoom Player 8 RC3 with madVR 0.69 as a video renderer ZP says there is an error in ntdll.dll. 0.67 is OK.
Try disabling the "delay playback start until render queue is full". Does that help?

v0.69 bug report:
Instantly seeking after the graph is built (used by the 'automatically restore last media position on replay' function) causes a crash
Will look into that.

YESSSSSSSS went back to 0.66 and DVDs work
Try disabling the option "delay playback start until the render queue is full" with 0.69, that worked for Wile-E-Coyote.

I've run a comparison between 0.66/0.69/HR in 0-255 RGB32/YV12: http://www.mediafire.com/?5zw7z5ra6gzs6px

AFAIK HR speaks the truth, 0.66 is wrong in YV12(but OK in RGB32) and 0.69 is fubar :o

if you could also fix the levels/gamma in YV12, I'd greatly appreciate it....as I'm forced to use RGB32 atm to get the right colors when feeding PC levels content.
Please check with v0.69 which primaries (press Ctrl+Alt+Shift+P once), decoding matrix (Ctrl+Alt+Shift+M) and input levels (Ctrl+Alt+Shift+I) madVR has detected. Which of them is right and which is wrong?

FWIW, madVR detects if ffdshow is set to PC or TV levels *RGB output*. madVR simply checks which option is activated under "ffdshow -> output -> RGB output levels" and uses that as the input PC vs. TV levels. If you have configured ffdshow to output YV12, then there is no simple ffdshow option (I know of) that I could check to see which levels ffdshow outputs. Of course ffdshow could fill in this structure in the media type:

http://msdn.microsoft.com/en-us/library/ff563967(v=vs.85).aspx

ffdshow could notify madVR about which output levels it uses this way. It seems that ffdshow is not doing that yet. So madVR can only guess. And YV12 is usually TV levels. You can manually switch, though, by using Ctrl+Alt+Shift+I.

madVR should also detect now which decoding matrix and primaries the original source had, even if you decode with an external decoder and use ffdshow to upscale.

Thanks for your answer but I can't find them in the list plus the extension is ".mvr".What should I do from there ?
In the SmartPlay options you click on e.g. "h264", then "configure". Then in the "decoding filters:" section you remove all filters, then you press "Add filter" and choose madVR from the list. That's it. Of course SmartPlay needs to be enabled.

[Luv]

Okidoki,let's go !

[Luv]

I feel silly ! :thanks:
-Queues behave erratically with the 264 decoder from Intel and a lot of glitches,frames drops but no conversion:it is 4:2:0.
-The mpeg2 decoder works fine but there's a conversion to 4:2:2.Was this expected ?

[leeperry]

Please check with v0.69 which primaries (press Ctrl+Alt+Shift+P once), decoding matrix (Ctrl+Alt+Shift+M) and input levels (Ctrl+Alt+Shift+I) madVR has detected.
I've disabled all calibration in mVR, whatever gamut or gamma. Would/Should it still matter? I merely require mVR >0.69 to output untouched 0-255 RGB32 exactly like 0.67, and YV12 would be great too.

FWIW, madVR detects if ffdshow is set to PC or TV levels *RGB output*. madVR simply checks which option is activated under "ffdshow -> output -> RGB output levels" and uses that as the input PC vs. TV levels. If you have configured ffdshow to output YV12, then there is no simple ffdshow option (I know of) that I could check to see which levels ffdshow outputs.
And why would this all matter to mVR? I really don't get it :o

There's an option in mVR to do a TV>PC conversion, if it's unchecked all BTB/WTW should be allowed to get through untouched...that isn't the case as of now.

Whatever YV12 or RGB32, as long as you haven't checked this option to process a TV>PC conversion, mVR shouldn't temper w/ the levels/gamma. If you feed 0-255 YUY2/RGB32 to HR/EVR, they will not touch the levels/gamma curves.

madVR should also detect now which decoding matrix and primaries the original source had, even if you decode with an external decoder and use ffdshow to upscale.
Nice! TBH, my ddcc() CUDA doesn't really work as expected because ffdshow kills the Avisynth plugins threads in a very dirty way(tritical confirmed it here (http://forum.doom9.org/showpost.php?p=1514073&postcount=694)) so I'm still looking for a no-nonsense gamut mapping solution, and I'm starting to lose faith tbh :(

Last time we discussed it, your VR considered all HD to be using the HDTV gamut...and whatever many professionals on AVS or my eyes are in complete disagreement w/ this choice...but well, I don't wanna sound like a broken record and my semi-working Avisynth kludge delivers the goods exactly the way I want it to: colors look amazing to my eyes, and it's all that truly matters :cool:

sansnom05 doesn't look quite dead, maybe he'll find some time to fix this glitch for me :)

I would very much enjoy seeing full support for 0-255 in mVR(3DLUT included) and some basic options to automatically set the input gamut depending on the frame rate/movie dimpensions: 23.976/24=SMPTE-C, 25=EBU, 29.97=HDTV when HD and SMPTE-C when uspcaled SD. And of course a hotkey to switch between them on the fly, but it's already there.

Either way, I'm back to 0.67 in 0-255 RGB32, and I dearly hope that you'll manage to make >0.69 output the exact same levels/gamma for both 0-255 RGB32(just like 0.67) & YV12 just like HR & EVR = untouched.

:thanks:

[leeperry]

And I shall add that I don't really see the point to try detecting the YCbCr decoding matrix in the stream, as -for once- this is fairly simple: x<1024=BT.601, x>1024=BT.709. There are no exceptions, well...except when newbies encode HD to SD without mapping the matrixes, or ppl encode 4:3 BD to 720p without the black bars.

[Carpo]

Happy to say the green screen image issue I was getting is fixed, thank madshi

[JarrettH]

Can I use the internal madvr MPEG2 decoder with DVDs? It seems to want to use the internal mpc one (low merit) when the Microsoft one isn't used.

Disabling the new delay playback start option solved my prior issue :D

[nevcairiel]

I found a sample that breaks with madVR 0.69.

I tested with ffdshow and my LAV Video, didn't try madVRs internal decoder.

Trying to play this sample simply freezes MPC-HC, but only with madVR 0.69/68 - 0.67 and prior work.

http://hotfile.com/dl/103917358/3471187/1.Twinpeaks1080p30fpsRef2-27Mbps.mov.html

[JarrettH]

editing...

[dansrfe]

I found a sample that breaks with madVR 0.69.

I tested with ffdshow and my LAV Video, didn't try madVRs internal decoder.

Trying to play this sample simply freezes MPC-HC, but only with madVR 0.69/68 - 0.67 and prior work.

http://hotfile.com/dl/103917358/3471187/1.Twinpeaks1080p30fpsRef2-27Mbps.mov.html

Your sample plays perfectly fine for me.

tested on v0.6x

[robpdotcom]

Your sample plays perfectly fine for me.

Works fine for me too. (btw, thanks for the latest LAVFilters, Nev).

And thanks, madshi, for the latest madVR. The issues I reported seem to be fixed now - no more corruption at the bottom of VC-1 files, and no problem with resolution changes. I'm also not getting any of the crashes I was getting with the past versions (mostly when seeking).

Maybe it's my imagination, but everything seems more responsive when using the internal decoders (as opposed to using external decoders) - quicker start up, faster/smoother seeking, etc.

The only thing missing now is deinterlacing.... hmmm... I wonder what's next? :D

[madshi]

-Queues behave erratically with the 264 decoder from Intel and a lot of glitches,frames drops but no conversion:it is 4:2:0.
Yeah, probably the Intel h264 decoder is too slow to make sense. So is probably the Intel VC-1 decoder. It seems to be slower than the MS VC-1 decoder.

-The mpeg2 decoder works fine but there's a conversion to 4:2:2.Was this expected ?
Are you sure that the internal decoder is used? I wouldn't expect it to output 4:2:2. What does the madVR OSD say exactly? Please check whether there's still a decoder filter in the chain.

I've disabled all calibration in mVR, whatever gamut or gamma. Would/Should it still matter? I merely require mVR >0.69 to output untouched 0-255 RGB32 exactly like 0.67, and YV12 would be great too.
You mean, I should treat FRAPS videos (0-255) and other videos (16-235) the same, when they come via RGB32? Are you serious?? It is very clear that if ffdshow is used for YCbCr -> RGB conversion and set to output RGB32 PC levels, madVR has to treat that differently than if ffdshow is set to output RGB32 TV levels. See ffdshow RGB conversion "output levels" section. I hope you can agree with that.

There's an option in mVR to do a TV>PC conversion
No, there is not. There is an option to define whether the display wants TV or PC levels. This option does not configure whether madVR is doing a conversion. This option just defines what the display wants. Whether a conversion is necessary depends on whether the input levels match what the display needs, of course.

If you feed 0-255 YUY2/RGB32 to HR/EVR, they will not touch the levels/gamma curves.
That's because HR/EVR are stupid and don't automatically adapt to different input types.

Last time we discussed it, your VR considered all HD to be using the HDTV gamut...and whatever many professionals on AVS or my eyes are in complete disagreement w/ this choice...
IIRC, you were saying that EU Blu-Rays may be using different primaries than US Blu-Rays? How is madVR supposed to automatically find out whether a Blu-Ray is EU or USA based? There's just no way. madVR behaves according to the official specifications. If some (or even many) Blu-Rays are not encoded the way they should be, that's bad, of course, but I don't think madVR should automatically stray away from the standards - unless madVR would be able to hit the right primaries automatically for 99% of content out there. And I just don't see how I could do that.

I would very much enjoy seeing full support for 0-255 in mVR(3DLUT included)
It is there in v0.69. You just don't like the way I implemented it. You want madVR to be stupid. To just don't touch RGB input. But that's not the way madVR works. madVR tries to automatically detect whether the RGB input is full range or not, and behave accordingly.

and some basic options to automatically set the input gamut depending on the frame rate/movie dimpensions: 23.976/24=SMPTE-C, 25=EBU, 29.97=HDTV when HD and SMPTE-C when uspcaled SD.
Didn't you say EU Blu-Rays were using EBU primaries? If so, your suggestion would treat them incorrectly.

Either way, I'm back to 0.67 in 0-255 RGB32, and I dearly hope that you'll manage to make >0.69 output the exact same levels/gamma for both 0-255 RGB32(just like 0.67) & YV12 just like HR & EVR = untouched.
In other words: You want me to stupify madVR. No thanks.

And I shall add that I don't really see the point to try detecting the YCbCr decoding matrix in the stream, as -for once- this is fairly simple: x<1024=BT.601, x>1024=BT.709.
Read this:

http://forum.doom9.org/showthread.php?p=1509130#post1509130

Also keep in mind that h264 allows more matrices to be used, e.g. YCgCo, GBR, SMPTE 240M. I have h264 samples which were encoded with YCgCo and GBR matrices. And madVR v0.69 now treats them correctly (automatically).

You haven't replied to my question which madVR auto detection (primaries, decoding matrix, input levels) goes wrong in your case?

Can I use the internal madvr MPEG2 decoder with DVDs? It seems to want to use the internal mpc one (low merit) when the Microsoft one isn't used.
I think for DVD playback the MPEG2 decoder needs to support some special stuff, which my internal decoders don't support yet, I'm sorry. I'll add that in a future version, but probably not too soon.

I found a sample that breaks with madVR 0.69.

I tested with ffdshow and my LAV Video, didn't try madVRs internal decoder.

Trying to play this sample simply freezes MPC-HC, but only with madVR 0.69/68 - 0.67 and prior work.

http://hotfile.com/dl/103917358/3471187/1.Twinpeaks1080p30fpsRef2-27Mbps.mov.html
Seems to work fine here with v0.69. Tested with ffdshow, LAV Video and madVR's internal decoders. No problem with any of them. Ok, ffdshow shows some corruption, which LAV Video and madVR's internal decoders don't. But no MPC-HC freeze here.

no problem with resolution changes.
It seems to work here with the Intel decoder, but not yet with the libav/ffmpeg decoder. I still have that on my to do list to check out.

Maybe it's my imagination, but everything seems more responsive when using the internal decoders (as opposed to using external decoders) - quicker start up, faster/smoother seeking, etc.
:)

[leeperry]

There is an option to define whether the display wants TV or PC levels. This option does not configure whether madVR is doing a conversion. This option just defines what the display wants. Whether a conversion is necessary depends on whether the input levels match what the display needs, of course.
Alright, you wanna set all kind of automatic detection schemes, good! I want untouched 0-255 RGB32, and 0.69 cannot do that for some reason :o

That's because HR/EVR are stupid and don't automatically adapt to different input types.

So allowing 0-255 RGB32 to pass untouched is "stupid" now? Why does everything always have to be so complicated :(

IIRC, you were saying that EU Blu-Rays may be using different primaries than US Blu-Rays? How is madVR supposed to automatically find out whether a Blu-Ray is EU or USA based? There's just no way. madVR behaves according to the official specifications. If some (or even many) Blu-Rays are not encoded the way they should be, that's bad, of course, but I don't think madVR should automatically stray away from the standards - unless madVR would be able to hit the right primaries automatically for 99% of content out there. And I just don't see how I could do that.

You can't automatically detect BD's that were mastered in EU(apart from a happy few that are actually 25fps :D), so going 23.976/24=SMPTE-C is as good as it's gonna get. There are far more BD's mastered in the US/JAP to give them a higher priority, for those EU BD's you can use the gamut mapping hotkey. You can't detect them automatically.

And allowing the end-user to set those automatic gamut rules will still allow you to set them all to HDTV if you like. So everyone will be happy in the end :)

But FWIR the 3DLUT cannot work w/ PC levels atm, so it would appear that I'm still daydreaming :o

It is there in v0.69. You just don't like the way I implemented it. You want madVR to be stupid. To just don't touch RGB input. But that's not the way madVR works. madVR tries to automatically detect whether the RGB input is full range or not, and behave accordingly.

Alright, please show me how to output 0-255 RGB32 *untouched* in 0.69? From my tests 0.67 can do it, 0.69 simply can't. They both fail in YV12 either way.

Read this:

http://forum.doom9.org/showthread.php?p=1509130#post1509130

Also keep in mind that h264 allows more matrices to be used, e.g. YCgCo, GBR, SMPTE 240M. I have h264 samples which were encoded with YCgCo and GBR matrices. And madVR v0.69 now treats them correctly (automatically).

Yeah, well if you use broadcast equipment that uses non 601/709 matrixes, it's your own damn job to convert it to the 709 industry standard before playing it in a consumer media player IMHO. But indeed, if you want to support exotic equipment, I guess supporting them will be good for the handful of ppl who don't do their homework beforehand :p

You haven't replied to my question which madVR auto detection (primaries, decoding matrix, input levels) goes wrong in your case?
How should I know? I've asked mVR to disable all calibration and I can't get it to output 0-255 RGB32 untouched. Last time you told me the exact same thing, but 1) it's HD and I've left it on default so it's using the 609 coeffs 2) how could the primaries matter? I've got the yCMS panel disabled in mVR("disable calibration controls for this display") 3) I've set ffdshow to 0-255 RGB32.

EDIT: Alright, w/ 0.67 there indeed was an option to process a TV>PC conversion, but now w/ 0.69 it's gotten smarter and will apply it depending on what ffdshow says, sorry for the misunderstanding.

So ffdshow is set like this: http://thumbnails56.imagebam.com/14194/b8ef0d141935239.jpg (http://www.imagebam.com/image/b8ef0d141935239)

It's indeed properly detected by mVR: http://thumbnails48.imagebam.com/14194/3bb512141935217.jpg (http://www.imagebam.com/image/3bb512141935217)

It's indeed using the 709 coeffs: http://thumbnails12.imagebam.com/14194/6692ba141935219.jpg (http://www.imagebam.com/image/6692ba141935219)

Rolling the primaries doesn't change anything, which is perfectly normal considering that the yCMS panel is disabled in mVR("disable calibration controls for this display")

I've disabled the gamma processing in mVR too.

And yet, the gamma curves are not rendered properly compared to 0.67 and HR :o

0.67: http://thumbnails49.imagebam.com/14194/22e70f141936539.jpg (http://www.imagebam.com/image/22e70f141936539)

HR: http://thumbnails29.imagebam.com/14194/13a0a3141936535.jpg (http://www.imagebam.com/image/13a0a3141936535)

0.69 w/ the aforementioned settings: http://thumbnails15.imagebam.com/14194/101600141936541.jpg (http://www.imagebam.com/image/101600141936541)

I've put my test pattern here: rec709.mkv (http://www.mediafire.com/?sfd13vqrgn7vh6i)

so what I would like to see in mVR:
-automatic detection of upscaled SD from ffdshow, in order to use the 601 coeffs(you said it should work :))
-0-255 3DLUT support
-no additional gamma processing whatsoever and proper luminance data preservation in 0-255(like in 0.67/RGB32)
-support for 0-255 YV12, making it manual if you don't want to rely on ffdshow for the levels range? Currently this setting is working for RGB32 but is ignored for YV12 from what my tests have shown :o
-automatic rules to set the input gamut depending on the frame rate and resolution

:thanks: for all once more, we might be almost there :cool:

[cyberlolo]

Well, some problems here since v0.67:

1) Trying to play some files make MPC-HC crashing. These are the logs of playing the same file (mkv movie) with v0.66 (success) and v0.69 (crash).

http://www.megaupload.com/?d=A0S7VH2T

2) Some files play fine on my PC monitor, but when I try to play them on my TV (via HDMI), MPC-HC freezes with black screen so I have to kill process with Task Manager. I use ATI profiles so in both cases the display is configured as primary display (and the only one, as the other display is deactivated). These are the logs of playing the same file (mkv movie) with v0.69 on PC (success), v0.69 on TV (freeze), and v0.66 on TV (success).

http://www.megaupload.com/?d=WG3XWSFU

However, I'm able to play with no problems some other files on PC and TV with v0.69.

My setup:

OS: Windows 7 x64
Graphics Card: ATI Radeon HD4850
Monitors:
1) (PC): Samsung 225MW (via DVI)
2) (TV): Krp 500 (via HDMI)
Player: MPC-HC x32 1.5.2.3446
Decoder: CoreAVC 2.0
Splitter: Haali 1.10.175.0
Using yCMS to calibrate ONLY in TV (but disabling yCMS on madVR didn't make any difference).

[Budtz]

Well, some problems here since v0.67:

1) Trying to play some files make MPC-HC crashing.

Yes. This happens for me aswell

[madshi]

Alright, you wanna set all kind of automatic detection schemes, good! I want untouched 0-255 RGB32, and 0.69 cannot do that for some reason :o
You don't want "untouched RGB32". You want "correct RGB32". Which in your case may happen to be the same as "untouched RGB32". Ok, so in your case you don't get "correct RGB32" rendering. So let's find out why!

So allowing 0-255 RGB32 to pass untouched is "stupid" now?
Yes, I consider it stupid. Let me give you two good reasons why:

(1) Let's say an end user plays different kinds of video formats, for which he uses different DirectShow decoder filters. Let's say some of them output RGB(0-255) and others output RGB(16-235). E.g. a FRAPS decoder is likely to output 0-255, while most other decoders, if you ask them to output RGB, will probably output RGB(16-235) by default. If in this situation the renderer passes RGB32 through untouched, some videos would play correctly and some would not.

(2) The typical dual monitor configuration is to have the primary monitor for emailing, browsing, working etc, so the primary display is usually a computer type display which needs PC levels. However, the secondary monitor is usually a TV or projector which by default usually expects TV levels. So if the video renderer passes RGB32 through untouched, videos would either look correct on the primary display, or on the secondary display, but not on both.

I hope after reading the above you can agree with me now that it's a stupid thing to do for a renderer to blindly pass RGB32 through untouched.

You can't automatically detect BD's that were mastered in EU(apart from a happy few that are actually 25fps :D), so going 23.976/24=SMPTE-C is as good as it's gonna get. There are far more BD's mastered in the US/JAP to give them a higher priority, for those EU BD's you can use the gamut mapping hotkey. You can't detect them automatically.
That's exactly my point. Whatever I do, it might be wrong:

* If I auto switch to SMPTE C, it would definitely be wrong for EU Blu-Rays.
* If I auto switch to EBU, it would definitely be wrong for USA Blu-Rays.
* If I auto switch to BT.709, it might be wrong for some USA/EU Blu-Rays.

Since I can't get it right, anyway, I prefer to stick to the standard. And the standard says that default primaries for Blu-Rays are supposed to be BT.709. And if they are not the mastering studio should pretty please list their primaries in the video bitstream. If they do that, madVR will detect that and auto switch correctly.

Besides, I'm not as convinced as you are that all (or almost all) US Blu-Rays are mastered in SMPTE C and that all (or almost all) EU Blu-Rays are mastered in EBU. If you're very sure about this, do you have a link to AVSForum where "whatever many professionals on AVS" all agree on that?

And allowing the end-user to set those automatic gamut rules
Profiles and rules have long been on my to do list, but there are many other things which come first.

But FWIR the 3DLUT cannot work w/ PC levels atm, so it would appear that I'm still daydreaming :o
The latest processing chain is like this:

(1) if input format is PC levels -> convert to video levels
(2) if input is YCbCr -> convert to RGB
(3) if activated -> apply 3dlut
(4) ...
(5) if display needs PC levels -> convert to PC levels

So in the latest madVR version 3dlut processing works just fine for both video and PC levels input data. And before you ask, since the whole processing chain from the first to the last step is very high bitdepth, the internal levels conversions shouldn't degrade image quality.

Alright, please show me how to output 0-255 RGB32 *untouched* in 0.69? From my tests 0.67 can do it, 0.69 simply can't. They both fail in YV12 either way.
Please let's analyze why you don't get *correct* RGB/YV12 rendering. Let's not concentrate on "untouched".

Yeah, well if you use broadcast equipment that uses non 601/709 matrixes
What are you talking about? The post I linked to mentioned a consumer digital camera, not broadcast equipment!

Oh, do you mean YCgCo? That's not broadcast stuff, either. It's here on doom9, it's for improving h264 compression efficiency. See here:

http://forum.doom9.org/showthread.php?t=161736

1) it's HD and I've left it on default so it's using the 609 coeffs
609 coeffs? What's that? :)

Hmmmm... From your screenshot it seems it's using BT.709. That's correct for that test pattern, right?

2) how could the primaries matter? I've got the yCMS panel disabled in mVR("disable calibration controls for this display") 3) I've set ffdshow to 0-255 RGB32.
Ok, if you feed madVR with RGB data and have the calibration controls disabled, the primaries should not matter.

So ffdshow is set like this
Is that really setup correctly? You're telling ffdshow that the input is Full Range. But it isn't, is it?

And yet, the gamma curves are not rendered properly compared to 0.67 and HR :o
Does your display need TV levels or PC levels? I mean, really, not tricked/hacked. Of course you need to configure madVR accordingly. I think you used to tell madVR that your display wants TV levels, although it really wants PC levels? Do you still have it setup that way? That won't work for v0.69. No tricks, please. You need to setup both ffdshow and madVR *correctly*.

so what I would like to see in mVR:
-automatic detection of upscaled SD from ffdshow, in order to use the 601 coeffs(you said it should work :))
-0-255 3DLUT support
-no additional gamma processing whatsoever and proper luminance data preservation in 0-255(like in 0.67/RGB32)
-support for 0-255 YV12, making it manual if you don't want to rely on ffdshow for the levels range? Currently this setting is working for RGB32 but is ignored for YV12 from what my tests have shown :o
This is all already working, IMHO, with v0.69. The only problem is the autodetection of 0-255 YV12. I simply don't know how to automatically find out whether ffdshow is sending 0-255 YV12 or 16-235 YV12. ffdshow doesn't tell me that, unfortunately, so I have to guess. And since YV12 is *normally* always 16-235, that's what madVR guesses, if there's no indication otherwise.

Do you get correct YV12 results with v0.69 now if you manually switch to PC levels input (Ctrl+Alt+Shift+I)? Of course you also need to configure the madVR display levels setting correctly.

[madshi]

Well, some problems here since v0.67:

1) Trying to play some files make MPC-HC crashing. These are the logs of playing the same file (mkv movie) with v0.66 (success) and v0.69 (crash).

http://www.megaupload.com/?d=A0S7VH2T

2) Some files play fine on my PC monitor, but when I try to play them on my TV (via HDMI), MPC-HC freezes with black screen so I have to kill process with Task Manager. I use ATI profiles so in both cases the display is configured as primary display (and the only one, as the other display is deactivated). These are the logs of playing the same file (mkv movie) with v0.69 on PC (success), v0.69 on TV (freeze), and v0.66 on TV (success).

http://www.megaupload.com/?d=WG3XWSFU

However, I'm able to play with no problems some other files on PC and TV with v0.69.
Yes. This happens for me aswell
Unfortunately, for crashes the logs won't help much. Would it be possible for you to provide me with a short sample with which I can reproduce the crash on my PC?

Could you please try disabling the option "delay playback start until render queue is full"? Does that fix the crashes and/or freezes?

[iSunrise]

Thanks a lot for 0.69 madshi.

I´m very pleased with the internal decoders. Seeking is extremely fast now (practically instant) and no image corruption whatsoever. Do you plan to support more codecs since you´re already using libav/ffmpeg? That would be great.

I also really like your automatic detection changes, the detection seems to behave very smart now. Seems like you have put a lot of thought into it beforehand.

Keep up the good work!

[mrdkreka]

Can't play these file with the new madVR 0.69, as soon as MPC try to play it, it will crash.
http://amvnews.ru/index.php?go=Files&file=down&id=3445
http://amvnews.ru/index.php?go=Files&file=down&id=3449


Could you please try disabling the option "delay playback start until render queue is full"? Does that fix the crashes and/or freezes?
Nope doesn't help

edit:
Weird some few times it manage to play the files without crashing.

[cyberlolo]

Unfortunately, for crashes the logs won't help much. Would it be possible for you to provide me with a short sample with which I can reproduce the crash on my PC?

Could you please try disabling the option "delay playback start until render queue is full"? Does that fix the crashes and/or freezes?

The first sample file provided by mrdkreka makes my MPC-HC crashing too. Didn't test the second one as now we have a same file to test, but if you want me to test the second file, please tell me.

Can't play these file with the new madVR 0.69, as soon as MPC try to play it, it will crash.
http://amvnews.ru/index.php?go=Files&file=down&id=3445

BTW, disabling the option "delay playback start until render queue is full" didn't work.

Going back to v0.66 until this is fixed...

[robpdotcom]

Don't know how can I send you a short example, as the file's size is 6GB. Any ideas?

You said it's an mkv? Use mkvmerge GUI to split the file:

Under the "Global" tab, check the "enable splitting" box. Choose the "..after this duration" option, set the time to 30s, and set the "max. number of files" to 2. Watch the output directory as mkvmerge runs, and abort the process when the second part starts muxing (it should only take a few seconds). The first part will be your sample.

[cyberlolo]

edit:
Weird some few times it manage to play the files without crashing.

Yes, here too. But very few times, let's say a 5%.

[Budtz]

[QUOTE=edit:
Weird some few times it manage to play the files without crashing.[/QUOTE]

Yes I also get this. Sometimes when i play a file that works if i go back to thouse that dont work sometimes they work anyway.

Kind regards.

[cyberlolo]

You said it's an mkv? Use mkvmerge GUI to split the file:

Under the "Global" tab, check the "enable splitting" box. Choose the "..after this duration" option, set the time to 30s, and set the "max. number of files" to 2. Watch the output directory as mkvmerge runs, and abort the process when the second part starts muxing (it should only take a few seconds). The first part will be your sample.

Thanks, but I think there's no need for this now. We've found a file that crashes to mrdkreka and to me as well, so I guess that will be enough for madshi to find what's going on.

[Blight]

madshi:
1. My initial report was not 100% accurate, it seems to be crashing even without instant seeking, but not always (about 80% of the time with some content).
I tried to help narrow down the cause, but the crash happens in a separate thread, so it's not a specific function I call which would make it easier to trace.
Just for the heck of it, since gleb seems to be suffering a similar issue, I disabled 'delay playback start until render queue is full', but it didn't help, it still crashes.
I also switched the H264 decoder to MadVR itself, but it didn't make a difference.

It seems a lot of people are reporting this crash (it manifests differently in ZP vs MPC), the best way to reproduce it in ZP is to load a known problematic file and then press Ctrl+J (reload file) over and over until the race condition is triggered and the crash occurs.


2. Is there a way to configure the madvr renderer with no video playing? What happens is that I create the filter and property page and it show up just fine, but when you click the button to 'edit settings', it returns with this error:

---------------------------
mad home cinema control...
---------------------------
madVR instance not found.

Please make sure that your firewall doesn't block madVR.



3. Do you feel that the the internal decoders are mature enough? I'd like to (but can't) provide a ZP profile for them as they are inactive by default.

[leeperry]

I hope after reading the above you can agree with me now that it's a stupid thing to do for a renderer to blindly pass RGB32 through untouched.

I only use one display and I always output 0-255 from ffdshow...this is overcomplicating things for me more than anything else. But yes, a foolproof smart VR is a good thing indeed.

Since I can't get it right, anyway, I prefer to stick to the standard. And the standard says that default primaries for Blu-Rays are supposed to be BT.709. And if they are not the mastering studio should pretty please list their primaries in the video bitstream. If they do that, madVR will detect that and auto switch correctly.

Of course, they won't and you know that. Anyway, I'd rather not get into the SMPTE-C/HDTV thingie once more. It's been thoroughly discussed in several threads and my real world experience has also shown me that using the SMPTE-C gamut for US HD and EBU for EU HD provided much more natural colors. Many ppl on the HCFR forum confirmed the exact same findings.

The french site of the ISF also confirmed it...I trust Joe Kane and the CEO of the ISF who both very much apply as industry insiders in my book more than what a standard made for a perfect world should supposedly do. IRL, CRT's are still being used for mastering movies, meaning phosphors based SMPTE-C light source gamuts.

Here's a good link: http://www.glennchan.info/articles/technical/hd-versus-sd-color-space/hd-versus-sd-color-space.htm
The most popular monitors for high-end reference monitoring are the Sony BVM series CRT monitors, which use SMPTE C phosphors (they conform to SMPTE C primaries). These monitors are not ideal for HD monitoring as modern HD formats (in other words, not the obsolete 1035i formats) call for Rec. 709 primaries. There is sometimes a disconnect between what the standards call for and what actually happens in practice.
There is little benefit for them to do these color space conversions correctly. Honestly, nobody will notice. They have little incentive to perform ideal color space conversions (if they even know about it).
That's where it all lies: no one cares! and it's a waste of time and money. Only utterly OCD'ed videophiles care, and as you can imagine they're a tiny little niche. Who wants to pay an extra $1 per disc to get the right colors? 0.001% of the BD buyers? This is a profit driven industry, they will ALWAYS go for the quick buck...look at the first Gladiator BD, it took a lot of whining to have the telecine transfer redone :devil:

Besides, I'm not as convinced as you are that all (or almost all) US Blu-Rays are mastered in SMPTE C and that all (or almost all) EU Blu-Rays are mastered in EBU. If you're very sure about this, do you have a link to AVSForum where "whatever many professionals on AVS" all agree on that?

Here's a good starting point: http://www.avsforum.com/avs-vb/showthread.php?t=1038602
It has been reported that certain members believe that SMPTE-C monitors are used by some of the studios and that we have no way of ascertaining when and where they are used

Of course, the studios that are too careless to map gamuts from SMPTE-C to HDTV at the very last stage won't brag about it :D

It's too bad that the blog of the french CEO of the ISF is currently down, he had posted the correct gamut to use on those Sammy pj's for hundred BD's and as you can guess: mastered in the US=SMPTE-C, mastered in EU=EBU. And he regularly talked to Joe Kane and was taking care of the "free" calibration(using his Minolta spectrophotometer) for the customers of those Sammy pj's. He's also taking care of calibration for mastering houses and so, he knows what happens there.

Profiles and rules have long been on my to do list, but there are many other things which come first.

Without automatic rules for the input gamut, there will never be a near-foolproof solution for automatic gamut mapping I'm afraid. You can use HDTV for anything HD if you like, but still 25fps DVD will require EBU and 23.976/29.97 DVD will need SMPTE-C.

What are you talking about? The post I linked to mentioned a consumer digital camera, not broadcast equipment

Yeah, so? mVR was a consumer grade media renderer aimed at playing DVD/BD/HDTV/SDTV last time I checked? If you use non-standard equipment(eg. some smart-ass manufacturer not finding the "Rec. ITU-R BT.709-4" YCbPr decoding matrix big enough to its taste :rolleyes:), I rest my case that it's your job to convert it to 601/709 before slapping it in ffdshow/mVR. Hollywood movies go through a lot of 3DLUT's for this very purpose. But well, if you feel like supporting them out of the box, then it's great news for the ppl who happen to manipulate non-601/709 YCbPr native content I guess, making mVR a semi-professional friendly VR indeed :)

609 coeffs? What's that?

oops, yeah I was still sleepy...I meant "Rec. ITU-R BT.709-4(Y’ = 0,2126R’ + 0,7152G’ + 0,0722B’)" of course.

That's correct for that test pattern, right?

Yes, it is.

Is that really setup correctly? You're telling ffdshow that the input is Full Range. But it isn't, is it?

It's converted from TV to PC using SmoothLevels() in the Avisynth filter of ffdshow, I'm not lying to anyone here. It's genuine 0-255 content to be displayed on a 0-255 display.

Does your display need TV levels or PC levels? I mean, really, not tricked/hacked. Of course you need to configure madVR accordingly. I think you used to tell madVR that your display wants TV levels, although it really wants PC levels? Do you still have it setup that way? That won't work for v0.69. No tricks, please. You need to setup both ffdshow and madVR *correctly*.

I did set them correctly, now that 0.69 has smartened up: I've set my display as 0-255 in mVR and same goes for ffdshow.

I used to lie about it in 0.67 coz otherwise this option would process a TV>PC conversion, considering that mVR didn't ask ffdshow what levels were being output and was assuming 16-235 input at all times.

ffdshow doesn't tell me that, unfortunately, so I have to guess. And since YV12 is *normally* always 16-235, that's what madVR guesses, if there's no indication otherwise.

Well, then a manual option like "assume 0-255 YV12" could save the day :)

Do you get correct YV12 results with v0.69 now if you manually switch to PC levels input (Ctrl+Alt+Shift+I)? Of course you also need to configure the madVR display levels setting correctly

OK, I've run a comparison again: http://www.mediafire.com/?jab3oh76jbpvxln

using:
-0-255 RGB32 in HR
-0-255 RGB32 in 0.67(same as HR)
-0-255 RGB32 in 0.69(PC levels are automatically detected from ffdshow, but gamma is way too bright)
-0-255 YV12 in 0.69 and setting the PC levels manually(gamma is slightly too dark)

Ideally the two last ones should look exactly like the two first ones :)

[madshi]

I´m very pleased with the internal decoders. Seeking is extremely fast now (practically instant) and no image corruption whatsoever. Do you plan to support more codecs since you´re already using libav/ffmpeg? That would be great.
For now I'd like to concentrate on h264, VC-1 and MPEG2 because those are IMO the most important codecs, and those are also the codecs I know quite well (on a bitstream level). Maybe some time in the future I might add support for other formats, as well, but now right now.

Can't play these file with the new madVR 0.69, as soon as MPC try to play it, it will crash.
Thanks for the samples. Is this with the internal decoders or with an external decoder? In the latter case: Which one? And which splitter are you using?

The first sample file provided by mrdkreka makes my MPC-HC crashing too. Didn't test the second one as now we have a same file to test, but if you want me to test the second file, please tell me.
I'd rather have a sample from your own crash file, too... :) Same questions to you: Does the crash happen with the internal decoders or an external decoder (which one) and which splitter are you using?

1. My initial report was not 100% accurate, it seems to be crashing even without instant seeking, but not always (about 80% of the time with some content).
I tried to help narrow down the cause, but the crash happens in a separate thread, so it's not a specific function I call which would make it easier to trace.
Just for the heck of it, since gleb seems to be suffering a similar issue, I disabled 'delay playback start until render queue is full', but it didn't help, it still crashes.
I also switched the H264 decoder to MadVR itself, but it didn't make a difference.

It seems a lot of people are reporting this crash (it manifests differently in ZP vs MPC), the best way to reproduce it in ZP is to load a known problematic file and then press Ctrl+J (reload file) over and over until the race condition is triggered and the crash occurs.
I'd be great if I could somehow reproduce this problem. Do you have a sample which crashes often, which you could share with me? Thanks!

2. Is there a way to configure the madvr renderer with no video playing?
Not at this time, but I plan to add support for that in a future version. No idea when, though.

3. Do you feel that the the internal decoders are mature enough? I'd like to (but can't) provide a ZP profile for them as they are inactive by default.
I was hoping to get a bit more feedback here in the forum. From what I've heard until now it seems that the decoders are working pretty well now. I plan to enable them by default in the next build.

[e-t172]

Of course, they won't and you know that. Anyway, I'd rather not get into the SMPTE-C/HDTV thingie once more. It's been thoroughly discussed in several threads and my real world experience has also shown me that using the SMPTE-C gamut for US HD and EBU for EU HD provided much more natural colors. Many ppl on the HCFR forum confirmed the exact same findings.

The french site of the ISF also confirmed it...I trust Joe Kane and the CEO of the ISF who both very much apply as industry insiders in my book more than what a standard made for a perfect world should supposedly do. IRL, CRT's are still being used for mastering movies, meaning phosphors based SMPTE-C light source gamuts.

It's too bad that the blog of the french CEO of the ISF is currently down, he had posted the correct gamut to use on those Sammy pj's for hundred BD's and as you can guess: mastered in the US=SMPTE-C, mastered in EU=EBU. And he regularly talked to Joe Kane and was taking care of the "free" calibration(using his Minolta spectrophotometer) for the customers of those Sammy pj's. He's also taking care of calibration for mastering houses and so, he knows what happens there.

Well, I'll just reiterate what I said when you first brought up this topic:

You'll find some food for thoughts in this thread: http://www.avsforum.com/avs-vb/showthread.php?t=1038602
I've just read this thread from beginning to end, and have not reached your conclusions. It seems the general consensus is that HD material is in fact mastered for 709 gamut. According to most professionals in this thread, they're using SMPTE-C monitors when mastering, but at the end of the chain (after the SMPTE-C monitor) there is always a gamut conversion to 709 using a 3dlut. Most of the thread is about whether it is possible to properly grade video material using a monitor with insufficient gamut ; but this discussion has nothing to do with the fact that, in the end, the result is always meant to be displayed using 709 gamut.

Because of this, I think it is best to follow the standard and use 709 gamut for HD content.

I guess this discussion will never end until we hear from the actual personnel of major mastering houses. Which will probably never happen, so this looks like an infinite loop to me. madshi applied the "When in doubt, follow the standard" principle, and I think that's for the best.

[madshi]

Those of you who have crashes, can you please try this special build to see if it fixes the issue?

http://madshi.net/madVR69test.zip

[mrdkreka]

Thanks for the samples. Is this with the internal decoders or with an external decoder? In the latter case: Which one? And which splitter are you using?

It is external decoders, where I'm using the latest CCCP beta build(2011-07-22). Since I'm using CCCP that means my splitter is "Haali Media Splitter".

edit:
Just tried the special build, so far it is working and haven't crashed yet with those files :D

[fps]

Do the internal decoders support multithreading?
Up to now I've only watched a 40 min tv show and didn't notice any corruption while normal playback and seeking.

[madshi]

Do the internal decoders support multithreading?
Yes, they support the whole shebang. It's the latest libav/ffmpeg version, just 1 day old, with all multi-threading options activated. And of course with MPEG2 4:2:2 decoding, h264 4:4:4 decoding and 9bit and 10bit h264 decoding etc...

Just tried the special build, so far it is working and haven't crashed yet with those files :D
Sounds good! :)

@cyberlolo, Budtz: Are your crashes gone, too?

@Blight, how about your crashes?

[Budtz]

Yes, they support the whole shebang. It's the latest libav/ffmpeg version, just 1 day old, with all multi-threading options activated. And of course with MPEG2 4:2:2 decoding, h264 4:4:4 decoding and 9bit and 10bit h264 decoding etc...


Sounds good! :)

@cyberlolo, Budtz: Are your crashes gone, too?

@Blight, how about your crashes?

Yup they seem to be gone. Very nice work

[ForceX]

I have been having some crashes with MPC's Remember File position option, and I am glad to report that I can't reproduce them anymore. Good work. :)

[madshi]

Happy to hear that! Will release a new official build later today or maybe tomorrow...

[cyberlolo]

Yes, they support the whole shebang. It's the latest libav/ffmpeg version, just 1 day old, with all multi-threading options activated. And of course with MPEG2 4:2:2 decoding, h264 4:4:4 decoding and 9bit and 10bit h264 decoding etc...


Sounds good! :)

@cyberlolo, Budtz: Are your crashes gone, too?

@Blight, how about your crashes?

Yep, crashes are gone here too, but freezes are still there with some other files. Are those log files that I posted before useful for finding the problem?

I use CoreAVC 2.0 and last version of Haali and MPC-HC. FYI, if I open that files with KMPlayer, everything is fine. Freezes only happen with MPC-HC.

[JarrettH]

Not sure if I said before, but the seekbar does not appear when I play a DVD in fullscreen. Using 0.69 and Microsoft DTV-DVD

[madshi]

Yep, crashes are gone here too, but freezes are still there with some other files. Are those log files that I posted before useful for finding the problem?

I use CoreAVC 2.0 and last version of Haali and MPC-HC. FYI, if I open that files with KMPlayer, everything is fine. Freezes only happen with MPC-HC.
Hmmmm... The v0.69 log stops after just 153 milliseconds of logging. That's weird. Also, the code location where it stops logging is 100% identical to v0.66. Can you create another log from the freeze with v0.69? Let MPC-HC sit frozen for 10 seconds before closing it down. Maybe that helps getting the log to work better. Also try disabling the two options "pause playback until render queue is full" and "run presentation in separate thread", just to make sure they're not causing the freeze you're seeing.

Not sure if I said before, but the seekbar does not appear when I play a DVD in fullscreen. Using 0.69 and Microsoft DTV-DVD
You mean the madVR exclusive mode seekbar? To be honest, I'm not really done anything to help with DVD playback. I'm even surprised it works at all. But then I don't know why the seekbar shouldn't show. It should work just fine, in theory at least.

[cyberlolo]

Hmmmm... The v0.69 log stops after just 153 milliseconds of logging. That's weird. Also, the code location where it stops logging is 100% identical to v0.66. Can you create another log from the freeze with v0.69? Let MPC-HC sit frozen for 10 seconds before closing it down. Maybe that helps getting the log to work better. Also try disabling the two options "pause playback until render queue is full" and "run presentation in separate thread", just to make sure they're not causing the freeze you're seeing.

Okay, here is the log. I've disabled "pause playback until render queue is full" (I had already disabled the other one), waited for more than 30 seconds, and on the second 15 (aprox), the movie audio started, but the screen remained completely black. Also, MPC-HC was unresponsive, so I had to kill the process.
http://www.megaupload.com/?d=CFZZNROG

[leeperry]

Well, I'll just reiterate what I said when you first brought up this topic
I got it the first time you said it, and I don't agree w/ either your observations or your conclusions(and yes, I read the AVS thread in full). Also, you don't seem to have run a single real world experiment on your end...which is rather odd, as we're talking about subjective opinions here, considering that the companies that are too careless to abide by the true standard won't be telling anyone.

madshi has made it clear that user-based gamut mapping automatic rules were not planned anytime soon, and I've got a perfectly working Avisynth kludge so this is just fine. Keep on believing what you want based on zero real world experiment if that can comfort you. I've personally chosen to trust what my brain tells me and what a lot of highly knowledgeable industry insiders are willing to share w/ anyone open-minded enough to listen: http://pro.jvc.com/prof/attributes/features.jsp?model_id=MDL101766
A feature unique to the RSVP2 is a "Color Gamut" menu with options for Wide, RS1, or RS2. This enables the operator to easily shift the output color space of the processor to match the SMPTE-C broadcast and telecine mastering standards most commonly used in production today. Color space is remapped inside the processor with a 3x3 "Look Up Table" (LUT) through a series of complex algorithms utilizing 14-bit processing to ensure accurate color reproduction on either the DLA-RS1X or DLA-RS2U without additional contouring in the image.
One would guess that the pro department of JVC would know what's being "most commonly" used in production environments? :p

http://www.hitechreview.com/tv/jvc-expands-its-reference-series-home-theater-line-with-anamorphic-lens-processor/308/
A 14-bit processor allows for color space remapping to SMPTE-C equaling the current telecine mastering standard
I could provide a zillion links really, coz pros know how it goes: http://www.quora.com/Is-there-such-a-thing-as-a-legal-color-gamut-in-HD-television
Blu-ray movies are color-corrected to be viewed with SMPTE 170M/240M primaries (also known as SMPTE-C); broadcast HDTV is generally supposed to be viewed with Rec. 709 primaries
I've only repeated myself coz madshi was asking for it, as I've got nothing to sell here..and I do have a working kludge to get what I want anyway :)