MPC Video Renderer support

[fenir]

Hello

MadvR is very old video renderer,  DVBViewer could add support new mpc video renderer ( 32 bit version is available):

 

 

 

MPCVideoRenderer-v0.4.10.1535_git2020.12.14-fc1270b.zip

[Griga]

Thanks for the hint. An important point for DVBViewer is an interface for outputting the OSD bitmaps, as provided by MadVR (see mvrInterfaces.pas -> IMadVROsdServices.OsdSetBitmap). Does something like this already exist?

 

[fenir]

I am not the author of this renderer, i found it on the russian forum because i use it from time to time MPC-BE player. Here is a link to the russian support forum, but you need to know russian, no english support.

 

https://mpc-be.org/forum/index.php?topic=381

 

Thank you for your interest in this topic, but it will probably to hard get full support for DVBViewer.

 

Greetings.

Edited December 15, 2020 by fenir

[lastcameleon]

It's a good open source renderer from the authors of MPC-BE, and it's hosted on github too: https://github.com/Aleksoid1978/VideoRenderer. The renderer support 'IMFVideoMixerBitmap' if this interface can help with OSD.

 

The author(s) are working on support for HLG and HDR10, you can get more information and download nightly builds in the doom9 forum under the section for MPC-BE.

 

Good luck.

 

[Griga]

6 hours ago, lastcameleon said:

IMFVideoMixerBitmap

 

This is one of the EVR interfaces. If you try the standard EVR (Enhanced Video Renderer) in DVBViewer, you can see that the OSD quality is quite poor. Furthermore you can't ouptut an OSD with it in paused or stopped state, only as long as the video is running, which is a major drawback that requires difficult work-arounds. So it's not really attractive....

 

[blasgl]

Sorry people, but saying that madVR is very old and implying that it needs a replacement is unthankful at best.

 

Madshi has created what it can be regarded as the most flexible and best quality DirectShow renderer out there, made it available for free and helped with the integration in the DVBViewer.

 

IMHO with DVBViewer you have only two practical options:

1) EVR Custom for the easiest setup and excellent performance.

2) madVR for best performance or best quality, depending on what your taste is.

 

I do not see any pressing need right now to integrate another renderer in DVBViewer, but if can be easily done I´m all for trying something new.

[ter9999]

MPC Video Renderer is very friendly for HDR content and it has added a bunch of new features till Jan 2022.

Since DVBViewer's currently not supporting it, I use MPC-HC to play DVBViewer timeshift file in order to use the MPC Video Renderer.

Clumsy but it's the only way for now. Suggest DVBViewer adding the MPC Video Renderer support.

 

 

 

 

Edited May 5, 2023 by ter9999

[Griga]

I'm still missing a documentation of the MPC Video Renderer interfaces that can be used by applications. Such a component is pretty useless if there is no known way to communicate with it.

 

[ter9999]

On 1/24/2022 at 2:45 AM, Griga said:

I'm still missing a documentation of the MPC Video Renderer interfaces that can be used by applications. Such a component is pretty useless if there is no known way to communicate with it.

 

I'm no developer, but an end user, so can't provide technical details on MPC VR. Maybe there is useful info on https://github.com/Aleksoid1978/VideoRenderer/blob/master/Readme.md

 

And I tried ProgDVB and some other media players, they've added the MPC VR already alongside the MadVR.

 

 

Edited May 5, 2023 by ter9999

[ter9999]

MPC VR has added the latest nVidia RTX Video Super Resolution (VSR) support. This is a much-anticipated feature for AI video upscaling, strongly suggest DVBViewer adding MPC VR support!

 

 

 

 

 

Edited May 5, 2023 by ter9999

[Webturtle]

Hello,

 

@ter9999: How do you use MPC Video Renderer with with MPC-HC? I can't find a setting option in my MPC-HC (64-Bit) 1.7.13.

 

 

Many greetings

 

Webturtle

[lastcameleon]

16 hours ago, Webturtle said:

Hello,

 

@ter9999: How do you use MPC Video Renderer with with MPC-HC? I can't find a setting option in my MPC-HC (64-Bit) 1.7.13.

 

 

Many greetings

 

Webturtle

 

