summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* timer: switch to CLOCK_MONOTONICwm42014-03-091-0/+10
| | | | | | | | | | | | | | | | | | | | | | | Apparently, this is always _really_ monotonic, despite what the Linux manpages say. So this should be much better than gettimeofday(). (At times there were kernel bugs which broke the monotonic property.) From the perspective of the player, time can still be discontinuous (you could just stop the process with ^Z), but at least it's guaranteed to be monotonic without further hacks required. Also note that clock_gettime() returns the time in nanoseconds. We want microseconds only, because that's the unit we chose internally. Another problem is that nanoseconds can wrap pretty quickly (less than 300 years in 63 bits), so it's just better to use microseconds. The devision won't make the code that much slower (compilers can avoid a real division). Note: this expects that the system provides clock_gettime() as well as CLOCK_MONOTONIC. Both are optional according to POSIX. The only system I know which doesn't have these, OSX, has seperate timer code anyway, but I still don't know whether more obscure (yet supported) platforms have a problem with this, so I'm playing safely. But this still expects that CLOCK_MONOTONIC always works at runtime if it's defined.
* DOCS: fix an external linkwm42014-03-091-3/+3
| | | | This got lost in commit b980884f.
* mpv.desktop: add video/mp2t mime typewm42014-03-091-1/+1
| | | | Closes #625.
* audio: don't write audio when pausedwm42014-03-091-0/+5
| | | | | | | | | | This is probably "safer". Without it, we will play 1 sample, because the logic was written in a way to decode 1 sample if audio is paused. 1 sample usually will initialize the audio PTS, but not play any real audio. Also see previous commit. In ancient times, this actually used 1 byte (instead of 1 sample), so clearly no sample was written, unless the audio was 8-bit mono.
* audio: remove handling of partially written datawm42014-03-093-21/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the ao_buffer_playable_samples field. This contained the number of samples that fill_audio_out_buffers() wanted to write to the AO (i.e. this data was supposed to be played at some point), but ao_play() rejected it due to partial fill. This could happen with many AOs, notably those which align all written data to an internal period size (often called "outburst" in the AO code), and the accepted number of samples is rounded down to period boundaries. The left-over samples at the end were still kept in mpctx->ao_buffer, and had to be played later. The reason ao_buffer_playable_samples had to exist was to make sure that at EOF, the correct number of left-over samples was played (and not possibly other data in the buffer that had to be sliced off due to endpts in fill_audio_out_buffers()). (You'd think you could just slice the entire buffer, but I suspect this wasn't done because the end time could actually change due to A/V sync changes. Maybe that was the reason it's so complicated.) Some commits ago, ao.c gained internal buffering, and ao_play() will never return partial writes - as long as you don't try to write more samples than ao_get_space() reports. This is always the case. The only exception is filling the audio buffers while paused. In this case, we decode and play only 1 sample in order to initialize decoding (e.g. on seeking). Actually playing this 1 sample is in fact a bug, but even of the AO doesn't have period size alignment, you won't notice it. In summary, this means we can safely remove the code.
* audio/out: make draining a separate operationwm42014-03-0921-82/+116
| | | | | | | | | | | | Until now, this was always conflated with uninit. This was ugly, and also many AOs emulated this manually (or just ignored it). Make draining an explicit operation, so AOs which support it can provide it, and for all others generic code will emulate it. For ao_wasapi, we keep it simple and basically disable the internal draining implementation (maybe it should be restored later). Tested on Linux only.
* ao_portaudio: use new pull API helperswm42014-03-091-147/+13
| | | | | | Same deal as with the previous commit. We don't lose any functionality, except for waiting "properly" on audio end, instead of waiting using the delay estimate.
* ao_jack: use new pull API helperswm42014-03-092-199/+16
| | | | | | | | | | | This removes the ringbuffer management from the code, and uses the generic code added with the previous commit. The result should be pretty much the same. The "estimate" sub-option goes away. This estimation is now always active. The new code for delay estimation is slightly different, and follows the claim of the jack framework that callbacks are timed exactly.
* audio/out: feed AOs from a separate threadwm42014-03-097-31/+593
| | | | | | | | | | | | | | | | | | This has 2 goals: - Ensure that AOs have always enough data, even if the device buffers are very small. - Reduce complexity in some AOs, which do their own buffering. One disadvantage is that performance is slightly reduced due to more copying. Implementation-wise, we don't change ao.c much, and instead "redirect" the driver's callback to an API wrapper in push.c. Additionally, we add code for dealing with AOs that have a pull API. These AOs usually do their own buffering (jack, coreaudio, portaudio), and adding a thread is basically a waste. The code in pull.c manages a ringbuffer, and allows callback-based AOs to read data directly.
* encode: add lockingwm42014-03-094-24/+99
| | | | | | | | | | Since the AO will run in a thread, and there's lots of shared state with encoding, we have to add locking. One case this doesn't handle correctly are the encode_lavc_available() calls in ao_lavc.c and vo_lavc.c. They don't do much (and usually only to protect against doing --ao=lavc with normal playback), and changing it would be a bit messy. So just leave them.
* command: fix osd-height propertywm42014-03-091-1/+1
|
* ao_null: add option for simulated device speedwm42014-03-092-2/+13
| | | | Helps with testing and debugging.
* ao: remove opts fieldwm42014-03-092-2/+0
| | | | Apparently unused.
* audio/out: make ao struct opaquewm42014-03-0926-117/+218
| | | | | | We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
* 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
| | |