summaryrefslogtreecommitdiffstats
path: root/etc
Commit message (Collapse)AuthorAgeFilesLines
* example.conf: some modificationswm42013-09-071-23/+22
| | | | | | Remove options which are too obscure and most likely not very useful in general, or update them to something more modern. Add some comments about how configuration files work in general.
* input: don't print warning if certain internal keys are not boundwm42013-09-061-4/+0
| | | | | | | | | | | This affects MOUSE_MOVE and MOUSE_LEAVE. Both are needed internally (such as for the OSC), but not really useful for input.conf. Since the warning has the purpose of notifying the user that a key is unmapped and what key name to use for setting up a binding in input.conf, the warning is rather useless in this case. It's also annoying in combination with the --no-input-default-bindings option, since that removes the default bindings to "ignore" for these keys.
* etc: delete mplayer.xpmwm42013-09-051-239/+0
| | | | I don't think we need this anymore.
* x11: add window iconwm42013-09-013-0/+0
| | | | | | | | | | | | | | | | | | | | | 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).
* osx: use MP_KEY_* instead of MK_* for media keysStefano Pigozzi2013-09-011-5/+0
| | | | | In 213ad5d6c I added `MK_*` key bindings overlooking the fact that mpv already has `MP_KEY_*` for media keys.
* input: comment all default bindings in input.confwm42013-09-011-137/+145
| | | | | | | | | | | | | | I suspect most users will just copy etc/input.conf when they want to remap some default bindings. But usually this means the user even copies bindings he doesn't care about, and it's better if the user maps only the bindings in his input.conf the user intends to remap. Comment all bindings in etc/input.conf. Since this file also defines the builtin defaults and is baked into the mpv binary, we have to do something to get them anyway, even though they are commented. Do this by having input.c "uncomment" the bindings in the baked in input.conf. (Of course this is done only for the builtin config, not configs loaded from disk.)
* change application iconStefano Pigozzi2013-09-012-556/+0
| | | | | | | | | | | | | | | | | | | | | | | | | I would like to thank Chris Ward (@tenzerothree, http://tenzerothree.com/) for working on the art for these icons and bringing some eye candy to the project. The PSDs made by Chris are available on our Dropbox [1], along with the exports I made to create OSX and Windows icons. The PSDs are almost completly vector and all the resolutions look really similar, except the 16px favicon which was handcrafted to look better and more recognizeable on the smaller pixel budget. For Mac OS X the icons were created using iconutils on the PNGs iconsets exported from the PSDs. These even support retina resolutions (except 512@2x). For Windows the .ico file was created with imagemagick. The included images are 16px, 24px, 32px, 48px 64px, 256px. These are the resolutions listed on MSDN for supporting Windows XP [2] and Windows versions based on Aero [3]. Only 32bit PNGs were used since it is 2013. For Linux nothing changed yet, even though @wm4 talked about using the PNGs directly there. This will probably be dealt with in a later commit. [1]: https://www.dropbox.com/sh/yelfoj9tbft7o06/A8vOT6JKaG [2]: http://msdn.microsoft.com/en-us/library/ms997636.aspx [3]: http://msdn.microsoft.com/en-us/library/aa511280.aspx
* input.conf: bind AXIS_(LEFT|RIGHT) to seek 5Stefano Pigozzi2013-08-131-2/+2
| | | | Binding them to volume was a bad default, so change it.
* video: redo hw decoding initialization, add --hwdec=autowm42013-08-111-1/+8
| | | | | | | | | | | | | | | | Change how the HW decoding stuff is organized, the way it's initialized in particular. Instead of duplicating the list of supported codecs for hwaccel decoders, add a probe function which allows each decoder to report whether it supports a given codec. Add an "auto" choice to the --hwdec option, which automatically enables hardware decoding if libavcodec and/or the VO supports it. What mpv prints on the terminal changes a bit. Now it will just print a single line whether hw decoding is used or not (and nothing at all if no hw decoding at all was requested). The pretty violent fallback from hw decoding to software decoding is still quite verbose and evil-looking though.
* input.conf: better documentation and sane defaultsAlexander Preisinger2013-08-071-2/+4
| | | | | Uses the same defaults as BTN3/4/5/6 which are hardcoded by most backends for the mouse wheel.
* input: add support for precise scroll axesAlexander Preisinger2013-08-071-0/+6
| | | | | | | | | | | | | | | Support horizontal and vertical axes of input devices. If the input device support precise scrolling with an input value then it should first be scaled to a standard multiplier, where 1.0 is the default. The multiplier will then applied to the following commands if possible: * MP_CMD_SEEK * MP_CMD_SPEED_MULT * MP_CMD_ADD All other commands will triggered on every axis event, without change the values specified in the config file.
* encoding-example-profiles: get rid of the N900 anti upscale hack.Rudolf Polzer2013-08-021-1/+1
| | | | | | This slightly increases file size due to needless downscaling on the device due to aspect correction, but keeps quality as is and prevents encoding errors caused by odd height/width.
* mpv.rc: update Windows iconJames Ross-Gowan2013-07-302-0/+0
| | | | Based on the OSX bundle icon.
* input: trigger mouse_leave key bindings if mouse leaves mouse areawm42013-06-291-0/+1
| | | | | | Also, implement mouse leave events for X11. But evne on other platforms, these events will be generated if mouse crosses a section's mouse area boundaries within the mpv window.
* input: handle mouse movement differentlywm42013-06-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this commit, mouse movement events emitted a special command ("set_mouse_pos"), which was specially handled in command.c. This was once special-cased to the dvdnav and menu code, and did nothing after libmenu and dvdnav were removed. Change it so that mouse movement triggers a pseudo-key ("MOUSE_MOVE"), which then can be bound to an arbitrary command. The mouse position is now managed in input.c. A command which actually needs the mouse position can use either mp_input_get_mouse_pos() or mp_get_osd_mouse_pos() to query it. The former returns raw window-space coordinates, while the latter returns coordinates transformed to OSD- space. (Both are the same for most VOs, except vo_xv and vo_x11, which can't render OSD in window-space. These require extra code for mapping mouse position.) As of this commit, there is still nothing that uses mouse movement, so MOUSE_MOVE is mapped to "ignore" to silence warnings when moving the mouse (much like MOUSE_BTN0). Extend the concept of input sections. Allow multiple sections to be active at once, and organize them as stack. Bindings from the top of the stack are preferred to lower ones. Each section has a mouse input section associated, inside which mouse events are associated with the bindings. If the mouse pointer is outside of a section's mouse area, mouse events will be dispatched to an input section lower on the stack of active sections. This is intended for scripting, which is to be added later. Two scripts could occupy different areas of the screen without conflicting with each other. (If it turns out that this mechanism is useless, we'll just remove it again.)
* core: add libquvi 0.9 supportwm42013-06-281-0/+3
| | | | | | | | | | | | | 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.
* Option -omaxfps: limit fps when encodingRudolf Polzer2013-06-091-0/+6
| | | | | Lower-fps content is left alone (NOT aligned to this fps); higher fps content is decimated to this frame rate.
* osx: improve Media Keys supportStefano Pigozzi2013-06-041-0/+5
| | | | | | | | | | | | | | | | | | | | | | | This commit addresses some issues with the users had with the previous implementation in commit c39efb9. Here's the changes: * Use Quartz Event Taps to remove Media Key events mpv handles from the global OS X queue. This prevents conflicts with iTunes. I did this on the main thread since it is mostly idling. It's the playloop thread that actually does all the work so there is no danger of blocking the event tap callback. * Introduce `--no-media-keys` switch so that users can disable all of mpv's media key handling at runtime (some prefer iTunes for example). * Use mpv's bindings so that users can customize what the media keys do via input.conf. Current bindings are: MK_PLAY cycle pause MK_PREV playlist_prev MK_NEXT playlist_next An additional benefit of this implementation is that it is completly handled by the `macosx_events` file instead of `macosx_application` making the project organization more straightforward.
* osx: add Apple Remote supportStefano Pigozzi2013-06-031-1/+16
| | | | | | | | | | | | | | | | | After killing the non functional AR support in c8fd9e5 I got much complaints so this adds AR support back in (and it works). I am using the HIDRemote class by Felix Schwarz and that part of the code is under the BSD license. I slightly modified it replacing [NSApplication sharedApplication] with NSApp. The code of the class is quite complex (probably because it had to deal with all the edge cases with IOKit) but it works nicely as a black box. In a later commit I'll remove the deprecation warnings caused by HIDRemote's usage of Gestalt. Check out `etc/input.conf` for the default bindings. Apple Remote functionality is automatically compiled in when cocoa is enabled. It can be disabled at runtime with the `--no-ar` option.
* input.conf: fix commentwm42013-06-031-3/+3
|
* core: add playback resume feature (manual/opt-in)wm42013-05-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | A "watch later" command is now mapped to Shift+Q. This quits the player and stores the playback state in a config file in ~/.mpv/watch_later/. When calling the player with the same file again, playback is resumed at that time position. It's also possible to make mpv save playback state always on quit with the --save-position-on-quit option. Likewise, resuming can be disabled with the --no-resume-playback option. This also attempts to save some playback parameters, like fullscreen state or track selection. This will unconditionally override config settings and command line options (which is probably not what you would expect, but in general nobody will really care about this). Some things are not backed up, because that would cause various problems. Additional subtitle files, video filters, etc. are not stored because that would be too hard and fragile. Volume/mute state are not stored because it would mess up if the system mixer is used, or if the system mixer was readjusted in the meantime. Basically, the tradeoff between perfect state restoration and complexity/fragility makes it not worth to attempt to implement it perfectly, even if the result is a little bit inconsistent.
* core: add backstep supportwm42013-04-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allows stepping back one frame via the frame_back_step inout command, bound to "," by default. This uses the precise seeking facility, and a perfect frame index built on the fly. The index is built during playback and precise seeking, and contains (as of this commit) the last 100 displayed or skipped frames. This index is used to find the PTS of the previous frame, which is then used as target for a precise seek. If no PTS is found, the core attempts to do a seek before the current frame, and skip decoded frames until the current frame is reached; this will create a sufficient index and the normal backstep algorithm can be applied. This can be rather slow. The worst case for backstepping is about the same as the worst case for precise seeking if the previous frame can be deduced from the index. If not, the worst case will be twice as slow. There's also some minor danger that the index is incorrect in case framedropping is involved. For framedropping due to --framedrop, this problem is ignored (use of --framedrop is discouraged anyway). For framedropping during precise seeking (done to make it faster), we try to not add frames to the index that are produced when this can happen. I'm not sure how well that works (or if the logic is sane), and it's sure to break with some video filters. In the worst case, backstepping might silently skip frames if you backstep after a user-initiated precise seek. (Precise seeks to do indexing are not affected.) Likewise, video filters that somehow change timing of frames and do not do this in a deterministic way (i.e. if you seek to a position, frames with different timings are produced than when the position is reached during normal playback) will make backstepping silently jump to the wrong frame. Enabling/disabling filters during playback (like for example deinterlacing) will have similar bad effects.
* Remove some apple remote leftoverswm42013-04-051-15/+0
| | | | The options and key names don't do anything anymore.
* encoding-example-profiles: block non-4:0:0 for baseline h264Rudolf Polzer2013-04-041-0/+4
| | | | | libx264 rejects the other pixel formats when doing baseline H.264, although libavcodec accepts them, leading to an encoding abort.
* encoding-example-profiles and manpage: prefer libvorbis over vorbisRudolf Polzer2013-03-311-1/+1
| | | | | vorbis is the builtin bad vorbis encoder; whenever possible, one should rather use the "libvorbis" codec name.
* encoding-examples-profiles: fix N900 profileRudolf Polzer2013-03-201-1/+1
| | | | | | | In some cases (when using tune=animation as an additional option), the N900 profile caused use of 6 reference frames, where Level 3.0 only allows 5 reference frames. This prevented playback on the Nokia N900. This has been fixed by always specifying refs=5.
* encoding-example-profiles: for Nokia N900, avoid upscalingRudolf Polzer2013-03-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This yields generally smaller files, by avoiding upscaling at all times. This method may or may not be useful for iOS, needs testing there. Note: this uses three instances of vf_scale: 1. Scale to target dimensions, ONLY if both are <= original video dimensions. 2. Failing that, scale to width*<calculated height by display aspect>, ONLY if <calculated height by display aspect> <= original video height. 3. Failing that, scale to <calculated width by display aspect>*height. When the test before failed, we KNOW that <calculated width by display aspect> <= original video width. So basically, only one of the three scalers should ever be active, as the last two scalers only can ever have an effect if the aspect ratio mismatches the video. As for danger of roundoff errors: If scaler 1 succeeded, we have won. Scalers 2 and 3 will never do anything, because display resolution == video resolution. Here it is crucial that no rounding of video size to display size takes place; in other words, the target display size already MUST be even, which it is because we pass 2 to the rounding parameter of the dsize filter. Scaler 2 and 3 are obviously mutually exclusive, as they depend on opposite aspect ratio conditions. We later should put this functionality directly into vf_scale...
* input: ignore normal mouse click by defaultwm42013-03-141-0/+1
| | | | Apparently this annoyed some users.
* encoding-example-profiles: add a Nokia N900 profileRudolf Polzer2013-03-041-0/+6
| | | | | Nokia N900 is simply H.264 Baseline, level must be forced to 3.0, at max. display resolution. There is no pan-scan like on iOS.
* input.conf: change default bindings of 5/6 from hue to gammawm42013-03-011-2/+2
| | | | | | | | I doubt anyone needs to adjust hue on a frequent basis, and gamma is much more useful. Suggestions for more radical changes of key bindings are welcome (there's a lot of useless crap mapped).
* options: drop --opt:subopt option nameswm42013-02-231-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For all suboptions, "flat" options were available by separating the parent option and the sub option with ":", e.g. "--rawvideo:w=123". Drop this syntax and use "-" as separator. This means even suboptions are available as normal options now, e.g. "--rawvideo-w=123". The old syntax doesn't work anymore. Note that this is completely separate from actual suboptions. For example, "-rawvideo w=123:h=123" still works. (Not that this syntax is worth supporting, but it's needed anyway, for for other things like vf and vo suboptions.) As a consequence of this change, we also have to add new "no-" prefixed options for flag suboptions, so that "--no-input-default-bindings" works. ("--input-no-default-bindings" also works as a consequence of allowing "-input no-default-bindings" - they are handled by the same underlying option.) For --input, always use the full syntax in the manpage. There exist suboptions other than --input (like --tv, --rawvideo, etc.), but since they might be handled differently in the future, don't touch these yet. M_OPT_PREFIXED becomes the default, so remove it. As a minor unrelated cleanup, get rid of M_OPT_MERGE too and use the OPT_SUBSTRUCT() macro in some places. Unrelated: remove the duplicated --tv:buffersize option, fix a typo in changes.rst.
* core: redo how codecs are mapped, remove codecs.confwm42013-02-101-2210/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use codec names instead of FourCCs to identify codecs. Rewrite how codecs are selected and initialized. Now each decoder exports a list of decoders (and the codec it supports) via add_decoders(). The order matters, and the first decoder for a given decoder is preferred over the other decoders. E.g. all ad_mpg123 decoders are preferred over ad_lavc, because it comes first in the mpcodecs_ad_drivers array. Likewise, decoders within ad_lavc that are enumerated first by libavcodec (using av_codec_next()) are preferred. (This is actually critical to select h264 software decoding by default instead of vdpau. libavcodec and ffmpeg/avconv use the same method to select decoders by default, so we hope this is sane.) The codec names follow libavcodec's codec names as defined by AVCodecDescriptor.name (see libavcodec/codec_desc.c). Some decoders have names different from the canonical codec name. The AVCodecDescriptor API is relatively new, so we need a compatibility layer for older libavcodec versions for codec names that are referenced internally, and which are different from the decoder name. (Add a configure check for that, because checking versions is getting way too messy.) demux/codec_tags.c is generated from the former codecs.conf (minus "special" decoders like vdpau, and excluding the mappings that are the same as the mappings libavformat's exported RIFF tables). It contains all the mappings from FourCCs to codec name. This is needed for demux_mkv, demux_mpg, demux_avi and demux_asf. demux_lavf will set the codec as determined by libavformat, while the other demuxers have to do this on their own, using the mp_set_audio/video_codec_from_tag() functions. Note that the sh_audio/video->format members don't uniquely identify the codec anymore, and sh->codec takes over this role. Replace the --ac/--vc/--afm/--vfm with new --vd/--ad options, which provide cover the functionality of the removed switched. Note: there's no CODECS_FLAG_FLIP flag anymore. This means some obscure container/video combinations (e.g. the sample Film_200_zygo_pro.mov) are played flipped. ffplay/avplay doesn't handle this properly either, so we don't care and blame ffmeg/libav instead.
* core: remove --edlout functionalitywm42013-02-061-1/+0
| | | | | | | | | | | | | | | | This could write .edl files in MPlayer's format. Support for playing these files has been removed from mplayer2 quite a while ago. (mplayer2 can play its own, "new" .edl format, but does not support writing it.) Since this is a rather obscure functionality, and it's not really clear how it should behave (e.g. what should it do if a new file is played), and wasn't all that great to begin with (what if you made a mistake? the "edl_mark" command sucks for editing), get rid of it. Suggestions how to reimplement this in a nicer way are welcome. If it's just about retrieving timecodes, this in input.conf will do: KEY print_text "position: ${=time-pos}"
* video: add --autofit and --autofit-larger optionswm42013-01-231-0/+3
| | | | | | | | | --autofit=WxH sets the window size to a maximum width and/or height, without changing the window's aspect ratio. --autofit-larger=WxH does the same, but only if the video size is actually larger than the window size that would result when using the --autofit=WxH option with the same arguments.
* encoding-example-profiles: typo fixesRudolf Polzer2013-01-181-3/+3
| | | | | The iPhone profiles recursively included themselves. Wonder why it even worked somewhat...
* video: decouple internal pixel formats from FourCCswm42013-01-131-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mplayer's video chain traditionally used FourCCs for pixel formats. For example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the string 'YV12' interpreted as unsigned int. Additionally, it used to encode information into the numeric values of some formats. The RGB formats had their bit depth and endian encoded into the least significant byte. Extended planar formats (420P10 etc.) had chroma shift, endian, and component bit depth encoded. (This has been removed in recent commits.) Replace the FourCC mess with a simple enum. Remove all the redundant formats like YV12/I420/IYUV. Replace some image format names by something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P. Add img_fourcc.h, which contains the old IDs for code that actually uses FourCCs. Change the way demuxers, that output raw video, identify the video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to request the rawvideo decoder, and sh_video->imgfmt specifies the pixel format. Like the previous hack, this is supposed to avoid the need for a complete codecs.cfg entry per format, or other lookup tables. (Note that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT raw video, but this is still considered better than adding a raw video decoder - even if trivial, it would be full of annoying lookup tables.) The TV code has not been tested. Some corrective changes regarding endian and other image format flags creep in.
* video: different way to enable hardware decoding, add software fallbackwm42013-01-132-2/+14
| | | | | | | | | | | | | | Deprecate the hardware specific video codec entries (like ffh264vdpau). Replace them with the --hwdec switch, which requests that a specific hardware decoding API should be used. The codecs.conf entries will be removed at a later time, but for now they are useful for testing and compatibility. Instead of --vc=ffh264vdpau, --hwdec=vdpau should be used. Add a fallback if hardware decoding fails. Most hardware decoders (including vdpau) support only a subset of h264, and having such a fallback is supposed to enable a better user experience.
* video: simplify decoder pixel format handlingwm42013-01-131-10/+2
| | | | | | | | | | | | | | | | | | | | Simplify the decoder pixel format handling by making it handle only the case vd_lavc needs: a video stream always decodes to a single pixel format. Remove the handling for multiple pixel formats, and remove the codecs.conf pixel format declarations that are left. Remove the handling of "ambiguous" pixel formats like YV12 vs. I420 (via VDCTRL_QUERY_FORMAT etc.). This is only a problem if the video chain supports I420, but not YV12, which doesn't seem to be the case anywhere, and in fact would not have any advantage. Make the "flip" flag a global per-codec flag, rather than a pixel format specific flag. (Some ffmpeg decoders still return a flipped image, so this has to be done manually.) Also fix handling of the flip operation: do not overwrite the global flip option, and make the --flip option invert the codec flip option rather than overriding it.
* encoding-example-profiles: restructure iPhone profilesRudolf Polzer2013-01-101-11/+11
| | | | The names are left as is, but they are hierarchic internally now.
* encoding-example-profiles: fix "oac" typoRudolf Polzer2012-12-281-2/+2
| | | | Fixes issue #10.
* audio/decode: remove ad_dvdpcm and use ad_lavc for DVD PCMwm42012-12-111-1/+2
| | | | | | | | | | ad_dvdpcm reads MPEG specific headers directly (passed through codecdata by demux_mpg), so you couldn't use ffmpeg's "pcm_dvd" with demux_mpg. Change demux_mpg to set the correct audio parameters directly. The code for this is taken from ad_dvdpcm. ad_dvdpcm is evil because it still does partial packet reads (with demux_read_data()), and it's redundant to libavcodec anyway.
* audio/decode: remove ad_pcm and use ad_lavc for PCMwm42012-12-111-31/+27
| | | | | | | | | | | | | | | Since libavcodec doesn't have a "generic" PCM decoder, we have to go out of out way to make it look like ad_lavc provides one: make it provide a pseudo "pcm" decoder, which maps some format tags manually to the