You will need MPC-HC build by CLSID2 https://github.com/clsid2/mpc-hc/releases/.

 

On 1/23/2022 at 6:45 PM, Griga said:

I'm still missing a documentation of the MPC Video Renderer interfaces that can be used by applications. Such a component is pretty useless if there is no known way to communicate with it.

 

 

It uses the same Interfaces as the old DXR Renderer (from the old Matroska); ISubRenderCallback, ISubRenderCallback2 and ISubRender, in addition to it's own interfaces (in the Include directory).

Edited March 3, 2023 by lastcameleon

[Webturtle]

Hello,

 

@lastcameleon: Thanks very much!

 

I had thought and so it was on the website that MPC-HC would no longer be developed, only MPC-HC BE.

 

 

Many greetings

 

Webturtle

 

[ter9999]

madVR development has been abandoned by the author.

MPC VR is the current popular choice by many video players, like Video LAN, PotPlayer, etc.

Hope DVBViewer can add the MPC VR support sooner than later.

 

[Griga]

On 4/17/2023 at 5:56 AM, ter9999 said:

Hope DVBViewer can add the MPC VR support sooner than later.

 

Rather later Yesterday I've tried to integrate the MPC Video Renderer in DVBViewer. Basically watching TV and playing videos works with it. However, as already suspected, the OSD is the crucial point. I've followed this suggestion:

 

On 12/17/2020 at 1:09 PM, lastcameleon said:

The renderer support 'IMFVideoMixerBitmap' if this interface can help with OSD.

 

It's the interface that DVBViewer also uses for outputting the OSD with the standard EVR Renderer (not custom), so I thought the same results could be achieved easily. Unfortunately the MPC VR only supports this interface partly.  When I tried to pass the OSD as Direct3D surface via SetAlphaBitmap, as for the standard EVR and as specified by Microsoft, MPC VR returned an E_INVALIDARG error.

 

A closer look at the MPC VR source code revealed that only passing the OSD as old-fashioned GDI bitmap is supported. GDI does not really allow for per-pixel transparency, which is required for the DVBViewer OSD. Since MPC VR internally converts the bitmap to a D3D surface anyway, this limitation seems to be quite unnecessary.  Here you can see the result:

 

HbbTV OSD (passed as D3D surface) with the standard EVR and per-pixel transparency:

 

 

The same OSD passed as GDI bitmap to MPC VR. Per-pixel transparency is lost:

 

 

Furthermore MPC VR crashes with access violations, when DVBViewer releases the IMFVideoMixerBitmap interface on playback termination, and refuses to be used on another (new) playback start. Making MPC VR work again requires restarting DVBViewer. This makes the interface completely unusable.

 

Since the OSD is an important part of DVBViewer Pro, I can see no way to add MPC VR support at present.

 

[Griga]

Well, there is some progress now:

 

On 4/25/2023 at 8:37 AM, Griga said:

Furthermore MPC VR crashes with access violations, when DVBViewer releases the IMFVideoMixerBitmap interface on playback termination

 

Fixed. The reason for it was not the MPC Video Renderer, but some overlooked DVBViewer code that still expected a D3D surface (containing the OSD) being present, instead of the GDI bitmap required for MPC VR.

 

On 4/25/2023 at 8:37 AM, Griga said:

A closer look at the MPC VR source code revealed that only passing the OSD as old-fashioned GDI bitmap is supported. GDI does not really allow for per-pixel transparency, which is required for the DVBViewer OSD.

 

Well, most of the GDI API doesn't support per-pixel transparency. But there is an exception. This interesting article that I've found in the web describes how per-pixel transparency can be achieved with pure GDI. It requires some cumbersome and ineffective transformation of the image data, but it works with MPC VR. The key term is "premultiplied per-pixel alpha".

 

This means in practice, that every color component (red, green blue) of each pixel must be multiplied by its transparency value (from the alpha channel) and divided by 255, or with other words, brightness must be decreased according to the transparency. Quite a lot of calculating... for each full HD OSD plane it must be performed 1,920 x 1,080 x 3 = 6,220,800 times. Additionally, since MPV VR finally converts the passed bitmap to a D3D surface, it must probably reverse this transformation.

 

