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.

 Doom9's Forum madVR - high quality video renderer (GPU assisted)
 Register FAQ Calendar Search Today's Posts Mark Forums Read

29th July 2011, 13:18   #9041  |  Link
yesgrey
Registered User

Join Date: Sep 2004
Posts: 1,295
Quote:
 Originally Posted by cyberbeing madshi, there appears to be a very slight inaccuracy in your 10-bit to 8-bit conversion
Did you disable dithering? Some fluctuations are due to dithering, so do not perform any values checking with it enabled.

29th July 2011, 13:42   #9042  |  Link
nevcairiel
Registered Developer

Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,836
Quote:
 Originally Posted by cyberbeing On another note, madshi could you make ISubRender subtitles get scaled with with the selected madVR luma/chroma resizers? If you set maximum texture size of 1280x720 and then playback fullscreen at 1920x1080, subtitles are very blurry. Do you even have control over that, or is it MPC-HC doing the blurry subtitle resizing with a lower texture size?
I don't think this is really possible. The subs need to be painted on the screen after scaling. What if my subs are rendered at 1920x1080, are they supposed to be scaled down to fit my 1280x720 video image? madVR does not know at what size the subtitles are rendered at.

All madVR does is tell MPC-HC to draw the subs onto the (otherwise finished) image. MPC-HC does all the subtitle scaling. It may be possible to actually get MPC-HC to do a bit sharper upscaling, instead of the extremely blurry version it has now - but its not something that madVR can influence.

If i were to change MPC-HC to do sharper scaling, i'm sure some people would complain because they like blurry, so i guess it would need a UI option, too... meh.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

29th July 2011, 14:34   #9043  |  Link
cyberbeing

Join Date: Oct 2005
Posts: 1,859
Quote:
 Originally Posted by yesgrey Did you disable dithering? Some fluctuations are due to dithering, so do not perform any values checking with it enabled.
Yes, I measured both with dithering enabled and dithering disabled before I made my previous post. The problem was actually much more obvious (looking a 16-bit color values in Photoshop instead of 8-bit) with dithering disabled since the values were more stable and even. I also measured FFDShow 10-bit -> 8-bit YV12 output which didn't exhibit the issue, so this seem to be something unique madVR is doing with 10-bit input.

@nevcairiel
Thanks for the info, I was somewhat suspecting it was a MPC-HC issue. It really depends on the subtitles in question, some are almost acceptable with 1280x720 tex size @ 1920x1080 others I need to strain my eyes to read because they almost unreadable blurry. The main cause seems to be when a subtitle line has a \blur or \be already applied to it... That could mean it's a bug with how MPC-HC scales blur and blur-edge, but I don't really know. Anyway, this is no longer a madVR topic it seems.

Last edited by cyberbeing; 29th July 2011 at 14:37.

 29th July 2011, 18:32 #9044  |  Link ForceX Registered User   Join Date: Oct 2006 Posts: 150 You may want to ask JanWillem32 since he is working on updating MPC-HC's subtitle renderer now.
 30th July 2011, 09:25 #9045  |  Link Volfield Registered User   Join Date: Mar 2010 Posts: 55 Is the Intel 3150 is supported? I have "creating Direct3D device failed (8876086c)" error when trying play movie.
 30th July 2011, 11:37 #9046  |  Link rahzel Registered User   Join Date: Jul 2005 Posts: 355 I'm playing around with the luma scaling options and I'm kind of confused. I have 1080p and 720p versions of the same clip and my display's native resolution is 1360x768, so madVR has to scale both videos right? And would I be right in assuming that madVR would apply luma upscaling to the 720p video and luma downscaling to the 1080p video? If so, this is what confuses me... tweaking the luma upscale option seems to have no affect on the 720p video -- changing the luma downscale option, however, does affect the 720p video. With luma downscaling set to bilinear, the 720p video looks noticeably softer than the 1080p video, but with luma downscaling set to bicubic, the 720p video is almost indistinguishable from the 1080p video. I was hoping that I could leave luma downscaling to bilinear because bicubic downscaling makes 1080p video unplayable on my machine (but it's fine for 720p). Last edited by rahzel; 30th July 2011 at 11:41.
30th July 2011, 12:53   #9047  |  Link
Registered Developer

