Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 23rd July 2011, 22:12   #8861  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by kostik View Post
Thanks Madshi for your response. But still what is the need in internal decoder if we use ffdshow or other decoders :\ I am confused .
Quote:
Originally Posted by dansrfe View Post
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.

Quote:
Originally Posted by ForceX View Post
madVR is giving black screen if color/gamma correction is enabled with RGB32 video input.
Quote:
Originally Posted by alph@ View Post
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.

Quote:
Originally Posted by cyberbeing View Post
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).

Quote:
Originally Posted by cyberbeing View Post
Other: madVR [benchmark] is still 0.67.
Yeah, planned to update it, but found no time.

Quote:
Originally Posted by cyberbeing View Post
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.

Quote:
Originally Posted by Gleb Egorych View Post
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?

Quote:
Originally Posted by Blight View Post
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.

Quote:
Originally Posted by JarrettH View Post
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.

Quote:
Originally Posted by leeperry View Post
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

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/libr...(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.

Quote:
Originally Posted by Luv View Post
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.
madshi is offline   Reply With Quote
Old 23rd July 2011, 22:16   #8862  |  Link
Luv
Registered User
 
Join Date: Nov 2009
Posts: 63
Okidoki,let's go !
Luv is offline   Reply With Quote
Old 23rd July 2011, 22:26   #8863  |  Link
Luv
Registered User
 
Join Date: Nov 2009
Posts: 63
I feel silly !
-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 ?
Luv is offline   Reply With Quote
Old 23rd July 2011, 22:27   #8864  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,463
Quote:
Originally Posted by madshi View Post
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.

Quote:
Originally Posted by madshi View Post
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

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.

Quote:
Originally Posted by madshi View Post
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) 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

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.


Last edited by leeperry; 24th July 2011 at 02:50.
leeperry is offline   Reply With Quote
Old 23rd July 2011, 22:33   #8865  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,463
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.

Last edited by leeperry; 23rd July 2011 at 22:37.
leeperry is offline   Reply With Quote
Old 23rd July 2011, 22:36   #8866  |  Link
Carpo
Registered User
 
Carpo's Avatar
 
Join Date: Dec 2002
Location: /dev/null
Posts: 1,369
Happy to say the green screen image issue I was getting is fixed, thank madshi
__________________
The Internet: where men are men, women are men, and children are FBI Agents
Carpo is offline   Reply With Quote
Old 23rd July 2011, 23:05   #8867  |  Link
JarrettH
Registered User
 
Join Date: Aug 2004
Posts: 838
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
JarrettH is offline   Reply With Quote
Old 23rd July 2011, 23:14   #8868  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,782
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/3471...7Mbps.mov.html
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 23rd July 2011, 23:20   #8869  |  Link
JarrettH
Registered User
 
Join Date: Aug 2004
Posts: 838
editing...

Last edited by JarrettH; 23rd July 2011 at 23:26.
JarrettH is offline   Reply With Quote
Old 24th July 2011, 02:22   #8870  |  Link
dansrfe
Registered User
 
Join Date: Jan 2009
Posts: 1,212
Quote:
Originally Posted by nevcairiel View Post
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/3471...7Mbps.mov.html
Your sample plays perfectly fine for me.

tested on v0.6x
dansrfe is offline   Reply With Quote
Old 24th July 2011, 04:15   #8871  |  Link
robpdotcom
Registered User
 
Join Date: Jan 2010
Posts: 297
Quote:
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?
__________________
Windows 7 x64
i7 870
16GB RAM
AMD 6870
robpdotcom is offline   Reply With Quote
Old 24th July 2011, 08:05   #8872  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by Luv View Post
-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.

Quote:
Originally Posted by Luv View Post
-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.

Quote:
Originally Posted by leeperry View Post
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.

Quote:
Originally Posted by leeperry View Post
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.

Quote:
Originally Posted by leeperry View Post
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.

Quote:
Originally Posted by leeperry View Post
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.

Quote:
Originally Posted by leeperry View Post
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.

Quote:
Originally Posted by leeperry View Post
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.

Quote:
Originally Posted by leeperry View Post
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.

