On Thu, 4 May 2017 08:44:04 +0200 wm4 <[email protected]> wrote:
> + AV_PIX_FMT_D3D11, ///< HW decoding through Direct3D11 via new API, > Picture.data[0] contains a ID3D11Texture2D pointer, and data[1] contains the > texture array index of the frame as intptr_t if the ID3D11Texture2D is an > array texture (or 0 if it's a normal texture) > + > AV_PIX_FMT_NB, ///< number of pixel formats, DO NOT USE THIS if > you want to link with shared libav* By the way, there is probably no strict need for a new pixfmt. With the "new" D3D11 hwaccel, we need it to carry different objects (a texture handle instead of a decoder view). So the semantics change which would warrant a new pixfmt. On the other hand, there's no hard technical reason to use a new pixfmt. We could just change the definition of AV_PIX_FMT_D3D11VA_VLD to depend on which API is used. Pro (for new, separate AV_PIX_FMT_D3D11): - cleaner - avoids confusion - chance that the old API is deprecated, and AV_PIX_FMT_D3D11VA_VLD is removed, also removing the problem Contra: - libavcodec dxva2 code needs tons of changes to deal with both d3d11 formats - separate AVHWAccels needed just because of the pixfmt Which should it be? Or maybe I'm missing something big here due to sleep deprivation. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
