summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* img_format.h: cosmetics: fix whitespacewm42018-03-151-1/+1
|
* 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.
* mp_image: fix UB with certain callers like vf_vdpauppwm42018-03-151-0/+4
| | | | | | | | | | | | | | | | | | | vf_vdpaupp crashed on certain files (with --hwdec=vdpau --deinterlace). This happened for example with mpeg2 files, which for some reason typically contain some AVFrame side data. It turns out the last change in 55c88fdb8f1a9269 was not quite clean, and forgot the special cases in mp_image_new_dummy_ref(). This function is supposed to copy all metadata from the argument passed, except buffer refs. But there were new buffer refs, that were not cleared properly. Also, the ff_side_data pointer must be cleared, or the new mp_image would try to free it on destruction. The bottom line is that mp_image_new_dummy_ref() is a pretty bad idea, and I suppose all callers with non-NULL arguments should be changed to create a blank mp_image, and copy frame properties as needed (this includes callers of mp_image_new_custom_ref()). Fixes #5630.
* 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.
* vd_lavc: slightly better logging about why hwdec is not usedwm42018-03-081-5/+9
| | | | | The old message was outdated and also not very precise. Make it all a bit more elaborate.
* 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.
* vd_lavc: fix inverted conditionwm42018-03-031-1/+1
|
* mp_image: replace rude function with less rude FFmpeg upstream functionwm42018-03-031-2/+4
| | | | This is new, thus a dependency bump is required.
* mp_image: make ref error handling slightly readablewm42018-03-031-10/+9
| | | | I think this is slightly more readable than this repeated "fail |= !".
* mp_image: pass through unknown AVFrame side datawm42018-03-032-1/+42
| | | | | | | | | Useful for libavfilter. Somewhat risky, because we can't ensure the consistency of the unknown side data (but this is a general problem with side data, and libavfilter filters will usually get it wrong too _if_ there are conflict cases). Fixes #5569.
* mp_image: fix subtle side data memory leakswm42018-03-031-2/+2
| | | | | | We must not create new references herem because mp_image_new_ref() is called later, and actually creates new references (including doing actual error checking). Blame C, not me.
* 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
| | | | | This can be used by client code that needs to fail when it cannot find a suitable EGLConfig.
* cocoa-cb: fix wrong fullscreen window sizeAkemi2018-02-252-11/+21
| | | | | | | | | | | | | | | | | | | even though the fullscreen animation has a shorter duration than the system wide animation (space sliding effect) there are still cases where it takes longer, eg performance issues (especially on init). furthermore the final size of the animation is usually different than the actual fullscreen size because of spect ratio differences. the actual resize to fullscreen is done automatically by cocoa itself when the actual transition to fullscreen happens (system event). so it could happen that the last animation resize happened after the actual resize to fullscreen leading to a wrongly sized frame after entering fullscreen. to prevent this we cancel the animation when entering fullscreen, we always set the proper frame size when in fullscreen and discard any other frame sizes, and to prevent some performance problems on init we push entering fullscreen to the end of the main queue to execute it when most of the init routines are done. Fixes #5525
* cocoa-cb: fix wrong drawing size on resizeAkemi2018-02-251-17/+12
| | | | | | on live resize, eg async resize, the layer's bounds size is not in sync with the actual surface size. this led to a wrongly sized frame and a perceived flicker. get and use the actual surface size instead.
* vo_gpu: fix mobius tone mapping when sig_peak <= 1.0Niklas Haas2018-02-251-0/+2
| | | | | | | Mobius isn't well-defined for sig_peak <= 1.0. We can solve this by just soft-clamping sig_peak to 1.0. Although, in this case, we can just skip tone mapping altogether since the limit of mobius as sig_peak -> 1.0 is just a linear function.
* vo_gpu: don't tone-map for pure gamut reductionsNiklas Haas2018-02-251-3/+0
| | | | | | | | | Based on testing with real-world non-HDR BT.2020 clips, clipping the color space looks better than attempting to gamut map using a tone mapping shader that's (by now) optimized for HDR content. If anything, we'd have to develop a separate gamut mapping shader that works in LCh space.
* drm_vo: pixel aspect from --monitoraspectMarco Migliori2018-02-211-1/+7
| | | | | | | | | | | | | | | | | When pixels are non-square, the appropriate value of vo->monitor_par is necessary to determine the destination rectangle, which in turn tells how to scale the video along the x and y axis. Before this commit, the drm driver only used --monitorpixelaspect. For example, to play a video with the right aspect on a 4:3 screen and 640:400 pixels, --monitorpixelaspect=5:6 had to be given. With this commit, vo->monitor_par is determined from the size of the screen in pixels and the --monitoraspect parameter. The latter is usually easier to determine than --monitorpixelaspect, since it is simply the proportion between the width and the height of the screen, in most cases 16:9 or 4:3. If --monitoraspect is not given, --monitorpixelaspect is used if given, otherwise pixel aspect is assumed 1:1.
* vf_vapoursynth: fix freezewm42018-02-201-5/+7
| | | | | | | Commit 59f9547fb56b missed this case, in which we can't make new progress and have to exit. Fixes #5548.
* vo_gpu: introduce --target-peakNiklas Haas2018-02-203-7/+16
| | | | | | | | | | | | | This solves a number of problems simultaneously: 1. When outputting HLG, this allows tuning the OOTF based on the display characteristics. 2. When outputting PQ or other HDR curves, this allows soft-limiting the output brightness using the tone mapping algorithm. 3. When outputting SDR, this allows HDR-in-SDR style output, by controlling the output brightness directly. Closes #5521
* vo_gpu: correctly parametrize the HLG OOTF by the display peakNiklas Haas2018-02-201-20/+31
| | | | | | | | | | | | | | The HLG OOTF is defined as a one-parameter family of OOTFs depending on the display's peak luminance. With the preceding change to OOTF scale and handling, we no longer have any issues with outputting values in whatever signal range we need. So as a result, it's easy for us to support a tunable OOTF which may (drastically) alter the display brightness. In fact, this is also the only correct way to do it, because the HLG appearance depends strongly on the OOTF configuration. For the OOTF, we consult the mastering display's tagging (via src.sig_peak). For the inverse OOTF, we consult the output display's target peak.
* vo_gpu: simplify and correct color scale handlingNiklas Haas2018-02-203-33/+40
| | | | | | | | | | | | | | | | | | | | | | | | | The primary need for this change is the fact that the OOTF was incorrectly scaled, due to the fact that the application of the OOTF can itself change the required normalization peak. (Plus, an oversight in pass_inverse_ootf meant we forgot to normalize at the end of it) The linearize/delinearize functions still normalize the scale since it's used in a number of places throughout gpu/video.c, but the color management function now converts to absolute scale right away, instead of in an awkward way inside the tone mapping branch. The OOTF functions now work in absolute scale only. In addition, minor changes have been made to the way normalization is handled for tone mapping - we now divide out the dst_peak *after* peak detection, in order to make the scale of the peak detection buffer consistent even if the dst_peak were to (hypothetically) change mid-stream. In theory, we could also do this for desaturation, but doing the desaturation before tone mapping has the advantage of preserving much more brightness than the other way around - and even mid-stream changes are not that drastic here. Finally, some preparation work has been done for allowing the user to customize the `dst.sig_peak` in the future.
* vo_mediacodec_embed: fix forgotten VO_CAP_NOREDRAW→VO_CAP_NORETAINJan Ekström2018-02-201-1/+1
| | | | Fixes compilation of this module.
* cocoa-cb: fix hwdec when drawing off-screenAkemi2018-02-171-0/+1
| | | | | | | | | drawing off-screen failed because we didn't have a valid context. the problem is we force off-screen drawing because the CA