aboutsummaryrefslogtreecommitdiffhomepage
path: root/DOCS
Commit message (Collapse)AuthorAge
* player: redo how stream caching and pausing on low cache worksGravatar wm42014-08-27
| | | | | | | | | | | | | | | | | | | 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 filterGravatar Bin Jin2014-08-26
| | | | | | | | | | 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 filtersGravatar Bin Jin2014-08-26
| | | | | | | 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 optionsGravatar Bin Jin2014-08-26
| | | | | | 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 propertiesGravatar Otto Modinos2014-08-25
| | | | | | | | 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-brokenGravatar wm42014-08-25
| | | | | | | 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 configurableGravatar wm42014-08-22
|
* manpage: remove duplicated contentGravatar Bin Jin2014-08-22
| | | | | | | Probably be accidentally added in b6b8bffd. CC: @mpv-player/stable Signed-off-by: wm4 <wm4@nowhere>
* options.rst: fix warningGravatar Alexander Preisinger2014-08-20
|
* command: add estimated-frame-count & estimated-frame-number propertiesGravatar Andrey Morozov2014-08-19
| | | | Signed-off-by: wm4 <wm4@nowhere>
* manpage: fix opengl-hq defaultsGravatar wm42014-08-18
| | | | | | The FBO format was changed some time ago. CC: @mpv-player/stable
* DOCS/tech-overview.txt: some updatesGravatar wm42014-08-18
|
* video: enable framedropping by defaultGravatar wm42014-08-17
|
* demux: enable thread by defaultGravatar wm42014-08-16
| | | | And change the defaults for the other queue options to reduce latency.
* demux: add option to control the readahead buffer by a duration valueGravatar wm42014-08-16
| | | | | | | | | | | | | --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 FPSGravatar wm42014-08-16
| | | | | | 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 desyncGravatar wm42014-08-15
| | | | | | 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_syncGravatar wm42014-08-15
| | | | | | | | | 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 swapppingGravatar wm42014-08-15
| | | | | | 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 modeGravatar wm42014-08-15
| | | | | | | | | | | | | | | | | | | | | | | | 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 filesGravatar wm42014-08-14
| | | | See additions to options.rst.
* af_lavcac3enc: lower minimum channel number to 3Gravatar wm42014-08-12
| | | | It seems only stereo PCM should be passed through.
* docs: cocoa example uses wakeup callback APIGravatar FRAU KOUJIRO2014-08-12
| | | | Also, imitate the qt example somewhat.
* docs: simple cocoa API usage exampleGravatar FRAU KOUJIRO2014-08-12
|
* af_lavcac3enc: change default bitrate to 640Gravatar wm42014-08-12
| | | | | | | 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 threadGravatar wm42014-08-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.rstGravatar wm42014-08-12
| | | | | | | Also add instructions to release-policy.md, since this can be easily forgotten. CC: @mpv-player/stable
* input.conf: make explanatory text more readableGravatar wm42014-08-11
| | | | | Or at leats this is the intention. It's a bit hard to tell which information is needed, and which not.
* manpage: update keybindingsGravatar wm42014-08-11
|
* Move status-line.luaGravatar wm42014-08-11
| | | | | 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 modeGravatar wm42014-08-09
| | | | | | | | | 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 bindingsGravatar wm42014-08-08
|
* manpage: add sections and order by usageGravatar Alexander Preisinger2014-08-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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" propertyGravatar wm42014-08-08
| | | | | | 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 mpvGravatar wm42014-08-07
| | | | | 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 macroGravatar wm42014-08-05
| | | | | | | 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 cleanupsGravatar wm42014-08-03
| | | | | | | | | | | | | 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 locatedGravatar wm42014-08-02
|
* manpage: explain how to replace --slave-brokenGravatar wm42014-08-02
|
* command: add a property that returns a list of all propertiesGravatar wm42014-08-02
| | | | Also remove the undocumented Lua mp.property_list() function.
* manpage: remove duplicated misplaced description of a commandGravatar wm42014-08-02
|
* Remove the last remains of slave modeGravatar wm42014-08-01
| | | | | | | | | | | 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 propertyGravatar wm42014-07-31
|
* video/filter: add vf_bufferGravatar wm42014-07-30
| | | | Mostly useful for debugging.
* ao_alsa: disable use of non-interleaved formats by defaultGravatar wm42014-07-30
| | | | | | | | 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-oGravatar wm42014-07-30
| | | | | 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 fieldsGravatar wm42014-07-29
| | | | | 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 workaroundsGravatar wm42014-07-26
| | | | | | | | | | | | | | | | 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"Gravatar wm42014-07-26
| | | | | | | It's evil and sounds outdated. Use the words "media" and "video" instead. Closes #935.
* manpage: fix a typoGravatar wm42014-07-24
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-13 14:38:18 +0000