Join Date: Sep 2006
Posts: 9,137
Quote:
 Originally Posted by Plutotype Just a hint - noticed, if you enable the madVR internal decoders and let ffdshow as preffered external video decoder ( you want to use ffdshow ), the CPU usage doubles. So it looks like the internal decoders are still on, inspite of the fact they should be blocked by the ffdshow video decoder, if ffdshow video decoder is set to prefer in the external filter list. Could you pls test this?
Just tested that, can't reproduce it. Doesn't make any sense, either, cause when ffdshow decodes, madVR isn't even getting the video bitstream, so the madVR internal decoder doesn't have any feed to work on.

Quote:
 Originally Posted by Plutotype ffdshow video 3949: MPEG2 - no A/V issues ( libavcodec ) VC-1 - occasional A/V issues ( libavcodec ), but no A/V issues with wmv9 H.264 - no A/V issues ( libavcodec ) madVR 0.71 internal decoders: MPEG2 - no A/V issues ( libavcodec ) VC-1 - no A/V issues ( libavcodec ) H.264 - no A/V issues ( libavcodec )
Looks goo to me...

Quote:
 Originally Posted by leeperry Oh, I've hardly ever encountered freezes between mVR and PotPlayer Lemme know if you want me to whine about anything on the official korean forum.
Not needed, already fixed in my sources.

Quote:
 Originally Posted by leeperry OK, neato! the only 2 things I would currently need in mVR are: -proper colors in PC range RGB32(just like in 0.67) -a way to get automatic PC range YV12(w/ proper colors of course), either through an "assume PC range for YCbCr" or "remember last YCbCr levels range".
In the next build you'll be able to create an empty file named "force full range input" in the madVR folder, which will make madVR always auto select full range input. You can still change input range via keyboard shortcut, of course. Before you ask: No similar hacks coming for gamut, though.

Quote:
 Originally Posted by Plutotype when using internal decoders and playing MPEG2 video, OSD via CTRL+J shows @ "every frame repeat" numbers like 41.67s or 41.57 etc. The playback is smooth. Im asking because...
Maybe I missed something, but where is your question?

Quote:
 Originally Posted by azaze1 Is this the 'Microsoft DTV-DVD Video Decoder' in the external filters?
No, in XP it's named "WMVideo Decoder DMO". Don't recall right now what the name is in win7.

Quote:
 Originally Posted by azaze1 If not, how can I ensure the decoder you're referring to is used for VC-1 content?
By setting it to "preferred" in the MPC-HC external filter list.

Quote:
 Originally Posted by azaze1 More importantly, is there a way to make sure it's used for VC-1 and NOT h264 should I choose to use madVR's h264 decoder....
The WMVideo Decoder DMO only decodes VC-1, not h264, so there's no conflict.

Quote:
 Originally Posted by jmone FYI the "delay playback start..." option in V0.71 causes video playback to stall in MC16
Works just fine here. Can anybody else reproduce the problem?

Quote:
 Originally Posted by andybkma Yes, I have tried different splitters, decoders (Win decoders vs 3rd party), renderers, players, different video formats, different hard drives, even different laptops. All lead to the same conclusion, it only occurs with madVR and even when I lower the scaling algorithms. That was the first thing I noticed when I moved to Win7 from XP this month, that video playback with madVR was not nearly as smooth. But like I mentioned before, it's just something to live with....
I'm confused. Originally you reported a problem only during playback *START*. Now you're saying video playback is generally not as smooth??

Quote:
 Originally Posted by azaze1 I did have a crash instantly while watching particular movies, so I'd like to provide logs, but I never see any...
If you have crashes, logs don't help as much. In that case a sample with which I can reproduce the crash would help MUCH more.

Quote:
 Originally Posted by ryrynz I've enabled MPEG2 decoding with MadVR and found when opening a VOB from any of my DVD rips the audio ends up being out of sync and after seeking the video speeds up and stutters. I'm using Lav splitter/audio 0.30 and I'm having no issues with playback when switched to ffdshow for decoding.
Which madVR version did you use? v0.70 contains an improvement for MPEG2 which might already have fixed this (if you tested with an older madVR build).

Quote:
 Originally Posted by cyberbeing Once you find and fix this bug, maybe you should make it an optional feature. I'm actually beginning to like videos opening paused, since it gives me a chance to enter fullscreen before starting playback.
I don't consider an option "make media player start paused". Such features should be provided by the media player, not by madVR.

Quote:
 Originally Posted by cyberbeing On another note, madshi could you make ISubRender subtitles get scaled with with the selected madVR luma/chroma resizers?
