[Videos] Adding madVR support (1 Viewer)

tourettes

Retired Team Member
  • Premium Supporter
  • January 7, 2005
    17,301
    4,800
    * added APIs for media player devs to draw their OSDs/GUIs in exclusive mode
    * added API for media player devs to disable the madVR seekbar

    Those wont help. MP needs to be able to access that video texture directly.

    Hello everyone.

    I won't open source madVR. But I'm willing to add custom interfaces, if they're needed to make it work with MediaPortal. FWIW, one of the features added recently was an interface which allows you to install a callback which is called once for every rendered video frame. Maybe that already helps? If not, but if you're interested in adding madVR support, let's discuss what you need exactly, and I'll add it (if reasonable and technically possible).

    What would be needed is to have a callback that will provide a texture that contains only the video frame. MediaPortal's skin engine needs to be able to draw under and on top of that video frame. Skin Engine is responsible for calling the D3DDevice.Present(). Callback should be called when the frame is about to be rendered (there is slight overhead on the Skin Engine since it will do some drawing as well).

    In addition to that there is fortcoming MediaPortal Audio Renderer that works like Reclock - video renderer is responsible for making the minor adjustments to allow the audio resampling to be used to eliminate dropped frames (the ones that are caused by A/V clocks running on different rates) and to allowe non 1:1 matching fps vs hz to used like with Reclock.

    Hare's what the audio renderer's control interface looks like:

    Code:
    struct CLOCKDATA
    {
      double driftMultiplier;
      double driftHWvsSystem;
      double currentDrift;
      double resamplingAdjustment;
    };
    
    // {91A198BA-1C78-4c31-A50F-0F5C7578F078}
    static const GUID IID_IAVSyncClock = { 0x91a198ba, 0x1c78, 0x4c31, { 0xa5, 0xf, 0xf, 0x5c, 0x75, 0x78, 0xf0, 0x78 } };
    DEFINE_GUID(CLSID_IAVSyncClock, 0x91a198ba, 0x1c78, 0x4c31, 0xa5, 0xf, 0xf, 0x5c, 0x75, 0x78, 0xf0, 0x78);
    
    MIDL_INTERFACE("91A198BA-1C78-4c31-A50F-0F5C7578F078")
    IAVSyncClock: public IUnknown
    {
    public:
      virtual HRESULT STDMETHODCALLTYPE AdjustClock(DOUBLE adjustment) = 0;
      virtual HRESULT STDMETHODCALLTYPE SetBias(DOUBLE bias) = 0;
      virtual HRESULT STDMETHODCALLTYPE GetBias(DOUBLE *bias) = 0;
      virtual HRESULT STDMETHODCALLTYPE GetMaxBias(DOUBLE *bias) = 0;
      virtual HRESULT STDMETHODCALLTYPE GetMinBias(DOUBLE *bias) = 0;
      virtual HRESULT STDMETHODCALLTYPE GetClockData(CLOCKDATA *clockData) = 0;
      virtual HRESULT STDMETHODCALLTYPE SetEVRPresentationDelay(DOUBLE EVRDelay) = 0;
    
    };
     

    madshi

    Portal Member
    August 13, 2011
    10
    2
    Home Country
    Germany Germany
    What would be needed is to have a callback that will provide a texture that contains only the video frame. MediaPortal's skin engine needs to be able to draw under and on top of that video frame. Skin Engine is responsible for calling the D3DDevice.Present(). Callback should be called when the frame is about to be rendered (there is slight overhead on the Skin Engine since it will do some drawing as well).
    In other words you want the renderer to just do the color conversion and scaling etc, but you want to do the presentation yourself? It would be possible to add such a rendering mode option to madVR, but it would bypass a lot of carefully implemented presentation code. Presentation is an important part of madVR. If we bypass that, we lose some of the things that make madVR better than other renderers. Here's a list of things that we would lose:

    - most importantly: smooth playback without any judder/stuttering
    - automatic windowed <-> exclusive mode switching
    - automatic display mode changing
    - 3:2 stutter removal for 24fps playback on 60Hz displays
    - support for true 10bit output
    - internal Reclock replacement without any audio quality loss (by doing the adjustments on the video side of things)
    - black/dark frame insertion

    The bottom 4 features are not implemented in madVR yet, but might eventually come in a future version (or not). Maybe you can implement some of these things inside MediaPortal, but you'd practically have to reinvent what madVR already does (or will eventually do).

    Wouldn't it be possible to allow madVR to take care of the presentation? I could add all kinds of callbacks which would allow you to draw under and over the video frame etc. That's no problem at all. But losing the presentation part of madVR would be a substantial loss, IMHO.
     

    Holzi

    Super Moderator
  • Team MediaPortal
  • April 21, 2010
    7,934
    2,235
    Ba-Wü
    Home Country
    Germany Germany
    AW: Adding madVR support

    I really would love to see madVR support! Would be a great improvement imo! =)
    Thanks!
     

    tourettes

    Retired Team Member
  • Premium Supporter
  • January 7, 2005
    17,301
    4,800
    In other words you want the renderer to just do the color conversion and scaling etc, but you want to do the presentation yourself? It would be possible to add such a rendering mode option to madVR, but it would bypass a lot of carefully implemented presentation code. Presentation is an important part of madVR. If we bypass that, we lose some of the things that make madVR better than other renderers. Here's a list of things that we would lose:

    - most importantly: smooth playback without any judder/stuttering

    That is already done by MP's own custom EVR renderer when A/V clocks match 1:1. And with MP Audio Renderer in same way as Reclock (excluding the startup etc. glitches Reclock has when it wont work with the video renderer) when A/V clocks are having their own will.

    - automatic windowed <-> exclusive mode switching

    Esclusive mode is not supported currently by MP (only on XP). So this couldn't be used - reseting the DirectX device on the fly is not not go well with the Skin Engine's current way it handles things.

    - automatic display mode changing

    This is conflicting with MediaPortal's code. It is already supported by MediaPortal with good user customization for mode matching so there is no requirement for this one (actually it should be completely disabled). Could cause some issues when MPC-HC for example is used on same PC since setting would conflict (althou MP is used as HTPC frontend so there usually aren't any other playback software on the same PC).

    - 3:2 stutter removal for 24fps playback on 60Hz displays

    Would be possible since madVR is responsible for the presentation time (calling the callback tells that render this texture now - basicly BeginScene and EndScene happens during this callback).

    - support for true 10bit output

    True, this is not possible to be supported unless MP's skin engine would support it as well.

    - internal Reclock replacement without any audio quality loss (by doing the adjustments on the video side of things)

    Would be possible since madVR is responsible for the presentation time.

    - black/dark frame insertion

    Would be possible since madVR is responsible for the presentation time.

    Wouldn't it be possible to allow madVR to take care of the presentation? I could add all kinds of callbacks which would allow you to draw under and over the video frame etc. That's no problem at all. But losing the presentation part of madVR would be a substantial loss, IMHO.

    Only presentation timing (which should be done in any ways since the skin engine is not doing any presentation timing when video playback is active - the texture callback is used for the presentation timing) - others would require just too much injecting code in different parts of the skin engine (which doesn't have the best design from architecture point of view :)).

    In my opinion other parts aren't interesting than the scaling and color space conversions. And in future the black frame insertion would be nice to have since it would allow bitstreaming to be used with smooth video playback. 10 bit might be after I get some display that support it :)
     

    tourettes

    Retired Team Member
  • Premium Supporter
  • January 7, 2005
    17,301
    4,800
    I haven't been following the madVR thread on doom9 forum's lately (6 months maybe :)). Just because I can't got enough free time. It would be nice to have madVR support in MP 1.3.0, but it probably needs lot of work (not as much on madVR as MP side). It would require some interested dev to hop in to make the required changes on MP side - I simply have already too much on my hands with the current components I'm working on (and as said there is just not that much free time... at least not as much I would like / need to have)

    btw. Does DVD navigator currently work with the madVR? I think it was problematic at least at some time in the past.
     

    tourettes

    Retired Team Member
  • Premium Supporter
  • January 7, 2005
    17,301
    4,800
    And how to solve deinterlacing? Using CUVID is not a solution for 2/3 users...

    Not everyone would have to use madVR. 95% of the people wont see anything different with madVR and MP's internal EVR presenter when playing a Blu-ray on 1:1 matching screen.

    • madVR implements some way to allow HW deinterlace to be used
    • LAV CUVID type of video decoders for other GPU types are created
    • probably pixel shaders on MP side could be used to deinterlace (who creates such, not me :))
    • people buy Nvidia :)

    In any case it is not this thread's topic to expand madVR's support for anything else than the MP related API.
     

    madshi

    Portal Member
    August 13, 2011
    10
    2
    Home Country
    Germany Germany
    That is already done by MP's own custom EVR renderer when A/V clocks match 1:1.
    Theoretically MPC-HC's internal renderers do that, too. But my users report that madVR still does it better than any other renderer. Furthermore some madVR users have CRTs with high refresh rates (e.g. 120Hz) and only madVR achieves smooth playback in that situation, according to what my users report.

    On my own HTPC with integrated NVidia 9400 GPU, I'm only getting smooth playback with madVR, when playing 25fps movies @ 50Hz. All other renderers I've tried so far fail miserably.

    Esclusive mode is not supported currently by MP (only on XP). So this couldn't be used - reseting the DirectX device on the fly is not not go well with the Skin Engine's current way it handles things.
    Exclusive mode is important, IMHO. It's needed for 10bit output. It's probably needed for frame packed 3D output (which is another feature which would require madVR to do the presentation, btw). And it's required for many users to reliably get rid of tearing. Finally, exclusive mode allows madVR to present several video frames in advance, which are then flipped by in driver land in the hardware vsync interrupt (I think).

    Would be possible since madVR is responsible for the presentation time (calling the callback tells that render this texture now - basicly BeginScene and EndScene happens during this callback).
    So basically whenever I fire a render callback, it would end up with a "D3D.Present" call in your code? That's still kinda problematic, though. madVR usually pre-renders frames in advance and then presents them to very strict timing ranges. If I fire that callback, and if you take more than just a few microseconds for your rendering, presentation might already be off, resulting in problems, especially with high refresh rates...

    Only presentation timing (which should be done in any ways since the skin engine is not doing any presentation timing when video playback is active - the texture callback is used for the presentation timing) - others would require just too much injecting code in different parts of the skin engine (which doesn't have the best design from architecture point of view :)).
    That's too bad... :(

    I haven't been following the madVR thread on doom9 forum's lately (6 months maybe :)). Just because I can't got enough free time. It would be nice to have madVR support in MP 1.3.0, but it probably needs lot of work (not as much on madVR as MP side). It would require some interested dev to hop in to make the required changes on MP side - I simply have already too much on my hands with the current components I'm working on (and as said there is just not that much free time... at least not as much I would like / need to have)
    I understand. My free time is quite limited, as well, sadly... :( Anyway, if there's any dev reading this and wanting to work on madVR support, just let me know. My email address is listed in the madVR readme.

    btw. Does DVD navigator currently work with the madVR? I think it was problematic at least at some time in the past.
    I've been told it works for some DVDs, when using specific MPEG2 decoders - but maybe not for all DVDs. I think it might start working for all DVDs once I add support for an external subtitle pin, so that the DVD navigator can overlay the menus.

    And how to solve deinterlacing?
    madVR has not reached v1.0 yet. Have some patience... ;)

    - black/dark frame insertion

    What is this used for - mimicing what a real film projector does maybe (i.e. the 48Hz flicker) ?
    Some projectors already have this feature built in (but in a rather bad way, IMHO).

    Yes, basically it simulates what a real film projector does. The purpose is not the simulation in itself, though. The main purpose of black/dark frame insertion is to reduce the "sample-and-hold" effect. Digital type displays are "hold" type displays. Which means that the image is visible at all times. There are no black phases (like there were with CRT). With digital displays, the image doesn't move smoothly. It jumps a bit every video frame. Our eyes/brain try to follow movements, but due to the jumping, our eyes/brain see a lot of blurring. Motion is just not sharp, anymore. This can be reduced by using intermedia frame interpolation. But doing that introduces the "soap opera" effect. Alternatively dark/black frame insertion helps making motion appear sharper.

    CRTs didn't have problems with displaying sharp motion because there were not hold-type displays. As annoying as the flickering was, it helped a lot in making motion sharp.
     

    Users who are viewing this thread

    Top Bottom