summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vo_gpu/d3d11: add adapter name validation and listing with "help"Jan Ekström2019-09-293-6/+73
| | | | Not the prettiest way to get it done, but seems to work.
* vo_gpu/d3d11: refactor pthread_once d3d11 loading to functionJan Ekström2019-09-291-6/+15
| | | | Lets us reuse this in the future.
* vo_gpu/d3d11: utilize the passed adapter nameJan Ekström2019-09-291-5/+77
| | | | | | Normalize nullptr and an empty string both to nullptr to simplify handling. API users cannot set a value back to nullptr, so both an empty string as well as nullptr should behave the same.
* vo_gpu/d3d11: add an option for the adapter nameJan Ekström2019-09-292-0/+6
| | | | Set it from the adapter name in the d3d11 options.
* video/d3d11: add adapter selection by name into d3d11 optionsJan Ekström2019-09-291-0/+3
| | | | | This lets the user define an adapter name that can then be passed further into the internals.
* vo_gpu/d3d11_helpers: also load up CreateDXGIFactory1Jan Ekström2019-09-291-4/+13
| | | | Just a factory, without a device, is required for listing of devices.
* vo_drm: fix flickering when setting pan/scanAnton Kindestam2019-09-291-4/+0
| | | | | | | | Turns out clearing all frambuffers in reconfig isn't such a great idea when you also end up here when setting pan/scan. I guess this is just a leftover from a previous iteration of vo_drm where doing this made sense.
* vo_gpu: hwdec_cuda: Synchronise OpenGL InteropPhilip Langdale2019-09-283-0/+8
| | | | | | | | | | | | | | | | | | | | | Previously, there appeared to be implicit synchronisation in the GL interop path, and we never observed any visual glitches. However, recently, I started seeing stuttering in the GL path and on closer examination it looked like read-before-write behaviour where GL would display an old frame again rather than the current one. After verifying that disabling hwdec made the problem go away, I tried adding a cuStreamSynchronize() after the memcpys and that also resolved the problem, so it's clearly sync related. cuStreamSynchronize() is a CPU sync and so more heavy-weight than you want, but it's the only tool we have. There is no mechanism defined for synchronising GL to CUDA (It looks like there is a way to synchronise CUDA to EGL but it appears one way and so wouldn't directly address this problem). Anyway, empirically, the output now looks the same as with hwdec off.
* vo_drm: support controlling swapchain depth using swapchain-depth optionAnton Kindestam2019-09-281-10/+13
|
* vo: make swapchain-depth option generic for all VOsAnton Kindestam2019-09-288-16/+10
| | | | In preparation for making vo_drm able to use swapchain-depth
* drm: refactor page_flipped callbackAnton Kindestam2019-09-284-109/+71
| | | | | Avoid duplicating the same callback function in both context_drm_egl and vo_drm.
* vo_drm: Implement N-buffering and presentation feedbackAnton Kindestam2019-09-281-39/+215
| | | | | | | | | | | Swapchain depth currently hard-coded to 3 (4 buffers). As we now avoid redrawing on repeat frames (we simply requeue the same fb again), this should give a nice performance boost when playing videos with a lower FPS than the display FPS in video-sync=display-resample mode. Presentation feedback has also been implemented to help counter the significant amounts of jitter we would otherwise be seeing.
* vo_drm: fix more than 2 buffersAnton Kindestam2019-09-281-1/+1
| | | | Now we can increase BUF_COUNT. Yay.
* drm: move struct vsync_tuple into drm_common as drm_vsync_tupleAnton Kindestam2019-09-282-9/+8
| | | | This struct will be useful in vo_drm as well.
* context_drm_egl: define EGL_PLATFORM_GBM_MESA, EGL_PLATFORM_GBM_KHR if not ↵Anton Kindestam2019-09-271-0/+8
| | | | | | | in system headers To account for oddball setups where EGL_PLATFORM_GBM_MESA or EGL_PLATFORM_GBM_KHR might not be defined for whatever reason.
* video: add pure gamma TRC curves for 2.0, 2.4 and 2.6.Wessel Dankers2019-09-274-0/+27
|
* options: add M_OPT_FILE to some more options that take filesPhilip Sequeira2019-09-271-2/+2
|
* vo_gpu: hwdec_drmprime_drm: add hwdec ctxJonas Karlman2019-09-271-0/+14
| | | | | | | This allows to use drm hwaccels that require a hwdevice. Tested with v4l2request hwaccel and cedrus driver on an allwinner device running mpv with --vo=gpu --gpu-context=drm --hwdec=drm.
* hwdec_vaapi_gl: add missing compatibility defineswm42019-09-271-0/+6
| | | | | | | | | | | At first, this code used only 1 plane, so the compatibility stuff was sufficient. But then use of planes 1 and 2 was added, without extending the compatibility stuff. I think I've seen a case recently where this broke the build and caused users to apply invalid fixes, but I don't remember where. It's possible that I didn't get all defines that are needed.
* vo_gpu: vulkan: add Android contextsfan52019-09-272-0/+98
|
* context_android: move common code to a separate filesfan52019-09-274-52/+152
| | | | | | In preparation for a Vulkan Android context. This also replaces querying for EGL_WIDTH and EGL_HEIGHT with equivalent ANativeWindow calls.
* vo_gpu: d3d11: don't reset frame stats after pauseJames Ross-Gowan2019-09-261-9/+0
| | | | | | | | | | | | | | | | | | | | | | I think I was wrong about having to reset the stats when mpv stops producing frames, eg. when it's paused. As long as the swapchain doesn't underflow, last_queue_display_time will still be accurate, because the next frame produced should still be presented one vsync after the last one in the swapchain. If the swapchain underflows (which is the common case for when mpv is paused for more than 150ms,) the next predicted frame time should be in the past. It should be fine to leave last_queue_display_time unset in this case, since vo.c will use the current time instead, which is a decent guess (though it doesn't take vsync phase into account.) last_sync_refresh_count and last_sync_qpc_time should be kept on swapchain underflow as well. Assuming the display refresh rate doesn't change while mpv is paused, they'll only provide a more accurate guess of the vsync duration when mpv starts playing again. Also, vsync_duration_qpc never needs to get reset. It will get overwritten immediately in most cases, and when it doesn't, it's still a better guess of the vsync duration than nothing.
* client API: fix potential deadlock problems by throwing more shit at itwm42019-09-264-21/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The render API (vo_libmpv) had potential deadlock problems with MPV_RENDER_PARAM_ADVANCED_CONTROL. This required vd-lavc-dr to be enabled (the default). I never observed these deadlocks in the wild (doesn't mean they didn't happen), although I could specifically provoke them with some code changes. The problem was mostly about DR (direct rendering, letting the video decoder write to OpenGL buffer memory). Allocating/freeing a DR image needs to be done on the OpenGL thread, even though _lots_ of threads are involved with handling images. Freeing a DR image is a special case that can happen any time. dr_helper.c does most of the evil magic of achieving this. Unfortunately, there was a (sort of) circular lock dependency: freeing an image while certain internal locks are held would trigger the user's context update callback, which in turn would call mpv_render_context_update(), which processed all pending free requests, and then acquire an internal lock - which the caller might not release until a further DR image could be freed. "Solve" this by making freeing DR images asynchronous. This is slightly risky, but actually not much. The DR images will be free'd eventually. The biggest disadvantage is probably that debugging might get trickier. Any solution to this problem will probably add images to free to some sort of queue, and then process it later. I considered making this more explicit (so there'd be a point where the caller forcibly waits for all queued items to be free'd), but discarded these ideas as this probably would only increase complexity. Another consequence is that freeing DR images on the GL thread is not synchronous anymore. Instead, it mpv_render_context_update() will do it with a delay. This seems roundabout, but doesn't actually change anything, and avoids additional code. This also fixes that the render API required the render API user to remain on the same thread, even though this wasn't documented. As such, it was a bug. OpenGL essentially forces you to do all GL usage on a single thread, but in theory the API user could for example move the GL context to another thread. The API bump is because I think you can't make enough noise about this. Since we don't backport fixes to old versions, I'm specifically stating that old versions are broken, and I'm supplying workarounds. Internally, dr_helper_create() does not use pthread_self() anymore, thus the vo.c change. I think it's better to make binding to the current thread as explicit as possible. Of course it's not sure that this fixes all deadlocks (probably not).
* cocoa-cb: add support for 10bit opengl renderingder richter2019-09-261-19/+38
| | | | | | | this will request a 16bit half-float framebuffer instead if a 8bit integer framebuffer. Fixes #3613
* drm_common: add missing zero-initialization of struct vt_mode variableAnton Kindestam2019-09-241-1/+1
| | | | | Some fields were being left uninitialized. This could be a problem particularly on non-Linux OS:s with vt_mode (see PR #6976).
* cocoa-cb: fix title bar button state on start upder richter2019-09-231-0/+2
| | | | | on start up it was possible to click the hidden buttons. hide the buttons ons tart up to make the state consistent with the visible state.
* context_drm_egl: Don't get stuck forever if drmHandleEvent failsAnton Kindestam2019-09-221-1/+3
|
* vo_drm: 30bpp supportAnton Kindestam2019-09-221-8/+53
|
* vo_gpu: d3d11: add support for presentation feedbackJames Ross-Gowan2019-09-221-0/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds vsync reporting to the D3D11 backend using the presentation feedback provided by DXGI, which is pretty similar to what's provided by GLX_OML_sync_control in the GLX backend. In DirectX, PresentCount is the SBC, PresentRefreshCount and SyncRefreshCount are kind of like the MSC and SyncQPCTime is the UST. Unlike GLX, the DXGI API makes it possible for PresentCount and SyncQPCTime to refer to different physical vsyncs, in which case PresentRefreshCount and SyncRefreshCount will be different. The code supports this possibility, even though it's not clear whether it can happen when using flip-model presentation. The docs say for flip-model apps, PresentRefreshCount is equal to SyncRefreshCount "when the app presents on every vsync," but on my hardware, they're always equal, even when mpv misses a vsync. They can definitely be different in exclusive fullscreen bitblt mode, though, which mpv doesn't support now, but might support in future. Another difference to GLX is that, at least on my hardware, PresentRefreshCount and SyncRefreshCount always refer to the last physical vsync on which mpv presented a frame, but glxGetSyncValues can apparently return a MSC and UST from the most recent physical vsync, even if mpv didn't present a new frame on it. This might result in different behaviour between the two backends after dropped frames or brief pauses. Also note, the docs for the DXGI presentation feedback APIs are pretty awful, even by Microsoft standards. In particular the docs for DXGI_FRAME_STATISTICS are misleading (PresentCount really is the number of times Present() has been called for that frame, not "the running total count of times that an image was presented to the monitor since the computer booted.") For good documentation, try these: https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/dxgi-flip-model https://docs.microsoft.com/en-us/windows/win32/direct3d9/d3dpresentstats https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/d3dkmthk/ns-d3dkmthk-_d3dkmt_present_stats (Yeah, the docs for the D3D9Ex and even the kernel-mode version of this structure are better than the DXGI ones. It seems possible that they're all rewordings of the same internal Microsoft docs, but whoever wrote the DXGI one didn't really understand it.)
* wayland: create current_output in wayland_reconfigdudemanguy2019-09-221-5/+6
| | | | | | | | Certain mpv config options require wl->current_output to be created before the video can actually start rendering. Just always create it here if the current_output doesn't exist (the one exception being the --fs option with no --fs-screen flag). Incidentally, this also fixes --fs-screen not working on wayland.
* vf_fingerprint: remove extraneous single quote from descriptionJan Ekström2019-09-211-1/+1
| | | | | | This happened to break ZSH completion and seemed to be extraneous. Reported by LaserEyess on IRC.
* wayland: avoid handling a 0-value axis eventDudemanguy9112019-09-211-0/+2
| | | | This shouldn't be possible, but an extra check never hurts.
* wayland: read xcursor size from XCURSOR_SIZE envemersion2019-09-211-1/+13
| | | | | This allows compositors to set the cursor size from user configuration.
* x11: fix ICC profiling for multiple monitorsslatchurie2019-09-212-2/+22
| | | | | | | | | To find the correct ICC profile X atom, the screen number was calculated directly from the xrandr order of the screens. But if a primary screen is set, it should be the first Xinerama screen, even if it is not the first xrandr screen. Calculate the the proper atom id for each screen.
* wayland: don't show cursor when fullscreeningdudemanguy2019-09-212-0/+7
|
* wayland: reconfigure cursor on pointer enter eventThomas Weißschuh2019-09-212-1/+4
| | | | | | | | | | | | | | | | | | | | | On wayland the cursor has to be configured each time the pointer enters. Currently if the window (re)gains the focus, the pointer is not hidden, even when configured. After the mouse has been moved the pointer hides correctly. https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_pointer: wl_pointer::enter - enter event ... When a seat's focus enters a surface, the pointer image is undefined and a client should respond to this event by setting an appropriate pointer image with the set_cursor request. Fixes #6185. Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
* wayland: add mouse buttons and fix axis scalingdudemanguy2019-09-211-4/+24
| | | | | | | | | | Previously, the only mouse buttons supported in wayland were left, right, and middle click. This adds the thumb back/forward buttons as valid bindings. Also it removes the old, default behavior of always sending a right click if an unrecognized mouse button is clicked. In a related but different fix, the magnitude of an axis event in wayland is not important to mpv since it internally handles all scaling. The only thing we care about is getting the sign when the event occurs.
* vo_sdl: Only create the SDL window onceCameron Cawley2019-09-211-54/+23
|
* context_drm_egl: Use eglGetPlatformDisplayEXT if availablememeka2019-09-201-1/+20
| | | | | | | | Check if eglGetPlatformDisplayEXT is available and try to use it to obtain the display connection. Fall back to eglGetDisplay if eglGetPlatformDisplayEXT is not available or failing. From PR #5992
* client API, vo_libmpv: document random deadlock problemswm42019-09-201-0/+16
| | | | | | | I guess trying to make DR work on libmpv was a mistake. I never observed such a deadlock, but it's looks like it's theoretically possible.
* vo_libmpv: fix some more uninit issueswm42019-09-201-24/+35
| | | | | | | | | | | | | | | | | | | | | | This is mostly for the case when mpv_render_context_free() is called while video is going on. This is supposed to gracefully stop video and deinitialize everything properly. (I feel like it would put too much on the API user to require that video is stopped before calling this function. Whether video is running or not is a fairly highlevel thing, and the API user could not do it in a race-free way.) One problem was that unit() accessed ctx after ctx->in_use was set to false. The update(ctx) call was basically a racy use-after-free. It needed that call to wake up the mpv_render_context_free() loop that waited for VO uninit. Fix this by triggering the wakeup inside the lock, and then doing "barrier" locking in mpv_render_context_free(). Another problem was that the wait loop didn't really wait properly. IT seems the had_kill_update field was a botched attempt to do that. It's indeed quite hairy to do that with update(). Instead make use of the dispatch queue (infinite timeout, using mp_dispatch_interrupt()), which handles the problem of having to wait both for dispatch queue updates and VO uninit at the same time.
* vo_libmpv: always create ctx->dispatchwm42019-09-201-19/+12
| | | | | | | | Preparation for the next commit. Until now, it was only needed if DR was involved. One reason for not always creating it was that you normally must not use it if advanced_control is not enabled. This is why e.g. VOCTRL_SCREENSHOT now checks for that variable; it still can't use ctx->dispatch if the render API user did not enable it.
* render api: fix use-after-freewnoun2019-09-201-12/+2
| | | | | | | | render api needs to wait for vo to be destroyed before frees the context. The purpose of kill_cb is to wake up render api after vo is destroyed, but uninit did that before kill_cb, so kill_cb tries using the freed memory. Remove kill_cb to fix the issue as uninit is able to do the work.
* rpi: Update for modern systemsCameron Cawley2019-09-203-6/+6
|
* vo: remove unused equalizer control remainswm42019-09-201-14/+1
| | | | | | | | | | Equalizer control was redone in 03cf150ff3516789d5812 (over 2 years ago). Ever since, the equalizer control structs and the GET voctrl have been unused. Only the SET voctrl is still used as notification mechanism (actually a bad hack to avoid some further option change handling complexity). Remove the unused parts.
* oml_sync: fix typo in commentwm42019-09-201-2/+2
| | | | I think... Also reword another part of the text.
* vf_fingerprint: use aligned_alloc instead of posix_memalignwm42019-09-191-2/+2
| | | | | | | | | | | I was assuming posix_memalign was the most portable function to use, but MinGW does not provide it for some reason. Switch to C11 aligned_alloc() which someone suggested was provided by MinGW (but actually isn't, someone probably confused it with the incompatible _aligned_malloc), and add a configure check. Even though it turned out that MinGW doesn't provide it, the function is slightly more elegant than posix_memalign(), so stay with it.
* video: add vf_fingerprint and a skip-logo scriptwm42019-09-191-0/+293
| | | | | | | | | | | | | | | | | | | | | | | | | skip-logo.lua is just what I wanted to have. Explanations are on the top of that file. As usual, all documentation threatens to remove this stuff all the time, since this stuff is just for me, and unlike a normal user I can afford the luxuary of hacking the shit directly into the player. vf_fingerprint is needed to support this script. It needs to scale down video frames as part of its operation. For that, it uses zimg. zimg is much faster than libswscale and generates more correct output. (The filter includes a runtime fallback, but it doesn't even work because libswscale fucks up and can't do YUV->Gray with range adjustment.) Note on the algorithm: seems almost too simple, but was suggested to me. It seems to be pretty effective, although long time experience with false positives is missing. At first I wanted to use dHash [1][2], which is also pretty simple and effective, but might actually be worse than the implemented mechanism. dHash has the advantage that the fingerprint is smaller. But exact matching is too unreliable, and you'd still need to determine the number of different bits for fuzzier comparison. So there wasn't really a reason to use it. [1] https://pypi.org/project/dhash/ [2] http://www.hackerfactor.com/blog/index.php?/archives/529-Kind-of-Like-That.html
* video: generally try to align image data on 64 byteswm42019-09-195-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Generally, using x86 SIMD efficiently (or crash-free) requires aligning all data on boundaries of 16, 32, or 64 (depending on instruction set used). 64 bytes is needed or AVX-512, 32 for old AVX, 16 for SSE. Both FFmpeg and zimg usually require aligned data for this reason. FFmpeg is very unclear about alignment. Yes, it requires you to align data pointers and strides. No, it doesn't tell you how much, except sometimes (libavcodec has a legacy-looking avcodec_align_dimensions2() API function, that requires a heavy-weight AVCodecContext as argument). Sometimes, FFmpeg will take a shit on YOUR and ITS OWN alignment. For example, vf_crop will randomly reduce alignment of data pointers, depending on the crop parameters. On the other hand, some libavfilter filters or libavcodec encoders may randomly crash if they get the wrong alignment. I have no idea how this thing works at all. FFmpeg usually doesn't seem to signal alignment internal anywhere, and usually leaves it to av_malloc() etc. to allocate with proper alignment. libavutil/mem.c currently has a ALIGN define, which is set to 64 if FFmpeg is built with AVX-512 support, or as low as 16 if built without any AVX support. The really funny thing is that a normal FFmpeg build will e.g. align tiny string allocations to 64 bytes, even if the machine does not support AVX at all. For zimg use (in a later commit), we also want guaranteed alignment. Modern x86 should actually not be much slower at unaligned accesses, but that doesn't help. zimg's dumb intrinsic code apparently randomly chooses between aligned or unaligned accesses (depending on compiler, I guess), and on some CPUs these can even cause crashes. So just treat the requirement to align as a fact of life. All this means that we should probably make sure our own allocations are 64 bit aligned. This still doesn't guarantee alignment in all cases, but it's slightly better than before. This also makes me wonder whether we should always override libavcodec's buffer pool, just so we have a guaranteed alignment. Currently, we only do that if --vd-lavc-dr is used (and if that actually works). On the other hand, it always uses DR on my machine, so who cares.
* vo: fix missed option updates under rare circumstanceswm42019-09-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Dear diary, today I fixed a shitty bug that was all my fault because I made a horrible mess. (E