path: root/
Commit message (Collapse)AuthorAgeFilesLines
* wayland_common: update to stable xdg-shellEmmanuel Gil Peyrot2018-04-291-5/+5
| | | | | This removes support for older compositors using the unstable version, but those will still use Xwayland by default, so not a big loss.
* vo: move DR helper code to a separate source filewm42018-04-291-0/+1
| | | | | So it can be reused by vo_libmpv.c, which needs to use it in a slightly different way.
* vo_gpu: hwdec: Use ffnvcodec to load CUDA symbolsPhilip Langdale2018-04-151-1/+0
| | | | | | The CUDA dynamic loader was broken out of ffmpeg into its own repo and package. This gives us an opportunity to re-use it in mpv and remove our custom loader logic.
* build: fixup vendored wayland protocols with variantsJan Ekström2018-04-151-6/+8
| | | | | | Utilize the SRC variable for this to get a built-in relative path. Can be tested by adding `--variant="random_string"` to configure and build.
* build: fix swift build with waf 1.8.4Akemi2018-03-111-2/+2
| | | | | | | with older waf versions a node doesn't return an absolute path but just a relative one. fix this by explicitly requesting an absolute one. Fixes #5604
* wscript: also install render API related headersNiklas Haas2018-03-041-1/+2
| | | | Omitted from b0371214
* build: restore alphabetical sort order of file listswm42018-02-281-71/+71
* client API: deprecate opengl-cb API and introduce a replacement APIwm42018-02-281-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | The purpose of the new API is to make it useable with other APIs than OpenGL, especially D3D11 and vulkan. In theory it's now possible to support other vo_gpu backends, as well as backends that don't use the vo_gpu code at all. This also aims to get rid of the dumb mpv_get_sub_api() function. The life cycle of the new mpv_render_context is a bit different from mpv_opengl_cb_context, and you explicitly create/destroy the new context, instead of calling init/uninit on an object returned by mpv_get_sub_api(). In other to make the render API generic, it's annoyingly EGL style, and requires you to pass in API-specific objects to generic functions. This is to avoid explicit objects like the internal ra API has, because that sounds more complicated and annoying for an API that's supposed to never change. The opengl_cb API will continue to exist for a bit longer, but internally there are already a few tradeoffs, like reduced thread-safety. Mostly untested. Seems to work fine with mpc-qt.
* build: fix dependency check on macOSAkemi2018-02-161-0/+7
| | | | | | | 235eb60 added a needed linking flag, but too soon. this lead to some of the configure checks to fail. add the flag in our build phase. Fixes #5528
* build: fix linking libmpv when swift features are builtAkemi2018-02-131-0/+1
| | | | | | | | the swift object file wasn't linked when libmpv was linked, which resulted in a missing symbol error. add the swift object to the linking list for libmpv too. Fixes #5522
* build: drop support for SDL1wm42018-02-131-1/+0
| | | | | For some reason it was supported for ao_sdl because we've only used SDL1 API.
* cocoa-cb: initial implementation via opengl-cb APIAkemi2018-02-121-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
* audio: move to decoder wrapperwm42018-01-301-1/+0
| | | | | | | | | | | | | | | | Use the decoder wrapper that was introduced for video. This removes all code duplication the old audio decoder wrapper had with the video code. (The audio wrapper was copy pasted from the video one over a decade ago, and has been kept in sync ever since by the power of copy&paste. Since the original copy&paste was possibly done by someone who did not answer to the LGPL relicensing, this should also remove all doubts about whether any of this code is left, since we now completely remove any code that could possibly have been based on it.) There is some complication with spdif handling, and a minor behavior change (it will restrict the list of codecs to spdif if spdif is to be used), but there should not be any difference in practice.
* video: make decoder wrapper a filterwm42018-01-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes a source filter. vd.h mostly disappears, because mp_filter takes care of the dataflow, but its remains are in struct mp_decoder_fns. One goal is to simplify dataflow by letting the filter framework handle it (or more accurately, using its conventions). One result is that the decode calls disappear from video.c, because we simply connect the decoder wrapper and the filter chain with mp_pin_connect(). Another goal is to eventually remove the code duplication between the audio and video paths for this. This commit prepares for this by trying to make f_decoder_wrapper.c extensible, so it can be used for audio as well later. Decoder framedropping changes a bit. It doesn't seem to be worse than before, and it's an obscure feature, so I'm content with its new state. Some special code that was apparently meant to avoid dropping too many frames in a row is removed, though. I'm not sure how the source code tree should be organized. For one, video/decode/vd_lavc.c is the only file in its directory, which is a bit annoying.
* player: replace old lavfi wrapper with new filter codewm42018-01-301-1/+0
| | | | | lavfi.c is not necessary anymore, because f_lavfi.c (which was actually converted from it) can be used now.
* audio: rewrite filtering glue codewm42018-01-301-9/+5
| | | | Use the new filtering code for audio too.
* video: rewrite filtering glue codewm42018-01-301-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Get rid of the old vf.c code. Replace it with a generic filtering framework, which can potentially handle more than just --vf. At least reimplementing --af with this code is planned. This changes some --vf semantics (including runtime behavior and the "vf" command). The most important ones are listed in interface-changes. vf_convert.c is renamed to f_swscale.c. It is now an internal filter that can not be inserted by the user manually. f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is conceptually easy, but a big mess due to the data flow changes). The existing filters are all changed heavily. The data flow of the new filter framework is different. Especially EOF handling changes - EOF is now a "frame" rather than a state, and must be passed through exactly once. Another major thing is that all filters must support dynamic format changes. The filter reconfig() function goes away. (This sounds complex, but since all filters need to handle EOF draining anyway, they can use the same code, and it removes the mess with reconfig() having to predict the output format, which completely breaks with libavfilter anyway.) In addition, there is no automatic format negotiation or conversion. libavfilter's primitive and insufficient API simply doesn't allow us to do this in a reasonable way. Instead, filters can use f_autoconvert as sub-filter, and tell it which formats they support. This filter will in turn add actual conversion filters, such as f_swscale, to perform necessary format changes. vf_vapoursynth.c uses the same basic principle of operation as before, but with worryingly different details in data flow. Still appears to work. The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are heavily changed. Fortunately, they all used refqueue.c, which is for sharing the data flow logic (especially for managing future/past surfaces and such). It turns out it can be used to factor out most of the data flow. Some of these filters accepted software input. Instead of having ad-hoc upload code in each filter, surface upload is now delegated to f_autoconvert, which can use f_hwupload to perform this. Exporting VO capabilities is still a big mess (mp_stream_info stuff). The D3D11 code drops the redundant image formats, and all code uses the hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a big mess for now. f_async_queue is unused.
* hwdec: detach d3d and d3d9 hwaccel from anglemyfreeer2018-01-251-3/+3
| | | | Fix
* vo_gpu: hwdec_dxva2dxgi: initial implementationJames Ross-Gowan2018-01-061-0/+1
| | | | | | | | | | | | | This enables DXVA2 hardware decoding with ra_d3d11. It should be useful for Windows 7, where D3D11VA is not available. Images are transfered from D3D9 to D3D11 using D3D9Ex surface sharing[1]. Following Microsoft's recommendations, it uses a queue of shared surfaces, similar to Microsoft's ISurfaceQueue. This will hopefully prevent surface sharing from impacting parallelism and allow multiple D3D11 frames to be in-flight at once. [1]:
* build: use unicode codepage in windresRicardo Constantino2018-01-011-1/+2
* vo_gpu: win: remove exclusive-fullscreen detection hackJames Ross-Gowan2017-12-201-1/+0
| | | | | | | | | | | | | | | | | | | | | This hack was part of a solution to VSync judder in desktop OpenGL on Windows. Rather than using blocking-SwapBuffers(), mpv could use DwmFlush() to wait for the image to be presented by the compositor. Since this would only work while the compositor was running, and the compositor was silently disabled when OpenGL entered exclusive fullscreen mode, mpv needed a way to detect exclusive fullscreen mode. The code that is being removed could detect exclusive fullscreen mode by checking the state of an undocumented mutex using undocumented native API functions, but because of how fragile it was, it was always meant to be removed when a better solution for accurate VSync in OpenGL was found. Since then, mpv got the dxinterop backend, which uses desktop OpenGL but has accurate VSync. It also got a native Direct3D 11 backend, which is a viable alternative to OpenGL on Windows. For people who are still using desktop OpenGL with WGL, there shouldn't be much of a difference, since mpv can use other API functions to detect exclusive fullscreen.
* vf_buffer: remove this filterwm42017-12-121-1/+0
| | | | | It has been deprecated for a while and is 100% useless. It was forgotten in the recent filter purge. Get rid of it.
* osdep: add poll shim for macOSDrew DeVault2017-12-091-0/+1
| | | | | | | This implements a poll-compatible interface, backed by select on macOS, suitable for polling on device files - which are not supported by macOS's implementation of poll. This is a (long-standing) bug in macOS, so hopefully we can eventually remove this shim.
* vd_lavc: drop mediacodec direct rendering support temporarilywm42017-12-011-1/+0
| | | | | | | | | | | | The libavcodec mediacodec support does not conform to the new hwaccel APIs yet. It has been agreed uppon that this glue code can be deleted for now, and support for it will be restored at a later point. Readding would require that it supports the AVCodecContext.hw_device_ctx API. The hw_device_ctx would then contain the surface ID. vo_mediacodec_embed would actually perform the task of creating vo.hwdec_devs and adding a mp_hwdec_ctx, whose av_device_ref is a AVHWDeviceContext containing the android surface.
* video: move d3d.c out of decode sub directorywm42017-12-011-1/+1
| | | | | | It makes more sense to have it in the general video directory (along with vdpau.c and vaapi.c), since the decoder source files don't even access it anymore.
* vd_lavc: delete hw_d3d11va.c/hw_dxva2.c and merge leftoverswm42017-12-011-2/+0
| | | | | | Like with all hwaccels, there's little that is actually specific to decoding (which has been moved away anyway), and what is left are declarations (which will also go away soon).
* vo_gpu: remove hwdec_vaglx interopwm42017-11-301-1/+0
| | | | | | This has stopped being useful a long time ago, and it's the only GPL source file in the vo_gpu source directories. Recently it wasn't even loaded at all, unless you forced loading it.
* build: fix LGPL build with ALSA enabledwm42017-11-291-3/+3
| | | | | | | Oops. This is part of the TV code, for which we didn't make any effort to relicense. But files were always built, because they didn't depend on the common TV code. (The HAVE_GPL in the source file exposed this by making the build fail.)
* af: remove deprecated audio filterswm42017-11-291-4/+0
| | | | | | | | | | | | These couldn't be relicensed, and won't survive the LGPL transition. The other existing filters are mostly LGPL (except libaf glue code). This remove the deprecated pan option. I guess it could be restored by inserting a libavfilter filter (if there's one), but for now let it be gone. This temporarily breaks volume control (and things related to it, like replaygain).
* vf_sub, vf_format: change license to LGPLwm42017-11-291-2/+2
| | | | | | | | | | | | They were added to the "to deleted" list and never relicensed, because I thought I'd delete them early. But it's possible that they'll stay in mpv for a longer time, so relicense them. Still leaving them as deprecated and scheduled for removal, so they can still be dropped once there is a better way to deal with them, if they get annoying, or if a better mechanism is found that makes them unnecessary. All contributors agreed. There are some minor changes by people who did not agree, but these are all not relevant or have been removed.
* vf: remove most GPL video filterswm42017-11-291-13/+1
| | | | | | | | | | | | | Almost all of them had their guts removed and replaced by libavfilter long ago, but remove them anyway. They're pointless and have been scheduled for deprecation. Still leave vf_format (because we need it in some form) and vf_sub (not sure). This will break some builtin functionality: lavfi yadif defaults are different, auto rotation and stereo3d downconversion are broken. These might be fixed later.
* vf: add vf_convert as interim replacement for vf_scalewm42017-11-291-0/+1
| | | | | | | | | | | We want to drop vf_scale, but we still need a way to auto convert between imgfmts. In particular, vf.c will auto insert the "scale" filter if the VO doesn't support a pixfmt. To avoid chaos, create a new vf_convert.c filter, based on vf_scale.c, but without the unrelicensed code parts. In particular, this filter does not do scaling and has no options. It merely converts from one imgfmt to another, if needed.
* vo_gpu: d3d11: initial implementationJames Ross-Gowan2017-11-071-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a new RA/vo_gpu backend that uses Direct3D 11. The GLSL generated by vo_gpu is cross-compiled to HLSL with SPIRV-Cross. What works: - All of mpv's internal shaders should work, including compute shaders. - Some external shaders have been tested and work, including RAVU and adaptive-sharpen. - Non-dumb mode works, even on very old hardware. Most features work at feature level 9_3 and all features work at feature level 10_0. Some features also work at feature level 9_1 and 9_2, but without high-bit- depth FBOs, it's not very useful. (Hardware this old is probably not fast enough for advanced features anyway.) Note: This is more compatible than ANGLE, which requires 9_3 to work at all (GLES 2.0,) and 10_1 for non-dumb-mode (GLES 3.0.) - Hardware decoding with D3D11VA, including decoding of 10-bit formats without truncation to 8-bit. What doesn't work / can be improved: - PBO upload and direct rendering does not work yet. Direct rendering requires persistent-mapped PBOs because the decoder needs to be able to read data from images that have already been decoded and uploaded. Unfortunately, it seems like persistent-mapped PBOs are fundamentally incompatible with D3D11, which requires all resources to use driver- managed memory and requires memory to be unmapped (and hence pointers to be invalidated) when a resource is used in a draw or copy operation. However it might be possible to use D3D11's limited multithreading capabilities to emulate some features of PBOs, like asynchronous texture uploading. - The blit() and clear() operations don't have equivalents in the D3D11 API that handle all cases, so in most cases, they have to be emulated with a shader. This is currently done inside ra_d3d11, but ideally it would be done in generic code, so it can take advantage of mpv's shader generation utilities. - SPIRV-Cross is used through a NIH C-compatible wrapper library, since it does not expose a C interface itself. The library is available here: - The D3D11 context could be made to support more modern DXGI features in future. For example, it should be possible to add support for high-bit-depth and HDR output with DXGI 1.5/1.6.
* videotoolbox: use generic code for dummy hwdevice initwm42017-10-311-1/+0
| | | | | And move the remaining code (just 2 struct constant definitions) to vd_lavc.c.
* Add DRM_PRIME Format Handling and Display for RockChip MPP decodersLionel CHAZALLON2017-10-231-0/+3
| | | | | | | | | | | This commit allows to use the AV_PIX_FMT_DRM_PRIME newly introduced format in ffmpeg that allows decoders to provide an AVDRMFrameDescriptor struct. That struct holds dmabuf fds and information allowing zerocopy rendering using KMS / DRM Atomic. This has been tested on RockChip ROCK64 device.
* stats: add documentationJulian2017-10-091-1/+1
| | | | stats.rst is heavily based on osc.rst
* lua: integrate stats.lua scriptJulian2017-10-091-1/+1
| | | | | | | | | Signed-off-by: wm4 <wm4@nowhere> Rename --stats to --load-stats-overlay and add an entry to options.rst over the original commit. Signed-off-by: wm4 <wm4@nowhere>
* vo_gpu: add android opengl backendAman Gupta2017-10-091-0/+1
| | | | | | | | | | At the moment, rendering on Android requires ``--vo=opengl-cb`` and a lot of java<->c++ bridging code to receive the receive and react to the render callback in java. Performance also suffers with opengl-cb, due to the overhead of context switching in JNI. With this patch, Android can render using ``--vo=gpu --gpu-context=android`` (after setting ``--wid`` to point to an android.view.Surface on-screen).
* vo: add mediacodec_embed output driverAman Gupta2017-10-091-0/+1
| | | | | Allows rendering IMGFMT_MEDIACODEC frames directly onto an android.view.Surface
* hwdec: rename mediacodec to mediacodec-copyAman Gupta2017-10-091-0/+1
* wayland_common: rewrite from scratchRostislav Pehlivanov2017-10-031-0/+23
| | | | | | | | | | | | The wayland code was written more than 4 years ago when wayland wasn't even at version 1.0. This commit rewrites everything in a more modern way, switches to using the new xdg v6 shell interface which solves a lot of bugs and makes mpv tiling-friedly, adds support for drag and drop, adds support for touchscreens, adds support for KDE's server decorations protocol, and finally adds support for the new idle-inhibitor protocol. It does not yet use the frame callback as a main rendering loop driver, this will happen with a later commit.
* vo_wayland: removeRostislav Pehlivanov2017-10-031-3/+0
| | | | | This VO was buggy and never worked correctly. Like with wayland_common, it needs to be rewritten from scratch.
* vaapi: change license to LGPLwm42017-09-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | Originally mpv vaapi support was based on the MPlayer-vaapi patches. These were never merged in upstream MPlayer. The license headers indicated they were GPL-only. Although the actual author agreed to relicensing, the company employing him to write this code did not, so the original code is unusable to us. Fortunately, vaapi support was refactored and rewritten several times, meaning little code is actually left. The previous commits removed or moved that to GPL-only code. Namely, vo_vaapi.c remains GPL-only. The other code went away or became unnecessary mainly because libavcodec itself gained the ability to manage the hw decoder, and libavutil provides code to manage vaapi surfaces. We also changed to mainly using EGL interop, making any of the old rendering code unnecessary. hwdec_vaglx.c is still GPL. It's possibly relicensable, because much of it was changed, but I'm not too sure and further investigation would be required. Also, this has been disabled by default for a while now, so bothering with this is a waste of time. This commit simply disables it at compile time as well in LGPL mode.
* vo_gpu: vulkan: add support for WindowsJames Ross-Gowan2017-09-281-0/+1
* video: remove old videotoolbox supportwm42017-09-261-1/+0
| | | | | Like as in previous commits, you need a very recent FFmpeg (probably git master).
* video: drop old D3D11/DXVA2 supportwm42017-09-261-1/+0
| | | | | | | | | Now you need FFmpeg git, or something. This also gets rid of the last real use of gpu_memcpy(). libavutil does that itself. (vaapi.c still used it, but it was essentially unused, because the code path isn't really in use anymore. It wasn't even included due to the d3d-hwaccel dependency in wscript.)
* video: drop old cuda/cuvid hwaccelwm42017-09-261-1/+0
| | | | Just use FFmpeg 3.3 (or whatever it was) to get Cuvid support.
* vo_gpu: vulkan: add support for waylandRostislav Pehlivanov2017-09-261-0/+1
* vo_gpu: vulkan: generalize SPIR-V compilerNiklas Haas2017-09-261-0/+3
| | | | | | | | | | | | | | In addition to the built-in nvidia compiler, we now also support a backend based on libshaderc. shaderc is sort of like glslang except it has a C API and is available as a dynamic library. The generated SPIR-V is now cached alongside the VkPipeline in the cached_program. We use a special cache header to ensure validity of this cache before passing it blindly to the vulkan implementation, since passing invalid SPIR-V can cause all sorts of nasty things. It's also designed to self-invalidate if the compiler gets better, by offering a catch-all `int compiler_version` that implementations can use as a cache invalidation marker.
* vo_gpu: vulkan: initial implementationNiklas Haas2017-09-261-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This time based on ra/vo_gpu. 2017 is the year of the vulkan desktop! Current problems / limitations / improvement opportunities: 1. The swapchain/flipping code violates the vulkan spec, by assuming that the presentation queue will be bounded (in cases where rendering is significantly faster than vsync). But apparently, there's simply no better way to do this right now, to the point where even the stupid cube.c examples from LunarG etc. do it wrong. (cf. 2. The memory allocator could be improved. (This is a universal constant) 3. Could explore using push descriptors instead of descriptor sets, especially since we expect to switch descriptors semi-often for some passes (like interpolation). Probably won't make a difference, but the synchronization overhead might be a factor. Who knows. 4. Parallelism across frames / async transfer is not well-defined, we either need to use a better semaphore / command buffer strategy or a resource pooling layer to safely handle cross-frame parallelism. (That said, I gave resource pooling a try and was not happy with the result at all - so I'm still exploring the semaphore strategy) 5. We aggressively use pipeline barriers where events would offer a much more fine-grained synchronization mechanism. As a result of this, we might be suffering from GPU bubbles due to too-short dependencies on objects. (That said, I'm also exploring the use of semaphores as a an ordering tactic which would allow cross-frame time slicing in theory) Some minor changes to the vo_gpu and infrastructure, but nothing consequential. NOTE: For safety, all use of asynchronous commands / multiple command pools is currently disabled completely. There are some left-over relics of this in the code (e.g. the distinction between dev_poll and pool_poll), but that is kept in place mostly because this will be re-extended in the future (vulkan rev 2). The queue count is also currently capped to 1, because of the lack of cross-frame semaphores means we need the implicit synchronization from the same-queue semantics to guarantee a correct result.
* android: posix_spawn(p) replacementsfan52017-09-221-0/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* build: make vo_gpu + infrastructure non-optionalwm42017-09-221-11/+11
| | | | | Also readd the the error message for when no GL backends are found (why was this removed?).
* vo_gpu: convert windows/osx hwdecs/contexts to new APIJames Ross-Gowan2017-09-211-9/+9
* vo_opengl: refactor into vo_gpuNiklas Haas2017-09-211-23/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is done in several steps: 1. refactor MPGLContext -> struct ra_ctx 2. move GL-specific stuff in vo_opengl into opengl/context.c 3. generalize context creation to support other APIs, and add --gpu-api 4. rename all of the --opengl- options that are no longer opengl-specific 5. move all of the stuff from opengl/* that isn't GL-specific into gpu/ (note: opengl/gl_utils.h became opengl/utils.h) 6. rename vo_opengl to vo_gpu 7. to handle window screenshots, the short-term approach was to just add it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to ra itself (and vo_gpu altered to compensate), but this was a stop-gap measure to prevent this commit from getting too big 8. move ra->fns->flush to ra_gl_ctx instead 9. some other minor changes that I've probably already forgotten Note: This is one half of a major refactor, the other half of which is provided by rossy's following commit. This commit enables support for all linux platforms, while his version enables support for all non-linux platforms. Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the --opengl- options like --opengl-early-flush, --opengl-finish etc. Should be a strict superset of the old functionality. Disclaimer: Since I have no way of compiling mpv on all platforms, some of these ports were done blindly. Specifically, the blind ports included context_mali_fbdev.c and context_rpi.c. Since they're both based on egl_helpers, the port should have gone smoothly without any major changes required. But if somebody complains about a compile error on those platforms (assuming anybody actually uses them), you know where to complain.
* build: add preliminary LGPL modewm42017-09-211-15/+15
| | | | | | | See "Copyright" file for caveats. This changes the remaining "almost LGPL" files to LGPL, because we think that the conditions the author set for these was finally fulfilled.
* audio: make libaf derived code optionalwm42017-09-211-13/+13
| | | | | | | | | | | | | | | This code could not be relicensed. The intention was to write new filter code (which could handle both audio and video), but that's a bit of work. Write some code that can do audio conversion (resampling, downmixing, etc.) without the old audio filter chain code in order to speed up the LGPL relicensing. If you build with --disable-libaf, nothing in audio/filter/* is compiled in. It breaks a few features, such as --volume, --af, pitch correction on speed changes, replaygain. Most likely this adds some bugs, even if --disable-libaf is not used. (How the fuck does EOF notification work again anyway?)
* audio: move libswresample wrapper out of audio filter codewm42017-09-211-0/+1
| | | | | | | | | Move it from af_lavrresample.c to a new aconverter.c file, which is independent from the filter chain code. It also doesn't use mp_audio, and thus has no GPL dependencies. Preparation for later commits. Not particularly well tested, so have fun.
* vf_eq: remove this filterwm42017-08-221-1/+0
| | | | | | | | | Both the video equalizer command/option glue, which drives this filter, as well as the filter itself are slightly GPL contaminated. So it goes. After this commit, "--vf=eq" will actually use libavfilter's vf_eq (if FFmpeg was compiled in GPL mode), but it has different options and will not listen to the equalizer VOCTRLs.
* build: pick a main-fn source file only if cplayer is builtwm42017-08-221-5/+6
| | | | libmpv does not need this.
* osx: move menu bar creation into its own fileAkemi2017-08-181-0/+1
* audio: introduce a new type to hold audio frameswm42017-08-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is pretty pointless, but I believe it allows us to claim that the new code is not affected by the copyright of the old code. This is needed, because the original mp_audio struct was written by someone who has disagreed with LGPL relicensing (it was called af_data at the time, and was defined in af.h). The "GPL'ed" struct contents that surive are pretty trivial: just the data pointer, and some metadata like the format, samplerate, etc. - but at least in this case, any new code would be extremely similar anyway, and I'm not really sure whether it's OK to claim different copyright. So what we do is we just use AVFrame (which of course is LGPL with 100% certainty), and add some accessors around it to adapt it to mpv conventions. Also, this gets rid of some annoying conventions of mp_audio, like the struct fields that require using an accessor to write to them anyway. For the most part, this change is only dumb replacements of mp_audio related functions and fields. One minor actual change is that you can't allocate the new type on the stack anymore. Some code still uses mp_audio. All audio filter code will be deleted, so it makes no sense to convert this code. (Audio filters which are LGPL and which we keep will have to be ported to a new filter infrastructure anyway.) player/audio.c uses it because it interacts with the old filter code. push.c has some complex use of mp_audio and mp_audio_buffer, but this and pull.c will most likely be rewritten to do something else.
* vo_opengl: extract non-ANGLE specific D3D11 codeJames Ross-Gowan2017-08-171-0/+1
| | | | | | | | | | | | This extracts non-ANGLE specific code to d3d11_helpers.c, which is modeled after egl_helpers.c. Currently the only consumer is context_angle.c, but in future this may allow the D3D11 device and swapchain creation logic to be reused in other backends. Also includes small improvements to D3D11 device creation. It is now possible to create feature level 11_1 devices (though ANGLE does not support these,) and BGRA swapchains, which might be slightly more efficient than ARGB, since its the same format used by the compositor.
* build: use main-fn-cocoa.c on OSXwm42017-08-081-1/+1
| | | | Broken by a434892208.
* build: fix dependencies for Cygwin environmentfeixm12017-08-081-2/+2
| | | | | This replaces previous commit with same intentions. This time, with proper formating (no tabs in code).
* vo_opengl: split utils.c/hwm42017-08-051-0/+2
| | | | | | | | | Actually GL-specific parts go into gl_utils.c/h, the shader cache (gl_sc*) into shader_cache.c/h. No semantic changes of any kind, except that the VAO helper is made public again as part of gl_utils.c (all while the goal for gl_utils.c itself is to be included by GL-specific code).
* vo_opengl: start work on rendering API abstractionwm42017-07-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | This starts work on moving OpenGL-specific code out of the general renderer code, so that we can support other other GPU APIs. This is in a very early stage and it's only a proof of concept. It's unknown whether this will succeed or result in other backends. For now, the GL rendering API ("ra") and its only provider (ra_gl) does texture creation/upload/destruction only. And it's used for the main video texture only. All other code is still hardcoded to GL. There is some duplication with ra_format and gl_format handling. In the end, only the ra variants will be needed (plus the gl_format table of course). For now, this is simpler, because for some reason lots of hwdec code still requires the GL variants, and would have to be updated to use the ra ones. Currently, the video.c code accesses private ra_gl fields. In the end, it should not do that of course, and it would not include ra_gl.h. Probably adds bugs, but you can keep them.
* x11: add 128x128 sized icon supportXu Zhao2017-07-021-0/+6
* x11: load icon differentlywm42017-07-011-2/+15
| | | | | | | | Now it's sourced from the etc/ PNG files directly, instead of preprocessing them with imagemagick. Add some ad-hoc code to decode PNG files with libavcodec. At least we can drop the zlib code in exchange.
* d3d: make DXVA2 support optionalwm42017-06-301-7/+7
| | | | | | | | | | | | This partially reverts the change from a longer time ago to always build DXVA2 and D3D11VA together. To make it simpler, we change the following: - building with ANGLE headers is now required to build D3D hwaccels - if DXVA2 is enabled, D3D11VA is still forcibly built - the CLI vo_opengl ANGLE backend is now under --egl-angle-win32 This is done to reduce the dependency mess slightly.
* Universal Windows Plaform (UWP) supportPedro Pombeiro2017-06-291-1/+2
| | | | | | | | libmpv only. Some things are still missing. Heavily reworked. Signed-off-by: wm4 <wm4@nowhere>
* build: change how some OS specific source files are selectedwm42017-06-291-25/+37
| | | | | | | | | | | | | | | | | | In a bunch of cases, we emulate highly platform specific APIs on a higher level across all OSes, such as IPC, terminal, subprocess handling, and more. We have source files for each OS, and they implement all the same mpv internal API. Selecting which source file to use on an OS can be tricky, because there is partially overlapping and emulated APIs (consider Cygwin on Windows). Add a pick_first_matching_dep() function to make this slightly easier and more structured. Also add dummy backends in some cases, to deal with APIs not being available. Clarify the Windows dependency identifiers, as these are the most confusing.
* build: replace glob() check and assume it's always in POSIXwm42017-06-291-1/+1
| | | | | POSIX requires glob(), so no need to check for it. Together with the fact that we can emulate glob() on Windows, glob() is always available.
* vf_dlopen: remove this filterwm42017-06-181-12/+0
| | | | | | | | | | | | | | | | It was an attempt to move some MPlayer filters (which were removed from mpv) to external, loadable filters. That worked well, but then the MPlayer filters were ported to libavfilter (independently), so they're available again. Also there is a more widely supported and more advanced loadable filter system supported by mpv: vapoursynth. In conclusion, vf_dlopen is not useful anymore, confusing, and requires quite a bit of code (and probably wouldn't survive the rewrite of the mpv video filter chain, which has to come at some point). It has some implicit dependencies on internal conventions, like possibly the format names dropped in the previous commit. We also deprecated it last release. Drop it.
* js: add javascript scripting support using MuJSAvi Halachmi (:avih)2017-06-141-0/+7
| | | | | | | | | | | | | | | Implements JS with almost identical API to the Lua support. Key differences from Lua: - The global mp, mp.msg and mp.utils are always available. - Instead of returning x, error, return x and expose mp.last_error(). - Timers are JS standard set/clear Timeout/Interval. - Supports CommonJS modules/require. - Added at mp.utils: getenv, read_file, write_file and few more. - Global print and dump (expand objects) functions. - mp.options currently not supported. See DOCS/man/javascript.rst for more details.
* wscript_build: install shared libmpv to BINDIR for Win32Ricardo Constantino2017-04-241-0/+4
* video: drop vaapi/vdpau hw decoding support with FFmpeg 3.2wm42017-04-231-2/+0
| | | | | | | | | | 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.
* player: make screenshot commands honor the async flagwm42017-04-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | And also change input.conf to make all screenshots async. (Except the every-frame mode, which always uses synchronous mode and ignores the flag.) By default, the "screenshot" command is still asynchronous, because scripts etc. might depend on this behavior. This is only partially async. The code for determining the filename is still always run synchronously. Only encoding the screenshot and writing it to disk is asynchronous. We explicitly document the exact behavior as undefined, so it can be changed any time. Some of this is a bit messy, because I wanted to avoid duplicating the message display code between sync and async mode. In async mode, this is called from a worker thread, which is not safe because showing a message accesses the thread-unsafe OSD code. So the core has to be locked during this, which implies accessing the core and all that. So the code has weird locking calls, and we need to do core destruction in a more "controlled" manner (thus the outstanding_async field). (What I'd really want would be the OSD simply showing log messages instead.) This is pretty untested, so expect bugs. Fixes #4250.
* wscript: fix broken build with dvdread+dvdnav in 34e6a26Ricardo Constantino2017-03-311-4/+2
| | | | Didn't know waf actually tried to compile the same files twice.
* wscript: decouple dvdnav check from dvdreadRicardo Constantino2017-03-311-0/+2
| | | | | | | | | Reallows enabling dvdnav without enabling dvdread which was broken in 77cbb3543 when they were both disabled by default. Since dvdnav requires dvdread, we can enable dvdread:// even if --enable-dvdread isn't passed. Fixes #4290
* osx: initial Touch Bar supportAkemi2017-03-261-0/+1
* sub: add SDH subtitle filterDan Oscarsson2017-03-251-0/+1
| | | | | | | | | | Add subtitle filter to remove additions for deaf or hard-of-hearing (SDH). This is for English, but may in part work for others too. This is an ASS filter and the intention is that it can always be enabled as it by default do not remove parts that may be normal text. Harder filtering can be enabled with an additional option. Signed-off-by: wm4 <wm4@nowhere>
* w32_common: move the IDropTarget impl to a separate fileJames Ross-Gowan2017-03-261-0/+1
| | | | | | This was mostly self-contained, so its removal makes w32_common.c a bit easier to read. Also, because it was self contained and its author has agreed to LGPL relicencing, the new file has the LGPL licence header.
* af_drc: removeJan Janssen2017-03-251-1/+0
| | | | | | | | | | | | | | | | Remove low quality drc filter. Anyone whishing to have dynamic range compression should use the much more powerful acompressor ffmpeg filter: mpv --af=lavfi=[acompressor] INPUT Or with parameters: mpv --af=lavfi=[acompressor=threshold=-25dB:ratio=3:makeup=8dB] INPUT Refer to for a full list of supported parameters. Signed-off-by: wm4 <wm4@nowhere>
* vdpau: support new vdpau libavcodec decode APIwm42017-03-231-1/+1
| | | | | | | | | | | | | | | | | | | The new API works like the new vaapi API, using generic hwaccel support. One minor detail is the error message that will be printed if using non-4:2:0 surfaces (which as far as I can tell is completely broken in the nVidia drivers and thus not supported by mpv). The HEVC warning (which is completely broken in the nVidia drivers but should work with Mesa) had to be added to the generic hwaccel code. This also trashes display preemption recovery. Fuck that. It never really worked. If someone complains, I might attempt to add it back somehow. This is the 4th iteration of the libavcodec vdpau API (after the separate decoder API, the manual hwaccel API, and the automatic vdpau hwaccel API). Fortunately, further iterations will be generic, and not require much vdpau-specific changes (if any at all).
* vo_opengl: add experimental vdpauglx backendwm42017-03-181-0/+1
| | | | | | | | | | | | | | | | As the manpage says, this has no value other than adding bugs. It uses code based on context_x11.c, and basically does very stripped down context creation (no alpha support etc.). It uses vdpau for display, and maps vdpau output surfaces as FBOs to render into them. This might be good to experiment with asynchronous presentation. For now, it presents synchronously, with a 4 frame delay (which should whack off A/V sync). The forced 4 frame delay is probably also why interaction feels slower. There are some weird vdpau errors on resizing and uninit. No idea what causes them.
* vd_lavc, vaapi: move hw device creation to generic codewm42017-02-201-1/+0
| | | | | | | | hw_vaapi.c didn't do much interesting anymore. Other than the function to create a device for decoding with vaapi-copy, everything can be done by generic code. Other libavcodec hwaccels are planned to provide the same API as vaapi. It will be possible to drop the other hw_ files in the future. They will use this generic code instead.
* vo_opengl: remove dxva2 dummy hwdec backendwm42017-02-201-1/+0
| | | | | | | | | This was a hack to let libmpv API users pass a d3d device to mpv. It's not needed anymore for 2 reasons: 1. ANGLE does not have this problem 2. Even native GL via nVidia (where this failed) seems to not require this anymore
* vo_opengl: implement videotoolbox hwdec on iOSAman Gupta2017-02-171-0/+1
| | | | | | 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.
* videotoolbox: factor some duplicated codewm42017-02-171-0/+1
| | | | | | | | 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.
* player: add experimental stream recording featurewm42017-02-071-0/+1
| | | | | This is basically a WIP, but it can't remain in a branch forever. A warning is print when using it as it's still a bit "shaky".
* build: prefix hwaccel decoder wrapper filenames with hw_wm42017-01-171-8/+8
| | | | | | Should have done this a long time ago. d3d.c remains as it is, because it's just a bunch of helper functions.
* player: add experimental C plugin interfacewm42017-01-121-1/+7
| | | | | | | | | | | | | | | | | This basically reuses the scripting infrastructure. Note that this needs to be explicitly enabled at compilation. For one, enabling export for certain symbols from an executable seems to be quite toolchain-specific. It might not work outside of Linux and cause random problems within Linux. If C plugins actually become commonly used and this approach is starting to turn out as a problem, we can build mpv CLI as a wrapper for libmpv, which would remove the requirement that plugins pick up host symbols. I'm being lazy, so implementation/documentation are parked in existing files, even if that stuff doesn't necessarily belong there. Sue me, or better send patches.
* vaapi: support new libavcodec vaapi APIwm42017-01-111-1/+2
| | | | | | | | | | | | | | | | | The old API is deprecated, and libavcodec prints a warning at runtime. The new API is a bit nicer and does many things for you, such as managing the underlying hwaccel decoder. libavutil also provides code for managing surfaces (we use their surface pool). The new code does not contain any code from the original MPlayer VAAPI patch (that was used as base for some of the vaapi code in mpv). Thus the new code is LGPL. The new API actually does not add any visible symbols, so the only way to detect it is a version check. Of course, the versions overlap between FFmpeg and Libav, which requires additional care. The new API did not get merged into FFmpeg yet, so there's no check for FFmpeg.
* vaapi: rename vaapi.c to vaapi_old.cwm42017-01-111-1/+1
| | | | | vaapi.c will be reintroduced with the new code using the new libavcodec vaapi API.
* build: always run code generators before compilingStefano Pigozzi2017-01-071-17/+2
* build: use & as python modulesStefano Pigozzi2017-01-051-17/+42
* manpage: add table of contents to the HTML versionZhiming Wang2016-12-141-1/+1
| | | | | | | | The reST contents directive is added to mpv.rst. In, the --strip-elements-with-class=contents option is needed for the rst2man call in order to prevent the TOC from appearing in mpv.1.
* wscript_build: rst2pdf: increase section break levelshinchiro2016-12-111-1/+1
| | | | This fix broken pdf build and hopefully less fragile in future
* vo_opengl: hwdec_cuda: Use dynamic loading for cuda functionsPhilip Langdale2016-11-231-0/+1
| | | | | This change applies the pattern used in ffmpeg to dynamically load cuda, to avoid requiring the CUDA SDK at build time.
* wscript: fix typowm42016-11-221-1/+1
* vf_vdpaurb: remove this filterwm42016-11-221-1/+0
| | | | Was deprecated, superseded by --hwdec=vdpau-copy.
* audio/out: add AudioUnit output driver for iOSAman Gupta2016-11-011-0/+3
* vo_tct: optional custom size, support non-posix with 80x25 defaultAvi Halachmi (:avih)2016-10-251-1/+1
| | | | Also, replace the UTF8 half block char at the source code with C escape.
* vo_tct: introduce modern caca alternativerr-2016-10-201-0/+1
* hwdec_cuda: Rename config variable to be more consistentPhilip Langdale2016-09-161-2/+2
| | | | | | 'cuda-gl' isn't right - you can turn this on without any GL and get some non-zero benefit (with the cuda-copy hwaccel). So 'cuda-hwaccel' seems more consistent with everything else.
* player: move builtin profiles to a separate filewm42016-09-151-0/+4
| | | | | | | | | Move the embedded string with the builtin profiles to a separate builtin.conf file. This makes it easier to read and edit, and you can also check it for errors with --include=etc/builtin.conf. (Normally errors are hidden intentionally, because there's no way to output error messages this early, and because some options might not be present on all platforms or with all configurations.)
* vo_opengl: mali fbdev supportwm42016-09-131-0/+1
| | | | | | | | | | | | Minimal support just for testing. Only the window surface creation (including size determination) is really platform specific, so this could be some generic thing with platform-specific support as some sort of sub-driver, but on the other hand I don't see much of a need for such a thing. While most of the fbdev usage is done by the EGL driver, using this fbdev ioctl is apparently the only way to get the display resolution.
* vo_opengl: add hw overlay support and use it for RPIwm42016-09-121-1/+2
| | | | | | | | | | | This overlay support specifically skips the OpenGL rendering chain, and uses GL rendering only for OSD/subtitles. This is for devices which don't have performant GL support. hwdec_rpi.c contains code ported from vo_rpi.c. vo_rpi.c is going to be deprecated. I left in the code for uploading sw surfaces (as it might be slightly more efficient for rendering sw decoded video), although it's dead code for now.
* build: recompile zsh completion if changesPhilip Sequeira2016-09-101-1/+1
* hwdec/opengl: Add support for CUDA and cuvid/NvDecodePhilip Langdale2016-09-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Nvidia's "NvDecode" API (up until recently called "cuvid" is a cross platform, but nvidia proprietary API that exposes their hardware video decoding capabilities. It is analogous to their DXVA or VDPAU support on Windows or Linux but without using platform specific API calls. As a rule, you'd rather use DXVA or VDPAU as these are more mature and well supported APIs, but on Linux, VDPAU is falling behind the hardware capabilities, and there's no sign that nvidia are making the investments to update it. Most concretely, this means that there is no VP8/9 or HEVC Main10 support in VDPAU. On the other hand, NvDecode does export vp8/9 and partial support for HEVC Main10 (more on that below). ffmpeg already has support in the form of the "cuvid" family of decoders. Due to the design of the API, it is best exposed as a full decoder rather than an hwaccel. As such, there are decoders like h264_cuvid, hevc_cuvid, etc. These decoders support two output paths today - in both cases, NV12 frames are returned, either in CUDA device memory or regular system memory. In the case of the system memory path, the decoders can be used as-is in mpv today with a command line like: mpv --vd=lavc:h264_cuvid foobar.mp4 Doing this will take advantage of hardware decoding, but the cost of the memcpy to system memory adds up, especially for high resolution video (4K etc). To avoid that, we need an hwdec that takes advantage of CUDA's OpenGL interop to copy from device memory into OpenGL textures. That is what this change implements. The process is relatively simple as only basic device context aquisition needs to be done by us - the CUDA buffer pool is managed by the decoder - thankfully. The hwdec looks a bit like the vdpau interop one - the hwdec maintains a single set of plane textures and each output frame is repeatedly mapped into these textures to pass on. The frames are always in NV12 format, at least until 10bit output supports emerges. The only slightly interesting part of the copying process is that CUDA works by associating PBOs, so we need to define these for each of the textures. TODO Items: * I need to add a download_image function for screenshots. This would do the same copy to system memory that the decoder's system memory output does. * There are items to investigate on the ffmpeg side. There appears to be a problem with timestamps for some content. Final note: I mentioned HEVC Main10. While there is no 10bit output support, NvDecode can return dithered 8bit NV12 so you can take advantage of the hardware acceleration. This particular mode requires compiling ffmpeg with a modified header (or possibly the CUDA 8 RC) and is not upstream in ffmpeg yet. Usage: You will need to specify vo=opengl and hwdec=cuda. Note that hwdec=auto will probably not work as it will try to use vdpau first. mpv --hwdec=cuda --vo=opengl foobar.mp4 If you want to use filters that require frames in system memory, just use the decoder directly without the hwdec, as documented above.
* misc: add some annoying mpv_node helperswm42016-08-281-0/+1
| | | | | | | Sigh. Some parts of mpv essentially duplicate this code (with varrying levels of triviality) - this can be fixed "later".
* audio/filter: remove delay audio filterPaul B Mahol2016-08-121-1/+0
| | | | Similar filter is available in libavfilter.
* client API: add stream_cb API for user-defined stream implementationsAman Gupta2016-08-071-1/+2
| | | | | | Based on #2630. Some heavy changes by committer. Signed-off-by: wm4 <wm4@nowhere>
* wscript: add proper non-version'd SONAME for AndroidJan Ekström2016-07-301-1/+7
| | | | | This seems to have become a requirement since API target 23+, and matches what FFmpeg does.
* build: add --htmldir optionChris Mayo2016-07-301-1/+1
| | | | | Defaults to docdir but makes it possible to install html documentation separately.
* audio: refactor mixer code and delete mixer.cwm42016-07-171-1/+0
| | | | | | | | | | | | | | | | | mixer.c didn't really deserve to be separate anymore, as half of its contents were unnecessary glue code after recent changes. It also created a weird split between audio.c and af.c due to the fact that mixer.c could insert audio filters. With the code being in audio.c directly, together with other code that unserts filters during runtime, it will be possible to cleanup this code a bit and make it work like the video filter code. As part of this change, make the balance code work like the volume code, and add an option to back the current balance value. Also, since the balance semantics are unexpected for most users (panning between the audio channels, instead of just changing the relative volume), and there are some other volumes, formally deprecate both the old property and the new option.
* d3d: merge angle_common.h into d3d.hwm42016-06-281-2/+1
| | | | | | | | OK, this was dumb. The file didn't have much to do with ANGLE, and the functionality can simply be moved to d3d.c. That file contains helpers for decoding, but can always be present (on Windows) since it doesn't access any D3D specific libavcodec APIs. Thus it doesn't need to be conditionally built like the actual hwaccel wrappers.
* vo_opengl: remove prescaling framework with superxbr prescalerBin Jin2016-06-181-1/+0
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: remove nnedi3 prescalerBin Jin2016-06-181-5/+0
* vo_opengl: fix d3d11 hardware decoding probing on Windows 7wm42016-06-091-0/+1
| | | | | | | | | | | | | | | Although D3D11 video decoding is unuspported on Windows 7, the associated APIs almost work. Where they fail is texture creation, where we try to create D3D11_BIND_DECODER surfaces. So specifically try to detect this situation. One issue is that once the hwdec interop is created, the damage is done, and it can't use another backend (because currently only 1 hwdec backend is supported). So that's where we prevent attempts to use it. It still can fail when trying to use d3d11va-copy (since that doesn't require an interop backend), but at that point we don't care anymore - dxva2(-copy) is tried before that anyway.
* build: don't install tests, only build themIlya Tumaykin2016-05-291-5/+6
| | | | | Considering tests are usually executed right after a successful build, there's no reason to keep them around for later.
* video: remove d3d11 video processor use from OpenGL interopwm42016-05-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We now have a video filter that uses the d3d11 video processor, so it makes no sense to have one in the VO interop code. The VO uses it for formats not directly supported by ANGLE (so the video data is converted to a RGB texture, which ANGLE can take in). Change this so that the video filter is automatically inserted if needed. Move the code that maps RGB surfaces to its own inteorp backend. Add a bunch of new image formats, which are used to enforce the new constraints, and to automatically insert the filter only when needed. The added vf mechanism to auto-insert the d3d11vpp filter is very dumb and primitive, and will work only for this specific purpose. The format negotiation mechanism in the filter chain is generally not very pretty, and mostly broken as well. (libavfilter has a different mechanism, and these mechanisms don't match well, so vf_lavfi uses some sort of hack. It only works because hwaccel and non-hwaccel formats are strictly separated.) The RGB interop is now only used with older ANGLE versions. The only reason I'm keeping it is because it's relatively isolated (uses only existing mechanisms and adds no new concepts), and because I want to be able to compare the behavior of the old code with the new one for testing. It will be removed eventually. If ANGLE has NV12 interop, P010 is now handled by converting to NV12 with the video processor, instead of converting it to RGB and using the old mechanism to import that as a texture.
* vf_d3d11vpp: add a D3D11 video processor filterwm42016-05-281-0/+1
| | | | | | | | | | | | | | | | | Main use: deinterlacing. I'm not sure how to select the deinterlacing mode at all. You can enumate the available video processors, but at least on Intel, all of them either signal support for all deinterlacers, or none (the latter is apparently used for IVTC). I haven't found anything that actually tells the processor _which_ algorithm to use. Another strange detail is how to select top/bottom fields and field dominance. At least I'm getting quite similar results to vavpp on Linux, so I'm content with it for now. Future plans include removing the D3D11 video processor use from the ANGLE interop code.
* vf_vavpp: move frame handling to separate filewm42016-05-251-0/+1
| | | | | | | | | | | | | | Move the handling of the future/past frames and the associated dataflow rules to a separate source file. While this on its own seems rather questionable and just inflates the code, I intend to reuse it for other filters. The logic is annoying enough that it shouldn't be duplicated a bunch of times. (I considered other ways of sharing this logic, such as an uber- deinterlace filter, which would access the hardware deinterlacer via a different API. Although that sounds like kind of the right approach, this would have other problems, so let's not, at least for now.)
* video: merge dxva2 source fileswm42016-05-171-1/+0
| | | | | | | video/dxva2.c exported only 2 functions, both used only by video/decode/dxva2.c. The same was already done for d3d11.
* vo_opengl: support external user hooksNiklas Haas2016-05-151-0/+1
| | | | | | | | | | | This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
* vo_opengl: reorganize texture format handlingwm42016-05-121-0/+1
| | | | | | | | | | | | | This merges all knowledge about texture format into a central table. Most of the work done here is actually identifying which formats exactly are supported by OpenGL(ES) under which circumstances, and keeping this information in the format table in a somewhat declarative way. (Although only to the extend needed by mpv.) In particular, ES and float formats are a horrible mess. Again this is a big refactor that might cause regression on "obscure" configurations.
* build: merge d3d11va and dxva2 hwaccel checkswm42016-05-111-3/+3
| | | | | | We don't have any reason to disable either. Both are loaded dynamically at runtime anyway. There is also no reason why dxva2 would disappear from libavcodec any time soon.
* vo_opengl: angle: dynamically load ANGLEwm42016-05-111-0/+1
| | | | | | | | | | | | ANGLE is _really_ annoying to build. (Requires special toolchain and a recent MSVC version.) This results in various issues with people having trouble to build mpv against ANGLE (apparently linking it against a prebuilt binary doesn't count, or using binaries from potentially untrusted sources is not wanted). Dynamically loading ANGLE is going to be a huge convenience. This commit implements this, with special focus on keeping it source compatible to a normal build with ANGLE linked at build-time.
* video: refactor how VO exports hwdec device handleswm42016-05-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The main change is with video/hwdec.h. mp_hwdec_info is made opaque (and renamed to mp_hwdec_devices). Its accessors are mainly thread-safe (or documented where not), which makes the whole thing saner and cleaner. In particular, thread-safety rules become less subtle and more obvious. The new internal API makes it easier to support multiple OpenGL interop backends. (Although this is not done yet, and it's not clear whether it ever will.) This also removes all the API-specific fields from mp_hwdec_ctx and replaces them with a "ctx" field. For d3d in particular, we drop the mp_d3d_ctx struct completely, and pass the interfaces directly. Remove the emulation checks from vaapi.c and vdpau.c; they are pointless, and the checks that matter are done on the VO layer. The d3d hardware decoders might slightly change behavior: dxva2-copy will not use the VO device anymore if the VO supports proper interop. This pretty much assumes that any in such cases the VO will not use any form of exclusive mode, which makes using the VO device in copy mode unnecessary. This is a big refactor. Some things may be untested and could be broken.
* d3d11va: store texture/subindex in IMGFMT_D3D11VA plane pointerswm42016-04-271-1/+0
| | | | | | | | | Basically this gets rid of the need for the accessors in d3d11va.h, and the code can be cleaned up a little bit. Note that libavcodec only defines a ID3D11VideoDecoderOutputView pointer in the last plane pointers, but it tolerates/passes through the other plane pointers we set.
* vo_opengl: D3D11VA + ANGLE interopwm42016-04-271-0/+1
| | | | | | | | | | | | | | | | | | | This uses ID3D11VideoProcessor to convert the video to a RGBA surface, which is then bound to ANGLE. Currently ANGLE does not provide any way to bind nv12 surfaces directly, so this will have to do. ID3D11VideoContext1 would give us slightly more control about the colorspace conversion, though it's still not good, and not available in MinGW headers yet. The video processor is created lazily, because we need to have the coded frame size, of which AVFrame and mp_image have no concept of. Doing the creation lazily is less of a pain than somehow hacking the coded frame size into mp_image. I'm not really sure how ID3D11VideoProcessorInputView is supposed to work. We recreate it on every frame, which is simple and hopefully doesn't affect performance.
* vd_lavc: simplify RPI and Mediacodec wrapperswm42016-04-251-2/+0
| | | | | | | | | | | | Use the recently added lavc_suffix mechanism to select the wrapper decoder. With all hwdec callbacks being optional, and RPI/Mediacodec having only dummy callbacks, all the callbacks can be removed as well. The result is that the vd_lavc_hwdec struct for both of them is tiny. It's better to move them to vd_lavc.c directly, because they are so trivial and small.
* vd_lavc: add d3d11va hwdecKevin Mitchell2016-03-301-0/+3
| | | | | | This commit adds the d3d11va-copy hwdec mode using the ffmpeg d3d11va api. Functions in common with dxva2 are handled in a separate decode/d3d.c file. A future commit will rewrite decode/dxva2.c to share this code.
* Add a mediacodec decoder hwdec wrapperJan Ekström2016-03-251-0/+1
| | | | | Does the same thing as the rpi one - makes fallback possible by pretending that h264_mediacodec is a hwdec.
* ipc: add Windows implementation with named pipesJames Ross-Gowan2016-03-231-1/+3
| | | | | | | | | | | | | | | This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
* build: be less strict about line endingswm42016-03-111-2/+2
| | | | This is a shitty hack, but also not terribly offensive.
* vo_opengl: add dxva2 interop to angle backendKevin Mitchell2016-03-101-0/+1
| | | | | | Like dxinterop, this uses StretchRect or RGB conversion. This is unavoidable as long as we use the dxva2 API, as there is no way to access the raw hardware decoded Direct3D9 surfaces.
* build: install symbolic SVG iconJashandeep Sohi2016-03-101-0/+4
* demux: add null demuxerwm42016-03-041-0/+1
| | | | It's useless, but can be used for fancy --lavfi-complex nonsense.
* ao: initial OpenSL ES supportIlya Zhuravlev2016-02-271-0/+1
| | | | | | | | OpenSL ES is used on Android. At the moment only stereo output is supported. Two options are supported: 'frames-per-buffer' and 'sample-rate'. To get better latency the user of libmpv should pass values obtained from AudioManager.getProperty(PROPERTY_OUTPUT_FRAMES_PER_BUFFER) and AudioManager.getProperty(PROPERTY_OUTPUT_SAMPLE_RATE).
* wscript: don’t install the encoding profiles with encoding disabledEmmanuel Gil Peyrot2016-02-221-1/+2
* wscript: remove dxva2-dxinterop configure testKevin Mitchell2016-02-171-1/+1
| | | | Wasn't really necessary as it was equivalent to gl-dxinterop.
* vo_opengl: dxinterop: add dxva2 passthroughKevin Mitchell2016-02-171-0/+1
| | | | | Use dxva2 surface to fill RGB IDirect3DSurface9 shared with opengl via DXRegisterObjectNV.
* Rewrite ordered chapters and timeline stuffwm42016-02-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This uses a different method to piece segments together. The old approach basically changes to a new file (with a new start offset) any time a segment ends. This meant waiting for audio/video end on segment end, and then changing to the new segment all at once. It had a very weird impact on the playback core, and some things (like truly gapless segment transitions, or frame backstepping) just didn't work. The new approach adds the demux_timeline pseudo-demuxer, which presents an uniform packet stream from the many segments. This is pretty similar to how ordered chapters are implemented everywhere else. It also reminds of the FFmpeg concat pseudo-demuxer. The "pure" version of this approach doesn't work though. Segments can actually have different codec configurations (different extradata), and subtitles are most likely broken too. (Subtitles have multiple corner cases which break the pure stream-concatenation approach completely.) To counter this, we do two things: - Reinit the decoder with each segment. We go as far as allowing concatenating files with completely different codecs for the sake of EDL (which also uses the timeline infrastructure). A "lighter" approach would try to make use of decoder mechanism to update e.g. the extradata, but that seems fragile. - Clip decoded data to segment boundaries. This is equivalent to normal playback core mechanisms like hr-seek, but now the playback core doesn't need to care about these things. These two mechanisms are equivalent to what happened in the old implementation, except they don't happen in the playback core anymore. In other words, the playback core is completely relieved from timeline implementation details. (Which honestly is exactly what I'm trying to do here. I don't think ordered chapter behavior deserves improvement, even if it's bad - but I want to get it out from the playback core.) There is code duplication between audio and video decoder common code. This is awful and could be shareable - but this will happen later. Note that the audio path has some code to clip audio frames for the purpose of codec preroll/gapless handling, but it's not shared as sharing it would cause more pain than it would help.
* dxva2: use mp_image pool for d3d surfacesKevin Mitchell2016-02-141-0/+1
| | | | | | | | | | | | | This is required so that the individual surfaces can pass beyond the dxva2 decoder and be passed to the vo. This also adds additional data to mp_image->planes[0] for IMGFMT_DXVA2, which is required for maintaining and releasing the surface even if the decoder code is uninited. The IDirectXVideoDecoder itself is encapsulated together with its surface pool and configuration in a dxva2_decoder structure whose creation and destruction is managed by talloc.
* wscript_build: disable SONAME generation when building for AndroidJan Ekström2016-02-101-11/+18
| | | | | Android is well-known for not supporting SONAME'd libraries. All libraries imported into an APK have to end with '.so'.
* Initial Android supportJan Ekström2016-02-101-0/+1
| | | | | * Adds an 'android' feature, which is automatically detected. * Android has a broken strnlen, so a wrapper is added from FreeBSD.
* player: add complex filter graph supportwm42016-02-051-0/+1
| | | | | | | | | | | | | | | | See --lavfi-complex option. This is still quite rough. There's no support for dynamic configuration of any kind. There are probably corner cases where playback might freeze or burn 100% CPU (due to dataflow problems when interaction with libavfilter). Future possible plans might include: - freely switch tracks by providing some sort of default track graph label - automatically enabling audio visualization - automatically mix audio or stack video when multiple tracks are selected at once (similar to how multiple sub tracks can be selected)
* build: make libavfilter mandatorywm42016-02-051-8/+8
| | | | | | The complex filter support that will be added makes much more complex use of libavfilter, and I'm not going to bother with adding hacks to keep libavfilter optional.
* build: fix mpv.conf installationwm42016-01-111-1/+1
* ao_wasapi: move out some utility functionswm42016-01-111-0/+1
| | | | | | Note that hresult_to_str() (coming from wasapi_explain_err()) is mostly wasapi-specific, but since HRESULT error codes are unique, it can be extended for any other use.
* ao_dsound: remove this audio outputwm42016-01-061-1/+0
| | | | | | | It existed for XP-compatibility only. There was also a time where ao_wasapi caused issues, but we're relatively confident that ao_wasapi works better or at least as good as ao_dsound on Windows Vista and later.
* build: add option of html manualChris Mayo2016-01-051-0/+13
* win32: input: use Vista CancelIoExJames Ross-Gowan2015-12-201-1/+1
| | | | | | | | | | | | | | | | | libwaio was added due to the complete inability to cancel synchronous I/O cleanly using the public Windows API in Windows XP. Even calling TerminateThread on the thread performing I/O was a bad solution, because the TerminateThread function in XP would leak the thread's stack. In Vista and up, however, this is no longer a problem. CancelIoEx can cancel synchronous I/O running on other threads, allowing the thread to exit cleanly, so replace libwaio usage with native Vista API functions. It should be noted that this change also removes the hack added in 8a27025 for preventing a deadlock that only seemed to happen in Windows XP. KB2009703 says that Vista and up are not affected by this, due to a change in the implementation of GetFileType, so the hack should not be needed anymore.
* vo_opengl: prefix per-backend source files with context_wm42015-12-191-9/+9
* vo_opengl: split backend code from common.c to context.cwm42015-12-191-0/+1
| | | | | | | | 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-191-0/+1
| | | | | | | | | | 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.
* sub: rename sd_lavc_conv.c to lavc_conv.cwm42015-12-181-1/+1
| | | | | | | | The previous commit turned sd_lavc_conv from a sd_driver to free-standing functions. Do the rename to reflect this change separately to avoid confusing git's content tracking. (Or did git solve this, making separating renames and content changes unnecessary?)
* sub: remove sd_srt.cwm42015-12-151-1/+0
| | | | | | | | The FFmpeg subtitle converter does the same. There used to be some deficiencies in FFmpeg's code, but it seems at least some of them have been fixed. There also used to be the timestamp issue (see previous commit messages), but this doesn't matter anymore. So no reason to keep this code - get rid of it.
* sub: remove sd_microdvd.cwm42015-12-151-1/+0
| | | | | | | This can be dropped for the same reasons as in the previous commits. It removes MicroDVD conversion support on Libav, although MicroDVD files couldn't be read in the first place ever since demux_subreader.c was removed.
* sub: remove sd_lavf_srt.cwm42015-12-151-1/+0
| | | | | | | This restored timestamps when demuxing srt subtitles in Libav, which was important for avoiding slightly overlapping subtitles. Since the way this works was changed, there is no real reason to maintain proper timestamps anymore on this level - this can be dropped without issues.
* sub: remove sd_movtext.cwm42015-12-151-1/+0
| | | | | libavcodec's movtext-to-ass converter does the same and has more features. On Libav, this commit disables mp4 subtitle display.
* vo_opengl: add dxinterop backendJames Ross-Gowan2015-12-111-0/+1
| | | | | | | | | | | | | | | | | | | | | 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:
* demux: remove old subtitle parserwm42015-12-101-1/+0
| | | | | | | | | All of these are supported by FFmpeg now. It was disabled by default too (with FFmpeg). If compiled against Libav, mpv will lose the ability to read some subtitle formats (but the most important ones, srt and ass, still should work).
* stream: drop PVR supportwm42015-12-101-1/+0
| | | | | | | | | This is only for specific Hauppage cards. According to the comments in who is actively using this feature. Get it out of the way. Anyone who still wants to use this should complain. Keeping this code would not cause terribly much additional work, and it could be restored again. (But not if the request comes months later.)
* build: install scalable svg icon as wellChristian Hesse2015-12-011-0/+4
* vo_opengl: win32: test for exclusive modeJames Ross-Gowan2015-11-261-0/+1
| | | | | | | | | | This is a hack, but unfortunately the DwmGetCompositionTimingInfo heuristic does not work in all cases (with multiple-monitors on Windows 8.1 and even with a single monitor in Windows 10.) See the comment in mp_w32_is_in_exclusive_mode() for more details. It should go without saying that if any better method of doing this reveals itself, this hack should be dropped.
* vo_opengl: add initial ANGLE supportJames Ross-Gowan2015-11-181-0/+1
| | | | | | | | | | | ANGLE is a GLES2 implementation for Windows that uses Direct3D 11 for rendering, enabling vo_opengl to work on systems with poor OpenGL drivers and bypassing some of the problems with native GL, such as VSync in fullscreen mode. Unfortunately, using GLES2 means that most of vo_opengl's advanced features will not work, however ANGLE is under rapid development and GLES3 support is supposed to be coming soon.
* demux_libass: remove this demuxerwm42015-11-111-1/+0
| | | | | | | | | This loaded external .ass files via libass. libavformat's .ass reader is now good enough, so use that instead. Apparently libavformat still doesn't support fonts embedded into text .ass files, but support for this has been accidentally broken in mpv for a while anyway. (And only 1 person complained.)
* vo_opengl: add DRM EGL backendrr-2015-11-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Notes: - Unfortunately the only way to talk to EGL from within DRM I could find involves linking with GBM (generic buffer management for Mesa.) Because of this, I'm pretty sure it won't work with proprietary NVidia drivers, but then again, last time I checked NVidia didn't offer proper screen resolution for VT. - VT switching doesn't seem to work at all. It's worth mentioning that using vo_drm before introduction of VT switcher had an anomaly where user could switch to another VT and input text to it, while video played on top of that VT. However, that isn't the case with drm_egl: I can't switch to other VT during playback like this. This makes me think that it's either a limitation coming from my firmware or from EGL/KMS itself rather than a bug with my code. Nonetheless, I still left (untestable) VT switching code in place, in case it's useful to someone else. - The mode_id, connector_id and device_path should be configurable for power users and people who wish to watch videos on nonprimary screen. Unfortunately I didn't see anything that would allow OpenGL backends to register their own set of options. At the same time, adding them to global namespace is pointless. - A few dozens of lines could be shared with vo_drm (setting up VT switching, most of code behind page flipping). I don't have any strong opinion on this. - Sometimes I get minor visual glitches. I'm not sure if there's a race condition of some sort, unitialized variable (doubtful), or if it's buggy driver. (I'm using integrated Intel HD Graphics 4400 with Mesa) - .config and .control are very minimal. Signed-off-by: wm4 <wm4@nowhere>
* w32: use DisplayConfig API to retrieve correct monitor refresh rateJames Ross-Gowan2015-11-061-0/+1
| | | | | | | | | | This is based on an older patch by James Ross-Gowan. It was rebased and cleaned up. Also, the DWM API usage present in the older patch was removed, because DWM reports nonsense rates at least on Windows 8.1 (they are rounded to integers, just like with the old GDI API - except the GDI API had a good excuse, as it could report only integers). Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: implement NNEDI3 prescalerBin Jin2015-11-051-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement NNEDI3, a neural network based deinterlacer. The shader is reimplemented in GLSL and supports both 8x4 and 8x6 sampling window now. This allows the shader to be licensed under LGPL2.1 so that it can be used in mpv. The current implementation supports uploading the NN weights (up to 51kb with placebo setting) in two different way, via uniform buffer object or hard coding into shader source. UBO requires OpenGL 3.1, which only guarantee 16kb per block. But I find that 64kb seems to be a default setting for recent card/driver (which nnedi3 is targeting), so I think we're fine here (with default nnedi3 setting the size of weights is 9kb). Hard-coding into shader requires OpenGL 3.3, for the "intBitsToFloat()" built-in function. This is necessary to precisely represent these weights in GLSL. I tried several human readable floating point number format (with really high precision as for single precision float), but for some reason they are not working nicely, bad pixels (with NaN value) could be produced with some weights set. We could also add support to upload these weights with texture, just for compatibility reason (etc. upscaling a still image with a low end graphics card). But as I tested, it's rather slow even with 1D texture (we probably had to use 2D texture due to dimension size limitation). Since there is always better choice to do NNEDI3 upscaling for still image (vapoursynth plugin), it's not implemented in this commit. If this turns out to be a popular demand from the user, it should be easy to add it later. For those who wants to optimize the performance a bit further, the bottleneck seems to be: 1. overhead to upload and access these weights, (in particular, the shader code will be regenerated for each frame, it's on CPU though). 2. "dot()" performance in the main loop. 3. "exp()" performance in the main loop, there are various fast implementation with some bit tricks (probably with the help of the intBitsToFloat function). The code is tested with nvidia card and driver (355.11), on Linux. Closes #2230
* vo_opengl: add Super-xBR filter for upscalingBin Jin2015-11-051-0/+1
| | | | | | | | | | | Add the Super-xBR filter for image doubling, and the prescaling framework to support it. The shader code was ported from MPDN extensions project, with modification to process luma only. This commit is largely inspired by code from #2266, with `gl_transform_trans()` authored by @haasn taken directly.
* build: remove explicit checks for VPPwm42015-10-171-1/+1
| | | | | This was once done when old versions of libva without VPP had to be supported. Some parts of it were removed earlier already.
* Revert "vo_x11: remove this video output"wm42015-09-301-0/+1
| | | | | | | | | | | | | | | This reverts commit d11184a256ed709a03fa94a4e3940eed1b76d76f. Unfortunately, there was a lot of unexpected resistance. Do note that this is still extremely slow, crappy, etc. Note that vo_x11.c was further edited. Compared to the removed vo_x11.c, an additional ~200 lines of code was removed in order to simplify it. I tried to strip it down as much as possible. In particular, support for odd non-32 bit formats (24, 16, 15, 8 bit) is dropped. Closes #2300.
* vo_opengl: rename hwdec_vda.c to hwdec_osx.cwm42015-09-281-1/+1
| | | | | | | It doesn't deal with VDA at all anymore. Rename it to hwdec_osx.c. Not using hwdec_videotoolbox.c, because that would give it the longest source path in this project yet. (Also, this code isn't even VideoToolox-specific, other than the name of the pixel format used.)
* video: remove VDA supportwm42015-09-281-2/+1
| | | | | | | | | VideoToolbox is preferred. Now that FFmpeg released 2.8, there's no reason to support VDA anymore. In fact, we had a bug that made VDA not useable with older FFmpeg versions in some newer mpv releases. VideoToolbox is supported even on slightly older OSX versions, and if not, you still can run mpv without hw decoding.
* vaapi: remove dependency on X11wm42015-09-271-2/+2
| | | | | | | | | | | | | There are at least 2 ways of using VAAPI without X11 (Wayland, DRM). Remove the X11 requirement from the decoder part and the EGL interop. This will be used by a following commit, which adds Wayland support. The worst about this is the decoder part, which includes a bad hack for using the decoder without any VO interop (also known as "vaapi-copy" mode). Separate the X11 parts so that they're self-contained. For the EGL interop code we do something similar (it's kept slightly simpler, because it essentially only has to translate between our silly MPGetNativeDisplay abstraction and the vaGetDisplay...() call).
* video: refactor GPU memcpy usagewm42015-09-251-0/+1
| | | | | | | | | | | | | | | | | Make the GPU memcpy from the dxva2 code generally useful to other parts of the player. We need to check at configure time whether SSE intrinsics work at all. (At least in this form, they won't work on clang, for example. It also won't work on non-x86.) Introduce a mp_image_copy_gpu(), and make the dxva2 code use it. Do some awkward stuff to share the existing code used by mp_image_copy(). I'm hoping that FFmpeg will sooner or later provide a function like this, so we can remove most of this again. (There is a patch, bit it's stuck in limbo since forever.) All this is used by the following commit.
* vo_opengl: support new VAAPI EGL interopwm42015-09-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Should work much better than the old GLX interop code. Requires Mesa 11, and explicitly selecting the X11 EGL backend with: --vo=opengl:backend=x11egl Should it turn out that the new interop works well, we will try to autodetect EGL by default. This code still uses some bad assumptions, like expecting surfaces to be in NV12. (This is probably ok, because virtually all HW will use this format. But we should at least check this on init or so, instead of failing to render an image if our assumption doesn't hold up.) This repo was a lot of help: The kodi code was also helpful (the magic FourCC it uses for EGL_LINUX_DRM_FOURCC_EXT are nowhere documented, and EGL_IMAGE_INTERNAL_FORMAT_EXT as used in ffvademo does not actually exist). (This is the 3rd VAAPI GL interop that was implemented in this player.)
* player: rename and move find_subfiles.cwm42015-09-201-1/+1
| | | | | | This was in sub/, because the code used to be specific to subtitles. It was extended to automatically load external audio files too, and moving the file and renaming it was long overdue.
* video/filter: remove some vf_lavfi wrapperswm42015-09-111-4/+0
| | | | | | | | | | | | | | | | I see no point in keeping these around. Keeping wrappers for some select libavfilter filters just because MPlayer had these filters is not a good reason. Ultimately, all real filtering work should go to libavfilter, and users should get used to using vf_lavfi directly. We might even not require the awful double-nested syntax for using libavfilter one day. vf_rotate, vf_yadif, vf_stereo3d are kept because mpv uses them internally. (They all extend the lavfi filters or change their defaults.) vf_mirror is kept for symmetry with vf_flip. vf_gradfun and vf_pullup are probably semi-popular, so I'll remove them not yet - only after some more discussion.
* vf: vf_stereo3d depends on libavfilterwm42015-09-111-1/+1
* vo_opengl: move self-contained shader routines to a separate fileNiklas Haas2015-09-091-0/+1
| | | | | | | | | | | This is mostly to cut down somewhat on the amount of code bloat in video.c by moving out helper functions (including scaler kernels and color management routines) to a separate file. It would certainly be possible to move out more functions (eg. dithering or CMS code) with some extra effort/refactoring, but this is a start. Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: remove gl_ prefixes from files in video/out/openglNiklas Haas2015-09-091-16/+16
| | | | | This is a bit redundant with the name of the directory itself, and not in line with existing naming conventions.
* vo_opengl: move gl_* files to their own subdirNiklas Haas2015-09-091-16/+16
| | | | | This is mainly just to keep things a bit more organized and separated inside the codebase.
* audio/filter: remove af_bs2b toowm42015-09-041-1/+0
| | | | | | | Some users still use this filter, so the filter was going to be kept. But I overlooked that libavfilter provides this filter. Remove the redundant wrapper from mpv. Something like --af=lavfi=bs2b should work and give exactly the same results.
* audio/filter: remove some useless filterswm42015-09-031-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | All of these filters are considered not useful anymore by us. Some have replacements in libavfilter (useable through af_lavfi). af_center, af_extrastereo, af_karaoke, af_sinesuppress, af_sub, af_surround, af_sweep: pretty simple and useless filters which probably nobody ever wants. af_ladspa: has a replacement in libavfilter. af_hrtf: the algorithm doesn't work properly on most sources, and the implementation was buggy and complicated. (The filter was inherited from MPlayer; but even in mpv times we had to apply fixes that fixed major issues with added noise.) There is a ladspa filter if you still want to use it. af_export: I'm not even sure what this is supposed to do. Possibly it was meant for GUIs rendering audio visualizations, but it couldn't really work well. For example, the size of the audio depended on the samplerate (fixed number of samples only), and it couldn't retrieve the complete audio, only fragments. If this is really needed for GUIs, mpv should add native visualization, or a proper API for it.
* vo_rpi: use EGL to render subtitleswm42015-08-181-1/+1
| | | | | | | | Slightly faster than using the dispmanx mess (perhaps to a large amount due to the rather stupid C-only unoptimized ASS->RGBA blending code). Do this by reusing vo_opengl's subtitle renderer, and vo_opengl's RPI backend.
* stream: libarchive wrapper for reading compressed archiveswm42015-08-171-0/+2
| | | | | | | | | | | | | | | | | | | | This works similar to the existing .rar support, but uses libarchive. libarchive supports a number of formats, including zip and (most of) rar. Unfortunately, seeking does not work too well. Most libarchive readers do not support seeking, so it's emulated by skipping data until the target position. On backwards seek, the file is reopened. This works fine on a local machine (and if the file is not too large), but will perform not so well over network connection. This is disabled by default for now. One reason is that we try libarchive on every file we open, before trying libavformat, and I'm not sure if I trust libarchive that much yet. Another reason is that this breaks multivolume rar support. While libarchive supports seeking in rar, and (probably) supports multivolume archive, our support of libarchive (probably) does not. I don't care about multivolume rar, but vocal users do.
* video: remove old vdpau hwaccel API usagewm42015-08-101-1/+0
| | | | | | | While the "old" libavcodec vdpau API is not deprecated (only the very- old API is), it's still relatively complicated code that badly duplicates the much simpler newer vdpau code. It exists only for the sake of older FFmpeg releases; get rid of it.
* hwdec: add VideoToolbox supportSebastien Zwickert2015-08-051-1/+2
| | | | | | | | VDA is being deprecated in OS X 10.11 so this is needed to keep hwdec working. The code needs libavcodec support which was added recently (to FFmpeg git, libav doesn't support it). Signed-off-by: Stefano Pigozzi <>
* player: remove higher-level remains of DVD/BD menu supportwm42015-08-031-1/+0
| | | | | | | | | | | | | | | Nobody wanted to restore this, so it gets the boot. If anyone still wants to volunteer to restore menu support, this would be welcome. (I might even try it myself if I feel masochistic and like wasting a lot of time for nothing.) But if it does get restored, it should be done differently. There were many stupid things about how it was done. For example, it somehow tried to pull mp_nav_events through all the layers (including needing to "buffer" them in the demuxer), which was needlessly complicated. It could be done simpler. This code was already inactive, so this commit actually changes nothing. Also keep in mind that normal DVD/BD playback still works.
* audio: remove af_dummywm42015-08-011-1/+0
| | | | Was used internally once; has no function anymore.
* build: fix windows compilation after cleanStefano Pigozzi2015-07-171-3/+5
| | | | broken since 4730e0aabab
* build: make mpv.rc depend on version.hStefano Pigozzi2015-07-151-0/+4
* vf_vdpaurb: Add a new filter for reading back vdpau decoded framesPhilip Langdale2015-07-111-0/+1
| | | | | | | | | | | | | | | | | Normally, vdpau decoded frames are passed directly to a suitable vo (vo_vdpau or vo_opengl) without ever touching system memory. This is efficient for output purposes, but prevents any of the regular filters from being used with such frames. This new filter implements a read-back step to pull the frames back into system memory where they can be acted on by other filters. Eventually the frames will be sent to the vo as if they were normal software-decoded frames. Note that a vdpau compatible vo must still be used to ensure that the decoder is properly initialised. Signed-off-by: wm4 <wm4@nowhere>
* client API, dxva2: add a workaround for OpenGL fullscreen issueswm42015-07-031-0/+1
| | | | | | | | | This is basically a hack for drivers which prevent the mpv DXVA2 decoder glue from working if OpenGL is in fullscreen mode. Since it doesn't add any "hard" new API to the client API, some of the code would be required for a true zero-copy hw decoding pipeline, and sine it isn't too much code after all, this is probably acceptable.
* vo_x11: remove this video outputwm42015-06-261-1/+0
| | | | | | | It only causes additional maintenance work. Even if you wanted to have a fallback, it's probably better to use --vo=sdl or so.
* af_convert24: remove this filterwm42015-06-161-1/+0
* audio: remove S8, U16, U24, U32 formatswm42015-06-161-1/+0
| | | | | | | | | | | | | They are useless. Not only are they actually rarely in use; but libavcodec doesn't even output them, as libavcodec has no such sample formats for decoded audio. Even if it should happen that we actually still need them (e.g. if doing direct hardware output), there are better solutions. Swapping the sign is a fast and lossless operation and can be done inplace, so AO actually needing it could do this directly. If you wonder why we keep U8 instead of S8: because libavcodec does it.
* vdpau: add support for the "new" libavcodec vdpau APIwm42015-05-281-1/+2
| | | | | | | | | Yet another of these dozens of hwaccel changes. This time, libavcodec provides utility functions, which initialize the vdpau decoder and map codec profiles. So a lot of work the API user had to do falls away. This also will give us support for high bit depth profiles, and possibly HEVC once libavcodec supports it.
* video: rename vdpau.c to vdpau_old.cwm42015-05-281-1/+1
| | | | vdpau.c will be used for new code.
* demux_cue: move cue parser to a separate filewm42015-05-191-0/+1
| | | | Preparation for the next commit.
* ao_coreaudio: move channel mapping code to a separate filewm42015-05-051-0/+1
| | | | | | | | | | Move all of the channel map retrieval/negotiation code to a separate file. This will (probably) be helpful when extending ao_coreaudio_exclusive.c. Nothing else changes, other than some minor cosmetics and renaming, and changing some details for decoupling it from the ao_coreaudio.c internals.
* build: move main-fn files to osdepwm42015-05-021-3/+6
| | | | | | And split the Cocoa and Unix cases. Simplify the Cocoa case slightly by calling mpv_main directly, instead of passing a function pointer. Also add a comment explaining why Cocoa needs a special case at all.
* cocoa: always compile OSX application code with cocoawm42015-05-021-1/+1
| | | | | | | | | | | | | | This unbreaks compiling command line player and libmpv at the same time. The problem was that doing so silently disabled the OSX application thing - but the command line player can not use the vo_opengl Cocoa backend without it. The OSX application code is basically dead in libmpv, but it's not that much code anyway. If you want a mpv binary that does not create an OSX application singleton (and creates a menu etc.), you must disable cocoa completely, as cocoa can't be used anyway in this case.
* path: refactorwm42015-05-011-0/+1
| | | | | | | | | | | | | | Somewhat less ifdeffery, higher flexibility. Now there are 3 separate config file resolvers for 3 platforms (unix, win, osx), and they can still interact with each other somewhat. For example, OSX for now uses most of Unix, but adds the OSX bundle path. This can be extended to resolve very specific platform paths, such as location of the desktop. Most of the Unix specific code moves to path-unix.c. The behavior should be the same - if not, it is likely a bug.
* build: fix libavfilter dependency for vf_mirrorxylosper2015-04-201-1/+1
| | | | | | | Since e207c24b32a457859ab6e3a5b1f5f9eaeea36ed1, vf_mirror requires libavfilter. Signed-off-by: wm4 <wm4@nowhere>
* vo_drm: extract vt_switcher to drm_commonMarcin Kurczewski2015-04-191-0/+1
* vf_screenshot: remove this filterwm42015-04-161-1/+0
| | | | | | It's entirely useless, especially now that vo.c handles screenshots in a generic way, and requires no special VO support. There are some potential weird use-cases, but actually I've never seen it being used.
* vo_drm: add KMS/DRM renderer supportMarcin Kurczewski2015-04-161-0/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* subprocess: move implementation for deatched subprocesseswm42015-04-151-0/+1
* win32: use a platform-specific unicode entry-pointJames Ross-Gowan2015-04-111-1/+5
| | | | | | | | | | Add a platform-specific entry-point for Windows. This will allow some platform-specific initialization to be added without the need for ugly ifdeffery in main.c. As an immediate advantage, mpv can now use a unicode entry-point and convert the command line arguments to UTF-8 before passing them to mpv_main, so osdep_preinit can be simplified a little bit.
* RPI supportwm42015-03-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires FFmpeg git master for accelerated hardware decoding. Keep in mind that FFmpeg must be compiled with --enable-mmal. Libav will also work. Most things work. Screenshots don't work with accelerated/opaque decoding (except using full window screenshot mode). Subtitles are very slow - even simple but huge overlays can cause frame drops. This always uses fullscreen mode. It uses dispmanx and mmal directly, and there are no window managers or anything on this level. vo_opengl also kind of works, but is pretty useless and slow. It can't use opaque hardware decoding (copy back can be used by forcing the option --vd=lavc:h264_mmal). Keep in mind that the dispmanx backend is preferred over the X11 ones in case you're trying on X11; but X11 is even more useless on RPI. This doesn't correctly reject extended h264 profiles and thus doesn't fallback to software decoding. The hw supports only up to the high profile, and will e.g. return garbage for Hi10P video. This sets a precedent of enabling hw decoding by default, but only if RPI support is compiled (which most hopefully it will be disabled on desktop Linux platforms). While it's more or less required to use hw decoding on the weak RPI, it causes more problems than it solves on real platforms (Linux has the Intel GPU problem, OSX still has some cases with broken decoding.) So I can live with this compromise of having different defaults depending on the platform. Raspberry Pi 2 is required. This wasn't tested on the original RPI, though at least decoding itself seems to work (but full playback was not tested).
* demux: fix rar support for files containing DTS audio trackswm42015-03-241-0/+1
| | | | | | | | | | | | | | | | | With a recent cleanup, rar support was stuffed into demux_playlist.c (because "opening" rar files pretty much just lists archive contents and adds them to a playlist using a special rar:// protocol, which will actually access the rar file contents). Since demux_playlist.c is probed _after_ demux_lavf.c (and should/must be), libavformat was given the chance to detect DTS streams embedded within the rar file. This is not really what we want, and a regression what happened before rar listing was moved to demux_playlist.c. Fix it by moving the rar listing into its own pseudo-demuxer, and let ir probe before demux_lavf.c. (Yes, this feature still has users.)
* input: remove Linux joystick supportwm42015-03-241-1/+0
| | | | | | | | | | | Why did this exist in the first place? Other than being completely useless, this even caused some regressions in the past. For example, there was the case of a laptop exposing its accelerometer as joystick device, which led to extremely fun things due to the default mappings of axis movement being mapped to seeking. I suppose those who really want to use their joystick to control a media player (???) can configure it as mouse device or so.
* input: remove classic LIRC supportwm42015-03-241-1/+0
| | | | It's much easier to configure remotes as X11 input devices.
* audio: remove internal libmpg123 wrapperwm42015-03-241-1/+0
| | | | | | | We've been prefering the libavcodec mp3 decoder for half a year now. There is likely no benefit at all for using the libmpg123 one. It's just a maintenance burden, and tricks users into thinking it's a required dependency.
* vo_opengl: refactor shader generation (part 1)wm42015-03-121-4/+0
| | | | | | | | | | | | | | | | | | | The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
* build: simplify windows checkswm42015-03-111-2/+2
| | | | | There's no reason to do finegrained checks for libraries which always must be present. It also reduces the number of extra dependencies.
* audio: change playback speed directly in resamplerwm42015-03-021-1/+0
| | | | | | | | | | | | | Although the libraries we use for resampling (libavresample and libswresample) do not support changing sampelrate on the fly, this makes it easier to make sure no audio buffers are implicitly dropped. In fact, this commit adds additional code to drain the resampler explicitly. Changing speed twice without feeding audio in-between made it crash with libavresample inc ertain cases (libswresample is fine). This is probably a libavresample bug. Hopefully this will be fixed, and also I attempted to workaround the situation that crashes it. (It seems to point in direction of random memory corruption, though.)
* demux_edl: move implementationwm42015-02-171-1/+0
| | | | Same deal as with demux_cue, and a separate commit for the same reasons.
* demux_cue: move implementationwm42015-02-171-1/+0
| | | | | | | | Move the implementation, of which most was in tl_cue.c, to demux_cue.c. Currently, this is illogical, because tl_cue.c still accesses MPContext. This is going to change, and then it will be better if everything is in demux_cue.c. This is only a separate commit to distinguish code movement and actual work; the next commit will do the actual work.
* matroska: move timeline code to demux/wm42015-02-171-1/+1
| | | | | Separate from previous commit, because git is bad at tracking file renames when the file contents are also changed.
* player: use a separate context for timeline loader stuffwm42015-02-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Instead of accessing MPContext in player/timeline/*, create a separate context struct, which the timeline loaders fill out. It turns out that there's not much in the way too big MPContext that these need to access. One major PITA is managing (and closing) the set of open demuxers. The problem is that we need a list of all demuxers to make sure no unneeded streams are enabled. This adds a callback to the demuxer_desc struct, with the intention of leaving to to the demuxer to call the right loader, instead of explicitly checking the demuxer type and dispatching manually in common code. I also considered making the timeline part of the demuxer state, but decided against: it's too much of a mess wrt. memory management and threading, and also doesn't make it clear who owns the child demuxers. With the struct timeline decoupled from the demuxer state, it's at least somewhat clear that the child demuxers are independent from the "main" demuxer. The actual changes to player/timeline/* are separated in the following commits, because they're quite verbose. Some artifacts will be removed later as soon as there's only 1 timeline loading mechanism.
* video/filters: simplify libavfilter bridgewm42015-02-111-8/+8
| | | | | | | | | | Remove the confusing crap that allowed a filter using the libavfilter bridge to be compiled without libavfilter. Instead, compile the wrappers only if libavfilter is enabled at compile time. The only filter which still requires it is vf_stereo3d (unfortunately). Special-case this one. (The whole filter and how it interacts with lavfi is pure braindeath anyway.)
* af_rubberband: pitch correction with librubberbandwm42015-02-111-0/+1
| | | | | | | | | If "--af=rubberband" is used, librubberband will be used to speed up or slow down audio with pitch correction. This still has some problems: the audio delay is not calculated correctly, so the audio position jitters around by a few milliseconds. This will probably ruin video timing.
* vo_opengl: move utility functions from loader to a separate filewm42015-01-281-0/+1
| | | | | | | gl_common.c contained the function loader (which is big) and additional utility functions (not so big, but will grow when moving more out of gl_video.c). Just split them. There are no changes other than some modifications to comments.
* vf_ilpack: remove this filterwm42015-01-271-1/+0
| | | | | | | | This was apparently useful for correct interlaced scaling (although I don't know anyone who used this). It was rarely used (if at all), had an inconvenient output format (packed YUV), and now has a better solution in libavfilter (using the libavfilter "scale" filter via vf_lavfi). There is no reason to keep this filter any longer.
* vf_divtc: remove this filterwm42015-01-271-1/+0
| | | | | Better solutions are available in vf_vapoursynth and vf_lavfi. The only user I know who used this is now using vf_vapoursynth.
* vf_phase: remove this filterwm42015-01-271-1/+0
| | | | If you really want it, it's in libavfilter and can be used via vf_lavfi.
* vf_swapuv: remove this filterwm42015-01-271-1/+0
| | | | | | It's entirely useless. I left it in for a while, because the analog TV code had a transitional bug that could switch chroma planes, but it was fixed long ago. It's also available in libavfilter.
* vf_softpulldown: remove this filterwm42015-01-271-1/+0
| | | | | | | | Apparently it was completely broken and essentially did nothing. This was broken sometime in early mpv or mplayer2 times. Get rid of it. If you _really_ need it, wait until FFmpeg ports it from MPlayer, which will happen very soon.
* vf_pullup: remove builtin implementationwm42015-01-271-1/+0
| | | | | Now it requires libavfilter. The wrapper is left in place, so FFmpeg users will not notice any change. On Libav, the filter stops working.
* build: remove bogus client API examples buildwm42015-01-231-28/+0
| | | | | | | | | | | The symlink trick made waf go crazy (deleting source files, getting tangled up in infinite recursion... I wish I was joking). This means we still can't build the client API examples in a reasonable way using the include files of the local repository (instead of globally installed headers). Not building them at all is better than deleting source files. Instead, provide some manual instructions how to build each example (except for the Qt examples, which provide qmake project files).
* vo_opengl_old: remove this VOwm42015-01-201-2/+0
| | | | | At this point, there is probably no hardware left that doesn't do OpenGL 2.1, and at the same time is fast enough to handle video.
* player: use libavutil API to get number of CPUswm42015-01-051-1/+0
| | | | | | | | | | | Our own code was introduced when FFmpeg didn't provide this API (or maybe didn't even have a way to determine the CPU count). But now, av_cpu_count() is available for all FFmpeg/Libav versions we support, and there's no reason to have our own code. libavutil's code seems to be slightly more sophisticated than our's, and it's possible that the detected CPU count is different on some platforms after this change.
* build: try to make examples build both in-tree and out-of-treewm42015-01-021-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | The examples simple.c and cocoabasic.m can be compiled without installing libmpv. But also, they didn't use the correct include path libmpv programs normally use, so they couldn't be built with a properly installed system-libmpv. That's pretty bad for examples, which are supposed to show how to use libmpv correctly. So do some bullshit that symlinks libmpv to a "mpv" include directory under the build directory. This name-mismatch is a direct consequence of the bullshit done in 499a6758 (requested in #539 for dumb reasons). (We don't want to name the client API headers directory "mpv", because that would be too unspecific, and clashes with having the mpv binary in the same directory.) If you have spaces or other "unusual" characters in your paths, the build will break, because I couldn't find out where waf hides its function to escape shell parameters (or a way to invoke programs without involving the shell). Neither does such a thing to be documented, nor do they seem to have a clear way to do this in their code. This also doesn't compile the Qt examples, because everything becomes even more terrible from there on.
* DOCS/client_api_examples: move all examples into their own subdirswm42015-01-011-2/+2
| | | | | Also get rid of shared.h; it actually doesn't have much value. Just copy the tiny function it contained into the 2 files which used it.
* win32: add native wrappers for pthread functionswm42015-01-011-0/+1
| | | | | | | Off by default, use --enable-win32-internal-pthreads . This probably still needs a lot more testing. It also won't work on Windows XP.
* demux_mf: move mf.c contents to demux_mf.cwm42014-12-291-1/+0
| | | | | | | | | There's no reason why parts of this demuxer would be in a separate source file. The existence of this code is already somewhat questionable anyway, so it may as well be dumped into a single file. Even stranger that demux.c included mf.h for no reason (it was an artifact from 2002 when the architecture was uncleaner).
* ao_portaudio: remove this audio outputwm42014-12-291-1/+0
| | | | | It's just completely useless. We have good native support for all 3 desktop platforms, and ao_sdl or ao_openal as fallbacks.
* build: fix linking with --enable-static-buildStefano Pigozzi2014-12-291-2/+2
* chmap_sel: add multichannel fallback heuristicStefano Pigozzi2014-12-291-4/+25
| | | | | | | | | | | | Instead of just failing during channel map selection, try to select a close layout that makes most sense and upmix/downmix to that instead of failing AO initialization. The heuristic is rather simple, and uses the following steps: 1) If mono is required always prefer stereo to a multichannel upmix. 2) Search for an upmix that is an exact superset of the required channel map. 3) Search for a downmix that is the exact subset of the required channel map. 4) Search for either an upmix or downmix that is the closest (minimum difference of channels) to the required channel map.
* win32: add mmap() emulationwm42014-12-261-1/+1
| | | | | | | | Makes all of overlay_add work on windows/mingw. Since we now don't explicitly check for mmap() anymore (it's always present), this also requires us to make af_export.c compile, but I haven't tested it.
* client API: expose OpenGL rendererwm42014-12-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds API to libmpv that lets host applications use the mpv opengl renderer. This is a more flexible (and possibly more portable) option to foreign window embedding (via --wid). This assumes that methods like context sharing and multithreaded OpenGL rendering are infeasible, and that a way is needed to integrate it with an application that uses a single thread to render everything. Add an example that does this with QtQuick/qml. The example is relatively lazy, but still shows how relatively simple the integration is. The FBO indirection could probably be avoided, but would require more work (and would probably lead to worse QtQuick integration, because it would have to ignore transformations like rotation). Because this makes mpv directly use the host application's OpenGL context, there is no platform specific code involved in mpv, except for hw decoding interop. main.qml is derived from some Qt example. The following things are still missing: - a way to do better video timing - expose GL renderer options, allow changing them at runtime - support for color equalizer controls - support for screenshots
* build: showqscale was removedwm42014-12-041-2/+1
* video/filter: kill vf_pp (libpostproc)wm42014-12-031-1/+0
| | | | | | | | | This is an ancient filter, and we assume it's not useful anymore. If you really want this, it's still available in libavfilter (e.g. via --vf=lavfi=[pp...]). The disadvantage is that mpv doesn't pass through QP information to libavfilter. (This was probably the reason vf_pp still was part of mpv - it was slightly easier to pass QP internally.)
* vo_opengl: move hwdec parts into their own fileswm42014-12-031-0/+1
| | | | | | This wasn't done before because there was no advantage in "abstracting" it. This changed, and putting this into its own files is better than messing it into gl_common.c/h.
* build: don't install some files if only libmpv is builtwm42014-11-291-13/+15
| | | | | | | encoding-profiles.conf can be used by libmpv, but it won't load it from this path by default, so exclude it as well. Fixes #1293.
* lua: subprocess: move to osdep/subprocess-{win,posix}.cJames Ross-Gowan2014-11-221-0/+2
| | | | | | The subprocess code was already split into fairly general functions, separate from the Lua code. It's getting pretty big though, especially the Windows-specific parts, so move it into its own files.
* build: don't build win32 wrapper with --disable-cplayerwm42014-11-211-13/+14
| | | | It'll be useless.
* player: integrate ytdl_hook.luawm42014-11-191-18/+6
* ao/wasapi: new wasapi device monitoring interfaceJonathan Yong2014-11-171-0/+1
| | | | | | | | | | | Implement skeleton IMMNotificationClient to watch for changes in the sound device. This will make recovery possible from changes shared mode sample rate, bit depth, "enhancements"/effects and even graceful device removal. Signed-off-by: Kevin Mitchell <>
* audio: change how filters are inserted on playback speed changeswm42014-11-101-0/+1
| | | | | | | | | | Use a pseudo-filter when changing speed with resampling, instead of somehow changing a samplerate somewhere. This uses the same underlying mechanism, but is a bit more structured and cleaner. It also makes some of the following changes easier. Since we now always use filters to change audio speed, move most of the work set_playback_speed() does to recreate_audio_filters().
* vo_opengl: minimal EGL on X11 supportwm42014-11-041-0/+1
| | | | | | Pretty useless and only good for testing. Does not include any form of GLES support.
* build: remove bundle support from wafStefano Pigozzi2014-11-011-24/+1
| | | | Use TOOLS/ instead. It's just better and less hacky.
* Drop libquvi supportwm42014-10-251-2/+0
| | | | | | | | | | | No development activity (or even any sign of life) for almost a year. A replacement based on youtube-dl will probably be provided before the next mpv release. Ask on the IRC channel if you want to test. Simplify the Lua check too: libquvi linking against a different Lua version than mpv was a frequent issue, but with libquvi gone, no direct dependency uses Lua, and such a clash is rather unlikely.
* video: initial dxva2 supportwm42014-10-251-0/+1
| | | | | Shamelessly stolen from ffmpeg. It probably doesn't work - you can debug it yourself.
* rename ao_coreaudio_device.c -> ao_coreaudio_exclusive.cStefano Pigozzi2014-10-231-1/+1
| | | | This is so that the source file name matches the AO name
* input: implement --input-file on unix using the IPC supportAlessandro Ghedini2014-10-171-1/+0
* manpage: add JSON IPC documentationAlessandro Ghedini2014-10-171-1/+1
* input: implement JSON-based IPC protocolAlessandro Ghedini2014-10-171-0/+2
* cocoa: allow to disable apple remote at compile timeStefano Pigozzi2014-10-171-1/+1
| | | | | Actually doesn't remove the related flags so that one can still pass the option with the option doing nothing.
* client API: add qthelper.hppwm42014-10-131-1/+1
| | | | | | | | | | | | | | This provides some helper functions and classes for C++/Qt. As the top of qthelper.hpp says, this is built on top of the client API, and is a mere helper provided for convenience. Maybe this should be a separate library, but on the other hand I don't see much of a point in that. It's also header-only, but C++ people like such things. This makes it easier for us, because we don't need to care about ABI compatibility. The client API doesn't change, but bump it so that those who are using this header can declare a proper dependency.
* vf_vapoursynth: add standalone Lua scriptingwm42014-10-121-1/+1
* cocoa: remove usage of Objective-C categoriesStefano Pigozzi2014-10-121-1/+0
| | | | | Objective-C categories need special linker flags from the user when statically linking (-ObjC LDFLAG), so make everyone's life simpler and remove them.
* build: install input config files into doc dirwm42014-10-111-0/+5
| | | | | Users using binary packages don't have obvious access to them, so this seems like a good idea.
* build: make zsh completion directory configurablePhilip Sequeira2014-10-111-1/+1
| | | | Also, use the zsh default location (rather than the Debian one).
* cocoa: separate video view and events viewStefano Pigozzi2014-10-051-1/+2
* build: fix examples target pathsStefano Pigozzi2014-10-041-3/+3
| | | I 'broke' it in 78c362b. Sorry!
* build: allow to compile the cocoabasic.m exampleStefano Pigozzi2014-10-041-3/+9
* input: use libwaio for pipe input on Windowswm42014-09-141-1/+2
| | | | | | | | | | | | Use libwaio to read from pipes (stdin or named pipes) on Windows. This liberates us from nasty issues, such as pipes (as created by most programs) not being possible to read in a non-blocking or event-driven way. Although it would be possible to do that in a somewhat sane way on Vista+, it's still not easy, and on XP it's especially hard. libwaio handles these things for us. Move pipe.c to pipe-unix.c, and remove Windows specific things. Also adjust the input.c code to make this work cleanly.
* vo_wayland: pixel perfect buffersAlexander Preisinger2014-09-101-0/+2
| | | | | | | | | | | | | | | 1. Separate buffer and temporary file handling from the vo to make maintenance and reading code easier 2. Skip resizing as much as possible if back buffer is still busy. 3. Detach and mark osd buffers for deletion if we want to redraw them and they are still busy. This could be a possible case for the video buffers as well. Maybe better than double buffering. All the above steps made it possible to have resizing without any artifacts even for subtitles. Also fixes dozen of bugs only I knew, like broken subtitles for rgb565 buffers. I can now sleep at night again.
* osdep: add POSIX semaphore emulation for OSXwm42014-09-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | OSX is POSIX conformant, but it's a sad joke: it provides the <semaphore.h> prototype as the standard demands, but they're empty wrappers, and all functions just return ENOSYS. Emulate them similar to how osdep/io.h emulate filesystem functions on Windows. By including the header, working sem_* functions become available. To make it async-signal safe, use a pipe for wakeup (write() is AS-safe, but mutexes can't be). Actually I'm not sure anymore if we really need AS-safety, but for now the emulation can do it. On Linux, the system provides a far more efficient and robust implementation. We definitely want to avoid using the emulation if possible, so this code is active on OSX only. For convenience we always build the source file though, even if the implementation is disabled and no actual code is generated. (Linux provides working semaphores, but is formally not POSIX conformant. On OSX it's the opposite. Is POSIX a complete joke?)
* vo_corevideo: remove this VOStefano Pigozzi2014-09-061-1/+0
| | | | | | | This was kept in the codebase because it is slightly faster than --vo=opengl on really old Intel cards (from the GMA era). Time to kill it, and let it rest. Fixes #1061
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-291-3/+1
| | | | | | | | | bstr.c doesn't really deserve its own directory, and compat had just a few files, most of which may as well be in osdep. There isn't really any justification for these extra directories, so get rid of them. The compat/libav.h was empty - just delete it. We changed our approach to API compatibility, and will likely not need it anymore.
* input: redo how --input-file is handledwm42014-08-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Abandon the "old" infrastructure for --input-file (mp_input_add_fd(), select() loop, non-blocking reads). Replace it with something that starts a reader thread, using blocking input. This is for the sake of Windows. Windows is a truly insane operating system, and there's not even a way to read a pipe in a non-blocking way, or to wait for new input in an interruptible way (like with poll()). And unfortunately, some want to use pipe to send input to mpv. There are probably (slightly) better IPC mechanisms available on Windows, but for the sake of platform uniformity, make this work again for now. On Vista+, CancelIoEx() could probably be used. But there's no way on XP. Also, that function doesn't work on wine, making development harder. We could forcibly terminate the thread, which might work, but is unsafe. So what we do is starting a thread, and if we don't want the pipe input anymore, we just abandon the thread. The thread might remain blocked forever, but if we exit the process, the kernel will forcibly kill it. On Unix, just use poll() to handle this. Unfortunately the code is pretty crappy, but it's ok, because it's late and I wanted to stop working on this an hour ago. Tested on wine; might not work on a real Windows.
* build: fix libmpv build when using system wafJan Palus2014-08-131-1/+3
| | | | | | | Since the 'syms' tool is shipped in waf's extras, when using system waf the default tool overrides our own. Force our syms tool by providing the tooldir. Fixes #1006
* build: add hacks to force waf to generate valid .pc fileswm42014-08-071-0/+8
| | | | Don't like this? You're invited to fix this crap.
* build: allow to disable building the cplayerStefano Pigozzi2014-08-061-10/+12
* cocoa: macosx_application needs cocoa-applicationFRAU KOUJIRO2014-08-061-1/+1
* build: move def file to libmpv/wm42014-08-051-1/+1
| | | | This is more consistent with mpv.pc, which is also in libmpv/.
* client API: add and use the MPV_MAKE_VERSION macrowm42014-08-051-5/+4
| | | | | | | This is probably nicer. The actual version number doesn't change (other than the minor being incremented). The "| 0UL" is to make the type unsigned long int, like it was before.
* build: list exported symbols explicitlywm42014-08-051-1/+1
| | | | | | | | | | | Instead of using a regex to match names to be exported from the libmpv dynamic shared library, use a libmpv.def file, which lists all exported functions explicitly. This reduces the platform specifics in I'm not sure if the separate compile_sym task is still needed (it could probably be collapsed, which would concentrate the platform specifics into one place).
* Improve setting AVOptionswm42014-08-021-1/+0
| | | | | | | | Use OPT_KEYVALUELIST() for all places where AVOptions are directly set from mpv command line options. This allows escaping values, better diagnostics (also no more "pal"), and somehow reduces code size. Remove the old crappy option parser (av_opts.c).
* video/filter: add vf_bufferwm42014-07-301-0/+1
| | | | Mostly useful for debugging.
* Add Plan 9-style barrierswm42014-07-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Plan 9 has a very interesting synchronization mechanism, the rendezvous() call. A good property of this is that you don't need to explicitly initialize and destroy a barrier object, unlike as with e.g. POSIX barriers (which are mandatory to begin with). Upon "meeting", they can exchange a value. This mechanism will be nice to synchronize certain stages of initialization between threads in the following commit. Unlike Plan 9 rendezvous(), this is not implemented with a hashtable, because that would require additional effort (especially if you want to make it actually scele). Unlike the Plan 9 variant, we use intptr_t instead of void* as type for the value, because I expect that we will be mostly passing a status code as value and not a pointer. Converting an integer to void* requires two cast (because the integer needs to be intptr_t), the other way around it's only one cast. We don't particularly care about performance in this case either. It's simply not important for our use-case. So a simple linked list is used for waiters, and on wakeup, all waiters are temporarily woken up.
* Revert "Remove DVD and Bluray support"wm42014-07-151-0/+6
| | | | | | This reverts commit 4b93210e0c244a65ef10a566abed2ad25ecaf9a1. *shrug*
* Remove DVD and Bluray supportwm42014-07-141-6/+0
| | | | It never worked well. Just remux your DVD and BD images to mkv.
* tv: move demuxer parts to separate filewm42014-07-051-0/+1
| | | | | Now all demuxer implementations (at least demuxer API-wise) are in the demux directory.
* dvd, bluray, cdda: add demux_disc containing all related hackswm42014-07-051-0/+1
| | | | | | | | | | | | DVD and Bluray (and to some extent cdda) require awful hacks all over the codebase to make them work. The main reason is that they act like container, but are entirely implemented on the stream layer. The raw mpeg data resulting from these streams must be "extended" with the container-like metadata transported via STREAM_CTRLs. The result were hacks all over demux.c and some higher-level parts. Add a "disc" pseudo-demuxer, and move all these hacks and special-cases to it.
* demux: move packet functions to a separate source filewm42014-07-051-0/+1
* ao_coreaudio: move spdif code to a new AOStefano Pigozzi2014-07-021-0/+1
| | | | | | | | | | | | | | | | The mplayer1/2/mpv CoreAudio audio output historically contained both usage of AUHAL APIs (these go through the CoreAudio audio server) and the Device based APIs (used only for output of compressed formats in exclusive mode). The latter is a very unwieldy and low level API and pretty much forces us to write a lot of code for little workr. Also with the widespread of HDMI, the actual need for outputting compressed audio directly to the device is getting lower (it was very useful with S/PDIF for bandwidth constraints not allowing a number if channels transmitted in LPCM). Considering how invasive it is (uses hog/exclusive mode), the new AO (`ao_coreaudio_device`) is not going to be autoprobed but the user will have to select it.
* stream: add a file cachewm42014-06-221-0/+1
| | | | | | | | | For remarks, pretty much see the manpage additions. Could help with network streams that require too much seeking (maybe), or might be extended to help with the use case of watching and downloading a file at the same time. In general, it might be a useless feature and could be removed again.
* DOCS: remove en/ sub-directorywm42014-06-201-6/+6
| | | | | This additional sub-directory doesn't serve any purpose anymore. Get rid of it.
* client API: declare as stablewm42014-06-201-3/+1
| | | | | | | | It is reasonably stable, so all further changes will be versioned. Also change how the libmpv version number is generated. Fix the patch version number to 0; I don't think we have a use for this. In particular, the version doesn't version mpv, just the client API.
* build: remove some trailing whitespacewm42014-06-201-1/+1
* build: add '--enable-libmpv-static' optionxylosper2014-06-161-13/+27
| | | | Signed-off-by: wm4 <wm4@nowhere>
* win32: implement --priority differentlywm42014-06-121-1/+0
| | | | | | | Does anyone actually use this? For now, update it, because it's the only case left where an option points to a global variable (and not a struct offset).
* build: generate and install zsh completion scriptAlessandro Ghedini2014-06-081-0/+6
* build: prevent installation of client API examplewm42014-06-061-0/+1
| | | | | | | | This was never intended to be installed; waf just picked it up automagically. There's also a closed ticket on github where someone complains that the program "simple" is installed, and I didn't realize at this point that it was actually installed by default when enabling the client API.
* stream: remove VCD supportwm42014-06-011-1/+0
| | | | | | | | | If a single person complains, I will readd it. But I don't expect that this will happen. The main reason for removing this is that it's some of the most unclean code remaining, it's unmaintained, and I've never ever heard of someone using it.
* lua/osc: forgot some changed files in previous commitChrisK22014-05-231-0/+4
* player: reorganize how lua scripts are loadedwm42014-05-131-0/+1
| | | | | | Make loading of scripts independent of Lua. Move some of the loading code from lua.c to scripting.c, and make it easier to add new scripting backends.
* video/out: separate out code to compute window sizewm42014-05-061-0/+1
| | | | | | | | | | | | | | | | | | | Currently, vo_reconfig() calculates the requested window size and sets the vo->dwidth/dheight fields _if_ VOCTRL_UPDATE_SCREENINFO is implemented by the VO or the windowing backend. The window size can be different from the display size if e.g. the --geometry option is used. It will also set the vo->dx/dy fields and read vo->xinerama_x/y. It turned out that this is very backwards and actually requires the windowing backends to workaround these things. There's also MPOpts.screenwidth/screenheight, which used to map to actual options, but is now used only to communicate the screen size to the vo.c code calculating the window size and position. Change this by making the window geometry calculations available as separate functions. This commit doesn't change any VO code yet, and just emulates the old way using the new functions. VO code will remove its usage of VOCTRL_UPDATE_SCREENINFO and use the new functions directly.
* vdpau: add a postprocessing pseudo-filterwm42014-05-021-0/+2
| | | | | | | | | | | This factors out some code from vo_vdpau.c, especially deinterlacing handling. The intention is to use this for vo_vdpau.c to make the logic significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to allow selecting deinterlace and postprocessing modes. As of this commit, the filter actually does nothing, since both vo_vdpau and vo_opengl treat the generated images as normal vdpau images. This will change in the following commits.
* dispatch: move into its own source filewm42014-04-231-1/+2
| | | | | | | This was part of osdep/threads.c out of laziness. But it doesn't contain anything OS dependent. Note that the rest of threads.c actually isn't all that OS dependent either (just some minor ifdeffery to work around the lack of clock_gettime() on OSX).
* Remove CPU detection and inline asm handlingwm42014-04-191-1/+0
| | | | | | | | | | | | | | Not needed anymore. I'm not opposed to having asm, but inline asm is too much of a pain, and it was planned long ago to eventually get rid fo all inline asm uses. For the note, the inline asm use that was removed with the previous commits was almost worthless. It was confined to video filters, and most video filtering is now done with libavfilter. Some mpv filters (like vf_pullup) actually redirect to libavfilter if possible. If asm is added in the future, it should happen in the form of external files.
* Remove radio://wm42014-04-131-1/+0
| | | | | It was disabled by default, works only for analogue radio, and I bet nobody uses it.
* mp_tags: move generic mp_tags stuff into its own .c/.h files in common/Kevin Mitchell2014-04-131-0/+1
| | | | | | rename add_metadata to the more genera/descriptive mp_tags_copy_items_from_av_dictionary Signed-off-by: wm4 <wm4@nowhere>
* player: remove ASX, SMIL and NSC playlist parserswm42014-04-131-2/+0
| | | | | | | | | | | | | | | | | | | These playlist parsers are all what's left from the old mplayer playlist parsing code. All of it is old code that does little error checking; the type of C string parsing code that gives you nightmare. Some playlist parsers have been rewritten and are located in demux_playlist.c. The removed formats were not reimplemented. ASX and SMIL use XML, and since we don't want to depend on a full blown XML parser, this is not so easy. Possibly these formats could be supported by writing a very primitive XML-like lexer, which would lead to success with most real world files, but I haven't attempted that. As for NSC, I couldn't find any URL that worked with MPlayer, and in general this formats seems to be more than dead. Move playlist_parse_file() to playlist.c. It's pretty small now, and basically just opens a stream and a demuxer. No use keeping playlist_parser.c just for this.
* video: add VapourSynth filter bridgewm42014-04-121-0/+1
| | | | | | | | | | | | Mainly meant to apply simple VapourSynth filters to video at runtime. This has various restrictions, which are listed in the manpage. Additionally, this actually copies video frames when converting frame references from mpv to VapourSynth, and a second time when going from VapourSynth to mpv. This is inefficient and could probably be easily improved. But for now, this is simpler, and in fact I'm not sure if we even can references VapourSynth frames after the core has been destroyed.
* player: rename dvdnav to discnavxylosper2014-03-301-1/+1
| | | | | Now, navigation works both of DVD and non-BD-J Blu-ray. Therefore, rename all 'dvdnav' strings which are not DVD specific to 'discnav'
* stream_cdda: remove unused stuffwm42014-03-261-1/+0
| | | | | | This cd_info_t struct was practically unused. The only thing it did was storing the track name of the form "Track %d" in a very roundabout way. Remove it. (It made more sense when there was still CDDB support.)
* build: simplify libavfilter configure checkswm42014-03-161-2/+2
| | | | | This is all not needed anymore. In particular, remove all configure switches except --enable-libavfilter.
* af_lavrresample: remove avresample_set_channel_mapping() fallbackswm42014-03-161-1/+0
| | | | | | | This function is now always available. Also remove includes of reorder_ch.h from some AOs (these are just old relicts).
* sub: remove old MPlayer DVD sub decoderwm42014-03-161-2/+0
| | | | | The DVD sub decoder in Libav 9 was broken/incomplete, so we kept the MPlayer decoder around. Now it's not needed anymore.
* vd_lavc: remove compatibility crapwm42014-03-161-2/+0
| | | | | | | All this code was needed for compatibility with very old libavcodec versions only (such as Libav 9). Includes some now-possible simplifications too.
* build: automagically extract client library versionwm42014-03-121-2/+11
| | | | | | | | | | This reads MPV_CLIENT_API_VERSION from the source header, and turns it into a 3 part version number. E.g. if MPV_CLIENT_API_VERSION were 0x12abcdef, this would result in "18.171.773615" (8 bits, 8 bits, 16 bits). We'll see if this is actually useful, or if it's too clever.
* build: rename --enable-shared switchwm42014-03-111-1/+1
| | | | | | | Rename it to --enable-libmpv-shared. The option name didn't really tell much. When we add the possibility to create a static library, it would also be bad if that were named --enable-static (because it would sound like it does what --static-build does).
* build: fix version in mpv.pcAlessandro Ghedini2014-03-111-1/+1
* ao_wasapi: Split into 2 filesDiogo Franco (Kovensky)2014-03-111-0/+1
| | | | | | ao_wasapi.c was almost entirely init code mixed with option code and occasionally actual audio handling code. Split most things to ao_wasapi_utils.c and keep the audio handling code in ao_wasapi.c.
* build: install client.h under mpv/ instead of libmpv/Alessandro Ghedini2014-03-111-1/+1
* libmpv: add pkg-config fileAlessandro Ghedini2014-03-111-0/+12
* audio/out: feed AOs from a separate threadwm42014-03-091-0/+2
| | | | | | | | | | | | | | | | | | This has 2 goals: - Ensure that AOs have always enough data, even if the device buffers are very small. - Reduce complexity in some AOs, which do their own buffering. One disadvantage is that performance is slightly reduced due to more copying. Implementation-wise, we don't change ao.c much, and instead "redirect" the driver's callback to an API wrapper in push.c. Additionally, we add code for dealing with AOs that have a pull API. These AOs usually do their own buffering (jack, coreaudio, portaudio), and adding a thread is basically a waste. The code in pull.c manages a ringbuffer, and allows callback-based AOs to read data directly.
* build: add SONAME to libmpv.sowm42014-02-111-0/+1
* Add a client API examplewm42014-02-101-0/+11
* build: add option to build a librarywm42014-02-101-1/+18
| | | | | | | | | | | | | This library will export the client API functions. Note that this doesn't allow compiling the command line player to link against this library yet. The reason is that there's lots of weird stuff required to setup the execution environment (mostly Windows and OSX specifics), as well as things which are out of scope of the client API and every application has to do on its own. However, since the mpv command line player basically reuses functions from the mpv core to implement these things, it's not very easy to separate the command line player form the mpv core.
* Add a client APIwm42014-02-101-0/+1
| | | | | | | Add a client API, which is intended to be a stable API to get some rough control over the player. Basically, it reflects what can be done with input.conf commands or the old slavemode. It will replace the old slavemode (and enable the implementation of a new slave protocol).
* waf: rename --enable-sdl to --enable-sdl1wm42014-01-251-1/+1
| | | | Grossly misleading.
* w32: use the w32_common keymap in terminal-win tooJames Ross-Gowan2014-01-191-0/+2
* cocoa: add application icon to the Dock when run from CLIStefano Pigozzi2014-01-141-0/+4
| | | | | | | | | | Application icon was added to the Dock only when run inside of a bundle. That was handled automatically by OS X using the Info.plist definition. To add the Application icon when run as a CLI program, I used the samme approach in the X11 code and loaded the icon as a static binary blob inside of mpv's binary. This is the simplest approach as it avoid headackes when relocating the binary and such.
* waf: do not use TaskGen for PDF build ruleMartin Herkt2014-01-081-14/+6
| | | | No longer necessary.
* Switch PDF manual generation to rst2pdfMartin Herkt2014-01-081-16/+4
| | | | | | | This finally gets rid of the LaTeX dependency. We should actually be using docultils directly here, but I didn't do this because of all the potential Python 2/3 breakage.
* input: move files drag and drop to a new event.c fileStefano Pigozzi2014-01-041-0/+1
| | | | | event.c will be used to feed the input queue with 'global' events that don't mesh well with the usual check_events path in mpv.
* Add Windows console wrapper program ( Herkt2014-01-021-0/+13
* Install encoding-profiles.conf by defaultwm42013-12-281-0/+2
| | | | | | | | | | | | This is probably useful. Note that this includes a small, stupid hack to prevent loading of the config file if vf_lavfi is not available. The profile by default uses vf_lavfi, and the config parser will output errors if vf_lavfi is not available. As another caveat, we install the example profile even if encoding is disabled (though we don't load it, since this would print errors).
* input: split off some code from input.c to separate fileswm42013-12-261-0/+3
| | | | This is mostly just moving code around.
* Rename getch2....c/h to terminal....c/hwm42013-12-191-2/+2
| | | | | "getch2" really tells nothing about what the heck this code does. It'd be even worse when moving the rest of terminal handling code there.
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-15/+19
* Move options/config related files from mpvcore/ to options/wm42013-12-171-7/+9
| | | | | | | | | Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
* Move libquvi stuff to stream/resolve/wm42013-12-171-2/+2
* Move mpvcore/input/ to input/wm42013-12-171-4/+6
* Rename mp_lua.c/h to lua.c/hwm42013-12-171-1/+1
* Move mpvcore/player/ to player/wm42013-12-171-22/+24
* Add prelimimary (basic, possibly broken) dvdnav supportwm42013-12-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | This readds a more or less completely new dvdnav implementation, though it's based on the code from before commit 41fbcee. Note that this is rather basic, and might be broken or not quite usable in many cases. Most importantly, navigation highlights are not correctly implemented. This would require changes in the FFmpeg dvdsub decoder (to apply a different internal CLUT), so supporting it is not really possible right now. And in fact, I don't think I ever want to support it, because it's a very small gain for a lot of work. Instead, mpv will display fake highlights, which are an approximate bounding box around the real highlights. Some things like mouse input or switching audio/subtitles stream using the dvdnav VM are not supported. Might be quite fragile on transitions: if dvdnav initiates a transition, and doesn't give us enough mpeg data to initialize video playback, the player will just quit. This is added only because some users seem to want it. I don't intend to make mpv a good DVD player, so the very basic minimum will have to do. How about you just convert your DVD to proper video files?
* video: move VO reinit from filter chain to playerwm42013-12-101-1/+0
| | | | | | | | | This gets rid of the vf_vo pseudo-filter. It ends the idea of MPlayer's architecture that the VO is just a (terminating) video filter. It didn't really work for us with respect to video timing (the "end" of the video chain isn't really made for video timing, and making it do so would be awkward), and now we're removing it entirely. We will be able to fix some things, such as properly draining video on reconfiguration.
* build: osx: set chmod to 755 for non-bundle binary during installStefano Pigozzi2013-12-041-1/+2
| | | | | When installing the bundle we also manually install the origianl binary. Waf defaults to chmod 644, so we must explicitely set it to 755.
* video/filter: remove vf_down3drightwm42013-12-041-1/+0
| | | | | | | | Apparently you can get this with: stereo3d=ab[2]{l,r}:sbs[2]{l,r} So it seems the filter is redundant and can be removed. Also see FFmpeg commit 2f11aa141a01.
* vo_opengl: support for vda hardware decodingStefano Pigozzi2013-12-021-0/+1
| | | | | | | | | | | The harder work was done in the previous commits. After that this feature comes out almost for free. The only problem is I can't get the textures created with CGLTexImageIOSurface2D to download properly, thus the code performs download using some CoreVideo APIs. If someone knows why download of textures created with CGLTexImageIOSurface2D doesn't work please contact me :)
* build: make pthreads mandatorywm42013-11-281-1/+1
| | | | | | | | | | | pthreads should be available anywhere. Even if not, for environment without threads a pthread wrapper could be provided that can't actually start threads, thus disabling features that require threads. Make pthreads mandatory in order to simplify build dependencies and to reduce ifdeffery. (Admittedly, there wasn't much complexity, but maybe we will use pthreads more in the future, and then it'd become a real bother.)
* build: make cygwin use *nix timersStefano Pigozzi2013-11-261-1/+0
* build: add a gdi check for windowsStefano Pigozzi2013-11-261-2/+1
| | | | | Incidentally this seems wrong in the configure as well because only gl-win32 depends on it instead of also making direct3d depend on this (as I did here).
* build: work around bug in waf's bundle installationStefano Pigozzi2013-11-251-0/+5
| | | | | | waf wrongly installs resources to BundleRoot/Resources instead of BundleRoot/Contents/Resources. Will post a patch to them later. Either way, this must worked around until the next waf patch release.
* build: add install_files call after the mpv target was definedStefano Pigozzi2013-11-241-2/+3
| | | | | This makes it work on cold compiles when there is no `build/` directory and one does ./waf configure && ./waf install (i.e.: no ./waf build).
* build: also install mpv CLI binary when building OS X bundleStefano Pigozzi2013-11-241-0/+2
* Rename sub.c/.h to osd.c/.hwm42013-11-241-1/+1
| | | | | This was way too misleading. osd.c merely calls the subtitle renderers, instead of actually dealing with subtitles.
* video: merge vd.c into dec_video.cwm42013-11-231-1/+0
| | | | | I don't feel like the separation ever made sense, and it was hard to tell which file a function you were looking for was in.
* build: fix install path for manualStefano Pigozzi2013-11-231-1/+1
| | | | | Appending man1 to the MANDIR was forgotten, so the manual was installed in the wrong path.
* switch the build system to wafStefano Pigozzi2013-11-211-0/+459
This commit adds a new build system based on waf. configure and Makefile are deprecated effective immediately and someday in the future they will be removed (they are still available by running ./old-configure). You can find how the choice for waf came to be in `DOCS/waf-buildsystem.rst`. TL;DR: we couldn't get the same level of abstraction and customization with other build systems we tried (CMake and autotools). For guidance on how to build the software now, take a look at and the cross compilation guide. CREDITS: This is a squash of ~250 commits. Some of them are not by me, so here is the deserved attribution: - @wm4 contributed some Windows fixes, renamed configure to old-configure and contributed to the bootstrap script. Also, GNU/Linux testing. - @lachs0r contributed some Windows fixes and the bootstrap script. - @Nikoli contributed a lot of testing and discovered many bugs. - @CrimsonVoid contributed changes to the bootstrap script.