DirectX Video Acceleration IAMVideoAccelerator Operational Specification
[La fonctionnalité associée à cette page, DirectShow, est une fonctionnalité héritée. Il a été remplacé par MediaPlayer, IMFMediaEngine et Audio/Video Capture in Media Foundation. Ces fonctionnalités ont été optimisées pour Windows 10 et Windows 11. Microsoft recommande vivement que le nouveau code utilise MediaPlayer, IMFMediaEngine et Audio/Video Capture dans Media Foundation au lieu de DirectShow, si possible. Microsoft suggère que le code existant qui utilise les API héritées soit réécrit pour utiliser les nouvelles API si possible.]
Le mécanisme précis de fonctionnement est le suivant :
Chaque profil de mode restreint défini ici a un GUID VA DirectX associé qui peut être pris en charge par les IPin::QueryAccept et IPin::ReceiveConnection d’une broche d’entrée en aval et répertoriés dans IAMVideoAccelerator::GetVideoAcceleratorGUIDs.
De même, chaque type de protocole de chiffrement à utiliser avec DirectX VA doit avoir un GUID de type de protocole de chiffrement associé qui peut être pris en charge par les IPin::QueryAccept et IPin::ReceiveConnection d’une broche d’entrée en aval et répertorié dans IAMVideoAccelerator::GetVideoAcceleratorGUIDs. La DXVA_NoEncrypt GUID « sans chiffrement » ne doit pas être envoyée dans cette liste, car elle est prise en charge et est donc implicite.
Après avoir appelé IPin::ReceiveConnection pour tenter une connexion à la broche d’entrée en aval, iamVideoAcceleratorNotify::GetCreateVideoAcceleratorData du décodeur retourne un pointeur vers une structure de données DXVA_ConnectMode contenant les informations de mode de connexion pour la connexion. IAMVideoAccelerator::GetCompBufferInfo doit être appelé avec *pdwNumTypesCompBuffers = 16 et retourne des informations de mémoire tampon compressées basées sur la convention selon laquelle le numéro de type de chaque mémoire tampon (tel que défini dans la section 3.4 de la spécification DirectX VA) peut être utilisé directement comme index de base zéro dans le tableau des structures de données AMVACompBufferInfo retournées. Cela nécessite que pour tous les types de mémoire tampon qui ne seront pas utilisés (y compris le type de mémoire tampon 0, car il n’y a pas d’utilisation définie de ce type de mémoire tampon), le pilote accélérateur fournit aux structures de données AMVACompBufferInfo une certaine forme de valeurs de paramètre « factices » (par exemple, dwNumCompBuffers=0, dwWidthToCreate=0, dwHeightToCreate=0 et dwBytesToAllocate=0).
Les indications de la fonction DXVA et les mémoires tampons de données associées sont envoyées à l’aide d’IAMVideoAccelerator::Execute. La fonction DXVA est indiquée dans le paramètre dwFunction de l’appel. Les seules fonctions DXVA pertinentes pour l’initialisation sont DXVA_ConfigQueryOrReplyFunc et DXVA_EncryptProtocolFunc.
Si dwFunction contient un DXVA_ConfigQueryOrReplyFunc, le pointeur lpPrivateInputData pour transmettre des données à l’accélérateur dans cet appel doit pointer vers une structure de données de configuration, le pointeur lpPrivateOutputData pour recevoir des informations de l’accélérateur pointe vers une zone où une structure de données de configuration alternative ou en double peut être placée, le pointeur pamvaBufferInfo pour un tableau d’AMVABUFFERINFO doit être NULL, et dwNumBuffers doit être égal à zéro. Le HRESULT retourné contient l’indication S_OK ou S_FALSE, ou E_FAIL ou E_INVALIDARG ou une autre indication d’erreur HRESULT en cas de problème grave dans l’exécution du protocole (par exemple, un paramètre de configuration non valide). Tous les appels à IAMVideoAccelerator::Execute pour toutes les utilisations de DXVA_ConfigQueryOrReplyFunc précèdent tous les autres appels à IAMVideoAccelerator::Execute.
Si dwFunction contient un DXVA_EncryptProtocolFunc, le pointeur lpPrivateInputData permettant de transmettre des données à l’accélérateur dans cet appel doit pointer vers une structure de données de protocole de chiffrement qui commence par DXVA_EncryptProtocolHeader, le pointeur lpPrivateOutputData pour recevoir des informations de l’accélérateur pointe vers une zone où les données à retourner (par exemple, un certificat) par le protocole de chiffrement (qui commence par DXVA_EncryptProtocolHeader) peuvent être placées, le pointeur pamvaBufferInfo pour un tableau d’AMVABUFFERINFO doit avoir la valeur NULL et dwNumBuffers est égal à zéro. Le HRESULT retourné contient S_OK tant que le protocole de chiffrement fonctionne normalement et contient E_FAIL ou E_INVALIDARG ou une autre indication d’erreur HRESULT en cas de problème grave dans l’exécution du protocole.
Après l’initialisation de l’opération de la façon ci-dessus, l’opération réelle du décodeur se poursuit comme suit :
IAMVideoAccelerator::BeginFrame doit être appelé avant d’envoyer des bDXVA_Func avec des paramètres de mémoire tampon compressée qui provoquent des écritures sur une surface de destination non compressée. L’objectif d’IAMVideoAccelerator::BeginFrame dans DirectX VA est d’associer des surfaces de destination à des valeurs d’index et d’informer le pilote de l’accélérateur vidéo de l’intention de lancer les écritures d’une surface afin que le pilote puisse répondre avec une indication indiquant si la surface est prête à être remplacée. La structure AMVABeginFrameInfo passée dans IAMVideoAccelerator::BeginFrame doit contenir un pointeur pInputData vers un seul paramètre WORD wBeginPictureIndex correspondant à l’index de frame passé dans IAMVideoAccelerator::BeginFrame (et dwSizeInputData doit avoir la valeur 2). Il s’agit de l’index à utiliser dans une mémoire tampon compressée pour commander une écriture sur la surface (par exemple, à utiliser comme wDecodedPictureIndex, wDeblockedPictureIndex, wBlendedDestinationIndex ou wPicResampleDestPicIndex). Chaque appel à IAMVideoAccelerator::BeginFrame doit être associé à un appel correspondant à IAMVideoAccelerator::EndFrame , comme décrit ci-dessous. Par exemple, si une image compressée doit être décodée, puis fusionnée alpha à l’aide d’un mélange de mémoire tampon à mémoire tampon frontale avec une image graphique, il y aurait un appel à IAMVideoAccelerator::BeginFrame avant de décoder l’image compressée dans une surface spécifiée dans wDecodedPictureIndex, puis un appel à IAMVideoAccelerator::EndFrame après avoir passé toutes les mémoires tampons compressées utilisées pour décoder l’image, ensuite, un deuxième appel à IAMVideoAccelerator::BeginFrame avant de commander une combinaison de fusion alpha de la source graphique avec l’image décodée dans une surface spécifiée dans wBlendedDestinationIndex, puis un deuxième appel à IAMVideoAccelerator::EndFrame après l’opération de combinaison alpha blend. Le pointeur pOutputData dans AMVABeginFrameInfo doit avoir la valeur NULL (et dwSizeOutputData doit être « 0 »). Le HRESULT retourné par IAMVideoAccelerator::BeginFrame doit être :
- S_OK si la surface non compressée est disponible et prête à être utilisée.
- E_PENDING si la surface non compressée n’est pas encore disponible, mais qu’elle sera bientôt disponible (si la surface non compressée est en cours de lecture pour affichage et que la lecture/l’affichage de la surface n’est pas encore terminé).
- E_FAIL ou E_INVALIDARG une autre indication d’erreur uniquement si une erreur de format de données ou de protocole est détectée (par exemple, une valeur incorrecte de dwSizeInputData ou un pOutputData non NULL ).
Les indications de la fonction DXVA et les mémoires tampons de données associées sont envoyées à l’aide d’IAMVideoAccelerator::Execute. Plusieurs bDXVA_Func valeur peuvent être indiquées dans le même appel à IAMVideoAccelerator::Execute. Les valeurs bDXVA_Func doivent être empaquetées dans le paramètre dwFunction de l’appel, avec la première commande de fonction dans les huit bases de données, la commande suivante dans les huit bits suivants, et ainsi de suite, avec les bits restants remplis de zéros. La valeur 0xFF pour bDXVA_Func indique que le bDXVA_Func est étendu à deux ou quatre octets. Si le deuxième octet est également 0xFF, cela indique que bDXVA_Func est étendu à quatre octets. Si les quatre bits supérieurs du troisième octet sont 0xF ou 0x0, cela indique que bDXVA_Func contient un DXVA_ConfigQueryOrReplyFunc ou un DXVA_EncryptProtocolFunc. Les commandes multioctets ne doivent pas indiquer la continuation après la fin de dwFunction. Le décodeur doit veiller à ce qu’aucune dépendance séquentielle ne soit présente entre différentes valeurs de bDXVA_Func spécifiées dans le même appel à IAMVideoAccelerator::Execute et que toutes les conditions de concurrence potentielles (par exemple, entre le décodage d’images et le sous-mélange d’images, entre le chargement de sous-images et le fusion de sous-images, etc.) sont empêchées par les appels appropriés à IAMVideoAccelerator :: BeginFrame et IAMVideoAccelerator::QueryRenderStatus avant les appels suivants à IAMVideoAccelerator::Execute.
Si dwFunction contient un DXVA_ConfigQueryOrReplyFunc, le pointeur lpPrivateInputData pour transmettre des données à l’accélérateur dans cet appel doit pointer vers une structure de données de configuration, le pointeur lpPrivateOutputData pour recevoir des informations de l’accélérateur pointe vers une zone où une structure de données de configuration alternative ou en double peut être placée, le pointeur pamvaBufferInfo pour un tableau d’AMVABUFFERINFO doit être NULL, et dwNumBuffers doit être égal à zéro. Le HRESULT retourné contient l’indication S_OK ou S_FALSE en réponse à la requête, ou E_FAIL ou E_INVALIDARG une autre indication d’erreur HRESULT en cas de problème grave dans l’exécution du protocole (par exemple, un paramètre invalid.configuration). Tous les appels à IAMVideoAccelerator::Execute pour toutes les utilisations de DXVA_ConfigQueryOrReplyFunc précèdent tous les autres appels à IAMVideoAccelerator::Execute.
Si dwFunction contient un DXVA_EncryptProtocolFunc, le pointeur lpPrivateInputData permettant de transmettre des données à l’accélérateur dans cet appel doit pointer vers une structure de données de protocole de chiffrement qui commence par DXVA_EncryptProtocolHeader, le pointeur lpPrivateOutputData pour recevoir des informations de l’accélérateur pointe vers une zone où les données à retourner (par exemple, un certificat) par le protocole de chiffrement (qui commence par DXVA_EncryptProtocolHeader) peuvent être placées, le pointeur pamvaBufferInfo pour un tableau d’AMVABUFFERINFO doit avoir la valeur NULL et dwNumBuffers est égal à zéro. Le HRESULT retourné contient S_OK tant que le protocole de chiffrement fonctionne normalement et contient E_FAIL ou E_INVALIDARG ou une autre indication d’erreur HRESULT en cas de problème grave dans l’exécution du protocole.
Si dwFunction ne contient pas de DXVA_ConfigQueryOrReplyFunc ou de DXVA_EncryptProtocolFunc, le pointeur lpPrivateInputData pour transmettre des données à l’accélérateur doit pointer vers une liste de description de mémoire tampon. Les quatre premières entrées de la structure de liste de description de la mémoire tampon pour chaque mémoire tampon (dwTypeIndex, dwBufferIndex, dwDataOffset et dwDataSize) doivent être égales à celles de la structure de données AMVABUFFERINFO pour la même mémoire tampon. Si bDXVA_Func est égal à « 1 » est spécifié dans dwFunction et bPicReadbackRequests est « 1 », Le pointeur lpPrivateOutputData pour la réception d’informations de l’accélérateur doit pointer vers une zone de mémoire persistante (par exemple tas) à remplir avec des données macroblock en lecture-retour à partir de l’accélérateur (ces données ne sont pas garanties d’être présentes jusqu’à IAMVideoAccelerator::QueryRenderStatus pour écrire dans la même mémoire tampon de paramètres d’image indique S_OK comme décrit à l’élément 10 ci-dessous). Sinon, le pointeur lpPrivateOutputData pour la réception d’informations à partir de l’accélérateur doit pointer vers un seul DWORD à définir sur l’une des valeurs d’indication suivantes (particulièrement utile pour signaler des erreurs de flux de bits dans une opération VLD hors hôte).
Valeur Description 0 Exécution OK. 1 Problème mineur dans le format des données rencontré. 2 Problème important rencontré dans le format des données. 3 Problème grave rencontré dans le format des données. 4 Autre problème grave rencontré. Si l’un ou l’autre type de problème « grave » est indiqué, le décodeur logiciel doit cesser d’utiliser la ou les fonctions, sauf si des mesures correctives peuvent être prises. Ces données retournées par l’accélérateur ne doivent pas être lues par l’hôte tant que le rendu de la mémoire tampon pour l’image n’est pas terminé, comme cela peut être testé par IAMVideoAccelerator::QueryRenderStatus. Le HRESULT retourné contient S_OK tant que l’opération d’interface fonctionne normalement et peut retourner E_FAIL ou E_INVALIDARG ou une autre indication d’erreur HRESULT en cas de problème grave.
La mémoire tampon des paramètres de décodage d’image doit figurer parmi les premières mémoires tampons envoyées pour le décodage de chaque image lors de l’utilisation d’IAMVideoAccelerator::Execute avec bDXVA_Func égale à « 1 », et toutes les mémoires tampons pour décoder une image dans un flux de bits doivent être envoyées avant les tampons pour décoder les images suivantes. Si une mémoire tampon de commande de contrôle macroblock est envoyée, une mémoire tampon de données de différence résiduelle correspondante est envoyée (contenant des données pour les mêmes macroblocks) avec le même appel IAMVideoAccelerator::Execute .
IAMVideoAccelerator::EndFrame doit être appelé après l’envoi de toutes les mémoires tampons compressées qui entraînent la création du contenu de sortie dans une surface non compressée spécifiée (résultat des opérations spécifiées pour wDecodedPictureIndex, wDeblockedPictureIndex, wBlendedDestinationIndex ou wPicResampleDestPicIndex). L’objectif de cet appel à IAMVideoAccelerator::EndFrame est d’informer le matériel de l’accélérateur vidéo que toutes les données nécessaires à l’opération spécifiée ont été envoyées. Le pointeur vers les données à envoyer en aval via IAMVideoAccelerator::EndFrame doit pointer vers un seul word wEndPictureIndex contenant l’index du frame qui se termine. Ce paramètre doit correspondre à la valeur wBeginPictureIndex spécifiée dans l’appel précédent à IAMVideoAccelerator::BeginFrame avant l’envoi des mémoires tampons compressées appropriées. Après un appel à IAMVideoAccelerator::EndFrame, La surface non compressée avec index wEndPictureIndex ne se trouve dans aucune image wDecodedPictureIndex, wDeblockedPictureIndex, wBlendedDestinationIndex ou wPicResampleDestPicIndex d’une image tant qu’un autre appel à IAMVideoAccelerator::BeginFrame est émis pour annoncer que cela se produira et qu’une S_OK a été retournée en conséquence. Toutefois, cet index de surface de destination peut se produire dans les commandes d’accès en lecture suivantes, telles que wForwardRefPictureIndex, wBackwardRefPictureIndex, wPicResampleSourcePicIndex ou bRefPicSelect[i]. Le HRESULT retourné par IAMVideoAccelerator::EndFrame doit être S_OK sauf s’il existe un type d’erreur de format ou de protocole de données, auquel cas il peut être E_FAIL ou E_INVALIDARG ou une autre indication d’erreur.
Dans le cas du décodage basé sur le champ (par exemple, dans les flux de bits MPEG-2), il n’y aura pas de mappage un-à-un d’images fonctionnelles dans le flux de bits avec des surfaces non compressées dans l’interface de l’accélérateur. Lors du décodage d’images de champ dans un flux mpeg-2 bits, deux « images » sont décodées pour produire une surface de sortie complète non compressée. Dans la définition de l’interface va DirectX, chaque trame correspond à chaque utilisation de wDecodedPictureIndex, wDeblockedPictureIndex, wBlendedDestinationIndex ou wPicResampleDestPicIndex. Par conséquent, deux paires d’appels à IAMVideoAccelerator::BeginFrame et IAMVideoAccelerator::EndFrame sont requises pour le décodage des images de champ dans des surfaces non compressées de sortie.
Un appel à IAMVideoAccelerator::QueryRenderStatus avec dwFlags égal à zéro qui se produit quelque temps après un appel à IAMVideoAccelerator::EndFrame avec un wEndPictureIndex particulier et vérifie la status d’une mémoire tampon qui a été envoyée qui contenait le wEndPictureIndex dans wDecodedPictureIndex, wDeblockedPictureIndex, wBlendedDestinationIndex ou wPicResampleDestPicIndex retournent une indication S_OK si toutes les opérations permettant d’écrire les données dans le surface non compressée terminée et retourne E_PENDING si l’opération n’est pas encore terminée. E_FAIL ou E_INVALIDARG ou une autre indication d’erreur peut être retournée en cas d’erreur de protocole.
Rubriques connexes