summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* cocoa-cb: remove get_property_* usages and split up mpv helperder richter2019-10-065-133/+123
| | | | | | | | | | all the get_property_* usages were removed because in some circumstances they can lead to deadlocks. they were replaced by accessing the vo and mp_vo_opts structs directly, like on other vos. additionally the mpv helper was split into a mpv and libmpv helper, to differentiate between private and public APIs and for future changes like a macOS vulkan context for vo=gpu.
* wayland opengl: actually call uninit if init failsdudemanguy2019-10-031-1/+3
| | | | | | | | This is the proper fix to the memory leak @wm4 pointed out. It turns out that when you autoprobe opengl and vo_wayland_init returns false, vo_wayland_uninit is never actually executed. So you have a leftover pointer. The vulkan context does this correctly which was why my old, dumb "fix" broke it.
* Revert "wayland: free wayland_state on a false return"dudemanguy2019-10-031-11/+3
| | | | | | | | Dumb idea. The correct thing to do is to fix the preinit and context creation so that the uninit is correctly executed when probing fails (and then everything gets freed). This reverts commit defc8f359c5e4bb666e8ad1d4a097a8ac66cc1e2.
* wayland: free wayland_state on a false returnDudemanguy9112019-10-021-3/+11
| | | | | | wm4 mentioned that the wayland autoprobe leaked. A simple oversight in the wayland_common code forgot to free the vo_wayland_state if vo_wayland_init returned false.
* vf_fingerprint: fix an obvious memory leakwm42019-10-031-4/+12
| | | | | | Leaks the entire zimg state on filter deinit. Not sure what I was thinking; with some luck, I just didn't give a shit about this case, but most likely I was thinking the same thing as always: nothing.
* vf_vapoursynth: fix crashing memory management mistakewm42019-10-031-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As pointed out by @olifre in #7016, this line of code was wrong. p->opts at this point is a struct allocated and managed by m_config. opts->file is a string, and m_config explicitly frees it on destruction. The line of code in question replaced the opts->file value, and made both the old and new value children of the talloc allocation, so they were _also_ freed on destruction. This crashed due to a double-free. First, talloc auto-freeing freed the string, then m_config explicitly called talloc_free() on the stale pointer again. As @v-fox pointed out, commit 36dd2348a1e1 seems to have triggered the crash. I suspect this code merely worked out of coincidence, since it allowed m_config to free the value first. This removed it from the auto-free list, and thus did not result in a double-free. The change in order of calling alloc destructors changed the order of these calls. There is no strong reason why new behavior (as introduced by commit 36dd2348a1e1) would be wrong (it feels like cleaner behavior). On the other hand, what the vf_vapoursynth code did is clearly unclean and going by the m_config API, you're not at all supposed to do this. m_config manages all memroy referenced by option structs, the end. @olifre's suggested fix also would have been correct (not just hiding the issue), I prefer my fix, as it doesn't mess with the option struct in tricky ways. This wouldn't have happened if mpv were written in Haskell.
* vf_vapoursynth: do not call vsscript_finalize() if init failedwm42019-10-031-1/+5
| | | | | If vsscript_finalize() is not matched by a successful vsscript_init(), an assert in the vsscript library triggers. Makes sense, I guess.
* vf_vapoursynth: remove some Lua backend remainswm42019-10-031-6/+0
| | | | Pretty funny.
* wayland: always create wl_output before renderingDudemanguy9112019-10-021-7/+6
| | | | | | | | | | | I previously skipped creating the wl_output if the --fullscreen flag with no --fsscreen_id was inputted, so the fullscreen video lands on the correct output (where mpv was launched). This has breakage if someone combines the --autofit flag (or other similar options with it). Instead, just actually read xdg_shell spec and realize that you can pass NULL to xdg_toplevel_set_fullscreen and let the compositor choose the output if the user doesn't specify it. If this has issues, get a better compositor.
* mp_image_pool: expose a function for reporting hw download formatwm42019-10-022-11/+22
| | | | | | | | Basically predicts what mp_image_hw_download() will do. It's pretty simple if it gets the full mp_image. (Taking just a imgfmt would make this pretty hard/impossible or inaccurate.) Used in one of the following commits.
* video: remove vf_vavpp from automatic deinterlace propertywm42019-10-021-9/+0
| | | | | | | | | | | | | | This reverts commit 6385a5fd1b8a67c051b82d48c993a6591e8f93c6, and in addition removes the code that automatically inserts the vavpp filter. The reason is the same as the commit that is being reverted: this filter seems to trigger driver bugs. It can cause GPU freezes or just doesn't work. This variant of disabling the filter is better. There was no way to add the "force" parameter to the automatically inserted filter, so the old approach just made manual filter insertion (with the --vf option or "vf" command) more cumbersome.
* 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