View Full Version : madVR - high quality video renderer (GPU assisted)
Thunderbolt8
2nd April 2011, 20:47
that could be it in case of madvr. only that 1 remux is YV12, the others are YUY2 (if reclocks report is reliable). doesnt seem to explain the different behaviour of haali and evr though.
does that now mean that I cannot watch these 4 sources with madvr at all? have they been broadcasted differently, are there different standards for those broadcasts?
edit: set output colourspace of dscaler decoder from YUV12 to YV12, now it works fine with madvr (and EVR) for those files. but is that colourwise ok to do so, will there be any alternation of the original picture or loss of quality when I do so?
madshi
2nd April 2011, 21:09
Reclock just reports what the decoder outputs, not the real source format. Ask eac3to which format those broadcasts have. If they're truely 4:2:2, eac3to will tell you that.
kasper93
2nd April 2011, 21:26
(2) subtitles disappear when pausing playback (caused by the "Pause" OSD message)
Problem is fixed, but not for all OSD languages. For example English, French and German works fine, but polish, Russian and Swedish not. I don't know why is that and maybe it's only me, but I'm using Polish lang and I will be grateful, if you could check this.
madshi
2nd April 2011, 21:30
Subtitles disappearing when paused can't have much to do with the subtitle language because madVR doesn't even know which language a subtitle has. madVR also doesn't know if and when you switch subtitle languages. That's all handled by MPC-HC. All madVR does is notify MPC-HC that subtitles for frame X needs to be rendered and then MPC-HC takes over and does all the work.
I'm not saying that it's impossible that subtitles can disappear when you pause movie playback. It doesn't happen for me, but it's possible that it occurs. If it does, there's not much I can do about it right now. This should get better with a future version, though, when I reorder the rendering chain. That's some revisions ahead, though.
nevcairiel
2nd April 2011, 21:31
How could you discriminate certain languages, how politically incorrect of you!
Sorry, couldn't resist. :)
kasper93
2nd April 2011, 21:37
Not subtitle language, but MPC-HC OSD messages language. But I thinks it also doesn't matter much.
nehcrow
3rd April 2011, 06:20
i need help, im using MPC-HC
i recently installed the madVR renderer but now i can't view subtitles
i changed it back to system default and subtitles can be viewed
it's not like the subtitles options are greyed out or anything, the subtitles options are still there, it just doesn't render
madshi
3rd April 2011, 06:43
@nehcrow, make sure you use MPC-HC version 1.5.2.3005 or newer and the latest madVR version (currently v0.48).
oddball
3rd April 2011, 07:48
If I switch Luma upscaling to bilinear in order to take some pressure off my low spec video card when playing back 720p stuff does it have any affect on 1080p video?
madshi
3rd April 2011, 07:57
madVR only applies scaling if it has to. If your display is 1080p and the content is 1080p and your media player does not ask madVR to apply any scaling then madVR will not scale. You can double check that in the OSD (movie resolution + target rectangle match = no scaling).
oddball
3rd April 2011, 08:42
madVR only applies scaling if it has to. If your display is 1080p and the content is 1080p and your media player does not ask madVR to apply any scaling then madVR will not scale. You can double check that in the OSD (movie resolution + target rectangle match = no scaling).
I don't get that. Whatever I set Luma to, 720p and 1080 show movie resolution as source res and target rectangle as 0,0, 1920 x 1080. But I know 720p is using more GPU using GPU-Z. I'm not sure if 1080p sources are though. It does not seem to jump as much so maybe it doesn't.
nehcrow
3rd April 2011, 08:44
thanks madshi, it worked :)
they really should update the mpc-hc sourceforge website haha
madshi
3rd April 2011, 10:16
I don't get that. Whatever I set Luma to, 720p and 1080 show movie resolution as source res and target rectangle as 0,0, 1920 x 1080. But I know 720p is using more GPU using GPU-Z. I'm not sure if 1080p sources are though. It does not seem to jump as much so maybe it doesn't.
If the movie resolution is identical to the target rectangle, then madVR does not scale. It's as easy as that.
kasper93
3rd April 2011, 11:01
@madshi
Can you explain what means all four values of target rectangle?
I get:
movie resolution 1920,1080
target rectangle 0,60,1920,1140
and I want to know why :) my screen resolution is 1920x1200.
madshi
3rd April 2011, 11:06
The target rectangle is the rectangle into which the media player wants the video to be rendered. The 4 numbers are "left, top, right, bottom". If you want to compare the target rectangle with the movie resolution, you need to do a small bit of math. The movie resolution is "width, height". You can convert the target rectangle to "width, height", too, by calculating "width = right - left" and "height = bottom - top". So in your case you'd have "width = 1920 - 0 = 1920" and "height = 1140 - 60 = 1080". So in your case there's no scaling because movie resolution is identical to target rectangle size.
Thunderbolt8
3rd April 2011, 12:11
no scaling even though the movis is 1080p, but the screensize is x1200? wouldnd the picture have more black bars than normal then?
pankov
3rd April 2011, 12:16
Thunderbolt8,
yes there would be thicker black bars if the movie is not 16:9 but let's say 2.35:1.
If there were some scaling you'll either get wrong aspect ratio (taller and thinner people) or you'll miss some parts of the screen on the sides.
So to sum it up - if your screen has enough horizontal width to accommodate the width of the video and enough vertical height to accommodate the height of the video there won't be any scaling done.
pirlouy
3rd April 2011, 13:46
(HS: Maybe just me, but I use "touch window from outside" in MPC-HC in order not to have black bars.)
ryrynz
3rd April 2011, 14:23
Madshi, the D3D Fullscreen option gives us automatic fullscreen on playback which I find useful in MPC (I don't have to push the fullscreen button on my remote after I press play) Is it possible to provide us this this feature aside from using this?
noee
3rd April 2011, 14:26
Madshi, the D3D Fullscreen option gives us automatic fullscreen on playback which I find useful in MPC (I don't have to push the fullscreen button on my remote after I press play) Is it possible to provide us this this feature aside from using this?
Why is that necessary when in the Playback/Fullscreen tab, MPC-HC has an option called "Launch Files in Fullscreen"?
madshi
3rd April 2011, 14:31
Controlling the size and state of the video window is the duty of the media player. If you want features that have to do with window size/state you need to ask the media player devs, not me.
madshi
3rd April 2011, 17:09
madVR v0.49 released
http://madshi.net/madVR.zip
* fixed: settings could not be edited if a monitor had a unicode name
* fixed: settings dialog with tray icon disabled took a long time to appear
* fixed: sometimes "madVR instance didn't reply properly" appeared
* settings are now stored under "HKCU\Software\madshi\madVR\Settings", too
* LAN support is disabled by default now, can be enabled through tray icon menu
Next thing on my list is the final fullscreen exclusive mode rendering path. I've a bit of free time currently, so expect it in the next few days... :)
sneaker_ger
3rd April 2011, 17:16
* settings are now stored under "HKCU\Software\madshi\madVR\Settings", too
Seems to work just fine, Thx.
CruNcher
3rd April 2011, 17:17
hehe esets heuristic doesn't like madHcCtrl.exe obviously false alert http://www.virustotal.com/file-scan/report.html?id=9073685f4cbf12c3bd293349b9e26e6926e6aefe095b2f856677a3b356f2993c-1301847525
madshi
3rd April 2011, 17:25
hehe esets heuristic doesn't like madHcCtrl.exe obviously false alert
Argh, I hate stupid false alarms. The file is even properly signed, stupid eset!
Anybody knows an eset contact address for false alarms?
fastplayer
3rd April 2011, 17:30
* settings are now stored under "HKCU\Software\madshi\madVR\Settings", too
Isn't writing to settings.bin and registry a bit redundant? IMO an approach like this would be more practical:
If settings.bin is writable and located in the same directory as madvr.ax, don't write to registry. Otherwise, write to registry, by default.
This way you have maximum portability and consistency (What happens when there's a mismatch between registry and settings.bin? Which settings location has a higher priority? etc.).
janos666
3rd April 2011, 17:42
Anybody knows an eset contact address for false alarms?
There is an option "Submit files for analysis". I sent it in and asked them to investigate the false alarm.
madshi
3rd April 2011, 17:44
Isn't writing to settings.bin and registry a bit redundant? IMO an approach like this would be more practical:
If settings.bin is writable and located in the same directory as madvr.ax, don't write to registry. Otherwise, write to registry, by default.
This way you have maximum portability and consistency (What happens when there's a mismatch between registry and settings.bin? Which settings location has a higher priority? etc.).
Hehe. I almost waited for your comment... :p
Writing to the registry should always work. Writing to the file will work only if madVR has write access rights. I'm writing to the registry because writing to the file doesn't always work. I'm writing to the file because it's good for portability. Why am I writing to both, even if writing to the file already works? Because if you delete the folder and reinstall madVR, the settings are still stored in the registry, so your settings are not lost. Basically you can see the registry storage as a "fail safe" in case the file gets accidently deleted or corrupted.
Consistency is not a problem. There's a version number (8 bytes) stored in the settings data which is increased by 1 every time you edit the settings. If madVR finds both a settings file and settings in the registry, madVR automatically uses the settings with the higher version number.
There is an option "Submit files for analysis". I sent it in and asked them to investigate the false alarm.
Thanks.
CruNcher
3rd April 2011, 17:45
Hmm it seems also really inefficient with Nvcuvid as decoded input (default settings) ? same for Haalis Renderer too like 4 fps, with CPU as input its Realtime though hmm.
Ehh was that me oopsy
http://img849.imageshack.us/img849/7292/wasthatmeoops.png
SamuriHL
3rd April 2011, 17:46
Argh, I hate stupid false alarms. The file is even properly signed, stupid eset!
Anybody knows an eset contact address for false alarms?
Getting the same issue. I don't know their address off the top of my head. I'm sure it's on the eset site somewhere. I was like "wait, what?? RESTORE you idiot virus scanner!!!" :D Definitely a false positive.
fastplayer
3rd April 2011, 17:53
Hehe. I almost waited for your comment... :p
Your approach is much better than mine. Using the registry as a fail-safe is a great idea!
:thanks:
janos666
3rd April 2011, 17:54
I don't know where is the problem, but I installed MPC-HC v1.5.2.3010 and madVR v0.49 on my friend's PC and subtitles doesn't work.
I have a slightly older MPC-HC and madVR 0.48 at home and it works.
(I disabled every internal filters and installed LAV splitter and FFDShow, just like I do it at home.)
The Subtitle option is grayed out in MPC-HC (I tried an mkv file with internal subtitles and I also placed an srt file next to the mkv file with the same filename.
sneaker_ger
3rd April 2011, 17:58
Did you activate "Auto-load subtitles" in MPC-HC options under "Playback"?
janos666
3rd April 2011, 18:00
Did you activate "Auto-load subtitles" in MPC-HC options under "Playback"?
Yes, and this is the default setting anyway.
sneaker_ger
3rd April 2011, 18:05
Sounds very strange to me. I just tested madVR 0.49 + mpc-hc 3010 + ffdshow 3785 + lav 0.19 without any problem.
Are you sure madVR is being used? MPC will switch to another renderer if ffdshow is not configured to output to a compatible colorspace.
madshi
3rd April 2011, 18:05
Hmm it seems also really inefficient with Nvcuvid as decoded input (default settings) ? same for Haalis Renderer too like 4 fps, with CPU as input its Realtime though hmm.
The problem is probably that Nvcuvid (and CoreAVC when using CUDA) has to transfer the decoded frames back from GPU RAM to System RAM. That can be very slow, depending on your GPU, driver version and OS. When using DXVA, typically the frames stay on the GPU. That's why DXVA performs a bit better. Although, it depends on the decoder. You could also write a DXVA decoder that transfers the frames back to System RAM, if you wanted to. Then probably performance would be comparable to Nvcuvid. If that topic is interesting to you, you can run my madNV12Test benchmark here:
http://forum.doom9.org/showthread.php?p=1484447&highlight=madnv12test#post1484447
This benchmark measures how fast NV12 textures can be transfered from GPU RAM to System RAM.
Getting the same issue. I don't know their address off the top of my head. I'm sure it's on the eset site somewhere. I was like "wait, what?? RESTORE you idiot virus scanner!!!" :D Definitely a false positive.
The problem is that AV companies don't have much to lose by those false alarms. In the real world you could sue someone for reporting false information about your business. In the AV world, that doesn't seem to work, unfortunately. So we software developers have to live with that all the time... :mad:
Your approach is much better than mine. Using the registry as a fail-safe is a great idea!
Thanks... :)
I don't know where is the problem, but I installed MPC-HC v1.5.2.3010 and madVR v0.49 on my friend's PC and subtitles doesn't work.
I have a slightly older MPC-HC and madVR 0.48 at home and it works.
(I disabled every internal filters and installed LAV splitter and FFDShow, just like I do it at home.)
The Subtitle option is grayed out in MPC-HC (I tried an mkv file with internal subtitles and I also placed an srt file next to the mkv file with the same filename.
Do subtitles work with EVR/VMR?
CruNcher
3rd April 2011, 18:16
Reset to Default Settings in the GUI or in the Tray Icon would be nice ;)
The excessive customizeability though is a real plus compared to haalis renderer :)
SamuriHL
3rd April 2011, 18:17
The problem is that AV companies don't have much to lose by those false alarms. In the real world you could sue someone for reporting false information about your business. In the AV world, that doesn't seem to work, unfortunately. So we software developers have to live with that all the time... :mad:
I know. SlySoft has to deal with it all the time, as well. Pretty much all developers deal with it at one point or another. The annoying part for end users is when something is flagged as quarantined, the idiots don't give you a "I know this is safe, ignore it" option on the big scary red dialog that pops up. You have to go mess around inside the AV settings to work around it. In most cases I shut off the AV until I download it and then add it to the exclusion list. What a pain.
SamuriHL
3rd April 2011, 18:24
Reset to Default Settings in the GUI or in the Tray Icon would be nice ;)
Actually, yea, this is a really good idea. If you're going to use the registry as a backup, a "reset to default" would be a really quick and easy way to reset a borked install. Even if it's just a batch file or something that'd be helpful.
madshi
3rd April 2011, 18:28
Reset to Default Settings in the GUI or in the Tray Icon would be nice ;)
The excessive customizeability though is a real plus compared to haalis renderer :)
Yeah, a reset to default settings option definitely makes sense. It's on my to do list.
I know. SlySoft has to deal with it all the time, as well. Pretty much all developers deal with it at one point or another. The annoying part for end users is when something is flagged as quarantined, the idiots don't give you a "I know this is safe, ignore it" option on the big scary red dialog that pops up. You have to go mess around inside the AV settings to work around it. In most cases I shut off the AV until I download it and then add it to the exclusion list. What a pain.
I just wish end users would complain about false alarms more to the AV companies and less to the poor false alarm'ed software devs. Maybe that would make AV companies change their stance. Maybe some day they will advertise with "lowest false alarm rate in the industry!". Haven't seen anyone claim that yet. Probably for a reason.
I'm not in a too bad situation, though, I guess, cause most of you guys are experienced enough to identify a false alarm right away. I guess doom9 users are simply much more experienced than other users.
janos666
3rd April 2011, 18:29
Do subtitles work with EVR/VMR?
No, they don't. Strange because they worked before I updated to x.3010 (The previous version wasn't too old, may be some 298x ; The splitter recognizes the subtitles in the mkv file.)
SamuriHL
3rd April 2011, 18:33
Yeah, a reset to default settings option definitely makes sense. It's on my to do list.
Sweet. That'll be helpful for sure.
I just wish end users would complain about false alarms more to the AV companies and less to the poor false alarm'ed software devs. Maybe that would make AV companies change their stance. Maybe some day they will advertise with "lowest false alarm rate in the industry!". Haven't seen anyone claim that yet. Probably for a reason.
I'm not in a too bad situation, though, I guess, cause most of you guys are experienced enough to identify a false alarm right away. I guess doom9 users are simply much more experienced than other users.
I couldn't agree more. I've submitted it with a "fix this it's a false positive" as well but I have no idea how seriously they take that until they get deluged with those reports. And yes, if you KNOW where you're getting your software from it's pretty easy to spot a false positive. For the average user, maybe not.
madshi
3rd April 2011, 18:38
No, they don't. Strange because they worked before I updated to x.3010 (The previous version wasn't too old, may be some 298x ; The splitter recognizes the subtitles in the mkv file.)
3010 works for me. Tested with Haali's MKV Splitter.
janos666
3rd April 2011, 18:52
3010 works for me. Tested with Haali's MKV Splitter.
http://forum.doom9.org/showpost.php?p=1489641&postcount=16801
Rain1
3rd April 2011, 20:21
Hehe. I almost waited for your comment... :p
Writing to the registry should always work. Writing to the file will work only if madVR has write access rights. I'm writing to the registry because writing to the file doesn't always work. I'm writing to the file because it's good for portability. Why am I writing to both, even if writing to the file already works? Because if you delete the folder and reinstall madVR, the settings are still stored in the registry, so your settings are not lost. Basically you can see the registry storage as a "fail safe" in case the file gets accidently deleted or corrupted.
Consistency is not a problem. There's a version number (8 bytes) stored in the settings data which is increased by 1 every time you edit the settings. If madVR finds both a settings file and settings in the registry, madVR automatically uses the settings with the higher version number.
Thanks.
Wow, that's quite thoughtful solution :)
My question: If i uninstall old version (instead of delete the folder), that will remove my settings that saved in registry, right ?
Also, thanks for yr trayicon fix /
madshi
3rd April 2011, 20:26
Wow, that's quite thoughtful solution :)
My question: If i uninstall old version (instead of delete the folder), that will remove my settings that saved in registry, right ?
No, not yet. The install/uninstall only registers/unregisters madVR for DirectShow usage. There's no "real" installer/uninstaller yet. Maybe some time later...
cyberbeing
3rd April 2011, 20:34
With 0.49 an iconless madhcctrl is shown flashing (usually triggered by a unfocused window that has changed) in my taskbar on WinXP, whenever madVR settings are opened. You seem to have set it to always-on-top but leaving it unfocused.
Could you revert the setting dialog to it's old behavior with nothing in the taskbar?
If not, then hopefully you can make a change which gives the setting window focus when opened, to stop the taskbar flashing.
Either how madHcCtrl (a network app) is calling that window, or the fact that it now reads/writes the registry, may be what is causing it to get flagged by ESET's advanced heuristics or suspicions file detection. Are advanced heuristics in ESET even enabled by default? I haven't used ESET in awhile, but when I did, I always had them disabled.
madshi
3rd April 2011, 20:42
Could you revert the setting dialog to it's old behavior with nothing in the taskbar?
I didn't really change anything in madHcCtrl's behaviour. However, I switched to a newer development system version. That seems to have triggered this change somehow. I haven't even noticed it myself yet. Anyway, it should be easy to fix.
Just to be safe: Having nothing in the taskbar is all that is needed to fix the problem, right?
cyberbeing
3rd April 2011, 20:50
Just to be safe: Having nothing in the taskbar is all that is needed to fix the problem, right?
Yes, I believe so. No need to mess with the tray though.
madshi
3rd April 2011, 20:55
No need to mess with the tray though.
What do you mean?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.