Furthermore the transparency value for each pixel, as used in D3D surfaces, has to be inverted for some reason, when passing a GDI bitmap to MPC VR. The article (see links above) doesn't mention it. I had to find it out by trial and error. So it's really a pity that MPC VR doesn't support passing the OSD as D3D surface. It would be straight forward and save a lot of code and work-around trouble.

 

Anyway, let's have a look at the resulting OSD with MPC VR:

 

 

This is roughly how it should look like. The colors are ok, transparency is ok. However, the OSD is quite pixelated. I've already seen this bad quality several times before. It also happens with standard video renderers like the EVR, if a GDI bitmap and a NVidia GPU are involved. Probably the result of a bad downscaling algorithm. Here it neither occurs with NVidia & D3D surfaces, nor with Intel GPUs & GDI bitmaps. Most likely it could be avoided if MPC VR would support passing the OSD as D3D surface.

 

On my PC (with Windows 10 and a NVidia GTX 660) it can also be fixed by opening the MPC VR property page, switching "Use Direct3D 11" off and restarting playback. After that, the OSD looks like this:

 

 

Almost perfect... however, having to switch Direct3D 11 usage off is probably not what people want who ask for MPC Video Renderer support in DVBViewer

 

Anyway, now it looks like there is a chance for MPC Video renderer support in future DVBViewer versions, though there are several more problems to solve. If it will be satisfying in the end, is another question...

 

[ter9999]

Wow!! Can't wait to test any beta versions!

[ter9999]

Per MPC VR author - 

 

The plans do not support this kind of OSD, at least because the renderer supports DX9 / DX11, which means that if a D3D surface is used for OSD, either refuse processing if it does not match DX9 / DX11, or do a DX9 <-> DX11 conversion.

The current OSD support algorithm is quite normal.

[Griga]

6 hours ago, ter9999 said:

or do a DX9 <-> DX11 conversion.

 

Why not? The Microsoft specifications allow passing a IDirect3DSurface9 interface pointer as IMFVideoMixerBitmap::SetAlphaBitmap parameter, so if MPC VR implements this interface, it should work as specified. If MPC VR prefers a proprietary solution, it should rather offer a proprietary interface for it, plus documentation how to use it, like MadVR does

 

Anyway, there is another major drawback of IMFVideoMixerBitmap::SetAlphaBitmap (also concerning the standard EVR). It only updates the OSD while video is playing. In pause mode it doesn't. From the user's point of view the OSD freezes when video stops. Changes like a moving selection bar in a menu are not displayed anymore. That was one of the main reasons for developing a custom EVR based video renderer and using it in DVBViewer. It still displays OSD changes if video stops for some reason (= no new pictures are received by the video renderer).

 

For other video renderers, particularly the Microsoft standard renderers, a dirty work-around had to be implemented, and unfortunately it must also be applied to MPC VR: If the user switches to pause mode, DVBViewer quickly retrieves a screenshot from the video renderer, switches over to its own OSD output, that normally is only used if no video is playing, and uses the screenshot as background picture for it. This hides (covers) the original video renderer output with the frozen OSD completely, until playback starts again.

 

However, this work-around is difficult to organize. And it doesn't work if video suddenly stops for reasons outside DVBViewer, e.g. TV signal loss. If you switch to a channel that doesn't work, the OSD doesn't work either. So it has to be stated that IMFVideoMixerBitmap::SetAlphaBitmap is not really suitable for TV applications, particularly when they are completely controlled via OSD in a HTPC environment. It is acceptable if the normal DVBViewer UI (menu bar etc.) is used, though.

 

BTW: This problem doesn't exist with MadVR. When it came to implementing MadVR support in DVBViewer, Madshi was willing to handle the issue and modified the (proprietary) IMadVROsdServices interface in a way that allowed for keeping the OSD alive even if video stops.

 

8 hours ago, ter9999 said:

Can't wait to test any beta versions!

 

I think you can get one soon, after I have fixed remaining minor issues.

 

[lastcameleon]

Why not use ISubRenderCallback and ISubRender11Callback (in "ISubRender.h" and "ISubRender11.h"), you will get a pointer to the "IDirect3DDevice9" or "ID3D11Device" depending on the interface user by the renderer.

