summaryrefslogtreecommitdiffstats
path: root/Makefile
Commit message (Collapse)AuthorAgeFilesLines
* Replace tallocwm42013-10-131-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are multiple reasons to do this. One big reason is the license: talloc is LGPLv3+, which forces mpv to be licensed as GPLv3+. Another one is that our talloc copy contains modifications, which makes it essentially incompatible with upstream talloc (in particular, our version aborts on out of memory conditions - well, it wasn't my idea). Updating from upstream is also a bit involved - the talloc source is not really organized in a way to allow copying it into projects (and this isn't an intended use-case). Finally, talloc is kind of big and bloated. The replacement halves the amount of code - mainly because we didn't use all talloc features. It's even more extreme if you compare upstream talloc (~4700 lines) and the new allocator without talloc compat (~900 lines). The replacement provides all features we need. It also doesn't clash with talloc. (The talloc compatibility wrapper uses macros to avoid introducing linker-level symbols which could clash with libtalloc.) It also tries to lower the overhead (only 4 words opposed to 10 words in talloc for leaf nodes in release mode). Debugging features like leak reporting can be enabled at compile time and add somewhat more overhead. Though I'm not sure whether the overhead reduction was actually successful: allocations with children need an "extra" header, which adds plenty of overhead, and it turns out that almost half of all allocations have children. Maybe the implementation could be simplified and the extra header removed - even then, overhead would be lower than talloc's. Currently, debugging features can be entirely deactivated by defining NDEBUG - I'm not sure if anything defines this directly yet, though. Unlike in talloc, the leak reporting stuff is thread-safe. (That's also why it's far less elegant, and requires extra list pointers.) Comes with a compatibility layer, so no changes to mpv source code are needed. The idea is that we will pretend to be using talloc for a while, so that we can revert to our old talloc implementation at any time for debugging purposes. Some inspiration was taken from Mesa's ralloc: http://cgit.freedesktop.org/mesa/mesa/tree/src/glsl/ralloc.h This is another talloc replacement, but lacks some features we need (getting size of an allocation, debugging features, being able to access children in the dtor). There's some information in ta/README what will happen next and how the transition is expected to progress.
* audio/out: add sndio supportChristian Neukirchen2013-10-031-0/+2
| | | | Based on an earlier patch for mplayer by Alexandre Ratchov <alex@caoua.org>
* cocoa_common: split the code, refactoring and cleanupsStefano Pigozzi2013-09-281-3/+7
| | | | | | | | | Split the code to several files. The GUI elements now each have they own files and private state. The original code was a mess to respect the retarded mplayer convention of having everything in a single file. This commit also seems to fix the long running bug of artifacts showing randomly when going fullscreen using nVidia GPUs.
* Add the on-screen-controllerChrisK22013-09-261-0/+5
| | | | Signed-off-by: wm4 <wm4@nowhere>
* Add initial Lua scripting supportwm42013-09-261-0/+12
| | | | | | | | | | | | | | | | | | | | | | This is preliminary. There are still tons of issues, and any aspect of scripting may change in the future. I decided to merge this (preliminary) work now because it makes it easier to develop it, not because it's done. lua.rst is clear enough about it (plus some sarcasm). This requires linking to Lua. Lua has no official pkg-config file, but there are distribution specific .pc files, all with different names. Adding a non-pkg-config based configure test was considered, but we'd rather not. One major complication is that libquvi links against Lua too, and if the Lua version is different from mpv's, you will get a crash as soon as libquvi uses Lua. (libquvi by design always runs when a file is opened.) I would consider this the problem of distros and whoever builds mpv, but to make things easier for users, we add a terrible runtime test to the configure script, which probes whether libquvi will crash. This is disabled when cross-compiling, but in that case we hope the user knows what he is doing.
* vaapi: add vf_vavpp and use it for deinterlacingxylosper2013-09-251-1/+3
| | | | | | | | Merged from pull request #246 by xylosper. Minor cosmetic changes, some adjustments (compatibility with older libva versions), and manpage additions by wm4. Signed-off-by: wm4 <wm4@nowhere>
* install: don’t force append /mpv to docdirMartin Herkt2013-09-231-3/+3
|
* macosx: move bundle path stuff to path-macosx.mStefano Pigozzi2013-09-181-1/+1
| | | | This makes the code uniform to how stuff was handled for Windows in 1cb55ceb.
* path, win32: redo user configfile path handlingwm42013-09-181-0/+1
| | | | | | | | | | | | | | | | | Remove the ifdef hell from mp_find_user_config_file(). Move the win32 specific code (for MinGW and Cygwin) to path-win.c. The behavior should be about the same, but I can't be sure due to lack of testing and because the old path.c code was hard to follow. (I expect those who care about windows will fix things, should issues pop up - sorry.) One difference is that the new code will always force MPV_HOME. It looks like the old code preferred the mpv config dir in the exe dir if it exists. Also, make sure MP_PATH_MAX has enough space, even if the equivalent wchar_t string is not 0-terminated with PATH_MAX (because apparently the winapi doesn't require this). (Actually, maybe we should just kill all uses of PATH_MAX/MP_PATH_MAX.)
* Add mpv.desktop, let Makefile install the desktop file and the iconswm42013-09-151-4/+24
| | | | | | | | | | | | | | | | | | | The mpv.desktop file is taken from the Arch package [1]. It appears to be based on the mplayer2 git mplayer.desktop file (e.g. very similar MimeType field), with minor modifications applied by Arch package maintainers. Note that for now, this doesn't show a terminal (Terminal=false), which might not always be ideal. For example, if the file is audio only, or if VO initialization fails for some reason, mpv will run in the background and play audio without showing a window. But users prefer running it without terminal, and don't want to play audio files with it. Maybe a --force-window option will be added in the future, which would always create a VO window, and compensate for these issues. [1] https://aur.archlinux.org/packages/mpv-git/
* macosx: always active bundle path lookup if cocoa is activeStefano Pigozzi2013-09-121-1/+1
| | | | | This is not really something you want to disable anyway. If there is no bundle the code already does it's falbacks anyway.
* Makefile: update DIRS to fix cleaningStefano Pigozzi2013-09-111-1/+2
| | | | Commits 40624100 and 72f2942df didn't update the variable accordingly.
* Makefile: restore manpage dependency ruleswm42013-09-101-0/+9
| | | | | | Broken by commit 0054073. Also add them to the pdf target.
* Add PDF manual targetMartin Herkt2013-09-091-13/+23
| | | | | | This builds a PDF version of the manpage using rst2latex and pdflatex, and installs it to PREFIX/share/doc/mpv by default.
* x11: add window iconwm42013-09-011-0/+5
| | | | | | | | | | | | | | | | | | | | | The png file added to etc/ are taken from the link mentioned in commit 303096b, except that they have been converted to 16 bit, sRGB (with color profile info dropped, if there was one), and transparent pixels reset for better compression. The file x11_icon.bin is generated by gen-x11-icon.sh. I'm adding it to the git repo directly, because the script requires ImageMagick, and we don't want to make building even more complicated. The way how this is done is basically a compromise between effort required in x11_common.c and in gen-x11-icon.sh. Ideally, x11_icon.bin would be directly in the format as required by _NET_WM_ICON, but trying to write the binary width/height values from shell would probably be a nightmare, so here we go. The zlib code in x11_common.c is lifted from demux_mkv.c, with some modifications (like accepting a gzip header, because I don't know how to make gzip write raw compressed data).
* stream: add uncompressed rar supportwm42013-08-261-0/+2
| | | | | | | | | | | | | | | | | Apparently, it is popular to store large files in uncompressed rar archives. Extracting files is not practical, and some media players suport playing directly from uncompressed rar (at least VLC and some DirectShow components). Storing or accessing files this way is completely idiotic, but it is a common practice, and the ones subjected to this practice can't do much to change this (at least that's what I assume/hope). Also, it's a feature request, so we say yes. This code is mostly taken from VLC (commit f6e7240 from their git tree). We also copy the way this is done: opening a rar file by itself yields a playlist, which contains URLs to the actual entries in the rar file. Compressed entries are simply skipped.
* core: add a playlist demuxerwm42013-08-261-1/+2
| | | | | | | | | Modeled after the old playlist_parser.c, but actually new code, and it works a bit differently. Demuxers (and sometimes streams) are the component that should be used to open files and to determine the file format. This was already done for subtitles, but playlists still use a separate code path.
* wayland: shm based software renderingAlexander Preisinger2013-08-251-0/+1
| | | | | | | | | | | | | | | | | | | | A wayland output based on shared memory. This video output is useful for x11 free systems, because the current libGL in mesa provides GLX symbols. It is also useful for embedded systems where the wayland backend for EGL is not implemented like the raspberry pi. At the moment only rgb formats are supported, because there is still no compositor which supports planar formats like yuv420p. The most used compositor at the moment, weston, supports only BGR0, BGRA and BGR16 (565). The BGR16 format is the fastest to convert and render without any noticeable differences to the BGR32 formats. For this reason the current (very basic) auto-detection code will prefer the BGR16 format. Also the weston source code indicates that the preferred format is BGR16 (RGB565). There are 2 options: * default-format (yes|no) Which uses the BGR32 format * alpha (yes|no) For outputting images and videos with transparencies
* video: add vda decode support (with hwaccel) and direct renderingStefano Pigozzi2013-08-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Decoding H264 using Video Decode Acceleration used the custom 'vda_h264_dec' decoder in FFmpeg. The Good: This new implementation has some advantages over the previous one: - It works with Libav: vda_h264_dec never got into Libav since they prefer client applications to use the hwaccel API. - It is way more efficient: in my tests this implementation yields a reduction of CPU usage of roughly ~50% compared to using `vda_h264_dec` and ~65-75% compared to h264 software decoding. This is mainly because `vo_corevideo` was adapted to perform direct rendering of the `CVPixelBufferRefs` created by the Video Decode Acceleration API Framework. The Bad: - `vo_corevideo` is required to use VDA decoding acceleration. - only works with versions of ffmpeg/libav new enough (needs reference refcounting). That is FFmpeg 2.0+ and Libav's git master currently. The Ugly: VDA was hardcoded to use UYVY (2vuy) for the uploaded video texture. One one end this makes the code simple since Apple's OpenGL implementation actually supports this out of the box. It would be nice to support other output image formats and choose the best format depending on the input, or at least making it configurable. My tests indicate that CPU usage actually increases with a 420p IMGFMT output which is not what I would have expected. NOTE: There is a small memory leak with old versions of FFmpeg and with Libav since the CVPixelBufferRef is not automatically released when the AVFrame is deallocated. This can cause leaks inside libavcodec for decoded frames that are discarded before mpv wraps them inside a refcounted mp_image (this only happens on seeks). For frames that enter mpv's refcounting facilities, this is not a problem since we rewrap the CVPixelBufferRef in our mp_image that properly forwards CVPixelBufferRetain/CvPixelBufferRelease calls to the underying CVPixelBufferRef. So, for FFmpeg use something more recent than `b3d63995` for Libav the patch was posted to the dev ML in July and in review since, apparently, the proposed fix is rather hacky.
* video: add vaapi decode and output supportwm42013-08-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is based on the MPlayer VA API patches. To be exact it's based on a very stripped down version of commit f1ad459a263f8537f6c from git://gitorious.org/vaapi/mplayer.git. This doesn't contain useless things like benchmarking hacks and the demo code for GLX interop. Also, unlike in the original patch, decoding and video output are split into separate source files (the separation between decoding and display also makes pixel format hacks unnecessary). On the other hand, some features not present in the original patch were added, like screenshot support. VA API is rather bad for actual video output. Dealing with older libva versions or the completely broken vdpau backend doesn't help. OSD is low quality and should be rather slow. In some cases, only either OSD or subtitles can be shown at the same time (because OSD is drawn first, OSD is prefered). Also, libva can't decide whether it accepts straight or premultiplied alpha for OSD sub-pictures: the vdpau backend seems to assume premultiplied, while a native vaapi driver uses straight. So I picked straight alpha. It doesn't matter much, because the blending code for straight alpha I added to img_convert.c is probably buggy, and ASS subtitles might be blended incorrectly. Really good video output with VA API would probably use OpenGL and the GL interop features, but at this point you might just use vo_opengl. (Patches for making HW decoding with vo_opengl have a chance of being accepted.) Despite these issues, decoding seems to work ok. I still got tearing on the Intel system I tested (Intel(R) Core(TM) i3-2350M). It was also tested with the vdpau vaapi wrapper on a nvidia system; however this was rather broken. (Fortunately, there is no reason to use mpv's VAAPI support over native VDPAU.)
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-39/+39
| | | | Followup commit. Fixes all the files references.
* Remove m_structwm42013-08-021-1/+0
| | | | Not needed anymore.
* vo_corevideo: move to C from Objective-CStefano Pigozzi2013-08-011-1/+1
| | | | | This file was alredy written in C. The only remaining part was the file exension and `#import`s.
* mpv.rc: update Windows iconJames Ross-Gowan2013-07-301-1/+1
| | | | Based on the OSX bundle icon.
* build: fix build with vdpau, simplifywm42013-07-291-4/+0
| | | | | | | | | | | | Instead of generating vdpau_template.c with a Perl script, just include the generated file in git. This is ok because it changes very rarely, and the script is larger than the output it generates. It also simplify the Makefile, and fixes the build. The problem was that transitive dependencies do not work with generated files: there is no dependency information yet when building it the first time. I overlooked this because I didn't delete the .d files for testing (which contained the correct dependencies, but only _after_ a first successful build).
* build: fix vdpau_template.c generationwm42013-07-291-1/+1
|
* vdpau: split off decoder parts, use "new" libavcodec vdpau hwaccel APIwm42013-07-281-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the decoder parts from vo_vdpau.c to a new file vdpau_old.c. This file is named so because because it's written against the "old" libavcodec vdpau pseudo-decoder (e.g. "h264_vdpau"). Add support for the "new" libavcodec vdpau support. This was recently added and replaces the "old" vdpau parts. (In fact, Libav is about to deprecate and remove the "old" API without deprecation grace period, so we have to support it now. Moreover, there will probably be no Libav release which supports both, so the transition is even less smooth than we could hope, and we have to support both the old and new API.) Whether the old or new API is used is checked by a configure test: if the new API is found, it is used, otherwise the old API is assumed. Some details might be handled differently. Especially display preemption is a bit problematic with the "new" libavcodec vdpau support: it wants to keep a pointer to a specific vdpau API function (which can be driver specific, because preemption might switch drivers). Also, surface IDs are now directly stored in AVFrames (and mp_images), so they can't be forced to VDP_INVALID_HANDLE on preemption. (This changes even with older libavcodec versions, because mp_image always uses the newer representation to make vo_vdpau.c simpler.) Decoder initialization in the new code tries to deal with codec profiles, while the old code always uses the highest profile per codec. Surface allocation changes. Since the decoder won't call config() in vo_vdpau.c on video size change anymore, we allow allocating surfaces of arbitrary size instead of locking it to what the VO was configured. The non-hwdec code also has slightly different allocation behavior now. Enabling the old vdpau special decoders via e.g. --vd=lavc:h264_vdpau doesn't work anymore (a warning suggesting the --hwdec option is printed instead).
* Remove subopt-helperwm42013-07-221-1/+0
| | | | Finally not used by anything anymore. Farewell.
* ao_coreaudio: split ao_coreaudio_common in two filesStefano Pigozzi2013-07-221-1/+3
| | | | | | | | | * ao_coreaudio_utils: contains several utility function * ao_coreaudio_properties: contains functions to set and get audio object properties. Conflicts: audio/out/ao_coreaudio.c
* audio/decode: remove macro crapwm42013-07-221-1/+0
| | | | | Declare decoders directly, instead of using the LIBAD_EXTERN macro. This is simpler (no weird magic) and more extensible.
* ao_wasapi0: Rename to ao_wasapiDiogo Franco (Kovensky)2013-07-221-1/+1
| | | | | Nobody knows what the 0 was for. There's no "WASAPI version 0". Just take it out.
* Merge branch 'remove_old_demuxers'wm42013-07-141-14/+1
|\ | | | | | | | | | | | | | | The merged branch doesn't actually just remove old demuxers, but also includes a branch of cleanups and some refactoring. Conflicts: stream/stream.c
| * demux_rawvideo/demux_rawaudio: move both demuxers to demux_raw.cwm42013-07-121-2/+1
| | | | | | | | | | This allows them to share some trivial code. Both demuxers are still separate from user perspective.
| * demux: rewrite probing and demuxer initializationwm42013-07-121-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Get rid of the strange and messy reliance on DEMUXER_TYPE_ constants. Instead of having two open functions for the demuxer callbacks (which somehow are both optional, but you can also decide to implement both...), just have one function. This function takes a parameter that tells the demuxer how strictly it should check for the file headers. This is a nice simplification and allows more flexibility. Remove the file extension code. This literally did nothing (anymore). Change demux_lavf so that we check our other builtin demuxers first before libavformat tries to guess by file extension.
| * core: move code from demux/video.c to mplayer.cwm42013-07-101-1/+0
| | | | | | | | | | Although I don't like putting even more crap into mplayer.c, this is a bit better, especially with coming cleanups in mind.
| * Remove old demuxerswm42013-07-071-10/+0
| | | | | | | | | | | | | | | | | | | | Delete demux_avi, demux_asf, demux_mpg, demux_ts. libavformat does better than them (except in rare corner cases), and the demuxers have a bad influence on the rest of the code. Often they don't output proper packets, and require additional audio and video parsing. Most work only in --no-correct-pts mode. Remove them to facilitate further cleanups.
* | build: change vf_dlopen testwm42013-07-121-4/+1
| | | | | | | | Didn't work on Windows. Apparently, WIN32 is not set in the Makefile.
* | configure: add libdl detection to ladspa, vf_dlopenRudolf Polzer2013-07-091-1/+5
|/
* osdep: remove unused mmap compatibility hackswm42013-07-071-1/+1
| | | | | | | Not sure how this worked. Only af_export.c and tvi_v4l2.c were using mmap, but they didn't include osdep/mmap.h or mmap_anon.h. In any case, we trust that the target system is sufficiently POSIX compliant if mmap is actually defined (as checked by configure).
* Remove some leftovers from network removalwm42013-07-071-1/+0
| | | | | | | | stream_vstream.c in particular was actually dependent on the network code, and didn't compile anymore. Cleanup the protocol list in mpv.rst, and add some missing ones supported by libavformat to stream_lavf.c.
* Remove internal network supportwm42013-07-071-11/+1
| | | | | | | | | | | This commit removes the "old" networking code in favor of libavformat's code. The code was still used for mp_http, udp, ftp, cddb. http has been mapped to libavformat's http support since approximately 6 months ago. udp and ftp have support in ffmpeg (though ftp was added only last month). cddb support is removed with this commit - it's probably not important and rarely used if at all, so we don't care about it.
* core: remove mp_fifo indirectionwm42013-07-021-1/+0
| | | | | | | | | | For some reason mp_fifo specifically handled double clicks, and other than that was a pointless wrapper around input.c functionality. Move the double click handling into input.c, and get rid of mp_fifo. Add some compatibility wrappers, because so much VO code uses these functions. Where struct mp_fifo is still used it's just a casted struct input_ctx.
* core: add libquvi 0.9 supportwm42013-06-281-0/+1
| | | | | | | | | | | | | This adds support for libquvi 0.9.x, and these features: - start time (part of youtube URL) - youtube subtitles - alternative source switching ('l' and 'L' keys) - youtube playlists Note that libquvi 0.9 is still in development. Although this seems to be API stable now, it looks like there will be a 1.0 release, which is supposed to be the next stable release and the actual successor of libquvi 0.4.x.
* core: rename mplayer.h and quvi.cwm42013-06-281-1/+1
| | | | | | mplayer.h used to be used for much more stuff, but all what is left are quvi related definitions. Rename quvi.c as well to make its purpose clearer.
* stream: redo memory streamswm42013-06-281-0/+1
| | | | | Make memory streams actual streams. This causes fewer weird corner cases and actually allows using demuxers with them.
* Merge branch 'sub_mess2'wm42013-06-251-3/+5
|\ | | | | | | ...the return.
| * sub: add hack for Libav SRT demuxerwm42013-06-251-0/+1
| | | | | | | | | | | | | | Before this commit, SRT demuxing and display actually happened to work on Libav. But it was using the libavcodec srt converter (which is essentially unmaintained in Libav), and timing postprocessing didn't work. For some bac