summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* 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: fix gray playbackwm42015-12-261-4/+3
| | | | | | Commit f24ba544 wasn't an equivalent change. (This shit needs some sort of automated tests.)
* vo_opengl: flip image if backend uses flipped renderingwm42015-12-251-0/+2
| | | | Should fix #2635 (untested).
* sub: find GBRP format automatically when rendering to RGBwm42015-12-243-11/+6
| | | | | | | | | | | | | | | | This removes the need to define IMGFMT_GBRAP, which fixes compilation with the current Libav release. This also makes it automatically pick up a GBRP format with the same bit width. (Unfortunately, it seems libswscale does not support conversion to AV_PIX_FMT_GBRAP16, so our code falls back to 8 bit, removing precision for video covered by subtitles in cases this code is used.) Also, when the source video is e.g. 10 bit YUV, upsample to 16 bit. Whether this is good or bad, it fixes behavior with alpha. Although I'm not sure if the alpha range is really correct ([0,2^16-1] vs. [0,255*256]). Keep in mind that libswscale doesn't even agree with the way we do it.
* 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.
* sub: better alpha blending when rendering to alpha surfaceswm42015-12-242-0/+2
| | | | | | | | | | | This actually treats destination alpha correctly, and gives much better results than before. I don't know if this is perfectly correct yet, though. Slight difference with vo_opengl behavior suggests it might not be. Note that this does not affect VOs with true alpha support. vo_opengl does not use this code at all, and does the alpha calculations in OpenGL instead.
* 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.
* vf_yadif: change defaultswm42015-12-211-0/+4
| | | | | | | | | | | | | | | | This is for the sake of command.c and the "deinterlace" option/property. Instead of forcing certain "better" defaults when inserting yadif, change the actual "yadif" defaults. I pondered not changing vf_yadif, and instead adding a trivial "yadif- auto" wrapper filter, which would merely have different defaults. But thinking about it, it doesn't make any sense for "deinterlace" to have different defaults from vf_yadif, with vf_yadif having the "worse" defaults. If someone wants the old behavior, the old behavior can be forced in a backward and forward compatible way by setting the suboptions. Fixes #2539 (kind of).
* 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.
* vaapi: add VP9 profile entiresBtbN2015-12-201-0/+7
|
* vf_vapoursynth: fix everythingwm42015-12-201-17/+13
| | | | | | | Broken by commit 0a0bb905. The changes to this filter were accidentally simply not tested, and it was obviously broken in a bunch of ways. Fixes #2616.
* video: switch from using display aspect to sample aspectwm42015-12-1925-166/+109
| | | | | | | | | | | | | | | | 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).
* vf: remove old config() callbackwm42015-12-199-96/+88
|
* vf: flush before reconfigwm42015-12-192-10/+1
|
* 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
| | | | | With --vo=opengl:alpha=yes, the Cocoa backend will now render alpha video without background.
* vo_opengl: fix "win" backend namewm42015-12-191-1/+1
| | | | | | | Although the source file is named w32.c, the backend name was "win" until recently. It was accidentally changed to "w32"; fix it. Fixes #2608 (the manual is correct).
* csputils: update MP_STEREO3D_COUNTPaul B Mahol2015-12-191-1/+1
| | | | | | | | | | This actually alows to playback alternating videos with mpv. Tested with actual file found in wild remuxed to mkv and changed props with following command: mkvpropedit /tmp/o.mkv --edit track:1 -s stereo-mode=13 Signed-off-by: Paul B Mahol <onemda@gmail.com>
* csputils: let mpv recognise frame sequenced 3D matroska videosPaul B Mahol2015-12-181-0/+2
| | | | | | Do actually such files exist? Signed-off-by: Paul B Mahol <onemda@gmail.com>
* vf_stereo3d: add alternating modesPaul B Mahol2015-12-181-0/+4
| | | | Signed-off-by: Paul B Mahol <onemda@gmail.com>
* vo_opengl: dxinterop: prevent crash after lost deviceJames Ross-Gowan2015-12-141-0/+13
| | | | | | | | | | | When a Direct3D 9Ex device fails to reset, it gets put into the lost state, so set the lost_device flag and don't attempt to present until the device moves out of that state. Failure to recreate the size- dependent objects should set lost_device as well, since we shouldn't try to present in that state. Also, it looks like I was too eager to remove code that sets priv members to NULL and I accidentally removed some that was needed.
* vo_opengl: dxinterop: prevent crash with 0-size windowJames Ross-Gowan2015-12-141-2/+3
| | | | | | Direct3D doesn't like 0-sized swapchain dimensions, even when those dimensions are automatically set. Manually set them to a size that isn't zero instead.
* vo_opengl: enable brightness/contrast controls for RGBwm42015-12-122-9/+14
| | | | | | | | | Why not. Also, instead of disabling hue/saturation for RGB, just don't apply them. (They don't make sense for conversion matrixes other than YUV, but I can't be bothered to keep the fine-grained disabling of UI controls either.)
* vo_opengl: add dxinterop backendJames Ross-Gowan2015-12-114-1/+677
| | | | | | | | | | | | | | | | | | | | | WGL_NV_DX_interop is widely supported by Nvidia and AMD drivers. It allows a texture to be shared between Direct3D and WGL, so that rendering can be done with WGL and presentation can be done with Direct3D. This should allow us to work around some persistent WGL issues, such as dropped frames with some driver/OS combos, drivers that buffer frames to increase performance at the cost of latency, and the inability to disable exclusive fullscreen mode when using WGL to render to a fullscreen window. The addition of a DX_interop backend might also enable some cool Direct3D-specific enhancements in the future, such as using the GetPresentStatistics API to get accurate frame presentation timestamps. Note that due to a driver bug, this backend is currently broken on Intel. It will appear to work as long as the window is not resized too often, but after a few changes of size it will be unable to share the newly created renderbuffer with GL. See: https://software.intel.com/en-us/forums/graphics-driver-bug-reporting/topic/562051
* vo_opengl: remove one more XYZ special-casewm42015-12-091-7/+2
| | | | The XYZ colorspace on XYZ pixfmt is enforced in some sanitation routine.
* vo_opengl: fix precision loss of fruit dithering matrixBin Jin2015-12-091-2/+9
| | | | | | | | | | With default setting, the matrix for fruit dithering requires 12 bits precision (values from 0/4096 to 4095/4096). But 16-bit float provides only 10 bits. In addition, when `dither-size-fruit=8` is set, 16 bits are required from the texture format. Fix this by attempting to use 16 bit integer texture first. This is still not precise, but should be better than using a half float.
* csputils: rename "yuv2rgb" functionswm42015-12-095-9/+9
| | | | | | They're not necessarily restricted to YUV aka YCbCr. vo_direct3d.c and demux_disc.c (DVD specific code) changes untested.
* csputils, vo_opengl: remove XYZ special case in color matrix retrievalwm42015-12-093-14/+8
| | | | | This just seems unnecessary. Refactor it a bit. There should be no functional changes.
* csputils: remove obscure int_bits matrix scalingwm42015-12-092-21/+10
| | | | | | | This has no reason to be there. Put the functionality into another function instead. While we're at it, also adjust for possible accuracy issues with high bit depth YUV (matters for rendering subtitles into screenshots only).
* vo_opengl: fix shader compilation regressionwm42015-12-082-4/+5
| | | | | | | | | | The recent LUT adjustment changes broke interpolation. The concatenation of the shader stages is a bit messy, and it seems like sampler_prelude is not a good place to add this macro. Always add the macro to every shader instead. (While this doesn't seem too elegant, this isn't too inelegant either, and goes these problems out of the way.)
* vo_opengl: enable colormatrix even for RGB inputwm42015-12-071-15/+13
| | | | Enables brightness/contrast controls, and handles gbrp10 correctly.
* vo_opengl: fix issues with some obscure pixel formatswm42015-12-075-11/+39
| | | | | | | | | | | | | | | | | | | The computation of the tex_mul variable was broken in multiple ways. This variable is used e.g. by debanding for moving expansion of 10 bit fixed-point input to normalized range to another stage of processing. One obvious bug was that the rgb555 pixel format was broken. This format has component_bits=5, but obviously it's already sampled in normalized range, and does not need expansion. The tex_mul-free code path avoids this by not using the colormatrix. (The code was originally designed to work around dealing with the generally complicated pixel formats by only using the colormatrix in the YUV case.) Another possible bug was with 10 bit input. It expanded the input by bringing the [0,2^10) range to [0,1], and then treating the expanded input as 16 bit input. I didn't bother to check what this actually computed, but it's somewhat likely it was wrong anyway. Now it uses mp_get_csp_mul(), and disables expansion when computing the YUV matrix.
* vo_opengl: decrease default lookup texture size to 64Bin Jin2015-12-071-2/+2
| | | | | | It turns out that with accurate lookup we can decrease the default size of texture now. Do it to compensate the performance loss introduced by the LUT_POS macro.
* vo_opengl: make LOOKUP_TEXTURE_SIZE configurableBin Jin2015-12-072-4/+5
|
* vo_opengl: Fix minor LUT sampling errorBin Jin2015-12-073-11/+22
| | | | | | Define a macro to correct the coordinate for lookup texture. Cache the corrected coordinate for 1D filter and use mix() to minimize the performance impact.
* filter_kernels: add warnings for potential LUT sampling errorBin Jin2015-12-071-0/+6
|
* cocoa: fix recent regressionwm42015-12-071-4/+6
| | | | | | | Commit 9db50c67 changed it so that the window title can now be a NULL string. Completely untested. Probably fixes #2570.
* win32: add option to set VO MMCSS profilewm42015-12-061-1/+5
| | | | This was requested.
* vo: get rid of vo_get_window_title()wm42015-12-066-34/+28
| | | | | | | | | | | It always was a weird artifact - VOCTRLs are meant _not_ to require special handling in the code that passes them through (like in vo.c). Removing it is also interesting to further reduce the dependency of backends on struct vo. Just get rid of it. Removing it is somewhat inconvenient, because in many situations the UI window is created after the first VOCTRL_UPDATE_WINDOW_TITLE. This means these backends have to store it in a new field in their own context.
* vd_lavc: fix avctx NULL checkswm42015-12-051-1/+4
| | | | | | If reinit after a fallback from hardware fails, this field can be NULL. The check in control() was broken due to a typo (found by Coverity), and decode() lacked the check entirely.
* vo_opengl_cb: avoid NULL pointer deref in corner caseswm42015-12-051-1/+2
| | | | Found by Coverity.
* vo_opengl: improve boundary check for polar filtersBin Jin2015-12-051-2/+2
| | | | | | | | | If the sampling point is placed diagonally, the radius difference could be as large as sqrt(2.0). And a loosened check with (radius - 1) would potentially include pixels out of the range. Fix the check to handle those corner case properly to avoid unnecessary texture lookup and improve the performance a bit.
* win32: remove dwmapi.dll dynamic loadingwm42015-12-041-34/+5
| | | | All Windows versions we support have this API.
* filter_kernels: remove redundant corner case checkBin Jin2015-12-041-1/+0
| | | | Actually, the original code would bypass some code path below.
* vo_opengl: require --enable-gpl3 for nnediwm42015-12-033-2/+31
| | | | | | | | | There are claims that nnedi3.c doesn't constitute its own new implementation, but is derived from existing HLSL or OpenCL shaders distributed under the LGPLv3 license. Until these are resolved, do the "correct" thing and require --enable-gpl3 to build nnedi.
* video: readd codec delay estimationwm42015-12-023-0/+18
| | | | | | | | | | | | | | | | | Approximately reverts commit 3ccac74d. This failed with some avi files, which do pseudo-VFR by sending packets with empty frames (or repeat frames, depending on point of view). Specifically, these packets are not 0 bytes, so they don't get skipped by libavformat, as with the usual VFR avi hack. Instead, the packet contains a VOP with vop_coded=0, so libavcodec will just return no frame. We could probably distinguish such skipped frames and delayed frames by explicitly measuring the codec delay by counting how long it takes to get the very first frame (and then treat skips as explicit drops), but we may as well simply reinstate the old code. To appease to at least one semi-broken case, do not enable this logic on the RPI, as the FFmpeg MMAL wrapper has arbitrary buffering (and MMAL itself is asynchronous).
* vo_opengl: fix backend=x11 on Intelwm42015-12-021-1/+1
| | | | "backend=x11" was resolved to x11_probe, which is unintentional.
* vo_opengl: add credits to NNEDI3 shaderBin Jin2015-12-021-0/+16
| | | | Add credits to several existing implementation of NNEDI3 shader.
* vo_opengl: enable NNEDI3 prescaler on OpenGL ES 3.0Bin Jin2015-12-023-14/+19
| | | | | | | | | | | | | | It turns out that both UBO and intBitsToFloat() are supported in OpenGL ES 3.0[1][2], enable them so that NNEDI3 prescaler can be used in a wider range of backends. Also fixes some implicit int-to-float conversions so that the shader actually compiles on GLES. Tested on Linux desktop (nvidia 358.16) with "es" sub-option. [1]: https://www.khronos.org/opengles/sdk/docs/man3/html/glGetUniformBlockIndex.xhtml [2]: https://www.khronos.org/opengles/sdk/docs/manglsl/docbook4/xhtml/intBitsToFloat.xml
* vo_opengl_cb: pass mpv_global to gl_videowm42015-11-301-1/+1
| | | | | | | | I guess gl_video->global was originally meant to be optional, but now it crashes in some newer code with vo_opengl_cb, which tries to init it with this field set to NULL (because normally it's not needed). Probably fixes #2542.
* vo: cosmetics: split functionwm42015-11-291-41/+56
| | | | | Split two huge chunks from the update_vsync_timing_after_swap() function. There should be no functional changes.
* vo: make using estimated FPS more conservativewm42015-11-291-0/+6
| | | | | | | | | | Don't use the average FPS if there are likely skipped vsyncs. Note that we don't use the normal skip detection, as it is unreliable if the real and assumed display FPS differ too much. The normal skip detection is still in place as it's more reliable in the case when vsync jitters much, but the display FPS is relatively exact. Further improvement over commit 41f2c653.
* vo: remove redundant and broken codewm42015-11-291-2/+0
| | | | This was stupid.
* vo_opengl: make tscale=mitchell:tscale-clamp the defaultwm42015-11-291-2/+4
| | | | Looks better than "oversample". tscale-clamp suggested by haasn.
* vo_opengl: warn if interpolation is enabled, but not display-syncwm42