Quote:
 Originally Posted by nevcairiel All madVR does is tell MPC-HC to draw the subs onto the (otherwise finished) image. MPC-HC does all the subtitle scaling.
Yep. madVR doesn't do *anything*. All the work is done by MPC-HC. So there's nothing I can do to improve subtitle quality.

Quote:
 Originally Posted by cyberbeing madshi, there appears to be a very slight inaccuracy in your 10-bit to 32/64-bit to 8-bit conversion using 10-bit input from the madVR internal decoder (either that or x264 has an issue with 8-bit to 10-bit conversion).
I've double checked. The raw unprocessed YCbCr output of the h264 decoder is:

8 bit black, Y: 16, Cb: 128, Cr: 128
8 bit white: Y: 235, Cb: 128, Cr: 128
10 bit black, Y: 64, Cb: 514, Cr: 514
10 bit white: Y: 943, Cb: 514, Cr: 514

Now let's check what the BT.709 specification says:

Black level, 8bit: 16, 10bit: 64
Achromatic, 8bit: 128, 10bit: 512
Nominal peak, 8bit: 235, 10bit: 940

Seems to me the 8bit -> 10bit conversion you've done is broken.

Quote:
 Originally Posted by Volfield Is the Intel 3150 is supported? I have "creating Direct3D device failed (8876086c)" error when trying play movie.
madVR needs PixelShader 3.0 hardware support. Seems the Intel 3150 can't do that.

Quote:
 Originally Posted by rahzel I'm playing around with the luma scaling options and I'm kind of confused. I have 1080p and 720p versions of the same clip and my display's native resolution is 1360x768, so madVR has to scale both videos right? And would I be right in assuming that madVR would apply luma upscaling to the 720p video and luma downscaling to the 1080p video? If so, this is what confuses me... tweaking the luma upscale option seems to have no affect on the 720p video -- changing the luma downscale option, however, does affect the 720p video. With luma downscaling set to bilinear, the 720p video looks noticeably softer than the 1080p video, but with luma downscaling set to bicubic, the 720p video is almost indistinguishable from the 1080p video.
What does the madVR OSD (Ctrl+J) say about source resolution and target rectangle when playing your 720p video?

 30th July 2011, 13:08 #9048  |  Link pankov Registered User   Join Date: Mar 2002 Location: Sofia, Bulgaria Posts: 658 madshi, guys, I need to rotate some video files (digital camera / smartphone) but I couldn't do it when I use madVR. With EVR everything is working as expected in MPC-HC. So the question is did I do something wrong or the rotation (at least in the Z axis) is something that the renderer must support / do? I mainly use ZoomPlayer but it doesn't have such feature so I'm using MPC-HC for it but it didn't work there too so I'm lost now. madshi, if it happens to be a feature of the renderer do you plan on adding it? __________________ Z370M Pro4 | i3-8100 | 16GB RAM | 256GB SSD + 40TB NAS NVIDIA GTX 1060 6GB (385.28) | LG OLED65B7V Win 10 64bit 1803 + Zoom Player v14
30th July 2011, 13:12   #9049  |  Link
leeperry
Kid for Today

Join Date: Aug 2004
Posts: 3,463
Quote:
 Originally Posted by madshi In the next build you'll be able to create an empty file named "force full range input" in the madVR folder, which will make madVR always auto select full range input. You can still change input range via keyboard shortcut, of course.
OK, great! I don't think I'll be only one enjoying full range video. I'm looking forward a fully PotP-compatible mVR build then

Quote:
 Originally Posted by madshi Before you ask: No similar hacks coming for gamut, though.
No worries, really! I completely overlooked that RGB32 support in mVR would allow me to use rgb3dlut() again, and when using YUY2 LUT's it basically does the RGB conversion for free(God knows using what miracle ), and tritical's yv12toyuy2() allows me to specify the YV12>YUY2 bicubic interpolation coeff, so together w/ mVR's own scaler settings and rgb3dlut() bicubic scaling settings that really enables me to perfectly finetune the sharpness of the picture. Your 0.33/0.33 advise looks amazing in yv12toyuy2(), and so does 1.0/0.0 in rgb3dlut(): I can't believe how crispy(but not oversharpened) the PQ currently looks on my rig. The last problem w/ yv12toyuy2() was that it's mod4 only, but Gavino wrote an automatic script that adds black borders in order to become mod4....I've put all my LUT's on a ramdisk, and presto! automatic ffdshow profiles based on resolution/frame rate and filename tags, perfect sharpness/smoothness and 3DLUT based corrections on the get go...I couldn't be happier

