Obsługa zmian strumienia

W tym temacie opisano sposób, w jaki transformacja programu Media Foundation (MFT) powinna obsługiwać zmiany formatu podczas przesyłania strumieniowego.

Omówienie zmian formatu

Ogólnie rzecz biorąc, istnieją dwa powody, dla których format może ulec zmianie podczas przesyłania strumieniowego.

• Klient może przełączyć się na strumień z nowym formatem. Na przykład w telewizji cyfrowej może się to zdarzyć z powodu zmiany kanału.
• W niektórych formatach wideo, takich jak H.264, strumień bitowy może sygnalizować zmianę formatu. Takie zmiany mogą obejmować zmiany w zdominowaniu pola, rozdzielczości wideo lub współczynniku proporcji pikseli.

Jeśli typ kodowania ulegnie zmianie, klient może potrzebować usunąć MFT z potoku i zastąpić go innym MFT. (Na przykład klient może wymagać zamiany w nowym dekoderze). Ten temat nie obejmuje tej sytuacji. W tym temacie opisano tylko ten przypadek, w którym bieżący protokół MFT może obsłużyć nowy format.

Jeśli format zmieni się, MFT może wymagać nowego typu danych wejściowych, nowego typu danych wyjściowych lub obu tych typów.

• Zmiany typu wejściowego są inicjowane przez klienta. MFT nigdy nie zmienia własnego typu danych wejściowych.
• Zmiany typu danych wyjściowych są inicjowane przez MFT. MFT sygnalizuje, że wymaga nowego typu danych wyjściowych, a klient negocjuje nowy typ danych wyjściowych z MFT.

W związku z tym możliwe są trzy odrębne przypadki:

• Klient ustawia nowy typ danych wejściowych. MFT używa nowego formatu bez zmiany typu danych wyjściowych.
• Klient ustawia nowy typ danych wejściowych, a spowoduje to zmianę typu danych wyjściowych.
• Typ danych wejściowych nie zmienia się, ale MFT wykrywa zmianę formatu w strumieniu bitowym, co wymaga nowego typu danych wyjściowych.

Implementowanie zmian formatu

W pozostałej części tego tematu opisano, jak klient powinien przetworzyć zmianę formatu oraz jak zaimplementować zmiany formatu w MFT.

Typ danych wyjściowych

Dowolny MFT może zainicjować zmianę typu danych wyjściowych w następujący sposób:

1. Klient wywołuje IMFTransform::ProcessOutput. MFT odpowiada w następujący sposób:
   1. MFT nie generuje próbki wyjściowej w ProcessOutput.
   2. MFT ustawia flagę MFT_OUTPUT_DATA_BUFFER_FORMAT_CHANGE w elemencie dwStatus struktury MFT_OUTPUT_DATA_BUFFER.
   3. Metoda ProcessOutput zwraca kod błędu MF_E_TRANSFORM_STREAM_CHANGE.
2. Klient wywołuje IMFTransform::GetOutputAvailableType. Ta metoda zwraca zaktualizowany zestaw typów danych wyjściowych.
3. Klient wywołuje SetOutputType, aby ustawić nowy typ danych wyjściowych.
4. Klient wznowi wywoływanie ProcessInput/ProcessOutput.

Typ danych wejściowych

Zmiany typu wejściowego są inicjowane przez klienta, nigdy przez MFT. Jeśli typ danych wejściowych ulegnie zmianie, może to spowodować zmianę typu danych wyjściowych.

Dokładna sekwencja zdarzeń zależy od wartości atrybutu MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE.

Protokół MFT uwidacznia ten atrybut za pośrednictwem metody IMFTransform::GetAttributes. Wartość domyślna tego atrybutu to FALSE; jeśli MFT nie ustawi atrybutu, traktuj wartość jako FALSE.

MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE ma wartość FALSE

1. Klient wysyła komunikat MFT_MESSAGE_COMMAND_DRAIN.
2. Klient opróżnia MFT, wywołując IMFTransform::ProcessOutput, dopóki ProcessOutput zwróci MF_E_TRANSFORM_NEED_MORE_INPUT.
3. Klient wywołuje IMFTransform::SetInputType, aby ustawić nowy typ danych wejściowych.
4. MFT weryfikuje typ danych wejściowych. Jeśli typ jest nieprawidłowy, SetInputType zwraca MF_E_INVALIDMEDIATYPE lub inny kod błędu. W przeciwnym razie SetInputType zwraca S_OK.
5. Zakładając, że typ danych wejściowych jest prawidłowy, MFT ocenia, czy typ danych wyjściowych również się zmienia. Jeśli tak nie jest, przesyłanie strumieniowe będzie kontynuowane i nie jest wymagana żadna dalsza akcja.
6. Jeśli typ danych wyjściowych ulegnie zmianie:
   1. MFT unieważnia bieżący typ nośnika wyjściowego i aktualizuje listę dostępnych typów nośników wyjściowych.
   2. Następne wywołanie ProcessOutput zwraca MF_E_TRANSFORM_STREAM_CHANGE, zgodnie z opisem w poprzedniej sekcji.
   3. Klient wywołuje IMFTransform::GetOutputAvailableType, aby uzyskać zaktualizowaną listę typów danych wyjściowych.
   4. Klient wywołuje SetOutputType.

MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE ma wartość TRUE

1. Klient wywołuje IMFTransform::SetInputType, aby ustawić nowy typ danych wejściowych.
2. MFT weryfikuje typ danych wejściowych. Jeśli typ jest nieprawidłowy, SetInputType zwraca MF_E_INVALIDMEDIATYPE lub inny kod błędu. W przeciwnym razie SetInputType zwraca S_OK.
3. Zakładając, że typ danych wejściowych jest prawidłowy, MFT ocenia, czy typ danych wyjściowych również się zmienia. Jeśli tak nie jest, przesyłanie strumieniowe będzie kontynuowane i nie jest wymagana żadna dalsza akcja.
4. Przed zmianą typu danych wyjściowych MFT musi przetworzyć wszystkie buforowane próbki danych wejściowych w następujący sposób:
   1. MFT nie unieważnia bieżącego typu danych wyjściowych.
   2. MFT generuje tyle danych wyjściowych, ile może pochodzić z buforowanych przykładów wejściowych.
   3. To, czy MFT akceptuje nowe próbki wejściowe podczas przetwarzania buforowanych próbek, jest opcjonalne. Jeśli tak, nowe próbki danych wejściowych będą używać nowego formatu wejściowego, więc MFT musi śledzić moment, w którym format się zmienił.
5. Gdy MFT przetworzy wszystkie próbki otrzymane przed zmianą typu wejściowego, IMFTransform::ProcessOutput zwraca wartość MF_E_TRANSFORM_STREAM_CHANGE.
6. Narzędzie MFT unieważnia bieżący typ danych wyjściowych i aktualizuje listę dostępnych typów nośników wyjściowych.
7. Klient negocjuje nowy typ danych wyjściowych zgodnie z wcześniejszym opisem.

asynchroniczne MFTs muszą zwrócić wartość TRUE dla atrybutu MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE. W przypadku korzystania z asynchronicznego protokołu MFT klient może założyć, że atrybut MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE jest ustawiony na true.

Gdy MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE jest TRUE, główną różnicą jest to, że klient nie musi opróżniać MFT przed ustawieniem nowego typu wejściowego. W związku z tym typ danych wejściowych może ulec zmianie, podczas gdy MFT trzyma się próbek wejściowych. Ważne jest, aby MFT nie po prostu usuwał tych próbek. Ponadto typ danych wyjściowych nie może ulec zmianie, dopóki usługa MFT przetworzy wszystkie buforowane dane.

Poprzedni akapit dotyczy zwłaszcza dekodatorów wideo, które mogą odbierać międzykodowane ramki poza kolejnością czasową, a tym samym muszą je buforować. Jeśli MFT nie buforuje próbek wejściowych, opróżnianie jest zasadniczo no-op. W takim przypadku MFT może ustawić MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE na wartość FALSE (lub pozostawić atrybut nieustawiony).

Należy również pamiętać, że każdy protokół MFT powinien prawidłowo obsługiwać zmiany formatu po opróżnieniu. Atrybut MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE wskazuje, czy MFT obsługuje zmiany formatu bez opróżniania.

Zmiana trybu przeplotu

Zmiany w trybie przeplotu wideo są specjalnym przypadkiem, ponieważ nie unieważniają bieżącego typu nośnika. Zamiast tego tryb przeplotu jest określony dla każdej ramki wideo poprzez ustawienie atrybutów na próbce multimedialnej. Wideo MFT powinno sprawdzić każdy przykład danych wejściowych pod kątem obecności tych flag.

Tryb przeplotu może ulec zmianie, gdy dominacja pola przełącza się z górnego pola na pole dolne lub gdy wideo przełącza się między obrazami progresywnymi i przeplotowymi.

Aby uzyskać więcej informacji, zobacz Interlace Flags on Samples.

Tematy pokrewne

pisanie niestandardowej MFT