gstreamer/subprojects/gst-plugins-bad/sys/d3d11/meson.build

91 lines
2.6 KiB
Meson
Raw Normal View History

d3d11_sources = [
'gstd3d11av1dec.cpp',
'gstd3d11basefilter.cpp',
'gstd3d11compositor.cpp',
'gstd3d11convert.cpp',
'gstd3d11decoder.cpp',
'gstd3d11deinterlace.cpp',
'gstd3d11download.cpp',
'gstd3d11h264dec.cpp',
'gstd3d11h265dec.cpp',
'gstd3d11mpeg2dec.cpp',
'gstd3d11overlaycompositor.cpp',
'gstd3d11pluginutils.cpp',
'gstd3d11testsrc.cpp',
'gstd3d11upload.cpp',
'gstd3d11videosink.cpp',
'gstd3d11vp8dec.cpp',
'gstd3d11vp9dec.cpp',
'gstd3d11window.cpp',
d3d11videosink: Add support for drawing on application's own texture Add a way to support drawing on application's texture instead of usual window handle. To make use of this new feature, application should follow below step. 1) Enable this feature by using "draw-on-shared-texture" property 2) Watch "begin-draw" signal 3) On "begin-draw" signal handler, application can request drawing by using "draw" signal action. Note that "draw" signal action should be happen before "begin-draw" signal handler is returned NOTE 1) For texture sharing, creating a texture with D3D11_RESOURCE_MISC_SHARED_KEYEDMUTEX flag is strongly recommend if possible because we cannot ensure sync a texture which was created with D3D11_RESOURCE_MISC_SHARED and it would cause glitch with ID3D11VideoProcessor use case. NOTE 2) Direct9Ex doesn't support texture sharing which was created with D3D11_RESOURCE_MISC_SHARED_KEYEDMUTEX. In other words, D3D11_RESOURCE_MISC_SHARED is the only option for Direct3D11/Direct9Ex interop. NOTE 3) Because of missing synchronization around ID3D11VideoProcessor, If shared texture was created with D3D11_RESOURCE_MISC_SHARED, d3d11videosink might use fallback texture to convert DXVA texture to normal Direct3D texture. Then converted texture will be copied to user-provided shared texture. * Why not use generic appsink approach? In order for application to be able to store video data which was produced by GStreamer in application's own texture, there would be two possible approaches, one is copying our texture into application's own texture, and the other is drawing on application's own texture directly. The former (appsink way) cannot be a zero-copy by nature. In order to support zero-copy processing, we need to draw on application's own texture directly. For example, assume that application wants RGBA texture. Then we can imagine following case. "d3d11h264dec ! d3d11convert ! video/x-raw(memory:D3D11Memory),format=RGBA ! appsink" ^ |_ allocate new Direct3D texture for RGBA format In above case, d3d11convert will allocate new texture(s) for RGBA format and then application will copy again the our RGBA texutre into application's own texture. One texture allocation plus per frame GPU copy will hanppen in that case therefore. Moreover, in order for application to be able to access our texture, we need to allocate texture with additional flags for application's Direct3D11 device to be able to read texture data. That would be another implementation burden on our side But with this MR, we can configure pipeline in this way "d3d11h264dec ! d3d11videosink". In that way, we can save at least one texture allocation and per frame texutre copy since d3d11videosink will convert incoming texture into application's texture format directly without copy. * What if we expose texture without conversion and application does conversion by itself? As mentioned above, for application to be able to access our texture from application's Direct3D11 device, we need to allocate texture in a special form. But in some case, that might not be possible. Also, if a texture belongs to decoder DPB, exposing such texture to application is unsafe and usual Direct3D11 shader cannot handle such texture. To convert format, ID3D11VideoProcessor API needs to be used but that would be a implementation burden for application. Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1873>
2020-12-23 14:49:12 +00:00
'gstd3d11window_dummy.cpp',
'plugin.cpp',
]
extra_c_args = ['-DCOBJMACROS']
extra_args = ['-DGST_USE_UNSTABLE_API']
extra_dep = []
d3d11_option = get_option('d3d11')
if host_system != 'windows' or d3d11_option.disabled()
subdir_done()
endif
if not gstd3d11_dep.found() or not cc.has_header('dxva.h') or not cc.has_header('d3d9.h')
if d3d11_option.enabled()
error('The d3d11 was enabled explicitly, but required dependencies were not found.')
endif
subdir_done()
endif
runtimeobject_lib = cc.find_library('runtimeobject', required : false)
winmm_lib = cc.find_library('winmm', required: false)
if d3d11_winapi_only_app and (not d3dcompiler_lib.found() or not runtimeobject_lib.found())
if d3d11_option.enabled()
error('The d3d11 plugin was enabled explicitly, but required dependencies were not found.')
endif
subdir_done()
endif
# if build target is Windows 10 and WINAPI_PARTITION_APP is allowed,
# we can build UWP only modules as well
if d3d11_winapi_app
d3d11_sources += ['gstd3d11window_corewindow.cpp',
'gstd3d11window_swapchainpanel.cpp']
extra_dep += [runtimeobject_lib]
endif
if d3d11_winapi_desktop
d3d11_sources += ['gstd3d11window_win32.cpp']
d3d11_sources += ['gstd3d11screencapture.cpp',
'gstd3d11screencapturedevice.cpp',
'gstd3d11screencapturesrc.cpp']
# multimedia clock is desktop only API
if winmm_lib.found() and cc.has_header('mmsystem.h')
extra_args += ['-DHAVE_WINMM']
extra_dep += [winmm_lib]
endif
endif
# MinGW 32bits compiler seems to be complaining about redundant-decls
# when ComPtr is in use. Let's just disable the warning
if cc.get_id() != 'msvc'
extra_mingw_args = cc.get_supported_arguments([
'-Wno-redundant-decls',
])
extra_args += extra_mingw_args
endif
gstd3d11 = library('gstd3d11',
d3d11_sources,
c_args : gst_plugins_bad_args + extra_c_args + extra_args,
cpp_args: gst_plugins_bad_args + extra_args,
include_directories : [configinc],
dependencies : [gstbase_dep, gstvideo_dep, gmodule_dep, gstcontroller_dep, gstd3d11_dep, gstcodecs_dep] + extra_dep,
install : true,
install_dir : plugins_install_dir,
)
plugins += [gstd3d11]