On Tue, 9 May 2017 08:48:45 +0100 Mark Thompson <s...@jkqxz.net> wrote:
> On 09/05/17 06:07, wm4 wrote: > > On Mon, 8 May 2017 22:59:11 +0100 > > Mark Thompson <s...@jkqxz.net> wrote: > >> On 04/05/17 07:44, wm4 wrote: > >>> To be used with the new d3d11 hwaccel decode API. > >>> > >>> With the new hwaccel API, we don't want surfaces to depend on the > >>> decoder (other than the required dimension and format). The old D3D11VA > >>> pixfmt uses ID3D11VideoDecoderOutputView pointers, which include the > >>> decoder configuration, and thus is incompatible with the new hwaccel > >>> API. This patch introduces AV_PIX_FMT_D3D11, which uses ID3D11Texture2D > >>> and an index. It's simpler and compatible with the new hwaccel API. > >>> > >>> The introduced hwcontext supports only the new pixfmt. > >>> > >>> Significantly based on work by Steve Lhomme <rob...@gmail.com>, but with > >>> heavy changes/rewrites. > > > > > >>> --- > >>> Somewhat sketchy: if initial_pool_size is set, the pool is assumed to > >>> be static. > >>> --- > > > > Any comments on that? > > It's how all of the other implementations with fixed pools work, so fine? Ah, you're right. when I looked at the vaapi implementation, I thought it allocated normal surfaces once the initial pool size is exceeded, but on a closer look it actually explicitly fails allocation in that case. So my code behaves the same. > >> Is the staging texture somehow magic such that it isn't going to be > >> uncached memory or anything tricky like that? > > > > Yes, I'm fairly sure it simply lives in CPU memory, and > > CopySubresourceRegion() will access the actual video memory. > > > > This is also why d3d11 with copy back is slower than dxva2, apparently. > > Well, at least it's probably faster on Braswell :P How so? For dxva2, we do use a magic memcpy for uncached memory. > >>> + 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) > >> > >> The old format was specifically for decoding, but the new one is more > >> general than that. > > > > OK. Well, someone new to the API who's trying to figure out which > > format to use is going to be confused, so mentioning the new decode API > > might help. > > Yeah, fair. Mention decoding but not as the only thing, then. Fine, maybe: + AV_PIX_FMT_D3D11, ///< Direct3D11 texture (in particular for HW decoding through the new d3d11 hwaccel 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) _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
