summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* player: add --subs-with-matching-audio optionrcombs2020-08-196-9/+40
| | | | | | | | | 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.
* wayland: refactor geometry/window handlingDudemanguy2020-08-202-104/+112
| | | | | | | | | | | | | | | | | | | | | | | | | The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
* stream: Implement slice:// for reading slices of streamsMohammad AlSaleh2020-08-194-0/+200
| | | | | | | | | | | | | | | | Add support for reading a byte range from a stream via the `slice://` protocol. Syntax is `slice://start[-end]@URL` where end is a maximum (read until end or eof). Size suffixes support in `m_option` is reused so they can be used with start/end. This can be very useful with e.g. large MPEGTS streams with corruption or time-stamp jumps or other issues in them. Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
* wayland: reset geometry on reconfig if fullscreenDudemanguy2020-08-181-4/+10
| | | | Fixes #8014.
* wayland: soften GNOME warningDudemanguy2020-08-172-8/+1
| | | | | | | | | | | | | | | | | | | We've had some serious issues with GNOME in the past, but since then their compositor has undergone some major internal improvements. The most severe one [1], random vsync spikes and mistimed frames, can no longer be reproduced by the original author of the issue. There are some minor UI-related things (lack of window decorations for instance since there is no xdg-decoration support), but users don't seem to complain about that too much and they aren't revelant to playback. 3.38 isn't out quite yet, but that should also fix playback issues when on a multimonitor setup (the fix is in the master branch at the moment). In terms of playback, the only real concerning issue is the lack of idle inhibit so a warning is still displayed. But GNOME has their own workaround that users can use for that so if anyone happens to complain, we can just point them to that. [1] https://gitlab.gnome.org/GNOME/mutter/-/issues/957
* wayland: don't rely on presentation discardedDudemanguy2020-08-164-10/+4
| | | | | | | | | | | | | When using presentation time, we have to be sure to update the ust when no presentation events are received to make sure playback is still smooth and in sync. Part of the recent presentation time refactor was to use the presentation discarded event to signal that the window is hidden. Evidently, this doesn't work the same everywhere for whatever reason (drivers?? hardware??) and at least one user experienced issues with playback getting out of sync since (presumably) the discarded event didn't occur when hiding the window. Instead, let's just go back to the old way of checking if the last_ust is equal to the ust value of the last member in the wayland sync queue. Fixes #8010.
* wayland: refactor presentation timeDudemanguy2020-08-164-61/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The motivation for this change was a segfault caused by e107342 which has complicated reasons for occuring (i.e. I'm not 100% sure but I think it is a really weird race). The major part of this commit is moving the initialization of presentation listener to the frame_callback function. Calling it in swap_buffers worked fine but in practice it meant a lot of meaningless function calls if a window was hidden (the presentation would just be immediately discarded). By calling it in frame_callback, we ensure the listener is only created when it is possible to receive a presentation event. Of course calling the presentation listener in feedback_presented or feedback_discarded was considered, but ultimately these events are too slow. Receiving the ust/msc/sbc triplet here and then passing it to mpv results in higher vsync judder since there is (likely) not enough time before the next pageflip. By design, the frame callback is meant to give us as much time as possible before the next repaint so calling it here is probably optimal. Additionally, we can make better use of the feedback_discarded event. The wp_presentation_feedback should not be destroyed here. It will be taken care of either when we get feedback again or when the player quits. Instead what we can do is set a bool that tells wayland_sync_swap to update itself based on mp_time delta. In practice, the result is not any different than before, but it should be more understandable what is going on now. Of course, the segfault mentioned at the beginning is fixed with this as well.
* DOCS/vo.rst: TCT: add note on interleaved outputAvi Halachmi (:avih)2020-08-161-2/+7
|
* win32: scripting utils.get_env_list(): use UTF-8Avi Halachmi (:avih)2020-08-164-4/+15
| | | | | | | | | | | | | | | | 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-167-6/+110
| | | | | | | | | | | | | | | 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
* demux_mkv: warn against some other aspects of mismatching codec datawm42020-08-161-0/+5
| | | | | | Such files violate the specification. Unfortunately, I could not test whether it really works correctly, since I don't have a sample at hand that is not broken in this regard.
* command: export alpha type in format propertieswm42020-08-152-0/+18
|
* wayland: destroy presentation feedback on uninitDudemanguy2020-08-141-0/+3
| | | | | | | Nothing major but it's technically possible for the wp_presentation_feedback struct to still be allocated when quitting the player. Just destroy it if it exists like all of the other wayland objects.
* wayland: actually resize videos in a playlistDudemanguy2020-08-141-1/+1
| | | | | | | In a playlist of videos with different sizes, going to the next video would not properly resize the window. This actually broke way back in 7170910 (oops), but somehow nobody ever complained. The fix is simple. If a window isn't maximized, be sure to set the window geometry again.
* sd_ass: remove debug printwm42020-08-141-1/+0
| | | | It's not even spelled correctly.
* wayland: expose wayland-app-id as a user optionDudemanguy2020-08-144-0/+20
| | | | | This is extremely similar to x11's WM_CLASS. This commit allows users to set mpv's app-id at runtime for any of the wayland backends.
* wayland: tweak xdg_surface creationDudemanguy2020-08-141-5/+4
| | | | | | | | | | | | Just some small changes when creating the xdg_surface. Don't set the toplevel title (or app id) in create_xdg_surface anymore because it's entirely pointless. Also make it possible for create_xdg_surface to return something other than 0 so the error checking is somewhat meaningful. It's not really clear if these xdg functions can even fail in the first place (perhaps some weird proxy marshalling crap could possibly go wrong somehow), but it can't hurt. Note that all app id stuff has been removed (temporarily) in this commit. See the next commit which adds it back in.
* command: fix current-tracks property notificationwm42020-08-131-0/+1
| | | | Also for track-list, because it contains the "selected" flag.
* sub: add application/font-sfnt to the list of font mime typesWessel Dankers2020-08-131-0/+1
| | | | | | | According to both file(1) and https://www.iana.org/assignments/media-types/application/font-sfnt application/font-sfnt is also a valid mime type for (at least some) .ttf files.
* client API: fix misleading remarkAlcaro2020-08-131-2/+1
|
* manpage: document a couple of wayland optionsDudemanguy2020-08-121-0/+9
| | | | | --wayland-edge-pixels-pointer and --wayland-edge-pixels-touch were both left out of the manual.
* 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.
* client API: fix incorrect documentation in sw rendererwm42020-08-121-4/+4
| | | | | | This was incorrect, and grossly misleading. It created the impression that the buffer is passed to mpv_render_context_create(), instead of mpv_render_context__render().
* sd_ass: fix converted subtitles pathwm42020-08-121-7/+7
| | | | Commit cda8f1613ff3 broke this.
* DOCS/contribute.md: add a CCoCwm42020-08-121-1/+4
| | | | | | | (The recommendation is to add the document to the project git root, but I'm against dumping such things into git. I'd rather replace the Copyright full text files with links and move contribute.md to the wiki than add the CCoC text as a file.)
* sub: extend range of --sub-pos optionwm42020-08-123-5/+14
| | | | | | | | | | | | Seems like this is requested all the time. It seems libass allows out of range values, but does allows the subtitle to go out of the screen at the bottom (only when moving it to the top it's "clamped"). Too bad, don't do that then. The bitmap sub rendering code on the other hand is under our control, and will not move a subtitle out of the screen. Fixes: #7986
* sd_ass: force full reinit if certain options change at runtimewm42020-08-125-34/+60
| | | | | | | | | | Options like --sub-ass-force-style and others could not be changed at runtime (the changes didn't take any effect). Fix this by using the brutal approach, and completely reinit the subtitle state when this happens. Maybe a bit clunky, but for now I'd rather not put more effort into this. Fixes: #7689
* command: add a way to access properties of a current trackwm42020-08-122-1/+69
| | | | | | Requested. Should be good for simple use cases. "sub2" is technically inconsistent (since the option is called --secondary-sid), but fuck the consistent name.
* TOOLS/file2string: change to python3wm42020-08-121-1/+1
| | | | | | The same was done to matroska.py before, so at least it's consistent. Doesn't matter for waf, because it imports this script (rather than executing it).
* win32: request the UTF-8 code page for Windows APIsJames Ross-Gowan2020-08-081-0/+1
| | | | | | | | | | | | | | This sets the activeCodePage property in the manifest, which forces the ANSI code page to be UTF-8 in Windows 10 1903 and up. It shouldn't make a difference for mpv itself, since mpv already uses the wide-char APIs for most functions, however some of mpv's dependencies, such as Lua, rely on the ANSI codepage. Hence this change enables support for Unicode file names in Lua's I/O library. Thanks @avih for finding this property. See: https://docs.microsoft.com/en-us/windows/uwp/design/globalizing/use-utf8-code-page
* ao/lavc: add channels and channel_layout to AVFrameekisu2020-08-071-0/+2
| | | | | | FFmpeg expects those fields to be set on the AVFrame when encoding audio, not doing so will cause the avcodec_send_frame call to return EINVAL (at least in recent builds).
* auto_profiles: unapply conditional profiles if declaredwm42020-08-072-19/+37
| | | | | | Uses the mechanism introduced in the previous commit. The hope was to make auto-profiles easier to use, and to get rid of the need for manually created inverse profiles. Not sure if the end result is useful.
* options: add some way to more or less "unapply" profileswm42020-08-076-61/+212
| | | | | | | | | | | | | | | | | | | | | | | | Make it possible to restore from profiles by backing up the option values before profile application. This is sort of like unapplying a profile. Since there might be multiple ways to do this, a profile needs to explicitly provide the "profile-restore" option, which specifies how exactly this should be done. This is a big mess. There is not natural way to do this. Profile application is "destructive" and simply changes the values of the options. Maybe one could argue that the option system should have hierarchical "overlays" of profiles instead, where unset options will use the value of the lower profiles. Options set interactively by the user would be the top profile. Default values would be in the lowest profile. You could unapply a profile by simply removing it from this overlay stack. But uh, let's not, so here's something stupid. It reuses some code used for file local options to reduce code size. At least the overlay idea would still be possible in theory, and could be added as another profile-restore mode. This is used by the following commit.
* js: hooks: allow deferred continuation (match d0ab562b)Avi Halachmi (:avih)2020-08-072-3/+10
| | | | | | | | | | The callback now gets an object argument with defer/cont functions. Like the lua code, the behavior is that each hook event allows at most one continue, but nothing enforces the order of continuations if more hook events arrive before prior ones were continued - which is possible now with the defer option, but wasn't possible before (continuation was synchronous from the hook event handler).
* auto_profiles: register hooks for more synchronous profile applicationwm42020-08-051-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | The property observation mechanism is fairly asynchronous to the player core, and Lua scripts also are (they run in a separate thread). This may sometimes lead to profiles being applied when it's too load. For example, you may want to change network options depending on the input URL - but most of these options would have to be set before the HTTP access is made. But it could happen that the profile, and thus the option, was applied at an slightly but arbitrary later time. This is generally not fixable. But for the most important use-cases, such as applying changes before media opening or playback initialization, we can use some of the defined hooks. Hooks make it synchronous again, by allowing API users (such as scripts) to block the core because it continues with loading. For this we simply don't continue a given hook, until we receive an idle event, and have applied all changes. The idle event is in general used to wait for property change notifications to settle down. Some of this relies on the subtle ways guarantees are (maybe) given. See commit ba70b150fbe for the messy details. I'm not quite sure whether it actually works, because I can't be bothered to read and understand my bullshit from half a year ago. Should provide at least some improvement, though.
* lua: make hook processing more flexiblewm42020-08-052-4/+41
| | | | | | | This can now opt to not continue a hook after the hook callback returns. This makes it easier for scripts, and may make it unnecessary to run reentrant event loops etc. for scripts that want to wait before continuing while still running the event loop.
* auto_profiles: add this scriptwm42020-08-0513-7/+326
| | | | | | | | | | | | | | | | | | | | | This is taken from a somewhat older proof-of-concept script. The basic idea, and most of the implementation, is still the same. The way the profiles are actually defined changed. I still feel bad about this being a Lua script, and running user expressions as Lua code in a vaguely defined environment, but I guess as far as balance of effort/maintenance/results goes, this is fine. It's a bit bloated (the Lua scripting state is at least 150KB or so in total), so in order to enable this by default, I decided it should unload itself by default if no auto-profiles are used. (And currently, it does not actually rescan the profile list if a new config file is loaded some time later, so the script would do nothing anyway if no auto profiles were defined.) This still requires defining inverse profiles for "unapplying" a profile. Also this is still somewhat racy. Both will probably be alleviated to some degree in the future.
* manpage: clarify requirements for boxvideoDudemanguy2020-08-041-1/+2
| | | | The osc must not auto-hide for this option to do anything.
* wayland: don't set mouse pos on state changeDudemanguy2020-08-022-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Sway 1.5 started sending more pointer motion events to mpv which broke the autohiding behavior. The cursor would appear again if you fullscreened. Sway had a good reason to do this because certain applications had inconsistencies between hardware cursor and software cursor without rebasing on state changes[1]. So mpv needs to take this special case into consideration. Initially, simply checking mouse coordinates for changes was considered, but this doesn't work. All coordinates are surface-local in wayland so something can appear to move in the local coordinate space but not globally. You're not allowed to know global mouse coordinates in wayland, and we don't care about local coordinate changes in mpv so this approach isn't viable. Instead, let's just keep track of a local state change. If the toplevel surface changes in some way (fullscreen, maximized, etc.), then just set a bool that lets us ignore the mp_input_set_mouse_pos function. This keeps the cursor from appearing simply because the state was changed (i.e. fullscreening). For compositors that don't send pointer motion events on a state change, this does technically mean that the initial mp_input_set_mouse_pos is never set. In practice, this isn't a noticeable difference though because moving a mouse generates a ton of motion events so you'll immediately see it on the second motion event. [1] https://github.com/swaywm/sway/issues/5594
* stats: fix crash when aspect ratio is unavailableEva2020-08-031-1/+3
| | | When switching between files it's possible that r["aspect"] returns nil, resulting in a crash.
* ytdl_hook: fix typo in unexpected error messageDerek Guenther2020-08-011-1/+1
|
* wayland: avoid potential deadlocksDudemanguy2020-07-311-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | wl_display_dispatch is dangerous because it will block forever if the event queue is empty. Any direct calls to this function should just be replaced with wl_display_dispatch_pending which accomplishes the same thing for mpv's purposes without any chance of blocking. The other potential trap is wl_display_roundtrip. It can internally call wl_display_dispatch which in certain circumstances could potentially block. There are cases where we need the server to finish processing client requests before doing anything else so this can not be cleanly avoided. The dangerous call is the usage of wl_display_roundtrip in vo_wayland_wait_frame. In the majority of cases, this shouldn't be a problem because the previous wl_display_read_events should always queue up some events on the fd for wl_display_roundtrip to send. However, the compositor could potentially send us an error in the display queue that could lead to bad behavior when wl_display_roundtrip is called. The wl_display_roundtrip can't be removed because we are relying on its semi-blocking capabilities, but the logic can be slightly adjusted to be safer. The obvious thing to do is to make sure we check the pollfd for any errors. If one is returned, then we call wl_display_cancel_read and try again. The less obvious trick is to call wl_display_dispatch_pending and move wl_display_roundtrip outside of the blocking + timeout loop. This change has some subtle but important differences. Previously, vo_wayland_wait_frame would read an event and wait on the server to process it one-by-one. With this change, the events are dispatched as soon as possible to the server and then we wait on all of those (potentially multiple) events to be processed after we have either received frame callback or the loop times out. After that is done, we can then check for if there are any errors on the display. If it's all clear, we can run wl_display_roundtrip without any worries. If some error happens, then don't execute the function at all.
* travis: update macOS image from 10.14 to 10.15der richter2020-07-311-1/+1
|
* travis: make macOS builds fasterder richter2020-07-311-28/+18
| | | | | | | | | | | | | | the problem here is that with time, and because the macOS VMs don't get updated, the homebrew update is getting longer since more and more changes have to be pulled. to prevent that, we cache the homebrew installation folder after the update. that way we don't have to update several months worth of updates every build. for the legacy build we have to check put master again to actually cache the newest homebrew version. additionally to that, we also do the same as on the legacy build, with the addition of not removing all installed formulas but only the ones we don't need. so we don't need to reinstall those.
* travis: fix macOS 10.12 legacy buildder richter2020-07-311-0/+1
| | | | | | | | | just remove all pre installed formulas, since we don't need the majority of it. after that install what we need. this also fixes the brew update of those formulas where the source links were broken like popt. this also helps when the build times out due to building some formulas from source that are not dependencies we need.
* wayland: correctly signal the end of drag-and-dropDudemanguy2020-07-291-1/+1
| | | | | | | | | | | | Previously, the compositor was signaled that a drag-and-drop ended with wl_data_offer_finish in check_dnd_fd. This is, however, erroneous because it is outside of the data_device_listener and in some cases caused errors with certain compositors. check_dnd_fd itself does not need to know or care about anything that happens in wayland. It just needs to read data from an fd. The simple fix is to just always signal the end of a drag-and-drop in data_device_handle_drop. check_dnd_fd can free memory and close the fd later, but it should not talk to the compositor. Fixes #7954.
* wayland: fix a potential race in wait_eventsDudemanguy2020-07-291-4/+7
| | | | | | | The read of the wayland display fd in vo_wayland_wait_events was incorrect and technically vulnerable to race conditions. The correct usage as per the client api is to use wl_display_prepare_read as well as wl_display_read_events.
* af_scaletempo2: fix bug where speed was not setDorian Rudolph2020-07-271-1/+0
| | | | | | the --speed parameter did not work with mpv --no-config whatever.mp3 --video=no --speed=2 --af=scaletempo2 (https://github.com/mpv-player/mpv/pull/7865#issuecomment-664243401)
* af_scaletempo2: M_PI is always definedwm42020-07-271-4/+0
| | | | I forgot why/how (C99?), but other code also uses it.
*