summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* vo_rpi: add geometry handlingUros Vampl2016-02-051-10/+59
| | | | | | This makes it possible to set video size and position using the --geometry and/or --autofit options. It's also possible to switch between fullscreen/non-fullscreen playback during runtime.
* w32_common: switch to UniformResourceLocatorWwm42016-02-021-3/+5
| | | | | | | | This is the "unicode" version of it. It appears Firefox uses it now? I'm not sure if we still need to support the old variant, but hopefully not. Fixes #2782.
* vo_opengl: hwdec: use IDs for API, and log which backend is usedwm42016-02-017-17/+30
| | | | | | | Since there can be multiple backends for a single API (vaapi can use GLX or EGL), not logging the exact backend name is annoying. So add it. At the same time, there is no need to duplicate the name as used by the --hwdec options, so replace it with using the numeric hwdec API ID.
* x11: stop waiting for MapNotify when WM_STATE changesTracerneo2016-01-311-1/+3
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: do chroma merging in integer conversion stagewm42016-01-271-3/+13
| | | | | | This is a huge win when playing yuv420p10 on ANGLE - the 2 conversion stages for planes 1 and 2 and the chroma merging stage are all merged into one.
* vo_opengl: add precision qualifier to usampler2D on ANGLEwm42016-01-271-1/+1
| | | | | | | | GLES requires this. Some more common sampler types have default precisions, but not usampler2D. Newer ANGLE builds verify this more strictly than older builds, so this wasn't caught before. Fixes #2761.
* vo_opengl: replace tscale-interpolates-only with interpolation-thresholdwm42016-01-272-9/+12
| | | | | The previous approach was too naive, and can e.g. ruin playback if scheduling switches e.g. between 1 and 2 vsync per frame.
* vo_opengl: support 10 bit support with ANGLEwm42016-01-263-10/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | GLES does not support high bit depth fixed point textures for unknown reasons, so direct 10 bit input is not possible. But we can still use integer textures, which are supported by GLES 3.0. These store integer data just like the standard fixed point textures, except they are not normalized on sampling. They also don't support bilinear filtering, and require a special sampler ("usampler2D"). While these texture formats enable us to shuffle the data to the GPU, they're rather impractical with the requirements mentioned above and our current architecture. One problem is that most code assumes it can always use bilinear scaling (even if bilinear is never used when using appropriate scale/cscale options). Another is that we don't have any concept of running a function on a texture in an uniform way. So for now, run a simple conversion step through a FBO. The FBO will use the rgba16f format normally, which gives enough bits for 10 bit, and will at least gracefully degrade with higher depth input. This is bound to be much slower than a more "direct" method, but at least it works and is simple to implement. The odd change of function call order in init_video() is to properly disable "dumb mode" (no FBO use) if these texture formats are in use.
* vo_opengl: actually reset use_normalized_range fieldwm42016-01-261-3/+3
| | | | | | | | | This was never reset - absolutely can't be right. If the renderer somehow switches back to another codepath, it certainly has to be reset. Maybe this was hard to hit, as the normalization is going to be idempotent in simpler cases (like rendering RGBA input). Also get rid of the "merged" variable.
* vo_opengl: default to rgba16f FBOs on ANGLEwm42016-01-261-2/+5
| | | | | Although it has only 1 bit more precission than rgba10_a2, it was reported to improve the visual quality.
* vo_opengl: add tscale-interpolates-only sub-optionwm42016-01-252-1/+8
|
* vo_opengl: default scaler-resizes-only sub-option to yeswm42016-01-251-0/+2
| | | | | | | | Often requested. The main argument, that prominent scalers like sharpen change the image even if no scaling happens, disappeared anyway. ("sharpen", unsharp masking, is neither prominent nor a scaler anymore. This is an artifact from MPlayer, which fuses unsharp masking with bilinear scaling in order to make it single-pass, or so.)
* vo_opengl: rename custom shader entrypoint from sample to sample_pixelwm42016-01-251-3/+19
| | | | | | | "sample" is a reserved identifier at least in GLES ES. Suggestions for a better name than "sample_pixel" are still welcome. Fixes #2733.
* vo_opengl: vdpau: better handling of preemption recoverywm42016-01-251-1/+1
| | | | | If recovery from preemption is done successfully, continue normally. Only fail if it's preempted during init.
* video: remove some useless old RGB formatswm42016-01-254-33/+0
| | | | | | | | | | | | | Some VOs had support for these - remove them. Typically, these formats will have only some use in cases where using RGB software conversion with libswscale is faster than letting the VO/GPU do it (i.e. almost never). For the sake of testing this case, keep IMGFMT_RGB565. This is the least messy format, because it has no padding/alpha bits with unknown semantics. Note that decoding to these formats still works. We'll let libswscale repack the data to whatever the VO in use can take.
* vo_opengl: vaapi: don't expect EGL exts. to be in common ext. stringwm42016-01-221-2/+6
|
* vo_opengl: vaapi: reorganize platform entrypoints as tablewm42016-01-211-15/+20
|
* x11: get *current* XRandR screen configurationNils Schneider2016-01-201-1/+1
| | | | | | | | | | | | Only request the current screen configuration instead of polling for new screens, too. We're not interested in detecting any new screens as we're merely enumerating what is currently connected and configured. On some hardware (like mine) calling XRRGetScreenResources will stall X11 for about 10 to 20 seconds. This has annoyed me for a few months now and almost made me switch to VLC ;) Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: add KMS/DRM VAAPI hardware decoding interopwm42016-01-202-0/+21
| | | | Just requires glueing it together with Bloat Super Glue (tm).
* filter_kernels.h: adjust the licensewm42016-01-191-11/+5
| | | | | | Make it consistent with filter_kernels.c. See #2688.
* Change GPL/LGPL dual-licensed files to LGPLwm42016-01-1931-368/+217
| | | | | | | | | | | Do this to make the license situation less confusing. This change should be of no consequence, since LGPL is compatible with GPL anyway, and making it LGPL-only does not restrict the use with GPL code. Additionally, the wording implies that this is allowed, and that we can just remove the GPL part.
* Relicense some non-MPlayer source files to LGPL 2.1 or laterwm42016-01-1912-84/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
* vo_drm: fix CRTC usagerr-2016-01-181-1/+1
|
* cocoa: get fps only from dislaylinkStefano Pigozzi2016-01-141-8/+9
| | | | | In my tests, CGDisplayModeGetRefreshRate returns 24.0 even though the nominal one is set to 24000/1001. This is obviously not good for video.
* cocoa: add an observer for screenmode changeStefano Pigozzi2016-01-141-0/+26
|
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-1116-16/+16
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* vaapi: replace VA_STR_FOURCCwm42016-01-112-3/+3
|
* vo_opengl: generic semi-planar supportwm42016-01-071-9/+10
| | | | | | Should take care of the planned FFmpeg AV_PIX_FMT_P010 addition. (This will eventually be needed when doing HEVC Main 10 decoding with DXVA2 copyback.)
* filter_kernels: improve the gaussian functionNiklas Haas2016-01-071-2/+2
| | | | | | | | | | | | | | | | | | | | | Commit 3909e4cd ended up losing the ability to tune the gaussian window, which this commit trivially reintroduces. The constant scaling factor (present in the code copied from glumpy) also goes against filter_kernels.c conventions, which is that f(0.0) = 1 (and the invoking code takes care of normalization), and has been removed. The values of this new gaussian function corresponds to different functions when compared against the old version. To translate the old values p1 to the new values p2 requires solving 2^(e/p1) = e^(2/p2) or p2 = p1 * 2/(e * ln(2)) ≈ p1 * 1.0615 In other words, to get the old default in the new function requires setting scale-param1 to 1.0615. (The new function is *slightly* sharper by default) (Though most users should probably not notice the change)
* filter_kernels: relicense under BSDwm42016-01-071-11/+5
| | | | | | | | | | | To get a uniform license for this file, relicense the mpv parts to BSD as well. But leave the door open for a later change to LGPL. (All non-Glumpy code was written within mpv, and all mpv authors have agreed to LGPL relicensing.) Closes #2688.
* vo_opengl: hwdec_vdpau: relicense under LGPLwm42016-01-071-7/+7
| | | | All code was written by myself.
* vo_opengl: video.h: fix licensewm42016-01-071-7/+8
| | | | | This is a mistake coming from commit 6ef06aa1: it accidentally changed the license from GPL/LGPL dual to GPL only.
* vo_opengl: hwdec_vaegl: change license to LGPL 2.1wm42016-01-071-9/+7
| | | | | | | | | This file claims to be based on the "MPlayer VA-API patch", but this is untrue. Only some glue code was copied from hwdec_vaglx.c, and this glue code was never in MPlayer or the MPlayer VA-API patch in any form, and instead part of the mpv-original way we do hardware decoding OpenGL interop. The EGL interop method didn't exist at the time the MPlayer VA-API patch was created either.
* filter_kernels: replace AGG-based codewm42016-01-061-71/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit replaces code based on AGG, taken from this source file: http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h The intention is that filter_kernels.c can be relicensed to LGPL or BSD. Because the AGG author died, full replacement is the only way to achieve it. This affects only some filter functions. These are exclusively mathematical functions for computing filter coefficients. (Other parts in filter_kernel.c were originally written by me, with heavy additions and refactoring done by other mpv contributors.) While the code is mostly just well-known mathematical formulas written down in C form, AGG copyright could perhaps be claimed anyway. To remove the AGG code, I replaced it with the filter functions from: https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py These functions conveniently compute exactly the same thing in mpv, Glumpy, AGG (and about anything that will filter images using the same mathematical principles). First I ported the Python code in the file to C. Then I replaced all functions in filter_kernels.c with this code that could be replaced. Then I investigated whether the remaining functions were based on AGG code and took appropriate action: hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(), spline16(), spline36(), gaussian(), sinc() were taken straight from Glumpy. For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit 586dc557 for unknown reasons. gaussian() loses its filter parameter for some reason. (Well, who cares, not my problem.) The really awkward thing is that the text for hanning() and hamming() does not change. In theory these functions are now based on Glumpy code, but it seems like this can be neither proven nor denied. (The same happened in some other cases with at least a few lines of code.) sphinx() was added in commit 586dc557, and looks suspiciously like sinc() as well. Replace the first 3 lines of the body with the ported function (of which 2 lines do not change; the first uses code only in mpv, and the second is just "return 1.0;"). The 4th line is only similar on an abstract level (and that because of the mathematical relation between these functions). Although the original sinc() was probably used as template for it, with the other lines replaced, I don't think you could make the claim that it falls under AGG copyright. jinc() was added in commit 26baf5b9, but the code for it might be based on sinc(). Rewrite it based on the "new" sinc(). Some of the same remarks as with sphinx() apply. cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware, with the default parameters it's called "the" Mitchell-Netravali filter, but in mpv this function is used to generate a whole group of filters.) spline64() was added in commit a8b67c66, and was probably derived from spline36(). Re-derive it from the "new" spline36(). triangle() could be considered derived from the original bilinear(). This is this in the original commit: static double bilinear(kernel *k, double x) { return 1.0 - x; } This _might_ be based on AGG's image_filter_bilinear: struct image_filter_bilinear { static double radius() { return 1.0; } static double calc_weight(double x) { return 1.0 - x; } }; Considering that the "framework" was written by me, and the only part from AGG taken is "return 1.0 - x;", and this part is trivial and was later thoroughly replaced, this is probably not under the AGG copyright. I'm hoping this doesn't introduce regressions. But the main focus is not being productive anyway, and I didn't rigorously check unintended changes in functionality.
* vo_rpi: handle rotationwm42016-01-051-1/+14
| | | | | Since the MMAL video renderer component supports exactly what we need, it's pretty simple.
* vo_rpi: work around firmware oddness leading to incorrect video rectwm42016-01-051-2/+4
| | | | | | | | | | | Apparently, the firmware will ignore pixel_x/pixel_y if the numeric value of them gets too high (even if they indicate square pixel aspect ratio). Even worse, the destination rectangle is ignored completely, and the video frame is simply stretched to the screen. I suspect this is an overflow or weird sanity check within the firmware. Work it around by limiting the fields to 16000, which is an arbitrary but apparently working limit.
* vo_opengl: fix operation on GLES 2.0wm42016-01-041-2/+2
| | | | | | | | | GLSL in GLES 2.0 did not have line continuation in its preprocessor. This broke shader compilation. It also broke subtitle rendering in vo_rpi, which reuses some of the OpenGL code. Line continuation was finally added in GLES 3.0, which is perhaps the reason why ANGLE accepted it.
* vo_opengl: reset nnedi3 weights properlyBin Jin2016-01-031-0/+1
| | | | Fixes #2661
* x11: silence xdg-screensaver failure messagewm42016-01-031-2/+2
|
* wayland: fix typo in error messageAlessandro Ghedini2015-12-271-1/+1
|
* vo_rpi: fix previous commitwm42015-12-261-1/+1
| | | | Meh. Fixes #2639.
* vo_rpi: fix compilationwm42015-12-262-6/+2
| | | | | | | | | Untested, but should be fine. Broken by commit 0a0bb905. Also fix the include statement in context_rpi.c, which caused another compilation failure. Also untested. (Because I'm lazy.) Fixes #2638.
* filter_kernels: use more precise parameters for robidoux filterswm42015-12-261-4/+10
| | | | See #2637.
* vo_opengl: flip image if backend uses flipped renderingwm42015-12-251-0/+2
| | | | Should fix #2635 (untested).
* vo_opengl: fix operation on GLSL versions earlier than 1.30wm42015-12-241-1/+1
| | | | | GLSL below version 1.30 does not support mix() with a boolean interpolation value. Use ?: instead. Untested, but probably works.
* vo_opengl: fall back to gcc thread local storagewm42015-12-231-1/+7
| | | | | | | | | | | | gcc 4.8 does not support C11 thread local storage. This is a bit annoying, so add a hack to use the gcc specific __thread extension if C11 TLS is not available. (This is used for the extremely silly mpv-internal way hwdec modules access some platform specific handles. Disabling it simply made hwdec_vaegl.c always fail initialization.) Fixes #2631.
* vo_opengl: blend transparent video against tiles by defaultwm42015-12-221-4/+9
| | | | | | | | | | | Add a "blend-tiles" choice to the "alpha" sub-option. This is pretty simplistic and uses the GL raster position to derive the tiles. A weird consequence is that using --vo=opengl and --vo=opengl-hq gives different scaling behavior (screenspace pixel size vs. source video pixel size 16x16 tiles), but it seems we don't have easy access to the original texture coordinates. Using the rasterpos is probably simpler. Make this option the default.
* vo_opengl: x11: fix alpha windowswm42015-12-201-2/+3
| | | | | | | long is 64 bits on x86_64 on Linux, which means the check for the corner case of computing the depth mask is wrong. Also, X11 compositors seem to expect premultiplied alpha.
* video: switch from using display aspect to sample aspectwm42015-12-197-23/+15
| | | | | | | | | | | | | | | | MPlayer traditionally always used the display aspect ratio, e.g. 16:9, while FFmpeg uses the sample (aka pixel) aspect ratio. Both have a bunch of advantages and disadvantages. Actually, it seems using sample aspect ratio is generally nicer. The main reason for the change is making mpv closer to how FFmpeg works in order to make life easier. It's also nice that everything uses integer fractions instead of floats now (except --video-aspect option/property). Note that there is at least 1 user-visible change: vf_dsize now does not set the display size, only the display aspect ratio. This is because the image_params d_w/d_h fields did not just set the display aspect, but also the size (except in encoding mode).
* vo_opengl: disable pbo by defaults for opengl-hqwm42015-12-191-1/+0
| | | | Too many problems.
* vo_opengl: handle alpha with odd bit widths toowm42015-12-191-4/+8
| | | | | | | | | | | | | | | Since alpha isn't pulled through the colormatrix (maybe it should?), we reject alpha formats with odd sizes, such as yuva444p10. But the awful tex_mul path in vo_opengl does this anyway (at some points even explicitly), which means there will be a subtle difference in handling of 16 bit yuv alpha formats. Make it consistent and always apply the range adjustment to the alpha component. This also means odd sizes like 10 bit are supported now. This assumes alpha uses the same "shifted" range as the yuv color channels for depths larger than 8 bit. I'm not sure whether this is actually the case.
* vo_opengl: cocoa: output premultiplied alphawm42015-12-193-0/+4
| | | | | Which is apparently what is expected here. (I'm pretty sure X11 compositors want stright alpha, so 2 code paths are needed.)
* vo_opengl: prefix per-backend source files with context_wm42015-12-1911-1/+1
|
* vo_opengl: split backend code from common.c to context.cwm42015-12-1914-275/+343
| | | | | | | | Now common.c only contains the code for the function loader, while context.c contains the backend loader/dispatcher. Not calling it "backend.c", because the central struct is called MPGLContext.
* vo_opengl: x11egl: retrieve framebuffer depthwm42015-12-193-0/+47
| | | | | | | | | | This is used for dithering, although I'm not aware of anyone who got higher than 8 bit depth support to work on Linux. Also put this into egl_helpers.c. Since EGL is pseudo-portable at best I have no hope that the EGL context creation code in all the backends can be fully shared. But some self-contained functionality can definitely be shared.
* vo_opengl: refactor how framebuffer depth is passed from backendswm42015-12-197-30/+22
| | | | | | | | | | | Store the determined framebuffer depth in struct GL instead of MPGLContext. This means gl_video_set_output_depth() can be removed, and also justifies adding new fields describing framebuffer/backend properties to struct GL instead of having to add more functions just to shovel the information around. Keep in mind that mpgl_load_functions() will wipe struct GL, so the new fields must be set before calling it.
* vo_opengl: cocoa: implement alpha window supportwm42015-12-192-2/+11
|