summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* video: fix another cover art corner casewm42014-06-091-1/+1
| | | | | | | Playing a video and then an audio file with cover art kept displaying the last frame of the video. This was because the hasframe flag was set, perhaps due to redrawing the last video frame before the cover art image is decoded.
* client API: disable LIRC input by defaultwm42014-06-091-0/+1
| | | | | | Not only should using libmpv hog such global resources; it's also very unlikely an application embedding mpv will ever want to make use of this.
* audio: add a "weak" gapless mode, and make it defaultwm42014-06-095-18/+45
| | | | | | | | | | | | | | Basically, this allows gapless playback with similar files (including the ordered chapter case), while still being robust in general. The implementation is quite simplistic on purpose, in order to avoid all the weird corner cases that can occur when creating the filter chain. The consequence is that it might do not-gapless playback in more cases when needed, but if that bothers you, you still can use the normal gapless mode. Just using "--gapless-audio" or "--gapless-audio=yes" selects the old mode.
* player: show "neutral" position markers for OSD barswm42014-06-086-6/+33
| | | | This commit implements them for volume and some video properties.
* build: generate and install zsh completion scriptAlessandro Ghedini2014-06-084-1/+32
|
* TOOLS: add script for generating a zsh completion scriptAlessandro Ghedini2014-06-081-0/+129
| | | | As discussed in #775
* client API: minor documentation fixes/enhancementswm42014-06-082-4/+6
|
* client API: trigger wakeup when creating wakeup pipe/callbackwm42014-06-081-1/+5
| | | | | | | | | Since redundant wakeups are avoided now, it's easy to miss a wakeup when creating/setting the pipe/callback after the client API was signalled. If the client API is signalled, need_wakeup is set to true, and wakeup_client skips writing to the pipe or calling the client API. That this can happen is not very obvious to the client API, so trigger a wakeup right on start in order to remove this special case.
* manpage: document new --sub-file semanticswm42014-06-081-3/+11
| | | | This was forgotten in the previous commit.
* options: change --sub-file behaviorwm42014-06-083-1/+41
| | | | | | | | | | | | | | | | | | | --sub-file is actually a string list, so you can add multipel external subtitle files. But to be able to set a list, the option value was split on ",". This made it impossible to add filenames. One possible solution would be adding escaping. That's probably a good idea (and some other options already do this), but it's also complicated both to implement and for the user. The simpler solution is making --sub-file appending, and make it take only a single entry. I'm not quite sure about this yet. It breaks the invariant that if a value is printed and parsed, you get the same value back. So for now, just go with the simple solution. Fixes #840.
* client API: restructure waiting, do log msg wakeup properlywm42014-06-072-43/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | Until now, availability of new log messages (through the mechanism associated with mpv_request_log_messages()) did not wakeup the client API properly. Commit 3b7402b5 was basically a hack to improve that somewhat, but it wasn't a solution. The main problem is that the client API itself is producing messages, so the message callback would attempt to lock the client API lock, resulting in a deadlock. Even if the lock was recursive, we'd run into lock-order issues. Solve this by using a separate lock for waiting and wakeup. Also, since it's a natural addition, avoid redundant wakeups. This means the wakeup callback as well as the wakeup pipe will be triggered only once until the next mpv_wait_event() call happens. This might make the wakeup callback be invoked in a reentrant way for the first time, for example if a mpv_* function prints to a log. Adjust the docs accordingly. (Note that non-reentrant beheavior was never guaranteed - basically the wakeup callback is somewhat dangerous and inconvenient.) Also remove some traces of unneeded code. ctx->shutdown for one was never set, and probably a leftover of an abandoned idea.
* client API: rename mpv_destroy() to mpv_detach_destroy()wm42014-06-074-22/+21
| | | | | | A bit verbose, but less misleading. In most cases, the API user probably actually wants mpv_terminate_destroy() instead, so the less-useful function shouldn't have a simnpler name anyway.
* client API: clarify mpv_get_wakeup_pipe docswm42014-06-071-13/+43
| | | | | | | | | | | It wasn't necessarily clear how this works. Especially make clear that the API user shouldn't expect that there's one byte per readable event in the wakeup pipe. Actually, the reason why this currently won't work is because property notifications can generate more events than wakeups. The limit of 4096 is a more fundamental issue, but the event ringbuffer is currently limited to 1000 entries anyway. Also add some important comments to mpv_set_wakeup_callback.
* client API: add API function that ensures total destructionwm42014-06-074-3/+55
| | | | | | | | | | | | mpv_destroy() should perhaps better be called mpv_detach(), because it destroys only the handle, not necessarily the player. The player is only terminated if a quit command is sent. This function quits automatically, and additionally waits until the player is completely destroyed. It removes the possibility that the player core is still uninitializing, while all client handles are already destroyed. (Although in practice, the difference is usually not important.)
* client API: docs: some clarificationswm42014-06-071-1/+7
|
* client API: change mpv_wait_event() timeout semanticswm42014-06-073-3/+7
| | | | | | | | | Now a negative timeout mean an infinite timeout. This is similar to the poll() system call. Apparently this is more intuitive and less confusing than specifying a "very high" value as timeout if you want to wait forever. For callers that never pass negative timeouts, nothing changes.
* build: prevent installation of client API examplewm42014-06-061-0/+1
| | | | | | | | This was never intended to be installed; waf just picked it up automagically. There's also a closed ticket on github where someone complains that the program "simple" is installed, and I didn't realize at this point that it was actually installed by default when enabling the client API.
* client API: enlarge the message buffer if log level is highwm42014-06-061-1/+2
|
* client API: call wakeup callback if there are new messageswm42014-06-063-15/+29
| | | | | | | | | | | | | | | | | | Listening on messages currently uses polling (every time mpv_wait_event() has no new events, the message buffer is polled and a message event is possibly created). Improve this situation a bit, and call the user-supplied wakeup callback. This will increase the frequency with which the wakeup callback is called, but the client is already supposed to be able to deal with this situation. Also, as before, calling mpv_wait_event() from the wakeup callback is forbidden, so the client can't read new messages from the callback directly. The wakeup pipe is written either. Since the wakeup pipe is created lazily, we can't access the pipe handle without creating a race condition or a deadlock. (This is actually very silly, since in practice the race condition won't matter, but for now let's keep it clean.)
* x11: cleanup motif hints handlingwm42014-06-062-38/+17
| | | | | | | | It seems we can't really get rid of this. There are no other hints to remove decorations that work across all reasonable WMs, so we're stuck with the ugly motif stuff. But at least we can make the code for it less ugly.
* client API: fix terminal usagewm42014-06-061-1/+4
| | | | | | By default this is disabled. But if it's enabled, then we have to account for proper states when enabling/disabling the terminal state itself.
* client API: don't update properties in uninitialized statewm42014-06-061-0/+2
| | | | | | If an API user calls mpv_wait_event() and mpv_observe_property() before mpv_initialize(), it could happen that a property was accessed before initialization, which is not ok.
* client API: don't use the mpv config files by defaultwm42014-06-061-0/+1
| | | | | | | | | This was always intended this way, and even documented in client.h. Due to an oversight it was never actually implemented. The intention is that mpv embedded in applications and "real mpv" don't conflict. An API user can undo this by setting the "config" option to "yes", if using the user's mpv config is desired.
* client API: use shared code for creating the wakeup pipewm42014-06-061-12/+2
| | | | Should be equivalent, reduces code duplication.
* client API: fix swapped pipe ends used with mpv_set_wakeup_callbackwm42014-06-061-2/+2
| | | | | This was extremely wrong. It was never tested because nobody ever used it (the feature was added for someone who never tried it in the end).
* input: don't print warning when aboting playback via commandswm42014-06-061-6/+1
| | | | I don't really see a reason for this.
* wscript: update waf version check to the version in bootstrap.pywm42014-06-061-1/+1
|
* sub: remove old style override optionwm42014-06-053-34/+2
| | | | Didn't work too well.
* sub: add --ass-style-override=force optionwm42014-06-053-4/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (The old "force" choice of that option is renamed to "force-default".) This allows overriding native ASS script subtitle styles with the style provided by the --sub-text-* options (like --sub-text-font etc.). This is disabled by default, and needs to be explicitly enabled with the --ass-style-override=force option and input property. This uses in fact exactly the same options (--sub-text-*) and semantics as the ones used to configure unstyled text subtitles. It's recommended to combine this with this in the mpv config file: ass-force-style="ScaledBorderAndShadow=1" # work around dumb libass behavior Also, adding a key binding to toggle this behavior should be added, because overriding can easily break: L cycle ass-style-override This would cycle override behavior on Shift+L and allows quickly disabling/enabling style overrides. Note: ASS should be considered a vector format rather than a subtitle format. There is no easy or reliable way to determine whether the style of a given subtitle event can be changed without destroying visuals or not. This patch relies on a simple heuristic, which often works and often breaks.
* stream/cache: handle failure of seeking underlying streamwm42014-06-051-1/+4
| | | | | | | | | | | | This could for example happen when serving an incomplete file from http, and the demuxer tries reading data from the end of the file when opening it (e.g. with avi). Seeking past EOF fails with http, so the file could never be opened, and the cache would get stuck trying to seek to the position. We can't really make the cache report seek failure directly (it would suck for various reasons), so just make the cache report EOF if seeking fails.
* lua: make warning about unknown scripts -v onlywm42014-06-041-1/+1
|
* filter_kernels: fix nearest scalerwm42014-06-041-1/+1
| | | | | | | | | | The previous commit assumed the filter would be 1x1 (then constant weight is correct) - but our code in fact uses at least a 2x2 filter. A 1x1 filter would generally be useless, except for nearest scaling - so it didn't exist. Insteasd of adding such a 1x1 filter, just turn the nearest weight function into a scare function, which should take care of the issue.
* filter_kernels: add nearest neighbour scalinglucy2014-06-031-0/+6
| | | | | | This is useful for playing content containing pixel art that hasn't been pre-scaled, such as TASVideos' high quality encodes. The implementation is lifted from <https://code.google.com/p/glumpy/source/browse/glumpy/image/filter.py#413>.
* audio/out/push: don't attempt to fill AO buffer when pausedwm42014-06-031-2/+3
| | | | Doing so will implicitly resume playback. Broken in commit 5929dc45.
* command: format_bitrate: fix conversion to kbits and mbitsMarcoen Hirschberg2014-06-021-2/+2
| | | | | | | Bitrates are now expressed in bits/second. This commit fixes conversions which assumed it was still in bytes/second. Signed-off-by: wm4 <wm4@nowhere>
* osc: keep track of the "fullscreen" state when it changesMarcoen Hirschberg2014-06-021-3/+6
| | | | | This avoids having to poll the "fullscreen" property in the tick callback.
* wayland: remove stub for unimplemented functionwm42014-06-021-15/+0
|
* osd/libass: use BorderStyle=4 for backgroundwm42014-06-011-0/+11
| | | | Avoids (some) overlaps. Hopefully fixes #822.
* player: write file name to the watch later config fileAlessandro Ghedini2014-06-014-0/+13
| | | | | | | | | This simply writes the file name as a comment to the top of the watch later config file. It can be useful to the user for determining whether a watch later config file can be manually removed (e.g. in case the corresponding media file has been deleted) or not.
* audio: prefer dsound over wasapiwm42014-06-011-3/+3
| | | | | ao_wasapi has too many subtle failures that were reported, but there's nobody to fix them. ao_dsound seems to be more robust; so prefer it.
* demux_lavf: support new rotation metadata APIwm42014-06-013-1/+23
|
* command: improve video-bitrate propertyAndrey Morozov2014-06-012-1/+7
| | | | | | Signed-off-by: wm4 <wm4@nowhere> Includes some cosmetic changes over the original PR.
* vo: correctly initialize parameters in corner caseswm42014-06-011-1/+4
|
* m_option: use isfinite() instead of isnormal()wm42014-06-011-1/+1
| | | | | | This accidentally rejected d==0. We can actually deal with sub-normals fine, we just want to exclude nan and infinity (although infinity is already accounted for, but anyway).
* stream: remove VCD supportwm42014-06-0112-1013/+0
| | | | | | | | | If a single person complains, I will readd it. But I don't expect that this will happen. The main reason for removing this is that it's some of the most unclean code remaining, it's unmaintained, and I've never ever heard of someone using it.
* client API: report success status when running commandswm42014-06-014-35/+52
| | | | | | Until now, an error was reported only if the command couldn't be parsed. Attempt to do more fine-grained reporting. This is not necessarily perfect, but it's an improvement.
* command: property notification when changing af/vfwm42014-06-011-0/+1
|
* command: add const to mp_notify_propertywm42014-06-012-2/+2
|
* player: hide audio/video codec and file format messageswm42014-05-313-7/+5
| | | | | None of these are very important usually. For error analysis, the plain log is useless anyway, and this information is still printed with "-v".
* gl_common: remove dlsym() fallbackwm42014-05-311-21/+1
| | | | See previous commits.
* gl_wayland: remove probably unneeded workaroundwm42014-05-311-2/+0
| | | | | | | | This would imply eglGetProcAddress() doesn't work correctly, but using dlsym() does. For now get rid of it - it won't work in libmpv, and we'll probably need a better workaround if it's still broken. This code was in the initial wayland commit.
* gl_x11: remove workaround for PPC OSX 10.4wm42014-05-311-7/+0
| | | | | Added in 2010 with commit 4a8486f8 (svn commit 30994). I doubt anyone still uses X11 on OSX, and we probably don't support 10.4 either.
* gl_x11: always require some GLX API functions, avoid dlsym()wm42014-05-314-20/+9
| | | | | | | | | | | | | | The functions glXGetProcAddressARB() and glXQueryExtensionsString() were loaded using dlsym(). This could fail when compiling to libmpv, because then dlopen(NULL, ...) will look in the main program's list of libraries, and the libGL linked to libmpv is never considered. (Don't know if this somehow could be worked around.) The result is that using vo_opengl with libmpv can fail. Avoid this by not using dlsym(). glXGetProcAddressARB() was already used directly in the same file, and that never caused any problems. (Still add it to the configure test.) glXQueryExtensionsString() is documented as added in GLX 1.1 - that's ancient.
* ao_alsa: make device the first sub optionwm42014-05-312-4/+4
| | | | This is more convenient.
* audio/out/push: keep some extra bufferwm42014-05-311-6/+4
| | | | | | | | | | | | | | | | | | | So the device buffer can be refilled quickly. Fixes dropouts in certain cases: if all data is moved from the soft buffer to the audio device buffer, the waiting code thinks it has to enter the mode in which it waits for new data from the decoder. This doesn't work, because the get_space() logic tries to keep the total buffer size down. get_space() will return 0 (or a very low value) because the device buffer is full, and the decoder can't refill the soft buffer. But this means if the AO buffer runs out, the device buffer can't be refilled from the soft buffer. I guess this mess happened because the code is trying to deal with both AOs with proper event handling, and AOs with arbitrary behavior. Unfortunately this increases latency, as the total buffered audio becomes larger. There are other ways to fix this again, but not today. Fixes #818.
* ao_alsa: reduce spurious wakeupswm42014-05-302-10/+18
| | | | | | Apparently this can happen. So actually only return from waiting if ALSA excplicitly signals that new output is available, or if we are woken up externally.
* tv: remove sysinfo() usagewm42014-05-303-18/+0
| | | | | | This call was used limited the buffer size if installed RAM was below 16 MB. This stopped being useful a decade ago. The check could also overflow on 32 bit systems. Just get rid of it.
* audio/out/push: handle draining correctlywm42014-05-301-7/+22
| | | | | | | | | This did not flush remaining audio in the buffer correctly (in case an AO has an internal block size). So we have to make the audio feed thread to write the remaining audio, and wait until it's done. Checking the avoid_ao_wait variable should be enough to be sure that all data that can be written was written to the AO driver.
* audio: change handling of an EOF corner casewm42014-05-302-12/+10
| | | | | | This code handles buggy AOs (even if all AOs are bug-free, it's good for robustness). Move handling of it to the AO feed thread. Now this check doesn't require magic numbers and does exactly what's it supposed to do.
* ao_alsa: use poll() to wait for devicewm42014-05-301-0/+30
| | | | | This means the audio feed thread is woken up exactly at the time new data is needed, instead of using a time-based heuristic.
* audio/out/push: add a way to wait for the audio device with poll()wm42014-05-302-3/+68
| | | | Will be used for ALSA.
* input: separate wakeup pipe creation into a separate functionwm42014-05-303-13/+28
| | | | | Error handling is slightly reduced: we assume that setting a pipe to non-blocking can never fail.
* audio/out/push: add mechanism for event-based waitingwm42014-05-303-76/+143
| | | | | | | | | | | | | | | | Until now, we've always calculated a timeout based on a heuristic when to refill the audio buffers. Allow AOs to do it completely event-based by providing wait and wakeup callbacks. This also shuffles around the heuristic used for other AOs, and there is a minor possibility that behavior slightly changes in real-world cases. But in general it should be much more robust now. ao_pulse.c now makes use of event-based waiting. It already did before, but the code for time-based waiting was also involved. This commit also removes one awkward artifact of the PulseAudio API out of the generic code: the callback asking for more data can be reentrant, and thus requires a separate lock for waiting (or a recursive mutex).
* audio/out: adjust documentation commentswm42014-05-301-11/+19
|
* ring: use a different type for read/write pointerswm42014-05-301-3/+3
| | | | | | uint_least32_t could be larger than uint32_t, so the return values of mp_ring_get_wpos/rpos must be adjusted. Actually just use unsigned long as type instead, because that is less awkward than uint_least32_t.
*