Last edited by leeperry; 30th July 2011 at 13:35.

30th July 2011, 13:45   #9051  |  Link
Registered Developer

Join Date: Sep 2006
Posts: 9,137
Quote:
 Originally Posted by pankov I need to rotate some video files (digital camera / smartphone) but I couldn't do it when I use madVR. With EVR everything is working as expected in MPC-HC. So the question is did I do something wrong or the rotation (at least in the Z axis) is something that the renderer must support / do?
I've no idea.

Quote:
 Originally Posted by joe42 Subtitles work fine with MPC-HC (1.5.2.3456), even with madVR v0.71 set as the renderer. However, as soon as I add madVR to the external filters list (so that madVR can do video decoding), set it to "prefer", and restart MPC-HC, the subtitles disappear and the MPC-HC subtitle menu is disabled (greyed out).
This is a known bug in MPC-HC. You can make madVR decode without setting it to "prefer" by blocking all other decoders.

30th July 2011, 14:22   #9052  |  Link
joe42
Registered User

Join Date: Sep 2010
Posts: 25
Quote:
 Originally Posted by madshi This is a known bug in MPC-HC. You can make madVR decode without setting it to "prefer" by blocking all other decoders.
Couldn't it be fixed in madVR? I've added a lot of external filters to MPC-HC and set them to prefer, and madVR is the only one that disables subtitles.

 30th July 2011, 14:50 #9053  |  Link madshi Registered Developer   Join Date: Sep 2006 Posts: 9,137 madVR does not disable subtitle. It's a bug in MPC-HC, not in madVR.
30th July 2011, 15:17   #9054  |  Link
cyberbeing

Join Date: Oct 2005
Posts: 1,859
Quote:
 Originally Posted by madshi I've double checked. The raw unprocessed YCbCr output of the h264 decoder is: 8 bit black, Y: 16, Cb: 128, Cr: 128 8 bit white: Y: 235, Cb: 128, Cr: 128 10 bit black, Y: 64, Cb: 514, Cr: 514 10 bit white: Y: 943, Cb: 514, Cr: 514 Now let's check what the BT.709 specification says: Black level, 8bit: 16, 10bit: 64 Achromatic, 8bit: 128, 10bit: 512 Nominal peak, 8bit: 235, 10bit: 940 Seems to me the 8bit -> 10bit conversion you've done is broken.
