Sprzętowe MFT

W tym temacie opisano sposób pisania transformacji programu Media Foundation (MFT), która działa jako serwer proxy do kodera sprzętowego, dekodera lub procesora sygnału cyfrowego (DSP).

Ten temat zawiera następujące sekcje:

• Wprowadzenie
• atrybuty sprzętu MFT
• sekwencji uzgadniania sprzętu
• przetwarzania danych
• sparowany dekoder/koder
• Tematy pokrewne

Wprowadzenie

Każdy koder koder sprzętowy, który nie jest oparty na avStream, musi dostarczyć własny MFT, aby działał jako serwer proxy dla sterownika. Koder kodowy sprzętowy może zawierać kilka odrębnych bloków funkcjonalnych:

• Koder
• Dekoder
• Skalowanie/konwersja formatu ramki

Każda z tych funkcji powinna być zarządzana przez oddzielny MFT. Sprzęt MFT nigdy nie powinien działać jako wielofunkcyjny "transkoder". Zamiast tego umieść funkcje kodowania w funkcji MFT kodera i dekodowania w dekoder MFT. Jeśli sprzęt oferuje konwersje skalowania i formatowania ramek, umieść te funkcje w osobnym procesorze wideo zarejestrowanych w kategorii MFT_CATEGORY_VIDEO_PROCESSOR. Jeśli sprzęt nie obsługuje skalowania ramek ani konwersji formatu, program Media Foundation udostępnia programowy procesor wideo.

Sprzętowe MFT mają następujące ogólne wymagania:

• Sprzętowe MFTs muszą używać nowego modelu przetwarzania asynchronicznego, zgodnie z opisem w Asynchroniczne MFTs.
• Sprzętowe MFTs muszą obsługiwać zmiany formatu dynamicznego, zgodnie z opisem w zmiany formatu dynamicznego.

Atrybuty sprzętu MFT

Sprzęt MFT musi implementować następujące metody związane z atrybutami:

• IMFTransform::GetAttributes: zwraca magazyn atrybutów dla globalnych atrybutów MFT.
• IMFTransform::GetInputStreamAttributes: zwraca magazyn atrybutów dla strumienia wejściowego.
• IMFTransform::GetOutputStreamAttributes: zwraca magazyn atrybutów dla strumienia wyjściowego.

Po pierwszym utworzeniu biblioteki MFT należy ustawić następujące atrybuty we własnym magazynie atrybutów globalnych (czyli magazynie atrybutów zwracanym przez GetAttributes):

Sekwencja uzgadniania sprzętu

Jeśli dwa MFT reprezentują to samo urządzenie fizyczne, mogą wymieniać dane w ramach sprzętu — na przykład za pośrednictwem magistrali sprzętowej. Nie ma potrzeby kopiowania danych do pamięci systemowej, a następnie z powrotem na urządzenie.

Na poniższym diagramie MFTs oznaczone jako "A" i "B" reprezentują bloki funkcjonalne w ramach tego samego sprzętu. Na przykład w scenariuszu transkodowania "A" może reprezentować dekoder sprzętowy, a "B" może reprezentować koder sprzętowy. Przepływ danych między elementami "A" i "B" występuje na sprzęcie. MFT oznaczony jako "C" to oprogramowanie MFT. Przepływ danych z "B" do "C" używa pamięci systemowej.

Aby nawiązać połączenie sprzętowe, dwa sprzętowe MFTs muszą korzystać z prywatnego kanału komunikacyjnego. To połączenie jest ustanawiane podczas negocjacji formatu, przed ustawieniem typów multimediów i przed pierwszym wywołaniem ProcessInput. Proces połączenia działa w następujący sposób:

1. Moduł ładujący topologii sprawdza oba MFT pod kątem obecności atrybutu MFT_ENUM_HARDWARE_URL_Attribute. Należy pamiętać, że nie analizuje wartości tego atrybutu.

2. Jeśli MFT_ENUM_HARDWARE_URL_Attribute występuje w obu zestawach MFT, moduł ładujący topologii wykonuje następujące czynności:

   1. Moduł ładujący topologii wywołuje IMFTransform::GetOutputStreamAttributes w nadrzędnym MFT (A). Ta metoda zwraca wskaźnik IMFAttributes. Niech ten wskaźnik zostanie oznaczony pUpstream.
   2. Moduł ładujący topologii wywołuje IMFTransform::GetInputStreamAttributes w podrzędnym MFT (B). To wywołanie zwraca również wskaźnik IMFAttributes. Niech ten wskaźnik zostanie oznaczony pDownstream.
   3. Moduł ładujący topologii ustawia atrybut MFT_CONNECTED_STREAM_ATTRIBUTE na pDownstream przez wywołanie IMFAttributes::SetUnknown. Wartość atrybutu to wskaźnik pUpstream.
   4. Moduł ładujący topologii ustawia atrybut MFT_CONNECTED_TO_HW_STREAM na true na pDownstream i pUpstream.

