summaryrefslogtreecommitdiffstats
path: root/DOCS
Commit message (Collapse)AuthorAgeFilesLines
* player: allow passing number of loops to --loop-filewm42014-09-221-5/+9
| | | | | | | | | | E.g. --loop-file=2 will play the file 3 times (one time normally, and 2 repeats). Minor syntax issue: "--loop-file 5" won't work, you have to use "--loop-file=5". This is because "--loop-file" still has to work for compatibility, so the "old" syntax with a space between option name and value can't work.
* options: remove --volstepwm42014-09-211-4/+0
| | | | | | | It's just confusing; users are encouraged to edit input.conf instead (changing the argument to the "add" command). Update input.conf to keep the old behavior.
* manpage: clarify vf_pp docswm42014-09-211-8/+14
| | | | | Make the note about quoting more prominent. Add a warning that this filter is useless for new files.
* vo_vdpau: better integration with the generic framedrop codewm42014-09-201-3/+2
| | | | | | | | | | | | | | | | | | | | vo_vdpau uses its own framedrop code, mostly for historic reasons. It has some tricky heuristics, of which I'm not sure how they work, or if they have any effect at all, but in any case, I want to keep this code for now. One day it might get fully ported to the vo.c framedrop code, or just removed. But improve its interaction with the user-visible framedrop controls. Make --framedrop actually enable and disable the vo_vdpau framedrop code, and increment the number of dropped frames correctly. The code path for other VOs should be equivalent. The vo_vdpau behavior should, except for the improvements mentioned above, be mostly equivalent as well. One minor change is that frames "shown" during preemption are always count as dropped. Remove the statement from the manpage that vo_vdpau is the default; this hasn't been the case for a while.
* manpage: document terminal status line componentswm42014-09-201-0/+45
| | | | | (The classic MPlayer documentation had this in separate files, but we deleted them ages ago.)
* player: allow overriding OSD message for all OSD levelswm42014-09-181-0/+24
| | | | | | | | | | | | | | | | | | Until now, you could override only level 3 with --osd-status-msg. Extend this, add add --osd-msg1 to --osd-msg3 (one for each OSD level). OSD level 0 always means disable OSD, so that isn't included. --osd-msg3 corresponds to --osd-status-msg, but they're not exactly the same. To allow more customization, --osd-msgN do not include the OSD symbol. The symbol can be manually added with "${osd-sym-cc}". We keep the "old" option for some short-term compatibility. --osd-msg1 should be particularly useful; for example you could do: --osd-msg1='${?pause==yes:${osd-sym-cc}}' to display a "paused" symbol when paused, and nothing during normal playback. (Although admittedly, the syntax is quite a bit of work.)
* command: allow using ASS tags on OSD messageswm42014-09-181-2/+19
| | | | | | | | | | | We don't allow this by default, because it would be silly if random external data (like filenames or file tags) could accidentally trigger them. Add a property that magically disables this ASS tag escaping. Note that malicious input could still disable ASS tag escaping by itself. This would be annoying but harmless.
* command: add osd-sym-cc propertywm42014-09-181-0/+5
| | | | This allows you to reproduce the OSD symbol.
* options: change --volstep to 2wm42014-09-161-1/+1
| | | | | | | | | | With default settings, this allows you to hit the 100% mark (with default --softvol-max in the middle) even if you've reached min or max volume before. This is because 50 is not divisible by 3 (old default) but by 2 (new default). Not really sure why there still can be issues with higher --softvol-max and --volstep=1, but this is where I stop caring.
* manpage: fix typo in input.rstAleksey Andreev2014-09-151-1/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* input.conf: map ESC to exiting fullscreenwm42014-09-151-1/+4
| | | | | | | | | | Apparently making ESC exit fullscreen mode is the more popular convention compared to ESC quitting the program. It was also concluded that ESC should do nothing when the windows is already in normal state. See discussion in #973.
* DOCS/client_api_examples: qtexample: resize to video sizewm42014-09-151-0/+21
| | | | | | | | | | | | | This is pretty imperfect, but it's just a demo. The main purpose is clarifying how and when to get the video size. In theory, retrieving the properties this way has a race condition: after reading dwidth, the video could resize again. But the worst that can happen are mismatching dwidth/dheight values, and the MPV_EVENT_VIDEO_RECONFIG event would be immediately received again, which would fix the mismatch. You could read the full video-out-params property to absolutely avoid it, but it's not worth the trouble.
* manpage: clarify description of dwidth/dheightwm42014-09-151-2/+6
|
* input: use libwaio for pipe input on Windowswm42014-09-141-0/+9
| | | | | | | | | | | | Use libwaio to read from pipes (stdin or named pipes) on Windows. This liberates us from nasty issues, such as pipes (as created by most programs) not being possible to read in a non-blocking or event-driven way. Although it would be possible to do that in a somewhat sane way on Vista+, it's still not easy, and on XP it's especially hard. libwaio handles these things for us. Move pipe.c to pipe-unix.c, and remove Windows specific things. Also adjust the input.c code to make this work cleanly.
* input: "quit_watch_later" and "stop" are abort commandswm42014-09-131-2/+8
| | | | | | | | | This means they get special handling for asynchronously aborting playback, even if the player is "stuck". Also document "stop". It seems somewhat useful for client API users (although that will be implemented properly only in the following commits.)
* manpage: document shift+pgup/pgdwn bindingswm42014-09-131-0/+4
|
* lua: synchronously wait until scripts are loadedwm42014-09-061-0/+9
| | | | | | | | | | | | | | | | | This makes the player wait until each script is loaded. Do this to give the script a chance to setup all its event handlers. It might also be useful to allow a script to change options that matter for playback. While waiting for a script to be loaded, the player actually accepts input. This is needed because the scripts can execute player commands anyway while they are being "loaded". The player won't react to most commands though: it can't quit or navigate the playlist in this state. For deciding whether a script is finally loaded, we use a cheap hack: if mpv_wait_event() is called, it's considered loaded. Let's hope this is good enough. I think it's better than introducing explicit API for this. Although I'm sure this will turn out as too simplistic some time in the future, the same would probably happen with a more explicit API.
* vo_corevideo: remove this VOStefano Pigozzi2014-09-062-8/+1
| | | | | | | This was kept in the codebase because it is slightly faster than --vo=opengl on really old Intel cards (from the GMA era). Time to kill it, and let it rest. Fixes #1061
* win32: add tmpfile() replacementJames Ross-Gowan2014-09-051-3/+2
| | | | | | | | | | | The Windows version of tmpfile is actually pretty broken. It tries to create the file in the root directory of the current drive, which means on Vista and up, it normally fails due to insufficient permissions. Replace it with a version that uses GetTempPath. Also remove the Windows-specific note about automatic deletion of the cache file. FILE_FLAG_DELETE_ON_CLOSE is available in NT, and it should be pretty reliable.
* manpage: fix sub_add descriptionwm42014-09-051-1/+1
| | | | | It is in fact selected. The manpage wasn't updated when this was changed.
* audio: make buffer size configurablewm42014-09-051-0/+14
| | | | Really only for testing.
* player: add --media-title optionwm42014-09-021-0/+5
| | | | Requested by ChrisK2.
* player: add --osd-playing-msg optionwm42014-09-021-0/+7
|
* player: simplistic HLS bitrate selectionwm42014-09-011-2/+11
| | | | | | --hls-bitrate=min/max lets you select the min or max bitrate. That's it. Something more sophisticated might be possible, but is probably not even worth the effort.
* command: remove broken quvi-format propertywm42014-09-012-10/+0
| | | | Never really worked, and libquvi is probably a lost cause anyway.
* man: fix a whole bunch of typosMartin Herkt2014-09-0111-130/+130
|
* player: always load playlistswm42014-08-311-14/+6
| | | | | | | | | Until now, you had to use --load-unsafe-playlists or --playlist to get playlists loaded. Change this and always load playlists by default. This still attempts to reject unsafe URLs. For example, trying to invoke libavdevice pseudo-demuxer is explicitly prevented. Local paths and any http links (and some more) are always allowed.
* x11: when using --wid, inherit event flags from parent windowwm42014-08-311-0/+1
| | | | | | | | | | | | | | | | | | | When embedding a X window, it's hard to control whether it receives mouse/keyboard input or not. It seems the X protocol itself makes this hard (basically due to the outdated design mismatching with modern toolkits), and we have to take care of these things explicitly. Simply do this by manually querying and using the parent window event flags. This restores some MPlayer behavior (it doesn't add back exactly the same code, but it's very similar). This probably has some potential to interfere with libmpv embedding, so bump the client API minor. CC: @mpv-player/stable (if applied, client-api-changes.rst has to be adjusted to include the 0.5.2 release)
* lua: expose mp_getcwd through mp.utilsOtto Modinos2014-08-311-0/+4
|
* manpage: be more explicit about "estimated-..." propertieswm42014-08-311-2/+7
| | | | | | In particular, use the note markup. The issue about rounded timestamps is mostly with respect to Matroska (which usually rounds them to milliseconds), which somewhat adds to the reliability issue.
* video: initial Matroska 3D supportwm42014-08-301-0/+16
| | | | | | | | | | | | | | | | | | | | | This inserts an automatic conversion filter if a Matroska file is marked as 3D (StereoMode element). The basic idea is similar to video rotation and colorspace handling: the 3D mode is added as a property to the video params. Depending on this property, a video filter can be inserted. As of this commit, extending mp_image_params is actually completely unnecessary - but the idea is that it will make it easier to integrate with VOs supporting stereo 3D mogrification. Although vo_opengl does support some stereo rendering, it didn't support the mode my sample file used, so I'll leave that part for later. Not that most mappings from Matroska mode to vf_stereo3d mode are probably wrong, and some are missing. Assuming that Matroska modes, and vf_stereo3d in modes, and out modes are all the same might be an oversimplification - we'll see. See issue #1045.
* cache_file: add a mode that creates a temporary filewm42014-08-301-15/+36
| | | | | | | Since we have to be portable, our options for creating temporary files are somewhat limited. tmpfile() happens to be available everywhere, so use that. This function doesn't allow having a "visible" filename or location, so we use the magic string "TMP" for this.
* player: reduce default demuxer cachewm42014-08-301-1/+1
| | | | | | | A (hopefully) temporary hack to make stream switching delays tolerable. It's not clear how this should be handled (either executing a precise seek on track switching, or always enabling all streams), so get this issue out of the way for now by picking a rather low value.
* manpage: document that --cache-file doesn't work with ordered chapterswm42014-08-301-0/+2
|
* manpage: fix minor grammar issuewm42014-08-291-1/+1
|
* command: export demuxer cache info propertieswm42014-08-281-0/+9
|
* player: redo how stream caching and pausing on low cache workswm42014-08-271-14/+9
| | | | | | | | | | | | | | | | | | | Add the --cache-secs option, which literally overrides the value of --demuxer-readahead-secs if the stream cache is active. The default value is very high (10 seconds), which means it can act as network cache. Remove the old behavior of trying to pause once the byte cache runs low. Instead, do something similar wit the demuxer cache. The nice thing is that we can guess how many seconds of video it has cached, and we can make better decisions. But for now, apply a relatively naive heuristic: if the cache is below 0.5 secs, pause, and wait until at least 2 secs are available. Note that due to timestamp reordering, the estimated cached duration of video might be inaccurate, depending on the file format. If the file format has DTS, it's easy, otherwise the duration will seemingly jump back and forth.
* vo_opengl: add parameter to gaussian filterBin Jin2014-08-261-1/+9
| | | | | | | | | | Add a new parameter 'p' to gaussian filter. The new formula used a different base taken from fmtconv plugin, so that the new parameter is exactly same as the one used in Avisynth and Vapoursynth. The new default value is 2 / log(2) * 10, with the default value it conforms to the original kernel taken from vector-agg.
* vo_opengl: add radius options for filtersBin Jin2014-08-261-5/+16
| | | | | | | Add two new options, make it possible for user to set the radius for some of the filters with no fixed radius. Also add three new filters with the new radius parameter supported.
* vo_opengl: add cparam1 and cparam2 optionsBin Jin2014-08-261-0/+7
| | | | | | Although cscale is rarely used, it's possible that params of cscale are accidentally set to lparam1 and lparam2, which might cause unexpected results.
* manpage: mention that mp.commandv doesn't expand propertiesOtto Modinos2014-08-251-0/+4
| | | | | | | | The little lua snippet at #488 as well as the actual implementation seems to indicate that not expanding properties is indeed the correct behavior. Document that. Signed-off-by: wm4 <wm4@nowhere>
* options: compatibility hack for --slave-brokenwm42014-08-251-0/+2
| | | | | | | Seems some programs were still relying on it. Whatever, it's not hard to support. CC: @mpv-player/stable
* ao_dsound: raise default buffer size to 200ms, make it configurablewm42014-08-221-0/+3
|
* manpage: remove duplicated contentBin Jin2014-08-221-29/+0
| | | | | | | Probably be accidentally added in b6b8bffd. CC: @mpv-player/stable Signed-off-by: wm4 <wm4@nowhere>
* options.rst: fix warningAlexander Preisinger2014-08-201-1/+1
|
* command: add estimated-frame-count & estimated-frame-number propertiesAndrey Morozov2014-08-191-0/+7
| | | | Signed-off-by: wm4 <wm4@nowhere>
* manpage: fix opengl-hq defaultswm42014-08-181-1/+1
| | | | | | The FBO format was changed some time ago. CC: @mpv-player/stable
* DOCS/tech-overview.txt: some updateswm42014-08-181-17/+35
|
* video: enable framedropping by defaultwm42014-08-171-4/+4
|
* demux: enable thread by defaultwm42014-08-161-1/+3
| | | | And change the defaults for the other queue options to reduce latency.
* demux: add option to control the readahead buffer by a duration valuewm42014-08-161-3/+13
| | | | | | | | | | | | | --demuxer-readahead-secs now controls how much the demuxer should readahead by an amount of seconds. This is based on the raw packet timestamps. It's not always very exact. For example, h264 in Matroska does not store any linear timestamps (only PTS values which are going to be reordered by the decoder), so this heuristic is usually off by several hundred milliseconds. The decision whether to readahead is basically OR-ed with the other --demuxer-readahead-packets options. Change the manpage descriptions to subtly convey these semantics.
* video: add --display-fps switch to control framedrop FPSwm42014-08-161-0/+7
| | | | | | Since the display FPS is currently detected on X11 only (and even there it's known to be wrong on certain setups), it seems like a good idea to make this user-configurable.
* audio: add a mode to insert silence on severe A/V desyncwm42014-08-151-0/+5
| | | | | | This is probably a stupid idea, but it can't be denied that this actually allows playing video without larger desync, even if video is too slow.
* vo_opengl: optional support for using GLX_SGI_video_syncwm42014-08-151-0/+7
| | | | | | | | | I'm not sure about the merit, though it does print nice numbers if debug output is enabled. Basically, this tries to achieve similar results as the glFinish() business, but again it entirely depends on the drivers whether this does anything meaningful, or whether it's actively harmful.
* vo_opengl: if glfinish is used, also call it after swapppingwm42014-08-151-1/+3
| | | | | | It seems that at least on nvidia systems with composting disabled, we can get it to block deterministically on the actual vsync event, which should improve framedropping.
* video: add VO framedropping modewm42014-08-152-10/+39
| | | | | | | | | | | | | | | | | | | | | | | | This mostly uses the same idea as with vo_vdpau.c, but much simplified. On X11, it tries to get the display framerate with XF86VM, and limits the frequency of new video frames against it. Note that this is an old extension, and is confirmed not to work correctly with multi-monitor setups. But we're using it because it was already around (it is also used by vo_vdpau). This attempts to predict the next vsync event by using the time of the last frame and the display FPS. Even if that goes completely wrong, the results are still relatively good. On other systems, or if the X11 code doesn't return a display FPS, a framerate of 1000 is assumed. This is infinite for all practical purposes, and means that only frames which are definitely too late are dropped. This probably has worse results, but is still useful. "--framedrop=yes" is basically replaced with "--framedrop=decoder". The old framedropping mode is kept around, and should perhaps be improved. Dropping on the decoder level is still useful if decoding itself is too slow.
* sub: add option to workaround broken mkv fileswm42014-08-141-0/+7
| | | | See additions to options.rst.
* af_lavcac3enc: lower minimum channel number to 3wm42014-08-121-1/+1
| | | | It seems only stereo PCM should be passed through.
* docs: cocoa example uses wakeup callback APIFRAU KOUJIRO2014-08-121-22/+54
| | | | Also, imitate the qt example somewhat.
* docs: simple cocoa API usage exampleFRAU KOUJIRO2014-08-121-0/+85
|
* af_lavcac3enc: change default bitrate to 640wm42014-08-121-1/+3
| | | | | | | No reason to use less. Since the name "default" is misleading now, replace it with "auto" (still recognize the old name).
* video: move display and timing to a separate threadwm42014-08-121-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The VO is run inside its own thread. It also does most of video timing. The playloop hands the image data and a realtime timestamp to the VO, and the VO does the rest. In particular, this allows the playloop to do other things, instead of blocking for video redraw. But if anything accesses the VO during video timing, it will block. This also fixes vo_sdl.c event handling; but that is only a side-effect, since reimplementing the broken way would require more effort. Also drop --softsleep. In theory, this option helps if the kernel's sleeping mechanism is too inaccurate for video timing. In practice, I haven't ever encountered a situation where it helps, and it just burns CPU cycles. On the other hand it's probably actively harmful, because it prevents the libavcodec decoder threads from doing real work. Side note: Originally, I intended that multiple frames can be queued to the VO. But this is not done, due to problems with OSD and other certain features. OSD in particular is simply designed in a way that it can be neither timed nor copied, so you do have to render it into the video frame before you can draw the next frame. (Subtitles have no such restriction. sd_lavc was even updated to fix this.) It seems the right solution to queuing multiple VO frames is rendering on VO-backed framebuffers, like vo_vdpau.c does. This requires VO driver support, and is out of scope of this commit. As consequence, the VO has a queue size of 1. The existing video queue is just needed to compute frame duration, and will be moved out in the next commit.
* DOCS: mark the recent release in client-api-changes.rstwm42014-08-122-0/+3
| | | | | | | Also add instructions to release-policy.m