Поделиться через

Implementing ProcessInput (deprecated)

  • Статья

This page documents a feature that may be unavailable in future versions of Windows Media Player and the Windows Media Player SDK.

When Windows Media Player has data to deliver to your rendering plug-in, it does so by calling IMediaObject::ProcessInput. Depending on how you made your content, this could occur infrequently or many times each second. For example, the sample rendering plug-in media contains just three lines of text that are each delivered to the plug-in at five-second intervals. An arbitrary data stream could just as easily contain full-motion video causing the Player to deliver new data constantly. It is up to the content author to specify the presentation time of each data sample.

The plug-in wizard sample code implementation of ProcessInput performs the following steps:

  1. Validate the relevant parameters. The sample code checks to ensure that the provided stream index is as expected and that the IMediaBuffer interface pointer provided is not NULL.

  2. Verify that the input media type has been set.

  3. Show the plug-in window under certain circumstances. The plug-in creates a hidden window and makes it visible to the user at appropriate times. The following code is from the sample plug-in:

    
if ( m_hWnd &&
     !IsWindowVisible() &&
     m_bHosted && 
     !m_bWindowless && 
     !m_bFullScreen)
{
    // Under these circumstances, be sure 
    // that the plug-in window is visible.
    ShowWindow( SW_SHOW );
}

    The preceding code first verifies that the rendering window exists. It then ensures that if the plug-in is rendering in a window hosted inside the Player user interface (and Now Playing is currently selected), and the Player isn't in full-screen mode, then the window is made visible if it is currently hidden. Your plug-in may require that the window remain hidden always, or may not use a window at all.

  4. Enter a critical section. This is a simple as calling Lock. It is important that rendering plug-ins process their data within critical sections. Otherwise, it is possible that Windows Media Player could change the data in the buffer before the plug-in is finished processing it.

  5. Release any existing input buffer. The call to ProcessInput acts as a signal that any previous buffer processing is completed. This also means that the previous data buffer can be released by the plug-in.

  6. Hold a reference on the input buffer.

  7. Exit the critical section. A simple call to Unlock accomplishes this.

  8. Invalidate the rendering region and force Windows to post a WM_PAINT message (provided that the window exists). The following code is from the Repaint method in the sample code:

    
if( m_bWindowless )
{
    if( m_spWMPNodeWindowlesshost.p )
    {
        // Invalidate the RECT to which we moved the window.
        // That's the same as the region to redraw.
        hr = m_spWMPNodeWindowlesshost->InvalidateRect( &m_rctWindowPos, FALSE );
    }
}

    The preceding code demonstrates that the plug-in must direct the Player to invalidate the rendering region when rendering in windowless mode. The following code continues the conditional block:

    
else
{
    InvalidateRect( NULL, FALSE );
    UpdateWindow();
}

    If rendering in windowed mode, the plug-in invalidates the rendering region itself.

Implementing Your Rendering Code (deprecated)