Vlissingen

[De functie die is gekoppeld aan deze pagina, DirectShow, is een verouderde functie. Het is vervangen door MediaPlayer, IMFMediaEngineen Audio/Video Capture in Media Foundation. Deze functies zijn geoptimaliseerd voor Windows 10 en Windows 11. Microsoft raadt ten zeerste aan om nieuwe code te gebruiken MediaPlayer, IMFMediaEngine en Audio/Video Capture in Media Foundation in plaats van DirectShow, indien mogelijk. Microsoft stelt voor dat bestaande code die gebruikmaakt van de verouderde API's, indien mogelijk opnieuw worden geschreven om de nieuwe API's te gebruiken.]

Terwijl de filtergrafiek wordt uitgevoerd, kunnen willekeurige hoeveelheden gegevens door de grafiek worden verplaatst. Sommige ervan bevinden zich mogelijk in wachtrijen, wachtend om te worden bezorgd. Soms moet de filtergrafiek deze in behandeling zijnde gegevens zo snel mogelijk verwijderen en vervangen door nieuwe gegevens. Na een zoekopdracht genereert het bronfilter bijvoorbeeld voorbeelden van een nieuwe positie in de bron. Om de latentie te minimaliseren, moeten downstreamfilters alle voorbeelden verwijderen die zijn gemaakt vóór de zoekopdracht. Het proces van het verwijderen van steekproeven wordt het leegmaken vangenoemd. Hierdoor kan de grafiek responsiever zijn wanneer gebeurtenissen de normale gegevensstroom wijzigen.

Spoelen wordt door het pull-model iets anders afgehandeld dan door het push-model. Dit artikel begint met het beschrijven van het pushmodel; vervolgens worden de verschillen in het pull-model beschreven.

Het leegmaken gebeurt in twee fasen.

• Eerst roept het bronfilter IPin::BeginFlush aan op de invoerpin van het downstreamfilter. Het downstreamfilter begint met het weigeren van voorbeelden van upstream. Het verwijdert ook alle voorbeelden die het vasthoudt en stuurt de BeginFlush--aanroep door naar het volgende filter.
• Wanneer het bronfilter klaar is om nieuwe gegevens te verzenden, roept het IPin::EndFlush op de invoerpin aan. Hiermee wordt het downstreamfilter aangegeven dat er nieuwe steekproeven kunnen worden ontvangen. Het downstreamfilter verzendt de EndFlush- aanroep naar het volgende filter.

In de methode BeginFlush doet de invoerpin het volgende:

1. Roep BeginFlush aan op downstream-invoerpinnen.
2. Weigert verdere aanroepen die gegevens streamen, waaronder Ontvangen en EndOfStream-.
3. Alle upstreamfilters die wachten op een voorbeeld van de allocator van het filter en geblokkeerd zijn, deblokkeren. Sommige filters verwijderen hun toewijzingen voor dit doel.
4. Opheffen van wachttijden die streaming blokkeren. Renderer-filters stoppen bijvoorbeeld met werken wanneer ze zijn gepauzeerd. Ze blokkeren ook wanneer ze wachten op het weergeven van een voorbeeld op de juiste stroomtijd. Het filter moet de blokkering opheffen, zodat monsters in de upstream-wachtrij geleverd en geweigerd kunnen worden. Deze stap zorgt ervoor dat alle upstream-filters uiteindelijk de blokkering opheffen.

In de methode EndFlush doet de invoerpin het volgende:

1. Wacht totdat alle in de wachtrij geplaatste monsters worden verwijderd.
2. Eventuele gebufferde gegevens worden vrijgemaakt. Deze stap kan soms worden uitgevoerd in de methode BeginFlush. BeginFlush- wordt echter niet gesynchroniseerd met de streaming-thread. Het filter mag geen gegevens meer verwerken of bufferen tussen de aanroep naar BeginFlush- en de aanroep van EndFlush-.
3. Wist alle openstaande EC_COMPLETE-meldingen.
4. Roep EndFlush naar de volgende stap aan.

Op dit moment kan het filter voorbeelden opnieuw accepteren. Alle monsters zijn gegarandeerd recenter dan de doorspoeling.

In het pull-model start het parserfilter het leegmaken in plaats van het bronfilter. Niet alleen roept het in het downstreamfilter IPin::BeginFlush en IPin::EndFlush aan, maar het roept ook IAsyncReader::BeginFlush en IAsyncReader::EndFlush aan op de output pin van het bronfilter. Als het bronfilter leesaanvragen in behandeling heeft, worden deze genegeerd.

Verwante onderwerpen

gegevens leegmaken