View Full Version : madVR - high quality video renderer (GPU assisted)
James Freeman
13th July 2015, 16:43
madVR 88.17 crashes immediately with MPC-HC nightly 1.7.9.54 64bit.
i7, GTX660, windows 7 64bit.
UPDATE:
Crashes only large files; small files play normally.
Talking about MKV here.
UPDATE2:
Disabling D3D11 fixes the crashes.
Enabling it again, stays fixed......
UPDATE3:
88.17 dropped about 8ms from my rendering time in P8 state! :D Thanks.
madshi
13th July 2015, 16:46
@James, more details, please. All videos files or just some? madVR crash report?
James Freeman
13th July 2015, 17:06
The crashes are back, they are totally random.
I'll do my best to catch one with debug mode.
EDIT:
When I first installed 88.17 it crashed immediately several time when I tried to play big files, but after disabling and enabling d3d11 the crashes became rare.... strange.
EDIT2:
It crashes even before it calculates the rendering times...
The image is frozen, so when I enlarge the window the text enlarges with it.
Movie resolution is 1920x1080.. something is wrong.
http://www.mediafire.com/convkey/83e5/2aty12fdc0kmdszzg.jpg
http://www.mediafire.com/convkey/ddac/27tzwm0tyrt7wtzzg.jpg
James Freeman
13th July 2015, 17:44
88.17 Crash log.
Probably due to "movie resolution"...
http://www.mediafire.com/download/0f72wzfqf2355r7/madVR_-_log.zip
kasper93
13th July 2015, 17:47
That sounds quite weird! I'm having trouble reproducing it, though. I suppose the MPC-HC window is not centered on the screen in this situation, is it? Could you create a debug log that shows this situation?
Tell me if you find something https://dl.dropboxusercontent.com/u/16282309/MPC-HC/madVR%20-%20log.7z if not I will look if I can provide more info.
madshi
13th July 2015, 19:13
88.17 Crash log.
Probably due to "movie resolution"...
http://www.mediafire.com/download/0f72wzfqf2355r7/madVR_-_log.zip
That's not a crash report, but a debug log. Debug logs are useless for crashes. What I need is the crash report. You can send it to me by pressing the "send bug report" button. Enter your name in the comments please, so I know the crash report is from you. If sending the crash report that way doesn't work, simply close the box, then you should get a crash report text file on your desktop. Upload that. If that also doesn't work, you should be able to press Ctrl+C when that "An error occurred in the application" crash box appears, which should copy the crash report to the clipboard.
Tell me if you find something https://dl.dropboxusercontent.com/u/16282309/MPC-HC/madVR%20-%20log.7z if not I will look if I can provide more info.
Thanks. The log is pretty clear about what's happening. Hope I can fix it based on that.
Warner306
13th July 2015, 20:36
Any particular reason for this feature?
Kodi DSPlayer is probably helped the most by any change to the rendering of OSD elements. I haven't had the chance to test it. General stability has been the issue with Kodi thus far, particularly on playback stop.
Warner306
13th July 2015, 21:12
I am getting presentation glitches when using SuperRes or FineSharp under Upscaling Refinement. madVR v0.88.16 had no such problems.
720p -> 1080p
D3D11
Present frame for every v-sync
Rendering queue: 36-38 ms
This problem is present with MPC-BE and DSPlayer. SuperRes is working harder with the AR filter. But what about FineSharp? Has performance simply degraded?
6ari8
13th July 2015, 21:23
Need more information. GPU? OS? Maybe a screenshot of the OSD (Ctrl+J)?
Does this problem also occur with v0.88.16, or is it a new problem with v0.88.17? How about this test build?
http://madshi.net/madVR8816b.rar
Does it show the same problem or not?
Sorry about that. More details:
System: Alienware M14x R2, Intel i7-3720QM, 16GB RAM, NVIDIA GeForce GT 650M 2GB + Intel HD Graphics 4000, Windows 10TP 10166.
The issue seems to be only affecting D3D11 and is more pronounced in exclusive mode. It did not occur since you introduced D3D11 until now. I missed the madVR8816b test build so I just tried it and it does have the issue. However, builds up to v0.88.16 did not have this.
I don't think you can see what's wrong from looking at still screenshots but I took some.
During playback:
http://s13.postimg.org/zerh8iskj/play.png (http://postimg.org/image/zerh8iskj/)
Paused:
http://s13.postimg.org/7ddfutnab/paused.png (http://postimg.org/image/7ddfutnab/)
I recorded a video that I hope can show the issue better here:
http://usersfiles.com/008uiezqcji8
mogli
13th July 2015, 21:28
Is 'delay playback start until queue is full' supposed to work after resuming from a paused video? If so it doesn't seem to work anymore.
MistahBonzai
13th July 2015, 21:48
I am getting presentation glitches when using SuperRes or FineSharp under Upscaling Refinement. madVR v0.88.16 had no such problems.
Same here. Just reverted to v0.88.16 and problem gone. Also had occasional long present times. However the glitches didn't seem to align with difficult video sections or jumps in GPU useage. Going back to v0.88.17 32-bit and investigate some more.
AMD HD7850
intel i7 3770
Windows 7 64-bit with sp-1
Display is 1080p 10 bpp
madshi
13th July 2015, 21:53
Sorry about that. More details:
System: Alienware M14x R2, Intel i7-3720QM, 16GB RAM, NVIDIA GeForce GT 650M 2GB + Intel HD Graphics 4000, Windows 10TP 10166.
The issue seems to be only affecting D3D11 and is more pronounced in exclusive mode. It did not occur since you introduced D3D11 until now. I missed the madVR8816b test build so I just tried it and it does have the issue. However, builds up to v0.88.16 did not have this.
I don't think you can see what's wrong from looking at still screenshots but I took some.
I recorded a video that I hope can show the issue better here:
http://usersfiles.com/008uiezqcji8
Now *that's* what I call a detailed bug report... :)
Yeah, that doesn't look too good. It's bad that no problems are reported in the OSD, but it still stutters. What happens if you show the madVR seekbar in exclusive mode instead of activating the Ctrl+J OSD? Same stuttering? I suppose you're rendering on the NVidia? What happens if you render on the Intel instead?
I am getting presentation glitches when using SuperRes or FineSharp under Upscaling Refinement. madVR v0.88.16 had no such problems.
720p -> 1080p
D3D11
Present frame for every v-sync
Rendering queue: 36-38 ms
This problem is present with MPC-BE and DSPlayer. SuperRes is working harder with the AR filter. But what about FineSharp? Has performance simply degraded?
Same here. Just reverted to v0.88.16 and problem gone.
FineSharp should not be any slower. Does the same problem also occur with this slightly older test build?
http://madshi.net/madVR8816b.rar
Is 'delay playback start until queue is full' supposed to work after resuming from a paused video? If so it doesn't seem to work anymore.
If you pause video, the queues should be all full all the time. So if you resume from paused state, there's no need to wait. Or are the queues not full when you resume playback, for some weird reason?
Warner306
13th July 2015, 22:30
FineSharp should not be any slower. Does the same problem also occur with this slightly older test build?
http://madshi.net/madVR8816b.rar
Using this test build, I am able to use FineSharp Upscaling Refinement once again without presentation glitches. You have broken something that impacts FineSharp. But SuperRes remains too demanding for my system using my previous settings.
I prefer the look of SuperRes, so I will have to do some testing with other settings to see if I can accommodate one pass after upscaling.
XMonarchY
14th July 2015, 00:48
The pause/resume stuttering was fixed for me with the latest release! Yey! I no longer have to exit Exclusive Fullscreen Mode after pausing playback to resume it without stutters.
I do have a somewhat separate question. I noticed in the very latest LAV Video Filter/Decoder, there is a new option for RGB Output levels. There used to be only 2 options - TV (16-235) and PC (0-255), but now there is the Untouched (same as input) option. My PC/GPU, TV, madVR, and 3DLUT are all configured to 0-255, but I still wonder whether Untouched (same as input) option would be of any benefit..?
Another thing I noticed is that my TV is set to 12bit color depth via NVidia CP, madVR is set to 10bit+, ctrl+J menu shows D3D11 exclusive (10bit), but right under it I get "h264, 8bit, 4:2:0 - NV12, 8bit, 4:2:0". Is that how it should be or is my LAV Filter/Decoder (or something else) not configured correctly? I have all LAV Filter/Decoder output formats ticked/enabled except for AYUV.
Ver Greeneyes
14th July 2015, 01:40
I noticed in the very latest LAV Video Filter/Decoder, there is a new option for RGB Output levels. There used to be only 2 options - TV (16-235) and PC (0-255), but now there is the Untouched (same as input) option.That has been around for a very long time. You must have been using an ancient version before if you didn't have it. I think it makes sense to use Untouched if it's feeding into madVR, since this will ensure that madVR gets the original output, and not something that LAV has expanded/compressed and dithered. Having said that, it probably doesn't matter at all, since LAV shouldn't be doing the YUV -> RGB conversion in the first place. It should be giving madVR the YUV signal.
MistahBonzai
14th July 2015, 02:53
FineSharp should not be any slower. Does the same problem also occur with this slightly older test build?
http://madshi.net/madVR8816b.rar
Sorry, false alarm. Problem has resolved itself - FM? Could be :) Anyway, shutdown madVR and overwrote .16 with .16b. Looked fine - no glitches. Uninstalled .16b and installed .17. Still no presentation glitches.
All I can offer is that I did reboot (Windows 7 64-bit) before reverting back to .16 on the first go round . In hindsight I should have rebooted before reverting from .17 to .16. Sometimes after testing many MadVR settings on a given video odd behaviour will occur and I reboot without further consideration to restore performance to normal.
James Freeman
14th July 2015, 04:11
That's not a crash report, but a debug log. Debug logs are useless for crashes. What I need is the crash report.
Sorry about that, never had to use this feature.
Here is a "Freeze Report" not crash report:
http://www.mediafire.com/view/3u3tqsz3yzook2k/madVR_-_freeze_report_(1).txt
Hope this is the correct one.
EDIT:
16b works fine.
I recently had .NET framework problems if that of any help...
Ver Greeneyes
14th July 2015, 04:22
I think I'm seeing the crashes that James is describing on my laptop. Here's a crash report: Mediafire link (http://www.mediafire.com/download/i9kpx0x5bd0x6yd/madVR+-+crash+report.rar). madVR's crash reporter did come up, but I couldn't send in the report for some reason. It just told me "failed to send crash report" without further information.
Warner306
14th July 2015, 04:59
Sorry, false alarm. Problem has resolved itself - FM? Could be :) Anyway, shutdown madVR and overwrote .16 with .16b. Looked fine - no glitches. Uninstalled .16b and installed .17. Still no presentation glitches.
All I can offer is that I did reboot (Windows 7 64-bit) before reverting back to .16 on the first go round . In hindsight I should have rebooted before reverting from .17 to .16. Sometimes after testing many MadVR settings on a given video odd behaviour will occur and I reboot without further consideration to restore performance to normal.
The problem with FineSharp is still present for me, even after a reboot. Its performance is gimped.
I was able to run the improved SuperRes without presentation glitches by lowering dithering from Error Diffusion 2 to Ordered. Disappointing but worth it.
All of the sharpening added to the image has gotten me away from a natural image in some ways, but I'm impressed that detail enhancement can be done in madVR with little to no increase in noticeable artifacts. The program is evolving to cater to many tastes in image quality.
KhR0N1K
14th July 2015, 05:03
theres seems to be a problem with "video" mode deinterlacing with v0.88.17. the video flashes rapidly or i get a DXVA failed error when i open MPC if i force "film" mode but the video plays ok after that in "film" mode.
didn't have either of these issues in v0.88.16. will revert back for now.
love coming here everday to check for updates. thanks a lot for your great renderer and hard work madshi.
Edit: reverted back to .16 and its working fine again in both modes no error msg or flashing video in "video" deinterlacing mode. def. seems like a .17 issue im using a Radeon HD 6900 vector adaptive deinterlacing if that helps you any. but obviously "film" mode forces software IVTC so i don't think its a hardware issue.
ThurstonX
14th July 2015, 05:40
theres seems to be a problem with "video" mode deinterlacing with v0.88.17. the video flashes rapidly or i get a DXVA failed error when i open MPC if i force "film" mode but the video plays ok after that in "film" mode.
didn't have either of these issues in v0.88.16. will revert back for now.
love coming here everday to check for updates. thanks a lot for your great renderer and hard work madshi.
Edit: reverted back to .16 and its working fine again in both modes no error msg or flashing video in "video" deinterlacing mode. def. seems like a .17 issue im using a Radeon HD 6900 vector adaptive deinterlacing if that helps you any. but obviously "film" mode forces software IVTC so i don't think its a hardware issue.
I think I saw this same problem with a Blu-ray file set earlier today. As it was the first Blu-ray I've tried, I didn't want to mention it without further investigation. I didn't revert to v0.88.16, but I played the DVD version of the same, and didn't experience the problem. With the Blu-ray files, there was also some audio corruption after pausing/resuming, and when jumping ahead. Had the DXVA Failed error, too.
All playback in the the latest stable MPC-HC x64 (1.7.9) under Win 7, with a passively cooled Sapphire R7 250, in FSE mode.
MistahBonzai
14th July 2015, 06:02
The problem with FineSharp is still present for me, even after a reboot. Its performance is gimped.
I was able to run the improved SuperRes without presentation glitches by lowering dithering from Error Diffusion 2 to Ordered. Disappointing but worth it.
All of the sharpening added to the image has gotten me away from a natural image in some ways, but I'm impressed that detail enhancement can be done in madVR with little to no increase in noticeable artifacts. The program is evolving to cater to many tastes in image quality.
Sorry to hear that :( I've been beating the crap outta my set-up and not a Presentation Glitch in sight. In fact it's never been better. Running a desktop with i7-3770 3.4Ghz (liquid cooled but stock clock), 16GB 1600 RAM, AMD HD-7850, good cooling and 512GB SSD 'C' drive with Windows 7 64-bit.
Along with MadVR/XySubFilter/LAV/AC3 I run SVP/AVS+ and NNEDI3 via Avisynth scripts in ffdshow raw video filter - all the latest versions. That way it's possible to split the load across GPC/CPU and stretch MadVR a bit further. Ideally I shoot for 50% CPU and 50%GPU.
MadVR looks like this (for now):
[]processing
reduce banding artifacts (medium and high)
image enhancements - FineSharp (.5)
[]scaling algorithms
Chroma upscaling (Bilateral)
image downscaling (Catmull-ROM)
image upscaling (Lanczos 3 taps with anti-ringing)
upscaling refinement (AdaptiveSharpen (0.3))
[]rendering
general settings (everything checked excepting windowed overlay and disable desktop composition)
smooth motion (only if...)
dithering (Ordered Dithering with colored noise and change every frame)
[]trade quality for performance
no DXVA (cuz I have AMD and I always use software)
don't analyze gradient...
don't render with fade in/out (this one is kinda strange sometimes when I encounter reported (but not observed) dropped frames when only panning a still image in a video - it all depends...)
It's gotten to the point where I wanna run my photo collection in MadVR as my 'screen saver' rather than Picasa. I don't think there is an end to it ;)
KeyserSoze17
14th July 2015, 07:45
Faster OSD reaction times, of course. Not so important for simple informational texts like "exclusive" or "windowed". But things like the FSE seekbar or even more complex OSD elements do benefit. Some media players draw complex OSDs through the madVR OSD interfaces.
Awesome. Thank you Madshi. I know the MeediOS player I wrote has some lag in the FSE menus it draws. I'm excited to test with this new version.
James Freeman
14th July 2015, 08:06
A positive thing I can say about 88.17 with my system is that it cuts the rendering time in half from 23ms to 11ms with DX11, in P8 state (NVIDIA).
Turning D11 off returns to 23ms.
Warner306
14th July 2015, 08:47
After watching some content with the most recent SuperRes, I feel as though further improvement is unnecessary. The anti-ringing filter is an adequate finishing touch.
I am curious if there is any relationship between debanding and image sharpening. If debanding is applied to the source, does this reduce the possibility of unwanted artifacts being sharpened?
ERRFMT
14th July 2015, 09:50
Hi
Seeing the following with any video when dxva deinterlacing is active:
Flashing screen, all queues showing zero on osd, screen goes blank when paused.
Jriver MC20.124, madvr 88.17, windows 7 x64, gtx960, 353.30 driver.
Reverting to 88.16 shows no problem with interlaced video.
88.17 is fine on all non-interlaced video, all queues full on osd.
madshi
14th July 2015, 10:12
Sorry about that, never had to use this feature.
Here is a "Freeze Report" not crash report:
http://www.mediafire.com/view/3u3tqsz3yzook2k/madVR_-_freeze_report_(1).txt
Hope this is the correct one.
EDIT:
16b works fine.
I recently had .NET framework problems if that of any help...
The freeze report is better than the debug log, but it's still not the crash report. Your earlier screenshots showed a little window with the text "An error occurred in the application". If you get this window, press Ctrl+C, then open Notepad and press Ctrl+V. This way you should get the crash report, if sending it doesn't work for you.
I think I'm seeing the crashes that James is describing on my laptop. Here's a crash report: Mediafire link (http://www.mediafire.com/download/i9kpx0x5bd0x6yd/madVR+-+crash+report.rar). madVR's crash reporter did come up, but I couldn't send in the report for some reason. It just told me "failed to send crash report" without further information.
That seems to be a different crash report. It's madHcCtrl crashing, not madVR or the media player. Not sure why sending the bug report fails, unfortunately.
Using this test build, I am able to use FineSharp Upscaling Refinement once again without presentation glitches. You have broken something that impacts FineSharp. But SuperRes remains too demanding for my system using my previous settings.
I prefer the look of SuperRes, so I will have to do some testing with other settings to see if I can accommodate one pass after upscaling.
With which media player are you testing this? Is it Kodi/DSPlayer? There is a bug in madVR right now which always puts it into "low latency" mode, when using Kodi/DSPlayer. You should see this in the OSD: The "present queue" should always be limited to max 2 frames. I guess that this might be causing the presentation glitches you're seeing. Although I've no idea why they should occur with FineSharp. I've not changed a single thing related to FineSharp from v0.88.16 to v0.88.17. That must be a coincident, or some weird timing related issue.
theres seems to be a problem with "video" mode deinterlacing with v0.88.17. the video flashes rapidly or i get a DXVA failed error when i open MPC if i force "film" mode but the video plays ok after that in "film" mode.
didn't have either of these issues in v0.88.16. will revert back for now.
Seeing the following with any video when dxva deinterlacing is active:
Flashing screen, all queues showing zero on osd, screen goes blank when paused.
Couldn't reproduce this yesterday, but today I can. Will fix it for the next build.
Awesome. Thank you Madshi. I know the MeediOS player I wrote has some lag in the FSE menus it draws. I'm excited to test with this new version.
Let me know if it works!
A positive thing I can say about 88.17 with my system is that it cuts the rendering time in half from 23ms to 11ms with DX11, in P8 state (NVIDIA).
Turning D11 off returns to 23ms.
Weird. I've no idea why rendering time should be lower.
After watching some content with the most recent SuperRes, I feel as though further improvement is unnecessary. The anti-ringing filter is an adequate finishing touch.
There are still some aliasing problems. Waiting for some samples to work on that.
I am curious if there is any relationship between debanding and image sharpening. If debanding is applied to the source, does this reduce the possibility of unwanted artifacts being sharpened?
I'm not sure if sharpening algorithm already start sharpening banding steps. Maybe they do, then debanding should help. In any case, it should not harm.
chros
14th July 2015, 10:14
theres seems to be a problem with "video" mode deinterlacing with v0.88.17. the video flashes rapidly or i get a DXVA failed error when i open MPC if i force "film" mode but the video plays ok after that in "film" mode.
didn't have either of these issues in v0.88.16. will revert back for now.
0.88.16b (beta) introduced this bug, I thought it's because it was a debug build. I got the same problem with it even with progressive content. Now 0.88.17 is working fine with progressive content.
A positive thing I can say about 88.17 with my system is that it cuts the rendering time in half from 23ms to 11ms with DX11, in P8 state (NVIDIA).
Turning D11 off returns to 23ms.
Woow! Thanks for the info, I'll try it out tonight.
nevcairiel
14th July 2015, 10:56
A positive thing I can say about 88.17 with my system is that it cuts the rendering time in half from 23ms to 11ms with DX11, in P8 state (NVIDIA).
Turning D11 off returns to 23ms.
This is more likely a statistic fluke than anything else. D3D11 won't make the GPU run 100% faster magically.
cvrkuth
14th July 2015, 11:05
88.16
present queue: 7-8/8
88.17
present queue: 1-2/2
madshi
14th July 2015, 11:13
88.16
present queue: 7-8/8
88.17
present queue: 1-2/2
This is the low latency mode. Which media player are you using?
cvrkuth
14th July 2015, 11:17
PotPlayer 1.6.55124 64-bit
cvrkuth
14th July 2015, 11:43
This is the low latency mode.
I don't know what is a "low latency mode", is there anything i can do about it?
madshi
14th July 2015, 11:49
Just wait for the next madVR build.
huhn
14th July 2015, 11:51
edit: source is RGB give me a sec to fix this and retest this.
edit2: there is a huge blue color shift but the scaling is something like lanczos3 AR.
MPC-HC thread: http://forum.doom9.org/showpost.php?p=1730068&postcount=2013
And that's with the latest madVR build? A couple of months ago the way madVR did DXVA scaling, AMD drivers produced Bilinear scaling. But I changed something a couple of weeks/months ago, and I'm getting "proper" scaling now with AMD drivers. However, I'm still on Windows 8.1.
yes still bilinear but the most interesting part is that the OSD says bilinear with selected DXVA2. looks like DXVA2 can't be used.
http://abload.de/img/dxva74sl4.png
windows 10 is released in 15 days and the RTM "10240" for "insider" should be available in a couple of days. I will report bugs with that version of windows.
madshi
14th July 2015, 11:55
DXVA2 scaling with best quality usually only works for YCbCr 4:2:0 sources. At least madVR only even tries to use DXVA scaling with YCbCr 4:2:0 sources. If you want to test with RGB test patterns, use AviSynth with ConvertToYV12().
huhn
14th July 2015, 12:11
DXVA2 scaling with best quality usually only works for YCbCr 4:2:0 sources. At least madVR only even tries to use DXVA scaling with YCbCr 4:2:0 sources. If you want to test with RGB test patterns, use AviSynth with ConvertToYV12().
fixed it already sorry. here is a screen from the color shift.
normal: http://abload.de/img/spline6guo5.png
colorshift: http://abload.de/img/blueshiftahucu.png
but most importantly it's not using bilinear.
Ver Greeneyes
14th July 2015, 13:23
That seems to be a different crash report. It's madHcCtrl crashing, not madVR or the media player. Not sure why sending the bug report fails, unfortunately.OK, in that case I hope you can make something of it :) I got the crash several times yesterday trying to open the same livestream (1280x720 but a static image, if that matters) using livestreamer + MPC-HC. After a few attempts it did load however, so it's not a consistent crash.
huhn
14th July 2015, 13:37
OK, in that case I hope you can make something of it :) I got the crash several times yesterday trying to open the same livestream (1280x720 but a static image, if that matters) using livestreamer + MPC-HC. After a few attempts it did load however, so it's not a consistent crash.
you are not using by any chance CUVID?
Ver Greeneyes
14th July 2015, 14:14
you are not using by any chance CUVID?No, the laptop's GPU is a Mobility Radeon HD 4650. I'm using the new windowed mode D3D9 path of madVR with the DWM enabled on Windows 7. The GPU is too weak for anything like NNEDI3 (or even Jinc), though I do use a 3DLUT.
But given that it's a madHcCtrl crash, I don't know how much the specific madVR settings matter.
tobindac
14th July 2015, 15:40
crashing when starting a dvb-t device/channel. correction that it wasn't on any video, adding on previous report about crash on latest mpc-hc nightly (also running svp latest).
PS. I know I was very cryptic. I had no time. I may go in more detail if I find more.
surgical
14th July 2015, 16:55
Greetings to all:
First of all, I apologize if the question I'm going to do may seem silly, but for more that I've read in this thread yet I've a doubt about the " upscale refinements ".
My question is if these are activated in "any" upscaling, I mean, for example, with "image doubling"; or only when acts an algo from "image upscaling" .
Thanks in advance
James Freeman
14th July 2015, 17:03
Madshi,
Here is my crash report (Ctrl+C as you instructed):
Zugriffsverletzung bei Adresse $4a47e0f8 in Modul 'madVR64.ax'. Lesen von Adresse $8fcf709.
Its in German. ;)
nevcairiel
14th July 2015, 17:10
Madshi,
Here is my crash report (Ctrl+C as you instructed):
The actual crash report would be much longer than this one line.
You can copy-paste the entire dialog - and it'll include plenty information. Don't try to extract this one line from it. ;)
Its in German. ;)
Thats fine, so is he. ;)
James Freeman
14th July 2015, 17:12
I did not try to extract anything, just ctrl+c and ctrl+v into notepad. That's all there is.
BUT, it tries to send email with a much longer crash report, I'll upload that.
EDIT:
Ahh yes, I need to click "show bug report" and only then press ctrl+c.
In a minute...
http://www.mediafire.com/download/6v27zhn5qmd7yhg/MadVR_crash_report_James.7z
disassembling:
[...]
4a47e0dd call +$4f6e ($4a483050) ; settings.cpp.CSettings.GetCurrentSmoothMotion (madVR64.ax)
4a47e0e2 test al, al
4a47e0e4 jz loc_4a47e387
4a47e0ea 7078 movsxd rax, dword ptr [r13+$26a0a0]
4a47e0f1 imul rax, rax, $9a8
4a47e0f8 > cmp byte ptr [rax+rsi+$71], 0
4a47e0fd jz loc_4a47e10f
4a47e0ff mov rcx, [r13+$26a0e0]
4a47e106 call -$6a30b ($4a413e00) ; dynopencl.cpp.COpenCL.IsNVidia (madVR64.ax)
4a47e10b test al, al
4a47e10d jnz loc_4a47e128
[...]
Disabling SmoothMotion from the start stops the crashes.
ashlar42
14th July 2015, 17:15
Another thing I noticed is that my TV is set to 12bit color depth via NVidia CP, madVR is set to 10bit+, ctrl+J menu shows D3D11 exclusive (10bit), but right under it I get "h264, 8bit, 4:2:0 - NV12, 8bit, 4:2:0". Is that how it should be or is my LAV Filter/Decoder (or something else) not configured correctly? I have all LAV Filter/Decoder output formats ticked/enabled except for AYUV.
I would be interested in a reply to the very same question. :)
Ver Greeneyes
14th July 2015, 17:15
madshi, I think the crash report I uploaded may not have been for the right crash (it may have been an old one still sitting on my desktop). Even though the crash reporter comes up, when I get this crash it doesn't seem to create a crash report - which may explain why it can't send the report. I created a debug log where it crashes, and tried pressing Ctrl+C on the crash reporter window (then pasting it to a text file), which seems to have worked. I've uploaded the two logs here (http://www.mediafire.com/download/qw7k336t1upb5sa/Crash+and+debug+log.rar).
noee
14th July 2015, 17:24
madshi,
I'm getting an immediate crash with jRiver MC20b129 as soon as I open an MKV for playback with 17. 16b is fine, seems like what the other guys are getting, would you like a crash report or do you have enough? MPC-HCx64, however, is not crashing...
huhn
14th July 2015, 17:33
I would be interested in a reply to the very same question. :)
h264, 8bit, 4:2:0 - NV12, 8bit, 4:2:0
means this:
h264 8bit is the source video. codec and bit deep.
NV12 is the decoded frame format. lavfilter or any other decoder is decoding these frames to this example format.
NV12 is a 8 bit 4:2:0 colorspace could be YV12 too doesn't matter.
or in short it is what madVR gets as input.
madshi
14th July 2015, 17:36
I'm getting an immediate crash with jRiver MC20b129 as soon as I open an MKV for playback with 17. 16b is fine, seems like what the other guys are getting, would you like a crash report or do you have enough?
A crash report is always helpful, so yes, I would like to see it. It could be the same as the one from Ver Greeneyes and James Freeman (which is identical), but it could also be a different one. One quick look at it and I know.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.