Flushing

  • Articolo

[La funzionalità associata a questa pagina, DirectShow, è una funzionalità legacy. È stata sostituita da MediaPlayer, IMFMediaEngine e Audio/Video Capture in Media Foundation. Queste funzionalità sono state ottimizzate per Windows 10 e Windows 11. Microsoft consiglia vivamente che il nuovo codice usi MediaPlayer, IMFMediaEngine e Audio/Video Capture in Media Foundation invece di DirectShow, quando possibile. Microsoft suggerisce che il codice esistente che usa le API legacy venga riscritto per usare le nuove API, se possibile.

Mentre il grafico dei filtri è in esecuzione, è possibile spostare quantità arbitrarie di dati nel grafico. Alcuni potrebbero trovarsi in code, in attesa di essere recapitati. In alcuni casi il grafico dei filtri deve rimuovere i dati in sospeso il più rapidamente possibile e sostituirli con nuovi dati. Dopo un comando seek, ad esempio, il filtro di origine genera campioni da una nuova posizione nell'origine. Per ridurre al minimo la latenza, i filtri downstream devono eliminare tutti gli esempi creati prima del comando seek. Il processo di eliminazione dei campioni viene chiamato scaricamento. Consente al grafico di essere più reattivo quando gli eventi modificano il normale flusso di dati.

Lo scaricamento viene gestito in modo leggermente diverso dal modello di pull rispetto al modello push. Questo articolo inizia descrivendo il modello push; descrive quindi le differenze nel modello pull.

Lo scaricamento avviene in due fasi.

  • Innanzitutto, il filtro di origine chiama IPin::BeginFlush sul pin di input del filtro downstream. Il filtro downstream inizia a rifiutare i campioni da upstream. Rimuove anche tutti i campioni che contiene e invia la chiamata BeginFlush downstream al filtro successivo.
  • Quando il filtro di origine è pronto per inviare nuovi dati, chiama IPin::EndFlush sul pin di input. Questo segnala al filtro downstream che può ricevere nuovi campioni. Il filtro downstream invia la chiamata EndFlush al filtro successivo.

Nel metodo BeginFlush il pin di input esegue le operazioni seguenti:

  1. Chiama BeginFlush sui pin di input downstream.
  2. Rifiuta qualsiasi altra chiamata che trasmette i dati, inclusi Receive e EndOfStream.
  3. Sblocca tutti i filtri upstream bloccati in attesa di un campione dall'allocatore del filtro. Alcuni filtri decommettono i relativi allocatori a questo scopo.
  4. Esce da eventuali attese che bloccano lo streaming. Ad esempio, i filtri del renderer vengono bloccati quando vengono sospesi. Bloccano anche quando sono in attesa di eseguire il rendering di un campione al momento corretto del flusso. Il filtro deve essere sbloccato, in modo che i campioni in coda upstream possano essere recapitati e rifiutati. Questo passaggio garantisce che tutti i filtri upstream si sblocchino.

Nel metodo EndFlush il pin di input esegue le operazioni seguenti:

  1. Attende che tutti gli esempi in coda vengano eliminati.
  2. Libera tutti i dati memorizzati nel buffer. Questo passaggio può talvolta essere eseguito nel metodo BeginFlush . BeginFlush, tuttavia, non è sincronizzato con il thread di streaming. Il filtro non deve elaborare o memorizzare nel buffer altri dati tra la chiamata a BeginFlush e la chiamata a EndFlush.
  3. Cancella eventuali notifiche di EC_COMPLETE in sospeso.
  4. Chiama EndFlush downstream.

A questo punto, il filtro può accettare nuovamente campioni. Tutti i campioni sono sicuramente più recenti rispetto allo scaricamento.

Nel modello di pull il filtro parser avvia lo scaricamento anziché il filtro di origine. Non solo chiama IPin::BeginFlush e IPin::EndFlush nel filtro downstream, chiama anche IAsyncReader::BeginFlush e IAsyncReader::EndFlush sul pin di output del filtro di origine. Se il filtro di origine contiene richieste di lettura in sospeso, le eliminerà.

Scaricamento dei dati