Läs på engelska

Dela via

Hantera streamändringar

  • Artikel

Det här avsnittet beskriver hur en Media Foundation-transformering (MFT) ska hantera formatändringar under strömning.

Viktigt

Det här avsnittet gäller inte för kodare. Kodare bör inte sprida formatändringar enligt beskrivningen i det här avsnittet. Kodare bör endast acceptera en indatatyp som matchar den för närvarande konfigurerade utdatatypen.

 

Översikt över formatändringar

I allmänhet finns det två orsaker till att ett format kan ändras under strömning.

  • Klienten kan växla till en ström med ett nytt format. I digital-TV kan detta till exempel inträffa på grund av en kanaländring.
  • I vissa videoformat, till exempel H.264, kan bitströmmen signalera en formatändring. Sådana ändringar kan omfatta ändringar i fältdominans, videoupplösning eller bildpunktsproportion.

Om kodningstypen ändras kan klienten behöva ta bort MFT från pipelinen och ersätta den med en annan MFT. (Klienten kan till exempel behöva växla i en ny avkodare.) Det här avsnittet beskriver inte den situationen. Det här avsnittet beskriver endast det fall där den aktuella MFT kan hantera det nya formatet.

Om formatet ändras kan MFT kräva en ny indatatyp, en ny utdatatyp eller båda.

  • Ändringar av indatatypen initieras av klienten. En MFT ändrar aldrig sin egen indatatyp.
  • Ändringar av utdatatypen initieras av MFT. MFT signalerar att den kräver en ny utdatatyp och klienten förhandlar om den nya utdatatypen med MFT.

Därför är tre distinkta fall möjliga:

  • Klienten anger en ny indatatyp. MFT använder det nya formatet, utan att dess utdatatyp ändras.
  • Klienten anger en ny indatatyp och detta utlöser en ändring i utdatatypen.
  • Indatatypen ändras inte, men MFT identifierar en formatändring i bitströmmen, som kräver en ny utdatatyp.

Implementera formatändringar

Resten av det här avsnittet beskriver hur klienten ska bearbeta en formatändring och hur du implementerar formatändringar i en MFT.

Utdatatyp

Alla MFT kan initiera en ändring av dess utdatatyp enligt följande:

  1. Klienten anropar IMFTransform::ProcessOutput. MFT svarar på följande sätt:
    1. MFT producerar inte något utdataexempel i ProcessOutput.
    2. MFT anger flaggan MFT_OUTPUT_DATA_BUFFER_FORMAT_CHANGE i medlemen dwStatus av MFT_OUTPUT_DATA_BUFFER-strukturen.
    3. Metoden ProcessOutput returnerar felkoden MF_E_TRANSFORM_STREAM_CHANGE.
  2. Klienten anropar IMFTransform::GetOutputAvailableType. Den här metoden returnerar en uppdaterad uppsättning utdatatyper.
  3. Klienten anropar SetOutputType för att ange en ny utdatatyp.
  4. Klienten återupptar anropet ProcessInput/ProcessOutput.

Indatatyp

Ändringar av indatatypen initieras av klienten, aldrig av MFT. Om indatatypen ändras kan det utlösa en ändring av utdatatypen.

Den exakta sekvensen av händelser beror på värdet för attributet MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE.

Värde Beskrivning
FALSE Innan klienten anger en ny indatatyp måste den tömma MFT.
TRUE Klienten kan ange en ny indatatyp utan att tömma MFT.

 

En MFT exponerar det här attributet via dess IMFTransform::GetAttributes-metoden. Standardvärdet för det här attributet är FALSE; Om MFT inte anger attributet behandlar du värdet som FALSE-.

MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE är FALSK

  1. Klienten skickar meddelandet MFT_MESSAGE_COMMAND_DRAIN.
  2. Klienten tömmer MFT genom att anropa IMFTransform::P rocessOutput tills ProcessOutput returnerar MF_E_TRANSFORM_NEED_MORE_INPUT.
  3. Klienten anropar IMFTransform::SetInputType för att ange den nya indatatypen.
  4. MFT verifierar indatatypen. Om typen är ogiltig returnerar SetInputTypeMF_E_INVALIDMEDIATYPE eller någon annan felkod. Annars returnerar SetInputType S_OK.
  5. Förutsatt att indatatypen är giltig utvärderar MFT om utdatatypen också ändras. Om inte fortsätter strömningen och ingen ytterligare åtgärd krävs.
  6. Om utdatatypen ändras:
    1. MFT ogiltigförklarar den aktuella utdatamedietypen och uppdaterar listan över tillgängliga typer av utdatamedier.
    2. Nästa anrop till ProcessOutput returnerar MF_E_TRANSFORM_STREAM_CHANGE, som beskrivs i föregående avsnitt.
    3. Klienten anropar IMFTransform::GetOutputAvailableType för att hämta den uppdaterade listan över utdatatyper.
    4. Klienten anropar SetOutputType.

MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE är SANT

  1. Klienten anropar IMFTransform::SetInputType för att ange den nya indatatypen.
  2. MFT verifierar indatatypen. Om typen är ogiltig returnerar SetInputTypeMF_E_INVALIDMEDIATYPE eller någon annan felkod. Annars returnerar SetInputType S_OK.
  3. Förutsatt att indatatypen är giltig utvärderar MFT om utdatatypen också ändras. Om inte fortsätter strömningen och ingen ytterligare åtgärd krävs.
  4. Innan utdatatypen ändras måste MFT bearbeta cachelagrade indataexempel på följande sätt:
    1. Den aktuella utdatatypen ogiltigförklaras inte av MFT.
    2. MFT genererar så mycket utdata som möjligt från cachelagrade indataexempel.
    3. Det är valfritt om MFT accepterar nya indataexempel medan det bearbetar de cachelagrade exemplen. I så fall använder de nya indataexemplen det nya indataformatet, så MFT måste hålla reda på punkten när formatet ändrades.
  5. När MFT har bearbetat alla exempel som togs emot innan indatatypen ändrades returnerar IMFTransform::P rocessOutputMF_E_TRANSFORM_STREAM_CHANGE.
  6. MFT ogiltigförklarar den aktuella utdatatypen och uppdaterar listan över tillgängliga typer av utdatamedier.
  7. Klienten förhandlar om den nya utdatatypen enligt beskrivningen tidigare.

Asynkrona MFT:er måste returnera värdet TRUE för attributet MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE. När du använder en asynkron MFT kan klienten anta att attributet MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE är inställt på TRUE-.

När MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE är TRUEär den största skillnaden att klienten inte behöver tömma MFT innan en ny indatatyp anges. Därför kan indatatypen ändras medan MFT håller fast vid indataexempel. Det är viktigt att MFT inte bara ignorerar dessa exempel. Utdatatypen kan inte heller ändras förrän MFT bearbetar alla sina cachelagrade data.

Föregående stycke gäller särskilt för videodekodare, som kan ta emot interkodade bildrutor ur tidsordning och därför behöver lagra dem i cache. Om en MFT inte cachelagrar indataexempel är tömning i princip en no-op. I så fall kan MFT ställa in MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE till FALSE (eller låta attributet vara oändrat).

Observera också att varje MFT förväntas hantera formatändringar korrekt när de har tömts. Attributet MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE anger om MFT stöder formatändringar utan att tömmas.

Ändra i interlace-läge

Ändringar i videoöverflätningsläget är ett specialfall eftersom de inte ogiltigförklarar den aktuella medietypen. I stället anges interlace-läget för varje videoruta genom att ange attributen på medieprovet. En video-MFT bör kontrollera varje indataexempel för förekomsten av dessa flaggor.

Interlace-läget kan ändras när fältdominansen växlar från det översta fältet till det nedre fältet, eller när videon växlar mellan progressiva och sammanflätade bilder.

Mer information finns i Flätning av flaggor på exempel.

Skriva en anpassad MFT