summaryrefslogtreecommitdiffstats
path: root/DOCS
Commit message (Collapse)AuthorAgeFilesLines
* 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.md, since this can be easily forgotten. CC: @mpv-player/stable
* input.conf: make explanatory text more readablewm42014-08-111-0/+1
| | | | | Or at leats this is the intention. It's a bit hard to tell which information is needed, and which not.
* manpage: update keybindingswm42014-08-111-1/+1
|
* Move status-line.luawm42014-08-111-69/+0
| | | | | Looks like TOOLS/lua/ is now established as dumping ground for random Lua scripts, so DOCS/lua_examples/ is not needed anymore.
* video: remove "hard" framedrop modewm42014-08-091-4/+8
| | | | | | | | | Completely useless, and could accidentally be enabled by cycling framedrop modes. Just get rid of it. But still allow triggering the old code with --vd-lavc-framedrop, in case someone asks for it. If nobody does, this new option will be removed eventually.
* manpage: update key bindingswm42014-08-081-36/+6
|
* manpage: add sections and order by usageAlexander Preisinger2014-08-081-1677/+1810
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Split the options into the following sections: * Playback Control * Program Behaviour * Video * Audio * Subtitles * Window * Disc Devices * Equalizer * Demuxer * Input * OSD * Screenshot * Software Scaler * Terminal * TV * Cache * Network * DVB * PVR * Miscellaneous Most options are sorted by usefullness and how often they're used or how important they are. This makes finding the right options easier and adds some sort of structure.
* command: add a "seeking" propertywm42014-08-081-0/+6
| | | | | | The client API exports this state via events already, but maybe it's better to explicitly provide this property in order to facilitate use on OSD and similar cases.
* client API: qtexample: don't pass deallocated strings to mpvwm42014-08-071-1/+2
| | | | | The temporary QByteArray is deallocated already at the end of the statement in C++, instead of the end of the scope (like in C).
* client API: add and use the MPV_MAKE_VERSION macrowm42014-08-051-0/+1
| | | | | | | This is probably nicer. The actual version number doesn't change (other than the minor being incremented). The "| 0UL" is to make the type unsigned long int, like it was before.
* player: some further playloop cleanupswm42014-08-032-6/+9
| | | | | | | | | | | | | Handle --term-playing-msg at a better place. Move MPV_EVENT_TICK hack into a separate function. Also add some words to the client API that you shouldn't use it. (But better leave breaking it for later.) Handle --frames and frame_step differently. Remove the mess from the playloop, and do it after frame display. Give up on the weird semantics for audio-only mode (they didn't make sense anyway), and adjust the manpage accordingly.
* manpage: be more explicit where input.conf is locatedwm42014-08-022-1/+6
|
* manpage: explain how to replace --slave-brokenwm42014-08-021-0/+10
|
* command: add a property that returns a list of all propertieswm42014-08-021-0/+2
| | | | Also remove the undocumented Lua mp.property_list() function.
* manpage: remove duplicated misplaced description of a commandwm42014-08-021-2/+0
|
* Remove the last remains of slave modewm42014-08-012-32/+10
| | | | | | | | | | | Almost nothing was left of it. The only thing this commit actually removes is support for reading input commands from stdin. But you can emulate this via: --input-file=/dev/stdin --input-terminal=no However, this won't work on Windows. Just use a named pipe.
* command: add cache-idle propertywm42014-07-311-2/+6
|
* video/filter: add vf_bufferwm42014-07-301-0/+6
| | | | Mostly useful for debugging.
* ao_alsa: disable use of non-interleaved formats by defaultwm42014-07-301-0/+4
| | | | | | | | Some ALSA plugins take non-interleaved audio, but treat it as interleaved, which results in various funny bugs. Users keep hitting this issue, and it just doesn't seem worth the trouble. CC: @mpv-player/stable
* stream_lavf: allow setting AVOptions with --stream-lavf-owm42014-07-301-0/+7
| | | | | This commit also creates a private option struct for stream_lavf.c, but since I'm lazy, I'm not moving any existing options to it.
* manpage: lua: document timer timeout and oneshot fieldswm42014-07-291-0/+14
| | | | | Might be useful for scripts, so document them. (Which means scripts are allowed to use them, without risking breakage.)
* ao_pulse: allow disabling timing bug workaroundswm42014-07-261-0/+6
| | | | | | | | | | | | | | | | Add an option that enables using native PulseAudio auto-updated timing information, instead of the manual calculations added in mplayer2 times. You can use --ao=pulse:no-latency-hacks to enable the new code. The code is almost the same as the code that was removed with commit de435ed5, but I didn't readd some bits I didn't understand. Likewise, the option will disable the code added with that commit. In my tests this seemed to work well, though the A/V sync display looks funny when seeking. The default is still the old behavior. See issue #959.
* manpage: eliminate the word "movie"wm42014-07-264-29/+29
| | | | | | | It's evil and sounds outdated. Use the words "media" and "video" instead. Closes #935.
* manpage: fix a typowm42014-07-241-1/+1
|
* command: add append-play loadfile modewm42014-07-231-0/+2
| | | | | | | | "loadfile filename append-play" will now always append the file to the playlist, and if nothing is playing yet, start playback. I don't want to change the semantics of "append" mode, so a new mode is needed. Probably fixes issue #950.
* sub: add detection via BOMwm42014-07-221-0/+3
| | | | | | | | | | | Useful for Windows stuff. Actually, ENCA support should catch this, but, well, whatever, everyone seems to hate ENCA. Detection with BOM is trivial, although it needs some hackery to integrate it with the existing autodetection support. For one, change the default value of --sub-codepage to make this easier. Probably fixes issue #937 (the second part).
* manpage: correct the --mf optionswm42014-07-211-6/+6
| | | | | | | The MPlayer style syntax ("-mf fps=10:type=png") was removed a while ago, and now only the flat variants ("--mf-fps=10" etc.) work. CC: @mpv-player/stable
* manpage: fix wording for --aidwm42014-07-201-2/+3
|
* manpage: fix documented default for --demuxer-threadwm42014-07-171-1/+1
|
* demux: add a demuxer threadwm42014-07-161-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a thread to the demuxer which reads packets asynchronously. It will do so until a configurable minimum packet queue size is reached. (See options.rst additions.) For now, the thread is disabled by default. There are some corner cases that have to be fixed, such as fixing cache behavior with webradios. Note that most interaction with the demuxer is still blocking, so if e.g. network dies, the player will still freeze. But this change will make it possible to remove most causes for freezing. Most of the new code in demux.c actually consists of weird caches to compensate for thread-safety issues (with the previously single-threaded design), or to avoid blocking by having to wait on the demuxer thread. Most of the changes in the player are due to the fact that we must not access the source stream directly. the demuxer thread already accesses it, and the stream stuff is not thread-safe. For timeline stuff (like ordered chapters), we enable the thread for the current segment only. We also clear its packet queue on seek, so that the remaining (unconsumed) readahead buffer doesn't waste memory. Keep in mind that insane subtitles (such as ASS typesetting muxed into mkv files) will practically disable the readahead, because the total queue size is considered when checking whether the minimum queue size was reached.
* DOCS/release-policy: mention the release version in the RELEASE_NOTES templateAlessandro Ghedini2014-07-131-1/+13
| | | | Also suggest adding changes in point releases to RELEASE_NOTES as well.
* DOCS/tech-overview: minor updateswm42014-07-091-12/+12
|
* Remove stream_pts stuffwm42014-07-062-5/+1
| | | | | This was used by DVD/BD, but its usage was removed with one of the previous commits.
* DOCS/client-api-changes: try to fix rst formatting againwm42014-07-061-3/+4
|
* DOCS, client API: add mpv release versionswm42014-07-051-0/+3
| | | | | | | | The intention is to make it obvious which mpv releases certain changes will apply to. Also attempt to fix RST formatting of the list. This is not very proper, but probably good enough.
* DOCS/client_api_examples: add a Qt examplewm42014-07-043-0/+177
| | | | | This is pretty dumb and extremely basic. The main purpose is demonstrating how to integrate mpv into the Qt GUI thread.
* DOCS: add a file listing API changes for the client APIwm42014-07-032-0/+36
|
* manpage: reflect new coreaudio changesStefano Pigozzi2014-07-021-1/+13
|
* command: change cache perentage to float, add cache-free and cache-usedAndrey Morozov2014-07-021-1/+7
|
* options: add --list-protocols optionAlessandro Ghedini2014-06-301-0/+3
|
* options: support setting start time relative to start PTSTsukasa OMOTO2014-06-291-3/+6
| | | | Signed-off-by: wm4 <wm4@nowhere>
* player: make the time display relative to start PTSTsukasa OMOTO2014-06-291-0/+3
| | | | |