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. |
23rd July 2011, 22:12 | #8861 | Link | ||||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
Quote:
Yeah, planned to update it, but found no time. Quote:
Quote:
Quote:
Try disabling the option "delay playback start until the render queue is full" with 0.69, that worked for Wile-E-Coyote. Quote:
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. 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. |
||||||||
23rd July 2011, 22:26 | #8863 | Link |
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 ? |
23rd July 2011, 22:27 | #8864 | Link | |||
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Quote:
Quote:
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:
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. |
|||
23rd July 2011, 22:33 | #8865 | Link |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
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. |
23rd July 2011, 23:05 | #8867 | Link |
Registered User
Join Date: Aug 2004
Location: Canada
Posts: 860
|
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 |
23rd July 2011, 23:14 | #8868 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,348
|
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 |
24th July 2011, 02:22 | #8870 | Link | |
Registered User
Join Date: Jan 2009
Posts: 1,210
|
Quote:
tested on v0.6x |
|
24th July 2011, 04:15 | #8871 | Link | |
Registered User
Join Date: Jan 2010
Posts: 297
|
Quote:
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 |
|
24th July 2011, 08:05 | #8872 | Link | |||||||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
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:
Quote:
Quote:
Quote:
Quote:
Quote:
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:
Quote:
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. |
|||||||||||
24th July 2011, 12:11 | #8873 | Link | ||||||
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Quote:
Quote:
Quote:
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:
Quote:
Quote:
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. |
||||||
24th July 2011, 12:20 | #8874 | Link |
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. |
24th July 2011, 12:58 | #8876 | Link | |||||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
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:
* 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? Profiles and rules have long been on my to do list, but there are many other things which come first. Quote:
(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:
Quote:
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:
Hmmmm... From your screenshot it seems it's using BT.709. That's correct for that test pattern, right? Quote:
Is that really setup correctly? You're telling ffdshow that the input is Full Range. But it isn't, is it? Quote:
Quote:
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. |
|||||||||
24th July 2011, 13:00 | #8877 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Could you please try disabling the option "delay playback start until render queue is full"? Does that fix the crashes and/or freezes? |
|
24th July 2011, 13:12 | #8878 | Link |
Registered User
Join Date: Dec 2008
Posts: 496
|
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! Last edited by iSunrise; 24th July 2011 at 13:15. |
24th July 2011, 13:21 | #8879 | Link | |
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:
edit: Weird some few times it manage to play the files without crashing. Last edited by mrdkreka; 24th July 2011 at 13:29. |
|
24th July 2011, 13:26 | #8880 | Link | ||
Registered User
Join Date: Feb 2010
Posts: 127
|
Quote:
Quote:
Going back to v0.66 until this is fixed... Last edited by cyberlolo; 24th July 2011 at 13:37. |
||
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
|
|