3. W tym momencie podrzędny MFT ma wskaźnik do nadrzędnego magazynu atrybutów MFT, jak pokazano na poniższym diagramie.

   

   Nuta

   W celu zapewnienia przejrzystości na tym diagramie przedstawiono strumienie, a atrybut przechowuje jako odrębne obiekty, ale nie jest to wymagane do implementacji.

    

4. Podrzędny MFT używa IMFAttributes wskaźnik do ustanowienia prywatnego kanału komunikacyjnego z nadrzędnym MFT. Ponieważ kanał jest prywatny, dokładny mechanizm jest definiowany przez implementację. Na przykład MFT może wykonywać zapytania dotyczące prywatnego interfejsu COM.

W kroku 4 podrzędny MFT musi sprawdzić, czy dwa MFT współużytkuje to samo urządzenie fizyczne. Jeśli nie, muszą wrócić do używania pamięci systemowej na potrzeby transportu danych. Dzięki temu MFT działa prawidłowo z oprogramowaniem MFTs i innymi urządzeniami sprzętowymi.

Jeśli uzgadnianie powiedzie się, a dwa MFTs współużytkują kanał danych prywatnych, nie używają standardowego modelu przetwarzania danych (opisanego w następnej sekcji) w punkcie połączenia. W szczególności podrzędny MFT nie wysyła meTransformNeedInput zdarzeń; Aby uzyskać więcej informacji, zapoznaj się z następną sekcją w tym temacie.

Przetwarzanie danych

Gdy sprzęt MFT używa pamięci systemowej do transportu danych, proces działa w następujący sposób:

1. Aby zażądać większej ilości danych wejściowych, MFT wysyła zdarzenie METransformNeedInput.
2. Zdarzenie METransformNeedInput powoduje wywołanie potoku IMFTransform::P rocessInput.
3. Gdy MFT zawiera dane wyjściowe, MFT wysyła zdarzenie METransformHaveOutput.
4. Zdarzenie METransformHaveOutput powoduje wywołanie potoku IMFTransform::P rocessOutput.

Aby uzyskać szczegółowe informacje, zobacz Asynchroniczne MFTs.

Jeśli jednak platforma MFT używa kanału sprzętowego, nie wysyła tych zdarzeń w punkcie połączenia sprzętowego, ponieważ cały transfer danych odbywa się wewnętrznie na sprzęcie. W związku z tym potok nie wywołuje ProcessInput ani ProcessOutput w punkcie połączenia.

Rozważmy na przykład pierwszy diagram w tym temacie. Biorąc pod uwagę tę konfigurację, przetwarzanie danych odbywa się w następujący sposób:

1. Wyrażenie "A" wysyła METransformNeedInput żądać danych.
2. Potok wywołuje ProcessInput na "A".
3. "A" i "B" przetwarzają dane na sprzęcie.
4. Po zakończeniu przetwarzania "B" wysyła zdarzenie METransformHaveOutput.
5. Potok wywołuje ProcessOutput w ciągu "B".

Sparowany dekoder/koder

Jeśli dekoder i koder znajdują się na tym samym chipie sprzętowym, może być lepiej używać ich razem podczas transkodowania. Oznacza to, że wybranie jednej z nich powinno spowodować wybranie drugiego w potoku transkodowania. Aby zapewnić wybór pasujących koderów sprzętowych, obie koderce MFT powinny oferować niestandardowy typ nośnika. Aby utworzyć typ nośnika niestandardowego:

• Ustaw atrybut MF_MT_MAJOR_TYPE na MFMediaType_Audio lub MFMediaType_Videoodpowiednio.
• Ustaw atrybut MF_MT_SUBTYPE na niestandardową wartość identyfikatora GUID.

Inne atrybuty typu są opcjonalne. Dekoder zwraca typ niestandardowy z jego IMFTransform::GetOutputAvailableType, a koder zwraca typ niestandardowy z jego IMFTransform::GetInputAvailableType metody. W obu przypadkach typ niestandardowy musi być pierwszym wpisem na liście (dwTypeIndex = 0).

Aby pracować z koderami oprogramowania, koder koder powinien również zwrócić co najmniej jeden standardowy format, taki jak NV12 dla wideo. Formaty standardowe powinny być wyświetlane po typie niestandardowym (dwTypeIndex> 0). Jeśli te dwa kodetki muszą być zawsze sparowane i nie mogą współpracować z koderami oprogramowania, MFTs powinny zwracać tylko format niestandardowy i nie zwracać żadnych standardowych formatów.

Tematy pokrewne

pisanie niestandardowej MFT

implementowanie codec MFT

przekształcenia Media Foundation