summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: implement videotoolbox hwdec on iOSAman Gupta2017-02-172-1/+215
| | | | | | Implements --hwdec=videotoolbox on iOS. Similar to hwdec_osx.c, but using CVPixelBuffer APIs available on iOS instead of the equivalent IOSurface APIs in macOS.
* vo_opengl: don't crash on unsupported formatswm42017-02-171-1/+2
| | | | Regression from recent refactor.
* vo_opengl: hwdec_vaegl: use new format setup functionwm42017-02-173-14/+28
| | | | Plus add a helper.
* vo_opengl: hwdec_osx: use new format setup functionwm42017-02-172-87/+21
| | | | | | | | | | | | | | | | We can drop the custom table. For some reason, the interop does not accept GL_RGB_RAW_422_APPLE as internal format for GL_RGB_422_APPLE, so switch the format table to use GL_RGB (this way both interop and real textures work the same). Another victim of the apparent requirement of exactly matching texture formats is kCVPixelFormatType_32BGRA. vo_opengl wants to handle this as normal RGBA texture, with a swizzle applied in the shader. CGLTexImageIOSurface2D() rejects this, because it wants the exact internal format. Just drop the format, because it's useless anyway. (Maybe this is a bit too fragile...)
* vo_opengl: hwdec_cuda: use new format setup functionwm42017-02-171-34/+8
| | | | Gives us automatically support for all formats vo_opengl supports.
* vo_opengl: move texture mapping of pixel formats to helper functionwm42017-02-173-128/+163
| | | | | | | All supported pixel formats have a specific "mapping" of CPU data to textures. This function determines the number and the formats of these textures. Moving it to a helper will be useful for some hardware decode interop backends, since they all need similar things.
* vo_opengl: handle GL_LUMINANCE_ALPHA and integer textures differentlywm42017-02-175-31/+38
| | | | | | | | | | | | | | | GL_LUMINANCE_ALPHA is the only reason why per-plane swizzles exist. Remove per-plane swizzles (again), and regrettably handle them as special cases (again). Carry along the logical texture format (called gl_format in some parts of the code, including the new one). We also don't need a use_integer flag, since the new gl_format member implies whether it's an integer texture. (Yes, the there are separate logical GL formats for integer textures. This aspect of the OpenGL API is hysteric at best.) This should change nothing about actual rendering logic and GL API usage.
* videotoolbox: fix RGB formatwm42017-02-171-1/+1
| | | | | Wrong colors. This didn't matter for the OpenGL interop code, because the CV format was mapped to the correct texture format.
* videotoolbox: remove weird format-negotiation between VO and decoderwm42017-02-171-16/+1
| | | | | | | | | | | | | | | | Originally, there was probably some sort of intention to restrict it to formats supported by the interop, or something. But in the end it was overcomplicated nonsense. In the future, we could use mp_hwdec_ctx.supported_formats or other mechanisms to handle this in a better way. mp_hwdec_ctx.ctx is not set to a dummy pointer - hwdec_devices_load() is only used to detect whether to vo_opengl interop is present, and the common hwdec code expects that the .ctx field is not NULL. This also changes videotoolbox-copy to use --videotoolbox-format, instead of the FFmpeg-set default.
* videotoolbox: factor some duplicated codewm42017-02-171-39/+2
| | | | | | | | The code for copying a videotoolbox surface to mp_image was duplicated (with some minor differences - I picked the hw_videotoolbox.c version, because it was "better"). mp_imgfmt_from_cvpixelformat() is somewhat duplicated with the vt_formats[] table, but this will be fixed in a later commit, and moving the function to shared code is preparation.
* cocoa: refactor mouse events and cursor visibilityAkemi2017-02-164-39/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | we reported some unnecessary mouse movements and not all mouse enter and leave events. that lead to wrongly reported activity on hover areas like on the OSC or comparable lua scripts. sometimes menu items were shown that shouldn't be shown or they didn't vanish because of the missing mouse leave event. this incorporates @torque's fix for mouse leave events that weren't triggered during a transition, like going to fullscreen. the tracking area was updated but the mouse never left that area because it was never over it. besides some known cursor visibility bugs the aforementioned changes also revealed some other bugs that weren't reproducible before because of the missbehavior. known issues, in some cases the cursor doesn't show or hide properly. for example when switching spaces, switching Apps via CMD+Tab or a system notification. former two could be fixed while keeping our current blank cursor approach. though the notification case couldn't. there is no event or similar to detect a notification and the cursor visibility couldn't be recovered in any way. new issues, i noticed that our event view isn't initialised yet when the first VOCTRL_SET_CURSOR_VISIBILITY event gets dispatched, which depends on the event view to be initialised. so the mouse cursor couldn't be hidden when mpv was opened and the cursor was within the window bounds. this wasn't noticeable before because of various bugs and unwanted behavior that have been fixed with this. now, in case the event view isn't ready yet, we set the visibility at a later point when the event view is ready and a helper flag is set. Fixes #1817 #3856 #4147
* vo_opengl: hwdec_vaegl: fix potentially undefined memory accesswm42017-02-141-2/+2
|
* cocoa: fix black edges on live resizeAkemi2017-02-131-20/+34
| | | | | | | | this fixes a small bug with black edges on live resize, due to the synchronisation with the DisplayLink. we just pause the DisplayLink for the duration of the live resize. i also added some convenience functions for reoccurring calls and simplified some DisplayLink related screen info.
* cocoa: add --ontop-level option for modifying ontop window levelAkemi2017-02-131-6/+13
| | | | | | | | | | since there are different views on what ontop is, we make the ontop window level modifiable. at the moment only support for macOS was added. the default for macOS was changed from 'system' to 'window' since this fixes an unwanted behaviour in fullscreen and in general causes less issues with expected behaviour. Fixes #2376 #3974
* win32: update the fullscreen state on restoringpavelxdd2017-02-121-1/+22
| | | | | If a maximized window restored from fullscreen, the fullscreen state needs to be updated manually.
* vo_opengl: angle: log the device/surface implementationJames Ross-Gowan2017-02-121-13/+27
| | | | | This should be useful for debugging, since otherwise it's hard to tell which implementation has been auto-detected or if any failed to init.
* vo_opengl: egl_helpers: fix for non-WindowsJames Ross-Gowan2017-02-081-1/+1
| | | | Whoops. Fixes #4119
* vo_opengl: angle: rewrite with custom swap chainJames Ross-Gowan2017-02-074-232/+653
| | | | | | | | | | | | | This replaces the old backend that exclusively used EGL windowing with one that can also use ANGLE's ability to render to directly to a texture. The advantage of this is that it allows mpv to create the swap chain itself and this allows mpv to use a flip-mode swap chain on a HWND (which avoids problems with DirectComposition) and to use a longer swap chain that has six backbuffers by default (which reportedly fixes problems with rendering 24fps video on 24Hz monitors.) Also, "screenshot window" should now work on DXGI 1.2 and up (Windows 8 and up.)
* cocoa: fix color profile retrievalAkemi2017-02-021-0/+1
| | | | | | | | when the color profile was changed it used the right NSScreen but with the old colorSpace. this was optimised out by a previous commit because of a wrong assumption. we need to update the screen so we can get the new colorSpace. this adds a bit of redundancy since on screen change it will update screen pointer twice.
* cocoa: fix dropping of files and URLsAkemi2017-02-021-14/+5
| | | | | | | | | | | | | | | | | | | the problem here is that dropped files can also be treated as NSURLPboardType instead of just NSFilenamesPboardType. the 'else if' could never be reached and was dead code. this basically reverts ed695ce which tried to fix multiple dropped URLs, or rather files, and moves the filename check infront of the URL check. the filename path can handle multiple dropped files, whereas the URL path can only handle one dropped URL. this assumes that only one URL can be dropped at a time. it also reverts a603543 because it's not needed any more. this also fixes a problem where dropped URLs from Chrome don't conform to the NSURL class and the readObjectsForClasses method always returned an empty URL. Fixes #4036
* cocoa: optimise screen event handlingAkemi2017-02-022-9/+20
| | | | | | | | | | | | | | | | this optimises two things and fix a minor bug. 1. we always updated the display refresh rate on any mode change whether it was the current screen or not. now we only update the refresh rate when the mode changed happened on the current screen. 2. the windowDidChangeScreen event doesn't exclusively trigger on screen changes so we updated the display refresh rate in cases where it wasn't needed at all. since we manually keep track of the current screen, we can easily test if the screen really changed. 3. weirdly on initWithContentRect accessing the screen of the window always returned the main screen instead of the screen the window is created on. since we already use the window init method with the screen as argument, overwrite that method instead and use the screen argument.
* cocoa: fix displaylink refresh rate retrievalAkemi2017-02-021-23/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | we are dealing with several problems here, which weren't apparent because we always initialised a new displaylink for the display refresh rate retrieval, previously to commit 449eb20 and bug 9490b62. just changing the display with CVDisplayLinkSetCurrentCGDisplay can cause inconsistent refresh rates and discontinuity in timestamps. this can either lead to bogus values for the Actual display refresh rate or retrieving the refresh rate of the previous display if we immediately try to get a new value. since the Actual refresh rate is computed i assume that it at least needs one refresh period to actual return something useful. furthermore when changing the screen and updating the displaylink, it seems that the retrieved refresh rates for the screen mpv wasn't opened on are being estimated in a sub-optimal way. as an example, when moving my window to my second screen the Actual refresh rate was always a constant 60Hz, even though it is supposed to fluctuate a little bit. though if mpv was started on the secondary screen the Actual refresh rate fluctuated around 59.94Hz like expected. in that case my primary screen always reported a constant 60Hz instead. for the first problem we moved the actual retrieval of the refresh rate to the very last moment when mpv actual requests a new value and not when the refresh rate changed. we only update the displaylink itself when a possible refresh rate change is detected. this gives the displaylink some time to calculate the new refresh rate. for the second problem, instead of setting the new display we completely uninitialise the old dislaylink and create a new one for the new screen. this gives us properly estimated refresh rates. additionally we also optimised the display refresh rate fallback heuristic. it will never be 0 anymore and we prevent it from returning bogus values with a simple threshold for the difference of the Actual and Nominal refresh rate.
* cocoa: fix unwanted behavior with window level other than the defaultAkemi2017-01-291-2/+4
| | | | | | | | | | setting a window level other than NSNormalWindowLevel always sets NSWindowCollectionBehaviorTransient, which prevents certain things to work properly. examples are automatic switching to the active Space when mpv is made active and (de-)miniaturizing. latter always lead to a vanishing window. Fixes #1757 #1884
* vo_opengl: dxinterop: use the new SAFE_RELEASE macroJames Ross-Gowan2017-01-301-15/+8
|
* vaapi: remove central lock around vaapi API callswm42017-01-283-20/+0
| | | | | | | | The lock was disabled recently. This commit gets rid of the dummied out calls. The main reason for removing it is that there is no apparent need for it anymore, and the new FFmpeg vaapi code does not use or provide such a lock (there are some places which we cannot control and which do vaapi API calls, like frame destructors).
* win32: snap to screen edgespavelxdd2017-01-271-0/+146
| | | | | | | Disabled by default. The snap sensitivity value depends on the screen DPI. The default value is 16px on a 96 DPI screen. Fixes #2248
* vo_opengl: egl_helpers: fix variable namewm42017-01-261-3/+3
| | | | | | It was basically inverted. Not sure how this even happened. Hopefully it's more an "I don't know what I was doing" instead of an "I don't know what I am doing" case.
* options: refacactor how --opengl-dwmflush is declaredwm42017-01-203-12/+10
| | | | | Same deal as previous commit, except this time we just readd it as lone global option, and read it directly.
* options: refactor how --opengl-dcomposition is declaredwm42017-01-204-8/+23
| | | | | | | | | | | | | | | | | vo_opengl used to have it as sub-option, which made it very hard to pass down option values to backends in a generic way (even if these options were completely backend-specific). For --opengl-dcomposition we used a VOFLAG to deal with this. Fortunately, sub-options are gone, and we can just add it as global option. Move the option to context_angle.c and add it as global option. I thought about adding a mechanism to let backends declare options, which would get magically picked up my m_config instead of having to add them to the global option list manually (similar to VO vo_driver.options), but decided against this complexity just for 1 or 2 backends. Likewise, it could have been added as a single option to avoid the boilerplate of an option struct, but then again there are probably going to be more angle suboptions, and it's cleaner.
* x11: pseudo HiDPI scalingwm42017-01-194-5/+38
| | | | | | | | | | | | | | | | Scale the window by the assumed DPI scaling factor, using 96 DPI as base. For example, a screen that reports 192 DPI is assumed to have a DPI scale factor 2. The window will then be created with twice the size. For robustness reasons, we accept only integer DPI scales between 1 and 9. We also error out if the X and Y scales are very different, as this most likely indicates a multiscreen system with botched size reporting. I'm not sure if reading the X server's DPI is such a good idea - maybe the Xrdb "Xft.dpi" value should be used instead. The current method follows what xdpyinfo does. This can be disabled with --hidpi-window-scale=no.
* cocoa: don't constrain window frame for fullscreenAkemi2017-01-191-3/+4
| | | | | | | | | | | | | our constrainFrameRect prevents our window from positioning itself ontop of the menubar, which is unwanted for a fullscreen window. this always positioned our window vertically at -22/-23pt when going into fullscreen because of the menubar. this bug doesn't show on newer versions of OS X since the various flags we set force the window position. on OS X 10.9 though the fullscreen window was shifted 22pt downwards. even though this bug doesn't show on newer OS X versions, it should still be fixed for a possible behaviour changes in future version. Fixes #4044
* cocoa: don't init displaylink on reconfigAkemi2017-01-191-1/+1
| | | | | | | | | | | everytime we switched to a new video file a new displaylink was initialised and started, but the old one was not stopped and released beforehand. this lead to several displaylink callback calls per swap, depending on how many files were switched beforehand. moving the displaylink init call to the cocoa init functions will ever only init one displaylink. Fixes #4031
* cocoa: move updateBorder method to the protocolAkemi2017-01-192-5/+6
| | | | | | we are calling the method on a NSWindow object that may not respond to that call, since its a method of MpvVideoWindow. add the method to our protocol and rename that protocol to reflect the change.
* cocoa: properly recover from toggleFullscreen failAkemi2017-01-191-8/+20
| | | | | | | | | | | in some circumstances cocoa isn't able to enter or exit fullscreen but we still set window sizes and flags accordingly. this leaves us in a hanging state between fullscreen and window. it also prevents the toggleFullscreen method and its events to work properly afterwards. in that state it's impossible to enter or exit this 'semi-fullscreen'. add a proper fallback to recover from this state. Fixes #4035
* cocoa: fix window size in certain circumstancesAkemi2017-01-191-8/+2
| | | | | | a combination of starting from bundle and fullscreen used the standard window size (960x480) from the pseudo GUI instead of the wanted video size.
* vo: log timings around flipping/waitingwm42017-01-181-3/+6
| | | | Found those useful.
* vo_opengl, vo_opengl_cb: better hwdec interop backend selectionwm42017-01-174-16/+76
| | | | | | | | | | | Introduce the --opengl-hwdec-interop option, which replaces --hwdec-preload. The new option allows explicit selection of the interop backend. This is relatively complex, and I would have preferred not to add this, but it's probably useful to debug certain problems. In exchange, the "new" option documents that pretty much any but the simplest use of it will not be forward compatible.
* vo_opengl_cb: cleanup messy option synchronizationwm42017-01-171-24/+16
| | | | | | | | Replace the old code, that played games to evade thread-safety issues, with newer thread-safe option access functions. This also means mp_opengl_create() doesn't need to cache the hwdec settings anymore. (They're applied in mpv_opengl_cb_init_gl() instead.)
* vdpau: use libavutil for surface allocation during decodingwm42017-01-171-1/+2
| | | | | | | | | | | | | | | | Use the libavutil vdpau frame allocation code instead of our own "old" code. This also uses its code for copying a video surface to normal memory (used by vdpau-copy). Since vdpau doesn't really have an internal pixel format, 4:2:0 can be accessed as both nv12 and yuv420p - and libavutil prefers to report yuv420p. The OpenGL interop has to be adjusted accordingly. Preemption is a potential problem, but it doesn't break it more than it already is. This requires a bug fix to FFmpeg's vdpau code, or vdpau-copy (as well as taking screenshots) will fail. Libav has fixed this bug ages ago.
* vo_opengl: hwdec_cuda: add yuv420p supportwm42017-01-161-19/+35
| | | | | | | | | Because it allows easier testing of filters + hwdec. Make the texture setup code a bit more generic so it doesn't get too much of a mess. We also use the GL renderer utility function gl_find_unorm_format(), which saves us additional work with OpenGL's semi-redundant format specifiers.
* vo_opengl: hwdec_cuda: export AVHWDeviceContextwm42017-01-161-6/+31
| | | | So we can use it for filtering later.
* vo_opengl: hwdec_vaegl: add a lie for compatibilitywm42017-01-131-1/+1
| | | | | | | EGL rendering + new decode API didn't work due to a certain libva bug with sort-of legacy API use hitting again. It will report the wrong vaapi pixel format. It's old code and always nv12 anyway, so stop worrying about it.
* vo_opengl, vaapi: properly probe 10 bit rendering supportwm42017-01-131-28/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are going to be users who have a Mesa installation which do not support 10 bit, but a GPU which can decode to 10 bit. So it's probably better not to hardcode whether it is supported. Introduce a more general way to signal supported formats from renderer to decoder. Obviously this is imperfect, because it still isn't part of proper format negotation (for example, what if there's a vavpp filter, which accepts anything). Still slightly better than before. I don't know any way to probe for vaapi dmabuf/EGL dmabuf support properly (in particular testing specific formats, not just general availability). So we stay with the current approach and try to create and map dummy surfaces on init to probe for support. Overdo it and check all formats that AVHWFramesConstraints reports, instead of only NV12 and P010 surfaces. Since we can support unknown formats now, add explicitly checks to the EGL/dmabuf mapper code to reject unsupported formats. I also noticed that libavutil signals support for RGB0/BGR0, but couldn't get it to work. Remove the DRM formats that are unused/didn't work the way I tried to use them. With this, 10 bit decoding + rendering should work, provided you have a capable CPU and a patched Mesa. The required Mesa patch adds support for the R16 and GR32 formats. It was sent by a Kodi developer to the Mesa developer mailing list and was not accepted yet.
* vo_opengl: hwdec_vaegl: remove redundant vaapi surface format checkwm42017-01-131-8/+1
| | | | | | | | | | | | | | | | | For surfaces allocated by libavutil, we assume that the sw_format (i.e. in hw_subfmt in mp_image_params) is always correct. The API guarantees that it explicitly sets the equivalent vaapi format on surface allocation. For surfaces allocated by mpv's old vaapi code, we explicitly retrieve the format right after decoding. Unless the driver magically changes the format asynchronously, it will still be correct once the surface reaches the renderer. In both cases, checking the format again is obviously redundant. In addition, it doesn't require us to maintain a libva fourcc <-> mpfmt table and the va_fourcc_to_imgfmt() function. This also unbreaks 10 bit rendering support (still disabled by default).
* vo_opengl: hwdec_vaegl: fix terminology in commentwm42017-01-131-2/+2
| | | | Bad idea to call a component "pixel" - that's true only for the Y plane.
* vo_opengl: hwdec_vaegl: DRM_FORMAT_GR16 was renamed to DRM_FORMAT_GR32Mark Thompson2017-01-131-1/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: hwdec_vaegl: add experimental P010 supportwm42017-01-121-6/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | This does not work, because Mesa has no support for the proposed DRM_FORMAT_R16 and DRM_FORMAT_GR16 formats. It's also untested of course. As long as video/decode/vaapi.c doesn't hand down P010 surfaces, this is fine anyway. This can be tested by removing the code that disables P010 output: diff --git a/video/decode/vaapi.c b/video/decode/vaapi.c --- a/video/decode/vaapi.c +++ b/video/decode/vaapi.c @@ -55,13 +55,6 @@ static int init_decoder(struct lavc_ctx *ctx, int w, int h) assert(!ctx->avctx->hw_frames_ctx); - // If we use direct rendering, disallow 10 bit - it's probably not - // implemented yet, and our downstream components can't deal with it. - if (!p->own_ctx && required_sw_format != AV_PIX_FMT_NV12) { - MP_WARN(ctx, "10 bit surfaces are currently supported.\n"); - return -1; - } -
* cuda: use libavutil functions for copying hw surfaces to memorywm42017-01-121-67/+0
| | | | | | | | mp_image_hw_download() is a libavutil wrapper added in the previous commit. We drop our own code completely, as everything is provided by libavutil and our helper wrapper. This breaks the screenshot code, so that has to be adjusted as well.
* cocoa: don't change Space on quit in fullscreenAkemi2017-01-111-6/+10
| | | | | | | circumvent undefined behavior when quitting in fullscreen. Fixes #3957
* cocoa: rate limit video outputAkemi2017-01-111-14/+51
| | | | | | | | | | | | the display refresh rate can't be est