The problem is that you will have to do the rendering if the Graph is stopped/paused and rely on the function ISubRenderCallback::Render(..) or ISubRender11Callback::Render11(..) if the Graph is Running (I didn't test this, just Ideas).

 

Good luck

 

[ter9999]

Per MPC VR author - 

 

 

Personally, I'm not at all interested in this. But if someone decides to implement this - please, I will not mind.

As for changing the OSD on pause - all this is possible in MPC VR, you just need to send it a command to draw, for this there is an IExFilterConfig interface. Let the DVBViewer developer figure it out.

[Griga]

6 hours ago, ter9999 said:

Personally, I'm not at all interested in this. But if someone decides to implement this - please, I will not mind.

 

So users have to live with it as it is. DVBViewer, DMS, TransEdit etc. are already keeping me busy enough. There is no time left for adjusting reluctant third party components to DVBViewer requirements

 

6 hours ago, ter9999 said:

As for changing the OSD on pause - all this is possible in MPC VR, you just need to send it a command to draw, for this there is an IExFilterConfig interface.

 

Good hint! One needs to search the MPC VR code for occurences of "draw" to find it, though. It is well hidden in IExFilterConfig.SetBool. Not really obvious.

 

Anyway, I've just tried... calling IExFilterConfig.SetBool('cmd_redraw', true) after each OSD change lets the MPC VR indeed redraw the OSD, even if there are no new video pictures arriving. This seems to be at least sufficient for handling OSD display in pause mode or in case of sudden signal loss.

 

However, it requires at least one picture that has arrived before, otherwise MPC VR (in contrast to MadVR and Custom EVR) does nothing. So if the user selects a dead channel or streaming source (delivering no data at all), for which DVBViewer build a new filter graph, the OSD remains dead too.

 

I'll check what can be done with it... DVBViewer is more than 20 years old now, and whatever I do has to fit into the existing structures somehow...

 

[Griga]

On 5/2/2023 at 9:27 AM, Griga said:

However, it requires at least one picture that has arrived before, otherwise MPC VR (in contrast to MadVR and Custom EVR) does nothing.

 

I was wrong. After some trial and error I realized that MPC VR requires an initial IBasicVideo.SetDestinationPosition call in any case for displaying the OSD. However, DVBViewer doesn't perform this call if no video data is arriving. It has to be added especially for MPC VR. After that, the renderer always displays the OSD, no matter if video is actually playing or not. That makes it much easier, because now MPC VR can be handled like MadVR in several DVBViewer code sections, without requiring a case distinction.

 

It's pretty hard to find it all out without any documentation

 

[ter9999]

nVidia VSR has outperformed madVR NGU Sharp Very High with less power consumption and better video quality when upscaling TV channels from 720p or 1080i to 4K.

 

UP: madVR NGU Sharp VH 

Down: VSR with MPC VR

[Griga]

@ter9999. @lastcameleon:

 

I've provided a DVBViewer test version for you via PM. You only need to replace DVBViewer.exe in a DVBViewer 7.2.4 installation. After that you can select the MPC Video Renderer on Options -> Playback Components (also for DVD playback and Picture in Picture).

 

The working features are

• Video playback, of course
• OSD including subtitles
• Brightness, contrast etc. settings
• Zoom settings
• Show/hide renderer statistics. It requires adding a command on Options -> Input with the "Toggle Renderer Stats" action and assigning a key to it in learn mode (also works with MadVR and Custom EVR)

Remaining known issues:

• It is not possible to use two instances of MPC VR at the same time, specifically for main window playback and picture in picture (PiP). A second instance refuses to be created. DVBViewer uses the standard EVR as fallback in this case. It seems like MPC VR occupies some resource exclusively. Even the Custom EVR can't be used simultaneously, because it doesn't connect to the video decoder anymore.
• Shaders don't work (the ones from the Shaders sub-directory of the DVBViewer program directory) because I don't know which kind of binary data has to be passed to MPC VR via IExFilterConfig.SetBin.
• Bad OSD quality in Direct3D 11 mode due to bad GDI bitmap downscaling (may depend on the GPU).
• The screen temporarily turns black on channel switching (which includes a filter graph transition to the stopped state). In MPC VR I can't find an option like "keep last frame on stop" in MadVR.

 

[ter9999]

Thanks! I did a quick test that MPC VR can be invoked with normal nice transparent OSD under D3D11.

 

 

Issues so far - 

1. The VSR is not in effect (although Renderer Stats says SuperRes*. * means VSR requested but not guaranteed).

2. Mouse pointer will stay double arrow (<->) when it moves from side into the DVBViewer window.

 

 

Will test more and feedback.

[Griga]

4 hours ago, ter9999 said:

The VSR is not in effect (although Renderer Stats says SuperRes*. * means VSR requested but not guaranteed).

 

Does it take effect if you record the program and play it in another player that supports MPC VR (particularly MPC)?

 

Is there anything known that an application hast to do or to avoid for enabling VSR? There is no direct communication with the graphics card if DVBViewer uses a video renderer like MPC VR. Everything is up to the renderer (and maybe also to a video decoder that uses DXVA2). So I can't imagine in which way DVBViewer could influence it.

 

5 hours ago, ter9999 said:

Mouse pointer will stay double arrow (<->) when it moves from side into the DVBViewer window.

 

Confirmed. The mouse cursor isn't switched back to the normal arrow form. It also happens here, but not with other video renderers. Somehow MPC VR influences the mouse pointer. Will be investigated...

 

[ter9999]

18 minutes ago, Griga said:

 

Does it take effect if you record the program and play it in another player that supports MPC VR (particularly MPC)?

 

Yes, before DVBViewer supported MPC VR, I used MPC-HC to playback temp Timeshift file in order to use MPC VR with VSR upscaling.

 

After a search, it seems VSR only works with a 64-bit player? https://github.com/emoose/VideoRenderer/issues/5

 

[Griga]

32 minutes ago, ter9999 said:

After a search, it seems VSR only works with a 64-bit player?

 

Maybe... the LAV Filters developer told me that graphics card drivers refuse DXVA2 decoding of 8k videos in 32 bit applications due to insufficient memory address space.

 

[ter9999]

8 hours ago, Griga said:

 

Maybe... the LAV Filters developer told me that graphics card drivers refuse DXVA2 decoding of 8k videos in 32 bit applications due to insufficient memory address space.

 

Is that easy to compile a 64-bit version of DVBViewer?

[Griga]

Impossible: https://www.dvbviewer.tv/forum/topic/60610-64-bit-porting/

 

Please don't start discussing it in this thread, because it is about the MPC Video Renderer. Rather start a new thread or continue one of the old ones about 64bit versions.

 

[Griga]

On 5/5/2023 at 12:06 PM, ter9999 said:

Mouse pointer will stay double arrow (<->) when it moves from side into the DVBViewer window.

 

Even worse: Also on other occasions the mouse cursor is not updated while it is inside the video area. Double-click it to change to full screen mode, wait until DVBViewer automatically hides the mouse cursor, double-click again, and the mouse cursor remains hidden in window mode, until it leaves the video area.

 

Somehow using MPC VR prevents the Windows default handling of the WM_SETCURSOR Message in the DefWindowProc function of the video window. The solution is some extra code in DVBViewer that does what the default handling is supposed to do: Set the cursor type if the message arrives while MPC VR is active. It took me one day to find out...

 

[lastcameleon]

On 5/7/2023 at 7:14 AM, Griga said:

 

Even worse: Also on other occasions the mouse cursor is not updated while it is inside the video area. Double-click it to change to full screen mode, wait until DVBViewer automatically hides the mouse cursor, double-click again, and the mouse cursor remains hidden in window mode, until it leaves the video area.

 

Somehow using MPC VR prevents the Windows default handling of the WM_SETCURSOR Message in the DefWindowProc function of the video window. The solution is some extra code in DVBViewer that does what the default handling is supposed to do: Set the cursor type if the message arrives while MPC VR is active. It took me one day to find out...

 

You can just disable the renderer Window, and see if that could fix the mouse problem.

 

What I do in my testing code; is (that work in my case) :
 

if (m_hWnd) { // the window that is the parent of the VideoWindow
    for (HWND pChild=::GetWindow(m_hWnd, GW_CHILD); pChild; pChild = ::GetNextWindow(pChild,GW_HWNDNEXT)) {
      if (!::IsWindow(pChild))
        continue;

      char  szBuff[512];
      szBuff[0] = 0;
      if (::GetClassNameA(pChild, szBuff, sizeof(szBuff))) {
        if (strlen(szBuff) > 0) {
          if (!strcmp(szBuff, "VRWindow")) { // MPCVR video window class
            ::EnableWindow(pChild, FALSE);
            bRes  = true;
          }
        }
      }
    }
  }

 

[ter9999]

Tested the mouse issue has been fixed in the latest beta test version.

Also, the MPC VR can trigger AVR and TV to automatically switch to HDR mode when watching HLG HDR channels. This can't be triggered by madVR (it has poor HLG HDR support).

 

Edited May 10, 2023 by ter9999

[Griga]

11 hours ago, lastcameleon said:

You can just disable the renderer Window, and see if that could fix the mouse problem.

 

Thanks for the suggestion. It looks like a reasonable approach. However, since the parent window catches some messages anyway in DVBViewer (particularly WM_PAINT and WM_ERASEBKGND), it can as well handle WM_SETCURSOR, that is passed to the parent window before the child window processes it:
 

Spoiler

 

 //Delphi pseudo code
 case message.Msg of
    WM_ERASEBKGND:
      if {this or that} then
      begin
        //do nothing in certain situations to avoid flickering
        message.Result := 1; //handled
        Exit; //no default processing
      end;        
    WM_PAINT:
      if Renderer <> nil then
      begin
        Renderer.RepaintVideoWindow;
        message.Result := 0; //handled
        Exit; //no default processing
      end;
    WM_SETCURSOR: //sent whenever the mouse moves inside the video window
      if (Renderer <> nil) and (Renderer.Mode = rmMPC) then 
      begin
        SetCursor(VideoPanel.hCurrentCursor); //set the parent's current cursor type
        message.Result := 1; //handled
        Exit; //no default processing
      end;
  end;

 

 

This was the easiest way to fix the mouse cursor issue. Surprisingly I don't have to do this for the PiP window, that is working more straight forward (no OSD and stuff). I don't know yet which condition in the main window prevents the default WM_SETCURSOR handling if MPC VR is used. In its source code I can find no reason for it.

 

4 hours ago, ter9999 said:

Tested the mouse issue has been fixed in the latest beta test version.

 

Thanks for testing. Looks like the MPC VR support is working now well enough to become part of the next DVBViewer release. Please let me know if there is still something to do.

 

[Bob.Dig]

Am 10.5.2023 um 08:18 schrieb Griga:

Thanks for testing. Looks like the MPC VR support is working now well enough to become part of the next DVBViewer release. Please let me know if there is still something to do.

Please don't do it. The reason is that MPC VR is bad with interlaced video if your refresh rate is higher than 60 Hz. They never fixed it.

 

I use MPC-HC from latest klite codec pack all the time which also includes MPC VR, I have not tested this beta version of DVBViewer.

Edited August 14, 2023 by Bob.Dig

[Griga]

49 minutes ago, Bob.Dig said:

Please don't do it.

 

???

 

I see no reson for not supporting MPC VR in DVBViewer. "Support" doesn't mean that you are forced to use it.

 

[Bob.Dig]

vor 1 Minute schrieb Griga:

"Support" doesn't mean that you are forced to use it.

Good, because problems with interlaced video is not something you want for a Television-app.

 

Or maybe someone (not me) is sponsoring a high refresh monitor for this Russian guy. 😉

[Bob.Dig]

So someone created a fix for the interlacing problem, hopefully it will be integrated into the MPC VideoRenderer soon.

Am 14.8.2023 um 16:38 schrieb Bob.Dig:

The reason is that MPC VR is bad with interlaced video if your refresh rate is higher than 60 Hz. They never fixed it.

 

[adib]

The latest MPC-VR version (0.7.3) fixes the interlacing issue with high-refresh rate monitors. And it also provides RTX Video super-resolution and HDR but it is not working properly with DVBViewer because enabling these features in the MPC-VR properties page does not enable any of the two RTX video enhancement features in the nvidia driver and the colors are not properly rendered. It seems like some "enabling" data is not reaching the driver. I tested also RTX video enhancement features with MPC-HC or MPC-BE and here they work fine.