summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vf: remove most GPL video filterswm42017-11-2913-1500/+0
| | | | | | | | | | | | | Almost all of them had their guts removed and replaced by libavfilter long ago, but remove them anyway. They're pointless and have been scheduled for deprecation. Still leave vf_format (because we need it in some form) and vf_sub (not sure). This will break some builtin functionality: lavfi yadif defaults are different, auto rotation and stereo3d downconversion are broken. These might be fixed later.
* vf: add vf_convert as interim replacement for vf_scalewm42017-11-292-2/+132
| | | | | | | | | | | We want to drop vf_scale, but we still need a way to auto convert between imgfmts. In particular, vf.c will auto insert the "scale" filter if the VO doesn't support a pixfmt. To avoid chaos, create a new vf_convert.c filter, based on vf_scale.c, but without the unrelicensed code parts. In particular, this filter does not do scaling and has no options. It merely converts from one imgfmt to another, if needed.
* vo_gpu: d3d11: don't use runtime version for UAV slot countJames Ross-Gowan2017-11-191-1/+1
| | | | | | FL 11_1 is only supported with the Direct3D 11.1 runtime anyway, so there is no need to check both the runtime version and the feature level.
* vo_gpu: d3d11_helpers: don't try BGRA_SUPPORTJames Ross-Gowan2017-11-191-20/+4
| | | | | | | | | The D3D11_CREATE_DEVICE_BGRA_SUPPORT flag doesn't enable support for BGRA textures. BGRA textures will be supported whether or not the flag is passed. The flag just fails device creation if they are not supported as an API convenience for programs that need BGRA textures, such as programs that use D2D or D3D9 interop. We can handle devices without BGRA support fine, so don't bother with the flag.
* vo_gpu: d3d11: mark the bgra8 format as unorderedJames Ross-Gowan2017-11-191-1/+1
| | | | Whoops. I was confused by the double-negative here.
* w32_common: move imm32.dll function to w32->api structpavelxdd2017-11-151-15/+12
| | | | | | | | | For consistency with already implemented shcore.dll function loading in w32->api: Moved loading of imm32.dll to w32_api_load, and declare pImmDisableIME function pointer in the w32->api struct. Removed unloading of imm32.dll.
* vo_gpu/context_android: Process surface resizes correctlysfan52017-11-141-10/+11
|
* vo_gpu: ra_gl: remove stride hackwm42017-11-121-4/+1
| | | | Same reasoning as in commit 9b5d062d36e3.
* vo_gpu: d3d11: remove flipped texture upload hackJames Ross-Gowan2017-11-121-8/+0
| | | | Made unnecessary by 4a6b04bdb930.
* cocoa: always return the target NSRect when in fullscreenAkemi2017-11-111-1/+4
| | | | | | there is no need to calculate a new rectangle when in fullscreen since we always want to cover the whole screen. so just return the target rectangle.
* vo_gpu: never pass flipped images to ra or ra backendswm42017-11-101-2/+7
| | | | | | | | | | | | | | | | | | | Seems like the last refactor to this code broke playing flipped images, at least with --opengl-pbo --gpu-api=opengl. Flipping is rather a shitmess. The main problem is that OpenGL does not support flipped uploading. The original vo_gl implementation considered it important to handle the flipped case efficiently, so instead of uploading the image line by line backwards, it uploaded it flipped, and then flipped it in the renderer (basically the upload path ignored the flipping). The ra code and backends probably have an insane and inconsistent mix of semantics, so fix this by never passing it flipped images in the first place. In the future, the backends should probably support flipped images directly. Fixes #5097.
* vo_gpu: hwdec_d3d11va: allow zero-copy video decodingJames Ross-Gowan2017-11-073-62/+159
| | | | | | | | | | | | | | Like the manual says, this is technically undefined behaviour. See: https://msdn.microsoft.com/en-us/library/windows/desktop/ff476085.aspx In particular, MSDN says texture arrays created with the BIND_DECODER flag cannot be used with CreateShaderResourceView, which means they can't be sampled through SRVs like normal Direct3D textures. However, some programs (Google Chrome included) do this anyway for performance and power-usage reasons, and it appears to work with most drivers. Older AMD drivers had a "bug" with zero-copy decoding, but this appears to have been fixed. See #3255, #3464 and http://crbug.com/623029.
* vo_gpu: d3d11: enhance cache invalidationJames Ross-Gowan2017-11-071-4/+70
| | | | | | | | The shader cache in ra_d3d11 caches the result of shaderc, crossc and the D3DCompiler DLL, so it should be invalidated when any of those components are updated. This should make the cache more reliable, which makes it safer to enable gpu-shader-cache-dir. Shader compilation is slow with D3D11, so gpu-shader-cache-dir is highly necessary
* vo_gpu: d3d11: log shader compilation timesJames Ross-Gowan2017-11-071-0/+26
| | | | | | | Some shaders take a _long_ time to compile with the Direct3D compiler. The ANGLE backend had this problem too, to a certain extent. Logging should help identify which shaders cause long stalls and could also help with benchmarking ways of reducing compile times.
* vo_gpu: move d3d11_screenshot to shared codeJames Ross-Gowan2017-11-074-80/+100
| | | | This can be used by the ANGLE backend and ra_d3d11.
* vo_gpu: d3d11: add RA caps for ra_d3d11James Ross-Gowan2017-11-077-6/+35
| | | | | | | | | | | | | | | | ra_d3d11 uses the SPIR-V compiler to translate GLSL to SPIR-V, which is then translated to HLSL. This means it always exposes the same GLSL version that the SPIR-V compiler supports (4.50 for shaderc/glslang.) Despite claiming to support GLSL 4.50, some features that are tied to the GLSL version in OpenGL are not supported by ra_d3d11 when targeting legacy Direct3D feature levels. This includes two features that mpv relies on: - Reading from gl_FragCoord in the fragment shader (requires FL 10_0) - textureGather from any texture component (requires FL 11_0) These features have been exposed as new RA caps.
* vo_gpu: d3d11: initial implementationJames Ross-Gowan2017-11-079-5/+2739
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a new RA/vo_gpu backend that uses Direct3D 11. The GLSL generated by vo_gpu is cross-compiled to HLSL with SPIRV-Cross. What works: - All of mpv's internal shaders should work, including compute shaders. - Some external shaders have been tested and work, including RAVU and adaptive-sharpen. - Non-dumb mode works, even on very old hardware. Most features work at feature level 9_3 and all features work at feature level 10_0. Some features also work at feature level 9_1 and 9_2, but without high-bit- depth FBOs, it's not very useful. (Hardware this old is probably not fast enough for advanced features anyway.) Note: This is more compatible than ANGLE, which requires 9_3 to work at all (GLES 2.0,) and 10_1 for non-dumb-mode (GLES 3.0.) - Hardware decoding with D3D11VA, including decoding of 10-bit formats without truncation to 8-bit. What doesn't work / can be improved: - PBO upload and direct rendering does not work yet. Direct rendering requires persistent-mapped PBOs because the decoder needs to be able to read data from images that have already been decoded and uploaded. Unfortunately, it seems like persistent-mapped PBOs are fundamentally incompatible with D3D11, which requires all resources to use driver- managed memory and requires memory to be unmapped (and hence pointers to be invalidated) when a resource is used in a draw or copy operation. However it might be possible to use D3D11's limited multithreading capabilities to emulate some features of PBOs, like asynchronous texture uploading. - The blit() and clear() operations don't have equivalents in the D3D11 API that handle all cases, so in most cases, they have to be emulated with a shader. This is currently done inside ra_d3d11, but ideally it would be done in generic code, so it can take advantage of mpv's shader generation utilities. - SPIRV-Cross is used through a NIH C-compatible wrapper library, since it does not expose a C interface itself. The library is available here: https://github.com/rossy/crossc - The D3D11 context could be made to support more modern DXGI features in future. For example, it should be possible to add support for high-bit-depth and HDR output with DXGI 1.5/1.6.
* vo_gpu: export the GLSL format qualifier for ra_formatJames Ross-Gowan2017-11-075-14/+77
| | | | | | | | | | | | | | | Backported from @haasn's change to libplacebo, except in the current RA, there's nothing to indicate an ra_format can be bound as a storage image, so there's no way to force all of these formats to have a glsl_format. Instead, the layout qualifier will be removed if glsl_format is NULL. This is needed for the upcoming ra_d3d11 backend. In Direct3D 11, while loading float values from unorm images often works as expected, it's technically undefined behaviour, and in Windows 10, it will cause the debug layer to spam the log with error messages. Also, apparently in GLSL, the format name must match the image's format exactly (but in Direct3D, it just has to have the same component type.)
* vo_gpu: add namespace query mechanismJames Ross-Gowan2017-11-074-10/+21
| | | | | | Backported from @haasn's change to libplacebo. More flexible than the previous "shared || non-shared" distinction. The extra flexibility is needed for Direct3D 11, but it also doesn't hurt code-wise.
* vo_lavc: remove messy delayed subtitle rendering logicwm42017-11-071-10/+8
| | | | | | | | | | | | | | | | | | | | | For some reason vo_lavc's draw_image can buffer the frame and encode it only later. Also, there is logic for rendering the OSD (i.e. subtitles) only when needed. In theory this can lead to subtitles being pruned before it tries to render them (as the subtitle logic doesn't know that the VO still needs them later), although this probably never happens in reality. The worse issue, that actually happened, is that if the last frame gets buffered, it attempts to render subtitles in the uninit callback. At this point, the subtitle decoder is already torn down and all subtitles removed, thus it will draw nothing. This didn't always happen. I'm not sure why - potentially in the working cases, the frame wasn't buffered. Since this logic doesn't have much worth, except a minor performance advantage if frames with subtitles are dropped, just remove it. Hopefully fixes #4689.
* img_format: remove some guards against old ffmpeg APIwm42017-11-061-5/+2
| | | | These are always present in ffmpeg-mpv, and never in Libav.
* vo_gpu: don't re-render hwdec frames when repeating frameswm42017-11-031-19/+11
| | | | | | | | | | | | | Repeating frames (for display-sync) is not supposed to render the entire frame again. When using hardware decoding, it unfortunately did: the renderer uses the frame ID to check whether the frame data changed, and unmapping the hwdec frame clears it. Essentially reverts commit 761eeacf5407cab07. Back then I probably thought it would be a good idea to release the hwdec image quickly in order to return it to the decoder, but they're referenced anyway. This should increase the performance and reduce GPU work.
* vo_gpu: ra_gl: fix minimum GLSL version to 120wm42017-11-031-1/+1
| | | | Not sure why there was 110, or why there is even a default.
* vo_gpu: fix mobius tone mapping compatibility to GLSL 120wm42017-11-031-1/+1
| | | | | | | | | Normally such code is didsabled by have_mglsl==false in check_gl_features(), but apparently not this one. Just fix it. Seems also more readable. Fixes #5069.
* vo_gpu: ra_gl: fix crash trying to use glBindBufferBase on GL 2.1wm42017-11-031-2/+7
| | | | | | | Apparently this is required, but it doesn't check for it. To be fair, this was tested by creating a compatibility context and pretending it's GL 2.1. GL_ARB_shader_storage_buffer_object actually requires GL 4.0 or up, but GL_ARB_uniform_buffer_object requires only GL 2.0.
* vd_lavc: restore --hwdec-image-format and d3d11 opaque modewm42017-11-022-1/+6
| | | | | When the ifdeffery for the frame_params API was added, the new code accidentally didn't include this.
* vo_gpu: potentially fix icc-profile-auto updatingwm42017-11-011-1/+1
| | | | | | | | | | | vo_gpu.c will call gl_video_icc_auto_enabled() to check whether it should retrieve the ICC profile. But the value returned by this function will be outdated, because gl_video_update_options() is not called yet. Change the order of function calls so that this is done after updating the options. (This is fairly chaotic, but I guess this code will be refactored a dozen of times anyway in the future.)
* vd_lavc: clean out more hwdec legacy codewm42017-10-313-39/+5
| | | | | | | | All this code used to be required by the old variants of the libavcodec hw decoding APIs. Almost all of that is gone, although the mediacodec API unfortunately still pulls in some old stuff (but not all of it). (mediacodec build/functionality is untested, but should work.)
* vd_lavc: remove more dead legacy codewm42017-10-314-108/+2
| | | | | | | | | | | | | | All of this was dead code and completely unused. get_buffer2_hwdec() is the biggest chunk. One unfortunate thing about it is that, while it was active, it could perform a software fallback much faster, because it didn't have to wait until a full frame is decoded (it actually decoded a full frame, but the current code has to decode many more frames due to the codec delay, because the current code waits until the API returns a decoded frame.) We should probably restore the latter, although since it's an optional optimization, and the current behavior doesn't change with the removal of this code, don't actually do anything about it.
* videotoolbox: use generic code for dummy hwdevice initwm42017-10-312-75/+19
| | | | | And move the remaining code (just 2 struct constant definitions) to vd_lavc.c.
* vd_lavc: remove dead legacy codewm42017-10-312-22/+0
|
* d3d: remove some legacy codewm42017-10-311-42/+0
| | | | See #5062.
* vd_lavc: makre sure required headers are included early enoughwm42017-10-312-1/+1
| | | | Should fix #5062.
* vd_lavc: move display mastering data stuff to mp_imagewm42017-10-304-42/+22
| | | | | | | | | | | This is where it should be. It only wasn't because of an old libavcodec bug, that returned the side data only on every IDR. This required some sort of caching, which is now dropped. (mp_image wouldn't have been able to do this kind of caching, because this code is stateless.) We don't support these old libavcodec versions anymore, which is why this is not needed anymore. Also move initialization of rotation/stereo stuff to dec_video.c.
* Bump libav* API usewm42017-10-302-163/+8
| | | | (Not tested on Windows and OSX.)
* vo_gpu: remove a redundant ifdefwm42017-10-301-2/+0
|
* vd_lavc: make --hwdec=nvdec-copy actually workwm42017-10-302-3/+32
| | | | | | | | | | | | This simply didn't work. Unlike cuda-copy, this is a true hwaccel, and obviously we need to provide it a device. Implement this in a relatively generic way, which can probably reused directly by videotoolbox (not doing this yet because it would require testing on OSX). Like with cuda-copy, --cuda-decode-device is ignored. We might be able to provide a more general way to select devices at some later point.
* vd_lavc: remove need for duplicated cuda GL interop backendwm42017-10-304-20/+7
| | | | | | | This is just a dumb consequence of HWDEC_ types somehow being part of both decoder and VO. Obviously, the VO should only care about supporting specific hardware surface types or providing specific device types, but until they are separated, stupid unintuitive mismatches will occur.
* Get rid of deprecated AVFrame accessorswm42017-10-302-2/+2
| | | | | | Fist we were required to use them for ABI compat. reasons (and other BS), now they're deprecated and we're supposed to access them directly again.
* hwdec_drmprime_drm: fix segv with --hwdecRyo Munakata2017-10-301-1/+4
|
* vd_lavc: add support for nvdec hwaccelwm42017-10-284-1/+36
| | | | | | | | See manpage additions. (In ffmpeg-mpv and Libav, this is still called "cuvid". Libav won't work yet, because it has no frame params support yet, but this could get fixed soon.)
* vd_lavc: use avcodec_fill_hw_frames_parameters() APIwm42017-10-272-2/+112
| | | | | | | | This removes the need for codec- and API-specific knowledge in the libavcodec hardware acceleration API user. For mpv, this removes the need for vd_lavc_hwdec.pixfmt_map and a few other things. (For now, we still keep the "old" parts for the sake of supporting older Libav, and FFgarbage.)
* vo_gpu: fix ra_tex_upload_pbo for 2D texturesNiklas Haas2017-10-271-1/+5
| | | | | | params->rc was ignored in the calculation for the buffer size. I fucking hate this stupid ra_tex_upload signature where *rc is randomly relevant or not.
* vo_gpu: osd: simplify some codewm42017-10-271-5/+5
| | | | | | Coverity complains about this, but it's probably a false positive. Anyway, rewrite it in a slightly more readable way. Now it's more obvious that it is correct.
* vd_lavc: more aggressive frame dropping for intra only codecswm42017-10-262-5/+15
| | | | | | | | Should speed up seeks. (Unfortunately it's useless for backstepping. Backstepping is like precise seeking, except we're unable to drop frames, as we can't know the previous frame if we drop it.)
* vo_gpu: change --tone-mapping-desaturate algorithmNiklas Haas2017-10-252-9/+11
| | | | | | | | | | | | | | | Comparing mpv's implementation against the ACES ODR reference samples and algorithms, it seems like they're happy desaturating highlights _way_ more aggressively than mpv currently does. And indeed, looking at some example clips like The Redwoods (which is actually well-mastered), the current desaturation produces unnatural-looking brightness fringes where the sky meets the treeline. Adjust the algorithm to make it apply to a much larger, more gradual brightness region; and change the interpretation of the parameter. As a bonus, the new parameter is actually sanely scaled (higher values = more desaturation). Also, make it scale based on the signal level instead of the luminance, to avoid under-desaturating bright blues.
* demux: get rid of demux_packet.new_segment fieldwm42017-10-241-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | The new_segment field was used to track the decoder data flow handler of timeline boundaries, which are used for ordered chapters etc. (anything that sets demuxer_desc.load_timeline). This broke seeking with the demuxer cache enabled. The demuxer is expected to set the new_segment field after every seek or segment boundary switch, so the cached packets basically contained incorrect values for this, and the decoders were not initialized correctly. Fix this by getting rid of the flag completely. Let the decoders instead compare the segment information by content, which is hopefully enough. (In theory, two segments with same information could perhaps appear in broken-ish corner cases, or in an attempt to simulate looping, and such. I preferred the simple solution over others, such as generating unique and stable segment IDs.) We still add a "segmented" field to make it explicit whether segments are used, instead of doing something silly like testing arbitrary other segment fields for validity. Cached seeking with timeline stuff is still slightly broken even with this commit: the seek logic is not aware of the overlap that segments can have, and the timestamp clamping that needs to be performed in theory to account for the fact that a packet might contain a frame that is always clipped off by segment handling. This can be fixed later.
* video : Move drm options to substruct.Lionel CHAZALLON2017-10-235-4/+30
| | | | | This allows to group them and most of all query the group config when needed and when we don't have the access to vo.
* Add DRM_PRIME Format Handling and Display for RockChip MPP decodersLionel CHAZALLON2017-10-2314-19/+773
| | | | | | | | | | | This commit allows to use the AV_PIX_FMT_DRM_PRIME newly introduced format in ffmpeg that allows decoders to provide an AVDRMFrameDescriptor struct. That struct holds dmabuf fds and information allowing zerocopy rendering using KMS / DRM Atomic. This has been tested on RockChip ROCK64 device.
* video : allow drm primary plane to be transparent for egl contextLionel CHAZALLON2017-10-231-2/+2
| | | | | We want primary plane to be one top of overlay (video), so we need it to be 32 bits.
* vo_opengl: hwdec_vaegl: Disable vaExportSurfaceHandle()Mark Thompson2017-10-231-3/+3
| | | | | libva 2.0 (VAAPI 1.0.0) was released without it, but it is scheduled to be included in libva 2.1.
* wayland_common: check monitor scaleRostislav Pehlivanov2017-10-221-3/+9
| | | | | | | Since we divide by it in a couple of places and compositors can be crazy, its better to be safe than sorry. Also checks cursor spawn durinig init (pointless since it does again on cursor entry but its more correct).
* wayland_common: improve cursor code and scale cursor properlyRostislav Pehlivanov2017-10-222-26/+35
| | | | | | It seems the cursor hadn't had its position properly adjusted when scaled. Hence, bring back correct buffer scaling to make the cursor look fine. Also the cursor surface now gets created sooner so that's better.
* wayland_common: don't scale the cursor wl_bufferRostislav Pehlivanov2017-10-191-1/+0
| | | | | Only gnome does something as stupid as always applying scaling to the cursor rather than just using a larger sized one with HIDPI.
* video: fix alpha handlingwm42017-10-191-2/+4
| | | | | | | | | Regression since ec6e8a31e092a1d. Removal of the explicit else case always applies the conversion to premultiplied alpha in the else branch. We want to scale with multiplied alpha, but we don't want to multiply with alpha again on top of it. Fixes #4983, hopefully.
* vo_gpu: add rgba16hf to the list of FBO formatsJames Ross-Gowan2017-10-181-1/+2
| | | | | | | This should be functionally identical to rgba16f, since the formats only differ in their representation on the CPU, but it could be useful for RA backends that don't expose rgba16f, like Vulkan. It's definitely useful for the WIP D3D11 backend.
* vo_rpi: fix build (probably)wm4