Megosztás a következőn keresztül:

Csapok újracsatlakoztatása

  • Cikk

[A laphoz társított funkció, DirectShowegy régi funkció. Ezt felváltotta a MediaPlayer, a IMFMediaEngineés a Media Foundation Audió/Videó Rögzítés. Ezek a funkciók Windows 10-hez és Windows 11-hez lettek optimalizálva. A Microsoft határozottan javasolja, hogy az új kód a MediaPlayer, a IMFMediaEngine és a Media Foundation részeként az Audio/Video Capture-t használja a DirectShowhelyett, ha lehetséges. A Microsoft javasolja, hogy az örökölt API-kat használó meglévő kódot át kell írni az új API-k használatára, ha lehetséges.]

A tűkapcsolat során a szűrő leválaszthatja és újracsatlakoztathatja az egyik másik tűjét, az alábbiak szerint:

  1. A szűrő meghívja IPin::QueryAccept a másik szűrő pin-kódjára, és megadja az új médiatípust.
  2. Ha QueryAccept S_OK ad vissza, a szűrő meghívja IFilterGraph2::ReconnectEx a tűk újracsatlakoztatásához.

Az alábbiakban néhány példát mutatunk be arra, hogy egy szűrőnek mikor kell újra csatlakoztatnia a tűket:

  • Tee szűrők. A tee szűrő a bemeneti adatfolyamot több kimenetre osztja anélkül, hogy módosítaná a streamben lévő adatokat. A pólószűrők számos médiatípust elfogadhatnak, de a típusoknak meg kell egyeznie az összes pin-kapcsolattal. Ezért amikor a bemeneti tű csatlakozik, előfordulhat, hogy a szűrőnek újra kell tárgyalnia a kimeneti tűk meglévő kapcsolatait, és fordítva. Példaként lásd a InfTee szűrőmintát.
  • Helyközi szűrők. A trans-in-place szűrő az eredeti pufferben módosítja a bemeneti adatokat, ahelyett hogy az adatokat külön kimeneti pufferbe másolná. A helyközi szűrőnek ugyanazt az elosztót kell használnia a felső és az alsóbb rétegbeli kapcsolatokhoz is. Az első tű, amely csatlakozik (bemenet vagy kimenet), a szokásos módon kiosztót tárgyal ki. Ha azonban a másik tű csatlakozik, előfordulhat, hogy az első kiosztó nem lesz elfogadható. Ebben az esetben a második pin egy másik kiosztót választ, és az első pin újra csatlakozik az új kiosztóval. Példaként tekintse meg a CTransInPlaceFilter osztályt.

A ReconnectEx metódusban a Filter Graph Manager aszinkron módon leválasztja és újracsatlakoztatja a tűket. A szűrő nem kísérelheti meg az újracsatlakozást, hacsak a QueryAccept nem ad S_OK vissza. Ellenkező esetben a rögzítés megszakad, és gráfhibákat okoz. Emellett a szűrőnek kérvényeznie kell az újracsatlakozást a IPin::Connect metódusban, ugyanazon a szálon. Ha a Connect metódus egy szálon tér vissza, míg egy másik szál végzi az újracsatlakozási kérelmet, a Filter Graph Manager futtathatja a gráfot, mielőtt újracsatlakozna, és gráfhibákat okozna.