summaryrefslogtreecommitdiffstats
path: root/Makefile
Commit message (Collapse)AuthorAgeFilesLines
* 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 background explanations see sd_lavf_srt.c.
| * sub: add subtitle charset conversionwm42013-06-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This code was once part of subreader.c, then traveled to libass, and now made its way back to the fork of the fork of the original code, MPlayer. It works pretty much the same as subreader.c, except that we have to concatenate some packets to do auto-detection. This is rather annoying, but for all we know the actual source file could be a binary format. Unlike subreader.c, the iconv context is reopened on each packet. This is simpler, and with respect to multibyte encodings, more robust. Reopening is probably not a very fast, but I suspect subtitle charset conversion is not an operation that happens often or has to be fast. Also, this auto-detection is disabled for microdvd - this is the only format we know that has binary data in its packets, but is actually decoded to text. FFmpeg doesn't really allow us to solve this properly, because a) the input packets can be binary, and b) the output will be checked whether it's UTF-8, and if it's not, the output is thrown away and an error message is printed. We could just recode the decoded subtitles before sd_ass if it weren't for that.
| * sub: add demux_libass wrapper, drop old hackswm42013-06-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | demux_libass.c allows us to make subtitle format detection part of the normal file loading process. libass has no probe function, but trying to load the start of a file (the first 4 KB) is good enough. Hope that libass can even handle random binary input gracefully without printing stupid log messages, and that the libass parser doesn't accept too many non-ASS files as input. This doesn't handle the -subcp option correctly yet. This will be fixed later.
| * Move/rename subreader.cwm42013-06-251-1/+1
| |
* | ao_wasapi0: add new wasapi event mode aoJonathan Yong2013-06-181-0/+1
| |
* | osdep: remove shmem wrapperwm42013-06-181-1/+0
|/ | | | This is unused now that the cache is always threaded.
* Merge branch 'cache_new'wm42013-06-161-1/+1
|\
| * stream: rename cache2.c to cache.cwm42013-06-091-1/+1
| | | | | | | | | | | | | | I never found cache1.c (whatever it was named, if it ever existed). cache2.h will be deleted later, so don't go through the trouble of renaming it.
* | core: add a spsc ringbuffer implementationStefano Pigozzi2013-06-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently every single AO was implementing it's own ringbuffer, many times with slightly different semantics. This is an attempt to fix the problem. I stole some good ideas from ao_portaudio's ringbuffer and went from there. The main difference is this one stores wpos and rpos which are absolute positions in an "infinite" buffer. To find the actual position for writing / reading just apply modulo size. The producer only modifies wpos while the consumer only modifies rpos. This makes it pretty easy to reason about and make the operations thread safe by using barriers (thread safety is guaranteed only in the Single-Producer/Single- Consumer case). Also adapted ao_coreaudio to use this ringbuffer.
* | ao_coreaudio: split ringbuffer in it's own fileStefano Pigozzi2013-06-161