Gestion de la négociation des types de données dans les codecs AVStream
Lorsqu’un appareil est initialisé, le module Proxy d’appareil (Devproxy) fourni par le système analyse les descripteurs de filtre fournis par le pilote. En outre, Devproxy expose les plages de données prises en charge par le pilote sur les broches d’entrée et de sortie de la transformation MFT (Media Foundation Transform) correspondante.
Lorsque la diffusion en continu commence, le pipeline MF et les applications en mode utilisateur utilisent ces plages pour effectuer une négociation de type de données avec le pilote.
Les interactions suivantes se produisent lors d’une négociation de type de données :
Devproxy récupère les plages de données fournies par le minidriver dans chaque descripteur de broche des filtres de codec matériel.
Devproxy émet une demande d’intersection de données au pilote.
Devproxy expose des types entièrement formés à MF.
Le générateur de topologie MF (l’équivalent MF du générateur de graphiques DirectShow) construit la topologie de streaming.
Une fois que le générateur de topologie MF a finalisé un type de données pour une broche d’entrée/sortie Devproxy, il définit le type de données sur la broche en appelant la fonction de rappel AVStrMiniPinSetDataFormat du minidriver. Si la broche KS n’existe pas, Devproxy appelle KsCreatePin.
Pour permettre une négociation de type de données réussie, le minidriver doit suivre les étapes suivantes :
Fournissez la liste des plages de données prises en charge dans le membre DataRanges de KSPIN_DESCRIPTOR pour chaque broche exposée incluse dans les filtres de codec matériel. Par exemple :
const PKSDATARANGE VideoDecoderInputPinDataRanges[8] = { (PKSDATARANGE)&H264DataFormat, (PKSDATARANGE)&VC_1DataFormat, (PKSDATARANGE)&VC_1DataFormatVIH2, (PKSDATARANGE)&WMV9DataFormat, (PKSDATARANGE)&WMV9DataFormatVIH2, (PKSDATARANGE)&DX50DataFormat, (PKSDATARANGE)&DX50DataFormatVIH2, (PKSDATARANGE)&MPEG2DataFormat };Dans ce cas, les plages spécifiées sont de types wrapper tels que KS_DATARANGE_MPEG2_VIDEO, KS_DATARANGE_VIDEO et KS_DATARANGE_VIDEO2. Dans l’exemple de code répertorié précédemment, chaque plage est de typecast sur KSDATARANGE.
Le dernier membre des structures wrapper est appelé structure de bloc de format, par exemple, KS_DATARANGE_MPEG2_VIDEO. VideoInfoHeader.
Un pilote qui prend en charge les plages de données continues doit spécifier les valeurs maximales dans la structure de bloc de format. Un pilote qui prend en charge les plages de données discrètes doit spécifier un tableau qui contient les valeurs discrètes dans les structures de blocs de format.
Si un pilote qui prétend prendre en charge un format donné échoue ultérieurement à une demande de format défini sur ce format, les performances peuvent être réduites. Répertorie uniquement les formats pour lesquels vous garantissez la prise en charge.
Les pilotes doivent autoriser la définition d’un type de média sur une broche en KSSTATE_STOP/KSSTATE_RUN. Aucune action n’est requise ici, si ce n’est pour s’assurer que le pilote ne l’interdit pas.
Le pilote doit fournir un gestionnaire d’intersection dans KSPIN_DESCRIPTOR_EX. IntersectHandler pour chaque broche.
Le minidriver doit fournir un gestionnaire pour la propriété KSPROPERTY_CONNECTION_PROPOSEDATAFORMAT .
Si le type de média de sortie est défini, un encodeur doit signaler les types d’entrée possibles (à l’aide d’un descripteur d’épingle) en fonction du type de média de sortie spécifié. Si aucun type de média de sortie n’est défini, les encodeurs ne doivent signaler aucun type de média d’entrée.
Si le type de média d’entrée est défini, les décodeurs doivent signaler les types de sortie possibles en fonction du type de média d’entrée spécifié.
Si le type de média d’entrée est défini, les processeurs vidéo doivent signaler leurs types de sortie en fonction du type de média d’entrée spécifié.
Le pilote doit prendre en charge l’interface ICodecAPI . Les composants en mode utilisateur peuvent ensuite obtenir des informations de configuration de codec à l’aide de cette interface en mode utilisateur.
Lors de l’installation d’un encodeur, les propriétés ICodecAPI sont d’abord définies, suivies du type de média de sortie. Ensuite, l’encodeur doit fournir uniquement les types d’entrée qu’il peut prendre en charge avec la configuration actuelle.
Les propriétés ICodecAPI et les propriétés de type de média de l’API Codec se chevauchent dans certaines zones, par exemple le profil et le niveau. Dans ce cas, les propriétés de l’API Codec liées au type de média remplacent les propriétés ICodecAPI. Une fois le type de média défini, le minidriver ne doit pas autoriser la modification de ces propriétés qui se chevauchent.
Lors de l’installation d’un décodeur, le type d’entrée est défini en premier. Après cela, le décodeur doit fournir uniquement les types de sortie qu’il peut prendre en charge avec son type d’entrée actuel.
L’entrée attendue dans un encodeur doit être 4:2:0 et au moins entrelacer/progressif NV12. La sortie attendue est un flux élémentaire compressé au format MPEG2 PS/TS ou H.264 Annexe B.
L’entrée attendue d’un décodeur est un flux élémentaire. La sortie attendue est la version non mise à l’échelle du flux source en tant que NV12 non compressé.
Les épingles sur un pilote AVStream doivent avoir des états indépendants les uns des autres. Cela signifie qu’une broche d’entrée peut passer de la KSSTATE_STOP à la KSSTATE_RUN tandis que la broche de sortie reste à l’état KSSTATE_STOP .
Lorsque le minidriver reçoit des requêtes GET de propriété avec des tailles de mémoire tampon de données variables, le minidriver doit interpréter une mémoire tampon NULL comme une requête pour la taille de la mémoire tampon requise. Dans ce cas, le pilote doit spécifier la longueur requise dans le champ Irp-IoStatus.Information> et retourner STATUS_BUFFER_OVERFLOW. En outre, le minidriver doit définir le code de retour comme un avertissement et non une erreur. Par exemple, suivez ces instructions avec les gestionnaires d’intersection de données.