Quote:
Originally Posted by leeperry View Post
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.ph...30#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?

Quote:
Originally Posted by JarrettH View Post
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.

Quote:
Originally Posted by nevcairiel View Post
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/3471...7Mbps.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.

Quote:
Originally Posted by robpdotcom View Post
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.

Quote:
Originally Posted by robpdotcom View Post
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.
madshi is offline   Reply With Quote
Old 24th July 2011, 12:11   #8873  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,463
Quote:
Originally Posted by madshi View Post
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

Quote:
Originally Posted by madshi View Post
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

Quote:
Originally Posted by madshi View Post
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 ), 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

Quote:
Originally Posted by madshi View Post
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.

Quote:
Originally Posted by madshi View Post
Read this:

http://forum.doom9.org/showthread.ph...30#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

Quote:
Originally Posted by madshi View Post
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:

It's indeed properly detected by mVR:

It's indeed using the 709 coeffs:

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

0.67:

HR:

0.69 w/ the aforementioned settings:

I've put my test pattern here: rec709.mkv

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
-automatic rules to set the input gamut depending on the frame rate and resolution

for all once more, we might be almost there

Last edited by leeperry; 24th July 2011 at 12:15.
leeperry is offline   Reply With Quote
Old 24th July 2011, 12:20   #8874  |  Link
cyberlolo
Registered User
 
Join Date: Feb 2010
Posts: 127
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).

Last edited by cyberlolo; 24th July 2011 at 12:23.
cyberlolo is offline   Reply With Quote
Old 24th July 2011, 12:56   #8875  |  Link
Budtz
Registered User
 
Join Date: Apr 2011
Posts: 138
Quote:
Originally Posted by cyberlolo View Post
Well, some problems here since v0.67:

1) Trying to play some files make MPC-HC crashing.
Yes. This happens for me aswell
Budtz is offline   Reply With Quote
Old 24th July 2011, 12:58   #8876  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by leeperry View Post
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
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!

Quote:
Originally Posted by leeperry View Post
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.

Quote:
Originally Posted by leeperry View Post
You can't automatically detect BD's that were mastered in EU(apart from a happy few that are actually 25fps ), 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?

Quote:
Originally Posted by leeperry View Post
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.

Quote:
Originally Posted by leeperry View Post
But FWIR the 3DLUT cannot work w/ PC levels atm, so it would appear that I'm still daydreaming
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.

Quote:
Originally Posted by leeperry View Post
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".

Quote:
Originally Posted by leeperry View Post
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

Quote:
Originally Posted by leeperry View Post
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?

Quote:
Originally Posted by leeperry View Post
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.

Quote:
Originally Posted by leeperry View Post
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?

Quote:
Originally Posted by leeperry View Post
And yet, the gamma curves are not rendered properly compared to 0.67 and HR
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*.

Quote:
Originally Posted by leeperry View Post
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
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 is offline   Reply With Quote
Old 24th July 2011, 13:00   #8877  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by cyberlolo View Post
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.
Quote:
Originally Posted by Budtz View Post
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?
madshi is offline   Reply With Quote
Old 24th July 2011, 13:12   #8878  |  Link
iSunrise
Registered User
 
Join Date: Dec 2008
Posts: 497
Thanks a lot for 0.69 madshi.

Im 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 youre 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!

Last edited by iSunrise; 24th July 2011 at 13:15.
iSunrise is offline   Reply With Quote
Old 24th July 2011, 13:21   #8879  |  Link
mrdkreka
Registered User
 
Join Date: Mar 2011
Posts: 4
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

Quote:
Originally Posted by madshi View Post
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.

Last edited by mrdkreka; 24th July 2011 at 13:29.
mrdkreka is offline   Reply With Quote
Old 24th July 2011, 13:26   #8880  |  Link
cyberlolo
Registered User
 
Join Date: Feb 2010
Posts: 127
Quote:
Originally Posted by madshi View Post
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.

Quote:
Originally Posted by mrdkreka View Post
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...

Last edited by cyberlolo; 24th July 2011 at 13:37.
cyberlolo is offline   Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 01:18.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.