Not good... Since x264 (swscale?) does the 8bit -> 10bit conversion, it means all builds of x264 are affected. Would you speculate that I don't have the issue with swscale 10-bit to 8-bit output because it clips levels (BTB/WTW) to TV-Range when converting to 8-bit YV12 while madVR doesn't, or because magicially swscale 10bit->8bit conversion is able to reverse the inaccuracy of swscale 8bit->10bit conversion...? If it's just an issue of madVR clipping levels, do you think it's worth having an option for clipping 10-bit input until this bug is fixed in x264 (which could take forever if it's a swscale problem)?

Hopefully Dark Shikari is aware of the problem and has someone attempting to fix it in x264 (swscale?). I wonder if it's related to the color hue bug with swscale. Though since you are able to get raw output from the decoder, it may be best if you provided the info on IRC #x264dev @ chat.freenode.net considering using swscale 8bit->10bit->8bit seems to hide the problem...

30th July 2011, 15:39   #9055  |  Link
Registered Developer

Join Date: Sep 2006
Posts: 9,137
Quote:
 Originally Posted by cyberbeing Not good... Since x264 (swscale?) does the 8bit -> 10bit conversion, it means all builds of x264 are affected. Would you speculate that I don't have the issue with swscale 10-bit to 8-bit output because it clips levels (BTB/WTW) to TV-Range when converting to 8-bit YV12 while madVR doesn't, or because magicially swscale 10bit->8bit conversion is able to reverse the inaccuracy of swscale 8bit->10bit conversion...?
My guess is that the conversion from 8 to 10 bit is done like this: "10bit = 8bit * 1023 / 255". The proper conversion would be a simple "10bit = 8bit * 4". If you use the same buggy conversion for both up- and downconversion, the error roughly equals out.

Quote:
 Originally Posted by cyberbeing If it's just an issue of madVR clipping levels, do you think it's worth having an option for clipping 10-bit input until this bug is fixed in x264 (which could take forever if it's a swscale problem)?
I won't introduce buggy conversions to madVR.

Quote:
 Originally Posted by cyberbeing Hopefully Dark Shikari is aware of the problem and has someone attempting to fix it in x264
I've just reported the problem to the x264 dev mailing list. Hopefully the problem can be fixed quickly.

30th July 2011, 17:45   #9056  |  Link
Registered Developer

Join Date: Sep 2006
Posts: 9,137
Quote:
 Originally Posted by Blight No, this looks like the exact bug that caused crashes in 0.69 that you fixed in 0.70, but only occurs in the DX11 path is used.
Quote:
 Originally Posted by Blight This happens in the DX9 path, I couldn't test the DX11 path, as it's not stable for this operation.
Can't reproduce any problems here. My win7 PC is single monitor, though. My dual monitor setup is XP.

Quote:
 Originally Posted by Blight Here's the log file you requested where creating a window (before even showing it) causes MadVR to lose exclusive mode for a second. Are you checking the window handle for visibility and position? If you're just checking position and hooking the window create function, you're going to get false positives.
Argh, I just noticed, the log file only contains the information I need if you enable the madVR debug OSD (Ctrl+J). Could you create another log with the madVR debug OSD on?

I'm enumerating all windows checking whether the madVR parent is fullscreen and on top. Invisible windows should be ignored, at least in theory.

Quote:
 Originally Posted by Blight My OSD (ControlBar/pop-up OSD). I try to clear it with a separate API call, I'm not using timeouts at all.
I've just tested that here on my PC with the ZP8 RC you sent me and it seems to work just fine here. Your "stop" message appears and then goes away after 3 seconds or so.

Quote:
 Originally Posted by Blight I just did a very quick initial test and 0.71 partially breaks the OSD. If I pause playback, no OSD is displayed. If I press play again, the 'pause' OSD appears briefly before switching to a 'play' OSD.
This doesn't occur here, either. How can I reproduce these OSD problems?

 30th July 2011, 17:54 #9057  |  Link nevcairiel Registered Developer   Join Date: Mar 2010 Location: Hamburg/Germany Posts: 9,836 Apparently the status messages of MPC-HC (like changing volume) cause alot of dropped frames now (or at least claims to). I can consistently drive the dropped-frames counter up by simply changing the volume with the mouse-wheel. Is that a display thing, or does it really drop frames? I can't say that it stuttered badly while doing it or anything... __________________ LAV Filters - open source ffmpeg based media splitter and decoders
30th July 2011, 17:57   #9058  |  Link
Registered Developer

Join Date: Sep 2006
Posts: 9,137
Quote:
 Originally Posted by nevcairiel Apparently the status messages of MPC-HC (like changing volume) cause alot of dropped frames now (or at least claims to). I can consistently drive the dropped-frames counter up by simply changing the volume with the mouse-wheel. Is that a display thing, or does it really drop frames? I can't say that it stuttered badly while doing it or anything...
In order to make the OSD more responsive, I'm now cutting the rendering queue down to 4/8 whenever anything OSD related is updated. This may eventually result in frame drops. If your GPU and CPU are fast enough, I would not expect that, though. Can you provide a log with such frame drops caused by the OSD?

 30th July 2011, 17:59 #9059  |  Link madshi Registered Developer   Join Date: Sep 2006 Posts: 9,137 madVR v0.72 released http://madshi.net/madVR.zip Code: * empty file "force full range input" in madVR folder overwrites auto detection * empty file "YCbCr" in madVR folder makes madVR output YCbCr data directly * fixed: video playback in PotPlayer froze in various situations * fixed: display mode change + "delay playback start..." -> video stayed paused
30th July 2011, 18:32   #9060  |  Link
nevcairiel
Registered Developer

Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,836
Quote:
 Originally Posted by madshi In order to make the OSD more responsive, I'm now cutting the rendering queue down to 4/8 whenever anything OSD related is updated. This may eventually result in frame drops. If your GPU and CPU are fast enough, I would not expect that, though. Can you provide a log with such frame drops caused by the OSD?
Here is a log of this (started playback, entered exclusive mode, did some volume changing, quit)

It does indeed only occur when the decoder isn't extremely fast. It does happen with LAV CUVID (hardware is limited to around 70-80fps), but it does not happen with a multi-threaded software decoder pulling off 300-400fps.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

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