summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* egl_helpers: log certain EGL attributeswm42018-04-291-0/+38
| | | | Might be helpful with broken EGL implementations.
* encode: rewrite half of itwm42018-04-291-198/+114
| | | | | | | | | | | | | The main change is that we wait with opening the muxer ("writing headers") until we have data from all streams. This fixes race conditions at init due to broken assumptions in the old code. This also changes a lot of other stuff. I found and fixed a few API violations (often things for which better mechanisms were invented, and the old ones are not valid anymore). I try to get away from the public mutex and shared fields in encode_lavc_context. For now it's still needed for some timestamp-related fields, but most are gone. It also removes some bad code duplication between audio and video paths.
* vo: add vo_reconfig2()wm42018-04-292-3/+26
| | | | | | 1. I want to get away from mp_image_params (maybe). 2. For encoding mode, it's convenient to get the nominal_fps, which is a mp_image field, and not in mp_image_params.
* video: remove internal stereo_out flagwm42018-04-291-2/+2
| | | | | | Also rename stereo3d to stereo_in. The only real change is that the vo_gpu OSD code now uses the actual stereo 3D mode, instead of the --video-steroe-mode value. (Why does this vo_gpu code even exist?)
* client API: add some render API extensions for timingwm42018-04-291-24/+68
| | | | | | | | | | | | Attempts to enable the following things: - let a render API user do "proper" audio-sync video timing itself - make it possible to not re-render repeated frames if the API user has better mechanisms available (e.g. waiting for a DisplayLink cycle instead) - allow the user to delay or skip redraws if it makes sense Basically this information will be needed by API users who want to be "clever" about optimizing timing and rendering.
* vo_libmpv: support GPU rendered screenshotswm42018-04-293-0/+45
| | | | | Like DR, this needed a lot of preparation, and here's the boring glue code that finally implements it.
* vo_libmpv: adjust redraw handling to new API semanticswm42018-04-291-12/+4
| | | | | | | | | | | | | | | | | In MPV_RENDER_PARAM_ADVANCED_CONTROL mode, a simple update callback does not necessarily make the API user redraw. So handle it differently. For one, setting vo->want_redraw already uses the "normal" redraw path, which will call draw_frame() and set next_frame. Then there are redraws trigered by mpv_render_context_set_parameter(), which are on the render thread, and would require a separate mechanism. I decided this is not really a good idea, since it's not even clear that setting an arbitrary parameter should redraw. Also this could trigger an unbounded number of redraws. The user can trigger redraws manually if really needed, depending on the parameter that's being set. If we really wanted vo_libmpv to do this, we could add a new flag like need_redraw, which would be 4 lines of code or so.
* vo_libmpv: remove annoying indirectionswm42018-04-291-71/+80
| | | | I think this is a bit more readable this way.
* vo_libmpv: move some update() callbacks out of context lockwm42018-04-291-3/+3
| | | | | | | | update() used to require the lock, but now it doesn't matter. It's slightly better to do it outside of the lock now, in case the update callback reschedules before returning, and the user render thread tries to acquire the still held lock (which would require 2 more context switches).
* vo_libmpv: move up update() functionwm42018-04-291-14/+12
| | | | Avoids a forward declaration.
* vo_libmpv: add support for DRwm42018-04-293-0/+38
| | | | | With all the preparation work done, this only has to do the annoying dance of passing it through all the damn layers.
* client API: preparations for allowing render API to use DR etc.wm42018-04-292-22/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | DR (letting the decoder allocate texture memory) requires running the allocation on the render thread. This is rather hard with the render API, because the user controls this thread and when it's entered. It was not possible until now. This commit adds a bunch of infrastructure to make this possible. We add a new optional mode (MPV_RENDER_PARAM_ADVANCED_CONTROL) which basically lets the user's render thread and libmpv agree how this should be done. Misuse would lead to deadlocks. To make this less likely, strictly document thread safety/locking issues. In particular, document which libmpv functions can be called without issues. (The rest has to be assumed unsafe.) The worst issue is destruction of the render context while video is still active. To avoid certain unintended recursive locks (i.e. deadlocks, unless we'd make the locks recursive), make the update callback lock separate. Make "killing" the video chain asynchronous, so we can do extra work while video is being destroyed. Because losing wakeups is a big deal, setting the update callback now triggers a wakeup. (It would have been better if the wakeup callback were a parameter to mpv_render_context_create(), but too late.) This commit does not add DR yet; the following commit does this.
* vo: move DR helper code to a separate source filewm42018-04-294-91/+183
| | | | | So it can be reused by vo_libmpv.c, which needs to use it in a slightly different way.
* vo_gpu: move some extra code for screenshot to video.cwm42018-04-202-13/+15
| | | | | This also happens to fix some UB on the error path (target being declared after the first "goto done;").
* encode: simplify colorspace settingwm42018-04-201-3/+2
| | | | | This was also refactored at some point, and is now unnecessarily roundabout.
* encode: cosmeticswm42018-04-201-35/+30
| | | | Mostly whitespace changes; some semantic preserving transformations.
* vo_lavc: remove pointless uint32_t type for int valueswm42018-04-201-7/+2
| | | | | params->w/h are int, and the further use of these variables are int. The uint32_t is probably some refactoring artifact.
* w32_common: avoid recursive dispatch queue callswm42018-04-181-1/+6
| | | | | | | | I suppose this doesn't matter in practice, i.e. even if calls relayed over the dispatch queue will cause WndProc to be invoked, WndProc will never run for a longer time. Preparation for removing recursion support from the dispatch queue code.
* hwdec_ios: fix crash after mapper_init failureAman Gupta2018-04-171-2/+4
|
* client API: clarify that Display pointers etc. need to stay validwm42018-04-161-6/+21
| | | | | | | | | | | | Normally, MPV_RENDER_PARAM* arguments are copied, unless documented otherwise. Of course we can't copy X11 Display or Wayland wl_display types, but for arguments that are "summarized" in a struct (like MPV_RENDER_PARAM_OPENGL_FBO), a copy is expected. Also add some unused infrastructure to make this explicit, and to make it easier to add parameter types that require a copy. Untested.
* vo_gpu: hwdec: Use ffnvcodec to load CUDA symbolsPhilip Langdale2018-04-153-244/+45
| | | | | | The CUDA dynamic loader was broken out of ffmpeg into its own repo and package. This gives us an opportunity to re-use it in mpv and remove our custom loader logic.
* opengl: include details in EGL context errorsAman Gupta2018-04-121-3/+3
|
* client API: add a new way to pass X11 Display etc. to render APIwm42018-03-2618-86/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hardware decoding things often need access to additional handles from the windowing system, such as the X11 or Wayland display when using vaapi. The opengl-cb had nothing dedicated for this, and used the weird GL_MP_MPGetNativeDisplay GL extension (which was mpv specific and not officially registered with OpenGL). This was awkward, and a pain due to having to emulate GL context behavior (like needing a TLS variable to store context for the pseudo GL extension function). In addition (and not inherently due to this), we could pass only one resource from mpv builtin context backends to hwdecs. It was also all GL specific. Replace this with a newer mechanism. It works for all RA backends, not just GL. the API user can explicitly pass the objects at init time via mpv_render_context_create(). Multiple resources are naturally possible. The API uses MPV_RENDER_PARAM_* defines, but internally we use strings. This is done for 2 reasons: 1. trying to leave libmpv and internal mechanisms decoupled, 2. not having to add public API for some of the internal resource types (especially D3D/GL interop stuff). To remain sane, drop support for obscure half-working opengl-cb things, like the DRM interop (was missing necessary things), the RPI window thing (nobody used it), and obscure D3D interop things (not needed with ANGLE, others were undocumented). In order not to break ABI and the C API, we don't remove the associated structs from opengl_cb.h. The parts which are still needed (in particular DRM interop) needs to be ported to the render API.
* cocoa-cb: render on a dedicated dispatch queueAkemi2018-03-253-28/+36
| | | | | | | | | | | we rendered on the displaylink thread which wasn't the best idea. if rendering took too long or was blocking it also blocked the displaylink callback. when that happened new vsyncs were reported delayed or not at all. consequently the mpv_render_context_report_swap function wasn't called consistently and that could cause bad video playback. so the rendering is moved to a dedicated dispatch queue. furthermore the update callback starts a layer update directly instead of the displaylink callback, making the rendering a bit more consistent.
* drm/atomic: ensure request is available until uninitLongChair2018-03-231-3/+14
| | | | | | | | | | Right now the atomic request is alive during the renderloop. We want it to be alive until the drm egl context is destroyed because some properties might still be set upon interop close This patch make the request to be kept created even outside the renderloop. The context uninit will commit the last request.
* cocoa-cb: fix shutdown when fullscreen animation is runningAkemi2018-03-182-7/+17
| | | | | | | | commit 2edf00f changed the MPV_EVENT_SHUTDOWN behaviour slightly, such that it will only be sent once. cocoa-cb relied on it being sent continuously till all mpv_handles are destroyed. now it manually shuts down and destroys the mpv_handle after the animation instead of relying on this removed behaviour.
* vo_gpu: fix anamorphic video screenshots (second try)wm42018-03-161-3/+4
| | | | | | | | | | | | | | This passed the display size as source size to the renderer, which is of course nonsense. I don't know what I was doing in 569383bc54. Yet another fix for those damn anamorphic videos. As a somewhat redundant/cosmetic change, use image_params instead of real_image_params in the code above. They should have the same, dimensions (but possibly different formats when doing hw decdoing), and mixing them is confusing. p->image_params wins because it's shorter. Actually fixes #5619.
* vo: pass through framedrop flag differentlywm42018-03-152-5/+3
| | | | | | | | There is some sort-of awkwardness here, because option access needs to happen in a synchronized manner, and the framedrop flag is not in the VO option struct. Remove the mp_read_option_raw() call and the awkward change notification via VO_EVENT_WIN_STATE from command.c, and pass it through as new vo_frame flag.
* vo: move display-fps internal option value to VO optswm42018-03-151-14/+18
| | | | | | Removes the awkward notification through VO_EVENT_WIN_STATE. Unfortunately, some awkwardness remains in mp_property_display_fps(), because the property has conflicting semantics with the option.
* video: add an option to tune waiting for video timingwm42018-03-151-2/+17
| | | | Probably mostly useful for the libmpv render API.
* vo: cosmetics: fix a case of bad whitespacewm42018-03-151-2/+1
|
* vo_gpu: fix anamorphic screenshotswm42018-03-151-2/+2
| | | | | | | | | | | We took the storage size instead of the display size for "unscaled" screenshots. Even if it's called "unscaled", it's still supposed to scale to compensate for aspect ratio. (How many commits fixing anamorphic screenshots in various situations are there?) Fixes #5619.
* cocoa-cb: fix crash on startup with not initialised title barAkemi2018-03-141-1/+2
| | | | | | | the first mouse events, that try to hide the title bar, could happen before the title bar was actually initialised. that caused our hiding code to access a nil value. check for an available title bar before trying to hide it.
* cocoa-cb: fix crash with forced iGPU on some multi GPU systemsAkemi2018-03-141-3/+5
| | | | | | | | | | | | | there were actually a few small problems. the fatalError() function wasn't supposed to be called there and caused an "Illegal instruction". this was replaced by a print and exit() call. the second problem was that cocoa returns a kCGLBadPixelFormat instead of a kCGLBadAttribute error, which broke our check, immediately exited our loop and no working pixel format was ever created. the third problem was that macOS 10.12 didn't return any errors but also didn't return a pixel format, that also broke our check. now the code checks for both cases. Fixes #5631
* cocoa-cb: remove unneeded icc-profile-auto checkAkemi2018-03-111-3/+1
| | | | | | with the new libmpv API it's not necessary to check for this property anymore since libmpv will only use the provided profile when it is needed.
* cocoa-cb: don't deactivate mouse events completely with input-cursor=noAkemi2018-03-111-7/+2
| | | | | | | | | | mouse events and the tracking area are needed for (un)hiding the new title bar, which was broken when input-cursor=no was set. no tracking area was ever created and set which completely deactivated any mouse events. the specific mouse event functions were already deactivated proactively and have the needed check. no events are being propagated to the mpv core when input-cursor=no is set, even with an active tracking area.
* vo_vdpau: fix resizing and rotation problemswm42018-03-081-3/+7
| | | | | | | | | | | | | | | The s_size() function, whatever it was supposed to do, caused the surface size to increase indefinitely. Fix by making it always use the maximum size that was last used, which is less optimal (many surface recreations when making the window slowly larger), but at least it works. The rotation code didn't mark the old surface as invalid when it was freed, so it could destroy random other surfaces (let's call it dangling ID). Also, the required rotation surface size depends on the rotation mode, so recreate the surfaces on rotation as well.
* hwdec_drmprime_drm: Fix a DRM buffer memory leakageLongChair2018-03-051-2/+3
| | | | | | | | We use triple buffering for this interop and we were only unreffing the data structures, which doesn't destroy the drm buffers. This patch allows to make sure that we release the drm buffers on playback end.
* cocoa-cb: fix a segfault without videoAkemi2018-03-041-10/+7
| | | | | | | we activated the rendering loop a bit too early and it was possible that the first draw function was called before it was actually ready. this was a remnant from the old init routine and should have been changed. start the queue on reconfigure instead of preinit.
* cocoa-cb: fix wrong aspect ratio on live resize after reconfig resizeAkemi2018-03-041-1/+1
| | | | | | | on a file change and when the aspect ratio of the window changed, the first live resize state had a wrong aspect ratio because the new aspect ratio was only set after the first resize. just set the new content frame before the resize.
* cocoa-cb: change handling of window aspect ratio changesAkemi2018-03-043-34/+16
| | | | | | | | | | | | i tried being smart and handle aspect ratio differences manually via atomic drawing and resizing to aspect fitted frames. there were a few issues with that. like unexpected visibility of certain System GUI elements on entering fullscreen or visually dropped frames due to the atomic drawing. now we rely on system mechanics to keep the proper aspect ratio of our layer, the recommended way. as a side effect it also fixes a segfault. Fixes #5581
* context_drm_egl: Allow fallback EGLConfig formatsAnton Kindestam2018-03-041-17/+49
| | | | | | | | | | | | It turns out that Mali drivers are likely broken, and do not return GBM_FORMAT_ARGB8888 (they return GBM_FORMAT_XRGB8888) when getting EGL_NATIVE_VISUAL_ID for any EGLConfig, even though the resulting EGLConfig appears to be capable of alpha. It could also be potentially useful to allow an ARGB EGLConfig used with an XRGB framebuffer on some platforms, so we do that. (cf. weston) Unrelated indentation fix in gbm_format_to_string.
* cocoa-cb: use new libmpv API instead of opengl-cbAkemi2018-03-043-14/+14
| | | | | a new replacement API was introduced with b037121 and the old one was deprecated. porting cocoa-cb to the new API.
* cocoa-cb: remove debug remnant (stray print)Akemi2018-03-041-1/+0
|
* vo_gpu: don't segfault in libmpv_gl's destroy()Niklas Haas2018-03-041-1/+2
| | | | | This segfaults when the GPU context has not been fully initialized, such as would be the case when initialization errors.
* vo_gpu: error out if there were rendering errors when taking screenshotwm42018-03-031-1/+5
|
* vo_gpu: fix taking screenshots of rotated videoswm42018-03-031-0/+3
| | | | Good old 90° rotation logic messing everything up.
* cocoa-cb: fix building with SDK 10.12 and earlierAkemi2018-03-011-1/+1
| | | | | | | | | the NSWindowButton enum was moved to be a member of NSWindow and renamed to ButtonType in SDK 10.13. apparently that wasn't documented anywhere. not even in the SDK changes Document and the official Documentations makes it look like it was always like this. the old NSWindowButton enum though is still around on SDK 10.13 or at least got a typealias. so we will just use that.
* client API: deprecate opengl-cb API and introduce a replacement APIwm42018-02-287-245/+595
| | | | | | | | | | | | | | | | | | | | | | | | | The purpose of the new API is to make it useable with other APIs than OpenGL, especially D3D11 and vulkan. In theory it's now possible to support other vo_gpu backends, as well as backends that don't use the vo_gpu code at all. This also aims to get rid of the dumb mpv_get_sub_api() function. The life cycle of the new mpv_render_context is a bit different from mpv_opengl_cb_context, and you explicitly create/destroy the new context, instead of calling init/uninit on an object returned by mpv_get_sub_api(). In other to make the render API generic, it's annoyingly EGL style, and requires you to pass in API-specific objects to generic functions. This is to avoid explicit objects like the internal ra API has, because that sounds more complicated and annoying for an API that's supposed to never change. The opengl_cb API will continue to exist for a bit longer, but internally there are already a few tradeoffs, like reduced thread-safety. Mostly untested. Seems to work fine with mpc-qt.
* vo_gpu: remove a dead declarationwm42018-02-281-1/+0
|
* cocoa-cb: make fullscreen resize animation duration configurableAkemi2018-02-281-2/+11
|
* cocoa-cb: fix stretched gl surface on window aspect ratio changeAkemi2018-02-282-2/+48
| | | | | | | | when resizing async it's possible that the layer, and the underlying gl surface, is stretched on an aspect ratio change. to prevent that we do an atomic resize (resize and draw at the same time). usually max one unique frame should be dropped but it's possible, depending on the performance, that more are dropped.
* cocoa-cb: change border and borderless window stylingAkemi2018-02-283-17/+120
| | | | | | | | | | | the title bar is now within the window bounds instead of outside. same as QuickTime Player. it supports several standard styles, two dark and two light ones. additionally we have properly rounded corners now and the borderless window also has the proper window shadow. Also make the earliest supported macOS version 10.10. Fixes #4789, #3944
* drm_common: Improve VT switching signal handling somewhatAnton Kindestam2018-02-261-1/+15
| | | | | | | | By blocking the VT switcher signal in the VO thread we get less races and other oddities. This gets rid of tearing (at least for me) when VT switching with --gpu-context=drm.
* vo_drm: Fix pageflip errors on VT switchAnton Kindestam2018-02-261-2/+5
| | | | | | | | crtc_setup gets called on VT reacquire as well as during normal setup. When called during VT reacquire p->front_buf might not be 0, so the maths was wrong, and could cause array OOB errors. Use mathematically correct (for negative numbers) modulo to always pick the farthest away buffer (should work even for larger values of BUF_COUNT).
* context_drm_egl: Repair VT switchingAnton Kindestam2018-02-261-2/+27
| | | | | | | | | | | | | The VT switcher was being set up, but it was being neither polled nor interrupted. Insert wait_events and wakeup functions based on those from vo_drm, and add return early in drm_egl_swap_buffers if p->active isn't set. This should get basic VT switching working, however there will likely still be some random glitches. Switching between mpv and X11/weston is unlikely to work satisfactorily until we can solve the problems with drmSetMaster and drmDropMaster.
* context_drm_egl: Introduce 30bpp supportAnton Kindestam2018-02-263-29/+89
| | | | | | | | | | | | | This introduces the option --drm-format (currently used only by context_drm_egl, vo_drm implementation is pending) which allows you to pick between a xrgb8888 or a xrgb2101010 visual for --gpu-context=drm. Requires a recent mesa (18.0.0_rc4 or later) to work. This also fixes a bug when using --gpu-context=drm on a 30bpp-enabled mesa (allow_rgb10_configs set to true). Previously it would've set up an XRGB8888 format at the DRM/GBM level, while a 30bpp EGLConfig would be picked, resulting in a garbled image.
* egl_helpers: mpegl_cb can now signal an error conditionAnton Kindestam2018-02-262-1/+8
| | | |</