summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* loadfile: make get_audio_lang function staticllyyr2023-07-171-1/+1
| | | | This fixes a build warning about missing prototypes
* DOCS/release-policy.md: add additional advicesfan52023-07-171-6/+18
|
* loadfile: compute audio lang for sub selection when using lavfi-complexrcombs2023-07-161-3/+30
| | | | | | | | When using lavfi-complex, no single track populates current_track for audio. We work around this by iterating over the list of tracks and using the first non-null language from a selected track. If multiple tracks are selected (i.e. used by the filter) and have conflicting language tags, we'll ignore them all and maintain the previous behavior (null).
* wayland: wrap resize requests in prepare_resizeDudemanguy2023-07-161-9/+19
| | | | | | | | | | | | | | | | | | | 828dd65ef84b4d8e95e70752b9eb0833909d1d23 started this and put it in the most common place, but any resize mpv is doing should be accompanied by that function call to correctly inform the compositor of the window bounds. Since we also have to set VO_EVENT_RESIZE at the same time, it makes sense to just put these in the same function. A slight thing to note is that xdg_surface_set_window_geometry uses surface local coordinates which means they are divided by the wl->scaling factor. If possible, we should use surface local coordinates directly if available (like in the toplevel config) to avoid potential rounding errors. Otherwise, just calculate it out. The linked commit actually broke some weston resizes in weird ways (window disappearing or completely freezing). Don't ask me why and I didn't attempt to find out why either, but with this it all appears to work normally again (the other compositors don't appear to be any different, and they shouldn't be), so we'll go with this since it fixes soemthing and it also is more conceptually correct.
* sd_ass: fix converted subtitles having too-wide bordersllyyr2023-07-161-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Libass commit f08f8ea5 (between 0.16 and 0.17) changed how PlayResX affects some aspects of rendering. The libass change fixes a VSFilter compatibility issue which existed for about two decades, and there are no libass plans to support the previous behavior, so ultimately we have to adjust the mpv code, and we can't guarantee to restore the old behavior in all cases. Starting at this commit, vector drawing coords, font spacing, border and shadow widths are all affected by PlayResX (specifically, by the aspect), while previously they were unaffected by PlayResX. This changed converted sub border and shadow widths in mpv, because ffmpeg generates the ass with fixed PlayResX of 384 (aspect of 4:3), and with libass 0.17, if this doesn't match the display aspect, then borders and shadow were too wide - because most clips aspect is more than 4:3. The fact that ffmpeg uses fixed PlayResX of 384 could be considered an issue, but for now we have no control over it, and ffmpeg doesn't have the video resolution when it converts an srt source to ass. So here we adjust PlayResX accordingly so that border/shadows are now rendered with correct width. However, regardless of that commit, changing PlayResX also affects the margin value, so to compensate, we adjust sub-margins-x too. According to libass devs, this should cover basic srt-to-ass conversion by ffmpeg to work correctly with libass 0.17. However, there could be srt extensions which use more complex ass, and/or ffmpeg conversion of other sub formats (such as aribb24, aribcaption and movtext), where more things need adjustments. As of now we don't know what these are, and so we don't really know what else might remain broken or get broken.
* sd_ass: don't reconfigure ass on every frameDudemanguy2023-07-151-1/+11
| | | | | | | | | | | | | | | | | | | dbc5d7b7db70f898dcd5cbbba76ffed38e5371ee seems to have originally introduced this behavior. At the time, wm4 simply reconfigured ass on every frame in order to accommodate runtime changes in sub options. This certainly works, but these libass API calls are not free and there is at least one known performance regression due to a change in libass*. Regardless of whether or not the libass change is good/bad, there is no need for mpv to constantly reconfigure this. When wm4 made that commit, there was no notification mechanism for options changing that could easily be used so he didn't really have any other choice. But it's nearly 10 years later now and internally we have all the necessary pieces to only configure ass again when we need to: on option changes or resizes. So go ahead and implement that in this commit which simply uses the already existing SD_CTRL_UPDATE_OPTS and compares osd_res sizes to determine whether or not an ass configure is needed. *: https://github.com/libass/libass/issues/698
* player: set default cache dir on macOSm154k12023-07-152-3/+18
| | | | Use ~/Library/Caches/io.mpv for caches instead of ~~home.
* DOCS/mpv: clarify the location of cache/state filesDudemanguy2023-07-151-7/+31
|
* path-win: implement cache directoriesDudemanguy2023-07-151-0/+9
| | | | | | | | | | | | 4502522a7aee093c923e79a65e4684ea2634af30 implemented cache directories but only on linux which meant other OSes continued to save this stuff in their config directory. Since we turned on cache by default, people are getting cache files in there which is understandably causing some confusion. Let's go ahead and implement a separate cache directory for windows since there seems to be some established conventions for this already. For people using the portable_path, the cache is saved in a subdirectory within the portable_path since the idea is for that to be completely self contained.
* DOCS/interface-changes: document change in ctrl+h behaviourPhilip Langdale2023-07-151-0/+1
| | | | | We now use `auto-safe` when turning on hardware decoding instead of `auto`.
* vd_lavc: map `hwdec=yes` to `hwdec=auto-safe`Philip Langdale2023-07-142-3/+3
| | | | | | To remain consistent with our belief that `auto-safe` should be the recommended mode when turning on hw decoding, let's remap `yes` from `auto` to `auto-safe`.
* vd_lavc: add `drm` and `drm-copy` to the `auto-safe` listPhilip Langdale2023-07-141-0/+2
| | | | | | | | | We have supported `hwdec=drm` for some time now, and on devices where this method is present, it is the preferred, and only, method available. Combine that with the fact that software decoding on embedded devices will not turn out well, and it's clear that we should put `drm` and `drm-copy` on the `auto-safe` list to maximise usability in simple configurations.
* input: update ctrl+h to toggle `auto-safe` rather than `auto`Philip Langdale2023-07-142-3/+3
| | | | | | | | | | | | | It has been odd that ctrl+h toggles `auto` for hwdecs even though we always recommend people start with `auto-safe`, and `auto` will attempt various hwdecs that can fail so badly we can't fall back to software decoding. With the change to more exhaustively attempt to use hwdecs, it is now easier to get into situations where these fragile hwdecs will get attempted in basic scenarios, like pressing ctrl+h. So it is high time to default to `auto-safe`.
* vd_lavc: try other hwdecs when falling back after an hwdec failurePhilip Langdale2023-07-141-2/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | Today, if hwdec initialisation succeeds, we move on to attempting decoding, and if decoding fails, we enter a fallback path that will only do software decoding. This is suboptimal because some hwdecs and codec combinations can pass hwdec init, but then fail at hwaccel init, or even frame decoding. In these situations, we will never attempt other hwdecs in the `auto` or manually specified lists which might work. One good example is someone tries to use `vulkan,auto` and tries to play av1 content. The vulkan decoding will fail at hwaccel init time, and then fallback to software instead of going through the auto list which would allow vaapi, nvdec, etc to play the file. Instead, let's not give up immediately, and try the next hwdec after a failure, just like we do if hwdec init fails. The key part of this change is to keep track of the hwdecs we have tried, so that each time we run through hwdec selection, we don't try the same one over and over again. If we really get through the whole list with no success, we will then fall back to software decoding. Fixes #11865
* vo_dmabuf_wayland: error out if compositor doesn't support the formatDudemanguy2023-07-141-2/+71
| | | | | | | | | | | | This was never implemented so in cases where the compositor didn't have support for the underlying format, the window would just be black and quite unhelpful. Well it turns out that fixing this is actually really easy because mpv has reconfig2 which returns the entire mp_image on every reconfig. We can just use that mp_image to try and obtain the format and modifier pair and then use that to check against what we know the compositor supports. If there are any problems, error out gracefully. Some code duplication with the vaapi/drmprime importers, but it's probably better to keep these separate. Fixes #11198 and fixes #11664
* build: make dmabuf-wayland a build option and require drmDudemanguy2023-07-144-20/+19
| | | | | | | It makes more sense as an option at this point. Also libdrm is not optional at all. You have to get a drm format and modifier for this to even work (the VO will just fail without DRM). Just hard require it and remove the guards. vaapi can remain optional.
* console: sort the output from the `help` commandChristoph Heinrich2023-07-141-0/+3
| | | | Closes #11927
* player: delete watch later redirect entries againGuido Cella2023-07-141-0/+2
| | | | | | | | | | 6a365b258a broke deleting redirect entries for resuming playback. If you do mpv dir1 dir2, quit-watch-later on a file in dir1, then later quit-watch-later on a file in dir2, mpv dir1 dir2 would not resume from dir2 because the redirect entry for dir1 is never deleted. Fix this by deleting watch later config files for directory/playlist entries.
* wayland: use xdg_surface_set_window_geometryDudemanguy2023-07-131-0/+1
| | | | | | | | | mpv has never used this because we never really seemed to need it, but it actually has a purpose. This informs the compositor of the actual dimensions of the mpv window and avoids errors with sizes not matching (particularly with weston). It's a better way to fix the "maximizing causing an error on weston" issue since it also works for dmabuf-wayland (which always had this problem).
* Revert "wayland_gl: wait until resize to create egl_window"Dudemanguy2023-07-131-32/+37
| | | | | | | | | | | | | | The original reason for this commit was to prevent a compositor error on weston when going into the maximized state. The configured dimensions of mpv didn't match its actual size and Weston is super strict about this so it threw a compositor error which is fatal. It only happened in opengl and this seemed like an OK workaround, so I went with this. However, there's actually a far easier way to solve this problem and we don't need this anymore. This has the benefit of avoiding a harmless warning message that appears with gpu-next on opengl. The next commit is the proper solution. Closes #10324. This reverts commit 661b5542de21d46d4d7c4693e564f4eec0526812.
* vo_dmabuf_wayland: guard in destroy_osd_buffersDudemanguy2023-07-121-0/+3
| | | | *sigh*
* vo_dmabuf_wayland: stop lazy loading hwdecDudemanguy2023-07-121-17/+12
| | | | | | | | | The implementation was copied from vo_gpu/vo_gpu_next but fundamentally it doesn't make sense for this VO. Hardware decoding is not optional in vo_dmabuf_wayland. We should be sure to request and load all supported formats in the preinit and fail if there are any problems. There should be no functional change from before, but it's more conceptually correct this way.
* vo_dmabuf_wayland: don't try to get pts without frame->currentDudemanguy2023-07-121-1/+2
| | | | Fixes a segfault with --force-window=immediate.
* draw_bmp: ensure last slice is less than total width (again)Dudemanguy2023-07-121-0/+4
| | | | | | | | | | | | | | Essentially the same as d1d2370d073e9b70a181696e57075545b4802517 except for clear_rgba_overlay. From some empirical testing, the s->x1 value is either 0 or SLICE_W (256). In the case where it is 256 and s->x0 is 0, then it writes memory. For most slices, this is fine. However for the very last slice in the loop, it is possible for the width here to exceed the total width of the line (p->w). If that occurs, the memset triggers a buffer overflow. This last case needs to be guarded in the same way as the previously mentioned commit (total width - SLICE_W * x) and with MPMIN in case s->x1 is 0 here to preserve the old behavior. It's unknown if anything other than dmabuf-wayland can possibly hit this, but it's definitely a problem within mp_draw_sub_overlay itself.
* vo_dmabuf_wayland: add osd supportDudemanguy2023-07-124-12/+231
| | | | | | | | | | | | | | | | | | This adds osd support via shm buffers using a similar approach that the normal buffers do, but it differs in a few key areas. One thing to note is that sway and weston actually handle this extremely differently which required all the abstractions here. In particular, weston does not cope well with destroying the wl_buffer from shm outside of the release handler at all (i.e. it segfaults). The workaround here is to simply attach a NULL to the osd surface and do a surface commit before we destroy the buffers. This is reasonable enough and seems to work well although it's pretty weird. Sway is more straightforward although it actually releases the osd buffer when the window goes out of sight. Also, I found that it doesn't always release every buffer before you close it unlike weston seems to do which is part of the reason all this bookkeeping is required. I don't know if there's any other compositor out there that can possibly handle vo_dmabuf_wayland right now, but suffering through these two is good enough for now I think.
* vo_dmabuf_wayland: init wl_list at the top of preinitDudemanguy2023-07-121-2/+2
| | | | | | Otherwise, we could fail and skip to uninit without initalizing this which then will segfault because the list is null and accessed while trying to destroy buffers.
* vo_dmabuf_wayland: stop guarding viewport interfacesDudemanguy2023-07-121-4/+2
| | | | | | It's entirely pointless. Not having viewport is already a fatal error for this VO as it cannot possibly work without that protocol. Just drop all these redundant if's.
* video/image_writer: check for write errorsNRK2023-07-111-3/+2
| | | | | | make sure that fwrite is error checked. and if any data was still remaining on the buffer, it will be flushed - and errors checked - via the fclose() call below.
* video/image_writer: fix file leak in error pathNRK2023-07-111-0/+1
| | | | regression from de7f4fb1e
* wscript: add 1.32 protocols to sourcesAdam Sampson2023-07-111-0/+2
| | | | | The patch that added these protocols didn't include them in the list of sources, which caused build failure with wayland-protocols 1.32.
* stats.lua: set sans-serif as default fontm154k12023-07-102-10/+3
| | | | sans is deprecated and unsupported on some platforms.
* wayland: add xdg_toplevel.wm_capabilities handlerllyyr2023-07-101-0/+10
| | | | Fixes crash when compositors advertise xdg_toplevel version >= 5
* wayland: add support for suspended toplevel stateDudemanguy2023-07-091-2/+14
| | | | | | | mpv already guesses when the window is hidden so plugging in a proper event that actually tells us this is really trivial. Note that there's some redundancy with setting wl->hidden in a few spots, but nothing can really be done about that as long as the crappy hack is still in place.
* wayland: add cursor-shape-v1 supportDudemanguy2023-07-095-12/+88
| | | | | | This protocol no longer requires us to draw a separate cursor surface and all of that horrible stuff. We can just ask the compositor for the default cursor instead since that's literally all mpv cares about.
* vd_lavc: fix delay_queue for videos with frames < max_delay_queueKacper Michajłow2023-07-091-3/+3
| | | | | | | | | | In case there are no packets from demuxer we cannot send EAGAIN, because we will not proceed and get stuck with one frame in queue and never output it. Just respect avcodec_receive_frame ret code and act accordingly. The only case to care about is EOF when we have to drain already queued frames. Fixes playback of 1-2 frame videos.
* vd_lavc: prefer d3d11va-copy over dxva2-copyKacper Michajłow2023-07-091-1/+1
| | | | | | There is no reason to prefer dxva2. I believe it was mistake from initial commit that added the hwdec list that has been propagated through years.
* vo_wlshm: bail out of resize if width/height is 0Dudemanguy2023-07-081-0/+4
| | | | | | | It can happen during initialization and of course nothing good will happen if we let this go through (i.e. segfault). Return and wait for geometry to finish setting up in the wayland stuff before doing the initial resize.
* wayland: fix memory leak with multiple monitorsDudemanguy2023-07-081-7/+5
| | | | | | | | | Very dumb. I can't remember if it was always like this or if I broke it at some point, but clearly each wl_output should just be freed in remove_output. Freeing it if it happens to be wl->current_output only works for that one monitor, so remove that whole line. This has to happen before we close the wayland connection so reorder the uninit a little bit.
* player: delete watch_later file after successful loadDudemanguy2023-07-083-6/+11
| | | | | | | | | | Currently, mpv immediately deletes the watch_later file after an attempt at playing the file is made. This is not really ideal because the file may fail to load for a variety of reasons (including not even existing), but the state is cleared anyway unconditionally. Instead, just wait until after playback is successfully initialized before deleting it. This way silly mistakes like forgetting to mount the drive doesn't result in deleting your watch_later data. Fixes #3427.
* json: unify json_parse depth to MAX_JSON_DEPTH=50cvzi2023-07-084-5/+5
|
* terminal-unix: better error detection logicNRK2023-07-081-1/+1
| | | | | | | | | | | | | | | | the reason for checking `EBADF|EINVAL` specifically is unknown. but it's clearly not working as intended since it can cause issues like #11795. instead of checking for "bad errors" check for known "good errors" where we might not want to break out. this includes: * EINTR: which can happen if read() is interrupted by some signal. * EAGAIN: which happens if a non-blocking fd would block. `tty_in` is _not_ non-blocking, so EAGAIN should never occur here. but it's added just in case that changes in the future. Fixes: https://github.com/mpv-player/mpv/issues/11795 Closes: https://github.com/mpv-player/mpv/pull/11805
* TOOLS/idet: fix some outdated cli syntaxDudemanguy2023-07-061-1/+1
| | | | | | | | d3cef97ad38fb027262a905bd82e1d3d2549aec7 changed the way the command line was parsed and syntax like "--foo value" stopped being considered valid. This old script still was using the old syntax and thus was broken. Update it to "--msg-level=ffmpeg=v" which is the recommended syntax. Fixes #11892.
* demux_playlist: sort files before directoriesChristoph Heinrich2023-07-061-22/+45
|
* demux_playlist: add option to control recursive directory loadingChristoph Heinrich2023-07-065-9/+51
| | | | | | | | | | | Directories were always loaded recursively, which can be slow (e.g. one of the subdirectories is a mounting point to a slow device) and can unexpectedly expand into a massive playlist. Due to the problems described in 503dada42f1ea1007768da0dc6a41b67cdf89400, this defaults to recursive loading. ref. https://github.com/mpv-player/mpv/issues/9652
* TOOLS/lua/autoload: allow extending ext sets from script-optsllyyr2023-07-061-0/+16
|
* various: correctly ignore cache files with --no-configDudemanguy2023-07-064-14/+25
| | | | | | | | | | | | --no-config should prevent loading user files of any type: configs, cache, etc. For cache files, this case wasn't properly handled and it was assumed they would always get something. vo_gpu's shader cache actually already handles this, so it was left untouched. In theory, demuxer cache should never have this issue because saving it to disk is disabled by default (and likely that will never change), but go ahead and change it for consistency's sake. Fixes some segfaults with --no-config and various combinations of settings (particularly --vo=gpu-next).
* vo_gpu/vo_gpu_next: enable gpu shader and icc cache by defaultDudemanguy2023-07-044-9/+13
| | | | | | | | | | | 4502522a7aee093c923e79a65e4684ea2634af30 changed the way mpv handled and saved cached files. In particular, it made a separate boolean option for actually enabling cache and left the *-dir options as purely just a path (i.e. having a dir set didn't mean you save cache). This technically regressed people's configs, so let's just turn the cache on by default. Linux users already expect random stuff in ~/.cache and well everyone else can just live with some files possibly appearing in their config directory.
* vo_gpu: fix some cache related memory leaksDudemanguy2023-07-042-2/+3
| | | | I goofed this up.
* player: add --input-cursor-passthrough optionDudemanguy2023-07-046-2/+54
| | | | | | | | | | | | | Add an option for allowing pointer events to pass through the mpv window. This could be useful in cases where a user wants to display transparent images/video with mpv and interact with applications beneath the window. This commit implements this functionality for x11 and wayland. Note that whether or not this actually works likely depends on your window manager and/or compositor. E.g. sway ignores pointer events but the entire window becomes draggable when you float it (nothing under the mpv window receives events). Weston behaves as expected however so that is a compositor bug. Excuse the couple of completely unrelated style fixes (both were originally done by me).
* TOOLS/lua/autoload: avoid unnecessary playlist manipulation, performanceEva2023-07-031-20/+29
| | | | | | | | | | | | | | We used to sort the playlist with playlist-move after every loadfile. Instead, append all files in order and call playlist-move once to move the only entry we don't control the position of. Don't fetch every playlist item separately, reuse native property. We used to pick up on new files added to the directory, but only when playing an entry at the edge of the playlist due to an early return. New files are now added to the playlist on every file change. This still works as expected and doesn't load duplicate files on shuffled playlists or playlists with files manually added after autoload 33% faster on average for my test directory with 1371 files.
* wscript: bump required libplacebo-next version to 5.266Dudemanguy2023-07-021-2/+2
| | | | | Was forgotten in b73d96776cfee61f88bf60b27315baab32a2115d. Can't wait until we finally remove the waf build.
* vo_gpu_next: remove synchronization from info_callbackKacper Michajłow2023-07-021-9/+0
| | | | VOCTRL is processed on VO thread.
* vo_gpu_next: use pl_dispatch_info_move to avoid useless data copyKacper Michajłow2023-07-022-23/+47
| | | | | Instead copy the data on-demand when VOCTRL_PERFORMANCE_DATA is requested.
* ci/msys2: double down on running meson through python3.11Kacper Michajłow2023-07-023-4/+4
| | | | | | | Run not only scripts inside build system, but also meson itself with Python 3.11. Fixes: eb4da3400a1c37eea7b258b00297e8b8fcdd8db4
* vo_x11: don't rely on XFree to free calloc-ed dataNRK2023-07-021-1/+6
|
* vo_x11: check for calloc() failureNRK2023-07-021-3/+5
|