summaryrefslogtreecommitdiffstats
path: root/DOCS/man/en/options.rst
Commit message (Collapse)AuthorAgeFilesLines
* manpage: mention that vda can work with vo_openglwm42013-12-021-1/+1
| | | | | Also, with the addition of VDA, all hardware decoding backends work with vo_opengl now.
* options: add option to disable using right Alt key as Alt GrVivek Jain2013-12-021-0/+5
| | | | | | | | | mpv was hardcoded to always consider the right Alt key as Alt Gr, but there are parituclar combinations of platforms and keyboard layouts where it's more convenient to treat the right Alt as a keyboard modifier just like the left one. Fixes #388
* video: disable PTS sorting fallback by defaultwm42013-11-251-4/+7
| | | | | | | | | | | | | | | | It appears PTS sorting was useful only for avi files (and VfW-muxed mkv). Maybe it was historically also important for decoders with broken or non-existent PTS reordering (win32 codecs?). But now that we handle demuxers which outputs DTS only correctly, it just seems dead weight. Disable it by default. The --pts-association-mode option is now forced to always use the decoder's PTS value. You can still enable the old default (auto) or force sorting. But we will probably remove this option entirely at some point. Make demux_mkv export timestamps at DTS when it's in VfW mode. This is needed to get correct timestamps with the new default mode. demux_lavf already does that.
* demux_lavf: disable genpts by default, remove the builtin genpts hackwm42013-11-251-8/+4
| | | | | | | | | This was needed to determine PTS from DTS, but the previous commits make it unnecessary. The builtin genpts hack was used for DVD, because libavformat's genpts essentially went amok on DVD timestamp resets. See commit 65d87091 for details.
* options: implement --pphelp differentlywm42013-11-231-3/+0
| | | | Make it work via --vf=pp:help instead.
* video: remove vf_pp auto-insertionwm42013-11-231-3/+0
| | | | | | | | | | This drops the --pp option, which was probably broken for a while. The option automatically inserted the "pp" filter. The value passed to it was ignored (which is probably broken, it always selected maximal quality). Inserting this filter can be done simply with --vf=pp, so this is not needed anymore.
* player: add --merge-files optionwm42013-11-191-0/+9
|
* manpage: fix typo in --video-align-y descriptionwm42013-11-191-1/+1
|
* manpage: mark DTS-HD passthough as brokenwm42013-11-151-0/+2
|
* sd_lavc, sd_spu: make dvdsub stretching conditional on --stretch-dvd-subs.Rudolf Polzer2013-11-071-0/+13
| | | | | | | | | | | | We found that the stretching - although it usually improves the looks of the fonts - is incorrect. On DVD, subtitles can cover the full area of the picture, and they have the same pixel aspect as the movie itself. Too bad many commercially released DVDs use bitmap fonts made with the wrong pixel aspect (i.e. assuming 1:1) - --stretch-dvd-subs will make these more pretty then.
* vd_lavc: remove explicit crystalhd supportwm42013-11-061-1/+0
| | | | | | | | | | | | | | | | This removes "--hwdec=crystalhd". I doubt anyone even tried to use this. But even if someone wants to use it, the decoders can still be explicitly invoked with e.g.: --vd=lavc:h264_crystalhd The only advantage our special code provided was fallback to software decoding. (But I'm not sure how the ffmpeg crystalhd pseudo-decoder actually behaves.) Removing this will allow some simplifications as soon as we don't need vdpau_old.c anymore.
* vo_opengl: support for vdpau hardware decodingwm42013-11-051-1/+1
| | | | | | | | | | | | This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
* manpage: fix incorrect default for --oscwm42013-11-051-1/+1
|
* vo_opengl: add support for VA-API OpenGL interopwm42013-11-041-1/+1
| | | | | | | | VA-API's OpenGL/GLX interop is pretty bad and perhaps slow (renders a X11 pixmap into a FBO, and has to go over X11, probably involves one or more copies), and this code serves more as an example, rather than for serious use. On the other hand, this might be work much better than vo_vaapi, even if slightly slower.
* video: check profiles with hardware decodingwm42013-11-011-0/+7
| | | | | | | | | | | | | | | We had some code for checking profiles earlier, which was removed in commits 2508f38 and adfb71b. These commits mentioned that (working) hw decoding was sometimes prevented due to profile checking, but I can't find the samples anymore that showed this behavior. Also, I changed my opinion, and I think checking the profiles is something that should be done for better fallback to software decoding behavior. The checks roughly follow VLC's vdpau profile checks, although we do not check codec levels. (VLC's profile checks aren't necessarily completely correct, but they're a welcome help anyway.) Add a --vd-lavc-check-hw-profile option, which skips the profile check.
* manpage: clarify --heartbeat-interval operationwm42013-10-251-0/+5
|
* spelling fixesAlessandro Ghedini2013-10-161-1/+1
|
* docs: Add osc.rst to mpv.rstChrisK22013-10-151-0/+3
| | | | Also moved OPTIONS headline into options.rst
* options: --loop=N means playback N times, not N+1 timesPhilip Sequeira2013-10-121-4/+5
| | | | | | | | | | The argument or this change is that --loop should set how often the file is played, not the number of additional repeats. Based on pull request 277, with additions to the manpage and removal of "--loop=0". Signed-off-by: wm4 <wm4@nowhere>
* core: add --force-windowwm42013-10-021-0/+14
| | | | | | | | | | | | | | | | | This commit adds the --force-window option, which will cause mpv always to create a window when started. This can be useful when pretending that mpv is a GUI application (which it isn't, but users pretend anyway), and playing audio files would run mpv in the background without giving a window to control it. This doesn't actually create the window immediately: it only does so only after initializing playback and when it is clear that there won't be any actual video. This could be a problem when starting slow or completely stuck network streams (mpv would remain frozen in the background), or if video initialization somehow is stuck forever in an in-between state (like when the decoder doesn't output a video frame, but doesn't return an error either). Well, we can pretend only so much that mpv is a GUI application.
* network: add options to control TLS verificationwm42013-09-271-0/+8
|
* Add the on-screen-controllerChrisK22013-09-261-0/+3
| | | | Signed-off-by: wm4 <wm4@nowhere>
* Add initial Lua scripting supportwm42013-09-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | 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.
* options: allow selecting the libass shaperwm42013-09-251-0/+9
| | | | | | I'm using the word "languages" instead of "scripts" in the manpage, but I think that's easier to understand with a smaller amount of descriptions.
* options: make --ass-hinting a choice, instead of using magic numberswm42013-09-251-6/+11
| | | | | options.c still doesn't use the constants defined by the libass headers, but it's still better than exposing those to the user directly.
* vaapi: allow GPU read-back with --hwdec=vaapi-copywm42013-09-251-0/+4
| | | | | | | | | | | | | | This code is actually quite inefficient: it reuses the (slow, simple) screenshot code. It uses an inefficient method to read the image (vaGetImage() instead of vaDeriveImage()), allocates new memory for each frame that is read, and it tries all image formats again each time. Also, in my tests it always picked NV12 as image format, which is not ideal if you actually want to filter the video, and vo_xv can't handle this format without conversion either. However, a user confirmed that it worked for him, so everything is fine.
* network: fix rtsp playbackwm42013-09-221-0/+5
| | | | | | | | | | | | | | By default, libavformat uses UDP for rtsp playback. This doesn't work very well. Apparently the reason is that the buffer sizes libavformat chooses for UDP are way too small, and switching to TCP gets rid of this issue entirely (thanks go to Reimar Döffinger for figuring this out). In theory, you can set buffer sizes as libavformat options, but that doesn't seem to help. Add an option to select the rtsp transport, and make TCP the default. Also remove an outdated comment from stream.c.
* Merge branch 'volume_restore'wm42013-09-201-0/+12
|\
| * mixer: restore volume with playback resumewm42013-09-201-0/+12
| | | | | | | | | | | | | | | | | | Note that this is intentionally never done if the AO or softvolume is different, or if the current volume control method is thought to control system wide volume (such as ALSA) or otherwise user controllable (such as PulseAudio). The intention is to keep things robust and to avoid messing with the user's audio settings as far as possible, while still providing the ability to resume volume if it makes sense.
* | Revert "osxbundle: fonts.conf: only look for fonts in ~/.mpv/fonts"Stefano Pigozzi2013-09-191-7/+0
|/ | | | | | | Commit broke text subtitles without embedded fonts. Will look for a better solution later. Revert it for now, since I'm starting to get bug reports. This reverts commit 4a9f618d9f3b2d964bcc819426cc3042b8e447f7.
* osxbundle: fonts.conf: only look for fonts in ~/.mpv/fontsStefano Pigozzi2013-09-181-0/+7
| | | | | | | | This is to avoid the 30s hang while mpv caches fonts. In practice all the fonts an average user is going to use are embedded in mkv files so there is no reason to build fontconfig's cache on all of OS X system directories. I might add something similar for terminal usage, but I am highly undecided.
* screenshot: change %w format to be more like %twm42013-09-151-14/+13
| | | | | | Instead of containing a format string within %w{...}, simply allow %w to specify one item of a time format string. This is simpler, more like other format specifiers (%t), and probably easier to use too.
* screenshot: make it possible to format playback time in various wayswm42013-09-151-0/+23
|
* mplayer: don't run heartbeat command while pausedwm42013-09-151-2/+4
| | | | | | | | This is commonly used to disable the screensaver with broken/non- standard X screensavers. During pause, the screensaver should not be disabled, so not calling this command while paused seems sensible. See github issue #236.
* core: add --deinterlace option, restore it with resume functionalitywm42013-09-131-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The --deinterlace option does on playback start what the "deinterlace" property normally does at runtime. You could do this before by using the --vf option or by messing with the vo_vdpau default options, but this new option is supposed to be a "foolproof" way. The main motivation for adding this is so that the deinterlace property can be restored when using the video resume functionality (quit_watch_later command). Implementation-wise, this is a bit messy. The video chain is rebuilt in mpcodecs_reconfig_vo(), where we don't have access to MPContext, so the usual mechanism for enabling deinterlacing can't be used. Further, mpcodecs_reconfig_vo() is called by the video decoder, which doesn't have access to MPContext either. Moving this call to mplayer.c isn't currently possible either (see below). So we just do this before frames are filtered, which potentially means setting the deinterlacing every frame. Fortunately, setting deinterlacing is stable and idempotent, so this is hopefully not a problem. We also add a counter that is incremented on each reconfig to reduce the amount of additional work per frame to nearly zero. The reason we can't move mpcodecs_reconfig_vo() to mplayer.c is because of hardware decoding: we need to check whether the video chain works before we decide that we can use hardware decoding. Changing it so that this can be decided in advance without building a filter chain sounds like a good idea and should be done, but we aren't there yet.
* quvi: restore playback position when switching formatswm42013-09-101-3/+4
| | | | This simply issues a seek after reloading.
* manpage: various improvementswm42013-09-101-67/+68
| | | | Took a superficial look at the manpage, and fixed whatever I spotted.
* Manpage: Fix formatting (mostly for PDF output)Martin Herkt2013-09-081-3/+8
|
* mplayer: add --cursor-autohide-fs-only optionwm42013-09-081-0/+5
| | | | | | | | This option makes the cursor always visible in windowed mode. Apparently, this is what (some?) Windows and OSX users expect. It's disabled by default for now. Restructure the cursor hide logic a bit for this purpose.
* options: remove --(no-)mouseinput optionwm42013-09-081-4/+1
| | | | I have no idea why it exists, as it's redundant to --(no-)mouse-movements.
* options: fix --volume option range, add some explanations to manpagewm42013-09-071-0/+6
| | | | | | | | The --volume option accepted values up to 10000, but internally, the value is always clipped to 0-100 range. What makes this even worse is that --softvol-max suggests that it extends the range of --volume, which is not the case. (And passing a volume larger than 100 to --volume didn't even print a warning.)
* mplayer: make --save-position-on-quit save only on quitwm42013-09-041-2/+4
| | | | | | | | | | | | When enabling --save-position-on-quit, playback position stored not only on quit, but in any case playback of a file was stopped. This includes going to the next file with playlist navigation commands. After some discussion on IRC, it turned out that nobody thought this was good behavior. Disable it, and really make it save only on quit. Maybe the option is useless now, as the user could remap the CLOSE_WIN key binding. On the other hand, CLOSE_WIN sounds and _is_ a bit obscure.
* video: add unscaled mode with --video-unscaledwm42013-09-011-0/+12
|
* core: add a playlist demuxerwm42013-08-261-0/+16
| | | | | | | | | 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.
* video: add vda decode support (with hwaccel) and direct renderingStefano Pigozzi2013-08-221-1/+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.
* options: replace --edition=-1 with --edition=autowm42013-08-211-2/+2
| | | | | | Originally, the objective of this commit was changing --edition to be 1-based, but this was cancelled. I'm still leaving the change to demux_mkv.c though, which is now only of cosmetic nature.
* mplayer: start track IDs from 1 rather than 0wm42013-08-211-1/+1
| | | | | | Completely pointless, but makes ChrisK happy for some reason. Track ID 0 is now rejected by the option parser itself.
* video: make it possible to scale/pan the video by arbitrary amountswm42013-08-191-0/+33
| | | | | | | | | | | Add --video-align-x/y, --video-pan-x/y, --video-scale options and properties. See the additions to the manpage for description and semantics. These transformations are intentionally done on top of panscan. Unlike the (now removed) --panscanrange option, this doesn't affect the default panscan behavior. (Although panscan itself becomes kind of useless if the new options are used.)
* options: remove --panscanrange optionwm42013-08-191-8/+0
| | | | | | This option allowed you to extend the range of the panscan controls, so that you could essentially use it to scale the video. This will be replaced by a separate option to set the zoom factor directly.
* command: more intuitive chapter seek behaviorPhilip Sequeira2013-08-171-0/+7
| | | | | | | | | If close to chapter start, skipping back goes to previous chapter (no change). If more than <threshold> seconds in, skipping back will now go to the beginning of the current chapter instead. The threshold is set by the new option --chapter-seek-threshold and defaults to 5 seconds. A negative value disables the new functionality.
* sub: make --subcp=enca the default.wm42013-08-151-5/+14
|
* sub: allow specifying a fallback codepage if input is not UTF-8wm42013-08-151-2/+8
| | | | | | | | | | | | | | | Normally, --subcp always forces conversion. This really always forces conversion, even if the UTF-8 check on the input succeeds. Extend the --subcp to allow codepages as fallback if UTF-8 doesn't work. So, for example --subcp=utf8:cp1250 will use UTF-8 if the input looks like UTF-8, and will fall back to use cp1250 if the UTF-8 check fails. I think this should actually be the default, but on the other hand, this changes the semantics of the option, and a user would actually expect --subcp to force conversion, rather than silently using UTF-8 if that happens to work.
* manpage: actually document --hwdec=autowm42013-08-121-0/+7
|
* video: add vaapi decode and output supportwm42013-08-121-1/+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.)
*