Haali Video Renderer

[In Libman]

Butnow after I upgraded to Windows 10 and Zoom Player 10.5, half of my Videos (regardless the format), I see a black screen, however the sound is playing correctly, and the preview thumbnails while hovering above the progress bar are getting shown too.

Welcome to the forums Hm, I haven't updated to Windows 10 as yet - is there anyone else on Windows 10 who can quickly test this? One thing you can try - reinstall Haali's from Install Center and see if it changes anything.

We generally only have debug versions of Zoom created for specific problems, there is no general debug version available. However, there is something else we can try to see if it is a Zoom problem (I don't think it is at this stage). Download MPC-HC:

Pick the 32bit, ZIP version. Extract the files in the zip to a temporary folder, and then run the mpc-hc.exe file. When MPC-HC opens, go View->Options. In the options, look for Playback->Output and click it (the Output section I mean). There is an option in this section, at the top titled "DirectShow Video" - from the dropdown, select "Haali Video Renderer" and then click Ok. Close MPC-HC and then open it again. Now, go File->Quick Open File and locate a video file to play (preferably the same one you are trying to play in Zoom which fails).

At this point, MPC-HC will either play the file correctly, or it won't (ie the same thing will happen that you see with Zoom). If the latter, it's definitely an issue with Haali, and you would need to contact the Haali developer to see if he can troubleshoot it. If the former, it's not a general Haali issue, and and will need to try and narrow down what is going on (not entirely sure how at the moment, but will cross that bridge if we need to).

When the Output is set to any renderer, when I switch between Fullscreen on/off, almost every fourth or fifth time, the screen turns black, and I have no more means to manually kill the ZP-process, so hard reset...

This is really odd - I can't think of any option in Zoom which would affect all the video renderers. I wonder if it is something in your video driver - if video output was generally broken in Win 10, we would have had a few complaints by now. What are your system specs (especially video hardware), and what video driver version are you using? Also, are you using hardware acceleration in the video decoder settings?

I am wondering if the last one may be because the display driver may have stopped responding - I get this a lot on my system, and have had for the last few NVIDIA driver versions. I don't know if this is still present in Windows 10, but at least on Windows 7, you can check the Event Viewer to see if at the times this happens, there are corresponding display driver failures. So when you have one, after you close Zoom, open Event Viewer and see if there is an entry there for the last few minutes for this type of thing. In Windows 7, you could open Event Viewer by going into Control Panel, typing 'event viewer' in the search field, clicking the resulting 'View Event Logs' entry, and then when Event Viewer opens, navigating to Windows Logs-->Systems. It should show something like this (the last event of this type I had on my system about half an hour ago):

@Lobo: If you check for Windows updates and make sure everything offered is installed, do you see the same thing? And is it the same issue that jhemp had reported with his system (ie the blank image during playback if Haali is used)?

Finally managed to get Windows 10 installed on my laptop - no issues with Haali here (all Windows updates are installed), so at least with the current crop of Windows fixes installed, it isn't an issue with Zoom generally, which is good.

Along the same kind of thinking, you say madVR only takes raw video - do other renderers take compressed video as input?? Again, I thought the video codec handled all that and the renderers always required 'raw' video...?

I assumed raw meant decoded (i.e. NOT h.264 or MPEG-2 or the like), but I suspect you are implying that raw means something else - do you mean like RGB32 as compared to another colorspace or something?

I didn't know any renderer (the last item in the chain) took encoded video (e.g. h.264) as input - however I guess with DXVA the decoder is more of a pass-through and gives the compressed stream to the graphics card to handle... is that anything to do with what you meant?? (sorry, this is confusing!!)

The MPC-HC subtitle renderer now fully works with madVR! However, I had to fix a couple of bugs in MPC-HC to make it work properly. Furthermore I've patched MPC-HC so that it now draws its text messages by using madVR's internal OSD text message system. My bugfixes are already committed to the MPC-HC SVN, so all new SVN builds compiled by other people should also work just fine with madVR v0.44. For your convenience I've uploaded a fixed MPC-HC executable file here:

-hc.zip

DXVA comes in different flavours from what I've read. Full-capability cards will do the whole decoding process in the GPU - i.e. the decoder hands the driver the encoded bitstream and gets fully-decoded video back. However in the not-too-distant passed, an earlier form of DXVA required some work by the CPU (in the decoding), with only some other stages handled by the GPU.

It's best described here where it talks about the difference between Partial and Complete acceleration in the Nvidia PureVideo DXVA solutions...

_Feature_Sets

Yes, ffdshow subs have lower quality and less compatability. The lower quality applies especially for SD content. Because with ffdshow the subs are burned into the video *before* scaling. While with the MPC-HC internal subtitle renderer, the subs are drawn onto the video *after* scaling. Meaning that the subs have a much higher resolution with MPC-HC, when you upscale the video. Of course this doesn't apply to HD content.

Edit: One thing I have only just remembered about Haali's and EVR when used with Zoom (problem does not affect other players such as MPC-HC) is that when you pause the video, Zoom skips to the next frame, which is pretty annoying. So add that to the negatives for both renderers. With EVR, it happens on every video file. With Haali's, it only happens on some video files (there is a recent thread about the problem on page 2, and an older thread just for the EVR issue elsewhere on the forum).

Thought I'd just update this topic a little. I know the original part of the thread is 3 years old now, but I occasionally check the forum's online users list just to see what threads are popular - and I quite frequently see this one being viewed (usually by a guest logon, which means someone not logged into an account on the forum, which probably means they came here via a google search for 'best renderer' or similar).

Anyway, some things have changed over the last 3 years since I did the dot point list in post #3 in the thread, so I thought I would compile a new list and just keep it up to date as changes are warranted. So, here we go!

VMR (VMR7 & VMR9)

The good:

My system is relatively new - and I suspect that this will be so for most people reading this topic - so for me, that leaves the race between 2: madVR and EVR. In my post #3 above, I listed 3 renderers here - EVR, madVR and Haali's. I can no longer recommend Haali's for the reasons detailed below. Keep in mind that if you currently use Haali's and have no issues with it, the information I have listed below is no reason to change your renderer. Though it does not work well for me, if it is working well for you there is no reason to change it. The same would apply if you don't currently use Haali's but were trying to find a renderer that worked for you - try it. If it doesn't work well for you, you haven't lost anything except a small amount of your time.

EVR

The good:

Personally, I now use madVR as my main renderer, only swapping to the other renderers for bug-testing and troubleshooting purposes. EVR is good - but I do notice a slight increase in the image quality of some clips when using madVR. Putting that aside, EVR is the least problematic renderer for my system overall, as it doesn't push the hardware envelope as much as madVR.

Still, I prefer madVR - when the current version is working well with my system that is, as it is at the moment - so that is what I use currently. I personally do not have fullscreen exclusive mode enabled in madVR, and would advise others to have it disabled as well, but it's a personal choice (it can improve playback in some cases, but it has some side-effects). The reason why I have it disabled is that I see too many problems with it:

None of those occur with fullscreen exclusive disabled. Anyway, your mileage with madVR - as the old saying goes - will vary, I guarantee it. How well madVR works is very dependent on your system. It may work fantastically on your system, it may work horribly on your system - or it may be somewhere in-between (some good things, some bad things).

MadVR has some other notable features as well:

- tuning of the scaling algorithms to your personal taste.

- automatically set display refresh rate based on content (the only way to achieve this in ZP?)

- Use of a custom ycms calibration file for further fine tuning video quality.

- detailed live statistics

A video renderer is software that processes a video file and sends it sequentially to the video display controller card for display on a computer screen. An example of a video renderer, is the VMR-7 that was used by Microsoft's DirectShow. An example of a UNIX video renderer is the one container within GStreamer.

Using OneCoreApi injection (not installing OneCoreApi on the system), I was able to run MPC-BE version 1.6.6 (a fork of MPC-HC). It has AV1 and AVS3 codecs, but no hardware acceleration, not even for h264. And because VMR7/9 were removed I have to install madVR. But MPC-HC even with OneCoreApi injection could not start.

3a8082e126