locked
Issue with rendering in DXVA2 mode (MediaFoundation VC-1 decoder) RRS feed

  • Question

  • We are experiencing problems with rendering via EVR in DXVA2 mode on our MediaFoundation VC-1 decoder. We use Windows Vista and ATI Radeon 2600Pro video card. This issue is seems t o be specific only to VC-1 and MediaFoundation because:


    1. All our DirectShow decoders (MPEG2, H.264, VC-1) work ok using DVXA2.

    2. Two our MediaFoundation decoders (MPEG2, H.264) work ok using DXVA2.

    3. VC-1 MediaFoundation decoder doesn't work in DXVA2 mode. WindowsMediaPlayer says "encountered a problem while playing…". Our testing application reports event from MediaSession with error code E_NOTIMPL=0x80004001. The error occurs just after sending first sample (DXVA2 surface) to the render (EVR).

    Behaviour is the same with both Microsoft ASF MediaSource (.wmv clips) and our VC-1 MediaSource (pure video clips).


    Are there any specifics or additional requirements on VC-1 MediaFoundation DXVA2 rendering?


    Any ideas or suggestions on this issue will be very helpful.


    Thanks a lot!


    Wednesday, January 23, 2008 6:35 PM

Answers

  • I do not know if anyone got back to you on Ask DXVA about this, so I will post my thoughts here.

     

    A diagnostic check to perform would be playing back VC-1 content on this machine through the default WMV decoder that shipped with Vista (CLSID_CWMVDecMediaObject).  This decoder does DXVA2 acceleration for VC1 so if it works it should rule out any quirks with this hardware.

     

    The typical source of E_NOTIMPL in DXVA playback is the media buffer on the video sample (that is, samples created with MFCreateVideoSampleFromSurface).  Doing much of anything with this media buffer besides querying it for the MR_BUFFER_SERVICE will return an E_NOTIMPL.  The EVR knows how to handle these types of buffers but non-D3D-aware transforms will attempt to treat them as normal buffers, causing the E_NOTIMPL to be fired back to the client.  If the topology containing your decoder is passed through the default topoloader (for example, calling SetTopology on the session without the NORESOLUTION flag), the topoloader may insert converters if it percieves a type mismatch between the decoder and the EVR.  Have you verified that there are no nodes between the decoder and the EVR in the topology returned from MESessionTopologySet?

     

    If this doesn't help and you are still stuck let me know.

    Wednesday, January 30, 2008 1:08 AM