summaryrefslogtreecommitdiffstats
path: root/player
Commit message (Collapse)AuthorAgeFilesLines
* player: make resetting of track selection to "auto" worksfan52021-01-161-9/+21
|
* console: use wl-paste on WaylandGuido Cella2020-12-141-1/+11
|
* auto_profiles: fix compile_cond on lua 5.1Philip Sequeira2020-12-081-6/+10
| | | | | | 5.1's load() doesn't accept strings; loadstring must be used instead. In 5.2, loadstring is deprecated and setfenv is gone.
* player: allow vo to be switched at runtimesfan52020-11-273-7/+23
|
* command: mouse: generate MOUSE_{ENTER,LEAVE} if requiredAvi Halachmi (:avih)2020-11-161-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | Previously the mouse command never ended up in enter/leave keypresses for the default section even when logically required, because input.c does not know the area of the default section and relies on something feeding it ENTER/LEAVE presses - which the VO typically does but the mouse command didn't. Now the mouse command feeds it ENTER/LEAVE if required. It's possible to handle it differently and more consistently by: 1. reverting this commit. 2. Updating the default section area whenever the osd dimensions change. 3. Always ignore MOUSE_ENTER keys because the position is not known yet (but MOSE_MOVE typically follows right away). 4. On mouse move: first generate ENTER/LEAVE if required. That would guarantee consistency between mouse position and enter/leave events but could be more sensitive to manage (the default section has "infinite" area which is used to capture any event outside of specific section areas), while this commit keeps consistency same as before and depending on correct external feeding - which we now do better, even if still not optimally (like before, it's still technically possible that a script recieves MOUSE_ENTER and then reads the position before it got updated after the ENTER).
* command: mouse-pos property: add field "hover"Avi Halachmi (:avih)2020-11-161-2/+3
| | | | | | | | | | | | | | | | | | | | | Add a third field: "hover", which is updated from input.c after input keys MP_KEY_MOUSE_LEAVE and MP_KEY_MOUSE_ENTER - which are typically sent by the VO. It's part of mouse-pos and not a new property because it's highly tied to mouse-pos - it makes x/y invalid while the cursor doesn't hover the window. Unike mouse-move, no dummy command was generated, so we add dummy command in order for observer notification to work even while nothing is bound. Like mouse-pos, clients could not detect whether the mouse pointer hovers the window because the OSC force-binds the MOUSE_LEAVE key, and now they can using the hover field. The lua mp.get_mouse_pos() wrapper still returns only x, y because that's what osc.lua needs. Other clients can simply read the property.
* lua/js: mp.get_mouse_pos: use the mouse-pos propertyAvi Halachmi (:avih)2020-11-164-22/+6
| | | | | | | mp.get_mouse_pos() is undocumented and is no longer required - the property can be used officially by any client now, however, osc.lua uses it, and also some user scripts learnt to rely on it, so we keep it - as a trivial wrapper around the new mouse-pos property.
* command: new property: mouse-posAvi Halachmi (:avih)2020-11-161-0/+30
| | | | | | | | | | | | | | | This is a read-only MPV_NODE value with integer fields: x, y. The values are unmodified from mp_input_get_mouse_pos(...). Observer notification of this property is tied to the INPUT_PROCESSED event, which fires after mouse move even if no command is bound (dummy commands are generated if nothing is bound to ensure that mp_input_get_mouse_pos returns the latest values - see ac927e39 ). This allows clients such as JSON IPC to observe mouse position even while the OSC is enabled - the OSC force-binds mouse move for most of the window area, making it impossible for other clients to bind mouse move without breaking the OSC.
* command: add internal INPUT_PROCESSED eventAvi Halachmi (:avih)2020-11-162-0/+5
| | | | | | Fires after a non-empty input queue was processed. Currently yet unused, but the next commit will use it.
* js: report scripts CPU/memory usage statisticsAvi Halachmi (:avih)2020-11-151-1/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This can be viewed at page 4 of the internal stats display (i or I). CPU time report is the same as at lua.c, but untested - doesn't seem to work on windows - also not for lua. TL;DR: Set env MPV_LEAK_REPORT=1 to enable js memory reporting stats. This also almost doubles the memory usage by js scripts. For memory reporting, we don't have enough info by default, because even when using a custom allocator, mujs doesn't report the old size (on free or realloc) because it doesn't track this value, and as a result we can't track the overall size. Our option are either to track the size of each allocation on our own, or use talloc which tracks this value. However, using talloc for mujs allocations adds a considerable overhead, and almost doubles(!) the overall memory used, because each individual allocation includes a considerable talloc header, and mujs does many small allocations. So our solution is that by default we behave like previously - not using a custom allocator with mujs, and stats does not display memory usage for js scripts. However, if the env var MPV_LEAK_REPORT is set to 1, then we use a custom allocator with talloc and track/report memory usage. We can't switch allocator at runtime, so an mpv instance either tracks or doesn't track js scripts memory usage, according to the env var. (we could use a property and apply it whenever a new script starts, so that it could change for newly launched scripts, but we don't).
* command: make subtitle time properties observableBen Kerman2020-11-111-1/+2
|
* player: fix external cover file prioritizationsfan52020-10-281-4/+8
| | | | | Array order was ignored entirely instead of being used as intended. Fixes: c07089a250
* console: let type set the cursor positionGuido Cella2020-10-271-4/+10
| | | | | | | | | | | | | | | | | | This allows keybindings such as: a script-message-to console type "seek :0 absolute" 6 % script-message-to console type "seek absolute-percent" 6 The cursor position 0 isn't allowed because it has the weird effect of filling the console with the text twice, leaving the cursor in the middle. Negative positions would put the cursor n characters before the end, and positions greater than the text's length at the end. They seem to work at first, but the console breaks when you move the cursor, so they aren't allowed. It seems that float values don't cause issues, but I'm using the argument's floor anyway to be safe. Using >= 1 instead of > 0 ignores values like 0.5.
* ytdl_hook: if ytdl not found in config dirs, use ytdl_path as isRicardo Constantino2020-10-271-1/+4
|
* ytdl_hook: support alternative youtube-dl pathRicardo Constantino2020-10-271-2/+4
| | | | | Allows using a youtube-dl not in PATH or a compatible fork of youtube-dl.
* player: reorder list of external cover files for optimal resultssfan52020-10-251-7/+9
|
* command: add delete-watch-later-configVladimir Panteleev2020-10-223-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces the delete-watch-later-config command, to complement write-watch-later-config. This is an alternative to #8141. The general problem that this change is attempting to help solve has been described in #336, #3169 and #6574. Though persistent playback position of a single file is generally a solved problem, this is not the case for playlists, as described in #8138. The motivation is facilitating intermittent playback of very large playlists, consisting of hundreds of entries each many hours long. Though the current "watch later" mechanism works well - provided that the files each occur only once in that playlist, and are played only via that playlist - the biggest issue is that the position is lost completely should mpv exit uncleanly (e.g. due to a power failure). Existing workarounds (in the form of Lua scripts which call write-watch-later-config periodically) fail in the playlist case, due to the mechanism used by mpv to determine where within a playlist to resume playback from. The missing puzzle piece needed to allow scripts to implement a complete solution to this problem is simply a way to clean up the watch-later configuration that the script asked mpv to write using write-watch-later-config. With that in place, scripts can then register an end-file event listener, check the stop playback reason, and in the "eof" and "stop" case, invoke delete-watch-later-config to delete any saved positions written by write-watch-later-config. The script can then proceed to immediately write a new one when the next file is loaded, which altogether allows mpv to resume from the correct playlist and file position upon next startup. Because events are delivered and executed asynchronously, delete-watch-later-config takes an optional filename argument, to allow scripts to clear watch-later configuration for files after mpv had already moved on from playing them and proceeded to another file. A Lua script which makes use of this change can be found here: https://gist.github.com/CyberShadow/2f71a97fb85ed42146f6d9f522bc34ef (A modification of the one written by @Hakkin, in that this one takes advantage of the new command, and also saves the state immediately when a new file is loaded.)
* stats: display hw pixel format toosfan52020-10-161-0/+4
|
* command: expose underlying pixfmt for hwdecsfan52020-10-161-0/+2
|
* player: fix another nightmarish corner casewm42020-10-081-3/+14
| | | | Pretty much fuck this shit.
* screenshot: add --screenshot-sw optionwm42020-10-051-1/+2
| | | | | Probably worthless. As usual, the manpage dumps all the subtle differences due to implementation details on the user.
* player: cosmetically change around some codewm42020-09-281-9/+9
| | | | Is this better?
* player: add automatic loading of external cover art fileswm42020-09-283-5/+50
| | | | | | | | | | | | | | | | | | | | | | | Picks up files like "cover.jpg". It's made part of normal external file loading, so I'm adding 3 new options that are direct equivalents for the options that control loading of external subtitle and audio files. Even though I bet nobody wants them and they just increase confusion... I guess the world is actually hell, so this outcome should be fine. It prefers non-specific external files like "cover.jpg" over embedded cover art. Not sure if that's wanted or unwanted. There's some pain over explicitly marking such files as external pictures. This is basically an optimization: in most cases, a heuristic would treat an image file loaded with --external-file the same (it's a heuristic because ffmpeg can't tell us whether something is an image or a video). However, even with this heuristic, it would decode the cover art picture again on each seek, which would essentially slow down seeking in audio files. This bothered me greatly, which is why I'm adding these additional options at all, and bothered with the previous commit. Fixes: #3056
* player: let frontend decide whether to use cover-art modewm42020-09-281-1/+4
| | | | | | | | | | | | | Essentially, this lets video.c decide whether to consider a video track cover art, instead of having the decoder wrapper use the lower level sh_stream flag. Some pain because of the dumb threading shit. Moving the code further down to make some of it part of the lock should not change behavior, although it could (framedrop nonsense). This commit should not change actual behavior, and is only preparation for the following commit.
* player: add pause state to playback start messagewm42020-09-211-2/+3
| | | | | Now the player tells you that audio or video are playing while paused, or something.
* options: simplify --android-surface-size handlingsfan52020-09-201-1/+1
|
* command, demux: make drop-buffers reset state even harderwm42020-09-171-2/+1
| | | | Leave nothing left when it's executed.
* command: add property track-list/N/main-selectionwnoun2020-09-121-0/+11
|
* player: fix inconsistent AO pause state in certain situationswm42020-09-122-8/+3
| | | | | | | | | | | | | | | | | | Pause can be changed during a file change, such as with for example --reset-on-next-file=pause, or in hooks, or by being quick, and in this case the AO's pause state was not updated correctly. mpctx->ao_chain is only set if playback is fully initialized, while the AO itself in mpctx->ao can be reused across files. Fix this by always running set_pause_state() if the pause option is changed. Could cause new bugs since running this used to be explicitly avoided outside of the loaded state. The handling of time_frame is potentially worrisome. Regression due to recent audio refactor; before that, the AO didn't have a separate/persistent pause state. Fixes: #8079
* player: some minor code golfwm42020-09-101-11/+6
|
* player: clamp relative seek base time to nominal durationwm42020-09-101-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since b74c09efbf7, audio-only files let you seek to arbitrary points beyond the end of the file (but still displayed the time clamped to the nominal file duration). This was confusing and just not wanted. The reason is probably that the commit removed setting the audio PTS for data before the seek target, so if you seek past the end of the file, the audio PTS is never set. This in turn means the logic to determine the current playback time has no PTS at all, and thus falls back to the seek PTS. This happened in the past for other reasons (like efe43d768f). I have enough of this, so I'm just changing the code to clamp the seek timestamp to a "known" range. Do this when seeking ends, because in the fallback case, the playback time shouldn't be stuck at e.g. "end + seek_argument". Also do it when initiating a new seek (mp_seek), because if the previous seek hasn't finished yet, it shouldn't add them up and allow it to go "out of range" either. The latter is especially relevant for hr-seeks. Doing this clamping is problematic because the duration is a possibly invalid value from the demuxer, or just missing. Especially with timestamp resets, fun sometimes happens, and in these situations it might be better not to clamp. One could argue you should just use the last audio timestamp returned by the decoder or demuxer (even if that directly conflicts with --end), but that sounds even more hairy. In summary: what a dumb waste of time, what the fuck.
* command: add read-only focused propertyGuido Cella2020-09-083-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a property that returns whether the window is focused, currently only for X11 and Wayland. My use cause for this is having an equivalent of pause-when-minimize.lua for tiling window managers: make mpv play only while it's in the current workspace or is focused (I'm fine with either one but prefer focus). On X I do this by observing display-names, which is empty when the rectangles of the display and mpv don't intersect, but on Wayland its value doesn't change when mpv leaves the current workspace (and the same check doesn't work since the geometries still intersect). This could later be made writable as requested in #6252. Note that on Wayland se shouldn't consider an unactivated window with keyboard input focused. The wlroots compositors I tested set activated after changing the keyboard focus, so if you set wl->focused only in keyboard_handle_enter() and keyboard_handle_leave() to avoid adding the "has_keyboard_input" member, focused isn't set to true when first opening mpv until you focus another window and focus mpv again. Conversely, if that order can't be assumed for all compositors, we should toggle wl->focused when necessary in keyboard_handle_enter() and keyboard_handle_leave() as well as in handle_toplevel_config().
* encode: propagate errors to exit status properlywm42020-09-032-1/+7
| | | | | Don't just let mpv CLI return 0 (success) as exit status if encoding failed somehow.
* client API: inactivate the opengl_cb APIwm42020-09-031-88/+10
| | | | | | | | | | The render API replaced the opengl_cb API over 2 years ago. Since then, the opengl_cb API was emulated on top of the render API. While it would probably be reasonable to emulate these APIs until they're removed in an eventual libmpv 2.0 bump, I have some non-technical reasons to disable the API now. The API stubs remain; they're needed for formal ABI compatibility.
* encode: disable unsupported media types automaticallywm42020-09-031-1/+10
| | | | | | | If you encode to e.g. an audio-only format, then video is disabled automatically. This also takes care of the very cryptic error message. It says "[vo/lavc] codec for video not found". Sort of true, but obscures the real problem if it's e.g. an audio-only format.
* encode: remove early EOF failure handlingwm42020-09-032-2/+0
| | | | | | | I don't see the point of this. Not doing it may defer an error to later. That's OK? For now, it seems better to reduce the encoding internal API. If someone can demonstrate that this is needed, I might reimplement it in a different way.
* audio: slightly simplify audio_start_ao()wm42020-09-031-10/+4
| | | | Get rid of an indirection; no behavior change.
* audio: reduce excessive logging of delayed audio startwm42020-09-032-2/+9
| | | | | | | Since this is a messy and fragile mechanism, I want it logged (even if it's somewhat in conflict with the verbose logging policy). On the other hand, it's unconditionally logged on every playloop iteration. So add some nonsense to log it only on progress.
* audio: do not show audio draining message when it does not make sensewm42020-09-011-1/+3
| | | | | | Just for the redundant message. The function which is called here, ao_drain(), does not care in which state it is called, and already handled this gracefully.
* audio: do not wake up player when waiting for audio state and pausedwm42020-09-011-1/+2
| | | | Bullshit.
* player/playloop.c: reorder included headers per contribute.mdLeo Izen2020-08-311-17/+14
| | | | | This commit sorts the included headers alphabetically and puts them in sections, as described by DOCS/contribute.md.
* audio: refactor how data is passed to AOwm42020-08-295-377/+334
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This replaces the two buffers (ao_chain.ao_buffer in the core, and buffer_state.buffers in the AO) with a single queue. Instead of having a byte based buffer, the queue is simply a list of audio frames, as output by the decoder. This should make dataflow simpler and reduce copying. It also attempts to simplify fill_audio_out_buffers(), the function I always hated most, because it's full of subtle and buggy logic. Unfortunately, I got assaulted by corner cases, dumb features (attempt at seamless looping, really?), and other crap, so it got pretty complicated again. fill_audio_out_buffers() is still full of subtle and buggy logic. Maybe it got worse. On the other hand, maybe there really is some progress. Who knows. Originally, the data flow parts was meant to be in f_output_chain, but due to tricky interactions with the playloop code, it's now in the dummy filter in audio.c. At least this improves the way the audio PTS is passed to the encoder in encoding mode. Now it attempts to pass frames directly, along with the pts, which should minimize timestamp problems. But to be honest, encoder mode is one big kludge that shouldn't exist in this way. This commit should be considered pre-alpha code. There are lots of bugs still hiding.
* player: fix video paused condition on VO creationwm42020-08-273-2/+8
| | | | | Doesn't take paused_for_cache into account. For consistency; unlikely to matter at all in practice.
* player: fix swapped debug outputwm42020-08-271-2/+2
| | | | Such failure.
* audio: remove delay debug loggingwm42020-08-232-28/+0
| | | | Some absurd useless stuff.
* player: do not loop if there's nothing to loopwm42020-08-221-0/+5
| | | | | | | | | | | | | | | | | This can happen if a file contains headers only, or if decoding of all data failed, and such. Interestingly, it also happened when doing "mpv --loop emptyfile.png", because demux_mf still detects file formats by file extension. In this situation, the player burned a lot of CPU by restarting playback after doing nothing. Although such "degenerate" behavior can't be avoided in all situations (what if you loop a file with 1 audio sample?), detecting this seems to make sense. For now, this actually decrements the loop count by 1, and then errors out with a warning. Works for --loop and --ab-loop, while --loop-playlist already avoids this situation with an existing mechanism.
* player: add --subs-with-matching-audio optionrcombs2020-08-191-5/+16
| | | | | | | | | This allows users to control whether full dialogue subtitles are displayed with an audio track already in their preferred subtitle language. Additionally, this improves handling for the forced flag, automatically selecting between forced and unforced subtitle streams based on the user's settings and the selected audio.
* win32: scripting utils.get_env_list(): use UTF-8Avi Halachmi (:avih)2020-08-162-4/+0
| | | | | | | | | | | | | | | | lua/js utils.get_env_list() uses `environ' which was ANSI, thus it broke any unicode names/values. mpv already has an internal utf8_environ for win32, but it's used only at the getenv(..) wrapper and not exposed in itself, and also it has lazy initialization - on first getenv() call. Now `environ' maps to a function which ensures initialization while keeping it an l-value (like posix expects). The cost of this fuglyness is that files should include osdep/io.h (which now declares environ as extern) rather than declaring it themselves, or else the build will break on mingw.
* lua: pass strings with embedded zeros as byte arrayswm42020-08-161-3/+14
| | | | | | | | | | This was a vague idea how to handle passing byte arrays from Lua to the mpv command interface in a somewhat reasonable way. The idea was cancelled, but leave the Lua part of it, since it might get useful later, and prevents passing (and silently cutting off) such byte strings. Barely tested, let's say not tested at all.
* command: extend subprocess command stdin, change behaviorwm42020-08-161-1/+26
| | | | | | | | | | | | | | | Make it possible to feed a string to stdin of a subprocess. Out of laziness, it can't be an arbitrary byte string. (Would require adding an option type that takes in a Lua byte string.) Do not set stdin of a subprocess to fd 0 (i.e. mpv's stdin) anymore, because it makes things more consistent. Enabling stdin didn't make too much sense in the first place, so this behavior change seems justifiable. win32 support missing. Fixes: #8003
* command: export alpha type in format propertieswm42020-08-151-0/+11
|
* command: fix current-tracks property notificationwm42020-08-131-0/+1
| | | | Also for track-list, because it contains the "selected" flag.
* ytdl_hook: sort subtitle list by languagewm42020-08-121-1/+7
| | | | | | The subtitle list is returned in randomized order, because a table (i.e. JSON object) is used. To make the order stable across repeated invocations, sort it by language.
* sd_ass: force full reinit if certain options change at runtimewm4