summaryrefslogtreecommitdiffstats
path: root/player
Commit message (Collapse)AuthorAgeFilesLines
* client API: minor documentation fixes/enhancementswm42014-06-081-2/+2
|
* 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.
* client API: restructure waiting, do log msg wakeup properlywm42014-06-071-42/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-072-5/+4
| | | | | | 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: add API function that ensures total destructionwm42014-06-073-2/+37
| | | | | | | | | | | | 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: change mpv_wait_event() timeout semanticswm42014-06-072-2/+5
| | | | | | | | | 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.
* 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-061-13/+17
| | | | | | | | | | | | | | | | | | 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.)
* 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).
* lua: make warning about unknown scripts -v onlywm42014-06-041-1/+1
|
* 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.
* player: write file name to the watch later config fileAlessandro Ghedini2014-06-011-0/+2
| | | | | | | | | 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.
* command: improve video-bitrate propertyAndrey Morozov2014-06-011-1/+4
| | | | | | Signed-off-by: wm4 <wm4@nowhere> Includes some cosmetic changes over the original PR.
* client API: report success status when running commandswm42014-06-013-29/+46
| | | | | | 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
|
* audio: change handling of an EOF corner casewm42014-05-301-7/+1
| | | | | | 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.
* audio: rename i_bps to 'bitrate' to avoid confusionMarcoen Hirschberg2014-05-281-4/+4
| | | | Since i_bps now contains bits/sec, rename it to reflect this change.
* audio: change values from bytes-per-second to bits-per-secondMarcoen Hirschberg2014-05-281-1/+1
| | | | | | | The i_bps members of the sh_audio and dev_video structs are mostly used for displaying the average audio and video bitrates. Keeping them in bits-per-second avoids truncating them to bytes-per-second and changing them back lateron.
* osc: correct calculation of slider positionChrisK22014-05-281-1/+1
| | | | | calculation the mouse position on the slider relied on how the hitbox is positioned, change it according to new hitbox size.
* osc: extend hitbox of seekbars to include gapChrisK22014-05-271-1/+1
| | | | | | should make usage a bit easy Fixes #810
* lua: slightly nicer diagnostics outputwm42014-05-271-1/+3
| | | | | | | | | | | | | When Lua itself prints errors such as: Error: [string "mp.defaults"]:387: syntax error near 'function' It's unclear why the location is prefixed with "string ". And for some reason, it disappears if you prefix the name with '@'. I suppose this is done for the sake of luaL_loadstring. With the '@' prefix added, the output is now: Error: mp.defaults:387: syntax error near 'function'
* lua: add missing include fileswm42014-05-261-0/+2
| | | | | | These are actually already included in osdep/io.h, but I think it's cleaner to repeat them in the file where they are actually needed. (osdep/io.h needs to have them for other reasons.)
* lua: fix compilation with lua 5.2wm42014-05-261-8/+42
| | | | | | | | | | | Commit e2e450f9 started making use of luaL_register(), but OF COURSE this function disappeared in Lua 5.2, and was replaced with a 5.2-only alternative, slightly different mechanism. So just NIH our own function. This is actually slightly more correct, since it forces the user to call "require" to actually make the module visible for builtin C-only modules other than "mp". Fix autoload.lua accordingly.
* command: add write_watch_later_config commandMartin2014-05-261-0/+5
| | | | | | Closes #808. Signed-off-by: wm4 <wm4@nowhere>
* lua: add some filesystem utility functionswm42014-05-251-10/+72
| | | | | | | | | | | We need this only because Lua's stdlib is so scarce. Lua doesn't intend to include a complete stdlib - they confine themselves to standard C, both for portability reasons and to keep the code minimal. But standard C does not provide much either. It would be possible to use Lua POSIX wrapper libraries, but that would be a messy (and unobvious) dependency. It's better to implement the missing functions ourselves, as long as they're small in number.
* osc: fix chapter list displayChrisK22014-05-241-2/+2
| | | | also fix small typo in DOCS
* client API: fix mpv_observe_property with MP_FORMAT_NONEwm42014-05-241-2/+3
| | | | | It returned only 1 change event (after registration), and then went silent. This was accidentally broken some time ago.
* stream: don't use end_poswm42014-05-243-13/+13
| | | | | | | | | | | | | | | | | | | Stop using it in most places, and prefer STREAM_CTRL_GET_SIZE. The advantage is that always the correct size will be used. There can be no doubt anymore whether the end_pos value is outdated (as it happens often with files that are being downloaded). Some streams still use end_pos. They don't change size, and it's easier to emulate STREAM_CTRL_GET_SIZE using end_pos, instead of adding a STREAM_CTRL_GET_SIZE implementation to these streams. Make sure int64_t is always used for STREAM_CTRL_GET_SIZE (it was uint64_t before). Remove the seek flags mess, and replace them with a seekable flag. Every stream must set it consistently now, and an assertion in stream.c checks this. Don't distinguish between streams that can only be forward or backwards seeked, since we have no such stream types.
* stream: kill start_pos, remove --sb optionwm42014-05-245-24/+6
| | | | | | | | | | | | | | | | | | | | stream.start_pos was needed for optical media only, and (apparently) not for very good reasons. Just get rid of it. For stream_dvd, we don't need to do anything. Byte seeking was already removed from it earlier. For stream_cdda and stream_vcd, emulate the start_pos by offsetting the stream pos as seen by the rest of mpv. The bits in discnav.c and loadfile.c were for dealing with the code seeking back to the start in demux.c. Handle this differently by assuming the demuxer is always initialized with the stream at start position, and instead seek back if initializing the demuxer fails. Remove the --sb option, which worked by modifying stream.start_pos. If someone really wants this option, it could be added back by creating a "slice" stream (actually ffmpeg already has such a thing).
* player: don't init/uninit terminal at runtimewm42014-05-241-7/+1
| | | | This seems like an unnecessary complication.
* lua/osc: forgot some changed files in previous commitChrisK22014-05-233-97/+20
|
* lua/osc: small overhaulChrisK22014-05-231-0/+105
| | | | | | | | | Small fixes for the OSC, seektooltip now enabled by default. Option-parser now moved to separate package, can be used from other scripts, see DOCS/man/en/lua.rst. OSC config file location moved to lua-settings/osc.conf
* player: give quit_watch_later an exit code argument like quitwm42014-05-221-6/+3
| | | | | | | | The quit command has an optional argument that is used as exit code. Extend that to the quit_watch_later command. Actually, unify the implementations of the two commands. Requested in #798.
* tl_mpv_edl: correct misspelling on line 233Yomi02014-05-221-1/+1
| | | | | | Closes #783 Signed-off-by: wm4 <wm4@nowhere>
* player: fix cover art sometimes "syncing" against audiowm42014-05-221-1/+3
| | | | | | | Cover art is treated like video, but is not really video. In one case, the audio sync code was accidentally still active. Fixes cover art playback with --ao=null. (This is due to ao_null's latency emulation. Although it's not very clear whether that is actually correct...)
* player: suggest --no-audio-display on cover artwm42014-05-221-0/+7
|
* video: fix display of cover art with vo_vdpauwm42014-05-221-2/+4
| | | | | | | | | | vo_vdpau currently has a video queue larger than 1 entry, which causes the video display code to never queue display the video frame. This is because we consider cover art an endless stream of frames decoded from the same source packet, and include special logic to actually only decode and display 1 frame. Also, make decode_image() also signal EOF in the cover art case.
* edl: use start PTS of the source files as default start timewm42014-05-221-2/+8
|
* cache: redo options and default settingswm42014-05-204-29/+18
| | | | | | | | | | | | Some options change from percentages to number of kilobytes; there are no cache options using percentages anymore. Raise the default values. The cache is now 25000 kilobytes, although if your connection is slow enough, the maximum is probably never reached. (Although all the memory will still be used as seekback-cache.) Remove the separate --audio-file-cache option, and use the cache default settings for it.
* client API: add mpv_load_config_file()wm42014-05-181-0/+15
| | | | | | | This is probably a good idea, because it would make it easier for software embedding mpv to configure the mpv parts, without requiring the host program to provide explicit mechanisms for this (other than calling mpv_load_config_file()).
* options: unify code for setting string and "raw" optionswm42014-05-182-47/+44
| | | | | | | | | The code paths for setting options by string and by direct "raw" value were too different, which resulted in some weird code. Make the code paths closer to each other. Also, use this to remove the weirdness in the mpv_set_option() implementation.
* threads: use mpv time for mpthread_cond_timedwait wrapperwm42014-05-181-2/+2
| | | | | | Use the time as returned by mp_time_us() for mpthread_cond_timedwait(), instead of calculating the struct timespec value based on a timeout. This (probably) makes it easier to wait for a specific deadline.
* player: increase seek accuracy when refreshing display on filter changewm42014-05-181-1/+1
| | | | | | | | | When the player is paused, and video filters are changed, an exact seek is executed to refresh the display. Increase the exactness of the seek in this case; this reuses the code used for frame backstepping. It might help in cases where seeking is very imprecise, such as with transport streams.
* command: add a disc-menu-active propertywm42014-05-183-0/+30
| | | | Returns whether a DVD/BD menu is active. As requested by #788.
* client API: fix "missed" property notificationswm42014-05-181-19/+25
| | | | | | | | | | | | | | | | | | If a property is notified as changed, and then again (before the change notification is returned to the client), and the second change is a sporadic change (i.e. nothing actually changed) and the change notification was associated with with a data type, it could happen that a change was "overlooked", because it would detect no change on the second notification. This is actually a pretty annoying corner case, due to the annoying way we do things, so just store both the previously returned _and_ the newly obtained property value. then we always compare with the user value to check for a change, excluding any possibility of a missed change. Note that we don't (can't/shouldn't) care if a value changes, and then changes back; it's fine if that doesn't generate a notification. This is due to how property notifications are supposed to be coalesced.
* x11: replace--[x11-]fstype option with --x11-netwmwm42014-05-161-11/+0
| | | | | Simplifies the code a lot. You can still use --x11-netwm=no to disable NetWM for whatever reasons.
* player: reorganize how lua scripts are loadedwm42014-05-138-130/+205
| | | | | | Make loading of scripts independent of Lua. Move some of the loading code from lua.c to scripting.c, and make it easier to add new scripting backends.
* player: disable hr-seek framedropping during backsteppingwm42014-05-121-2/+3
|
* player: don't assign "false" to pointerwm42014-05-111-1/+1
| | | | | | | This is legal in theory. "false" expand to 0, and 0 is a valid pointer value. But I guess this was not really intended. Found by cppcheck.
* input: remove pausing command prefixeswm42014-05-111-9/+0
| | | | | | These are now equivalent to combining commands with the "cycle pause" or "set pause" commands, and thus are not needed anymore. They were also obscure and undocumented.
* player: don't complain on too long filenameswm42014-05-101-2/+2
| | | | | | | | | mpv supports per-file config files, basically filename+".conf". We use a static buffer for the new filename, and if that buffer is too small, we print a warning. This is confusing for e.g. long URLs, so just hide the warning by default. Why not dynamically allocate the buffer? Who cares.
* command: add property that estimates current video FPSwm42014-05-081-0/+27
| | | | | | | | | | | | | | | | | | This is done after filters, so things like framerate-doubling deinterlacing is accounted for. Unfortunately, framedropping can cause inaccuracies (especially after precise seeks), and we can't really know when that happens. Even though we know that the decoder might drop a frame if we request it to do so, we don't know when the dropped frame will start or stop affecting the video filter chain. Video filters can have frames buffered, and we can't tell at which point the dropped frame would have been output. It's not even possible to mark a discontinuity after seek, because again we don't know if the filter chain still has the discontinuity within its buffers. So we have to live with the fact that the output of this property can be completely broken after seek, unless --no-hr-seek-framedrop is used.
* options: add --hr-seek-framedrop optionwm42014-05-071-1/+2
| | | | | | | | This allows disabling of decoder framedrop during hr-seek. It's basically another useless option, but it will help exploring whether this framedropping really makes seeking faster, or whether disabling it helps with precise seeking (especially frame backstepping).
* player: avoid reconfig during seekingwm42014-05-071-1/+2
| | | | | This probably matters only in extremely corner-case heavy testcases, such as using mf:// with a bunch of differently sized images.
* player: remove VO from seeking code pathwm42014-05-072-11/+26
| | | | | | | | | | | | | | | Until recently, the VO was an unavoidable part of the seeking code path. This was because vdpau deinterlacing could double the framerate, and hr- seek and framestepping etc. all had to "see" the additional frames. But we've removed the frame doubling from the vdpau VO and moved it into a video filter (vf_vdpaupp), and there's no reason left why the VO should participate in seeking. Instead of queuing frames to the VO during seek and skipping them afterwards, drop the frames early. This actually might make seeking with vo_vdpau and software decoding faster, although I haven't measured it.
* player: minor reshuffling of video codewm42014-05-071-28/+30
|
* player: limit max. fallback frame durationwm42014-05-071-1/+1
| | | | | | It's calculated from the demuxer reported FPS, which is not very reliable. Limit the damage a completely insane and broken value could cause.