aboutsummaryrefslogtreecommitdiffhomepage
path: root/video/out/opengl/hwdec_dxva2egl.c
Commit message (Collapse)AuthorAge
* vo_opengl: hwdec: reset hw_subfmt fieldGravatar wm42016-07-15
| | | | | | In theory, mp_image_params with hw_subfmt set to non-0 if imgfmt is not a hwaccel format is invalid. (It worked fine because nothing checks this yet.)
* d3d: merge angle_common.h into d3d.hGravatar wm42016-06-28
| | | | | | | | OK, this was dumb. The file didn't have much to do with ANGLE, and the functionality can simply be moved to d3d.c. That file contains helpers for decoding, but can always be present (on Windows) since it doesn't access any D3D specific libavcodec APIs. Thus it doesn't need to be conditionally built like the actual hwaccel wrappers.
* vo_opengl: hwdec: remove build-dependency on dxva2Gravatar wm42016-05-17
| | | | | | | | | | | | | wscript builds hwdec_dxva2gldx.c if gl-dxinterop is enabled, while video/dxva2.c depends on d3d-hwaccel. If d3d-hwaccel is disabled, then hwdec_dxva2gldx.c will fail to link, because it uses d3d9_surface_in_mp_image(), defined in dxva2.c. Fix this by removing the use of this function. It has barely any value at this point anyway. Just use the libavcodec documented way to get the surface directly. Fixes #3150.
* vo_opengl: angle: dynamically load ANGLEGravatar wm42016-05-11
| | | | | | | | | | | | ANGLE is _really_ annoying to build. (Requires special toolchain and a recent MSVC version.) This results in various issues with people having trouble to build mpv against ANGLE (apparently linking it against a prebuilt binary doesn't count, or using binaries from potentially untrusted sources is not wanted). Dynamically loading ANGLE is going to be a huge convenience. This commit implements this, with special focus on keeping it source compatible to a normal build with ANGLE linked at build-time.
* vo_opengl: refactor how hwdec interop exports texturesGravatar wm42016-05-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rename gl_hwdec_driver.map_image to map_frame, and let it fill out a struct gl_hwdec_frame describing the exact texture layout. This gives more flexibility to what the hwdec interop can export. In particular, it can export strange component orders/permutations and textures with padded size. (The latter originating from cropped video.) The way gl_hwdec_frame works is in the spirit of the rest of the vo_opengl video processing code, which tends to put as much information in immediate state (as part of the dataflow), instead of declaring it globally. To some degree this duplicates the texplane and img_tex structs, but until we somehow unify those, it's better to give the hwdec state its own struct. The fact that changing the hwdec struct would require changes and testing on at least 4 platform/GPU combinations makes duplicating it almost a requirement to avoid pain later. Make gl_hwdec_driver.reinit set the new image format and remove the gl_hwdec.converted_imgfmt field. Likewise, gl_hwdec.gl_texture_target is replaced with gl_hwdec_plane.gl_target. Split out a init_image_desc function from init_format. The latter is not called in the hwdec case at all anymore. Setting up most of struct texplane is also completely separate in the hwdec and normal cases. video.c does not check whether the hwdec "mapped" image format is supported. This should not really happen anyway, and if it does, the hwdec interop backend must fail at creation time, so this is not an issue.
* video: refactor how VO exports hwdec device handlesGravatar wm42016-05-09
| | | | | | | | | | | | | | | | | | | | | | | | | | The main change is with video/hwdec.h. mp_hwdec_info is made opaque (and renamed to mp_hwdec_devices). Its accessors are mainly thread-safe (or documented where not), which makes the whole thing saner and cleaner. In particular, thread-safety rules become less subtle and more obvious. The new internal API makes it easier to support multiple OpenGL interop backends. (Although this is not done yet, and it's not clear whether it ever will.) This also removes all the API-specific fields from mp_hwdec_ctx and replaces them with a "ctx" field. For d3d in particular, we drop the mp_d3d_ctx struct completely, and pass the interfaces directly. Remove the emulation checks from vaapi.c and vdpau.c; they are pointless, and the checks that matter are done on the VO layer. The d3d hardware decoders might slightly change behavior: dxva2-copy will not use the VO device anymore if the VO supports proper interop. This pretty much assumes that any in such cases the VO will not use any form of exclusive mode, which makes using the VO device in copy mode unnecessary. This is a big refactor. Some things may be untested and could be broken.
* vo_opengl: EGL: fix hwdec probingGravatar wm42016-05-05
| | | | | | | | | | | | | If ANGLE was probed before (but rejected), the ANGLE API can remain "initialized", and eglGetCurrentDisplay() will return a non-NULL EGLDisplay. Then if a native GL context is used, the ANGLE/EGL API will then (apparently) keep working alongside native OpenGL API. Since GL objects are just numbers, they'll simply fail to interact, and OpenGL will get invalid textures. For some reason this will result in black textures. With VAAPI-EGL, something similar could happen in theory, but didn't in practice.
* vo_opengl: dxva2egl: ignore alpha component in the mapped videoGravatar wm42016-03-17
| | | | | | | | | | | converted_imgfmt will be used by the renderer logic to build an appropriate shader chain. It doesn't influence the format of any textures. Thus it doesn't matter whether the hw video surface is mapped as RGB or RGBA. What matters is if the video actually contains alpha or not. Since virtually all hardware decoder do not support alpha in any way, this can be hardcoded as "no alpha". This avoids unnecessary GPU work.
* vo_opengl: add dxva2 interop to angle backendGravatar Kevin Mitchell2016-03-10
Like dxinterop, this uses StretchRect or RGB conversion. This is unavoidable as long as we use the dxva2 API, as there is no way to access the raw hardware decoded Direct3D9 surfaces.