Dela via

Rensa data

[Funktionen som är associerad med den här sidan, DirectShow, är en äldre funktion. Det har ersatts av MediaPlayer, IMFMediaEngineoch Audio / Video Capture i Media Foundation. Dessa funktioner har optimerats för Windows 10 och Windows 11. Microsoft rekommenderar starkt att ny kod använder MediaPlayer, IMFMediaEngine och Audio/Video Capture i Media Foundation i stället för DirectShow, när det är möjligt. Microsoft föreslår att befintlig kod som använder äldre API:er skrivs om för att använda de nya API:erna om möjligt.]

Följande pseudokod visar hur du implementerar metoden IPin::BeginFlush:

HRESULT CMyInputPin::BeginFlush()
{
    CAutoLock lock_it(m_pLock);
   
    // First, make sure the Receive method will fail from now on.
    HRESULT hr = CBaseInputPin::BeginFlush();
    
    // Force downstream filters to release samples. If our Receive method
    // is blocked in GetBuffer or Deliver, this will unblock it.
    for (each output pin)
    {
        hr = pOutputPin->DeliverBeginFlush();
    }

    // Unblock our Receive method if it is waiting on an event.
    SetEvent(m_hSomeEventThatReceiveNeedsToWaitOn);

    // At this point, the Receive method can't be blocked. Make sure 
    // it finishes, by taking the streaming lock. (Not necessary if this 
    // is the last step.)
    { 
        CAutoLock lock_2(&m_csReceive);

        /* Now it's safe to do anything that would crash or hang 
           if Receive were executing. */
    }
    return hr;
}

När tömningen startar tar metoden BeginFlush filterlåset, vilket serialiserar tillståndsändringen. Det är ännu inte säkert att ta strömningslåset eftersom tömning sker på programtråden och strömningstråden kan vara mitt i ett Ta emot-anrop. Pin-koden måste garantera att Ta emot inte blockeras och att efterföljande anrop till Ta emot misslyckas. Metoden CBaseInputPin::BeginFlush anger en intern flagga CBaseInputPin::m_bFlushing. När flaggan är TRUEmisslyckas metoden Ta emot.

Genom att leverera BeginFlush--anrop nedströms garanterar pinnen att alla nedströmsfilter släpper sina samples och returnerar från Receive--anrop. Detta garanterar i sin tur att ingångsstiftet inte blockeras i väntan på att GetBuffer eller Ta emot. Om pin-kodens Ta emot-metoden någonsin väntar på en händelse (till exempel för att hämta resurser) bör metoden BeginFlush tvinga väntan att avslutas genom att ställa in händelsen. I det här läget kommer metoden Ta emot garanterat att returneras, och flaggan m_bFlushing förhindrar att nya Ta emot-anrop utför något arbete.

För vissa filter är det allt BeginFlush behöver göra. Metoden EndFlush signalerar till filtret att den kan börja ta emot exempel igen. Andra filter kan behöva använda variabler eller resurser i BeginFlush som också används i Mottag. I så fall bör filtret hålla streaminglåset först. Se till att inte göra detta före något av föregående steg, eftersom du kan orsaka ett dödläge.

Metoden EndFlush innehåller filterlåset och sprider anropet nedströms:

HRESULT CMyInputPin::EndFlush()
{
    CAutoLock lock_it(m_pLock);
    for (each output pin)
        hr = pOutputPin->DeliverEndFlush();
    return CBaseInputPin::EndFlush();
}

Metoden CBaseInputPin::EndFlush återställer flaggan m_bFlushing till FALSE, vilket möjliggör för metoden Receive att börja ta emot prover igen. Detta bör vara det sista steget i EndFlush, eftersom anslutningspunkten inte får ta emot några prover förrän flushprocessen är slutförd och alla nedströmsfilter har fått en notifikation.

trådar och kritiska avsnitt

 

 

  • Last updated on