summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* mp_image: change license to LGPL (almost)wm42017-06-162-6/+5
| | | | | | | | | | | | | | | | | | | | | | Since michael was somewhat involved in it, wait with the actual license change until the core is relicensed. Thus mark it as "Almost LGPL.". The worrisome part about mp_image.c is that it was created by cehoyos (which disagreed with LGPL) in commit f2dee327b2797. But it turns out it was a patch by someone else (who agreed with LGPL). For some reason, the patch was actually slightly modified by cehoyos for no reason (messed with the include statements), so we mess them back, just to be sure. Other than this, there were some commits that added support for new IMGFMTs over the years. Some of these were by people we didn't ask or we didn't get permission from. But since the original mp_image code was replaced by more generic code using FFmpeg pixdesc, none of these changes are left anyway. One additional change by cehoyos (115bfb976270) has been removed as well (when "direct rendering" was dropped from the filter chain).
* vd, vd_lavc: change license to LGPL (almost)wm42017-06-152-8/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | iive agreed only to LGPL 3.0+ only. All of his relevant changes are for XvMC, for which mpv completely dropped support back in mplayer2 times. But you could claim that the get_format code represents some residual copyright (everything else added by iive was removed, only get_format still is around in some form). While I doubt that this is relly copyright-relevant, consider it is for now. michael is the original author of vd_lavc.c, so this file can become LGPL only after the core becomes LGPL. cehoyos did not agree with the LGPL relicensing, but all of his code is gone. Some others could not be reached, but their code is gone as well. In particular, vdpau support, which was originally done by Nvidia, had larger impact on vd_lavc.c, but vdpau support was first refactored a few times (for the purpose of modularization) and moved to different files, and then decoding was completely moved to libavcodec. Lastly, assigning the "opaque" field was moved by Gwenole Beauchesne in commit 8e5edec13eab. Agreement is pending (due to copyright apparently owned by the author's employer). So just undo the change, so we don't have to think about whether the change is copyrightable.
* 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.
* mp_image: refuse to convert frames of unknown format to AVFramewm42017-06-081-0/+2
| | | | | This could happen with some "special" hwaccel formats, that exist in mpv, but not libavutil.
* d3d: add support for new libavcodec hwaccel APIwm42017-06-0811-13/+391
| | | | | | 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.
* af, vf: improvements to libavfilter bridgewm42017-05-312-1/+8
| | | | | | Add the "lavfi-" prefix (details see manpage additons). Tag the filter name as "(lavfi)" in the verbose filter list output.
* video/out/wayland/buffer.c: Add missing free()Raúl Peñacoba2017-05-261-1/+4
|
* videotoolbox: support new libavcodec APIwm42017-05-244-0/+88
| | | | | | | | | | | 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).
* vd_lavc: check for missing device_ctx refwm42017-05-241-0/+5
| | | | | | It's not really guaranteed that other components always set this (e.g. on subtle errors), so check it explicitly. Although I'm not aware of a failing case.
* hwdec: fix 2 commentswm42017-05-241-2/+1
| | | | The first is outdated, the second was always wrong.
* demux_raw: drop "mp-rawvideo" usewm42017-05-201-5/+0
| | | | | | This is an old pseudo codec to pass through the pixel format. Setup a suitable AVCodecParameter directly instead, so the "rawvideo" codec can be used.
* 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
* vdpau: crappy hack to allow initializing hw decoding after preemptionwm42017-05-193-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If vo_opengl is used, and vo_opengl already created the vdpau interop (for whatever reasons), and then preemption happens, and then you try to enable hw decoding, it failed. The reason was that preemption recovery is not run at any point before libavcodec accesses the vdpau device. The actual impact was that with libmpv + opengl-cb use, hardware decoding was permanently broken after display mode switching (something that caused the display to get preempted at least with older drivers). With mpv CLI, you can for example enable hw decoding during playback, then disable it, VT switch to console, switch back to X, and try to enable hw decoding again. This is mostly because libav* does not deal with preemption, and NVIDIA driver preemption behavior being horrible garbage. In addition to being misdesigned API, the preemption callback is not called before you try to access vdpau API, and then only with _some_ accesses. In summary, the preemption callback was never called, neither before nor after libavcodec tried to init the decoder. So we have to get mp_vdpau_handle_preemption() called before libavcodec accesses it. This in turn will do a dummy API access which usually triggers the preemption callback immediately (with NVIDIA's drivers). In addition, we have to update the AVHWDeviceContext's device. In theory it could change (in practice it usually seems to use handle "0"). Creating a new device would cause chaos, as we don't have a concept of switching the device context on the fly. So we simply update it directly. I'm fairly sure this violates the libav* API, but it's the best we can do.
* 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.
* csputils: code clarityNiklas Haas2017-05-131-5/+5
| | | | | `cmax` is more intuitive than `cmin` especially for full-range YUV, and this also explains the behavior of `anyfull` better.
* 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.
* vf.c, vf.h: change license to LGPLwm42017-05-112-14/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most authors have agreed. Like with vo.c, we don't take module declarations into consideration (see 0e09533c73dc0). Notable issues: 115bfb9762: the author has (probably) not agreed. The vf.c changes were removed with the removal of filter DR, though (see c54fc507da8e). 7b25afd742: the same author adds VOCTRLs for deinterlacing switching at runtime. Put them under a HAVE_GPL ifdef just to be sure. (It looks like we could remove the VOCTRLs immediately, as they're needed only for some compatibility things, but no need to do that yet.) 02b199e5e9: the author had a conditional agreement to LGPL, which doesn't allow us to change it just yet, but the code added here was completely removed anyway. (These days, the pts is passed as mp_image field, and put_image is gone.) 3532cd532e: same author, but code removed with DR removal. f0626e2f8d: same author, but code was moved to mp_image.c. e5b4b495c3: agreed to LGPLv3+ only, but the code was removed in cfa1f9e082 anyway. 086c324692: author was not asked - minor warning fix, but no mpv includes malloc.h anymore. e9d0a1d609: author was not asked - removed again in 33b62af947. c260a1139d: author could not be reached - but this code was removed when mpv changed the image allocation code to essentially use FFmpeg's pixdesc.
* 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.
* cuda: add new way to set cuda context on cuvid codecswm42017-05-053-3/+27
| | | | See FFmpeg commit c0f17a905f3588bf61ba6d86a83c6835d431ed3d.
* d3d: fix build with Libavwm42017-05-042-0/+2
| | | | Apparently it has been broken since forever?
* d3d11: change mp_image plane pointer semanticswm42017-05-045-16/+16
| | | | | | | | 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.
* vd_lavc: fix build with FFmpeg 3.2wm42017-05-041-1/+6
| | | | | | | | Sigh... The functionality is not actually needed for vdpau, but if the vdpau hwaccel is present, the FFmpeg version is new enough that it includes the field.
* vd_lavc: add support for decoders which use AVCodecContext.hw_device_ctxwm42017-05-032-7/+18
| | | | | | | | | | | | These decoders can select the decoding device with hw_device_ctx, but don't use hw_frames_ctx (at least not in a meaningful way). Currently unused, but intended to be used for cuvid, as soon as it hits ffmpeg git master. Also make the vdpau and vaapi hwaccel definition structs static, as we have removed the old code which would have had clashing external declarations.
* 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.
* vdpau, vaapi: unref libavutil device refwm42017-04-292-0/+4
| | | | It's a simple memory leak. (The API objects were destroyed anyway.)
* 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-234-644/+37
| | | | | | | | | | 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. Then the definitions could clash. Fortunately, redefining preprocessor symbols to the same content is allowed and ignored. Also, redefining typedefs to the same thing is allowed in C11. Apparently the latter is not allowed in C99, so there is an imperfect attempt to avoid the typedefs if required API symbols are apparently present already. The nost risky part about this are the standard typedefs and GLAPIENTRY. The latter is different only on win32 (and at least consistently so). The typedefs are mostly based on stdint.h typedefs, which khrplatform.h clumsily emulates on platforms which don't have it. The biggest difference is that we define GLsizeiptr directly to ptrdiff_t, instead of checking for the _WIN64 symbol and defining it to long or long long. This also typedefs GLsync to __GLsync, just like the khronos headers. Although symbols prefixed with __ are implementation reserved, khronos also violates this rule, and having the same definition as khronos will avoid problems on duplicate definitions. We can simplify the build scripts too. The ios-gl check seems a bit wrong now (what we really want to test for is EAGLContext), but I can't test and thus can't improve it. cuda_dynamic.h redefined two GL symbols; just include the new headers directly instead.
* vd_lavc: fix return value in receive_frame()wm42017-04-071-1/+1
| | | | | Pointed out by uau. Not sure why gcc doesn't warn (it uses ((void*)0) for NULL).
* vo_opengl: add a generic EGL function loader functionwm42017-04-068-42/+40
| | | | | | | This is pretty trivial, but also quite annoying due to details like mismatching eglGetProcAddress() function signature (most callers just cast the function pointer), and ARM/Linux hacks. So move them all to one place.
* vo_opengl: fix windows build if GLES3 is detectedwm42017-04-061-0/+4
| | | | | | | | | With the recent GLES3 header detection, and if ANGLE is in the search path, the ANGLE headers will be used over the desktop GL ones. It appears the ANGLE headers do not include <windows.h>, which leads to the dxinterop code to fail building. Oops. Fix this by including <windows.h> is dxinterop is compiled in.
* vo_opengl: header_fixes.h: merge IOS GLES blockwm42017-04-061-18/+3
| | | | | | | | It appear