summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* encode: don't access ao->ptswm42014-03-075-1/+20
| | | | | | | | | | This field will be moved out of the ao struct. The encoding code was basically using an invalid way of accessing this field. Since the AO will be moved into its own thread too and will do its own buffering, the AO and the playback core might not even agree which sample a PTS timestamp belongs to. Add some extrapolation code to handle this case.
* lua: add license headerwm42014-03-071-0/+17
| | | | Oops.
* common: add some helper macroswm42014-03-071-0/+3
|
* Merge pull request #619 from mpv-player/wasapi/better_timingDiogo Franco2014-03-061-4/+87
|\ | | | | ao_wasapi: Add device latency to get_delay
| * ao_wasapi: Slightly improve timer accuracyDiogo Franco (Kovensky)2014-03-061-3/+12
| | | | | | | | | | | | | | | | | | | | | | Use QueryPerformanceCounter to improve the accuracy of IAudioClock::GetPosition. While this is mainly for "realtime correctness" (usually the delay is a single sample or less), there are cases where IAudioClock::GetPosition takes a long time to return from its call (though the documentation doesn't define what a "long time" is), so correcting its value might be important in case the documented possible delay happens.
| * ao_wasapi: Add device latency to get_delayDiogo Franco (Kovensky)2014-03-061-4/+78
|/ | | | | | | | | | | The lack of device latency made get_delay report latencies shorter than they should; on systems with fast enough drivers, the delay is not perceptible, but high enough invisible delays would cause desyncs. I'm not yet completely sure whether this is 100% accurate, there are some issues involved when repeatedly pausing+unpausing (the delay might jump around by several dozen miliseconds), but seeking seems to be working correctly now.
* wayland/shm: fix leak in buffer poolAlexander Preisinger2014-03-061-10/+13
| | | | Rename it to reinit and check if parts of the pool are already allocated.
* ao_jack: fix termination on the end of filewm42014-03-051-3/+19
| | | | | | | | | | | | | | | | | | | | The player didn't quit when the end of a file was reached. The reason for this is that jack reported a constant audio delay even when all audio was done playing. Whether that was recognized as EOF by the player depended whether the exact value was higher or lower than the player's threshhold for what it considers no more audio. get_delay() should return amount of time it takes until the last sample written to the audio buffer reaches the speaker. Therefore, we have to track the estimated time when the last sample is done, and subtract it from the calculated latency. Basically, the latency is the only amount of time left in the delay, and it should go towards 0 as audio reaches ths speakers. I'm not sure if this is correct, but at least it solves the problem. One suspicious thing is that we use system time to estimate the end of the audio time. Maybe using jack_frame_time() would be more correct. But apart from this, there doesn't seem to be a better way to handle this.
* build: update wafwm42014-03-041-2/+2
| | | | <lachs0r> it fixes issues with recent python3
* demux_lavf: fix typo in commentwm42014-03-041-1/+1
| | | | Pushed too early...
* sub: use new FFmpeg API to check MicroDVD FPSwm42014-03-044-10/+21
| | | | | | Before this, it wasn't possible to distinguish MicroDVD subtitles without FPS header, and subtitles with FPS header equal to FFmpeg's fallback FPS.
* player: reformat some codewm42014-03-031-22/+14
|
* player: make separation between user/automatic track selection strongerwm42014-03-033-8/+29
| | | | | | | | | | For example, consider the case when audio initialization fails. Then the audio track is deselected. Before this commit, this would have been equivalent to the user disabling audio. This is bad when multiple files are played at once (the next file would have audio disabled, even if it works), or if playback resume is used (if e.g. audio output failed to initialize, then audio would be disabled when resuming, even if the system's audio driver was fixed).
* m_property: allow setting string properties via M_PROPERTY_SET_STRINGwm42014-03-031-2/+1
| | | | | | | | | | | | | | | | | Setting string options to strings over the m_option fallback (i.e. M_PROPERTY_SET_STRING is called if the option type is CONF_TYPE_STRING) failed. This was because m_option_parse() returns 0. 0 still means success, but the property code tried to be clever, and considered 0 not a success in order to disallow setting flags to an emtpy string (which in turn is allowed, because the command line allows flag options without parameters). Fix this by removing the overly clever code. This could happen when e.g. using the "set" command on options/title (a string option), and also was a problem for the client API. Closes #610.
* command: fix null pointer dereference in idle modewm42014-03-021-2/+2
| | | | Pressing 'h' in idle mode -> crash.
* player: cheap hack against idle event feedback loopwm42014-03-012-2/+7
| | | | | | | | | | | The OSC used significant CPU time while the player was paused. It turned out that the "tick" event sent during pause is the problem. The OSC accesses the player core when receiving a tick event, which in turn will cause the core to send another tick event, leading to infinite feedback. Fix this by sending an idle tick only every 500ms. This is not very proper, but the idea behind the tick event isn't very clean to begin with (and the OSC should use timers instead).
* client API: fix playloop thread wakeupwm42014-03-011-0/+9
| | | | | | | | | | | | | | The playloop usually waits in select(), using a timeout needed for refilling audio and video buffers. This means the client API needs a separate mechanism to interrupt the select() call. This mechanism exists, but I forgot to use it. This commit fixes it. If it works, this will make the client API react faster, epsecially in audio-only mode. If video is enabled, the reaction time is capped to 50ms (or somewhat faster if the framerate is >20 fps), because the playloop stops reacting to anything in order to render and time the next video frame. (This will be fixed later by moving the VO to its own thread.)
* vo_opengl: minor simplificationwm42014-03-011-30/+24
| | | | I think this is easier to follow.
* vo_opengl: Include :icc-approx-gamma option in the 3DLUT cache headerNiklas Haas2014-03-011-2/+3
| | | | | This makes sure the ICC cache is recomputed when the :icc-approx-gamma option is changed, since it affects the output quite a lot.
* sd_ass: add a very simple and evil way to override ASS subtitle styleswm42014-03-013-6/+38
| | | | | | --ass-style-override=force now attempts to override the 'Default' style. May or may not work. In some situations it will work, but also mess up seemingly unrelated things like signs typeset with ASS.
* lua: set a proper chunk name for builtin moduleswm42014-03-011-1/+2
| | | | | | | | luaL_loadstring(), which was used until now, uses the start of the Lua code itself as chunk name. Since the chunk name shows up even with runtime errors triggered by e.g. Lua code loaded from user scripts, this looks a but ugly. Switch to luaL_loadbuffer(), which is almost the same as luaL_loadstring(), but allows setting a chunk name.
* lua: fix add_key_binding()wm42014-03-011-2/+2
| | | | | add_key_binding() didn't work, because it passed a flag that was renamed. add_forced_key_binding() worked, but did the wrong thing.
* lua: fix format string in luaL_error()wm42014-03-011-1/+1
|
* client API: fix timeout handlingwm42014-03-011-1/+4
| | | | | | (Again.) Fixed Lua timers as well.
* lua: fix use of renamed functionwm42014-03-011-3/+3
| | | | Apparently this was overlooked when get_timer was renamed to get_time.
* timer: add utility function to get relative timewm42014-02-282-0/+17
|
* msg: add --msgtime option to add timestamps to each output messagewm42014-02-283-2/+11
| | | | | | | Will be helpful to track down strange wait times and such issues, as well when you have develop something timing related. (Then you may print timestamps in your debug output, and the --msgtime timestamps will help giving context.)
* lua: add option to disable auto-loading of lua scriptswm42014-02-285-1/+11
|
* config: don't load global config files with --config-dirwm42014-02-281-1/+2
| | | | This sidestepped the usual logic by hardcoding the path.
* config: fix --config-dir logic for global config fileswm42014-02-281-1/+1
| | | | | Global config files should be loaded only when --no-config is missing _and_ --config-dir is not set.
* manpage: document properties added in previous commitwm42014-02-281-0/+7
|
* client API: add two properties, 'time-start' and 'seekable'xylosper2014-02-281-0/+21
|
* client APIs: fix some typosxylosper2014-02-282-2/+2
|
* audio: add enum name for speaker idxylosper2014-02-281-1/+1
|
* manpage: lua: fix typowm42014-02-281-1/+1
|
* manpage: lua: update from previous commitwm42014-02-281-1/+7
| | | | I forgot about this.
* client API: rename MPV_EVENT_PLAYBACK_START, add MPV_EVENT_SEEKwm42014-02-284-4/+23
| | | | | | Rename MPV_EVENT_PLAYBACK_START to MPV_EVENT_FILE_LOADED. Add MPV_EVENT_SEEK and MPV_EVENT_PLAYBACK_RESTART.
* client API: wait for remaining asynchronous requests before terminatingwm42014-02-281-0/+9
| | | | | | Sending an asynchronous request and then calling mpv_destroy() would crash the player when trying to send the reply to the removed client. Fix this by waiting until all remaining replies have been sent.
* ao: document some functionswm42014-02-282-3/+35
|
* DOCS: kill the rest of the old mplayer tech documentationwm42014-02-288-949/+0
| | | | Not really useful anymore, other than confusing everyone.
* command: use the step size for "add volume" commandswm42014-02-273-18/+4
| | | | | | | | | | | | The step argument for "add volume <step>" was ignored until now. Fix it. There is one problem: by defualt, "add volume" should use the value set with --volstep. This value is 3 by default. Since the default volue for the step argument is always 1 (and we don't really want to make the generic code more complicated by introducing custom step sizes), we simply multiply the step argument with --volstep to keep it compatible. The --volstep option should probably be just removed in the future.
* command: format volume property as integer for OSDwm42014-02-271-0/+6
| | | | | | | The value range is 0-100, so fractional values don't make much sense. But the underlying data type is probably float to avoid getting "stuck" when doing small volume increments. So step this around and pretend it's an integer just on display.
* vo_opengl: change gamma suboption to take a valuewm42014-02-273-9/+15
| | | | | | | | | | | | The previous version of the gamma suboption was pretty useless. It could be used to disable delayed gamma enabling, which is a mechanism to avoid having to adjust gamma in the shader by default. Repurpose the suboption and allow setting an exact gamma value with it. You can already override gamma with the --gamma option as well as the gamma input property, but these use a weird curve to create the impression of a linear perceived brightness change when changing the value. This suboption now allows setting an exact gamma value.
* vo_opengl: Change the default icc-intent to relative colorimetricNiklas Haas2014-02-262-3/+3
| | | | | | | | | | | | | | | | This used to be absolute colorimetric, but relative colorimetric is a saner default due to the arguments presented in issue #595. A short summary: In general it doesn't affect much because our eyes adapt to the white point either way, but if running in windowed mode it would make the whites seem inconsistent/tinted. For fullscreen projection it's also undesirable since it reduces the dynamic range without much benefit (again, since our eyes adapt either way) and it also breaks calibration against ambient lighting. This shouldn't change much, since most profile types that aren't 3DLUTs aren't capable of either of those transforms, and most displays are calibrated against D65 (same as BT.709 source) either way.
* lua: add set_property_native functionwm42014-02-262-5/+144
| | | | | | Probably completely useless, at least for now. Also not very well tested, but initial test seems successful.
* lua: mark table values returned by get_property_native with their typewm42014-02-262-1/+22
| | | | | | | Lua doesn't distinguish between arrays and maps on the language level; there are just tables. Use metatables to mark these tables with their actual types. In particular, it allows distinguishing empty arrays from empty tables.
* m_option: make converting mpv_node to string always failwm42014-02-261-1/+1
|
* lua: implement mp.get_opt() in Luawm42014-02-262-24/+9
| | | | | | Will be more expensive if used very often, but it's probably ok. Reduce the dependency of lua.c on MPContext a bit further.
* m_option: fix key/value list string conversionwm42014-02-261-1/+1
| | | | Meh.
* client API: don't send MPV_EVENT_IDLE when not entering idle modewm42014-02-261-2/+3
| | | | | | For simplicity, this was sent before actually checking the idle condition, which meant that we'd send it even of the idle loop is never entered.
* threads: fix wait time overflow checkwm42014-02-261-2/+2
| | | | | | | | | | | | | When passing a very large timeout to mpthread_cond_timed_wait(), the calculations could overflow, setting tv_sec to a negative value, and making the pthread_cond_timed_wait() call return immediately. This accidentally made Lua support poll and burn CPU for no reason. The existing overflow check was ineffective on 32 bit systems. tv_sec is usually a long, so adding INT_MAX to it will usually not overflow on 64 bit systems, but on 32 bit systems it's guaranteed to overflow. Simply fix by clamping against a relatively high value. This will work until 1 week before the UNIX time wraps around in 32 bits.
* client API: don't explode when destroying uninitialized mpv_handlewm42014-02-261-1/+2
|
* client API: accept NULL as mpv_destroy() argumentwm42014-02-261-0/+3
|
* options: fix --list-options outputwm42014-02-261-2/+2
| | | | This was a bit damaged by commit f3c933e5.
* client API: treat MPV_FORMAT_STRING differently in mpv_set_propertywm42014-02-261-19/+20
| | | | | | | | | | | | | | Always map MPV_FORMAT_STRING to setting property value directly through M_PROPERTY_SET_STRING, instead of trying to go through M_PROPERTY_SET_NODE. This treats a direct MPV_FORMAT_STRING query differently from a MPV_FORMAT_STRING wrapped in a mpv_node. This was already the case in mpv_get_property(). The reason for all this is that mpv_node is supposed to be the exact type, while a direct MPV_FORMAT_STRING goes through all possible conversions. Not sure if these semantics are good.
* m_property: fix confused error codewm42014-02-261-1/+1
| | | | This broke the client API.
* m_option: don't make "unset" string and string list return NULL stringswm42014-02-261-2/+2
| | | | | | | | | | This is a bit weird: m_option_string types (i.e. char*) can be NULL. But they're supposed to be treated just like empty strings. So don't make the m_option_type.print function return NULL for these values. Returning NULL would mean failure. This didn't matter much before, but was quite visible through the client API.
* client API: fix broken property/option functionsxylosper2014-02-261-3/+4
| | | | | | | | | | | | | | | | | | 1. Cannot set option after initialized: it seems that this bug has existed since libmpv was introduced first. Maybe just a typo. 2. Crash when setting property with native format: mpv_set_property just causes a crash when using a native format. I found an invalid casting and fixed it. 3. Wrong error value for mpv_get_property: when an error occurred, mpv_get_property always returns wrong format error because every error for property except M_PROPERTY_NOT_IMPLEMENTED is just ignored. Signed-off-by: wm4 <wm4@nowhere> Closes pull request #593. Does not incldue the first fix, which was not correct. The underlying bug will be fixed by a later commit. Commit message extracted from pull request and slightly edited.
* osd: override user bindings for OSC inputwm42014-02-263-5/+5
| | | | | | | | | E.g. binding MOUSE_BTN0 always used the user defined binding. While it is ok that the user can override mouse_move and mouse_leave (for whatever reasons), we want to strictly override the bindings when input is sent to the OSC itself. Regression since 03624a1.
* options: allow changing options at runtimewm42014-02-255-44/+56
| | | | | Allow changing all options at runtime, except some cherry-picked options, which are disabled with M_OPT_FIXED.
* client API: change description of format conversionswm42014-02-251-6/+10
| | | | | | | This changed during the time between writing the comment, and finishing up the implementation. Although I'm still unsure about this.
* config: when writing resume config, read options, not propertieswm42014-02-251-33/+33
| | | | | | | | | | | This lowers the number of data stored in the resume config a bit further, because some properties can't be read at program start and when e.g. the VO wasn't created yet. Some fields still need to be read from a property (actually only "volume-restore-data", a hack to save the full volume information). So abuse the "options/" property, and make use of the fact that changing things at runtime also changes the options.
* config: don't save options to resume-config that didn't changewm42014-02-253-5/+31
| | | | | | | | | | | | | | | | This is approximate: we read each option value on program start (before starting playback of a file), and when writing the resume config, compare each value to the current state. This also means when a value is changed and then changed back, it's not stored. In particular, option values set in config files and on the command line are considered the default. This should help reducing the numbers of options overridden by the resume config. If too much is overridden, it becomes an inconvenience, because changes in config files will apparently have no effect when resuming a file. Also see github issue #574.
* input: allow input.conf bindings to be declared as builtinwm42014-02-252-0/+14
| | | | | | This might be helpful if we ever want cascading config files. Also, we will probably need it if we change the default input.conf bindings, and want to provide compatibility input.conf files.
* config: always print resolved config paths in verbose modewm42014-02-251-50/+63
| | | | | Restructure the code to make that easier. There should be no functional changes, other than the log call at the end of each function.
* manpage: remove unused environment variablewm42014-02-251-3/+0
| | | | We removed gettext (which was disabled by default) a while ago.
* config: add a --config-dir option to force config directorywm42014-02-254-0/+29
| | | | Useful for slave-mode like uses, and not as radical as --no-config.
* config: don't write default config filewm42014-02-251-13/+3
| | | | | | This created an essentially empty config file. This is not really needed and probably causes more trouble than it solves (such as littering the home directory with crap), so get rid of it.
* manpage: Improve wording on icc-approx-gammaNiklas Haas2014-02-251-5/+5