summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* Avoid calling close(-1)wm42017-06-291-2/+4
| | | | | | | | | | While this is perfectly OK on Unix, it causes annoying valgrind warnings, and might be otherwise confusing to others. On Windows, the runtime can actually abort the process if this is called. push.c part taken from a patch by Pedro Pombeiro.
* vo_opengl: unify user_shaders constantsNiklas Haas2017-06-282-13/+10
| | | | | | | | | | | | | | | Commit 3fb6380 was supposed to increase MAX_TEXTURE_HOOKS but instead increased SHADER_MAX_HOOKS, since I forgot that they were separate (for whatever reason). To prevent this mistake from happening again, and to unify the location in which user_shader-specific #defines are placed, get rid of the two constants in opengl/video.c and move/reuse them from user_shaders.h instead. Also bump up MAX_SAVED_TEXTURES (now SHADER_MAX_SAVED) slightly as a precaution against adding more passes to vo_opengl. I think we're already flirting with the limit.
* vo_opengl: tone map using only luminance informationNiklas Haas2017-06-271-33/+24
| | | | | | | | | | | | | | | | | | | This is even better at preventing discoloration than tone mapping on the XYZ image. Partly inspired by the HLG OOTF. Also simplifies the way we tone map, and moves this logic to the pass_tone_map function where it belongs. This also fixes what could arguably be considered a bug in the HLG implementation when using HLG for non-BT.2020 colorspaces, which is not permitted by spec but thinkable in theory. Although in this case, I guess it will be arbitrary whether people use the BT.2020-normalized luma coefficients or change it to fit the colorspace, so I guess either way could be considered "right", depending on what people end up doing. Either way, in lieue of standard practice, we do what makes the most sense (to me), and hopefully others will follow. The downside is that we upload an extra vec3 uniform even if we don't use it, but eliminating that would be ugly.
* vo_opengl: silence -Wmaybe-uninitialized false positiveNiklas Haas2017-06-241-3/+3
| | | | | | | | | These can never be uninitialized because the enum cases are exhaustive and the fallback is in the correct order, but GCC is too dumb to understand this. Also explicitly initialize tex_type, because while GCC doesn't warn about it (for some reason), maybe it will in the future.
* osx: change license header on some more cocoa fileswm42017-06-247-49/+49
| | | | Changing the headers was actually forgotten in the previous commit.
* osx: change license of OSX and cocoa files to LGPLwm42017-06-242-15/+15
| | | | All authors of the current code have agreed.
* w32_common, w32_keyboard: change license to LGPLwm42017-06-242-14/+14
| | | | All authors agreed.
* vo_opengl: bump up SHADER_MAX_HOOKSNiklas Haas2017-06-241-1/+1
| | | | | Apparently people are running into the current limit. 64 ought to be enough for everybody.
* context_dxinterop: lock rendertarget after present when swapping buffersquilloss2017-06-181-7/+6
| | | | | | | | Moves the DXLockObjectsNV call to after PresentEx. This fixes an issue where the presented image is a single frame late. This may be due to DXLockObjectsNV locking the render target before StretchRect is done. The spec indicates that the lock call should provide synchronization for the resource, so this may be due to a driver bug.
* vo_drm: nake drm mode help output also output refresh rateAnton Kindestam2017-06-181-3/+9
| | | | | | | | | The printout of available modes that you can get with --drm-mode=-1 (with -vo drm or --opengl-backend=drm) does not include the refresh rate in the printout, which is quite useful to know, if one is to choose for instance 23.98, or 24 Hz for film material. Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: implement sony s-log2 trcNiklas Haas2017-06-181-1/+18
| | | | | | | | Apparently this is virtually identical to Panasonic's V-Log, but using the constants from S-Log1 and an extra scaling coefficient to make the S-Log1 curve less limited. Whatever floats their NIH boat, I guess. Source: https://pro.sony.com/bbsccms/assets/files/micro/dmpc/training/S-Log2_Technical_PaperV1_0.pdf
* vo_opengl: implement sony s-log1 trcNiklas Haas2017-06-181-0/+14
| | | | | | | | Source: https://pro.sony.com/bbsccms/assets/files/mkt/cinema/solutions/slog_manual.pdf Not 100% confident in the implementation since the values from the spec seem to be very subtly off (~1%), but it should be close enough for practical purposes.
* vo_opengl: tone map in linear XYZ instead of RGBNiklas Haas2017-06-181-1/+19
| | | | | | | | | | | | | This preserves channel balance better and helps reduce discoloration due to nonlinear tone mapping. I wasn't sure whether to stuff this inside pass_color_manage or pass_tone_map but decided for the former because adding the extra mp_csp_prim would have made the signature of the latter longer than 80col, and also because the `mp_get_cms_matrix` below it basically does the same thing anyway, so it doesn't look that out of place. Also why is this justification longer than the actual description of the algorithm and what it's good for?
* vo_opengl: implement support for OOTFs and non-display referred contentNiklas Haas2017-06-183-8/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces (yet another..) mp_colorspace members, an enum `light` (for lack of a better name) which basically tells us whether we're dealing with scene-referred or display-referred light, but also a bit more metadata (in which way is the scene-referred light expected to be mapped to the display?). The addition of this parameter accomplishes two goals: 1. Allows us to actually support HLG more-or-less correctly[1] 2. Allows people playing back direct “camera” content (e.g. v-log or s-log2) to treat it as scene-referred instead of display-referred [1] Even better would be to use the display-referred OOTF instead of the idealized OOTF, but this would require either native HLG support in LittleCMS (unlikely) or more communication between lcms.c and video_shaders.c than I'm remotely comfortable with That being said, in principle we could switch our usage of the BT.1886 EOTF to the BT.709 OETF instead and treat BT.709 content as being scene-referred under application of the 709+1886 OOTF; which moves that particular conversion from the 3dlut to the shader code; but also allows a) users like UliZappe to turn it off and b) supporting the full HLG OOTF in the same framework. But I think I prefer things as they are right now.
* csputils: rename HDR curvesNiklas Haas2017-06-182-26/+22
| | | | | | | | | | st2084 and std-b67 are really weird names for PQ and HLG, which is what everybody else (including e.g. the ITU-R) calls them. Follow their example. I decided against naming them bt2020-pq and bt2020-hlg because it's not necessary in this case. The standard name is only used for the other colorspaces etc. because those literally have no other names.
* video: refactor HDR implementationNiklas Haas2017-06-183-73/+54
| | | | | | | | | | | | | | | List of changes: 1. Kill nom_peak, since it's a pointless non-field that stores nothing of value and is _always_ derived from ref_white anyway. 2. Kill ref_white/--target-brightness, because the only case it really existed for (PQ) actually doesn't need to be this general: According to ITU-R BT.2100, PQ *always* assumes a reference monitor with a white point of 100 cd/m². 3. Improve documentation and comments surrounding this stuff. 4. Clean up some of the code in general. Move stuff where it belongs.
* image_writer, vo_image: change license to LGPLwm42017-06-181-7/+7
| | | | | | | | | | | | | | | | | | image_writer.c has code originating from vf_screenshot.c, vo_jpeg.c, and potentially others. vo_image.c is based on a bunch of those VOs as well, and the intention was to replace them with a single codebase. vo_tga.c was written by someone who was not or not could be contacted, but it doesn't matter anyway, as no code from that initial patch was used. One rather old patch (57f77bb41a9) reordered by libjpeg patch API calls, and the author of the patch was not contacted. But at least with the smoothing_factor override removed, this pretty much exactly corresponds to the official libjpeg API example (and might even reflect a change to those - didn't dig deeper). This removes the -jpeg-smooth option. While we're at it, remove all the other dropped jpeg options from the manpage (which was forgotten in past changes).
* Drop/move img_fourcc.hwm42017-06-182-6/+13
| | | | | | | | | | | | | | | This file is an leftover from when img_format.h was changed from using the ancient FourCCs (based on Microsoft multimedia conventions) for pixel formats to a simple enum. The remaining cases still inherently used FourCCs for whatever reasons. Instead of worrying about residual copyrights in this file, just move it into code we don't want to relicense (the ancient Linux TV code). We have to fix some other code depending on it. For the most part, we just replace the MP_FOURCC macro with libavutil's MKTAG (although the macro definition is exactly the same). In demux_raw, we drop some pre-defined FourCCs, but it's not like it matters. (Instead of --demuxer-rawvideo-format use --demuxer-rawvideo-mp-format.)
* win_state: change license to LGPLwm42017-06-171-7/+7
| | | | | | All relevant authors have agreed. Also correct an unrelated entry in the "Copyright" file.
* aspect: change license to LGPLwm42017-06-172-14/+14
| | | | | | | | | | | | | | | Quite chaotic history, which code being moved, refactored, duplicated, unified a bunch of times. But I think everything is covered by LGPL agreements. In one case, cehoyos (who didn't agree) applied a patch by someone who agreed, but didn't change anything (except weirdly adding German translations). In another case, cehoyos moved code covered by LGPL agreements (without changing it), which was later used for some other code. We consider both cases not relevant for copyright. win_state.c/.h is similar, but pending for reply by the author of 2ab259e68 (I guess).
* vo_opengl: fall back to ordered dither instead of blowing upwm42017-06-171-4/+9
| | | | | | | | | | | | | In GLES 2 mode, we can do dither, but "fruit" dithering is still out of the question, because it does not support any high depth textures. (Actually we probably could use an 8 bit texture too for this, at least with small matrix sizes, but it's still too much of a pain to convert the data, so why bother.) This is actually a regression; before this, forcibly enabling dumb mode due to low GL caps actually happened to avoid this case. Fixes #4519.
* encode_lavc: move from GPL 2+ to LGPL 2.1+.Rudolf Polzer2017-06-131-7/+7
|
* vo_opengl: change default tone mapping algorithmNiklas Haas2017-06-101-1/+1
| | | | | d8a3b10f4 was supposed to change this (as reflected in the man page and commit message), I just forgot.
* vo_opengl: add new HDR tone mapping algorithmNiklas Haas2017-06-093-0/+17
| | | | | | | | | | | | | | | | | I call it `mobius` because apparently the form f(x) = (cx+a)/(dx+b) is called a Möbius transform, which is the algorithm this is based on. In the extremes it becomes `reinhard` (param=0.0 and `clip` (param=1.0), smoothly transitioning between the two depending on the parameter. This is a useful tone mapping algorithm since the tunable mobius transform allows the user to decide the trade-off between color accuracy and detail preservation on a continuous scale. The default of 0.3 is already far more accurate than `reinhard` while also being reasonably good at preserving highlights, without suffering from the overall brightness drop and color distortion of `hable`. For these reasons, make this the new default. Also expand and improve the documentation for these tone mapping functions.
* d3d: add support for new libavcodec hwaccel APIwm42017-06-084-0/+5
| | | | | | Unfortunately quite a mess, in particular due to the need to have some compatibility with the old API. (The old API will be supported only in short term.)
* vo_drm: fallback to vo_wait_default if VT switcher is not availablerslovers2017-06-081-0/+2
| | | | | | | | | | | | | | | | | | | When the drm video output is used under VT with a terminal multiplexer like screen, the VT_SETMODE ioctl call will fail since the controlling terminal is a pseudoterminal instead of a real one, thus the VT switcher will be unavailable. The problem is, the wait_events function inside vo_drm.c will test for this, and will do nothing if the switcher is not active. Normally, this would not be noticed, however, when you pause a video, or if you're playing multiple image files, mpv will suddenly start busy waiting on a single core. I confirmed this by building mpv with gprof support, in a few seconds, wait_events got called about 90 million times. So I added a fallback, when the VT switcher is not availble, just use the vo_wait_default function. I tested it and it's working well so far.
* vo_opengl: hwdec_cuda: Support separate decode and display devicesPhilip Langdale2017-06-032-12/+47
| | | | | | | | | | | | | | | | | In a multi GPU scenario, it may be desirable to use different GPUs for decode and display responsibilities. For example, if a secondary GPU has better video decoding capabilities. In such a scenario, we need to initialise a separate context for each GPU, and use the display context in hwdec_cuda, while passing the decode context to avcodec. Once that's done, the actually hand-off between the two GPUs is transparent to us (It happens during the cuMemcpy2D operation which copies the decoded frame from a cuda buffer to the OpenGL texture). In the end, the bulk of the work is around introducing a new configuration option to specify the decode device.
* video/out/wayland/buffer.c: Add missing free()Raúl Peñacoba2017-05-261-1/+4
|
* videotoolbox: support new libavcodec APIwm42017-05-242-0/+24
| | | | | | | | | | | The new API has literally no advantages (other than that we can drop mp_vt_download_image and other things later), but it's sort-of uniform with the other hwaccels. "--videotoolbox-format=no" is not supported with the new API, because it doesn't "fit in". Probably could be added later again. The iOS code change is untested (no way to test).
* cocoa: properly unhide Dock when quitting during System fs animationAkemi2017-05-192-0/+64
| | | | | | | | when quitting mpv during the System fullscreen animation cocoa can't reset some flags properly and won't reset the Dock hiding behaviour to it's previous state. Fixes #4400
* context_angle: fix fallback to D3D9 deviceJames Ross-Gowan2017-05-161-30/+56
| | | | | | | | | This was broken in e0250b9604b2. In some cases, device creation will succeed, but creating an EGL context on the device will fail. With --angle-renderer=auto, it should try to create the context again on a D3D9 device. This fixes mpv in Windows Vista on VirtualBox for me.
* w32_common: drop TLS usageJames Ross-Gowan2017-05-161-20/+21
| | | | | | | | | | | This was added in 3f268cc4f2a4 because it wasn't clear whether WM_NCCREATE could be used to send a context pointer from CreateWindowEx to the window procedure. WM_NCCREATE isn't always the first message sent to a window, but this seems to be because of an undocumented but well-known bug where, for top-level overlapped windows, a spurious WM_GETMINMAXINFO arrives first instead. The WM_GETMINMAXINFO can be safely ignored, so it is still okay to pass the context struct in WM_NCCREATE.
* w32_common: use the proper keycodes for XBUTTON1/2James Ross-Gowan2017-05-121-2/+2
| | | | | | | mpv's mouse button numbering is based on X11, which means XBUTTON1 and 2 on Windows (the "back" and "forward" buttons) should map to MOUSE_BTN7 and 8 in mpv. MOUSE_BTN5 and 6 refer to the horizontal scroll buttons on mouses that have them.
* w32_common: generate MP_AXIS_* keycodes for scrollingJames Ross-Gowan2017-05-121-8/+18
| | | | | | | | | | | Windows doesn't have a way to distinguish "precise" mouse wheel events and events from regular notched mouse wheels. A notched wheel should always send events with a delta of 120, but a precise wheel could also happen to send 120 if multiple scroll events are coalesced (and to make things even harder, some buggy Microsoft drivers send deltas less than 120, even for notched wheels.) Since there is no distinction, but MP_AXIS_* keycodes can hold more information (the delta value,) send MP_AXIS_* events for both kinds of mouse wheel scrolling.
* vo_opengl: drop TLS usagewm42017-05-116-38/+32
| | | | | | | | | | | TLS is a headache. We should avoid it if we can. The involved mechanism is unfortunately entangled with the unfortunate libmpv API for returning pointers to host API objects. This has to be kept until we change the API somehow. Practically untested out of pure laziness. I'm sure I'll get a bunch of reports if it's broken.
* vo.c, vo.h, vo_null.c: change license to LGPLwm42017-05-103-24/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most contributors have agreed. vo.c requires a "driver" entry for each video output - we assume that if someone who didn't agree to LGPL added a line, it's fine for vo.c to be LGPL anyway. If the affected video output is not disabled at compilation time, the resulting binary will be GPL anyway. One problem are the changes by Nick Kurshev (usually using "nick" as SVN username). He could not be reached. I believe all changes to his files are actually gone, but here is a detailed listing: fa1d5742bc: nick introduces a new VO API. It was removed in 64bedd9683. Some of this was replaced by VOCTRLs are introduced in 7c51652a1b, obviously replacing at least some functionality by his API. b587a3d642: nick adds a vo_tune_info_t struct. Removed in 64bedd9683 too. 9caad2c29a: nick adds some VOCTRLs, which were silently removed in 8cc5ba5ab8 (they became unused probably with the VIDIX removal). 340183b0e9: nick adds VO-based screenshots, which got removed in 2f4b840f62. Strangely the same name was introduced in 01cf896a2f again, but this is a coincidence and worked differently (also it was removed yet again in 2858232220). 104c125e6d: nick adds an option for "direct rendering". It was renamed in 6403904ae9 and fully removed in e48b21dd87. 5ddd8e92a1: nick adds code to check the VO driver preinit arg to every single VO driver. The argument itself and any possibly remaining code associated with it was removed in 1f5ffe7d30. f6878753fb: nick adds header inclusion guards. We assume this is not relevant for copyright. Some of nick's code was merely moved to other files, such as the equalizer stuff added in 555c676683 and moved in 4db72f6a80 and 12579136ff, and don't affect copyright of these files anymore. Other notes: fef7b17c34: a patch by someone who wasn't asked for relicensing added a symbol that was removed again in 1b09f4633. 4a8a46fafd: author probably didn't agree to LGPL, but the function signature was changed later on anyway, and nothing of this is left. 7b25afd742: the same author adds a symbol to what is vo.h today, which this relicensing commit removes, as it was unused. (It's not clear whether the mere symbol is copyrightable, but no need to take a risk.) 3a406e94d7, 9dd8f241ac: slave mode things by someone who couldn't be reached. This aspect of the old slave mode was completely removed. bbeb54d80a: patch by someone who was not asked, but the added code was completely removed again.
* d3d11: change mp_image plane pointer semanticswm42017-05-042-3/+3
| | | | | | | | Until now, the texture pointer was stored in plane 1, and the texture array index was in plane 2. Move this down to plane 0 and plane 1. This is to align it to the new WIP D3D11 decoding API in Libav, where we decided that there is no reason to avoid setting plane 0, and that it would be less weird to start at plane 0.
* vo_opengl: another attempt at removing the overlay correctlywm42017-05-021-4/+12
| | | | | | | | This reverts commit 142b2f23d4293, and replaces it with another try. The previous attempt removed the overlay on every rendering, because the normal rendering path actually unrefs the mp_image. Consequently, unmap_current_image() was completely inappropriate for removing the overlay.
* vo_opengl: make sure overlays are removed on gl_video_config()wm42017-04-291-1/+4
| | | | | This should make vo_opengl_cb uninit remove the frame, even if the renderer and OpenGL state remains active.
* vo_opengl: context_drm_egl: remove unnecessary includewm42017-04-261-1/+0
| | | | | Could be broken after the previous commit removed finding the GL include dir.
* video: drop vaapi/vdpau hw decoding support with FFmpeg 3.2wm42017-04-231-47/+34
| | | | | | | | | | This drops support for the old libavcodec APIs. Now FFmpeg 3.3 or FFmpeg git is required. Libav has no release with the new APIs yet, so for Libav git as of a few weeks or months ago or so is required if you want to use Libav. Not much actually changes in hwdec_vaegl.c - some code is removed, but the reindentation inflates the diff.
* build: make various x11 protocol extension libs mandatorywm42017-04-213-65/+31
| | | | | | | Reduces the ifdeffery, which is good and will avoid silent breakages, or weird behavior if a lib is omitted. Also reorder the x11_common.c include statements.
* vo_opengl: fix crash by coping temporal_dither_period for dumb mode toowm42017-04-211-0/+1
| | | | | Specifically, this field must never be 0 (and the option can naturally not be 0 in any way, unless it wasn't initialized correctly).
* cocoa: fix retrieval of unfs window size while animatingAkemi2017-04-171-1/+2
| | | | | | | | | | | due to the System inherent fullscreen animation the option and the actual fullscreen state can be out of sync, leading to a wrongly reported unfs window size in the time of the animation. just always fall back to the window size, we keep track of, when we either are in fullscreen or are currently switching to it. Fixes #4323
* vo_opengl: move X11 backends before Waylandwm42017-04-161-3/+3
| | | | | | | | Wayland is still too amateurish, and multiple features don't work, including critical ones. There is no solution in sight, so prefer X11. (Which seems to mostly work ok via xwayland.) Once all problems are solved, the defaults can be switched back.
* vo_opengl: minor cosmeticswm42017-04-143-11/+13
|
* vo_opengl: add option for caching shaders on diskwm42017-04-086-12/+142
| | | | | | | | | | | | | Mostly because of ANGLE (sadly). The implementation became unpleasantly big, but at least it's relatively self-contained. I'm not sure to what degree shaders from different drivers are compatible as in whether a driver would randomly misbehave if it's fed a binary created by another driver. The useless binayFormat parameter won't help it, as they can probably easily clash. As usual, OpenGL is pretty shit here.
* vo_opengl: fix a confused commentwm42017-04-081-1/+1
|
* vo_opengl: remove two unused symbolswm42017-04-082-2/+0
|
* vo_opengl: add our own copy of OpenGL headerswm42017-04-077-170/+781
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gl_headers.h is basically header_fixes.h done consequently. It contains all OpenGL defines (and some typedefs) we need. We don't include GL headers provided by the system anymore. Some care has to be taken by certain windowing APIs including all of gl.h anyway. Th