summaryrefslogtreecommitdiffstats
path: root/wscript_build.py
Commit message (Collapse)AuthorAgeFilesLines
* 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 mpv.com 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. http://msdn.microsoft.com/en-us/library/windows/desktop/dd371417%28v=vs.85%29.aspx Signed-off-by: Kevin Mitchell <kevmitch@gmail.com>
* 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/osxbundle.py 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 wh